Sunday, November 13, 2005

SOA Dialogues

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].
None.
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.

4 Comments:

Anonymous Muhammad Zahalqa said...

It's seems that most of the buzz around SOA is driven by misunderstanding of the real meaning of SOA.

Architecture is almost like diamonds (for ever), implementation is always constrained by the available or lack of technology and standards.

2:26 PM  
Blogger Muli Koppel said...

Hence, an "Open Architecture" is one that is indifferent to any standard or technology. I think that's openess and not WS or J2EE or whatever you'd pick from the bunch of current, temporal, standads.

Thanks Muhammad for your comment

Muli

10:23 AM  
Blogger Joshua Fox said...

Your comments are quite correct.

Just to add a point in favor of where WS-* can provide value: Your proposed architecture requires the hub to provide adapters into many technologies such as Java, .NET, mainframes, etc. Adaptation must include the functionalities of invocation, discovery, transactions, etc.

Not too hard to do, but you'd save yourself this step if you could easily procure adapters to convert any of these technologies, and other, more obscure ones, into your hub.

5:35 PM  
Blogger Philip Hartman said...

It seems that the only thing which makes the current buzz around SOA perhaps a little different from previous silver bullet discussions like CORBA, message oriented middleware, etc. is that in the case of SOA enabled by web services, both the Microsoft camp and the non-Microsoft camp (IBM, Sun, HP, BEA, etc.) are finallly agreeing to at least some of the same standards. Without this agreement, SOA is just the latest hub and spoke marketing fad.

5:18 AM  

Post a Comment

<< Home