O'Reilly logo

Patterns: Implementing Self-Service in an SOA Environment by Fernando Teixeira, Shashi Shrimali, Peter Hood, Sandy Grewal, Diego Cotignola, Anup Aggarwal, Carla Sadtler

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

182 Patterns: Implementing Self-Service in an SOA Environment
While these proposals and specifications are still evolving, it is recommended
that we, as architects and developers, actively participate in, review, comment,
and help improve the specifications. Also evaluate early implementations for
inclusion in corporate architecture standards and possible application
implementation. If there is urgent need for designing and implementing a Web
services-based transactional infrastructure and related business services, we
recommend using the principles behind the new specifications.
7.3.4 Best practices for Web services
Web services constitute a distributed computer architecture made up of different
computers communicating over a network to form one system. In this section, we
focus on best practices for Web services development and deployment within a
J2EE environment, that is Web services that are built using servlets, JSP pages,
EJB architecture, and all the other standards that are part of the J2EE
technology.
Apply distributed computing principles
Think of Web services as another technology for developing distributed systems.
All of the best-practice principles used in developing distributed systems apply to
Web services. All of the considerations that would go into any enterprise systems
design apply to Web services, such as high availability, high throughput,
clustering, hardware management, and network topology.
The main difference between most distributed systems and Web services is that
Web services are newer. Most Web services software is less than a year old. As
a rule, there is not the same level of reliability, security, or performance that you
would find with other distributed systems software that has been around longer.
Another factor is that Web services are built on a set of technologies (SOAP,
XML, WSDL, UDDI) that are still evolving and are being evolved by separate
standards organizations and vendors in parallel. It will be some time before all of
these standards will be able to converge, especially given the Sun versus
Microsoft debate. Because of the lack of a solid set of standards, implementation
details are left for individuals. Still, some common principles can be adopted as
best practices at this time:
򐂰 Design systems that are layered
This is the same principle that you would apply to any distributed, component
architecture. It is especially important in Web services applications where we
do not have control over some components (services) that we access in our
application.
Chapter 7. Application and system design guidelines 183
򐂰 Design coarse-grained Web services
Web services have all of the same issues as those of distributed systems
when it comes to requesting a remote service. Requesting a service from a
machine over the network is more expensive than a local operation. With this
in mind, keep the request as coarse-grained as possible when requesting a
Web service from a remote machine.
Existing JavaBeans or EJBs with fine-grained methods or operations should
be aggregated into a single coarse-grained Web service, wherever possible.
This technique avoids unnecessary network traffic and overhead on the
communication stack. This also makes it possible to push the transaction
integrity requirements to the Web service provider making for a cleaner
design. In other words, if a coarse-grained request did not successfully
complete, then the Web service provider can roll back that entire transaction.
򐂰 Design for loosely coupled components.
A Web service by definition is an interface to a loosely-coupled component on
a remote system. Therefore, it is very important to be cognizant of the impact
of integrating loosely coupled components. With this in mind, define clear
contracts between layers and services, but use the Parameter List paradigm
where possible.
򐂰 Limit dependency on other components.
Managing dependencies is one of the key challenges in using Web services
in an intranet or extranet scenario. Common dependencies that occur in an
application design are:
Call flow dependency
Business processes implemented by systems are not typically within the
domain of one business component.
Object association dependency
Using object-oriented techniques, it is easy to model a business problem
by associating objects together. However, from an implementation
perspective, doing so increases the linkage from one component to
another. Use interfaces where possible.
򐂰 Implement all cross “domain” business processes in a control or workflow
layer.
The flexibility of an application is increased if all business processes that
cross multiple business domains are implemented in a workflow layer. In
doing so, the application architecture has more flexibility in what is called,
when it is called, managing the call (such as exception handling), and
performing any translation on the data that is passed in or out.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required