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.