There are two transaction models in JBI I know about: * the one from ServiceMix 3 * the one from OpenESB The JBI 2.0 spec will certainly include support for transactions, and it may be the OpenESB model...
ServiceMix 3 model makes a difference between an exchange that is sent synchronously and an exchange sent asynchronously. When the exchange is sent asynchronously, the transaction will not be conveyed, rather the sending of the exchange will be enlisted in the transaction. This means that the NMR has to be transactional, which is what the JCA flow provides in SMX3. The OpenESB model does not make any difference and the transaction is conveyed whether the exchange is sent synchronously or asynchronously. The JCA flow in ServiceMix has several drawbacks: * no easy control over the JMS settings used * no control over the number of messages pushed into the bus (throttling / concurrent consumers) * no control over transaction rollback: all exceptions will be sent back as ERROR status These limitations usually lead me to not use the JCA flow and rather use a JMS endpoint if needed to provide persistence and HA. This is what is done in the following schema for example (http://people.apache.org/~gnodet/full-async.png) where a JMS queue is put after the HTTP request so that the message is persisted. Then, the JMS consumer is configured to be transacted and synchronous. That way, I have full control over the JMS parameters, including the number of concurrent consumers, etc... I'm thus thinking that we may want to not backport the JCA flow feature and adopt the OpenESB model. This would also allow us to change the JMS BC to be able to control the number of concurrent messages put in the bus, while not having all the threads blocked (by having a single consumer and count the number of exchanges sent in the bus and not terminated). I'm not sure how we could do that while keeping compatibility in the components. Most of the work related to transactions is done in servicemix-common, so that should be possible to modify it and be able to support both modes. If we can't support both, this means that we would have two copies of all the components, which would seem a bad idea imho (though it would be a good oportunity to get rid of all the deprecated stuff). This also leads me to two other points: * should we enhance servicemix-common so that we can actually get rid of the jbi packaging in smx4 as an option (just deploy an xml file containing the endpoint definition should work) * should we extract the components from servicemix 3 in a subproject that would be used by both smx3 and smx4 ? As I said, the last point is only valid if we can support the new transaction model (if we choose it) and the enhancements of the first point while still being backward compatible. -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
