JCA's relation to ESB

[bill.burke]

Please tell me if I'm on the right track....

My question is, how is ESB different than JCA? What are its value adds?

Use Case #1: ESB is interacting with ESB-unaware message producers and consumers.

In this case, where the ESB is sitting between two ESB-unaware clients, I don't think ESB provides any value (unless its doing some JBPM or Drools stuff) beyond JCA+MDB (inflow) and JCA outflow. I do see a benefit in the actions working with a generic, unifying Message interface though.

Use Case #2: ESB interacting with ESB aware message producers and consumers.

In this case, ESB's messaging abstraction shines. The client is not aware of the protocol, or even underlying API the message is being published with.

The thing I worry about Use Case #2 is when JMS is involved. The JMS API is always going to be richer and more flexible than any all-in-one universal ESB messaging API. Most of this richness can be hidden as attributes in the EPR (security, persistence, priority), but things like transacted delivery cannot (I guess this could be added to the ESB api).

So ESB advantages:

* Actions work with a unified Message interface. (Although I do think Seam integration will make this a bit mute).
* Clients work with a unified abstract Messaging interface that is protocol unaware.

BTW, I'm doing this to figure out in my mind why you guys do what you do. Why do you need a registry? So that clients can get at EPRs. Why do you have EPRs? So that clients have a protocol independent abstraction.

[weston.price]

My question is, how is ESB different than JCA? What are its value adds?

JCA is an 'enabling' technology, not a platform in and of itself. An ESB, as I understand it, provides a higher set of services (ie routing, rules, transformations etc). Again, I could be wrong on this being that the definition of an ESB is a bit hard to pin down.

Use Case #1: ESB is interacting with ESB-unaware message producers and consumers.

In this case, where the ESB is sitting between two ESB-unaware clients, I don't think ESB provides any value (unless its doing some JBPM or Drools stuff) beyond JCA+MDB (inflow) and JCA outflow. I do see a benefit in the actions working with a generic, unifying Message interface though.

JCA just provides the mechanism for inflow and outflow it 'enables' a node to receive and send, what should be (again just my opinion) a generic message format. In the use case you mentioned, the ESB would be have to do *something* right?

The thing I worry about Use Case #2 is when JMS is involved. The JMS API is always going to be richer and more flexible than any all-in-one universal ESB messaging API.

Why? JMS is JMS. Are you saying is that all ESB related messaging semantics and characteristics should be able to be mappend onto JMS? Or again, am I completely missing something?

It was my understanding that in an ESB, regardless of messaging type or technology (ie JMS) has to go through some form of central authority managed by the ESB. To do this you need some internal representation of the message. If you choose JMS, are you basically saying that the ESB is JMS dependent at that point, regardless of client type. I thought that JMS was simply a transport/messaging format (one of many) that the ESB will support.

So ESB advantages:

* Actions work with a unified Message interface. (Although I do think Seam integration will make this a bit mute).
* Clients work with a unified abstract Messaging interface that is protocol unaware.

Yep, this more lin line with how I thought of an ESB. JCA simply provides the 'glue' to accomplish this from node to node.

[tfennelly]

Yep, the ESB allows you to plug in logic between your inflow and outflow(s) e.g. split the message and route each of them to multiple outbound routers (outflows), transforming the message payload differently for each destination etc. Basically, do whatever it takes to make a message produced at A consumable at B, without having to modify A or B (i.e. develop point-to-point solutions). JCA can handle the transport end of this only, right?

[kconner]

JCA is an 'enabling' technology, not a platform in and of itself. An ESB, as I understand it, provides a higher set of services (ie routing, rules, transformations etc). Again, I could be wrong on this being that the definition of an ESB is a bit hard to pin down.

Yes, JCA is another mechanism to enable the inflow/outflow of messages albeit an extremely useful one ;-). It is the ESB's responsibility to handle the routing of messages to other services.

JMS is just another transport mechanism which could be used in the routing of the messages.

At present the code exposes too much of the transport details to the busines logic but this will change in 5.

[weston.price]

Well, it *should* handle the transport end only. The adapter itself is really just a conduit. The 'brains' is in the ESB itself.

Think of JCA (and Remoting for that matter) as being the device driver framework of the ESB world with the ESB itself being the PCI-E bus/CPU etc.

[marklittle]

As Weston pointed out, there's 1001 definitions of what an ESB is, depending on your perspective. http://isp.webopedia.com/TERM/E/ESB.html is fairly typical, as is http://en.wikipedia.org/wiki/Enterprise_service_bus. Some bundle orchestration, application servers etc. as part of the ESB. The definition we've been working towards is that the ESB is concerned with message routing and service/transport plugins: all of the capabilities you've expect from a "classic" ESB can be cast in those terms. Very similar to Weston's the PCI/CPU bus analogy.

[marklittle]

Kind of screwed those links ;-)

http://isp.webopedia.com/TERM/E/ESB.html

and

http://en.wikipedia.org/wiki/Enterprise_service_bus

[steventechy]

thanks for the unscrewed links Mark Little