QoS features

[Darko Androsevic]

Hi all,

We would like to understand what petals currently supports and plans to
support in connection to QoS (reliability, transactions, msg
persistence...)
Precisely, which section (if any) of "Chapter15: Use of transaction" of
the JBI specification 1.0 does petals support?

The chapter15 describes some models that are not normative but we think
they are important pieces of any "production" system.
We are aware that JMS_BC does not support transaction and durable
subscriptions (as per Roland's e-mail) which slightly further complicate
things :)

Thanks,
Darko


--
You receive this message as a subscriber of the petals-users@... mailing list.
To unsubscribe: mailto:petals-users-unsubscribe@...
For general help: mailto:sympa@...?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

[Darko Androsevic]

Hi,

I have not got any response so I am just following up on this topic.

How do current petals based production systems resolve issues mentioned
below?
I have noticed that petals July release notes states support for
"Transaction management based on JOTM in Kernel and Component
Development Kit (OK)"
Can someone shed some lights on this feature and potential connections
to the JBI spec?

Thanks,
Darko

-----Original Message-----
From: Darko Androsevic [mailto:dandrosevic@...]
Sent: Tuesday, August 19, 2008 11:35 AM
To: petals-users@...
Subject: [petals-users] QoS features

Hi all,

We would like to understand what petals currently supports and plans to
support in connection to QoS (reliability, transactions, msg
persistence...)
Precisely, which section (if any) of "Chapter15: Use of transaction" of
the JBI specification 1.0 does petals support?

The chapter15 describes some models that are not normative but we think
they are important pieces of any "production" system.
We are aware that JMS_BC does not support transaction and durable
subscriptions (as per Roland's e-mail) which slightly further complicate
things :)

Thanks,
Darko


--
You receive this message as a subscriber of the petals-users@... mailing list.
To unsubscribe: mailto:petals-users-unsubscribe@...
For general help: mailto:sympa@...?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

[Roland Naudin - EBM WebSourcing]

Hello Darko,

Sorry for the delay of the response, but it's holidays time...

The JBI specs mentions transaction in on of its appendix, as one of
technic to provide QoS. It is mentioned briefly others fields, like
persistence, integrity... This appendix illustrates some usecase around
transaction...amongst many others possibilities!

In PEtALs, we have identified several fields to provide QoS;
persistence, loadBalancing, high-avaibility, transaction, security.
The fields are often related each-others, and many possibilities on each
fields.

We have not yet discussed about a global view of QoS (officialy...). I
have started a subject about that on the forum.

Here is my point of view on transaction in PEtALS:

PEtALS provides a transaction manager to
start/enlist/delist/commit/rollback transactions.

There is no pattern to decide when to start and end a transaction during
a flow, but in JBI the transaction is bound the the Message Exchange.
So, PEtALS container content itself to convey the transaction attached
to a given message exchange from a component to another and make no
decision on the life-cycle of transactions.
The components are handling the transaction, and decides to
enlist/start... transactions.

Note that PEtALS can not relay a transaction from a third-part
environment (it cannot relay transaction from JMS message eg), so PEtALS
handles only INTERNAL transaction. The external transaction must be
handled by the BC itself.

I'm thinking of adding a transaction interceptor which can be activated
at any phase of a exchange (accept/send-response/accept-response) to
automatically commit/rollback transaction according to the message
state/faults.

We can add to the EIP component the ability to transmit a transaction
exchange to exchange, and according to the result of the EIP process the
global transaction would be commit or rollbacked.

The JMS component must evolve to handle external transaction.
The XQuare component must evolve to be able to enlist transaction when
providing services.

Any comments are welcome!
/Roland

Le mercredi 27 août 2008 à 10:16 -0700, Darko Androsevic a écrit :

