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
