[tom.baeyens]

That says Microcontainer could be used as NMS.

i didn't get all of your argumentation, but i came to the exact same conclusion.

in the POJO API, i don't see that we need to differentiate between binding components and service engines. that gives us a Bus and Components.

Microcontainer is oriented towards synchronous invocations, the JBI NMR is oriented towards asynchronous invocations. I believe it must be possible to create a common basis. that is, revise the microcontainer to handle asynchronous invocations. the only thing we need to add for that to the microcontainer is metadata facility.

the metadata is passed with an invocation to the bus. one of the metadata attibutes could be "synchronicity" with possible values: "synchronous", "asynchronous". in case of async, 2 extra attributes can be specified: a Quality of Service attribute with possible values: "best-effort", "transactional", .... and a protocol attribute saying "this is message 2 in protocol REQUEST-RESPONSE_REPLY"

regards, tom.

[ovidiu.feodorov]

I am questioning the benefit of building an asynchronous communication foundation (NMS) within a single JVM when the protocols provide asynchronizity.

This is a justified concern. However, NMR does not necessariy have to behave asynchronously all the time. A Channel (this is what Messaging Core is based on) first tries to synchronously deliver the message to its receivers, if possible, and only if one (ore more) receivers NACK, it stores the message, and this only in the case it was configured to be "asynchronous" and has access to a reliable store. This is currently possible within the Messaging Core, it's actually the default behavior. We need to be, however, careful in this approach, since as you very well metioned, the spec seem to specifically prohibit this kind of behavior.

So you can look at JBI (and not talking about ESB here, in my view ESBs ar e distributed) as a service container that allows you to integrate engines not part of J2EE into your platform in a standard fashion

Yes, this could naturally lead to an architecture where the JBI container is inherently an in-VM construct, the NMR *is* the microcontainer and in order to achieve distribution, we plug in a special service, probably in the form of a BC, that acts as the ESB's peer for that specific JBI container instance.

I can see as easy an alternate architecture where the NMR is distributed by default but mediates synchronous invocations when the services that communicate are colocated . This has the advantage that relieves SE/BC of the worry of dealing with reliability, since reliability support is built into the core.

So I've heard JBI touted as a service container, and I've heard it touted as an ESB. The problem is that these two goals come with very different profiles in terms of distribution, and distribution tends to be a significant factor to take into account in the architecture and implementation.

What if we abstract out distribution? We delegate it to a black box that is going to behave correcty depending of the environment it happens to run in. Synchronously in VM, asynchronously in a distributed configuration. It also provides transactional reliabilty, as a built in feature.

1) We take JBI as an SPI for services that had no "home" in J2EE (e.g. workflow engine with no standardized API vs. transaction manager with a defined JTA). That means there will be significant local traffic, and we can look at NMR as a local entity in physical view (single node) but distributed in logical view (multiple nodes) via BCs.

2) Take JBI as an ESB to integrate processes across IT enterprise, no local "container" view for engines, might as well distribute the whole thing at NMR .

I am biased toward the second direction, with the observation that a distributed core doens't preclude fast, synchronous, in-VM invocations.

Again, I think it depends how you mainly see JBI being used for: integrating service engines locally to your middleware stack, or building vast, distributed integration networks of applications.

Agreed. How do we decide? Should be use the classical "pro/cons" approach? :)

[tom.baeyens]

distribution
is outside the scope of the spec. jbi mainly specifies how components (SE's and BC's) are plugged into the JBI bus. API between component and bus on the one hand. deployment & mgmt on the other hand.

how a vendor realizes distribution is outside the scope of the JBI spec.

synchronicity
the communication between components (via the JBI NMR) is based on the WSDL 2 message exchange patters. afaik this is fundamentally asynchronous messages travelling between the components. the message exchange patterns define the (very simple) protocols between 2 components.

a binding component may simulate a synchronous invocation. e.g. a http-invoker BC. you enter a form and press submit. in the generation of the http-response, the http invoker will start a message exchange with the JBI bus. the http invoker will send a message over the bus. then the http invoker may block the thread until it receives the asynchronous response. that way, the http-invoker simulates a synchronous invocation to its client.

i wonder why JBI puts the burden on the components to manage the threads. my first impression is that the NMR is much better positioned to handle that. each message exchange pattern should define the threading model as part of the NMR.

i just looked where it said that components never share a thread. it is baked in the API. each component MUST be polling the NMR for receiving messages. after i done my doodle i start to understand better what they are doing it the jbi api. seems horrible at first sight :-( hopefully there is some good motivation that i don't see yet.

[transactions]
seems straight forward on how i would handle that. sending messages to the NMR and receiving messages from the NMS should be transactional, just as with JMS. but scanning the sequence diagrams in the spec i'm a bit afraid. i see different threads for beginning and committing transactions :-( this definitely requires some more investigation

regards, tom.

[juha]

I can see as easy an alternate architecture where the NMR is distributed by default but mediates synchronous invocations when the services that communicate are colocated . This has the advantage that relieves SE/BC of the worry of dealing with reliability, since reliability support is built into the core.

To me, it is just delegating the responsibility to the "core" (NMR?). Bottom line is the JBI environment must provide the service to allow recovery. Whether this is in the SE or BC container or in the NMR. If it is in the NMR then it means either BC that is receiving a message or SE that is creating one cannot "hold" on to those messages. For instance, a BC would not be able to acknowledge a message as received until it is pushed to NMR and NMR acknowledges the message is in its queue and persisted. Otherwise recovery would not be possible.

1) We take JBI as an SPI for services that had no "home" in J2EE (e.g. workflow engine with no standardized API vs. transaction manager with a defined JTA). That means there will be significant local traffic, and we can look at NMR as a local entity in physical view (single node) but distributed in logical view (multiple nodes) via BCs.

