RE: Action Property Issue (Web Services Addressing 1.0 - Metadata)

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?

 

  <http://www.bea.com/content/images/spacer.gif> 	
  <http://www.bea.com/content/images/spacer.gif>
<http://www.bea.com/content/images/email_sig/sig_jelly_blue.gif> 	
  <http://www.bea.com/content/images/email_sig/bealogo_sig_tl_r.gif> 
  <http://www.bea.com/content/images/spacer.gif> 	
 	 
Gilbert Pilz
Sr. Principal Technologist
Office of the CTO 
Phone: 408.687.4874 
Mobile: 831.332.0737 
YIM: gilbertpilz
 <mailto:gilbert.pilz@bea.com> gilbert.pilz@bea.com
  <http://www.bea.com/content/images/spacer.gif> 	BEA Systems, Inc.
Corporate Office, USA 
2315 North First Street 
San Jose, CA 95131 
Fax: 408.570.8901
 <http://www.bea.com/> www.bea.com
<http://www.bea.com/content/images/spacer.gif> 	
  <http://www.bea.com/content/images/spacer.gif> 	
 	 Dev2Dev blog:  <http://dev2dev.bea.com/pub/au/3277>
http://dev2dev.bea.com/pub/au/3277