01/29/08 :: [SOA] Spaghetti Oriented Architecture [permalink]
You might think at this point that all I care is to pick a fight. This is really not the case. It is just that everyone that has something to sell in SOA is trying to kill something else: a technology, a product, a vendor... It seems that in our industry there is no growth possible anymore, you have to "reap and replace" to be successful. This is the attitude that I am fighting. There is a lot of value and good things built by a lot of people. The key to a successful SOA is to really understand when and where to use a technology or a product.
Imagine if we could spend our time doing that instead of trying to confuse the customer base?
I am watching Jim Webber's presentation on Guerilla SOA. He is after large SOA efforts, ESBs and WSDL ("WSDL encourages RPC like interactions" and of course he is selling his own SizDL). Frankly I don't understand his point. Because first he tries to show that an ESB is stupid and then he says, well spaghetti oriented architecture is a fact of life and BTW, don't throw your ESB because you can use it as a service container on the "edges".
Again, I don't think this is rocket science, if we go back to my simple model of Loose Coupling, this model supports multiple topologies, here is a centralized one:
ESB is about centralizing some of the loose coupling code (as well as management and coordination). There is nothing wrong with this picture, it is topologically equivalent to the decentralized picture. IMHO, people don't get (bi-directional) SOA topologies. You would use an ESB if it helps you write the LC code and "connect" to heterogeneous back-end (internal) interfaces.
Five years ago WS-* did not have security, transaction, addressing and reliability, so the ESB provided messaging with this kind of QoS. The value of this aspect has gone down because of the completion of WS-* stack, but it does not mean that the ESB has lost value as a service container (with centralized management, and coordinators) or as a loose-coupling engine.
So the real question you need to ask is how do you plan writing the LC code and connecting to your internal interfaces. Sometimes, it makes no sense to use an ESB, sometimes it does.
Now if you look at Microsoft’s Windows Communication Foundation, which is Microsoft’s Service Container, you realize that it suffers from an important architecture flaw. The flaw is not fatal, and WCF is a great container for certain types of service implementations but it does not offer any room to implement LCc and LCp independently of your component implementation. The design goal of WCF was to enable designers to model service, message and data contracts from familiar and popular programming languages such as C#, but by doing so, Don strongly coupled the implementation to the external interface. Incidentally, this is why WCF is really about "code generation" and why people like Steve Vinoski were lead to believe at first glance that "this is WS-*". In WCF, you have no choice, the implementations of the consumer and provider are tied to the "service" interface.
In terms of loose coupling, WCF only offers the antiquated thinking that loose coupling is achieved by exposing multiple endpoints for a given implementation and configuring communication channels at deployment time. Not surprisingly, WCF does not offer any assembly mechanism other than creating a binary assembly (with two components). WCF was solely built with the assumption that the use of a common syntax, the use of an “Object Oriented” contract and the abstraction of middleware APIs was enough to ensure loose-coupling between consumers and providers. The WCF designers never thought about concepts such as WSDL as inter-action definition languages, BPEL as an inter-action programming language, assemblies as way to create units of work from inter-acting components...
On another note, I was happy to hear Jim talking about BPEL as simply a programming language. I picked this fight in 2002. I remember being the only one to speak of BPEL in these terms against people like Assaf, John Pike or Howard Smith. As usual, there was no room for something else than their views, we all know how it ended... Yet, I am a bit disappointed by Sanjiva, who has participated in the WS-BPEL working group, that still considers BPEL as a "workflow" language (as opposed to a composition language) and explains that WSO2 has developed a JavaScript based language to compose services. Again, there can be several programming languages that are capable of doing the exact same thing. IMHO, what Sanjiva is explaining is that sometimes BPEL is heavy weight and you might benefit from a lighter weight web services composition language. We certainly agree on that. Is that a reason to try to displace BPEL, I am not sure.