Blog on Technologies like BPM,Web Services, Android, J2EE: Different Design Patterns for Web Services-An Overview

Web Services provide an important building block for integrating disparate computing platforms and, indirectly, provide a mechanism to integrate their global value chains. You can build Web Services after the system was originally deployed, making them similar in many ways to today's EAI software, but you can also build them along with new software as the open Application Programming Interface (API) to the application.

Advantages of using Web Services
Using Web Services , you can build an API which islanguage- neutral and platform-neutral format, programmers can access data from one system and quickly move it to the other through the Web Service. There are several strengths to this approach:

Programmers can write the data-transfer programs in any language or platform with which they are comfortable.
The source and target systems can control the requests and updates of data in such a way that they do not interfere with a running system.

Consider the number of ways that a simple problem, such as notifying interested parties of a change to an object's state, are solved with a platform such as Java 2 Standard Edition. Some developers may use an intermediate file to track changes, with interested parties reading the file to find out when and how an object changed. Other developers may construct a point-to-point notification system, or even a set of one-to-many Publish/Subscribe patterns. Some developers may have one type of naming convention for the adding and removing of listeners; other developers may not have any naming convention for the same operations-these are some of the areas where Web Services can be highly useful

Using Design Patterns
Patterns can be applied to any portion of the software cycle which usually involve gathering requirements, creating the architecture, designing the software, and implementing it.Thousands of software design patterns document the common problems encountered by software designers and generic solutions for those problems. For example, an architect may give a system structure that identifies a point in the system where an object change drives listeners to make changes in their own state, or the change kicks off a business process. In these cases, a designer can look and determine that the Publish/Subscribe or the Observer pattern can fulfill the requirements and constraints an architect put on the design. Once identification of patterns is complete, the generic structure given in a pattern drives the design of the particular system structure.

Web Services Design Patterns
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.
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.
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
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.
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
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).