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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> Paul,
>
> On 12/03/07, Paul Fremantle <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > --
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >
> > http://bloglines.com/blog/paulfremantle
> > [EMAIL PROTECTED]
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> http://www.gerald-loeffler.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
http://www.gerald-loeffler.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]