A new entity is emerging, deep within the SOA fabric, as crucial as the web application server became at the dawn of web-based distributed computing. This new entity doesn't have a name or a well-defined shape, yet. But it must evolve before the new era of services-based distributed computing can have its day.
Its role boils down to policy-driven message routing and monitoring. More expansively, what that means is that this is an entity that:
passes messages across the services infrastructure (ie on their journey between endpoints),
monitors the headers and content of messages, with a view to logging, reporting, or acting on the data it discovers,
transforms messages in accordance with the policies laid down in the service contract they're fulfilling, and
takes actions (eg re-routing or transforming the message, and/or sending an alert) to enforce any overarching governing policies where a message appears to infringe them.
Classically speaking, this is a message broker, but the term is so overloaded with legacy meanings that using it often obscures rather than helps productive discussion of what shape it should take in a standards-based, loosely coupled, services-oriented architecture. Most crucially, a broker tends to be imagined as a single component some kind of hub or crossing point through which every message must pass, which is inconsistent with the notion of a truly distributed, loosely coupled architecture. The entity that's required is more likely to be a loose confederation of co-operating components collectively, a mediation services layer and the collective name for those components could be 'mediation services brokers'.
Mediation services brokers take various forms and footprints. They perform a subset of the features found within an ESB product, for example. But breaking out the MSB functionality as a separate component is a great help in conceptualizing
patterns of interoperability between separate MSB implementations within the mediation services layer,
different possible implementations of MSB functionality ranging from embedded network devices through operating system extensions to dedicated servlets or server instances and finally
how to optimize implementations to deliver the desired functionality at various price and performance points.
What set me thinking was Reactivity's inclusion of a native Java capability in its appliance to make it easier to configure policies that relate to enforcing certain business logic rules. CTO Andrew Nash explained to me that "you're going to need enforcement points in the network that can do this in a configurable fashion." Although an XML purist would undoubtedly insist on doing this using XSLT and XPath, a pragmatist would recognize that it's a whole lot simpler and cleaner to do it by building a little bit of business logic execution capability into the device using a Java VM.
I also had a meeting last week with Mark Palmer, from the Real Time Divison of Sonic Software parent Progress Software. Palmer's division specializes in a discipline known as event stream processing, which is the art of looking for patterns in message flows and applying business rules on-the-fly in response to certain patterns (eg 'if you see multiple credit card transactions on the same card account with different merchants within a few seconds of each other, decline the transactions and alert the fraud unit'). This form of business visibility and reaction is going to be an increasing feature as SOAs grow in maturity, and the message services layer is where it will be executed.
The emergence of the Windows Communications Foundation (WCF) from Microsoft and the Apache Synapse project are further examples of potential MSBs, providing ample evidence that this functionality will take many forms within a typical enterprise infrastructure (and even more so in the wider Web spanning multiple enterprises), emphasizing the importance of interoperability within the mediation services layer.
As I've said earlier, I see this interoperability being enabled with web services standards acting as the default mediation framework, but as the comments on that earlier posting show, not everyone agrees with me. A couple of days ago, I noticed an interview with Jim Waldo, the one-time architect of Sun's Jini project, who takes a very different view, rejecting the whole idea of protocols because they're too rigid. Personally I'd say that's the reason mediation is so important, but I'll give Jim the last word here because it's always interesting to consider different viewpoints, and maybe our apparent disagreement has more to do with our choice of words than the underlying concepts:
"Web services are the galactic star cruisers of the Internet ... there will be lots of smaller services that you send over the networks. And that's going to be the platform that you write to. You will see virtual machines of various sorts. I personally like the Java one, but there will be others. Those are the things that will define the platform for you, not the operating system.
"... there is one thing to learn about RMI [remote method invocation] and Jini: It's to give the ability to code from one network to another, which frees you up from having the same protocol everywhere. And by not having the same protocol everywhere, you can specify protocols for a particular use and then grow protocols like you grow a language and let it change over time."
I know our comment system's a bit clunky (actually I'm currently looking for sponsors to help fund an upgrade) but I'd like to hear some other views on this. Tell me what you think about virtual machines and protocols and the whole notion of mediation services brokers.