Related Topics: Java EE Journal, Apache Web Server Journal

J2EE Journal: Article

Applying Design Patterns to Web Services Architectures

Applying Design Patterns to Web Services Architectures

From the beginnings of the well-known "Gang of Four" design patterns book to more recent publications on J2EE design patterns, the software industry has always tried to find ways to design frameworks, ideas, and concepts that could be used repeatedly. With the introduction of Web services technologies, the need for design patterns remains the same.

The good news is that software architects today can apply many of the existing design patterns to Web services. Use of these patterns can greatly help the architect in building scalable, reliable, and robust Web services architectures.

This article takes a look at four of the more well-known design patterns and discusses how they can be applied to Web services architectures. The following design patterns are examined here:

  • Adapter: The Adapter pattern is often used to provide a different interface to an existing software component to make it more compatible to a client. This pattern can be used to wrap existing technologies, such as an HTML interface, to make it more compatible with SOAP.
  • Façade: The Façade pattern has been used frequently in J2EE to reduce the coupling between client and server. This same design approach can be used to create the right level of granularity in the Web services that are exposed to a client.
  • Proxy: The Proxy pattern is used to provide a placeholder for another object. Here, I show how the proxy pattern can be applied to a number of areas in Web services design, including client proxy generation, mobile processing, and Web services testing.
  • Controller: The Controller pattern has been used as a way to separate presentation from data. It is often used in a Model-View-Controller (MVC) architecture. This article shows how an architect can introduce Web services to an existing MVC-based design.

    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++ ( 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 (, 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:

  • Consistent interfaces: You are building consistent interfaces to your low-level application components, interfaces that more closely match the specific business requirements. As a result, you can shield the clients from having to know some of the back-end implementation details.
  • Centralized management: Use of a façade can also help facilitate, control, and manage your Web services environment. The façades will act as centralized access points, handling issues such as security, transactions, and management. Without these "umbrella" services, the individual components, or the client itself, would have to handle this.
  • Improved performance: This is one of the biggest benefits of this pattern. By reducing the number of client access points, you reduce the number of network calls required by the client. Data is bundled together, typically mapping to a specific business service needed by the client.

    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 ( 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:

  • Model: Contains the information, or data, required by the application
  • View: Manages the presentation for the application
  • Controller: Acts as an intermediary between the client and the data

    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.

    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.


  • Gamma, E.; Helm, R.; et al. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.
  • Alur, D.; Crupi, J.; et al. Core J2EE Patterns: Best Practices and Design Strategies. Sun Microsystems Press, 2001.
  • Mackinnon, T.; Freeman, S.; et al. "Endo-Testing: Unit Testing with Mock Objects.", 2000.
  • More Stories By Chris Peltz

    Chris Peltz is a senior architect within HP's
    Developer Resources Organization (, providing technical and architectural consulting to enterprise customers in the areas of J2EE, Web services, and
    application management.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.