> Hi,
>
> I have not got any response so I am just following up on this topic.
>
> How do current petals based production systems resolve issues mentioned
> below?
> I have noticed that petals July release notes states support for
> "Transaction management based on JOTM in Kernel and Component
> Development Kit (OK)"
> Can someone shed some lights on this feature and potential connections
> to the JBI spec?
>
> Thanks,
> Darko
>
> -----Original Message-----
> From: Darko Androsevic [mailto:dandrosevic@...]
> Sent: Tuesday, August 19, 2008 11:35 AM
> To: petals-users@...
> Subject: [petals-users] QoS features
>
> Hi all,
>
> We would like to understand what petals currently supports and plans to
> support in connection to QoS (reliability, transactions, msg
> persistence...)
> Precisely, which section (if any) of "Chapter15: Use of transaction" of
> the JBI specification 1.0 does petals support?
>
> The chapter15 describes some models that are not normative but we think
> they are important pieces of any "production" system.
> We are aware that JMS_BC does not support transaction and durable
> subscriptions (as per Roland's e-mail) which slightly further complicate
> things :)
>
> Thanks,
> Darko
> pièce jointe document plein texte (message-footer.txt)
> --
> You receive this message as a subscriber of the petals-users@... mailing list.
> To unsubscribe: mailto:petals-users-unsubscribe@...
> For general help: mailto:sympa@...?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws

--

Roland NAUDIN
PEtALS team
EBM Websourcing

Try PEtALS at http://petals.ow2.org




--
You receive this message as a subscriber of the petals-users@... mailing list.
To unsubscribe: mailto:petals-users-unsubscribe@...
For general help: mailto:sympa@...?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

[Darko Androsevic]

Hi Roland,

Thanks for your response. Your thought are really good and I think petals is going into right direction.
Maybe we should create a matrix with various possibilities and describe them.
 
Here is the use case which is important for us (maybe even for anybody else who uses JMS). The JMS-BC shoud be able to receive a "transactional" message from JMS and initiate "ESB" transaction (even XA one). It would then pass the transaction context in the message exchange as you mentioned below. As the exchange passes through the "chain" (in or inout, EIP, BPEL...) the services can perform certain tasks in that same transaction context (or end up in another JMS which could be part of XA). The initial JMS-BC would commit/rollback transaction (XA one) which would force all XA particiapants to commit. The rollback would in turn force a JMS to follow its QoS policies and potentially redeliver message (even with a delay parameter that some JMS support).
 
I think the ability to transmit transaction context from component to component is important one for any component and not just EIP.

BTW, does petals queue and persists internal message exchanges? If it does would't be useful to have ability to initiate transactional async delivery (so in essence mimic JMS in NMR)...

Darko


-----Original Message-----
From: Roland Naudin - EBM WebSourcing [mailto:roland.naudin@...]
Sent: Friday, August 29, 2008 8:15 AM
To: petals-users@...
Subject: [petals-users] Re: RE: QoS features

Hello Darko,

Sorry for the delay of the response, but it's holidays time...

The JBI specs mentions transaction in on of its appendix, as one of technic to provide QoS. It is mentioned briefly others fields, like persistence, integrity... This appendix illustrates some usecase around transaction...amongst many others possibilities!

In PEtALs, we have identified several fields to provide QoS; persistence, loadBalancing, high-avaibility, transaction, security.
The fields are often related each-others, and many possibilities on each fields.

We have not yet discussed about a global view of QoS (officialy...). I have started a subject about that on the forum.

Here is my point of view on transaction in PEtALS:

PEtALS provides a transaction manager to start/enlist/delist/commit/rollback transactions.

There is no pattern to decide when to start and end a transaction during a flow, but in JBI the transaction is bound the the Message Exchange.
So, PEtALS container content itself to convey the transaction attached to a given message exchange from a component to another and make no decision on the life-cycle of transactions.
The components are handling the transaction, and decides to enlist/start... transactions.

Note that PEtALS can not relay a transaction from a third-part environment (it cannot relay transaction from JMS message eg), so PEtALS handles only INTERNAL transaction. The external transaction must be handled by the BC itself.

I'm thinking of adding a transaction interceptor which can be activated at any phase of a exchange (accept/send-response/accept-response) to automatically commit/rollback transaction according to the message state/faults.

We can add to the EIP component the ability to transmit a transaction exchange to exchange, and according to the result of the EIP process the global transaction would be commit or rollbacked.

The JMS component must evolve to handle external transaction.
The XQuare component must evolve to be able to enlist transaction when providing services.

Any comments are welcome!
/Roland

Le mercredi 27 août 2008 à 10:16 -0700, Darko Androsevic a écrit :