2) Take JBI as an ESB to integrate processes across IT enterprise, no local "container" view for engines, might as well distribute the whole thing at NMR .

I am biased toward the second direction, with the observation that a distributed core doens't preclude fast, synchronous, in-VM invocations.

Right. At which point the question that comes up is why there is need for two implementations of fast, synchronous, in-VM bus implementations?

If the Messaging Core is capable of equal performance to MicroContainer bus, should it then be placed as the bus for the MicroContainer?

Or, if the MicroContainer already has a fast in-JVM synchronous bus, could it then be extended to include asynchronous messaging model (Tom's question)?

Again, I think it depends how you mainly see JBI being used for: integrating service engines locally to your middleware stack, or building vast, distributed integration networks of applications.

Agreed. How do we decide? Should be use the classical "pro/cons" approach? :)

Personally, I see JBI as a specification to define SOA. Reading Tom's latest comment, the emphasis there is on plugging in components and enabling a communication channel between them. In addition some deployment and management features. Service Oriented Architecture. The specification today is explicit in not defining distribution, message transformations (?), or workflow/orchestration oriented features.

I'd define ESB as a distributed SOA with additional services such as B2B message translations (EDI <--> XML, etc.), workflow, orchestration. What exactly those additional services would be is up to the vendor though, since there is no specification that defines ESB today. ESB can certainly be build out of JBI environment nodes, which distribution added to the bus via BCs and the additional services like jBPM plugged in via SE wrappers. That's how I would do it, since it provides a standard way for 3rd parties to join the ESB via the SOA architecture defined by JBI.

[adrian.brock]

There is an overloaded acronym here
MC -> MicroContainer (I'll use this one :-)
MC -> Messaging Core

Right. At which point the question that comes up is why there is need for two implementations of fast, synchronous, in-VM bus implementations?

If the Messaging Core is capable of equal performance to MicroContainer bus, should it then be placed as the bus for the MicroContainer?

The MicroContainer Bus is just a switching mechanism
name -> object reference (which can be aspectized to have a "container")

The Messaging Core is a "container" implementation for message routing which could be
remote/local, synchronous/asynchronous, reliable/unreliable, etc.

The Message Core only becomes a bus when you put a broker in front of it
e.g. for the jms facade, create channels that implement queues/topics and add them to the destination manager.
Other brokers/buses are equally possible as front ends (including the MC bus),
in the same way as you can have a byte code engineered class, a dynamic proxy
or some other front end to an AOP aspect chain.

The "container" could equally be an aspectized POJO with an enhanced version
of the asynchronous/remoting aspects (e.g. add reliablity).

You shouldn't confuse the two responsibilites:
1) Dispatch based on a name/indirection (the bus)
2) The method/aspects of the dispatch (the container)

[adrian.brock]

[transactions]
seems straight forward on how i would handle that. sending messages to the NMR and receiving messages from the NMS should be transactional, just as with JMS. but scanning the sequence diagrams in the spec i'm a bit afraid. i see different threads for beginning and committing transactions :-( this definitely requires some more investigation

This does not look like JMS semantics to me.

In JMS, it is the send that is transactional. i.e. until the commit, the receiver does not
get the message.

In JBI, the sender/initiator is handing over control of the transaction to the receiver/servicer
with what looks like a protocol to ensure that both are not in control at the same time.
It does say, that it is only anticpated to be used locally (no DTM for now...).

So JBI is performing a fundamentally synchronous protocol even if it done across
threads using "lock step".

[ovidiu.feodorov]

For instance, a BC would not be able to acknowledge a message as received until it is pushed to NMR and NMR acknowledges the message is in its queue and persisted. Otherwise recovery would not be possible.

Correct. But SE shares a thread with the application it acts as container for and BC is based on a synchronous protocol. If the component receives a positive acknowledgment from the NMR, everything is fine, if not it propagates the error back to the caller, either as an exception or an error code.

[ovidiu.feodorov]

The Message Core only becomes a bus when you put a broker in front of it e.g. for the jms facade, create channels that implement queues/topics and add them to the destination manager.

For a JMS system, routing is external. The producer must decide what destination to use, so it uses the "broker" to mediate the transport of that message to the destination's receivers, by passing the message and the destination to the broker. A service plugged into an ESB shouldn't have to do this. It should simply pass the message to the bus and the bus should route the message to its destination based on arbitrary rules, most likely involving the abstract destination service definition or other message metadata.