Specialized Message Patterns for SOA

Duane Nickull, OASIS SOA-RM chair and Senior Technology Evangelist at Adobe, has announced that they have just released a new white paper covering specialized message patterns for SOA. As Duane says:

The paper looks into specialized messaging patterns for Service Oriented Architecture (SOA). Most people still mistakenly believe that SOA is limited to request-response. Such is far from the truth as most standards work on SOA now recognizes alternative patterns such as subscribe-push and probe-match.

Duane discusses a close relationship between Web 2.0 and SOA:

... Web 2.0, is not defined as a static architecture. Web 2.0 can be generally characterized as a common set of architecture and design patterns, which can be implemented in multiple contexts. The list of common patterns includes the Mashup, Collaboration-Participation, Software as a Service (SaaS), Semantic Tagging (folksonomy), and Rich User Experience (also known as Rich Internet Application) patterns among others. These are augmented with themes for software architects such as trusting your users and harnessing collective intelligence. Most Web 2.0 architecture patterns rely on Service Oriented Architecture in order to function.

When designing Web 2.0 applications based on these patterns, architects often have highly specialized requirements for moving data. Enterprise adoption of these patterns requires special considerations for scalability, flexibility (in terms of multiple message exchange patterns), and the ability to deliver these services to a multitude of disparate consumers. Architects often need to expand data interchanges beyond simple request-response patterns and adopt more robust message exchange patterns, triggered by multiple types of events. As a result, many specialized platforms are evolving to meet these needs.

Fortunately the paper includes a nice overview of SOA concepts for those not familiar. It also manages to discuss that perennial flame-war candidate, the role that ESBs can play in a SOA infrastructure:

The common service bus is really a virtual environment whereby services are made available to all potential consumers on a fabric.  This is typically referred to as an Enterprise Service Bus (ESB) and has a collection of specialized subcomponents including naming and lookup directories, registry-repositories, and service provider interfaces (for connecting capabilities and integrating systems) as well as a standardized collection of standards and protocols to make communications seamless across all connected devices.  Advanced ESB vendors have tools that can aggregate services into complex processes and workflows.

And as you might expect given Duane (and Adobe's) history, there's a nice reference architecture for SOA and Web 2.0 that the paper uses when discussing the points the authors want to make. According to the paper, the core axioms of SOA are:

Services themselves should be treated as subservient to the higher level system or systems that use them.  If you are deploying services to be part of an automated process management system, the services themselves should not know (or care) what they are being used for.

...  keep the service consumers agnostic to how the services are delivering their functionality.  This results in a clean decoupling of components, another architecturally elegant feature of modern service oriented systems.  Having dependencies on knowing the internal working of the services functionality is another anti-pattern of SOA and should also be avoided

The first 10 pages of the report are a good overview of SOA, with obvious input from the authors' real-world experiences. Solely for that reason, it is worth reading. Section 4 discusses the different message exchange patterns that can arise within SOA-based applications:

• Simple request-response.
• Request-response via the registry: "An optional service registry can be used within the architecture to help the client automatically configure certain aspects of its service client. The service provider pushes changes regarding the service’s details to the registry to which the consumer has subscribed. When the changes are made, the service consumer is notified of these changes and can configure its service client to talk to the service components and the relationships between them, using features specific to a given language or environment."
• Subscribe-push: "In this pattern, one or more clients register subscriptions with a service to receive messages based on some criteria. Regardless of the criteria, the externally visible pattern remains the same."
• Probe and match: "... a single client may multicast or broadcast a message to several endpoints on a single fabric, prompting them to respond based on certain criteria."
• Patterns for RIA: "Creating Rich Internet Applications (RIAs) requires a level of data management that goes beyond the traditional Request-Response model. Providing a richer, more expressive experience often requires more data-intensive interaction and introduces new challenges in managing data between the client and server tiers."
• Data paging: "Some services automatically facilitate the paging of large data sets, enabling developers to focus on core application business logic instead of worrying about basic data management infrastructure."
• Data push: "Some services offer data-push capability, enabling data to automatically be pushed to the client application without polling (contrast this pattern to the “Subscribe-Push pattern listed above)."

This seems like a complete list. Are there MEPs that are not covered? Are some of these MEPs not necessary?