While this is only a sampling of the many design patterns available today, it will hopefully give you a better sense of the value patterns can bring to Web services design and development. So, let's begin by taking a look at how the Adapter pattern can be used to incorporate incompatible technologies into a Web services architecture...

Managing Incompatible Interfaces
An organization will often look to existing software assets to exploit Web services technologies. In some cases, these existing applications utilize languages, protocols, or platforms that are not compatible with the target Web services platform. Managing these incompatible interfaces can be solved through the use of the Adapter pattern. The intent of this pattern is to "convert the interface of a class into another interface clients expect" (Design Patterns: Elements of Reusable Object-Oriented Software). It would typically be used to provide compatibility between multiple platforms or systems.

In the design of Web services architectures, the Adapter pattern can be used to expose existing components as Web services. It's important to remember that any given Web services platform will only support a set number of languages and protocols. This pattern can be used to wrap any incompatible interfaces with one the Web services platform understands. For example, Figure 1 illustrates how a C++ interface and the HTTP protocol can be utilized on a J2EE-based platform.

Two approaches can be taken to integrate a C++ component. If you have a large amount of code written in this language, you might want to invest in a C++-based Web services platform, such as the Systinet WASP Server for C++ (www.systinet.com). But, if you have standardized on a J2EE-based platform, you can typically only expose Java-based components, e.g., Enterprise JavaBeans, directly as Web services. One solution to this problem is to write a Java wrapper class that can interface with the C++ component over JNI or sockets.

Taking a look at the HTTP example, there might be a case in which a company has already exposed a software asset with HTML over HTTP. These Web-based applications might make excellent candidates for Web services. Web services and Web applications already share a common protocol - HTTP. The main difference is the use of HTML instead of XML. In this scenario, an Adapter could be written that invokes the appropriate URL Web pages, and repurposes the HTML content as XML. Listing 1 shows a simple example of how this could be done.

While this approach may work in some cases, you also have to remember that every HTTP-based application may not necessarily make a useful Web service. This is a similar design problem that existed with mobile application design. In the beginning, many developers were "transcoding" their existing Web site to quickly get their Web application available through a mobile device. But, many of these applications were not directly suitable for the mobile user.

Regardless of the design choices you make, the important thing to remember is that you don't have to start from scratch with Web services. You can leverage many of your existing software assets, and the Adapter pattern is one approach to help resolve integration issues. At the same time, you have to be very careful about trying to provide the quickest Web services solution. This often will not always meet the needs of the clients who have to use the service.

Creating Business-Level Web Services
To meet the needs of the business, you have to design the right level of granularity in your Web services. Choice of granularity can impact the usability, performance, and management of the services. A fine-grained approach typically maps each service to a low-level component. A coarse-grained approach exposes services that map to a particular business need.

We can illustrate the differences between these two approaches by looking at XMethods (www.xmethods.com), a popular Web services Web site. On this site, you can find services that deliver news, stock quotes, and text translation services. These services provide a specific function to the caller, but don't necessarily fulfill a business need. By combining these services (e.g., connecting the news feed service to the text translation service), we can begin to deliver more coarse-grained services that deliver additional business value.

The Façade pattern can often be applied to build coarse-grained services. This pattern has been most recently applied with J2EE through the Session Façade pattern (Core J2EE Patterns: Best Practices and Design Strategies). In J2EE, there are entity beans that typically model data and session beans that model business logic. It was common for developers to have clients talk directly to the entity beans, resulting in a number of fine-grained invocations to retrieve data. A façade could be written around the entity beans by creating more coarse-grained components represented by session beans.

This same design approach can be leveraged for Web services. Rather than providing a direct one-to-one mapping to every existing software component, you can encapsulate multiple components into higher-level, coarse-grained services. Figure 2 shows how the Façade pattern can be used in this regard. The individual components can be any software technology, including Java, EJBs, JMS, C++, and CORBA. They can even be other Web services that were already exposed with a WSDL interface. This is where Web services orchestration standards (BPEL4WS, WSCI, etc.) become important.

A number of key benefits are gained by using the Façade pattern with Web services:

As was mentioned in the previous section, it's very important to remember that not every existing component will make a good Web service for the consumer. In addition, use of object-based technologies such as EJBs and CORBA still serves a valuable purpose in an infrastructure. The value will come when you can identify how to best combine and aggregate these components to deliver real value to your customers, partners, and suppliers.

Isolating Complex Processing
The Proxy pattern is another well-known pattern that can be used to isolate or hide complex processing. The intent of the pattern is to "provide a surrogate or placeholder for another object" (Design Patterns: Elements of Reusable Object-Oriented Software). It can be applied to Web services to simplify the interaction between Web services components.

The most common application of this pattern is to hide the complexity required to construct SOAP messages. Almost every Web services platform available today uses some form of this pattern to shield the developer from this complexity. For example, Apache Axis (ws.apache.org) provides a WSDL2Java tool that will automatically generate client proxy code containing the SOAP processing logic. The following code snippet illustrates how a client can communicate with a service using an Axis-based client proxy.

