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.
Service Oriented Architecture is an architectural paradigm and discipline that may be used to build infrastructures enabling those with needs (consumers) and those with capabilities (providers) to interact via services across disparate domains of technology and ownership. Services act as the core facilitator of electronic data interchanges yet require additional mechanisms in order to function. Several new trends in the computer industry rely upon SOA as the enabling foundation. These include the automation of Business Process Management (BPM), composite applications (applications that aggregate multiple services to function), and the multitude of new architecture and design patterns generally referred to as Web 2.0.
The latter, 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.