Patterns: Implementing Self-Service in an SOA Environment

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.