public static void main(String[] args) {
WeatherService service = new WeatherServiceLocator();
Weather weather = service.getweather();
Forecast forecast = weather.getWeather(args[0]);
System.out.println("Forecast is " + forecast.getForecast());
}

The Proxy pattern can also be used to move complex processing from the client to a back-end service. This is often useful when dealing with lightweight clients, such as mobile devices. Instead of requiring the client to perform the processing, this work can be moved to a proxy server. The proxy server acts as an intermediary between the client and the Web service. The client can have a very thin communication layer, with the actual SOAP invocation being done by the proxy server. This approach can help reduce the number of network calls required by the client to communicate with the service.

Another function for a Proxy is to serve as a standardized interface for a collection of back-end services. For any given deployment, there might be a handful of services available on a server. Rather than giving each service its own entry point, a proxy server can be developed that consolidates these messages into a standardized interface. Again, the benefit is simplification of the communication model required on the client side.

This notion of standardized interfaces can be applied in the Web services testing domain. During the testing phase, your components may need to communicate with third-party services that are outside your control. A common scenario is an e-commerce-based service that includes a payment-processing step. As part of this process, the consumer's credit card may be charged for a given purchase. However, during the testing of the service, the developer wouldn't want to interface with the real payment system. Instead, they would typically write a "dummy" service that would be functionally equivalent to the original.

To manage these external dependencies, a developer can use a technique called mock objects, an Extreme Programming (XP) approach to unit testing ("Endo-Testing: Unit Testing with Mock Objects"). The basic idea is that you create a mock object that takes the place of the actual object. The mock object will look and act just like the original component. In our example, a mock object could fulfill the needs of a credit card service without requiring the developer to invoke the real system during testing.

Figure 3 illustrates how mock objects could be used with Web services testing. In this approach, the Proxy pattern is used to encapsulate the SOAP messaging logic. The Proxy is further enhanced through the use of an XML configuration file. The purpose of this file is to indicate the host and port number where the Web service is located. If the original Web service and the mock Web service conform to the same Web service interface (WSDL), the only change that has to be made is in this configuration file. A developer could quickly update the configuration file to indicate which version of the service to use.

Leveraging Existing Frameworks
The previous approach of using the Proxy pattern to encapsulate complex processing logic provides another important benefit - leverage. In fact, patterns exist to provide reusable concepts or ideas that can be applied to solve new programming problems. As a Web services architect, you need the ability to quickly recognize where and how you can leverage your existing components, systems, and infrastructures. One important area to focus on is the use of existing frameworks that can be applied to Web services architectures.

One of the better-known architectural frameworks is the Model-View-Controller (MVC) architecture. Originally a design applied to the Smalltalk language, it has been frequently used in the design of Web-based architectures. The general design approach around MVC is to clearly separate the key components of the architecture. These components are:

If architected correctly, an MVC approach will allow an organization to expose multiple interfaces to the same set of data. One application of this has been in J2EE architectures, where Enterprise JavaBeans (EJBs) are the model, JSP and HTML pages are the view, and servlets are used to manage the navigation between Web pages. With this separation, a developer can easily plug in new presentation modules that support different device types (e.g., HTML, WML, etc.).

So, how can Web services leverage the MVC architecture? If you think about Web services as just another view on the model, a Web services "presentation" can easily be plugged into an existing MVC architecture. Rather than sending HTML or WML back to the client application, the Web services view would construct XML or SOAP messages through interactions with the Controller (see Figure 4).

This solution can be somewhat hard to understand because a Web service doesn't really have a presentation - it's really more of a model in MVC. But, if you think about it, Web services can be looked at as another view (or interface) on an existing information model. In this case, the view is represented as SOAP. Obviously, if you have an existing architecture that generates XML from the controller, it is even easier to extend your application to support Web services. The architecture will still have to design a presentation layer that can present the SOAP-based information to the consumer (e.g., through a Web-based portal).

The overall intent here is to illustrate how you can easily leverage your existing architecture to support Web services. While we have just talked about MVC in this example, similar approaches can be applied to other software frameworks you might be using. This approach might make sense if you have an existing set of components you want to expose as Web services, but it might not be appropriate for new Web services projects being designed from the ground up.

Conclusion
If you are beginning to explore the use of Web services, it's important to remember that it is not a revolutionary new approach. Web services build on many of the existing distributed technologies and paradigms. Using Web services does not necessarily mean that you have to throw away all of your existing components and start from scratch. In fact, you can discover opportunities to leverage many of your existing software assets and expose them with Web services interfaces.

The right amount of design and analysis should be performed to determine what would make a good Web service. Not every existing object or API can map directly to a Web service, and it's important not to fall into the trap of delivering the quickest solution that might be offered by the Web services platform. Choosing the right level of granularity can help deliver usable, well-defined, and scalable Web services to your customers, suppliers, and partners. These services can be combined and aggregated to provide even more business value.

Value can also be delivered by leveraging many of the existing design patterns that have been developed for object-oriented systems. This article showed you how a few well-known patterns can be applied to Web services architectures. With these specific patterns, a Web services design can simplify the development effort required to take a set of existing software assets and expose them as business-level Web services.

References