Ironically, Ross Mason commented on Patrick's post & Patrick responded with what we've been discussing lately at work. The ironic part is I spent the better part of yesterday messing with Restlet and Mule (Ross's product).
My point of view on this topic has changed significantly over the years like Patrick's. I have been pro-CORBA, pro-EAI, tolerant of WS-* (couple months where I built a couple of them in 2001), pro-message broker, pro-ESB, pro-JavaSpaces, and most recently pro-please don't hurt the web
I think that if you spend enough time with middle-ware, you eventually conclude that the best approach is to not hurt the web as much as you can and embrace a more-or-less-peer-to-peer model (i.e., how the web works). A year and a half ago, I preferred the message-centric to the service-centric approach. I have concluded that at the time I was misguided in how I thought I was dealing with the fallacies of distributed computing. I don't think there is anything wrong with messaging & there is a place for it for sure - I just think that the dominant integration protocol should be HTTP. I used to see messaging in the center, now I see it on the edges. HTTP should be in the center.
It is probably important to note that I am talking about coarse grained integration ... the integration of large domains (e.g., sales, manufacturing). I've heard this called the "federated ESB" approach although I wouldn't call it that. I've also heard it called the "ABC" model (application, business unit/domain, corporate). I'm focused right now on the communication at the corporate level - across domains rather than within them. I think that HTTP makes sense everywhere, but for lower level integration (A & B) there may be other choices (I still think that conceptually, you can't beat the Tuple Space concept for A - large applications).
Mule is an ESB, but that term is essentially meaningless today. MuleSource also refers to it as an "integration platform" and an "Enterprise Service Network". Mule allows and encourages any-2-any protocol "mediation". This is good. Mule can certainly be used in a way that does not hurt the web.
I have more learning on Mule to do. I was a little overwhelmed in working with it yesterday (lots of jar files, lots of XML config, examples that didn't help with what I wanted to do, docs that didn't answer my questions - typical newbie stuff). I did succeed in getting it configured to do what I wanted it to do after going down a number of rat holes & now have something to build on this week.
Mule may be a good runtime choice, but I agree with Patrick that an ESB isn't your architecture. Your architecture is things like reference data, meta data, the services & events you expose, your URI naming standard, security, and what is on the wire. You want to build these things so they can stand the test of time.
The appealing thing to me about hiding as much of this as possible behind a good URI naming scheme that doesn't change & HTTP is that I know for a fact that the URI & HTTP will be thriving in 10 years. I can't say that about any integration vendor let alone any integration vendor's current product set.
2 comments:
Fuzzy,
The biggest reason I've seen for using messaging instead of HTTP is guaranteed delivery. Has that improved any in the past few years, or is "good enough" delivery more accepted?
Hi mwesty,
It goes to the whole fallacies of distributed computing bit.
I like messaging - i it just isn't what I lead with any more.
Messaging certainly has its place & isn't going anywhere.
It definitely depends on your requirements. It is definitely the right solution for certain types of systems. For general integration, however, I don't think it is the best choice. It is really hard to compete with the power of the web. You can put a lot of booya behind HTTP.
I think it is just that I used to take false comfort in it.
Post a Comment