[jboss-dev-forums] [Design of JBoss ESB] - JCA's relation to ESB

bill.burke@jboss.com do-not-reply at jboss.com
Tue Apr 17 12:33:15 EDT 2007


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.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038040#4038040

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038040



More information about the jboss-dev-forums mailing list