On 12/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
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.
Yeah, I agree.
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.
What kind of scenarios can not be handled ? While the transaction model in servicemix is not controlled by the MEP of the exchange, but by the synchronous / asynchronous sending of the exchange, it can handle all the possible use cases afaik (though it only handle XA transactions).
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).
Agreed.
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.
Or on an endpoint level. Of course both would match if the SU contains a single endpoint. The declaration of these metadata on the SU would allow the use of the SU jbi descriptor. But I doubt it can be completely handled by the container itself, and I guess the components will need to change its behavior depending on these metadata. So it would not be portable across containers and components, unless they all agree on the same spec.
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.
Agreed
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.
You are talking about jms transactions, jdbc transactions without xa, right ? If you start a jms transaction when consuming a jms message and send it asynchronously in the NMR, you want both to be transacted, else you will have a point of failure: the only way to do that is to use XA. So I think this use case only works when the message is send synchronously in the NMR. For the persistence point, this can already be controlled, but I agree we need to be able to define it on the SU / endpoint 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.
This is the main point I don't understand. Let's take the use case of a service engine that needs to send an InOnly mep to a given service and an InOut mep to another one. If you want the whole thing to be transactional, you need to call a sendSync on the InOnly (and have the transaction conveyed) so that you can receive the ERROR status (if any) and rollback the transaction if needed. So you may want to send an InOnly mep synchronously or send an InOut mep asynchronously. On the other side, if the delivery channel is xa-enabled, you will never be able to use sendSync on it. I know that ServiceMix transactional model can be improved on the configuration side, and that it involves for a given component to be able to use both asynchronous and synchronous model, but I don't see how your proposal would enhance the possible use cases covered, as it is the opposite in my mind. Comments ?
------------------- thanks Raffaele [EMAIL PROTECTED]
-- Cheers, Guillaume Nodet
