Understanding Web Service Patterns

Patterns apply to Web Services in several ways. First, the Web Service paradigm builds on a variety of patterns. Second, Web Service implementations can benefit from existing patterns. Finally, some patterns that seemed incidental in an object-oriented paradigm are useful, educational, and more important in a Web Service paradigm than in an object-oriented paradigm.

Learning About Web Services

You will start your look at patterns with three that help illustrate Web Services. The following patterns look at how Web Services implement the service-oriented architecture, how service implementations interact with the Web Service environment, and how to locate and use Web Services:

Service-Oriented Architecture: The Web Services environment is an architecture implementation known as the service-oriented architecture . There are several different implementations of the service-oriented architecture with Web Services having the most penetration in the industry to date. Implementations of service-oriented architectures stress two attributes: implementation transparency and location transparency. Implementation transparency requires a common system structure that applies equally to all possible underlying service implementations and a neutral mechanism for describing services. Location transparency requires the use of agnostic interfaces. You will dissect the Service-Oriented Architecture pattern to learn about the foundations of Web Services.

Architecture Adapter: This pattern expands on the GoF Adapter pattern. Although the GoF Adapter pattern resides in object-oriented programming as a way to adapt an exposed interface from a component to an expected dependent interface from another component, the Architectural Adapter pattern is responsible for allowing two completely separate architectures to interoperate .

Service Directory: In statically bound systems, and even in many dynamic systems, companies assume that their choices for the purchaser of software are the right choices. The Web Service paradigm challenges this tradition. Instead, by creating detailed metadata about a service, a service user should be able to locate your service and use it without application modification. The metadata in a service-oriented architecture includes its interface, location for binding, mechanism for communication, and information about the business that created the service. This pattern goes into depth on the Service Directory patterns that are inherent in the leading service architectures and that you will encounter in Web Services.

With these patterns and the sample implementations that go along with the patterns, you should have a good understanding of the Web Service environment. Further, the examples and samples in the text use the Apache Axis Web Service environment, so you will also have a good understanding of this environment after you finish the patterns.

Adapting to Web Services

The next four patterns walk through a typical progression of thought refinement as object-oriented programmers adapt to Web Services. These patterns illustrate various business concepts with the sample implementations showing how to deploy them as Web Services. These patterns are examples of patterns taken for granted in an object-oriented environment but that become interesting in a Web Service environment. First, the patterns illustrate a typical learning curve in Web Services, and the patterns give insight into the Web Service environment. Second, the patterns give insight as to how business concepts embody themselves in Web Services:

Business Object: This pattern discusses the typical structure and contents of a single business object. Although the frequency that you will use a single business object for deployment is low, there are substantial lessons you can learn from the exercise of deploying a business object. As with the first three patterns, this pattern is heavy in discussion around the Web Service environment and lessons you can learn from deploying relatively simple objects.

Business Object Collection: In business, you will rarely find business objects that are not collected. Like the business object itself, handling collections with Web Services yields substantial instructional substance as you learn more about the Web Service environment.

Business Process (Composition): Business systems today revolve more around business processes than around supporting business objects. A business process does not necessarily correlate to a single business object but is more abstract in nature. This pattern looks at business processes and lays a general framework for exposing them as Web Services. The business process is also a form of composition. To achieve a business process, multiple business objects and, often, other business processes and activities must run.

Asynchronous Business Process: A world where all business processes are synchronous would be a fine world to live in for programmers. Unfortunately, most important business processes are not synchronous. Even the most basic business processes, such as fulfilling a book order, run into asynchronous complexities. In introducing the Asynchronous Business Process pattern, you will find many similarities to the relationship between business objects and business object collections.

Determining When Changes Occur

These patterns are most interesting in what they teach you about the Web Service environment. The next three patterns introduce practical mechanisms to determine when changes occur to a Web Service. The first is a commonly used pattern in business applications when you deal with services that did not predict you would care to be notified when a change occurs to the internal state of a Web Service. The latter two patterns implement existing patterns within the Web Service paradigm to illustrate mechanisms that can aid clients in determining when data changes occur within your Web Service:

Event Monitor: Often, the burden of determining when events occur in a service lies with the client. There are a variety of reasons for this, such as the service not having a reasonable publish/subscribe interface or the client desiring control of the event determination. This is a common, and relatively simple, design pattern to implement that has well- established roots throughout software history.

Observer: Rather than leaving a client to determine when data changed on a server, it is often more efficient to have the server component tell interested clients when data changes. This is especially true when the server component has a low frequency of updates compared to the frequency that clients will want to check. The Observer pattern formalizes the relationship between one or more clients and a Web Service that contains interesting state. The Web Service delivers events to interested clients when an interesting change occurs. The Gang of Four documented the Observer pattern. This implementation is similar to the original documentation of the pattern, with necessary information about Web Services.

