Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley Signature Series (Fowler))

by Hohpe Gregor

Two mental artifacts provide the highest levels of abstraction in software architecture today: programming orientations, which include object-oriented programming, service-oriented programming, generative programming, and the like; and pattern languages, such as those documented in this book. If a particular orientation or design pattern proves useful, and if its context proves to recur frequently, the tactics and strategies used to implement the pattern often become very similar. Pattern solutions on multiple platforms, products, and applications end up owning very few differences—but those few differences are often frustrating growth inhibitors, typically semantic in nature, and produce interoperability that hinders sophistication of scale. To extend the reach of applications and the patterns on which they’re based, such differences tend to be eliminated from products and platforms through formally agreed-upon standards.

When a pattern’s tactic or implementation strategy is standardized, the pattern does not wane in usefulness, replaced by that standard; instead, quite the opposite occurs. Like rings within a tree trunk, a strong pattern grows upon itself to ever-broader levels of applicability, creating and then applying itself in broader instances of context. This growth in scale occurs because separate instances of a pattern’s implementation become interoperable with one another.

The usefulness of design patterns and programming orientation for developing sophisticated systems is proportional to the application developer’s ability to depend upon common, interoperable implementation strategies and tactics.

By exercising the design patterns in this book, you may be contributing to the development of a standard even if you don’t directly contribute to a specification working group. The organizations and consortiums that oversee specification working groups don’t always do a great job of recognizing and assimilating implementation approaches, but that’s the intention.

Standards are officially born when an inventor or group of inventors makes a formal proposal to a standards body. Usually, this requires membership in the standards body. Each standards body enforces its own process for shaping proposals into a standard, and all members are legally bound to those rules. The processes generally involve the forming of a working group or committee to further develop the specification under the oversight and eventual approval of the organization’s management. Intellectual property rights and licensing policies are often hot topics in these organizations and can vary between standards bodies and even between working groups within the standards bodies.

Aristotle also mischievously posed one of the most influential rhetorical questions ever to trouble software architecture: Is the world predominantly a series of processes, or is it a series of objects? Messaging standards reply with an answer worthy of a Zen disciple: yes. The world is a series of objects whose most important characteristics are usually the processes through which they engage with and relate to other objects. It is often an object’s behaviors related to other objects rather than its own internal composition that turn out to be most significant. In the realm of Web services and enterprise integration, this object/process hybrid view is referred to as the business process component. The business process component unites a series of services into a logical unit that interacts with other such units via messaging to achieve highly scalable, resilient flows of logic and data. The coalescence of process, object, and interaction patterns into a business process component is the future of messaging as seen by many Web services vendors and standards bodies.

Taking a nontechnical example, a human can drive a car, and both the human and the car are separate, highly-complex systems; the process view of the human and car, however, sees them as a single component defined by their interactions with one another and does not focus on the composition of either the human or the car separate from the interaction between them. Further, the process component view describes the interactions of that single component with others on the road, again without interest in the internal composition of other automobiles or drivers.

Web services and other message destinations are building blocks used to compose larger compositions whose interactions follow messaging patterns—both the composition of the process component and the linking of multiple process components into an application follow messaging patterns. Business process standards address the correlation of messages between Web services in order to create flows of execution and include behaviors related to errors, transactions, and data exchange.

A popular emerging standard for defining business process components and their interactions is Business Process Execution Language for Web Services (BPEL4WS).

The design of BPEL calls for linkages of Web services, named partners, to put XML messages into and out of message stores, called containers, according to rules called activities. A logical set of service linkages, message containers, and activities comprise a single business process component.

After declaring the relationships between services, the developer uses BPEL to create containers to hold the messages that the services use as input and output. Containers are very much like a Datatype Channel (111) for the message types defined in WSDL. Depending on the underlying container implementation, a container could also be considered from the perspective of the Shared Database (47) integration style, but with added encapsulation and built-in collaboration semantics; a container is a shared data repository used by separate services.

A business activity is typically a long-lived process that may consist of a number of atomic transactions. A global rollback is usually not desirable in the event of a single failure condition in a business activity; instead, a failure of one atomic transaction within a business activity should often trigger another set of service invocations and message exchanges. These exchanges might include compensation techniques to recover from the error in a way that preserves part of the history of the business activity.

At their best, standards extend the reach of design patterns by ensuring that different implementations of the same pattern are interoperable. Many efforts are underway to extend messaging patterns through Web services standards; many of these standards focus on the composition and behavior of workflow components called business process components.

As standards mature, architects are wise to consider how their use might extend enterprise integration solutions to broader, less risky, less costly, and more powerful levels of sophistication.