I'm interested in defining the transaction behaviour of components inside a JBI ESB. Of course for the components to be portable among different JBI container the beahviuor of the component and of the container should be standardized. I feel the JBI specification is not enough on this issue. Basing on my experience with traditional integration brokers I also feel that the implementation choices that servicemix is undergoing could not meet some common transactional scenarios. Therefore I'd like to propose you the following transaction model. It's just a skecth but please evaluate it and let's discuss it.
------------------ A transaction model for jbi esb A transaction model for a jbi esb should define how transaction are handled in a consistent and forecastable way. A transaction model should allow to mix transactional and non transactional components (BC and SE) and should allow to mix them so allowing to create non transactional flows (no component in the flow is transactional or use transaction), partially transactional flow (some component in the flow is transactional and use transaction) and fully transactional flow (every component in the flow is transactional and use transaction). An esb jbi should allow these kind flows to cohexists in the same instance. In my opinion the transaction behaviuor should be configurable with the granularity of the service unit, that is each service unit must be able to specify its transactional behaviour. Before delving into this transactional behaviuor proposal it may be useful to focus on wich are the transactional resources and the transactional operations inside an ESB. A delivery channel should be considered a transactional resource so the act of consuming and of sending a message should be considered transactional operations. Any other traditional transactional resource (like database) used inside a component could potentially participate to the transaction assocated with the service unit execution and so must be taken into account in this discussion. For binding components the act of communicating with an external peer should be considered a transactional operation if the external process and the communication protocol support the concept of transaction. I propose three level of transaction support for a component: 1. none 2. transacted 3. XA transacted 1. in the none transaction behaviour every transactional operation is committed the moment it is executed (autocommit). This is mandatory for the operation done on the delivery channel and for the operations done on external peers. The transactional resources handled by the component may be freely used. So the component may allocate a transaction and commit it when it wants. 2. in the transacted mode the act of consuming a message from delivery channel or from an external peer is transactional. The transaction is open at the beginning of the exchange processing and is committed at the end if and only if the processing does'not end with an error or an unandled exception. A fault is instead considered a normal resutl and thus the transaction is commited. The act of sending message on the delivery channel or to an external peer occurs in autocommit mode and the component is free to handle its internal resource as in the none transaction mode. When sending a message if the message exchange pattern is synchronous and the resource orginating the message is the delivery channel the allocated transaction is propagated to the endpoint cosuming the message so that the consumption occurs in the same transaction. This happens iteratively so that a fully synchronous flow uses one transaction. When the message pattern is asynchronous a new trasaction must be allocated for every act of consuming the message. There sould also be a way to tell the container if these asynchronous messages must be persisted or not. This should be configurable at the sending service unit level. 3. in the XA transacted mode the act of consuming messages from delivery channel and from an external peer is transactional and the allocated transaction is an XA transaction. This is of course possible only if the transactional resources are XA capable. The XA transaction is commited at the end of the message exchenge execution with the same rules of the transacted behaviour. The delivery channel in a JBI BUS should be XA capable since it is implemented by a messaging middleware. Any internal reosurce used by the component must be XA and must be enlisted in the transaction. When sending a message if the MEP is asyncrhonous the operation must be enlisted in the XA transaction. if the MEP is synchronous the act of sending must be in autocommit mode but the the transaction must be propagated to the consuming endpoint. please notice that the transaction semantic is implied by the MEP and not by the API used to send the message on the delivery channel. ------------------- thanks Raffaele [EMAIL PROTECTED]
