Related Patterns

The following patterns relate to this chapter's discussion of the Service-Oriented Architecture pattern:

Architecture Adapter: The Architecture Adapter pattern separates the service-oriented architecture and the underlying service implementation architecture, allowing them to vary independently of each other.

Service Directory: This is the pattern used for publishing information about a service and the business that owns the service. This information is vital to the consumption and usage of your service or to selecting and consuming a service.

Faux Implementation: This chapter showed heavyweight and common ways to implement Web Services through a complete Web Service environment. Because Web Services enforce strict SOAP semantics and interfaces, you can choose instead to implement a lightweight Web Service that sits on a socket and reads data. Although you lose a lot of the robustness of your Web Service environment, you also lighten the burden on a client installation that needs to surface a Web Service.

Additional Reading

Web Service specification documents and related information: http://www.w3c.org/
The Jini technology: http://www.jini.org/
The Openwings technology, a service-oriented architecture based on Jini: http://www.openwings.org/

Chapter 4: Exploring the Architecture Adapter Pattern

Overview

The previous chapter explained the Web Service architecture in terms of the Service-Oriented Architecture pattern. Web Services implement the service- oriented architecture using Simple Object Access Protocol (SOAP) as a communication mechanism between services and Universal Description, Data, and Discovery (UDDI) as a directory implementation. Web Services Description Language (WSDL) describes the interface to a Web Service. Web Services do not support inheritance or polymorphism, and they do not delve into the service implementation techniques. On the other hand, Web Services build on such a small set of primitive types and concepts that you can use virtually any semi-modern programming language to build service implementations .

In the beginning days of Web Services, Java programmers coded socket listeners that received SOAP messages, parsed them, and called the proper code in the Java language. There are significant challenges to writing the code that converts between the Web Service implementation of a service-oriented architecture and the Java platform. Thankfully, tools, such as some of the tools included with Apache Axis, automate the creation of this code that converts data from the Web Service architecture to the Java architecture. At design time, it is easy to wrap up the responsibilities of this conversion from Web Services to Java in a simple design pattern: the Architecture Adapter pattern.

In this chapter, you will look at the architecture adapter as a generic pattern. You then dissect the architecture adapter in terms of service deployment in Apache Axis and service consumption from Java.

Facilitating Communication Between Architectures

Before digging too deeply into the architecture adapter, it is worth taking a few moments to discuss exactly what is the true nature of architecture. Once you have an understanding of some of the highlights of architecture, you can explore the issues surrounding Web Services and the Java platform.

What Is Architecture?

There are many definitions of architecture, and there are many interpretations of those definitions. The architecture of a system, in general, discusses its structure through a set of the following:

Architecture components that describe the core blocks of a system
Connectors that describe the mechanisms and expectations on communication paths between components
Task flows that illustrate how an application uses the components and connectors to fulfill a requirement

The architecture of a system becomes very complex very quickly, especially for an enterprise-class application. Architecture documents usually consist of 100 or more pages.

For this discussion, you need to focus on the content of the architecture with respect to the components and connectors. Typically, at the root of architecture are an architectural style and a variety of architecture patterns. Style is somewhat difficult to describe. When you think of an architectural style, you can compare it to physical building architecture. In the physical world, an architectural style dictates the dominant feel of a building. Typically, neighborhoods all contain the same architectural style. Unique architectural styles, such as Western Indian architecture, have elements that make it unique. For the Western Indian architectural style, one thinks of Islamic-style domes, ornate columns , and marble building blocks. The Taj Mahal in India is a perfect example.

Compare the Western Indian style with Frank Lloyd Wright's prairie architectural style, recognized as one of the first original American architectural styles. The Prairie style contains dominant horizontal lines; includes large, sweeping roofs; and weaves common Japanese architectural styles. The style attempts to connect the structure itself with the dominant Midwest prairie landscape.

Now, imagine placing the Taj Mahal next to a home built in the prairie style. The two architectures are fundamentally different, and only a master landscaper could make the transition from one structure to the other structure appear seamless and be functional. The transition contains elements of both architectural styles, yet blends its own techniques to help the transition between the two dominant styles. This transition landscaping is an architecture adapter.

Common elements of software architecture styles include the following:

The dominant communication style: Two common communication styles are message-based communication and call-return communication . The former is similar to today's message services, such as the Java Message Service (JMS), that provide loose coupling and that lend themselves well to asynchronous communications. Java's method call mechanism is an example of the call-return communication mechanism. In call-return communication, the thread of control originates with and returns to the method caller.

The dominant structuring technique for the functional implementation: Component and object-oriented styles are common in architecture. A component architectural style indicates a tendency toward the loose coupling of components and a high degree of cohesion within the components. This style is valuable when you want to create boundaries between components and allow programmers to easily restructure applications, acquire new units of functionality, and replace pieces of functionality. Object-oriented styles do not stress loose coupling as much. Often, if you want to take an object and use it in another application, you bring many other classes and dependencies with you. In a component style, the act of reusing functionality in an entirely different program is trivial.

No inherent problems exist with either type of architecture. The strengths and weaknesses balance out and often reflect preferences and experiences of the senior architecture staff. Once an architect promotes a particular architectural style, it permeates the entire application implementation.

Using Web Services and Java

Web Services and the Java platform have dramatically different architectural styles. The Web Service architecture, based on the service-oriented architecture, has its roots in the component-based architectural style, and it facilitates all of the dominant communication architectural styles: message-based and call- return. The Java platform is a classic embodiment of the object-oriented architecture style with a call-return communication style.

Java interacts with Web Services in two scenarios:

Java serves as the platform for writing a service implementation that turns into a Web Service at deployment time.
A Java program needs to use one or more Web Services.

The first scenario deals with how to represent programmatic function written with object-oriented techniques into an architecture that minimizes dependencies and does not stress or allow rich class hierarchies. The second scenario deals with representing loosely coupled and relatively flat structures in a rich, object-oriented environment. The communication mechanisms also differ between the two architectures. Either of the two scenarios requires a conversion from Java's call-return communication style to the Web Service dominant message-based communication style.

The challenges in combining the two architectural styles is not as difficult as putting a Prairie style home next to the Taj Mahal, but it is a significant challenge rife with minute details that take several iterations to get correct. As you architect and design your system, it is important that you isolate the component responsible for making the conversion between the architectures. The root motivation of the architecture adapter is to isolate this conversion process out of the primary business components and logic.