W3C home > Mailing lists > Public > public-ws-addressing@w3.org > March 2005

Use of WSA in other specs.

From: David Hull <dmh@tibco.com>
Date: Tue, 22 Mar 2005 15:08:55 -0500
To: "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>
Message-id: <42407B57.20601@tibco.com>
I just had a quick --and I'll emphasize quick -- look at 
WS-ReliableMessaging, WS-Transfer and WS-Enumeration.  These all refer 
to WSA fault or reply endpoints, but I don't believe they need to or 
should do so.  Note that these specs refer to other MAPs, particularly 
[action], in ways that appear to make sense.

In section 4 (faults) WS-RM says "The fault definitions defined in this 
section reference certain abstract properties, such as [fault endpoint], 
that are defined in section 3 of the WS-Addressing specification.  
Endpoints compliant with this specification MUST include required 
message information headers /[sic] /on all fault messages."   As far as 
I can tell, none of the text that follows actually references [fault 
endpoint].  It /does /talk about where to send faults, but that's the 
[destination] property of the fault message itself (see * below).  The 
only required MAP I can see here is the wsa:Action MAP for faults.

WS-Transfer and WS-Enumeration talk variously about To, Action, ReplyTo, 
FaultTo, and MessageID headers in what appear to be basic request/reply 
messages.

In all these cases, I don't see the value of talking about MAPs 
explicitly, particularly as headers in example SOAP messages.  Depending 
on how we ultimately resolve various issues, these headers may or may 
not need to be present.  I particularly don't see any reason that 
Transfer or Enumeration would not work just as well over existing 
SOAP/HTTP stacks without these headers present.  Obviously we would like 
to be able to leverage WSA for asynchronous request/reply where 
appropriate, but we shouldn't have to say anything to make this happen, 
beyond "this is a request/reply".  Or will we need to have every spec 
that currently uses request/reply change to say "this uses (or MAY use) 
request/reply as defined in WSA" in order to leverage WSA?

In any case, I don't see how any of these specs depends materially on 
WSA.  By contrast, Notification and Eventing depend materially on WSA, 
though they don't depend materially on MAPs, only on EPRs.  I think we 
need to distinguish what parts of WSA are referenced by various specs, 
and to what degree there is a direct dependence (as opposed to an 
indirect one such as "we use request/reply and request/reply may use WSA 
for correlation").

I don't yet know of any specs outside ours that depend /directly/ on 
MAPs.  I do know at least two that depend materially and directly on 
EPRs, and I expect this list to grow.

(*) WS-RM says (in section 4) that sequence faults should go to the same 
place as message acknowledgments.  It phrases this as "Sequence faults 
SHOULD be sent to the same [destination] as <SequenceAcknowledgement> 
messages."  That is, the [destination] MAP for sequence faults should be 
the same as that for acknowledgments.
Received on Tuesday, 22 March 2005 20:09:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:04 GMT