(By Sean Neville)
As data flows across system and domain boundaries through messaging conduits, and as developers and architects become more proficient in the patterns that govern messaging systems, new standards and products will emerge to extend the tactical reach of those patterns. Over time, patterns tend to strengthen but otherwise change little if at all; but their implementation strategies often evolve rapidly to allow developers to apply them to much broader scales of sophistication. The fundamental Message Pattern, for example, finds its reach and applicability extended as implementation artifacts grow from EDI to proprietary MOM to open XML and SOAP-based web services to global BPEL and beyond.
This chapter takes a look at the future of message-based enterprise integration in terms of the emerging standards that application developers will encounter in the mid 00's. Many of these standards are not currently in common use, but are coalescing with broad industry support, and are likely to serve as the foundation of integration pattern implementations particularly in service-oriented architectures. Most of them extend nascent web services technologies to support the types of patterns presented in this book. We'll take a look at why these standards are important in relation to design patterns, which organizations are creating them and how they're going about it, and offer a brief summary of the technical solutions for business process integration that a few of the most promising web services and Java standards aim to provide.
The Relationship between Standards and Design Patterns
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 that 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. Taking a typical message-oriented J2EE application as an example: A pattern such as Pipes and Filters exists at many levels -- within the application as designed by the developer, but also within the server product used to host the application, within the containers and services within that server, within the filters and components that compose the messaging subsystems, and so forth in recursive fashion.
Emerging messaging and web service standards will serve to strengthen the patterns in this book by extending the reach of the developers who employ them. Standards such as Business Process Execution Language (BPEL) and Web Services Reliability (WS-Reliability) propagate the scope of these patterns beyond bits, beyond languages, beyond products, and outward into increasingly useful compositions in the human- and system-centric circles of use cases and requirements. Application developers can stop using patterns such as Correlation Identifier to match raw message replies to their senders, and can start using that same pattern to correlate process components that consist of multiple asynchronous message senders and receivers. Without the benefit of messaging standards, a Java developer may implement Message Router at the code level to inspect the contents of individual XML messages in order to programmatically forward the message to a particular service or filter. Emerging workflow and choreography standards will allow that same developer to apply his knowledge of the Message Router pattern at a higher level of abstraction to route workflow among process compositions, where the tactical artifacts are business process components rather than raw sections of XML documents. In other words, application developers can stop spending precious time linking protocols and set about the business of linking business processes and services across domain boundaries.
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. Today, strategies for working with a messaging pattern in J2EE may mean use of JMS, JCA, or JAX-RPC; tomorrow, the strategies used by application developers may involve use of model-driven technology, schema-based scripts, aspects or intentions -- and any such shifts in implementation tactics only increase the significance of the patterns, if both the pattern's contextual definition and relevant standards are appropriately embraced. Standards provide the best way we currently know to enforce these commonalities to extend the software architect's mastery of design patterns.
Survey of Standards Processes and Organizations
Contrary to popular cynicism, standards are not intended to be developed in a vendor vacuum isolated from practical application development. They are intended to unify and improve the implementation approaches discovered and developed by application developers. 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 standard bodies and even between working groups within the standards bodies.
Here's a look at the major standards organizations involved in creating the emerging messaging and web service standards:
W3C (http://www.w3c.org): The World Wide Web Consortium develops many of the basic web technologies that are in turn used as building blocks by other standards organizations. It is managed by an international team of researchers and engineers, and consists of a large group of member vendors, content providers, governments, research laboratories, and other entities. The W3C makes use of an open, collaborative review process in Working Groups and subsequently in public that results in lengthy but generally high-quality iterations. Technologies created through the W3C are usually unencumbered by member claims to intellectual property rights. W3C technologies include SOAP and WSDL, as well as all of the core XML specifications. The W3C Choreography Working Group will likely resolve conflicting business process specifications and provide the definitive basis for integration using web services.
OASIS (http://www.oasis-open.org): One of several organizations that builds on W3C technologies is the Organization for the Advancement of Structured Information Standards, or OASIS. Chartered to foster guidelines for SGML development, this non-profit consortium of vendors now focuses on driving the adoption of global e-business standards. OASIS technical committees are producing many emerging web service standards, such as ebXML and WS-Reliability. OASIS also hosts the xml.org portal.
WS-I (http://www.ws-i.org): The Web Services Interoperability Organization (WS-I) aims to ensure that web service technologies and standards are suitable for enabling business collaborations in a generic, interoperable manner. The organization promotes web service protocols and practices that can apply across multiple systems, platforms, and languages. A key tactic in achieving these goals is the WS-I Basic Profile, which specifies the collection of web service standards along with their version numbers -- in the first profile these are XML Schema 1.0, SOAP 1.1, WSDL 1.1, and UDDI 1.0 -- as well as conventions governing how they should be used together. Thus the WS-I intends to play a unifying role in ensuring that various vendors involved in web services development can work together in a way that benefits application developers. It was founded and is managed by the leading web service vendor companies, including Microsoft, IBM, BEA Systems, Oracle, and others.
JCP (http://www.jcp.org): The Java Community Process (JCP) produces Java language bindings and J2EE APIs for technologies such as the web services and messaging standards developed by other organizations. Led by Sun Microsystems, the JCP has not historically been an open process; although it makes use of Expert Groups and a proposal process similar to that of other standards organizations, intellectual property rights are typically retained by Sun and licensed to the Java and J2EE platform vendors for a fee. Most of the JSR Expert Groups are also led by Sun engineers. While lacking the openness of other organizations, the JCP has, on the other hand, benefited from the focus that Sun has provided somewhat unhindered by external agendas.
Ad Hoc Vendor Consortiums: In the race to establish control over portions of the emerging web services technologies, particularly for the purposes of enterprise integration, traditional competitors such as IBM and Microsoft have in some cases united to publish would-be standards without submitting those works to any standards body. Many of the WS-* specifications fall into this bucket. Often standards developed through vendor consortiums end up as submissions to standards organizations; the promising Business Process Execution Language (BPEL), for example, spent its early life as a creation of Microsoft and IBM before being submitted to OASIS. Interest in retaining intellectual property rights seems to be the catalyst for working in ad hoc fashion. These specifications achieve interoperability without the licensing openness, which is often satisfactory for application developers integrating platforms as popular as those produced by Microsoft and IBM, though whether these works are truly "open standards" is understandably the subject of much debate.
Business Process Components and Intra-Web Service Messaging
Not content merely to influence object-oriented programming, structural decomposition, and domain modeling, 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 turns 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.
The process component is a macro view of a set of services that is particularly relevant to enterprise integration. Taking a non-technical example: A man can drive a car, and both the man and the car are separate highly-complex systems; the process view of the man 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 man or the car separate from the interaction between them. Further, the process component view goes on to describe the interactions of that single component with others on the road, again without interest in the internal composition of other automobiles or drivers. This is not the same as simply presenting an external interface, as it also includes the rules that govern behaviors between usages of the interfaces.
The business process component as emerging in standards is a single component that internally consists of a set of web services and a definition for how messages flow into and out of them. 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 more technical business example is illustrated below, in which the processing of a purchase order is handled by a component that consists of a number of service operations.
Figure 1: The Business Process Component exposing a single destination endpoint on behalf of multiple internally choreographed web services.
The example includes the following characteristics and activities:
- Each operation in the Process Purchase Order component is an operation available on the portType of a web service, and the various web services which expose the operations may reside on remote hosts in partner production facilities.
- When a purchase order is received, four operations are invoked concurrently; but some of the operations have dependencies that must be synchronously resolved (the dashed arrows in the illustration indicate dependencies).
- Two specific dependencies show that the shipping agreement and insurance costs are needed in order to calculate the final cost, and that a binding insurance agreement must be received before the manufacturer will commit resources to a production schedule.
- Once all service operations have asynchronously completed, the purchase order has been processed. Rather than requiring the messaging client to interact with all of these services individually and manage the dependencies between them -- that is, rather than requiring the client to create a Process Manager implementation -- the process component exposes a single network endpoint on behalf of all the services, and manages all of the messaging and dependencies between services internally, simplifying the client's tasks.
- The Purchase Order process component is in turn linked to another business process component, the Process Invoice Component.
Four standards initiatives warrant a good look in the business process component and integration space: the ebXML initiative, two competing proposals called Business Process Execution Language and Web Services Choreography Interface, and a collection of individual specifications joined through the "WS-" prefix that address pieces of the same functionality in slightly narrower, more specific fashion.
ebXML and the Electronic Business Messaging Service (ebMS)
Even before the explosive popularity of SOAP and WSDL, many bright thinkers working on business collaboration and B2B integration projects saw a need to develop an open, secure, and interoperable infrastructure for exchanging business information using XML messaging. The several specifications and initiatives developed under the Electronic Business using eXtensible Markup Language (ebXML) banner address that need, and as technologies such as SOAP have become popular, ebXML has grown to include and build upon them. The ebXML initiatives are jointly managed through OASIS and the United Nations UN/CEFACT organization. UN/CEFACT is the global group that brought the Electronic Data Interchange (EDI) standard into the world, and ebXML in many ways represents the next logical stage in the evolution of EDI.
Several specifications comprise ebXML, covering topics such as how enterprises advertise their business process and search for those of potential partners, how partners agree upon and initiate communication, the use of registries to facilitate the discovery and initialization of business conversations, and the behavior of the messaging infrastructure required to facilitate the conversations. This last element in particular has garnered a great deal of attention, and while it leverages the other ebXML specifications, it can also be considered separately, which is useful for the purposes of focusing on messaging patterns.
The Electronic Business Messaging Service (ebMS) is not quite as "emerging" as some of the other standards mentioned here, as it has already achieved significant success as a means of integrating business processes, augmenting EDI systems, and extending SOAP to provide reliability and security for web services. Developed by OASIS over a three-year period beginning in 1999, ebMS is also proving influential in the development of other business process standards.
The goal of ebMS is to ease the exchange of business messages within an XML framework, but that framework includes the use of message payloads that are not necessarily XML -- the payload can take any form, including traditional EDI formats as well as binary formats. Thus ebMS can encapsulate existing messaging systems and serve as a flexible bridging technology, containing a set of Message Translator implementations, which is particularly useful in scaling integration to extranets and to B2B communication between business partners. An important source of use cases for ebMS is the linkage of proprietary MOM systems across separate enterprises, and considerable testing between vendors and developers has occurred to verify this interoperability. Critical to ebMS is that it supports legacy EDI systems, allowing enterprises to leverage longstanding investments in EDI while compensating for EDI's shortcomings by incorporating features of the web and XML.
While on the one hand ebMS is a compatible iteration of EDI, on the other hand it is also a sophisticated improvement of standard SOAP-based services. The XML transmissions used in an ebMS system consist of SOAP envelopes that include ebMS-specific SOAP Headers to record unique message identifiers, timestamps, digital signatures, and a manifest which provides metadata about the message's payload. Thus ebMS uses the SOAP Header mechanism to implement the Introduction to Message Routing patterns and many of the Introduction to Messaging Endpoints patterns, such as Idempotent Receiver and others related to guaranteed sequential delivery.
ebMS transports its payloads by using the SOAP with Attachments standard to attach the payload to the SOAP envelope in much the same way that attachments are added to email messages. These payloads, again, have no formatting restrictions placed upon them: a message's payload may be XML data, binary data, link-based references to external data, etc. Further, each payload may have its own digital signature, and additional authentication and authorization may be provided by ebMS implementers.
Figure 2: An ebMS message is composed as SOAP messages with attachments.
Asynchronous message delivery is the default, but synchronous delivery is also possible through ebMS. The error-handling mechanism is also quite sophisticated, and depending on the implementation can provide SOAP Fault information along with payload-specific error messages.
To provide reliability, the critical element of an ebMS implementation -- called ebXML Message Service Handlers -- persist messages at the sending end of a conversation. Developers can provide semantic declarations such as "once-and-only-once" and "store-and-forward" for individual messages or for groups of messages. ebMS specifies services to manage sequential delivery and management as well; this last service is implemented through a Message Status Service that represents a Control Bus. It provides the ability to request the status of a message previously sent into the ebMS system, which underneath the covers operates through an implementation of Message History and related patterns.
More information on ebXML can be found here: http://www.ebxml.org/
The ebMS specification can be found here: http://www.ebxml.org/specs/ebMS2.pdf
Business Process Execution Language for Web Services (BPEL4WS)
A popular emerging standard for defining business process components and their interactions is Business Process Execution Language for Web Services (BPEL4WS). The name is often pronounced "bee-pel" or even worse -- "bee-pel for wuss." This standard represents the merging of two competing proposals from IBM and from Microsoft. IBM's Web Services Flow Language (WSFL) specified a means of creating and linking service endpoints to choreograph web service workflows, while Microsoft's XLANG provided a syntax and development model for creating workflow components as realized in the Microsoft BizTalk server product. BPEL4WS provides a bit of both: It includes a syntax for composing processes from existing services, and for describing process interfaces for the purpose of linking them together in larger workflows. It was created by an ad hoc collaboration between BEA Systems, IBM, and Microsoft, and has been submitted to OASIS.
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. The BPEL specification essentially defines a Process Manager that creates Routing Slip, Durable Subscriber, Datatype Channel, and more based on a declarative XML syntax. Developers declare behaviors in XML (perhaps with the aid of visual tools) in order to craft business process components such as the one in Figure 1 above, and do not need to programmatically create the messaging between services.
Web Service Description Language (WSDL) documents are very important to BPEL, as the BPEL component will consist of and manage multiple web services based on the services' WSDL documents. The business process instantiates and routes messages to the service endpoints declared within these services' WSDL documents using messages that are formatted according to the WSDL message declarations. The BPEL syntax links the portType and operations of a set of web services by importing their WSDL files and declaring what sequences to use to receive the service messages, where to send them, when and how to reply, when to invoke other web services, and so forth.
In order to establish the linkages between services, the application developer imports the WSDL of the web services comprising the component and defines the partner relationships between them using the BPEL serviceLinkType element. This element refers to the portTypes of the web services involved in a flow and the partner roles that they play in relation to the process; the developer is then able to refer to these linkages and partner roles when declaring how messages should flow into and out of them.
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 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 integration style, but with added encapsulation and built-in collaboration semantics; a container is a shared data repository used by separate services. In addition to connecting containers to services through the BPEL elements, a container's contents can be accessed directly via XPath extensions.
A BPEL component itself exposes its own input and output points as a single interface, and it does so in the same form that its internal web services use: through WSDL. It should be evident, however, that the WSDL of a business process component is slightly different from a web service WSDL document in that the business process WSDL's portTypes define entry points into and out of that single process, and not separate pieces of logic implemented as methods in a service interface.
The behavior of a BPEL component is declared as a set of actions. In any one specific action, a business processes can send messages to a service (in this case the web service is called an invoked partner), receive messages from a service (in this case the service is called a client partner), reply to a message sent by a client partner, determine whether it should send or receive messages based on some logical rule, wait for a scheduled period of time, report an error, copy a message from one place to another, or do nothing at all.
The BPEL XML grammar reflects each these basic actions. A developer uses the <invoke> element to send messages to an invoked partner, and uses <receive> and <reply> to receive and reply to a client partner. Elements such as <flow> and <pick> fork logic into parallel and event-based channels of execution. The <throw> element facilitates error reporting, while the <wait>, <empty> and <terminate> elements pause or halt execution. Elements to structure activities include <while>, <sequence> and <pick>, and conditionals in BPEL are declared using XPath statements.
Once a developer has created the XML source file that defines the services that will compose a business process, declares the message containers that the services will use, and declares the sequence of operations involved in the message exchange, he is ready to deploy the business process component. This is where the runtime aspects of BPEL implementations come into play.
In addition to acting as declarations of service relationships and message flow, BPEL descriptions are also executables file that can be fed into a BPEL4WS engine. When this happens, the engine interprets the file and sets up a series of messaging constructs for the application developer that connects the web services that are part of the business process. As a Process Manager implementation, the BPEL4WS runtime is the governing entity that manages and correlates the flow of messages between services. The BPEL4WS engine accepts all of the necessary documents and dynamically generates and manages the messaging infrastructure.
The BPEL specification can be found here: http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/
Web Service Choreography Interface (WSCI)
The Web Service Choreography Interface (often pronounced "whiskey") addresses the same problem domain tackled by BPEL. The two were competing specifications initially backed by competing vendor alliances (with the exception of BEA, which appears to be hedging bets by contributing to both specifications). WSCI was backed by Sun, Intalio, SAP, and BEA, and has been submitted to the W3C. However, several original supporters of WSCI are now lending support to BPEL.
WSCI is influenced by Business Process Modeling Language (BPML), which while not directly relevant to integration patterns does bear mentioning for the sake of WSCI's historical context. BPML represents business processes in an XML-based meta language used in process modeling. BPML's workflow aspects are largely part of WSCI, but BPML also includes a companion graphical notation and query language.
Like BPEL, WSCI recognizes the fact that enterprise integration involves lengthy conversations among composite services rather than the single operational invocations assumed by basic web services protocols. WSCI provides a way to link service messages from multiple operations into these composite processes, ensuring along the way that messages are sent or received in the proper sequences, sent and received according to declarative business rules, sent in transactional fashion when needed, and portrayable and manageable as a single global process. Leveraging web service advantages over traditional proprietary MOM solutions, WSCI also accommodates the dynamic discovery of services, heterogeneous protocols, and decentralized coordination of workflow.
Like BPEL, WSCI relies heavily upon WSDL's advertisement of service endpoints, portTypes, operations, and message types. WSCI actions directly map to operations exposed in the WSDL of the services within a choreography. Moreover, the WSCI syntax is embedded directly within a WSDL file; the declarations sit either in a WSDL document which imports the WSDL documents of the choreographed services, or within the WSDL file of a single service whose operations are being choreographed. WSCI elements are contained within the WSDL <definitions> element.
The fundamental construct of WSCI is the action, in which web service messaging occurs. Actions are grouped within process elements so that they are declared to occur sequentially, in parallel, in loop, or conditionally. A set of processes is grouped with an interface declaration; this <interface> element is the interface to the process component, and it is directly embedded within the WSDL definitions of a web service. Many of the activity elements are similar to those of BPEL, and like their BPEL counterparts they include support for XPath expressions.
The WSCI specification can be found here: http://wwws.sun.com/software/xml/developers/wsci/wsci-spec-10.pdf
Java business process component standards
The Java Community Process (JCP) creates Java language APIs and bindings influenced by non-Java standards. In particular, standards developed by the Object Management Group (OMG) and the W3C have been shadowed by the JCP. Recently, the JCP has turned this approach toward web service standards developed by groups such as the WS-I, and two new much-ballyhooed JSR's are now underway to address Java bindings for business process components: Process Definition for Java (JSR-207) submitted by BEA Systems, and Java Business Integration (JSR-208) submitted by Sun Microsystems. While at first glance these two proposals may seem to overlap, they are actually fairly complimentary. JSR-207 specifies a way for developers to craft messaging or process components quickly and easily using metadata attached to Java code; JSR-208 specifies how those components will interact with each other, with containers, and with the rest of the J2EE and web services world. So JSR-207 is more or less a micro view and JSR-208 is a macro view of how the messaging between process components is to be standardized in Java.
Process Definition for Java (JSR-207)
Process Definition for Java (JSR-207), submitted by BEA Systems, aims to define metadata, interfaces, and a runtime model for creating business processes in the Java/J2EE environment. This very important JSR intends to specify the standard means of crafting business process components using the Java language and Javadoc-like metadata annotations. Proposed as an addition to J2EE, the mechanism could also be used to build Java implementations of business process initiatives such as BPEL4WS, WSCI, and those produced by the W3C Choreography Working Group.
This technology builds upon Java Language Metadata technology (JSR-175) in order to supply a simple syntax for describing business processes. Metadata can be applied directly to Java source code in order to dynamically generate and bind process behaviors, including support for asynchronous messaging, parallel execution, message correlation, message routing, error handling, and other common flow activities. The metadata semantics, therefore, need to be rich enough to support the parameters needed for a component's container to dynamically set up the messaging infrastructure and handle issues described in Introduction to Message Construction upon the component's deployment.
It is worth noting that this JSR is not needed to enable developers to build business process components in J2EE. It is possible to build such processes today -- but it is laborious work that requires developers to apply messaging patterns at a very low level, and results in workflows that are costly to maintain. This specification intends to simplify the creation of process components so that developers can apply their skills at a higher level, creating more powerful applications more rapidly that are less expensive to evolve and administer over time.
More details on Process definition for Java can be found here: http://www.jcp.org/en/jsr/detail?id=207
Java Business Integration (JSR-208)
Sun proposed Java Business Integration (JBI) in JSR-208 with the intention of defining service provider interfaces (SPIs) for creating a business integration environment for specifications such as WSCI, BPEL4WS and the work produced by the W3C Choreography Working Group. JBI proposes no new Java APIs or annotations, but does include a new deployment and packaging mechanism. Instead of adding APIs for developers, JBI focuses on integration infrastructure, and its SPIs will be visible primarily to product vendors who create messaging and process component models for performing integration work in a Java setting. The JBI expert group aims to follow the lead of the W3C Choreography Working Group and ensure that the work of that group will fit seamlessly into the J2EE platform.
JBI has a fairly lofty goal: Map various systems and protocol standards -- that is, multiple syntaxes used to describe relationships between processes, including syntaxes that are proprietary and vendor-specific as well as those that become standard -- to one another and to J2EE. It provides a Java binding for message choreography regardless of the underlying message and process specifics. It also includes a new packaging mechanism that extends J2EE packaging (such as WAR, JAR, RAR and EAR) to support the deployment of a JBI component into a J2EE environment.
JBI sees three principal roles required for supporting process components: Bindings, machines, and the environment. Bindings are about communication formats, and include message formats and network transports along with their mappings as well as forming an umbrella around workflow formats such as BPEL; machines are the service and process containers that host and manage business processes; the environment is the over-arching process management system that links heterogeneous machines and bindings to one another. JBI focuses on the environment as the core of the integration system, and specifies how machines and bindings interact with it. The JBI packaging and deployment mechanism is intended to provide a means of hooking processes up to the environment in a standard way, but the actual creation of those components is outside the scope of the specification.
JBI views the Process Definition for Java (JSR-207) described above as a way of composing process components, and the runtime that will host those components fits into the category of a JBI machine. That machine should implement the Message Translator, Service Activator, Envelope Wrapper and other patterns necessary to expose their formats and protocol behaviors through JBI to ensure that it can integrate correctly with the integration environment.
More details on JBI can be found here: http://www.jcp.org/en/jsr/detail?id=208
WS-*
Less ambitious than the process integration specifications described above, a number of web services specifications are emerging to extend SOAP- and WSDL-based web services to include reliability, security, statefulness, and quality of service. Typically identifiable by the "WS-" prefix, these specifications build on the W3C technologies and each addresses a fairly specific problem.
Unfortunately the web services standards landscape has become muddled with competing versions backed by competing vendor alliances, and perhaps as a result of this competition many of these standards are rarely seen implemented in the wild today. A standards shake-out seems to be looming. Nevertheless, these specifications are worth noting, as their idioms and tactics might prove useful to application developers who are applying web services technologies like SOAP and WSDL to messaging-based enterprise integration. These standards are also certain to find a home in the products of the vendors who propose them, including those of IBM, BEA, Microsoft, and Oracle.
A few of the more notable specifications in this category include those dealing with transactability, reliability, routing, conversational state, and security. These are described below.
WS-Coordination and WS-Transaction
Being stateless and unreliable, the most popular web service protocols and transports do not provide the quality of service required by transactional processes. This shortcoming blossoms into a critically important problem. In practice, it means that if a developer wishes to use a web service-based integration mechanism, that developer must grow his own transaction scheme within those integration mechanisms. A collection of service invocations that occur through asynchronous messaging must be capable of being batched atomically, so that the messages function as unit that can fail or rollback all at once, or as a unit whose failure can trigger some form of compensation. This is common in proprietary MOM systems. The Web Services Coordination and Web Services Transaction specifications tackle this problem for web services.
WS-Coordination, drafted by BEA, Microsoft and IBM, specifies a way to create and propagate contextual information by all of the services participating in a flow, even asynchronously and over jagged time intervals. The specification describes an extensible framework for creating protocols that coordinate the actions of applications and services. These coordination protocols function by creating and registering XML-based contexts that are propagated with SOAP messages and used by coordinators located at all endpoints in an interaction.
Such contexts can be used to support a number of application behaviors, such as those that need to reach consistent agreement on the outcome of distributed transactions. Accordingly, the WS-Transaction specification uses WS-Coordination to implement distributed transactability across service invocations.
WS-Transaction defines a way to monitor and message the success or failure of each action in a flow. Practically, this means that when a SOAP message arrives at an endpoint, the SOAP Header containing the coordination context must be filtered and pulled from the message (implementations may employ the Content Filter and Splitter patterns for this task) and then sent to the transaction coordinator for interpretation.
The SOAP envelope excerpt below provides a simple example of a coordination context used for making SOAP operations transactable through WS-Transaction. This context information in the SOAP header is used by coordinators to register applications to receive transaction events such as enlistments, the prepare stage of a two-phase commit process, rollbacks, and commits.
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope">
<SOAP-ENV:Header>
<wscoor:CoordinationContext
xmlns:wscoor="http://schemas.xmlsoap.org/ws/2002/08/wscoor"
xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"
xmlns:myTransactableApp="http://foo.com/baz">
<wsu:Identifier>http://foo.com/baz/bar</wsu:Identifier>
<wsu:Expires>2004-12-31T18:00:00-08:00</wsu:Expires>
<wscoor:CoordinationType>
http://schemas.xmlsoap.org/ws/2002/08/wstx
</wscoor:CoordinationType>
<wscoor:RegistrationService>
<wsu:Address>
http://foo.com/coordinationservice/registration
</wsu:Address>
</wscoor:RegistrationService>
<myTransactableApp:IsolationLevel>
RepeatableRead
</myTransactableApp:IsolationLevel>
</wscoor:CoordinationContext>
</SOAP-ENV:Header>
<!-- SOAP BODY (snipped) -->
</SOAP-ENV:Envelope>
The WS-Transaction specification defines two coordination types for developers to use in their applications: Atomic Transaction (AT) and Business Activity (BA).
Atomic Transactions map fairly well to traditional distributed transaction technology, such as XA. They are useful for relatively short-lived operations in which locking of resources -- such as threads and portions of data sources -- are acceptable, and in which absolute rollbacks make sense. WS-Transaction provides a means of linking proprietary XA implementations, including support for two-phase commit, to web 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. An example is a business activity that includes the booking of an airline flight, rental of a car, reservation of a hotel room, and reservation of theater tickets that a user makes over a two- or three-day period. Each activity in this flow may be an atomic transaction, and if one of the events should fail, the over-arching business activity of making the travel arrangements should adjust via compensation rather than through coordinated rollback of all atomic transactions.
The WS-Coordination and WS-Transaction specifications are promising attempts to provide reliable, rich behaviors in the event of failures during service messaging. As they begin to wind their way into products, they should take the burden off of developers to craft their own transactability and contextual services around message-based service applications.
Information on WS-Transaction can be found here: http://dev2dev.bea.com/technologies/webservices/ws-transaction.jsp
WS-Reliability and WS-ReliableMessaging
It is common for message-based interactions between web services to require reliable, guaranteeable messaging even in the event of network, application, or component failures, and to include persistence mechanisms and resend semantics. The most popular web service technologies do not provide such reliability, however; SOAP without enhancements, for example, isn't comprehensively useful in many enterprise messaging scenarios because its most popular bindings don't reliably guarantee message delivery.
To remedy this, application developers are typically forced to implement reliability themselves using the extensibility of web service mechanisms such as SOAP Headers. To eliminate the need for application developers to take on this task, new standards are emerging to tackle web service reliability. Two such specifications are WS-Reliability and WS-ReliableMessaging. As is common in the nascent web services standards space, these two standards are competing, backed by different groups of vendors aimed at the same problem domain.
Web Services Reliability (WS-Reliability) provides SOAP-based web services with the ability to exchange messages asynchronously with guaranteed delivery, without duplicates, and with message ordering. It is a SOAP standard for managing message aggregation and sequencing, and provides a standard tactic for implementing theGuaranteed Delivery and Resequencer patterns, among others. WS-Reliability leverages the SOAP Header mechanism to add the header elements MessageHeader, ReliableMessage, MessageOrder, and RMResponse to SOAP messages. These elements denote message identifiers such as group ids and sequence numbers, timestamps, time to live values, message type values, sender and receiver information, and acknowledgment callback information. WS-Reliability is produced by a number of vendors, including Sun, Oracle, and Sonic, and it has been submitted to OASIS. It is heavily influenced by the functionality of the ebXML Message Service (ebMS) described above.
To conform to WS-Reliability, the receiver of a SOAP message must respond with either a fault or an acknowledgement using the RMResponse element in a SOAP header. If such an acknowledgement is not received, then the sender will resend the same message using the same message identifier. The sender is required to persist the message until its time to live value has expired, or until acknowledgment or failure has occurred; the receiver is also required to persist the message until it can be reliably transmitted to the application layer.
To ensure that once-and-only-once message behaviors are enforced, WS-Reliability provides a sequence number mechanism which can be enabled based on application requirements. Separate messages that are grouped together may share the same group identifier, but will advertise their own sequence numbers within the SOAP header, allowing receivers to resequence the messages before delivering them to the application.
The WS-Reliability specification can be found here: http://www.oasis-open.org/committees/documents.php?wg_abbrev=wsrm
The Web Services Reliable Messaging (WS-ReliableMessaging) specification describes a similar protocol that allows messages to be delivered reliably between distributed applications in the presence of failures. The protocol is described in an independent manner, allowing it to be implemented using a variety of network transport technologies and bindings. The specification does include one specific binding for SOAP. WS-ReliableMessaging is backed by BEA, IBM, and Microsoft and has not yet been released to a standards body.
WS-ReliableMessaging operates on the same principles as WS-Reliability. It makes similar use of acknowledgements, callbacks, identifiers, implies similar usage of persistent message caches, and offers detailed fault messages. It ensures that messages are delivered according to any of four basic delivery assurances: At most once, at least once, exactly once, and in order. An example of a message sequence delivered through WS-ReliableMessaging is illustrated below.
Figure 3: WS-ReliableMessaging provides guaranteed sequential delivery through a series of acknowledgment callbacks that rely on unique ID's inserted into the SOAP header element.
A key difference between the two competing reliability specifications is that WS-ReliableMessaging includes usage of other critical web services specifications, such as WS-Security and WS-Addressing. In practice, this means that WS-ReliableMessaging uses specific idioms from other standards for supplying this information, whereas WS-Reliability supports the features but does not yet insist on the idiomatic forms specified in the other new standards.
More information on WS-ReliableMessaging can be found here: http://dev2dev.bea.com/technologies/webservices/ws-reliablemessaging.jsp
WS-Conversation
Web Services Conversation (WS-Conversation) specifies a protocol for managing stateful asynchronous message exchange between a sender and receiver, usually across two SOAP endpoints. In contrast to relying on an encapsulating business process component for managing stateful message exchange among multiple partners, this proposal provides a simple means of accomplishing the same thing between a single client and single service (where the client may also be a service).
The protocol leverages the SOAP Header mechanism to send identifiers, or token ids, along with SOAP messages. When a stateful conversation is begun, the <StartHeader> element is used to supply a conversation identifier and callback URI. Subsequent messages that are part of the same conversation use the <ContinueHeader> and the <CallbackHeader> for further requests and replies, and these elements will include the same identifier established when the conversation was started.
The SOAP Header mechanism can be used to implement these patterns without use of these standard mechanisms, though there is benefit in establishing a common mechanism for clients and services across platforms. It is a formalization of the Aggregator and Composed Message Processor patterns using Correlation Identifier for the purposes of mapping multiple messages to a single session.
The approach of externalizing state management through a process component or choreography seems more promising for larger-scale integration projects where it is useful for simplicity's sake to consider the services and components as black boxes, but WS-Conversation is an example of what can be done when greater control over the services and clients is possible.
WS-Security
While standards such as WS-ReliableMessaging, WS-Coordination, and WS-Addressing provide various mechanisms that identify the sender of a message, none of those specifications guarantee that the sender actually owns the identity it claims. The elements of the WS-I Basic Profile -- XML Schema, SOAP, WSDL and UDDI -- make no mention of how identity is verified and guaranteed, or how message integrity is to be maintained. Early adopters of web services either kept their services open and available to all, or developed proprietary security protocols in order to fill this gap. The proprietary and private approaches created an undesirable coupling between message senders and receivers, something particuarly galling in otherwise asynchronous and loosely coupled federations of message nodes.
WS-Security, also referred to as the Web Services Security Language, is the proposed standard means of addressing these issues. Of all the WS-* specifications, it enjoys perhaps the broadest level of consensus among the major web service platform vendors. Created by a consortium consisting of Microsoft, IBM, and Verisign, it is now part of OASIS; it has received votes of confidence from the likes of Sun, BEA, Intel, SAP, IONA, RSA Security, and others.
WS-Security does not propose new security technologies, but rather it bridges SOAP and existing security technologies. It provides a generic, extensible means of associating security tokens with SOAP messages and propagating those tokens to SOAP endpoints. It also specifies the standard approach to encoding binary security tokens, such as digital certificates and Kerberos tickets, in SOAP messages. It does not describe specific fixed protocols, but rather establishes a general set of mechanisms for implementing any number of security protocols and incorporating any number of trust domains, signature formats, and encryption technologies. In as much as it can include use of digital certificates, digests, and implementations of technologies such as PKI, Kerberos, SSL and the like, WS-Security represents a way to apply familiar Internet security standbys to SOAP endpoints.
In addition to verification of sender identity, WS-Security may also protect message integrity -- that is, protect it from intermediary prying eyes during network transmission -- by leveraging the W3C XML Signature and XML Encryption standards. In cases in which intermediary actors and third party services are not involved, however, the use of HTTPS is a common alternative means of protecting SOAP messages in transit.
The security model specifies that a SOAP message sender makes a series of claims such as the sender's identity, group, privilege, and the like. These claims are collected in the form of a signed security token. The receiver of the message is charged with endorsing the claims. The tokens and signatures are carried in a SOAP Header block, specifically under the <security> header element in the WS-Security namespace. If an error occurs when the receiver endorses claims, that error will be one of two types: "unsupported" errors, which indicate that the endpoint does not support a particular token or encryption algorithm; and "failure" errors, which indicate most other errors, including all those related to invalid tokens and signatures. The specification does not mandate that failure errors always be reported, as they may be the result of an attack. When errors are reported, they take the form of SOAP Faults with fault codes defined in the specification.
The WS-Security specification can be found on the web sites of each of its co-authoring vendors, including the following location at IBM: http://www-106.ibm.com/developerworks/library/ws-secure/
WS-Addressing, WS-Policy other WS- Specifications
There are a number of other proposed "WS-" specifications with varying degrees of support and acceptance. Some are quite narrow in scope, such as WS-Addressing which defines XML elements to identify web service endpoints in messages. This specification aims to support messaging through intermediaries such as endpoint managers, proxies, firewalls, and gateways in a transport-neutral manner. Essentially, WS-Addressing is a standard way to denote who a message is from ("From:") and who it is to ("To:"). It provides a means to plug SOAP-based web services into Recipient List solutions. As it provides a means of specifying where to direct a reply, it appears destined to be the standard web services approach to resolving the issues raised in Return Address.
A means of supplying metadata about services, the Web Services Policy Framework (WS-Policy) offers a syntax for describing the policies of a web service. Such policies include service requirements, preferences, capabilities, and quality of service metadata. The accompanying Web Services Policy Assertions Language (WS-PolicyAssertions) specifies a means of asserting that a message or service endpoint supports a particular policy. It involves investigating the WS-Policy declarations in search of a specific required policy. Finally, the Web Services Policy Attachment (WS-PolicyAttachment) describes how these policy standards fit into existing web service technologies. It specifies how to associate policy expressions with WSDL type definitions and UDDI entities, and it defines how to associate implementation-specific policies with all or part of a WSDL portType.
New WS-* specifications are surfacing quickly as vendors race to formalize the implementation practices that application developers are following, staking a claim to valuable web service intellectual property in the process. Wise application developers will keep an eye on interesting standards and cull idioms from them when useful, but will also bear in mind that the pattern and not the implementation idiom is most important to crafting a message-based application. The emerging WS- standards are not yet required for implementing interoperable enterprise messaging systems, and where they become hindrances or distractions, they should boldly be ignored until mature.
Summary
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 service standards; many of these standards focus on the composition and behavior of workflow components called business process components. Standards such as BPEL, WSCI, and the WS-* specifications tackle many of the problems described in this book, and implement several of the patterns in this pattern language.
Still, the emerging standards stories are occasionally conflicting and can be confusing. They're certainly not all ready for prime time. When applying a pattern, an application developer should avoid getting bogged down by standards and stay focused instead on the particular use cases at hand. Take a look at how certain standards are approaching a problem, and adopt those tactical, idiomatic implementations of a pattern if it makes sense, or if it's helpful during implementation -- regardless of whether the approach is standardized across vendor products. Developers can also provide feedback to standards organizations to challenge, criticize, and otherwise ensure that standards become practically useful and not academic or vendor exercises. 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.
Integration Pattern Language
