|
Hi All,
Few thoughts inline.
-Jaliya
----- Original Message -----
Sent: Tuesday, August 22, 2006 6:53
AM
Subject: Re: use transportOutProtocol to
setup async listeners
Hi Thomas,
See my
comments below.
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?
yes
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.
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
out
This 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?
Chamikara
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
| "Chamikara Jayalath"
<[EMAIL PROTECTED]>
22/08/2006 06:23 |
|
To |
Thomas
McKiernan/UK/[EMAIL PROTECTED] |
|
cc |
[email protected] |
|
Subject |
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
|
