This content has been marked as final.
Show 5 replies
-
1. Re: WSA message correlation
hbraun Jan 13, 2006 8:05 AM (in response to hbraun)Specification includes the follwing rule:
In the absence of the wsa:Action attribute, the following pattern is used to construct a default action for inputs and outputs. The general form of an action URI is as follows:
[target namespace]/[port type name]/[input|output name]
Maybe we should modify the SOAPServerHandler to reflect the above rule? -
2. Re: WSA message correlation
thomas.diesler Jan 16, 2006 5:21 AM (in response to hbraun)
I realized that AddressingProperties.initialzeAsReply doesn't correlate wsa:messageId -> wsa:relatesTo. Is there a specific reason for that ... ?
The reason is probably, that it is not explicitly stated by the javadoc that I based the implementation on.
However, this process is better defined in
3.3 Formulating a Reply Message
http://www.w3.org/TR/ws-addr-core/#formreplymsg
and explicitly says
[relationship]: this property MUST include a pair of IRIs as follows; the relationship type is the
predefined reply URI "http://www.w3.org/2005/08/addressing/reply" and the related message?s
identifier is the [message id] property value from the message being replied to; other relationships
MAY be expressed in this property
So, I would say the current implementation is incomplete and should be changed more in line what you suggest. -
3. Re: WSA message correlation
thomas.diesler Jan 16, 2006 5:34 AM (in response to hbraun)
In the absence of the wsa:Action attribute, the following pattern is used to construct a default action for inputs and outputs. The general form of an action URI is as follows:
[target namespace]/[port type name]/[input|output name]Maybe we should modify the SOAPServerHandler to reflect the above rule?
Yes -
4. Re: WSA message correlation
hbraun Jan 16, 2006 5:40 AM (in response to hbraun)
I assigned this to me:
http://jira.jboss.org/jira/browse/JBWS-655 -
5. Re: WSA message correlation
hbraun Jan 16, 2006 6:22 AM (in response to hbraun)Some specifications (ws-eventing for instance) don't follow this rule. They have fixed response action values, that can't be resolved by the above rule. I suggest we implement it the following way:
1.) Is there a custom was:action set on message context, then use it.
2.) If this property is missing, we resolve the wsa:action element by the means described above.