More on ESBs and the Last Mile…

I’ve been following the thread that Mike blogged and a comment from Paul H on Steve’s original post stated:

Thereâ??s something in the middle and nobody can agree on what to call it â?¦ is it an â??ESBâ?? is it â??REST + Dynamic Languagesâ?? â?¦ I canâ??t help but think that these same type of arguments arose during the infancy of data comms (should I use a Cisco â??switchâ? or a Novell â??switchâ?? is a â??switchâ? really necessary, or can I get away with PPP?) â?¦ nowadays, the thing in the middle is colloquially referred to as â??The Networkâ?, and switches/routers/etc. are the generally accepted, standardized, manageable, and self-federating mediation technologies â?¦ I look forward to the day when weâ??re in a similar stage of maturity at the level of EAI – a day when thereâ??s a colloquial name for the thing in the middle (â?The Interop Networkâ??) and there exists generally accepted, standardized, manageable, and self-federating mediation technologies â?¦ until then, weâ??ll all have to suffer through endless arguments along the lines of â??should I use a BEA ESB or a Sonic ESB? is an ESB really necessary, or can I get away with REST + Dynamic Languages?â?

Boy, can I relate! I’ve been struggling with this for a long time….

I hope Paul reads this because here’s the name he’s looking for:SnapLogic.

Blatant self promotion aside, the point he raises is a good one. A really good one. One we’ve wrestled with here at SnapLogic from the very beginning.

We started calling it a “Data Integration Network”, which I still like, but it doesn’t describe what it actually does, and that’s kind of a problem is your objective is to come up with a name that is descriptive and informative.

Mike talks about ESBs being like multi-protocol routers, and the important point that ESBs are only part of the overall integration infrastructure.

I think it’s useful to extend the networking metaphor further by recognizing that there are in fact distinct classes of routers. Some targeted at the Core of the network, while others are for the Edge. No one would put an Edge router in the Core, or vise versa. Very little confusion exists because Core routers do different things than Edge routers, but you need them both for the network to run.

But that doesn’t mean that everyone needs both. I don’t need a Core router, but I sure as heck need an Edge router. Conversely, AT&T might have entire divisions that don’t have any Edge routers.

So why should everyone need an ESB? They don’t. That’s because an ESB is like the Core router. Great for certain things like low latency, high throughput, but don’t try updating the BGP tables without departmental sign off.

Perhaps not the best choice for the Agile Enterprise.

Likewise, REST + Dynamic languages are great for Edge integrations where you’ve got to quickly (i.e. time to deployment) get data out of the Core, groom it, massage it, and get out to the edge. Where ever that may be, a file, a departmental database, a browser, website, pretty much anything in the Last Mile.

From now on I’m going to call REST + Dynamic language style integrations, Edge Integrations

What do you think?

Subscribe to Blog Updates

Quickly connect apps, data, and devices

Start Free Trial
Contact Us Free Trial