I had some interesting meetings recently with both Enterprise Customers and Enterprise Software Vendors around the subject of Enterprise Integration and Web Services. Known for my Telco-Grade SOA implementations, I've been invited as the SOA incumbent. What has happened in these meetings resembled a shock therapy. Well, the therapeutic effects are yet to be proven; but judging by the number of dropping jaws – a shock it was.
Here's an excerpt from the vendor's meeting. A picture's worth a thousand words.
Q: Well, being an SOA expert, I'd like to start by asking what WS-standards you were using?
A: No one...
[5 seconds of deep silence].
Q (and the rest of the attendees looking at me in disbelief, as if a horrible consulting swindle has just being revealed): You didn't use any WS standard?
A: No. I don't think SOA and WS-* are interchangeable. They are related, undoubtedly, but they are absolutely not interchangeable. I am here to tell you how to implement SOA. WS-* will come further down the road, if at all.
Q (trying a different tactic): So what's a Service?
A: Service is the façade of anything
Q (visibly annoyed): If it's the façade of anything then it is the façade of nothing!
A: A Service can mask anything that provides functionality. It can mask a granular API, or a business process spanning across multiple applications and enterprises. It can even mask a grid layer providing a computing resource like CPU. So practically, a Service can mask anything.
And then the conversation went on for nearly two hours, in which the internals of Enterprise SOA management were thoroughly discussed. I felt, though, that all the participants in the room were in a great puzzlement, not knowing how to buy this unusual SOA expert.
The meeting with the Enterprise Customer was just as tensed. I was actually invited to comment or verify the work of another consulting firm that prepared a thick-doc recommendation about the future Enterprise Integration infrastructure. And, the manager of the consulting firm said: "Obviously, the Integration architecture must be open and by open I mean complying to nowadays' standards of WS-*, such as WSDL, SOAP, UDDI, WS-Attachment and more."
WS-Attachment? I felt my own jaw dropping. I looked at him in disbelief, thinking: "Your audience is a group of IBM veterans that still live inside the Mainframe. Their kick is CICS. What are you trying to achieve with this WS-Attachment thing?" And then, "Reflexes got the better of me, and what is to be must be…I shot the Sheriff".
Waking-up from this sudden day-dream I found myself in the midst of a tumult. The IBM veterans were on the verge of becoming completely depressed by the idea of having to Web Servicize their entire applications portfolio. And the manger of the other consulting firm was reassuring them by saying that even "Shai Agassi, the golden boy", is on his side – and he fumbled through his presentation until he found a slide of SAP's Enterprise Services Architecture. I sneaked out unnoticed, put on my super hero robe and reentered the room as the SOA-man. "I am the SOA-Man" I shouted to the cheers of the old IBMers.
Ok. Let's cut it here.
What I'd really want to do is to make my SOA point clearer, as I do acknowledge it is bizarre to talk about implementing SOA without using WS-*.
So using my architecture reverse-engineering techniques I would first claim that there are only two application integration architectures: point-to-point (direct) or Hub and Spoke (the go-between). P2P is an ad-hoc, unmanaged, decentralized integration architecture, in which applications are directly connected one to another. Enterprise-level P2P is like Enterprise-level Anarchy. Actually, we cannot seriously claim P2P to be "Architecture", if we consider architecture to be a deliberate cognitive artifact. P2P is indeed the lack of architecture. And I am witnessing, too often, P2P integrations migrated into P2P Web Service integrations by people who believe that now they have finally architected their integrations.
In the Hub & Spoke architecture, all inter-applications communication is bridged and managed by the Hub. When Big Brother is in charge, great Enterprise-level things can happen, easily. This leaves a lot of place for as creative and robust architecture as possible. The Hub can authorize and log; translate and route; handle exceptions and notify errors; briefly – the Hub is the Services Framework. As a framework the Hub masks: it masks technology, semantics, failures, downtime of providers and so forth.
That's for architecture; now for the implementation.
I think the implementation doesn't matter. The Hub can be built using any programming language, using any persistence mechanism and bridging any two technologies. Web Services, in this sense, are nothing but an invocation standard. The Hub is capable of invoking a COM object, an ejb, an Oracle Stored Procedure or… a Web Service. One can request a Service from the Hub by placing the request inside a SOAP message and sending it to the Hub over http, or by placing a proprietary, non-soap request inside an http post, or inside a database table: that's the idea of masking – every application thinks "I am the world" – and the Hub allows it to feel so. And that's today biggest challenge: centrally managing and integrating a bunch of heterogenous, distributed applications, while giving each the illusion it is the "one". It's just like the Mainframe used to be, only it was indeed one physical and logical thing - so it was not that much of a challenge...
Having said all the above, it is clear that current applications shouldn't go through any changes to be centrally integrated – the Hub will take care of what's needed.
Should the Hub be constructed around WS-*? Well, so far I couldn't see the business value of WS-* inside the Enterprise. Moreover, so far WS-* haven't been fully standardized, nor there has been one coherent reference architecture for WS-* that the industry can rely upon. But I am willing to change my mind. And when that happens, I'll let you know.