asap message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: review of WS-Addressing
- From: Keith Swenson <KSwenson@us.fujitsu.com>
- To: "'workgroup4@ftplist.aiim.org'" <workgroup4@listserv.aiim.org>, ASAP <asap@lists.oasis-open.org>
- Date: Sun, 3 Apr 2005 20:08:07 -0700
At long last, the
WS-Addressing specification is availble for final review. It has been
broken into three pieces: Core, SOAP, and WSDL. The core piece is the critical
one. It is clear and succinct. It defines two things: an EPR (end point
reference) and a some header elements to be used to address the
message.
First of all, in February all references to "URL" or
"URI" were replaced with a new acronym "IRI". The IRI is clearly very
similar to a URL/URI but it has some international extensions, and possible some
vague points clarified. Seems we will need to make the same change in the
ASAP spec.
The EPR is a way to refer to a web service
instance. It is a structure to be passed around from one web service
to a second web service in order to deliver the address of the first or possible
a third web service. The EPR definintion shows the effect of political
fight between parties that have a vested interest in particular implementation,
and as such it shows a certain amount of "overkill" for our situation. But
the extra parts are optional, so for the most part can be ignored. Here
are the parts of an EPR:
<Address> - this carries the IRI (essentially the
URI or URL) of the service endpoint. This is the only part that ASAP
needs.
<ReferenceParameters> - this is needed by some
legacy protocols where the address does not in itself address the actual web
service. The example is given where where a service needs a "shopping cart
id" and a "customer id" in order to address the web service. The position
of ASAP & WfXML has always been that these can be encoded into the address
using URL parameters. This is allowed under WS-Addressing ... there is no
limitation on the address. So, as far as I can conclude, the reference
parameters as essentially a legacy appendage to allow WS-Addressing to remain
compatible with older implementation. Since ASAP is a new protocol, and
all implementations are new, and because reference parameters are optional
dependent upon the protocol, we should take the position that reference
paramters MUST NOT be used in ASAP exchanges. There is no need for them,
and to clarify implementation decisions they should be prohibited from ASAP
implementations.
<Metadata> - this optional tag is not needed
by the ASAP protocol, but there is a potential use in service instance migration
when we get around to it.
Then there are the
tags for implementing the actual addressing.
<To> this
required tag carries the address part of the EPR. (and not the entire EPR
which would be more logical). It serves the same purpose as the former
ASAP ReceiverKey tag.
<ReplyTo>
carries an EPR. This is optional, but it is required if there is to be a
response. Since every ASAP exchange involves a response, this is
effectively required. It carries the address that the response will go
back to. This is meaningless in the case of HTTP where the response
is sent back over the same connection that the request was sent on. There
is, in fact, a special defined 'anonymous' value that can be used in this case
if you wish. This serves the same purpose as the former ASAP SenderKey
tag.
<FaultTo> is
an optional field to carry an EPR that error should be sent to. This sound more like someone's pet
feature than a good programming principle. It is not clear that sending
fault messages to a different place is a good idea. Nevertheless someone
wanted this flexibility. ASAP requires that every request gets a response,
and that response is either the successful completion of the operation, or a
fault message. Therefor, implementations of the ASAP protocol MUST NOT
specify a different fault address from the ReplyTo address, which means that
FaultTo should not be used.
<Action> - this is a required tag for protocols
where the the first tag in the body does not necessarily distinguish the
operation. The value here is a unique identifier of the operation.
For ASAP protocol, each operation has a unique tag in the body that
distinguishes it. In this case the value of the action
parameter should be the URL that is the namespace URL combined with
the name of the body tag, but the spec says that the WSDL can override this
convention and specify any unique IRI. For ASAP this is redundant,
but the WS-Addressing requires it.
<MessageId> - this is a unique id for the
message. It is required whenever there is a response message, and since
ASAP always involves a response message, the message ID is required. This
replaces the former ASAP RequestId tag.
<RelatesTo> - if this message is a reply
message, this tag carries the message id of the original message.
This replaces the ASAP former RequestId tag, when it is in a response
message. This tag has an optional parameter to tell what kind of
relationship, but the only relationship needed by ASAP is that of a response,
and for this case the attribute can be omitted.
<From> - the
meaning of this optional EPR is not defined. You can't send a message to
it, and it is not a secure field for authentication purposes. ASAP
protocol does not need a from field. It is STRONGLY RECOMMENDED that
implementations of ASAP omit this tag, and ignore the tag if
received.
(reference
parameters) - any reference parameters from the EPR are then placed in the
header of the message. As mentioned earlier, reference parameters MUST NOT
be used.
Backward
compatibility. Since we have a couple of implementations out there, for
maximum interoperability, one should implement the following
optional upgrade procedures. The former ASAP tags are considered
"deprecated", and are to be replaced by another "new" tag. When sending
message, both the deprecated and the replacement tag should be included.
The header is allowed to contain any amount of additional tags, so this should
not cause any problems. Upon receipt of a message, if the new tag is
present, it takes precidence, and the corresponding deprecated tag must be
ignored. If the new tag is missing, but the corresponding deprecated tag
is present, then the value should be received from the deprecated
tag.
New
Tag
Deprecated Tag
<To>
<ReceiverKey> Both carry IRI addresses
<ReplyTo>
<SenderKey> Deprecated carries just address, while new
tag carries EPR.
<MessageId>
<RequestId> (in request messages)
<RelatesTo>
<RequestId> (in a response message)
The second
specification is the "Binding to SOAP" which brings in some additional
requirements when addressing SOAP messages. Some further research is
needed because it is not clear to me what the impact of this spec
is.
A read through the
2a version of the ASAP spec, I see these action items:
- Change URL/URI to
IRI. Research whether this should be done across the board, or whether
it applies only to certain situations.
- Discuss the
proactive positions described above. If people agree, the change
descriptions to discourage use of FaultTo and From. Make a definition of
how the Action tag should be filled in.
- Response message
uses From as the address of the originally requested server. Does it
make more sense to use ReplyTo?
- What about the old
ResponseRequired tag? Do we want to continue with this, or drop
it?
- Add a small section
on backward compatibility.
I have made an
initial pass as modifying the document, a PDF showing changes is attached.
(I am not 100% sure I started with John's latest version, so need to chack
that.) This should just about do it. I don't see any reason why we
can't get an updated new version into Committee Draft status, why we can
not move forward with getting this through the OASIS process to an actual
standard.
-Keith
Keith D Swenson, kswenson@us.fujitsu.com
Fujitsu Software Corporation
1250 E. Arques Avenue, Sunnyvale, CA
94085
(408) 746-6276 mobile: (408) 859-1005
wd-asap-spec-02b_differences.pdf
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]