Andi Egloff's Weblog

Inside JBI part I: Clarifying Lifecycles

In this series I would like to give some insights into gotchas and topics that are not immediately obvious when reading the JBI 1.0 (JSR 208) specification. I'm very lucky that I can bug the spec leads Peter and Ron - and architects and leads like Keith Babo and Mark White who work on the RI and project OpenESB when I want to get some background information on JBI. I'd like to pass on some of this information that I have acquired in the last couple of years.

When stop isn't equals stop

In JBI the components and the service unit (SU) deployments both have their own lifecycle - and in just skimming the spec one might easily presume that stop in both has the same implications. It turns out, the service unit stop might be better described as "stop consuming" - that is right, after a SU stop it can still be provisioning services, it just isn't initiating new requests.

This is different than the component "stop", which means that the whole component should stop provisioning AND consuming services.

Here is another item to be aware of: the specification does not perscribe the interaction between the component and the SU lifecycles. The RI (and project OpenESB) does call the equivalently named lifecyle operation on all SUs when the component lifecycle operations are called (e.g. stop on all SUs when the component stop is called), but that is not explicit in the specification.

When implementing the component stop, you may come accross another interesting feature of the delivery channel: there is no way to re-start message delivery once it is closed, and we only get a new delivery channel in the component initialization.

This means you can not use the delivery channel close to implement the component stop: if the user does a stop and subsequent start you could not re-start delivery on this delivery channel, the user would have to completely shutdown the component first. This makes for an interresting time in implementing the component stop; none of these options are optimal and includes approches such as interrupting the deliverychannel or using the accept on the delivery channel with a regular time-out.

With this in mind, here is my wish-list for enhancements I would like to see in future specs:

• SU stop may benefit from a different name that makes it clear that only service consumption is stopped


• That the specification would explicitly declare the relationship between the component and SU lifecycle


• That the delivery channel would have a way to stop and re-start message delivery - separate from the ultimate shutdown

Tags: jbi esb openesb soa

Posted at 11:18PM Jan 04, 2007 by Andreas Egloff in SOA  |  Comments[2]