Monday, January 23, 2006

Outstanding questions regarding BPEL and ESB

James McGovern has some excellent questions on his blog.

I could write pages on some of the questions but I thought I'd limit myself to just two for now.

"When should one use BPM with an ESB?"

I think this question probably reflects the multiple inconsistent definitions used by all the vendors and analysts out there. In my view of the world, the ESB is the construct that says to the world: "You need to send some information to an application? You need to invoke an application? I'm the man. Send the request to me - in the way that makes most sense to you - and I'll take care of making it happen, in the way that makes most sense to the target application".

So, by this 'definition' it exposes services deployed in the enterprise in a way that is independent of how the services are actually implemented and it does it in both synchronous and asynchronous cases.

By contrast, BPM is the orchestration layer that sits above this. This is the layer that says: "Great! All the enterprise services I may ever need to invoke are all easily accessible via the bus. Now I can deliver some extra business value by wiring some of them together to automate a business process. I'll involve a few humans here and I'll emit monitoring information there and the result will be an end-to-end automated business process."

Now, a particular vendor's product my conflate the two worlds but, at an architectural level, they are very different.

ESB is about exposing services

BPM is about chaining them together (and more... true BPM involves people)

ESB is worried about technical details

BPM is worried about business process, key performance indicators and monitoring.

So, I would argue one implicitly uses an ESB whenever one is doing BPM.


"What's the difference between Interoperability and Integration?"

Excellent question. I agree with James that there is a difference but until now, I, too, had never tried to articulate what it was.

Here's my first stab (and I stress that this is a first pass.... I'm not totally happy with it)

If two systems are interoperable, we mean that they are capable of working together. Consider SAP: two SAP systems are interoperable.

However, two systems being capable of working together is merely a statement of fact. It says nothing about how you do it.

Two SAP systems can be integrated by configuring them to fire IDOCS at each other (or in one of all the other possible ways). Moreover, to achieve true integration, you may require the assistance of some extra technology (home-grown code, an EAI product, an ESB, whatever).

So: I would say that interoperability is a statement of the possible. Integration is how you do it.

4 comments:

James McGovern said...

Actually I have heard different definitions that state the following:

Integration is something done within an application (aka glueing components together) whereas interoperability occurs outside.

The key point though is not whether this definition even makes sense (of course I never like my own thoughts and will usually disclaim them in the future) but what others in the industry believe.

This could turn into a separate blog entry. Maybe you could create it and ask for others to chime in...

Richard Brown said...

Done: http://gendal.blogspot.com/2006/01/what-is-difference-between.html

James Governor said...

god i hate this stuff.

ESB is not about exposing services is it, but orchestrating and routing them?

re interop i am with james.

interop means a translation is used to allow two services to speak to one another (loosely coupled)

integration is where two services are bound together (tightly coupled).

Richard Brown said...

"god i hate this stuff. "

Esoteric debates or the integration space?!

On ESB:

My view is that the ESB is the thing that allows an application to say: "I want to invoke this service". The ESB is reponsible for understanding the request, routing it to the appropriate system to fulfil it and returning the reponse.

In other words, it's the thing that intermediates requesters and providers. In many cases, it may be a passthru. In other cases it may be a protocol transformation, complex routing or, perhaps, an orchestration... but we need to be clear what we're talking about here. The orchestration would be a simple composition of services to create the illusion of a composite whole.

This orchestration is a technical thing, necessary to fulfil the request.

It is emphatically not a business process.

A business process, which may include the participation of multiple people and logical services, sits above this layer.