Applying Design Issues and Patterns in Web Services

Leveraging Well-Known Design Patterns
One area where Web service and object-oriented designs are comparable is in the use of patterns. In his book "Analysis Patterns" (Addison-Wesley), Martin Fowler defines a pattern as "an idea that has been useful in one practical context and will probably be useful in others."

Patterns are good constructs for designing Web services. In particular, there are several well-known patterns that apply, such as can be found in "Core J2EE Patterns: Best Practices and Design Strategies" (Prentice Hall PTR).

Adapter or Wrapper: Used to expose internal application functionality with a different interface
Façade: Used to encapsulate complexity and provide coarse-grained services
Proxy: Used as a surrogate for another object or service.

The Wrapper pattern leverages the popular Adapter pattern. The basic idea is to convert a component's interface into another interface that the client expects. This would typically be used to provide some compatibility with the client. The adapter pattern can be used to expose existing technologies as Web services. For example, if you are running on a J2EE platform and have a need to interact with a C++ component, you may wrap the C++ component with JNI code, and then expose that Java interface as a Web service using the available Web services tools.

The Façade pattern is a familiar approach to building coarse-grained services. In J2EE, the Façade was represented by a session bean, while the fine-grained components were typically entity beans. For Web services, the same approach can be leveraged. The idea is to take existing components that are already exposed and encapsulate some of the complexity into high-level, coarse-grained services that meet the specific needs of the client. In using this approach, you can enhance overall performance of the Web services interactions and centralize infrastructure services such as security and transactions. Figure 4 shows the relationships between an application's presentation and business tiers using the Façade pattern.


Figure 4: The Façade Pattern. The Façade pattern here is used between presentation and business tiers as a method of encapsulating application logic to address the specific needs of particular clients.

In the Proxy pattern one object can be used as a surrogate for another, often to offload processing from one component to another. This pattern has been frequently used to hide complexity of the SOAP messaging constructs. It can also be used in the development of mock objects, which have been around for quite some time.

These are just a few of the design patterns that can readily be applied to Web service development. As you become more comfortable with Web service paradigms, you will find these patterns can guide you just as they do with other types of object-oriented design.

Levels of Security
As you know, Web services creates another avenue for hackers to exploit corporate resources. Detailed knowledge of Web service security layers and their use leads to markedly more secure architectures.

Rather than focus on the various evolving Web service security standards, this article will focus on what improvements can be achieved today. There are three levels at which Web service security can be applied:

Transport: SSL/HTTPS—encrypts the connection, but not the data
Message: Data Encryption (XML Encryption) / Digital signatures (XML-DSIG)
Infrastructure: Leveraging the application server security mechanisms.

The transport level is probably one of the easiest ways to introduce security into your architecture. The idea is to leverage the transport security mechanisms that are already available to help secure the connection between the client and the service. With this approach, you would leverage SSL and HTTPS to potentially encrypt the data while it is on the communication pipe.

However, this approach has two limitations. First, you are only securing the connection, not the data itself. This means that while the data is in transit, it will be secure. But, at the point it reaches the destination or any intermediary, there is nothing to protect the information. For Web services, protection at the destination is vital because the data could be processed by many intermediaries. The other limitation is that it's basically an all-or-nothing operation—you cannot selectively control what specific data is encrypted and who might be authorized to view it.

The second level of security deals with securing the message itself. Here, you would leverage some of the available XML standards to help encrypt or sign the data. XML digital signatures are typically used for data integrity, authentication, and non-repudiation. You may use message-level security to validate that a given SOAP message came from a particular party and that it hasn't been modified.

XML Encryption adds the confidentially aspect, indicating whether the data can be viewed by the receiver. These XML security standards have been around for awhile and are fairly stable for development projects. There are other Web services security standards (e.g., SAML and WS-Security) that are still being defined by the industry.

Finally, you may want to leverage some of the security features of the infrastructure that is hosting the Web service. In the case of a J2EE Web service, this means leveraging the specific security mechanisms that are built into the application server.

Infrastructure-level security involves leveraging the middleware and OS infrastructure, as well as additional services to provide security. For example, you can make use of the authentication and authorization mechanisms of the application server that is hosting the Web service. Most J2EE application servers support the Java Authentication and Authorization Service (JAAS), which was added to the 1.4 version of the J2SE. So, it may be a natural fit to leverage this capability for defining the authorization capabilities of clients trying to access services hosted there.

Another example of infrastructure-level security is an authentication server or trust service that acts as an independent center for authentication and authorization. In this case both the client and Web service must be willing to trust the independent center.

Issues of Deployment
Many IT development teams are overburdened with the rapid changes in computing technology. Still, new services must be developed and deployed. These services need to be tested, installed, and managed. When problems occur, IT developers must be involved. Serious bugs can range from services crashing to performance degradation. In those cases, customers cannot get to required services and service-level agreements (SLA) may be broken.

Considering the cost of these deployment problems, it makes sense for developers to design for deployment. But, in the Web service world, what exactly does that mean?

The primary design issues for deployed Web services are control, availability, performance, security, and scalability. There may certainly be other issues for your Web service deployment, depending on the runtime environment and customer requirements. A key element in all of the deployment issues is the ability to bridge the gap between development and deployment. In fact, what is needed are mechanisms to place runtime (deployment) data back into the hands of developers, analysts, and business planners, so they can make better choices about applying scarce resources.

To better handle the issues of availability, performance, and scalability, runtime components and tools are needed to measure the condition of the Web service and capture that data. Furthermore, tools are needed that can help developers and analysts review the data. In some cases, additional instrumentation within the Web service can go a long way to providing a more accurate view of the runtime conditions. In future articles, you will find more detail on how to consider the management platform as part of your development environment.