|
List Info
Thread: RE: Action Property Issue (Web Services Addressing 1.0 - Metadata)
|
|
| RE: Action Property Issue (Web Services
Addressing 1.0 - Metadata) |
|
2007-06-07 13:49:56 |
|
|
Cindy,
Thank you
for your comments on the Web Services
Address 1.0 - Metadata specification concerning the default action
pattern for WSDL 2.0. The Web Services Addressing Working Group discussed this
issue during its June 4th teleconference and I was given the task of relating
this discussion to you.
Although
the WS-Addressing 1.0 Metadata document refers to a "best practice in WSDL 2.0",
the WG was unclear about the intent of these ;"best
practices". The language in Sections 2.3.1 and 2.4.1 of the WSDL 2.0 core
document concerns the ability to derive one interface from another
whereas the language in Section 4.4. of the WSA Metadata spec (augmented by the memories of the participants in
the WG) is about the ability to
dispatch an incoming message to the correct handler for the intended WSDL
operation (though, obviously, these two concerns are closely
related).
The point
was raised that the handling of new messages and the handling of fault
messages are not symmetric. At the point in which a processor receives a new
message, there is no context or other information about that message. The
default action pattern for input/output messages allows the service to dispatch
the message to the correct handler for the WSDL operation. On the other hand,
when the processor receives a fault, it does so as a result of previously
sending a message. The "core task", if you will, of the processor receiving a
fault is to correlate the fault to the request for which it is a response.
Knowing which operation triggered the fault doesn't help you perform this task,
since a service consumer may have sent multiple messages for the same
operation, some of which caused faults and some of which did not. On the other
hand, the [relationship] property (wsa:RelatesTo) of the fault message
does allow you to correlate the fault to the request which triggered
it.
Another
point raised was that changing the default action pattern
would impact existing implementations of WS-Addressing 1.0. To the
extent that the default action pattern for WSDL 2.0 faults has
remained unchanged for some time now (going back to second working draft of the
WS-Addressing WSDL Binding specification in January of 2005), it is likely that
changing this pattern will break existing implementations of WS-Addressing 1.0.
While its true that organizations have no right to expect that a
pre-Recommendation specification will not change, it's considered bad form to
make these sorts of changes (i.e. changes that are reflected on the wire) at
this stage without a compelling reason. Furthermore, such breaking changes shouldn't be made
without reflecting the change in the namespace of the specification. Although
the ;default action patterns are
specified in the WS-Addressing 1.0 Metadata specification, it seems clear
that we would actually have to change the WS-Addressing namespace to indicate to
implementations that these patterns
have changed (since the "wsam" namespace wouldn't necessarily appear in a fault
message).
When the WG
weighed the harm of the existing default action pattern for WSDL 2.0 faults
against the impact of changing this
pattern, it was decided that it would be best to leave that pattern as it is.
Consequently this issue was closed with no action.
That
being said, there are some actions that should be carried forward into any
further work on the WS-Addressing 1.0 Core and Metadata specifications (i.e. as errata,
etc.)
1.) The
reference to the "WSDL 2.0" best practices in Section 4.4 of the Metadata
specification should either be removed or clarified. If clarified they should
(a) clearly indicate which "best practices" are being referred to and (b)
describe the motivation behind the use of such "best
practices".
2.) The
intended use of the [action] property in fault messages, specifically within the
context of WSDL 2.0, should be clarified. Is it enough to indicate which fault
was generated or does the "semantics implied by a fault message" need to include
an indication of the operation that generated the
fault?
|
 Approximate file size 62 bytes |
| Approximate file size 29650 bytes |
| Approximate file size 3498 bytes |
[1]
|
|
|
about | contact Other archives ( Real Estate discussion Medical topics )
|
bea.com