The deeply ingrained point-to-point mindset of mainstream computer systems design is hampering recognition of some of the most basic concepts required for successful deployment of service-oriented architecture. It always seems more appealing to think in terms of dedicated, high-performance direct connections, but pause for a moment to consider the limitations on scalability and flexibility this kind of architecture brings with it.
"Practitioners of Ajax get high-intensity user interaction (end-user productivity), asynchronicity (efficient background processing), web browser access to web services (web service access, reuse, and interoperability, as well as SOA integration), platform neutrality (browser and operating system agnosticity), and the Ajax feature set can be delivered as a framework you don't have to create yourself (developer productivity)."
But Dion forgets about mediation, writing that "heavy-duty WS-*-style SOAP stacks probably won't play well with the lightweight XML/JSON service interactions that Ajax prefers." This is a misguided assumption for two separate reasons:
As Nick Malik pointed out in a somewhat ill-tempered post, a lot of Ajax implementations are going to be RPC-style requests that are effectively part of an application rather than something that operates at the services layer.
In cases where Ajax acts as a client service consuming an enterprise web service, the way to preserve WS-* integrity will be to do so through the means of a mediation layer that transforms between the two services implementations.
Citing Ajax may be an extreme example, but it demonstrates the value of mediation in connecting diverse services. You can never assume in an enterprise services infastructure that every participant will be using a full WS-* stack (and even if they are that they will all be using the same one!). The surge of interest in Ajax is yet another illustration of the unpredictable variables that enterprise SOA has to cope with. You can either attempt to lock down your enterprise architecture with iron-fisted governance that in all probability is going to negate every benefit you ever hoped to gain from rolling out SOA in the first place. Or you can mediate.
As Blue Titan's Frank Martinez explained to me last week, this means adopting a new programming model in place of client-server or client-service that is client-intermediary-service. Actually, that should probably be clients-intermediaries-services all in the plural, because it's only by having a distributed web (or mesh, or fabric) of intermediaries that you get the kind of redundancy and scalability that's required to operate an enterprise infrastructure of multiple autonomous service consumers and providers.
This is the context in which Synapse emerges. Backed by Blue Titan, Infravio, Iona Technologies and Sonic Software, Synapse is an attempt to define an open-source intermediary that can be used across a broad swathe of SOA infrastructure products, potentially creating a common mediation framework that will be used across all web services deployments. A new startup, WSO2, led by senior figures from the Apache Web Services group, is spearheading the project (I highlighted WSO2's launch in a previous post). Their familiarity with, and status within, the Apache community should give Synapse a good chance of rapid progress through the Apache process. But for the next few months, the best prognosis for the success of Synapse would be if very little was heard about it. The last thing the project needs is a succession of vendors joining up and combining to slow down the fast pace that the prime movers plan to set. The sooner that Synapse emerges as a fully formed, Apache licensed project, the easier it will be to establish a mediation framework powerful and ubiquitous enough to begin to dissolve away that hidebound point-to-point mindset.