Messages versus Events?

One way of thinking about SOAs is that they are only about sending and receiving messages (documents) of arbitrary types. Everything else, such as the interpretation of those documents, is hidden behind the service endpoint and is hence implementation specific. Although this is a technically accurate description, the problem with this is that at some level all distributed systems work this way. For example, in the case of CORBA, the message/document is encoded in an IIOP packet and there are well defined ways for that document to be interpreted. Therefore, from an abstract architectural level it would seem like CORBA is an appropriate SOA infrastructure.

The SOA purist says that it is inherently impossible for a CORBA user (or a user of any distributed OO system) to ignore the fundamental implementation choices that are made for them by the architecture: everything is based on objects and methods. In SOA those choices are not architecture but implementation. The problem, however, is that this is an arbitrary distinction; someone else could draw the line at a different level in the stack and come up with different conclusions. Precisely because no new languages have been developed to construct SOA applications, ultimately they will all use objects and method invocations and an architecture built purely on messages has to eventually say something concerning how those messages are mapped to higher-level business logic.

Therefore, no architecture for a distributed system can be complete if it simply works in terms of the message. However, in order to address the 5 points mentioned earlier and maintain the benefits of SOA, it is appropriate to break down the global architecture into two related components:

  • The message architecture: this is concerned solely with the message interaction pattern and although it acknowledges higher-level business processes, these are left to the other architectural component.
  • The implementation architecture: this describes how messages are mapped onto physical components and objects and is not concerned with how those messages are conveyed. A suitable concrete form of this component can still be responsible for maintaining SOA principles, such as loose coupling.

Furthermore, fundamentally SOA is not about message exchange patterns based on request-response, request-request, asynchrony etc. but about events. The fundamental SOA is a unitary event bus which is triggered by receipt of a message: a service registers with this bus to be informed when messages arrive. Next up the chain is a demultiplexing event handler (dispatcher), which allows for sub-services (sub-components) to register for sub-documents (sub-messages) that may be logically or physically embedded in the initially received message. This is an entirely recursive architecture that abstracts away from implementation details, allowing large-scale SOAs to be designed without recourse to a specific implementation.