I think that you have to be very careful
about this.
The sole purpose of this spec is interoperable reliable messaging.
The markitectural half-truth of “composable
specs” cannot be alchemically converted into a whole truth to be relied
upon for the purposes of interoperability.
Any given set of versions of the composable specs may be truly composable (to
ensure this at some basic level is why WS-I exists), but this cannot be
assumed.
In the case of any one spec, it is the
job of the spec to create an island of composability by narrowing its
references to specific version(s). If this is not done then the resulting spec
is open to implementation variation which could be (almost certainly will be)
lethal to interoperation. If there are multiple versions specified then implementations
can state the matrix of interop that they will support. If there are no
specified versions then the statement “implements the interoperable
protocol” becomes close to meaningless (will only be true by sheer luck).
Alastair
Alastair J. Green
CEO and CTO
Choreology
Ltd
68 Lombard Street
London EC3V 9LJ
www.choreology.com
+44 207 868 2316 (office)
+44 870 739 0051 (fax)
+44 795 841 2107 (mobile)
-----Original Message-----
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: 21 September 2005 14:21
To: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] NEW ISSUE:
Which version of WS-Addressing spec?
Do we really need to point to a specific version of
WS-Addr? I thought that one
of
the composibility aspects of these WS specs was that we wouldn't need to change
all
of them just because one of them was modified. As long as the basic ideas
of
WSA
(that RM needs) don't change - like EPRs, MI Headers... can't we just talk
about
them
in generic terms and let the implementations decide which version they want to
support?
Should one that (for some reason) can't step up to the latest WSA be
tagged
as
non-RM compliant? I don't think it should. It may not be as
interoperable, but that's
a
different story.
I've
seen other specs go thru quite a lot of pain because different specs they're
composing
with point to different levels of WSA - and they actually try to support
more
than one at the same time - what a hassle.
-Doug
Anish Karmarkar
<Anish.Karmarkar@oracle.com>
09/20/2005 04:01 PM
|
To
|
wsrx <ws-rx@lists.oasis-open.org>
|
cc
|
|
Subject
|
[ws-rx] NEW ISSUE: Which version of
WS-Addressing spec?
|
|
Title:
Which version of WS-Addressing spec?
Description:
Page 25, lines 664-665 at [1] says:
"WS-ReliableMessaging faults MUST include as
the [action] property the
default fault action URI defined in the version of
WS-Addressing used in
the message."
This can be interpreted as any version of
WS-Addressing is allowed with
WSRM. WSRM spec should specify which version of
WS-Addressing is used by
the spec.
A related issue is that:
On page 25, lines 664-666 talk about the default
"http://schemas.xmlsoap.org/ws/2004/08/addressing/fault"
as the Fault
[action] property. This default is defined only
for the SOAP binding and
is meant to be used with WS-Addr faults not WSRM
faults.
Justification:
Without clearly indicating which version of
WS-Addressing is
required/used by the spec, independent
implementation will not
interoperate. WS-Addressing specification has
changed substantially (in
certain sections/artifacts of the WS-Addressing
spec) over the years.
Target: core
Type: design
Proposal:
Use the CR version of the spec [2] (in this
paragraph as well as the
normative reference for the spec) for now and make
changes as the
addressing spec transitions through the process of
becoming a REC. Based
on the WS-Addr schedule and WSRM schedule, WS-Addr
is slated to become a
REC before WSRM is final.
For the related issue:
change line 664 from --
"WS-ReliableMessaging faults MUST include as
the [action] property the
default fault"
to --
"WS-ReliableMessaging faults MUST include as
the [action] property as
defined by WS-Addressing [ref]."
and
delete lines 665-667
Related issues: none
[1]
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14548/wsrm-1.1-spec-wd-03.pdf
[2]
http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/