You are viewing a plain text version of this content. The canonical link for it is here.
Posted to sandesha-dev@ws.apache.org by Paul Fremantle <pz...@gmail.com> on 2007/03/16 11:38:15 UTC
Re: protocol conversion from HTTP to JMS
Gerald
Interesting. Thanks for testing this!
There are two ways we can work this. One expects Synapse to have a
resilient store and transactions, the other expects us to simply
bridge the transactions from different systems.
The first approach is that Sandesha stores the message in a persistent
store when it arrives. Then it attempts to deliver the message. It
should only unpersist the message from the store when that "delivery"
works. In your case the attempt to send on with cause an exception and
we should roll back the delete from the store. This means that we need
the Sandesha delivery thread to start a transaction, and Synapse to
mark the transaction as failed.
To make this really work, we need some kind of smart retry handling.
In other words, we don't want to retry endlessly to that endpoint. We
need to backoff exponentially and also have a max retry count. In case
we hit the max retry - what should the behaviour be? Should we keep
accepting incoming messages and storing them?
The second approach requires more changes to Sandesha. In this model
we don't ack to the client until JMS acks to us. In other words we
don't need to store the messages persistently - we simply bridge JMS
acks back to the client. This is a neater solution in one way. We
still need a persistent store for the RM sequence information, but
that is pretty small (one row per open sequence). So this model is
much more suitable for a router or gateway that might be in the DMZ
and have a limited storage.
Paul
On 3/16/07, Gerald Loeffler <ge...@googlemail.com> wrote:
> hi all,
>
> further to this, i see the following behaviour:
>
> after the proxy received an SOAP/HTTP message containing WS-RM headers
> from the client, it acknowledges the receipt of that message to
> Sandesha. The proxy then attempts to send the message over the JMS
> endpoint. If that endpoint is down, however, an exception is triggered
> and the proxy basically drops the message. Since the message has
> already been acknowledged to the client, the client will not try to
> re-send it.
>
> now this begs the obvious questions:
> - how can i configure acknowledgement behaviour of a proxy? can i
> get the proxy to only acknowledge the message receipt to Sandesha
> after sending it on?
> - is there any concept of transactions in Synapse? could the
> combination of message accept/send described above be executed within
> one transaction (e.g. by connecting to a configurable transaction
> manager and have the Synapse proxy to the begin/commit/rollback with
> that transaction manager?)
>
> cheers,
> gerald
>
>
> On 12/03/07, Paul Fremantle <pz...@gmail.com> wrote:
> > Gerald
> >
> > Sure.
> >
> > Are you using 0.91 or the latest build?
> >
> > In 0.91 you need to do this:
> > <proxies>
> > <proxy name="RMProxy" transports="http" description="A simple RM
> > endpoint">
> > <target endpoint="jmsEndpoint"/>
> > <enableRM/>
> > </proxy>
> > </proxies>
> >
> > <definitions>
> > <endpoint name="jmsEndpoint" address="jms://localhost:blah"
> > force="pox"/>
> > </definitions>
> >
> > Its been updated in the latest trunk.
> >
> > Paul
> >
> > On 3/12/07, Gerald Loeffler <ge...@googlemail.com> wrote:
> > > Paul,
> > >
> > > On 12/03/07, Paul Fremantle <pz...@gmail.com> wrote:
> > > > I think in general it is more likely that you would use one way flows
> > > > between HTTP and JMS, or use SOAP together with RM. Otherwise it seems
> > > > to me that the HTTP might well timeout and without RM you cannot
> > > > resend the response after the client has timed out.
> > >
> > > I agree. Can i use WSRM guaranteed/exactly-once delivery on one-way
> > > SOAP messages? This would allow me to
> > > 1. reliably send a message via a one-way SOAP/HTTP request from the
> > > client to synapse,
> > > 2. then have synapse put the message onto a JMS queue
> > > - without either synapse or the client waiting for the message to
> > > actually be consumed from the JMS queue.
> > >
> > > cheers,
> > > gerald
> > >
> > > >
> > > > Paul
> > > >
> > > > On 3/12/07, Asankha C. Perera <as...@wso2.com> wrote:
> > > > > Hi Gerald
> > > > > > i understand the message flow in sample 111 as follows:
> > > > > > 1. client sends SOAP/HTTP request for the getQuote operation to the
> > > > > > synapse proxy. This is an in-out operation and the client actually
> > > > > > waits synchronously for the response.
> > > > > > 2. the synapse proxy accepts this request message and routes it to
> > > > > > SimpleStockQuoteService via JMS by posting a JMS message on the
> > > > > > SimpleStockQuoteService queue.
> > > > > > 3. the SimpleStockQuoteService accepts the request and replies
> > > > > > synchronously with a response. But where is that reponse sent to?
> > > > > When the request to the service was sent over JMS, Synapse created a
> > > > > temporary Queue for the response message and awaits for it by blocking
> > > > > > Since this service is invoked through JMS in this scenario, i would
> > > > > > expect the response message to be sent to a JMS queue - but where is
> > > > > > that queue configured?
> > > > > > 4. assuming that the reponse message was put on a JMS queue, synapse
> > > > > > must now listen on that queue. This is for the out-rule of synapse. I
> > > > > > don't see how/where i could tell synapse to listen on a particular JMS
> > > > > > queue for response messages from a service.
> > > > > > 5. assuming that the response message was received by synapse from
> > > > > > that JMS queue, the synapse proxy then puts that message into the
> > > > > > SOAP/HTTP response for the initial SOAP/HTTP request
> > > > > > 6. client receives the SOAP/HTTP response for his initial request
> > > > > > (synchronously, in this example).
> > > > > Yep, the rest is all correct and indeed works! On a separate note, the
> > > > > JMS destinations for responses have been discussed on the Axis2 lists
> > > > > recently and some JIRAs are pending for some enhancements. The current
> > > > > version of the JMS transport is the first cut implementation and now its
> > > > > time to enhance it to cater to scenarios such as this
> > > > > > there seems to be a missing link here somewhere that handles the
> > > > > > translation from *one* request/response pair in SOAP/HTTP to *two*
> > > > > > queues (input and output) for the JMS transport. The root problem is
> > > > > > that the SOAP operation invoked by the client is an in-out operation.
> > > > > > I could imagine that the synapse proxy needs to inserts a WSA reply-to
> > > > > > header with a JMS-address before sending the request to the
> > > > > > SimpleStockQuoteService...
> > > > > >
> > > > > > please help me solve this mystery! ;-)
> > > > > >
> > > > > > kind regards,
> > > > > > gerald
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Paul Fremantle
> > > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > > >
> > > > http://bloglines.com/blog/paulfremantle
> > > > paul@wso2.com
> > > >
> > > > "Oxygenating the Web Service Platform", www.wso2.com
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > http://www.gerald-loeffler.net
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >
> > http://bloglines.com/blog/paulfremantle
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-user-help@ws.apache.org
> >
> >
>
>
> --
> http://www.gerald-loeffler.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-user-help@ws.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: protocol conversion from HTTP to JMS
Posted by Paul Fremantle <pz...@gmail.com>.
PS can you please raise a JIRA?
Paul
On 3/16/07, Paul Fremantle <pz...@gmail.com> wrote:
> Gerald
>
> Interesting. Thanks for testing this!
>
> There are two ways we can work this. One expects Synapse to have a
> resilient store and transactions, the other expects us to simply
> bridge the transactions from different systems.
>
> The first approach is that Sandesha stores the message in a persistent
> store when it arrives. Then it attempts to deliver the message. It
> should only unpersist the message from the store when that "delivery"
> works. In your case the attempt to send on with cause an exception and
> we should roll back the delete from the store. This means that we need
> the Sandesha delivery thread to start a transaction, and Synapse to
> mark the transaction as failed.
>
> To make this really work, we need some kind of smart retry handling.
> In other words, we don't want to retry endlessly to that endpoint. We
> need to backoff exponentially and also have a max retry count. In case
> we hit the max retry - what should the behaviour be? Should we keep
> accepting incoming messages and storing them?
>
> The second approach requires more changes to Sandesha. In this model
> we don't ack to the client until JMS acks to us. In other words we
> don't need to store the messages persistently - we simply bridge JMS
> acks back to the client. This is a neater solution in one way. We
> still need a persistent store for the RM sequence information, but
> that is pretty small (one row per open sequence). So this model is
> much more suitable for a router or gateway that might be in the DMZ
> and have a limited storage.
>
> Paul
>
>
> On 3/16/07, Gerald Loeffler <ge...@googlemail.com> wrote:
> > hi all,
> >
> > further to this, i see the following behaviour:
> >
> > after the proxy received an SOAP/HTTP message containing WS-RM headers
> > from the client, it acknowledges the receipt of that message to
> > Sandesha. The proxy then attempts to send the message over the JMS
> > endpoint. If that endpoint is down, however, an exception is triggered
> > and the proxy basically drops the message. Since the message has
> > already been acknowledged to the client, the client will not try to
> > re-send it.
> >
> > now this begs the obvious questions:
> > - how can i configure acknowledgement behaviour of a proxy? can i
> > get the proxy to only acknowledge the message receipt to Sandesha
> > after sending it on?
> > - is there any concept of transactions in Synapse? could the
> > combination of message accept/send described above be executed within
> > one transaction (e.g. by connecting to a configurable transaction
> > manager and have the Synapse proxy to the begin/commit/rollback with
> > that transaction manager?)
> >
> > cheers,
> > gerald
> >
> >
> > On 12/03/07, Paul Fremantle <pz...@gmail.com> wrote:
> > > Gerald
> > >
> > > Sure.
> > >
> > > Are you using 0.91 or the latest build?
> > >
> > > In 0.91 you need to do this:
> > > <proxies>
> > > <proxy name="RMProxy" transports="http" description="A simple RM
> > > endpoint">
> > > <target endpoint="jmsEndpoint"/>
> > > <enableRM/>
> > > </proxy>
> > > </proxies>
> > >
> > > <definitions>
> > > <endpoint name="jmsEndpoint" address="jms://localhost:blah"
> > > force="pox"/>
> > > </definitions>
> > >
> > > Its been updated in the latest trunk.
> > >
> > > Paul
> > >
> > > On 3/12/07, Gerald Loeffler <ge...@googlemail.com> wrote:
> > > > Paul,
> > > >
> > > > On 12/03/07, Paul Fremantle <pz...@gmail.com> wrote:
> > > > > I think in general it is more likely that you would use one way flows
> > > > > between HTTP and JMS, or use SOAP together with RM. Otherwise it seems
> > > > > to me that the HTTP might well timeout and without RM you cannot
> > > > > resend the response after the client has timed out.
> > > >
> > > > I agree. Can i use WSRM guaranteed/exactly-once delivery on one-way
> > > > SOAP messages? This would allow me to
> > > > 1. reliably send a message via a one-way SOAP/HTTP request from the
> > > > client to synapse,
> > > > 2. then have synapse put the message onto a JMS queue
> > > > - without either synapse or the client waiting for the message to
> > > > actually be consumed from the JMS queue.
> > > >
> > > > cheers,
> > > > gerald
> > > >
> > > > >
> > > > > Paul
> > > > >
> > > > > On 3/12/07, Asankha C. Perera <as...@wso2.com> wrote:
> > > > > > Hi Gerald
> > > > > > > i understand the message flow in sample 111 as follows:
> > > > > > > 1. client sends SOAP/HTTP request for the getQuote operation to the
> > > > > > > synapse proxy. This is an in-out operation and the client actually
> > > > > > > waits synchronously for the response.
> > > > > > > 2. the synapse proxy accepts this request message and routes it to
> > > > > > > SimpleStockQuoteService via JMS by posting a JMS message on the
> > > > > > > SimpleStockQuoteService queue.
> > > > > > > 3. the SimpleStockQuoteService accepts the request and replies
> > > > > > > synchronously with a response. But where is that reponse sent to?
> > > > > > When the request to the service was sent over JMS, Synapse created a
> > > > > > temporary Queue for the response message and awaits for it by blocking
> > > > > > > Since this service is invoked through JMS in this scenario, i would
> > > > > > > expect the response message to be sent to a JMS queue - but where is
> > > > > > > that queue configured?
> > > > > > > 4. assuming that the reponse message was put on a JMS queue, synapse
> > > > > > > must now listen on that queue. This is for the out-rule of synapse. I
> > > > > > > don't see how/where i could tell synapse to listen on a particular JMS
> > > > > > > queue for response messages from a service.
> > > > > > > 5. assuming that the response message was received by synapse from
> > > > > > > that JMS queue, the synapse proxy then puts that message into the
> > > > > > > SOAP/HTTP response for the initial SOAP/HTTP request
> > > > > > > 6. client receives the SOAP/HTTP response for his initial request
> > > > > > > (synchronously, in this example).
> > > > > > Yep, the rest is all correct and indeed works! On a separate note, the
> > > > > > JMS destinations for responses have been discussed on the Axis2 lists
> > > > > > recently and some JIRAs are pending for some enhancements. The current
> > > > > > version of the JMS transport is the first cut implementation and now its
> > > > > > time to enhance it to cater to scenarios such as this
> > > > > > > there seems to be a missing link here somewhere that handles the
> > > > > > > translation from *one* request/response pair in SOAP/HTTP to *two*
> > > > > > > queues (input and output) for the JMS transport. The root problem is
> > > > > > > that the SOAP operation invoked by the client is an in-out operation.
> > > > > > > I could imagine that the synapse proxy needs to inserts a WSA reply-to
> > > > > > > header with a JMS-address before sending the request to the
> > > > > > > SimpleStockQuoteService...
> > > > > > >
> > > > > > > please help me solve this mystery! ;-)
> > > > > > >
> > > > > > > kind regards,
> > > > > > > gerald
> > > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Paul Fremantle
> > > > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > > > >
> > > > > http://bloglines.com/blog/paulfremantle
> > > > > paul@wso2.com
> > > > >
> > > > > "Oxygenating the Web Service Platform", www.wso2.com
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > http://www.gerald-loeffler.net
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Paul Fremantle
> > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > >
> > > http://bloglines.com/blog/paulfremantle
> > > paul@wso2.com
> > >
> > > "Oxygenating the Web Service Platform", www.wso2.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > http://www.gerald-loeffler.net
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-user-help@ws.apache.org
> >
> >
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-user-help@ws.apache.org
Re: protocol conversion from HTTP to JMS
Posted by Paul Fremantle <pz...@gmail.com>.
PS can you please raise a JIRA?
Paul
On 3/16/07, Paul Fremantle <pz...@gmail.com> wrote:
> Gerald
>
> Interesting. Thanks for testing this!
>
> There are two ways we can work this. One expects Synapse to have a
> resilient store and transactions, the other expects us to simply
> bridge the transactions from different systems.
>
> The first approach is that Sandesha stores the message in a persistent
> store when it arrives. Then it attempts to deliver the message. It
> should only unpersist the message from the store when that "delivery"
> works. In your case the attempt to send on with cause an exception and
> we should roll back the delete from the store. This means that we need
> the Sandesha delivery thread to start a transaction, and Synapse to
> mark the transaction as failed.
>
> To make this really work, we need some kind of smart retry handling.
> In other words, we don't want to retry endlessly to that endpoint. We
> need to backoff exponentially and also have a max retry count. In case
> we hit the max retry - what should the behaviour be? Should we keep
> accepting incoming messages and storing them?
>
> The second approach requires more changes to Sandesha. In this model
> we don't ack to the client until JMS acks to us. In other words we
> don't need to store the messages persistently - we simply bridge JMS
> acks back to the client. This is a neater solution in one way. We
> still need a persistent store for the RM sequence information, but
> that is pretty small (one row per open sequence). So this model is
> much more suitable for a router or gateway that might be in the DMZ
> and have a limited storage.
>
> Paul
>
>
> On 3/16/07, Gerald Loeffler <ge...@googlemail.com> wrote:
> > hi all,
> >
> > further to this, i see the following behaviour:
> >
> > after the proxy received an SOAP/HTTP message containing WS-RM headers
> > from the client, it acknowledges the receipt of that message to
> > Sandesha. The proxy then attempts to send the message over the JMS
> > endpoint. If that endpoint is down, however, an exception is triggered
> > and the proxy basically drops the message. Since the message has
> > already been acknowledged to the client, the client will not try to
> > re-send it.
> >
> > now this begs the obvious questions:
> > - how can i configure acknowledgement behaviour of a proxy? can i
> > get the proxy to only acknowledge the message receipt to Sandesha
> > after sending it on?
> > - is there any concept of transactions in Synapse? could the
> > combination of message accept/send described above be executed within
> > one transaction (e.g. by connecting to a configurable transaction
> > manager and have the Synapse proxy to the begin/commit/rollback with
> > that transaction manager?)
> >
> > cheers,
> > gerald
> >
> >
> > On 12/03/07, Paul Fremantle <pz...@gmail.com> wrote:
> > > Gerald
> > >
> > > Sure.
> > >
> > > Are you using 0.91 or the latest build?
> > >
> > > In 0.91 you need to do this:
> > > <proxies>
> > > <proxy name="RMProxy" transports="http" description="A simple RM
> > > endpoint">
> > > <target endpoint="jmsEndpoint"/>
> > > <enableRM/>
> > > </proxy>
> > > </proxies>
> > >
> > > <definitions>
> > > <endpoint name="jmsEndpoint" address="jms://localhost:blah"
> > > force="pox"/>
> > > </definitions>
> > >
> > > Its been updated in the latest trunk.
> > >
> > > Paul
> > >
> > > On 3/12/07, Gerald Loeffler <ge...@googlemail.com> wrote:
> > > > Paul,
> > > >
> > > > On 12/03/07, Paul Fremantle <pz...@gmail.com> wrote:
> > > > > I think in general it is more likely that you would use one way flows
> > > > > between HTTP and JMS, or use SOAP together with RM. Otherwise it seems
> > > > > to me that the HTTP might well timeout and without RM you cannot
> > > > > resend the response after the client has timed out.
> > > >
> > > > I agree. Can i use WSRM guaranteed/exactly-once delivery on one-way
> > > > SOAP messages? This would allow me to
> > > > 1. reliably send a message via a one-way SOAP/HTTP request from the
> > > > client to synapse,
> > > > 2. then have synapse put the message onto a JMS queue
> > > > - without either synapse or the client waiting for the message to
> > > > actually be consumed from the JMS queue.
> > > >
> > > > cheers,
> > > > gerald
> > > >
> > > > >
> > > > > Paul
> > > > >
> > > > > On 3/12/07, Asankha C. Perera <as...@wso2.com> wrote:
> > > > > > Hi Gerald
> > > > > > > i understand the message flow in sample 111 as follows:
> > > > > > > 1. client sends SOAP/HTTP request for the getQuote operation to the
> > > > > > > synapse proxy. This is an in-out operation and the client actually
> > > > > > > waits synchronously for the response.
> > > > > > > 2. the synapse proxy accepts this request message and routes it to
> > > > > > > SimpleStockQuoteService via JMS by posting a JMS message on the
> > > > > > > SimpleStockQuoteService queue.
> > > > > > > 3. the SimpleStockQuoteService accepts the request and replies
> > > > > > > synchronously with a response. But where is that reponse sent to?
> > > > > > When the request to the service was sent over JMS, Synapse created a
> > > > > > temporary Queue for the response message and awaits for it by blocking
> > > > > > > Since this service is invoked through JMS in this scenario, i would
> > > > > > > expect the response message to be sent to a JMS queue - but where is
> > > > > > > that queue configured?
> > > > > > > 4. assuming that the reponse message was put on a JMS queue, synapse
> > > > > > > must now listen on that queue. This is for the out-rule of synapse. I
> > > > > > > don't see how/where i could tell synapse to listen on a particular JMS
> > > > > > > queue for response messages from a service.
> > > > > > > 5. assuming that the response message was received by synapse from
> > > > > > > that JMS queue, the synapse proxy then puts that message into the
> > > > > > > SOAP/HTTP response for the initial SOAP/HTTP request
> > > > > > > 6. client receives the SOAP/HTTP response for his initial request
> > > > > > > (synchronously, in this example).
> > > > > > Yep, the rest is all correct and indeed works! On a separate note, the
> > > > > > JMS destinations for responses have been discussed on the Axis2 lists
> > > > > > recently and some JIRAs are pending for some enhancements. The current
> > > > > > version of the JMS transport is the first cut implementation and now its
> > > > > > time to enhance it to cater to scenarios such as this
> > > > > > > there seems to be a missing link here somewhere that handles the
> > > > > > > translation from *one* request/response pair in SOAP/HTTP to *two*
> > > > > > > queues (input and output) for the JMS transport. The root problem is
> > > > > > > that the SOAP operation invoked by the client is an in-out operation.
> > > > > > > I could imagine that the synapse proxy needs to inserts a WSA reply-to
> > > > > > > header with a JMS-address before sending the request to the
> > > > > > > SimpleStockQuoteService...
> > > > > > >
> > > > > > > please help me solve this mystery! ;-)
> > > > > > >
> > > > > > > kind regards,
> > > > > > > gerald
> > > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Paul Fremantle
> > > > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > > > >
> > > > > http://bloglines.com/blog/paulfremantle
> > > > > paul@wso2.com
> > > > >
> > > > > "Oxygenating the Web Service Platform", www.wso2.com
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > http://www.gerald-loeffler.net
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Paul Fremantle
> > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > >
> > > http://bloglines.com/blog/paulfremantle
> > > paul@wso2.com
> > >
> > > "Oxygenating the Web Service Platform", www.wso2.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > http://www.gerald-loeffler.net
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-user-help@ws.apache.org
> >
> >
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: protocol conversion from HTTP to JMS
Posted by Gerald Loeffler <ge...@googlemail.com>.
hi,
i've submitted this JIRA "new feature":
https://issues.apache.org/jira/browse/SYNAPSE-72
regarding your solutions: the second is the one i was having in mind
(being the more traditional "application server mindset" solution)
while the first one is probably more in the spirit of MOM.
In both cases i would assume that the final step (ack of the message
to Sandesha or deletion from the persistent message store,
respectively) actually happens implicitly during transaction commit,
if you participate in a transaction coordinated by a transaction
manager. For the second solution you would need to write a
"transaction completion handler" that interfaces with Sandesha to
acknowledge (or not) the message, and that "transaction completion
handler" would need to be registered with the transaction. For JMS
this comes out-of-the-box in the form of a Java EE Connector - and a
Connector might in fact be the best implementation of plugging
Sandesha into an application server (as one way of allowing it to
participate in transactions coordinated by a transaction manager).
just a thought,
gerald
On 16/03/07, Paul Fremantle <pz...@gmail.com> wrote:
> Gerald
>
> Interesting. Thanks for testing this!
>
> There are two ways we can work this. One expects Synapse to have a
> resilient store and transactions, the other expects us to simply
> bridge the transactions from different systems.
>
> The first approach is that Sandesha stores the message in a persistent
> store when it arrives. Then it attempts to deliver the message. It
> should only unpersist the message from the store when that "delivery"
> works. In your case the attempt to send on with cause an exception and
> we should roll back the delete from the store. This means that we need
> the Sandesha delivery thread to start a transaction, and Synapse to
> mark the transaction as failed.
>
> To make this really work, we need some kind of smart retry handling.
> In other words, we don't want to retry endlessly to that endpoint. We
> need to backoff exponentially and also have a max retry count. In case
> we hit the max retry - what should the behaviour be? Should we keep
> accepting incoming messages and storing them?
>
> The second approach requires more changes to Sandesha. In this model
> we don't ack to the client until JMS acks to us. In other words we
> don't need to store the messages persistently - we simply bridge JMS
> acks back to the client. This is a neater solution in one way. We
> still need a persistent store for the RM sequence information, but
> that is pretty small (one row per open sequence). So this model is
> much more suitable for a router or gateway that might be in the DMZ
> and have a limited storage.
>
> Paul
>
>
> On 3/16/07, Gerald Loeffler <ge...@googlemail.com> wrote:
> > hi all,
> >
> > further to this, i see the following behaviour:
> >
> > after the proxy received an SOAP/HTTP message containing WS-RM headers
> > from the client, it acknowledges the receipt of that message to
> > Sandesha. The proxy then attempts to send the message over the JMS
> > endpoint. If that endpoint is down, however, an exception is triggered
> > and the proxy basically drops the message. Since the message has
> > already been acknowledged to the client, the client will not try to
> > re-send it.
> >
> > now this begs the obvious questions:
> > - how can i configure acknowledgement behaviour of a proxy? can i
> > get the proxy to only acknowledge the message receipt to Sandesha
> > after sending it on?
> > - is there any concept of transactions in Synapse? could the
> > combination of message accept/send described above be executed within
> > one transaction (e.g. by connecting to a configurable transaction
> > manager and have the Synapse proxy to the begin/commit/rollback with
> > that transaction manager?)
> >
> > cheers,
> > gerald
> >
> >
> > On 12/03/07, Paul Fremantle <pz...@gmail.com> wrote:
> > > Gerald
> > >
> > > Sure.
> > >
> > > Are you using 0.91 or the latest build?
> > >
> > > In 0.91 you need to do this:
> > > <proxies>
> > > <proxy name="RMProxy" transports="http" description="A simple RM
> > > endpoint">
> > > <target endpoint="jmsEndpoint"/>
> > > <enableRM/>
> > > </proxy>
> > > </proxies>
> > >
> > > <definitions>
> > > <endpoint name="jmsEndpoint" address="jms://localhost:blah"
> > > force="pox"/>
> > > </definitions>
> > >
> > > Its been updated in the latest trunk.
> > >
> > > Paul
> > >
> > > On 3/12/07, Gerald Loeffler <ge...@googlemail.com> wrote:
> > > > Paul,
> > > >
> > > > On 12/03/07, Paul Fremantle <pz...@gmail.com> wrote:
> > > > > I think in general it is more likely that you would use one way flows
> > > > > between HTTP and JMS, or use SOAP together with RM. Otherwise it seems
> > > > > to me that the HTTP might well timeout and without RM you cannot
> > > > > resend the response after the client has timed out.
> > > >
> > > > I agree. Can i use WSRM guaranteed/exactly-once delivery on one-way
> > > > SOAP messages? This would allow me to
> > > > 1. reliably send a message via a one-way SOAP/HTTP request from the
> > > > client to synapse,
> > > > 2. then have synapse put the message onto a JMS queue
> > > > - without either synapse or the client waiting for the message to
> > > > actually be consumed from the JMS queue.
> > > >
> > > > cheers,
> > > > gerald
> > > >
> > > > >
> > > > > Paul
> > > > >
> > > > > On 3/12/07, Asankha C. Perera <as...@wso2.com> wrote:
> > > > > > Hi Gerald
> > > > > > > i understand the message flow in sample 111 as follows:
> > > > > > > 1. client sends SOAP/HTTP request for the getQuote operation to the
> > > > > > > synapse proxy. This is an in-out operation and the client actually
> > > > > > > waits synchronously for the response.
> > > > > > > 2. the synapse proxy accepts this request message and routes it to
> > > > > > > SimpleStockQuoteService via JMS by posting a JMS message on the
> > > > > > > SimpleStockQuoteService queue.
> > > > > > > 3. the SimpleStockQuoteService accepts the request and replies
> > > > > > > synchronously with a response. But where is that reponse sent to?
> > > > > > When the request to the service was sent over JMS, Synapse created a
> > > > > > temporary Queue for the response message and awaits for it by blocking
> > > > > > > Since this service is invoked through JMS in this scenario, i would
> > > > > > > expect the response message to be sent to a JMS queue - but where is
> > > > > > > that queue configured?
> > > > > > > 4. assuming that the reponse message was put on a JMS queue, synapse
> > > > > > > must now listen on that queue. This is for the out-rule of synapse. I
> > > > > > > don't see how/where i could tell synapse to listen on a particular JMS
> > > > > > > queue for response messages from a service.
> > > > > > > 5. assuming that the response message was received by synapse from
> > > > > > > that JMS queue, the synapse proxy then puts that message into the
> > > > > > > SOAP/HTTP response for the initial SOAP/HTTP request
> > > > > > > 6. client receives the SOAP/HTTP response for his initial request
> > > > > > > (synchronously, in this example).
> > > > > > Yep, the rest is all correct and indeed works! On a separate note, the
> > > > > > JMS destinations for responses have been discussed on the Axis2 lists
> > > > > > recently and some JIRAs are pending for some enhancements. The current
> > > > > > version of the JMS transport is the first cut implementation and now its
> > > > > > time to enhance it to cater to scenarios such as this
> > > > > > > there seems to be a missing link here somewhere that handles the
> > > > > > > translation from *one* request/response pair in SOAP/HTTP to *two*
> > > > > > > queues (input and output) for the JMS transport. The root problem is
> > > > > > > that the SOAP operation invoked by the client is an in-out operation.
> > > > > > > I could imagine that the synapse proxy needs to inserts a WSA reply-to
> > > > > > > header with a JMS-address before sending the request to the
> > > > > > > SimpleStockQuoteService...
> > > > > > >
> > > > > > > please help me solve this mystery! ;-)
> > > > > > >
> > > > > > > kind regards,
> > > > > > > gerald
> > > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Paul Fremantle
> > > > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > > > >
> > > > > http://bloglines.com/blog/paulfremantle
> > > > > paul@wso2.com
> > > > >
> > > > > "Oxygenating the Web Service Platform", www.wso2.com
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > http://www.gerald-loeffler.net
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Paul Fremantle
> > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > >
> > > http://bloglines.com/blog/paulfremantle
> > > paul@wso2.com
> > >
> > > "Oxygenating the Web Service Platform", www.wso2.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > http://www.gerald-loeffler.net
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-user-help@ws.apache.org
> >
> >
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-user-help@ws.apache.org
>
>
--
http://www.gerald-loeffler.net
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-user-help@ws.apache.org
Re: protocol conversion from HTTP to JMS
Posted by Paul Fremantle <pz...@gmail.com>.
PS can you please raise a JIRA?
Paul
On 3/16/07, Paul Fremantle <pz...@gmail.com> wrote:
> Gerald
>
> Interesting. Thanks for testing this!
>
> There are two ways we can work this. One expects Synapse to have a
> resilient store and transactions, the other expects us to simply
> bridge the transactions from different systems.
>
> The first approach is that Sandesha stores the message in a persistent
> store when it arrives. Then it attempts to deliver the message. It
> should only unpersist the message from the store when that "delivery"
> works. In your case the attempt to send on with cause an exception and
> we should roll back the delete from the store. This means that we need
> the Sandesha delivery thread to start a transaction, and Synapse to
> mark the transaction as failed.
>
> To make this really work, we need some kind of smart retry handling.
> In other words, we don't want to retry endlessly to that endpoint. We
> need to backoff exponentially and also have a max retry count. In case
> we hit the max retry - what should the behaviour be? Should we keep
> accepting incoming messages and storing them?
>
> The second approach requires more changes to Sandesha. In this model
> we don't ack to the client until JMS acks to us. In other words we
> don't need to store the messages persistently - we simply bridge JMS
> acks back to the client. This is a neater solution in one way. We
> still need a persistent store for the RM sequence information, but
> that is pretty small (one row per open sequence). So this model is
> much more suitable for a router or gateway that might be in the DMZ
> and have a limited storage.
>
> Paul
>
>
> On 3/16/07, Gerald Loeffler <ge...@googlemail.com> wrote:
> > hi all,
> >
> > further to this, i see the following behaviour:
> >
> > after the proxy received an SOAP/HTTP message containing WS-RM headers
> > from the client, it acknowledges the receipt of that message to
> > Sandesha. The proxy then attempts to send the message over the JMS
> > endpoint. If that endpoint is down, however, an exception is triggered
> > and the proxy basically drops the message. Since the message has
> > already been acknowledged to the client, the client will not try to
> > re-send it.
> >
> > now this begs the obvious questions:
> > - how can i configure acknowledgement behaviour of a proxy? can i
> > get the proxy to only acknowledge the message receipt to Sandesha
> > after sending it on?
> > - is there any concept of transactions in Synapse? could the
> > combination of message accept/send described above be executed within
> > one transaction (e.g. by connecting to a configurable transaction
> > manager and have the Synapse proxy to the begin/commit/rollback with
> > that transaction manager?)
> >
> > cheers,
> > gerald
> >
> >
> > On 12/03/07, Paul Fremantle <pz...@gmail.com> wrote:
> > > Gerald
> > >
> > > Sure.
> > >
> > > Are you using 0.91 or the latest build?
> > >
> > > In 0.91 you need to do this:
> > > <proxies>
> > > <proxy name="RMProxy" transports="http" description="A simple RM
> > > endpoint">
> > > <target endpoint="jmsEndpoint"/>
> > > <enableRM/>
> > > </proxy>
> > > </proxies>
> > >
> > > <definitions>
> > > <endpoint name="jmsEndpoint" address="jms://localhost:blah"
> > > force="pox"/>
> > > </definitions>
> > >
> > > Its been updated in the latest trunk.
> > >
> > > Paul
> > >
> > > On 3/12/07, Gerald Loeffler <ge...@googlemail.com> wrote:
> > > > Paul,
> > > >
> > > > On 12/03/07, Paul Fremantle <pz...@gmail.com> wrote:
> > > > > I think in general it is more likely that you would use one way flows
> > > > > between HTTP and JMS, or use SOAP together with RM. Otherwise it seems
> > > > > to me that the HTTP might well timeout and without RM you cannot
> > > > > resend the response after the client has timed out.
> > > >
> > > > I agree. Can i use WSRM guaranteed/exactly-once delivery on one-way
> > > > SOAP messages? This would allow me to
> > > > 1. reliably send a message via a one-way SOAP/HTTP request from the
> > > > client to synapse,
> > > > 2. then have synapse put the message onto a JMS queue
> > > > - without either synapse or the client waiting for the message to
> > > > actually be consumed from the JMS queue.
> > > >
> > > > cheers,
> > > > gerald
> > > >
> > > > >
> > > > > Paul
> > > > >
> > > > > On 3/12/07, Asankha C. Perera <as...@wso2.com> wrote:
> > > > > > Hi Gerald
> > > > > > > i understand the message flow in sample 111 as follows:
> > > > > > > 1. client sends SOAP/HTTP request for the getQuote operation to the
> > > > > > > synapse proxy. This is an in-out operation and the client actually
> > > > > > > waits synchronously for the response.
> > > > > > > 2. the synapse proxy accepts this request message and routes it to
> > > > > > > SimpleStockQuoteService via JMS by posting a JMS message on the
> > > > > > > SimpleStockQuoteService queue.
> > > > > > > 3. the SimpleStockQuoteService accepts the request and replies
> > > > > > > synchronously with a response. But where is that reponse sent to?
> > > > > > When the request to the service was sent over JMS, Synapse created a
> > > > > > temporary Queue for the response message and awaits for it by blocking
> > > > > > > Since this service is invoked through JMS in this scenario, i would
> > > > > > > expect the response message to be sent to a JMS queue - but where is
> > > > > > > that queue configured?
> > > > > > > 4. assuming that the reponse message was put on a JMS queue, synapse
> > > > > > > must now listen on that queue. This is for the out-rule of synapse. I
> > > > > > > don't see how/where i could tell synapse to listen on a particular JMS
> > > > > > > queue for response messages from a service.
> > > > > > > 5. assuming that the response message was received by synapse from
> > > > > > > that JMS queue, the synapse proxy then puts that message into the
> > > > > > > SOAP/HTTP response for the initial SOAP/HTTP request
> > > > > > > 6. client receives the SOAP/HTTP response for his initial request
> > > > > > > (synchronously, in this example).
> > > > > > Yep, the rest is all correct and indeed works! On a separate note, the
> > > > > > JMS destinations for responses have been discussed on the Axis2 lists
> > > > > > recently and some JIRAs are pending for some enhancements. The current
> > > > > > version of the JMS transport is the first cut implementation and now its
> > > > > > time to enhance it to cater to scenarios such as this
> > > > > > > there seems to be a missing link here somewhere that handles the
> > > > > > > translation from *one* request/response pair in SOAP/HTTP to *two*
> > > > > > > queues (input and output) for the JMS transport. The root problem is
> > > > > > > that the SOAP operation invoked by the client is an in-out operation.
> > > > > > > I could imagine that the synapse proxy needs to inserts a WSA reply-to
> > > > > > > header with a JMS-address before sending the request to the
> > > > > > > SimpleStockQuoteService...
> > > > > > >
> > > > > > > please help me solve this mystery! ;-)
> > > > > > >
> > > > > > > kind regards,
> > > > > > > gerald
> > > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Paul Fremantle
> > > > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > > > >
> > > > > http://bloglines.com/blog/paulfremantle
> > > > > paul@wso2.com
> > > > >
> > > > > "Oxygenating the Web Service Platform", www.wso2.com
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > http://www.gerald-loeffler.net
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Paul Fremantle
> > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > >
> > > http://bloglines.com/blog/paulfremantle
> > > paul@wso2.com
> > >
> > > "Oxygenating the Web Service Platform", www.wso2.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > http://www.gerald-loeffler.net
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-user-help@ws.apache.org
> >
> >
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: protocol conversion from HTTP to JMS
Posted by Paul Fremantle <pz...@gmail.com>.
PS can you please raise a JIRA?
Paul
On 3/16/07, Paul Fremantle <pz...@gmail.com> wrote:
> Gerald
>
> Interesting. Thanks for testing this!
>
> There are two ways we can work this. One expects Synapse to have a
> resilient store and transactions, the other expects us to simply
> bridge the transactions from different systems.
>
> The first approach is that Sandesha stores the message in a persistent
> store when it arrives. Then it attempts to deliver the message. It
> should only unpersist the message from the store when that "delivery"
> works. In your case the attempt to send on with cause an exception and
> we should roll back the delete from the store. This means that we need
> the Sandesha delivery thread to start a transaction, and Synapse to
> mark the transaction as failed.
>
> To make this really work, we need some kind of smart retry handling.
> In other words, we don't want to retry endlessly to that endpoint. We
> need to backoff exponentially and also have a max retry count. In case
> we hit the max retry - what should the behaviour be? Should we keep
> accepting incoming messages and storing them?
>
> The second approach requires more changes to Sandesha. In this model
> we don't ack to the client until JMS acks to us. In other words we
> don't need to store the messages persistently - we simply bridge JMS
> acks back to the client. This is a neater solution in one way. We
> still need a persistent store for the RM sequence information, but
> that is pretty small (one row per open sequence). So this model is
> much more suitable for a router or gateway that might be in the DMZ
> and have a limited storage.
>
> Paul
>
>
> On 3/16/07, Gerald Loeffler <ge...@googlemail.com> wrote:
> > hi all,
> >
> > further to this, i see the following behaviour:
> >
> > after the proxy received an SOAP/HTTP message containing WS-RM headers
> > from the client, it acknowledges the receipt of that message to
> > Sandesha. The proxy then attempts to send the message over the JMS
> > endpoint. If that endpoint is down, however, an exception is triggered
> > and the proxy basically drops the message. Since the message has
> > already been acknowledged to the client, the client will not try to
> > re-send it.
> >
> > now this begs the obvious questions:
> > - how can i configure acknowledgement behaviour of a proxy? can i
> > get the proxy to only acknowledge the message receipt to Sandesha
> > after sending it on?
> > - is there any concept of transactions in Synapse? could the
> > combination of message accept/send described above be executed within
> > one transaction (e.g. by connecting to a configurable transaction
> > manager and have the Synapse proxy to the begin/commit/rollback with
> > that transaction manager?)
> >
> > cheers,
> > gerald
> >
> >
> > On 12/03/07, Paul Fremantle <pz...@gmail.com> wrote:
> > > Gerald
> > >
> > > Sure.
> > >
> > > Are you using 0.91 or the latest build?
> > >
> > > In 0.91 you need to do this:
> > > <proxies>
> > > <proxy name="RMProxy" transports="http" description="A simple RM
> > > endpoint">
> > > <target endpoint="jmsEndpoint"/>
> > > <enableRM/>
> > > </proxy>
> > > </proxies>
> > >
> > > <definitions>
> > > <endpoint name="jmsEndpoint" address="jms://localhost:blah"
> > > force="pox"/>
> > > </definitions>
> > >
> > > Its been updated in the latest trunk.
> > >
> > > Paul
> > >
> > > On 3/12/07, Gerald Loeffler <ge...@googlemail.com> wrote:
> > > > Paul,
> > > >
> > > > On 12/03/07, Paul Fremantle <pz...@gmail.com> wrote:
> > > > > I think in general it is more likely that you would use one way flows
> > > > > between HTTP and JMS, or use SOAP together with RM. Otherwise it seems
> > > > > to me that the HTTP might well timeout and without RM you cannot
> > > > > resend the response after the client has timed out.
> > > >
> > > > I agree. Can i use WSRM guaranteed/exactly-once delivery on one-way
> > > > SOAP messages? This would allow me to
> > > > 1. reliably send a message via a one-way SOAP/HTTP request from the
> > > > client to synapse,
> > > > 2. then have synapse put the message onto a JMS queue
> > > > - without either synapse or the client waiting for the message to
> > > > actually be consumed from the JMS queue.
> > > >
> > > > cheers,
> > > > gerald
> > > >
> > > > >
> > > > > Paul
> > > > >
> > > > > On 3/12/07, Asankha C. Perera <as...@wso2.com> wrote:
> > > > > > Hi Gerald
> > > > > > > i understand the message flow in sample 111 as follows:
> > > > > > > 1. client sends SOAP/HTTP request for the getQuote operation to the
> > > > > > > synapse proxy. This is an in-out operation and the client actually
> > > > > > > waits synchronously for the response.
> > > > > > > 2. the synapse proxy accepts this request message and routes it to
> > > > > > > SimpleStockQuoteService via JMS by posting a JMS message on the
> > > > > > > SimpleStockQuoteService queue.
> > > > > > > 3. the SimpleStockQuoteService accepts the request and replies
> > > > > > > synchronously with a response. But where is that reponse sent to?
> > > > > > When the request to the service was sent over JMS, Synapse created a
> > > > > > temporary Queue for the response message and awaits for it by blocking
> > > > > > > Since this service is invoked through JMS in this scenario, i would
> > > > > > > expect the response message to be sent to a JMS queue - but where is
> > > > > > > that queue configured?
> > > > > > > 4. assuming that the reponse message was put on a JMS queue, synapse
> > > > > > > must now listen on that queue. This is for the out-rule of synapse. I
> > > > > > > don't see how/where i could tell synapse to listen on a particular JMS
> > > > > > > queue for response messages from a service.
> > > > > > > 5. assuming that the response message was received by synapse from
> > > > > > > that JMS queue, the synapse proxy then puts that message into the
> > > > > > > SOAP/HTTP response for the initial SOAP/HTTP request
> > > > > > > 6. client receives the SOAP/HTTP response for his initial request
> > > > > > > (synchronously, in this example).
> > > > > > Yep, the rest is all correct and indeed works! On a separate note, the
> > > > > > JMS destinations for responses have been discussed on the Axis2 lists
> > > > > > recently and some JIRAs are pending for some enhancements. The current
> > > > > > version of the JMS transport is the first cut implementation and now its
> > > > > > time to enhance it to cater to scenarios such as this
> > > > > > > there seems to be a missing link here somewhere that handles the
> > > > > > > translation from *one* request/response pair in SOAP/HTTP to *two*
> > > > > > > queues (input and output) for the JMS transport. The root problem is
> > > > > > > that the SOAP operation invoked by the client is an in-out operation.
> > > > > > > I could imagine that the synapse proxy needs to inserts a WSA reply-to
> > > > > > > header with a JMS-address before sending the request to the
> > > > > > > SimpleStockQuoteService...
> > > > > > >
> > > > > > > please help me solve this mystery! ;-)
> > > > > > >
> > > > > > > kind regards,
> > > > > > > gerald
> > > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Paul Fremantle
> > > > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > > > >
> > > > > http://bloglines.com/blog/paulfremantle
> > > > > paul@wso2.com
> > > > >
> > > > > "Oxygenating the Web Service Platform", www.wso2.com
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > http://www.gerald-loeffler.net
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Paul Fremantle
> > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > >
> > > http://bloglines.com/blog/paulfremantle
> > > paul@wso2.com
> > >
> > > "Oxygenating the Web Service Platform", www.wso2.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: synapse-user-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > http://www.gerald-loeffler.net
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-user-help@ws.apache.org
> >
> >
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org