> Hi,
>
> I have not got any response so I am just following up on this topic.
>
> How do current petals based production systems resolve issues
> mentioned below?
> I have noticed that petals July release notes states support for
> "Transaction management based on JOTM in Kernel and Component
> Development Kit (OK)"
> Can someone shed some lights on this feature and potential connections
> to the JBI spec?
>
> Thanks,
> Darko
>
> -----Original Message-----
> From: Darko Androsevic [mailto:dandrosevic@...]
> Sent: Tuesday, August 19, 2008 11:35 AM
> To: petals-users@...
> Subject: [petals-users] QoS features
>
> Hi all,
>
> We would like to understand what petals currently supports and plans
> to support in connection to QoS (reliability, transactions, msg
> persistence...)
> Precisely, which section (if any) of "Chapter15: Use of transaction"
> of the JBI specification 1.0 does petals support?
>
> The chapter15 describes some models that are not normative but we
> think they are important pieces of any "production" system.
> We are aware that JMS_BC does not support transaction and durable
> subscriptions (as per Roland's e-mail) which slightly further
> complicate things :)
>
> Thanks,
> Darko
> pièce jointe document plein texte (message-footer.txt)
> --
> You receive this message as a subscriber of the petals-users@... mailing list.
> To unsubscribe: mailto:petals-users-unsubscribe@...
> For general help: mailto:sympa@...?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws

--

Roland NAUDIN
PEtALS team
EBM Websourcing

Try PEtALS at http://petals.ow2.org




--
You receive this message as a subscriber of the petals-users@... mailing list.
To unsubscribe: mailto:petals-users-unsubscribe@...
For general help: mailto:sympa@...?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

[Roland Naudin - EBM WebSourcing]

Hi Darko,

Your use case is exactly illustrating the way to handle an incoming
request from a transacted JMS BC (as consumer of service).

About the ability to transmit transaction, only component offering
services orchestration/chaining of services are concerned about transmit
a transaction from exchanges to exchanges. Others components work with a
unique message exchange to provide/consume their service; thus the
transaction context is already conveyed as it is attached to the message
exchange.

So the concerned components are (for current PEtALS components) the EIP
and orcherstra components.
For orchestra, dealing with transaction is different. Orchestra provides
BPEL support and it is designed to deals with medium/long service
orchestrations(business process). The recommended way to handle
transaction of an these kinds of orchestration is compensation, as using
direct transactions would monopolise to much resources during the BP
lifetime.
So to resume, i think that only EIP component must evolve to handle the
transaction context correctly for certain patterns.

BTW, we have an expert on BPEL if you want more details on that,
nicolas!

PEtALS is currently using JORAM, a JMS provider. It persists message and
we is certainly possible to use JMS transaction session as well.
BUT, as i said in the forum, using persitence or going further with
transaction can be useful only for one way message exchange and
asynchronous invocation.
All others possibilities, two way or synchronous invocation induces that
the consumer is expecting a response which is bound to its invocation
context. If something goes wrong, and we have transaction on the
invocation, the consumer may receive a response whenever and don't know
how to deal with it.


I think the best way to provide a robustness would be to use
high-avaibility feature where if a provider of service is down, others
are solicited until one provide the service demanded.
If none response to the demand, we can think to persist the request
(only if necessary -> in most case onway request and async invocation).
Others evolutions for PEtALS that we are thinking about.

/Roland

Le vendredi 29 août 2008 à 12:04 -0700, Darko Androsevic a écrit :