Publish/Subscribe: The Publish/Subscribe pattern [Buschmann] is a heavily used pattern in EAI software as well as in many distributed programming paradigms . The Publish/Subscribe pattern is interesting in the context of the definition of Web Services as application components . Using a topic-based mechanism common in very loosely coupled architectures, you create a stand-alone event service that is, in effect, an application component. The event service forwards published events to subscribers without awareness of the application components that use the event service.

The Observer and Publish/Subscribe patterns introduce an interesting issue. The subscriber to Web Service events must, itself, be a Web Service. Web Services are, by definition, application components. Instead of an application component, event subscribers are a part of another application that requires up-to-date information on changes to a target Web Service. In other words, subscribers by their nature are not stand-alone application components.

Refining the Structure of Your Web Services

The next two patterns address this issue in radically different ways, one by embracing the Web Service paradigm and the other by pretending to embrace the Web Service paradigm:

Physical Tiers: Throughout the book and the sample implementations in the chapters, you will use a simple Java-based deployment mechanism built into Apache Axis. Therefore, your components live entirely within the process space that Apache Axis uses. This is not an optimal model for enterprise applications. The model discourages runtime reuse and creates a larger footprint than is necessary. Further, the event patterns produced some interesting challenges for a Web Service environment. A client interested in events from a Web Service often exists in its own process. This pattern discusses Web Service implementations that must, and often should, communicate to other processes for their implementation behavior.

Faux Implementation: One of the most fascinating pieces of the Internet is the ability of someone or something to be able to pretend to be something they are not and actually get away with it. As long as an interface and the behavior of a service implementation is what others expect, there is no way to tell what drives the behavior of the service implementation. The Observer and Publish/Subscribe patterns require clients to implement a Web Service to receive event publications . The Faux Implementation pattern shows that as long as the behavior fulfills the contract, there is no reason you have to implement a service with traditional mechanisms.

Creating Flexibility in Your Web Services

The final three patterns give some additional mechanisms to bring flexibility to the Web Service paradigm. The first brings flexibility to clients who want to leverage a Web Service that exhibits a particular behavior. The last two provide mechanisms to streamline client interactions with Web Services:

Service Factory: Class factories are common in Java programming. A class factory gives a mechanism to bind to a class implementation at runtime rather than compile time. The same capability is possible with service implementations. For example, there is no reason that a company must use a single package shipper for all shipments. Instead, the service factory illustrates how your application can determine what service to use at runtime.

Data Transfer Object: The Data Transfer Object pattern originated with Java 2 Enterprise Edition (J2EE) patterns. When you move from a single process application to a distributed application, calls between participants in the distributed architecture become more expensive in terms of performance. By giving clients mechanisms to get groups of commonly accessed data in single operations, you can streamline clients and lower the number of accesses necessary to your Web Service.

Partial Population: The Data Transfer Object pattern passes fully populated data structures between programs. This is a great paradigm but creates a proliferation of data structures and relegates the service implementation to determining what the most likely groups of accessed data will be. Partial population takes a different approach to data transfers; it allows clients to tell the server what parts of a data structure to populate. In this way, you can lighten the burden on the communication mechanism as well as the query in the server object. This technique is especially useful for services that contain complex, nested data structures (not something you will typically find in a Web Service environment).

Overall, the 15 previous patterns run the gamut from patterns that help understand the Web Service environment to patterns that optimize Web Service implementations. The organization of the patterns in the book starts with patterns to help understand Web Services and moves slowly to patterns that apply to relatively complex service implementations.

Using the Sample Code

This book's source code and working samples are available in the Downloads section of the Apress Web site (http://www.apress.com/book/download.html). This source is as presented in the text ”potential bugs and all. (Refer to Appendix A for instructions on how to install and run the code samples.)

A working copy of the P.T. Monday application presented in this book is available in the Web Service Design Patterns in Java project on SourceForge(http:// sourceforge .net/projects/websvcdsnptn/). This project is active, and the source contains bug fixes and evolutionary changes to the patterns and classes presented in the text. You are also welcome to join the project and contribute to the application in this book. You could build a user interface to it, contribute more robust Java Data Objects (JDO) code, or test new Web Service design patterns and specifications.

Finally, I am always available for feedback at [e-mail]. I try to get to all of my email and am relatively humble about the code I produce and writing I do, so I will be glad to discuss a pattern or two with you.