cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessio Soldano <asold...@redhat.com>
Subject Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Date Sat, 25 Sep 2010 23:48:30 GMT
  Hi Dan,

On 09/24/2010 08:58 PM, Daniel Kulp wrote:
> I'm not sure I understand.   Does the RelatesTo on the response properly match
> the message id of the request?
Yes, it does; here is an example of request and response:

POST /wstf/sc003/Sc003Service HTTP/1.1

<soap:Envelope 
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header><Action 
xmlns="http://www.w3.org/2005/08/addressing">http://www.wstf.org/docs/scenarios/sc002/Echo</Action><MessageID

xmlns="http://www.w3.org/2005/08/addressing">urn:11d1def534ea1be0:43941453:12b43e809f7:-7ffd</MessageID><To

xmlns="http://www.w3.org/2005/08/addressing">http://localhost:8080/wstf/sc003/Sc003Service</To><ReplyTo

xmlns="http://www.w3.org/2005/08/addressing"><Address>http://localhost:8080/wstf/sc003/Sc003ResponseService</Address></ReplyTo><SessionData

xmlns="http://www.wstf.org/docs/scenarios/sc002" 
xmlns:ns2="http://www.w3.org/2005/08/addressing"><ID>0</ID></SessionData></soap:Header><soap:Body><Echo

xmlns="http://www.wstf.org/docs/scenarios/sc002" 
xmlns:ns2="http://www.w3.org/2005/08/addressing"><text>World</text></Echo></soap:Body></soap:Envelope>


POST /wstf/sc003/Sc003ResponseService HTTP/1.1

<soap:Envelope 
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header><Action 
xmlns="http://www.w3.org/2005/08/addressing">http://www.wstf.org/docs/scenarios/sc002/EchoResponse</Action><MessageID

xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:b3743575-569d-4f31-960d-eb784ae2a37e</MessageID><To

xmlns="http://www.w3.org/2005/08/addressing">http://localhost:8080/wstf/sc003/Sc003ResponseService</To><RelatesTo

xmlns="http://www.w3.org/2005/08/addressing">urn:11d1def534ea1be0:43941453:12b43e809f7:-7ffd</RelatesTo></soap:Header><soap:Body><EchoResponse

xmlns="http://www.wstf.org/docs/scenarios/sc002" 
xmlns:ns2="http://www.w3.org/2005/08/addressing"><text>World</text></EchoResponse></soap:Body></soap:Envelope>


>    If so, why is the MAPCodec not able to
> correlate the message?
Because we have 2 MAPCodec instances involved in the process



> I guess my concern is around a potential memory leak if the MAPCodec is
> holding onto messages waiting for a response.
mmh... I see what you mean, that's an issue related to this kind of 
scenario though, not to the change I'd do for preventing the abort on 
response receipt. I need to look better at the code next week, perhaps 
the memory leak can be prevented early detecting this kind of message 
exchange when sending the request...?

Cheers
Alessio


>     But then again, I'm not sure I
> understand the issue.  :-)
>
> Dan
>
>
>
> On Friday 24 September 2010 11:43:19 am Alessio Soldano wrote:
>>    Hi,
>> I'm currently dealing with an application meant for testing the
>> scenarios defined by WSTF (http://www.wstf.org/). The application uses
>> JBossWS-CXF, currently leveraging Apache CXF trunk.
>> The third scenario of those WSTF tests is about WS-Addressing
>> interoperability, see http://www.wstf.org/docs/scenarios/sc003/sc003.xml
>> for all the details.
>> Currently I'm dealing with the 1.4 test (ASynch Echo+WSA): the client
>> sends a non-faulting echo message with WS-Addressing headers to indicate
>> an asynchronous response[1] is expected. wsa:Action, wsa:To,
>> wsa:MessageID and wsa:ReplyTo are required. The wsa:ReplyTo must refer
>> to an addressable endpoint that is also part of the application.
>> The success criteria for the test is that the service responds with the
>> appropriate echo response on a new connection to the wsa:ReplyTo EPR
>> specified in the echo message. On the original connection an HTTP 202 is
>> returned. The echo response message will contain the appropriate
>> WS-Addressing headers (wsa:Action, wsa:To and wsa:RelatesTo).
>> Currently the messages going over the wire are OK, however the test is
>> failing because when receiving the response message on the response
>> endpoint, the message is discarded with an abort on the interceptor
>> chain performed by the MAPCodec. The reason is that MAPCodec is not able
>> to find a correlated request message for the id provided in the
>> relatesTo attribute of the response message.
>> This is basically the same problem explained in CXF-2167, except we're
>> talking about a req-res MEP, so the application developer is not meant
>> (at least to me) to deal with setting the RelationshipType of relatesTo
>> in the response.
>> I'm thinking about relaxing that check for the correlated Exchange in
>> MAPCodec::restoreExchange, basically avoiding the abort on the
>> interceptor chain when the id is not found, for supporting usecases like
>> this.
>> WDYT ?
>> Thanks
>> Alessio
>>
>> [1] As per WSTF definition, Asynchronous Request-Response Message
>> Exchange: "A SOAP message exchange in which a requester sends a SOAP
>> message to a service and receives a response message. "Asynchronous" in
>> this context refers to the manner in which the underlying transport
>> protocol is used to carry the request and response messages. The
>> response message is sent over a separate connection that is initiated by
>> the service to the client (a "callback")."


-- 
Alessio Soldano
Web Service Lead, JBoss


Mime
View raw message