06/15/08 :: [SOA] the Remoting Bunch [permalink]

|

Jim Webber pointed out (a better) conversation he has had with Herbjörn Wilhelmsen at the end of last year. The level is a bit higher here. Interestingly he starts talking about "states", maybe another year and he will realize how important the concept of "state" is to constructing reusable IT assets assembled in composite information systems. He is still cohesively stuck on the concept of "one process" equals "one service" and mixing up loose coupling and cohesion. But hey, what are the kinds of ideas that humor can't make you swallow: if you can "joke" about it, it must be right.  I crack jokes therefore I am is the 21st century philosophy.

At the end of the day, you have a bunch of guys who have been remoting anything they could -probably because it was a "cool" idea. Most of their focus has been on making remoting "seamless" (or even serendipitous). Ultimately the remoting bunch (any one remembers this movie "My Name is Nobody"? -it's a spaghetti western that features the Wild Bunch), ultimately the remoting bunch  did not find many applications for their work, sure enough "scaling out", "fail over" or "Distributed transactions" were direct applications of distributed computing but non content of these major achievements they kept shooting at everything they could.

SOA is an architecture that let's you build solutions from reusable IT assets. Sure enough that smells remoting, that feels remoting but not the kind of remoting that Jim, Steve or Stefan are talking about. They focus only, and exclusively, on calling a process from another process as much as possible (not even reliably). Over all these years, the only thing they dropped is the making remoting "seamless", they got that right. In a reverse of fortune, they now want to make remoting "explicit", subsuming programming models. They see the Web not as resources (don't be fooled, they can't care less about the resources) but as a massive self-expanding remoting infrastructure. Wow, could they have ever dreamed of something like that? REST and MEST allied to the same cause.

The question I have and will always have for this kind of reasoning is: Do you really think that by using HTTP you are automatically creating reusable assets? This is the fundamental question. Do you give a money back guarantee to your statements? What Jim tells you in the small print (and without jokes) is that there the "smarts" are pushed on the "edges". Yeah,  ... yawn ... this is how ESB's have been implemented for years now. Jim, you need to change your slides and come up with new jokes. The big "in the middle" infrastructure is a thing of the past that initially came out precisely of the limitations of HTTP as a transport for Web Services. The "common" information model and the "common" transport of EAI have long disappeared. Sure JBI perpetuated that idea with the "Normalized Message Router" but who is using JBI "in the middle" today? not many people or vendors.

An ESB is a "Service Container", you can have more than one ESB type in your infrastructure. Service Containers can even be nested. The primary purpose of a Service Container is to provide "loose coupling" between the service implementation and the interface it is exposed with. This is what you call "smart" on the edges, in the fine prints. Now you can hand-code these "smarts" with lots of people or you can use technologies (and tools) that make it easier to "transform", "route" (behind the service interface to the appropriate service implementation), ...

I would even argue that when it comes to "ESBs" (as Service Containers), two can prove better than one. You need a service container on the consumer side and one on the provider side. Of course, I am a "peer-to-peer" guy, so the notion of "consumer" and "provider" is kind of weak. The only distinction is "who fired the first message first". At the end of the day, a Service container is in charge of bridging the internal interface with the external interface from many different aspects (Transport, Security, Protocol, Message exchange pattern, ...). If you push these "smarts" in your code and hand code them because you think "HTTP is enough" you are in for a very big disillusion.

Now, if you think just by throwing an ESB in your IT organization you will create reusable assets? you would be wrong too. Creating reusable assets is not easy (it is not really hard too), what I mean by that is that it is not serendipitous. Reusable assets are reusable because you spent a bit of time on governing them, you have a rock solid versioning strategy (I would argue 99% of the people don't get that) and because you have an ESB to help you inject some code without breaking or touching your service implementation. A guerilla approach to SOA will sent you directly to the inextricable jungle where Che ended his life. I am a lot closer to Jean-Jacques Rousseau than the Che, it is not with "killings" from the "remoting bunch" that we will restore IT's ability to deliver value, far from it. There is a lot more to learn in Rousseau, for instance in the Contrat Social, when building your SOA than in the Che: 

  • understanding the tension that seems to exist between liberalism and communitarianism
  • following the general will allows for individual diversity and freedom
  • Simply having power is not sufficient for that power to be morally legitimate
  • There is often a great deal of difference between the will of all and the general will

I think that I have overwhelmingly proven that thinking "remoting" is the worst thing you can do when building a Service Oriented Architecture. You should focus on creating software agent "interactions" and then, only then use middleware to realize these interactions. Now, don't get me wrong I don't recommend that you start a massive SOA project, each project within IT should be an opportunity to create reusable assets. But this is not "Guerilla SOA", this is another instance of think "Globally" act "Locally".

If you ever wonder what happened to the Wild Bunch, they got all shot -like the Che, after messing up all they could- by Jack Beauregard (with the help of Nobody - Terence Hill).