> Hi Roland,
>
> Thanks for your response. Your thought are really good and I think petals is going into right direction.
> Maybe we should create a matrix with various possibilities and describe them.
>  
> Here is the use case which is important for us (maybe even for anybody else who uses JMS). The JMS-BC shoud be able to receive a "transactional" message from JMS and initiate "ESB" transaction (even XA one). It would then pass the transaction context in the message exchange as you mentioned below. As the exchange passes through the "chain" (in or inout, EIP, BPEL...) the services can perform certain tasks in that same transaction context (or end up in another JMS which could be part of XA). The initial JMS-BC would commit/rollback transaction (XA one) which would force all XA particiapants to commit. The rollback would in turn force a JMS to follow its QoS policies and potentially redeliver message (even with a delay parameter that some JMS support).
>  
> I think the ability to transmit transaction context from component to component is important one for any component and not just EIP.
>
> BTW, does petals queue and persists internal message exchanges? If it does would't be useful to have ability to initiate transactional async delivery (so in essence mimic JMS in NMR)...
>
> Darko
>
>
> -----Original Message-----
> From: Roland Naudin - EBM WebSourcing [mailto:roland.naudin@...]
> Sent: Friday, August 29, 2008 8:15 AM
> To: petals-users@...
> Subject: [petals-users] Re: RE: QoS features
>
> Hello Darko,
>
> Sorry for the delay of the response, but it's holidays time...
>
> The JBI specs mentions transaction in on of its appendix, as one of technic to provide QoS. It is mentioned briefly others fields, like persistence, integrity... This appendix illustrates some usecase around transaction...amongst many others possibilities!
>
> In PEtALs, we have identified several fields to provide QoS; persistence, loadBalancing, high-avaibility, transaction, security.
> The fields are often related each-others, and many possibilities on each fields.
>
> We have not yet discussed about a global view of QoS (officialy...). I have started a subject about that on the forum.
>
> Here is my point of view on transaction in PEtALS:
>
> PEtALS provides a transaction manager to start/enlist/delist/commit/rollback transactions.
>
> There is no pattern to decide when to start and end a transaction during a flow, but in JBI the transaction is bound the the Message Exchange.
> So, PEtALS container content itself to convey the transaction attached to a given message exchange from a component to another and make no decision on the life-cycle of transactions.
> The components are handling the transaction, and decides to enlist/start... transactions.
>
> Note that PEtALS can not relay a transaction from a third-part environment (it cannot relay transaction from JMS message eg), so PEtALS handles only INTERNAL transaction. The external transaction must be handled by the BC itself.
>
> I'm thinking of adding a transaction interceptor which can be activated at any phase of a exchange (accept/send-response/accept-response) to automatically commit/rollback transaction according to the message state/faults.
>
> We can add to the EIP component the ability to transmit a transaction exchange to exchange, and according to the result of the EIP process the global transaction would be commit or rollbacked.
>
> The JMS component must evolve to handle external transaction.
> The XQuare component must evolve to be able to enlist transaction when providing services.
>
> Any comments are welcome!
> /Roland
>
> Le mercredi 27 août 2008 à 10:16 -0700, Darko Androsevic a écrit :
> > Hi,
> >
> > I have not got any response so I am just following up on this topic.
> >
> > How do current petals based production systems resolve issues
> > mentioned below?
> > I have noticed that petals July release notes states support for
> > "Transaction management based on JOTM in Kernel and Component
> > Development Kit (OK)"
> > Can someone shed some lights on this feature and potential connections
> > to the JBI spec?
> >
> > Thanks,
> > Darko
> >
> > -----Original Message-----
> > From: Darko Androsevic [mailto:dandrosevic@...]
> > Sent: Tuesday, August 19, 2008 11:35 AM
> > To: petals-users@...
> > Subject: [petals-users] QoS features
> >
> > Hi all,
> >
> > We would like to understand what petals currently supports and plans
> > to support in connection to QoS (reliability, transactions, msg
> > persistence...)
> > Precisely, which section (if any) of "Chapter15: Use of transaction"
> > of the JBI specification 1.0 does petals support?
> >
> > The chapter15 describes some models that are not normative but we
> > think they are important pieces of any "production" system.
> > We are aware that JMS_BC does not support transaction and durable
> > subscriptions (as per Roland's e-mail) which slightly further
> > complicate things :)
> >
> > Thanks,
> > Darko
> > pièce jointe document plein texte (message-footer.txt)
> > --
> > You receive this message as a subscriber of the petals-users@... mailing list.
> > To unsubscribe: mailto:petals-users-unsubscribe@...
> > For general help: mailto:sympa@...?subject=help
> > OW2 mailing lists service home page: http://www.ow2.org/wws
> --
> Roland NAUDIN
> PEtALS team
> EBM Websourcing
>
> Try PEtALS at http://petals.ow2.org
>
>
> pièce jointe document plein texte (message-footer.txt)
> --
> You receive this message as a subscriber of the petals-users@... mailing list.
> To unsubscribe: mailto:petals-users-unsubscribe@...
> For general help: mailto:sympa@...?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws

--

Roland NAUDIN
PEtALS team
EBM Websourcing

Try PEtALS at http://petals.ow2.org




--
You receive this message as a subscriber of the petals-users@... mailing list.
To unsubscribe: mailto:petals-users-unsubscribe@...
For general help: mailto:sympa@...?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws