World Wide Webber


My Books
Developing Enterprise Web Services by Sandeep Chatterjee and Jim Webber
Amazon:
US, UK, Canada, Germany, France
Now available: Korean Edition

My Bookshelf
Programming Clojure by Stuart Halloway

RESTful Web Services by Leonard Richardson and Sam Ruby
The Grady Bunch
Posted: 16 March 2006 @ 01:50 UT from Sydney, Australia

There's a lot of blog traffic (and a high degree of email traffic too) about Grady Booch's recent article, much of it highly complimentary. Grady is clearly a far smarter monkey than most and has a bit of cult following, but in this instance some of what Grady is saying is (perhaps unintentionally) unhelpful, irrespective of his luminary status (not that I mind disagreeing with luminaries, I'll disagree with my mob's Chief Luminary too!).

Grady says:

BTW, in this context, the concept of an enterprise service bus can be easily explained as a very elegant and simple pattern for location independence/message translation.

In no way should location transparency be considered a virtue in service-oriented systems. While location transparency underpinned distributed object systems like CORBA and was a great thing for individual applications, location transparency in service-oriented systems is the thin end of the wedge in terms of making the distributed system mistakenly appear as if they are centralised systems. When a service determines it is time to send a message it should be aware that it is sending to a remote entity and know the (logical) address of that recipient because a boundary is explicitly being crossed.

Furthermore, the notion of having messages transformed on the bus complicates architecture, development, deployment and governance. The most scalable system in the word today (the Internet) works because application smarts are all at the edges of the network. Sure there are smarts in the network, like routers, but these are totally transparent to applications. From service or application's point of view there is a simple, transparent channel between applications and services. Introducing smarts at the application level on the network merely complicates matters since I now have multiple locations where application logic can reside - I'd very strongly advocated keeping all such logic encapsulated behind service endpoints.

So to paraphrase Grady, I'd say that the concept of an enterprise service bus can be easily explained as an inelegant and overly simplistic pattern for location independence and message translation.

Comments:
#

I agree: transformation is not something that is helpful "on the bus". It's also not something that is needed in a pure SOA, which is another reason the "ESB is the way to achieve SOA" crowd annoy me! I think there is a need for a service bus (note, no TLA), but it can and should be pure SOA.

#

You're both wrong.  

1) Jim just translated "location independence" to "location transparency". Two different things entirely. Having said that, excellent point on moving complexity to the boundary of the system. In distributed systems, I thought we learned that first from socket programming, though... 

2) Mark, it depends what you mean by "on the bus", but problem here is that you need transformations to be managed at the infrastructure layer before you arrive at the service: precisely because the transformation is required to move between type definitions: its unlikely all participants in a soa will understand the same types.

#

Greg, I didn't say that transformations aren't needed, but I don't see them as some special part of an SOA infrastructure (i.e., "in the bus" is what I meant): it's a service just like anything else. If I need transformation then I'll indirect to my ultimate service through a transformation service, i.e., it's "on the bus".

#

Your previous comment said "transformation is not something that is helpful "on the bus".", so I take this to mean that you meant something different than what you said? In any case, the difference between "in" and "on" the bus is all relative since the topology of any given ESB product appears to be somewhat unique. Bottom line: transformation is required as an infrastructure service in a SOA solution. I think we are in agreement on that?

#

We're in agreement that it's required. We're in disagreement as to whether it makes a difference "in" or "on" the bus. I think it does.

#

Ah, but that really requires an agreement on what we mean by "the bus"...

Author Name:
Email:
Author URL:
Comment:
Antispam:
Please type the following string (note that if the strings don't match, your comment will be lost... sorry!): 'RFOTN'.
 
Recent entries

Recent comments

Feeds:
RSS 2.0 Atom