On 8/22/06, Jaliya Ekanayake <[EMAIL PROTECTED]> wrote:
What Thomas is talking abt is the case where the user has not set any incoming transport. If he want he can set the transportInProtocol which will be picked by Sandesha (and Axis2).
Chamikara
Hi All,Few thoughts inline.-Jaliya----- Original Message -----From: Chamikara JayalathTo: Thomas McKiernanSent: Tuesday, August 22, 2006 6:53 AMSubject: Re: use transportOutProtocol to setup async listenersHi Thomas,See my comments below.
On 8/22/06, Thomas McKiernan <[EMAIL PROTECTED]> wrote:
Hi Chamikara,
Thanks for your response - I've asked some questions/made some comments in blue.
This restriction was added considering the WSRM 1.0 spec where it was not possible to get sync Application responses in a RM sequences.Ok, I think I understand. Therefore when polling is introduced, is it correct to say that sync 2-way with an anonymous acksTo will work and an async listener/transportIn etc will not be required for that particular flow?
yesStill I belive we should start the listner if the client sets an Async acksTo endpoint. In this case Sandesha2 will expect the TransportInProtocol to be set. Hope this is ok for the JAX-WS case.
Ok, so as I understand it, this currently works today i.e. without polling, provided that the transportIn etc is setup.
I agree that Sandesha needs to setup an async listener for an addressable acksTo. However, is it necessarily right that the client or jaxWS layer should know that, by setting an acksTo, it also has to set up a transportInProtocol, in order for this async listener to be set up? It seems to me that some implementation detail of sandesha is that an async listener is used to receive response messages during an addressable synchronous flow. It seems therefore that it would be good to shield the jaxWS layer from this implementationd detail. What would be the effect of using transportOut details to setup the transportIn in the case of one not having been set?
OK. This seems to be a valid requirement. I'll do this change. Thaks for pointing it outThis is ok but we need to make sure that we have a very clear way to get things done. So jaxWS does not need different transports by any chance?
What Thomas is talking abt is the case where the user has not set any incoming transport. If he want he can set the transportInProtocol which will be picked by Sandesha (and Axis2).
Chamikara
----------------------------------
Thomas McKiernan
WebSphere Messaging Development,
IBM United Kingdom Limited
Internal Phone: 248241
External Phone: +44 (0)1962 818241
Mobile: +44 (0)789 1737497
Email: [EMAIL PROTECTED]
Mail Point 211, IBM, Hursley Park, Winchester, Hampshire, England, SO21 2JN
Caminante, no hay camino
Se hace camino al andar.
("Walker, there is no path; the path is made by walking.") Antonio Machado
"Chamikara Jayalath" <[EMAIL PROTECTED]> 22/08/2006 06:23
Thomas McKiernan/UK/[EMAIL PROTECTED] [email protected] Re: use transportOutProtocol to setup async listeners
Hi Thomas,
This restriction was added considering the WSRM 1.0 spec where it was not possible to get sync Application responses in a RM sequences. So setting transport In protocol was a must if you need to get response messages.
But due to Message Polling introduced in the new spec it is possible to get reliable response messages without an endpoint in the client side. So i guess we should remove this restriction.
(Message Polling is not implemented yet, but hope to do this in next couple of weeks)
Still I belive we should start the listner if the client sets an Async acksTo endpoint. In this case Sandesha2 will expect the TransportInProtocol to be set. Hope this is ok for the JAX-WS case.
Chamikara
On 8/21/06, Thomas McKiernan <[EMAIL PROTECTED] > wrote:
Hi guys,
Using JAX-WS to invoke Sandesha, I get the following problem for a sync two-way invoke:
org.apache.sandesha2.SandeshaException: cannot start async listener transportInProtocol=null
at org.apache.sandesha2.util.SequenceManager.updateClientSideListnerIfNeeded(SequenceManager.java:355)
at org.apache.sandesha2.util.SequenceManager.setupNewClientSequence(SequenceManager.java:323)
at org.apache.sandesha2.msgprocessors.ApplicationMsgProcessor.processOutMessage(ApplicationMsgProcessor.java:634)
at org.apache.sandesha2.handlers.SandeshaOutHandler.invoke(SandeshaOutHandler.java:131)
at org.apache.axis2.engine.Phase.invoke(Phase.java:380)
at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:528)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:638)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:357)
at org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:288)
at org.apache.axis2.jaxws.core.controller.AxisInvocationController.invoke(AxisInvocationController.java:146)
at org.apache.axis2.jaxws.client.BaseDispatch.invoke(BaseDispatch.java:123)
at jaxws.tester.JAXInvoker.testSync(JAXInvoker.java:61)
at jaxws.tester.JAXInvoker.main(JAXInvoker.java:133)
Looking at it, the transportInProtocol is not being set and the code is deciding to listen for async acks / cntrl msgs.
The question is whether it is reasonable for Sandesha to expect JAX-WS/Axis2 to have set this field in this situation.
As I understand it, this is only currently done in JAX-WS/Axis2 levels if the client knows that it requires an asyncListener.
But in this case this is not known until it reaches Sandesha - so far as the client is concerned this is just a sync two way call. It is only, I think, because the create sequence flow is required that this is not the case.
Therefore could Sandesha change to use the TransportOut (which I believe is always set) in the case when the TransportInProtocol is not set?
Many thanks,
Thomas
----------------------------------
Thomas McKiernan
WebSphere Messaging Development,
IBM United Kingdom Limited
Internal Phone: 248241
External Phone: +44 (0)1962 818241
Mobile: +44 (0)789 1737497
Email: [EMAIL PROTECTED]
Mail Point 211, IBM, Hursley Park, Winchester, Hampshire, England, SO21 2JN
Caminante, no hay camino
Se hace camino al andar.
("Walker, there is no path; the path is made by walking.") Antonio Machado
