A Non-Anonymous Wish List To Santa

Former Member · ‎12-28-2005

As a member of the WS-Addressing working group in W3C, I am
reflecting on where we are with some holiday spirit.

If you are a Web Services follower/developer, you are probably
aware that WS-Addressing working group has started in the Fall of 2004
as a fast track working group and made considerable progress within
2005 [WS-Addressing]. However, we are not
close to being done as suggested by our charter and this blog discusses
why.

A detailed summmary of WS-Addressing as well as its key differences
from the original summission to the W3C [[Submission] | #submission] will be the focus of a different
document. The focus of this blog is about a specific aspect of these
specifications, namely the use of anonymous addresses in
WS-Addressing. You can safely skip the following Section if you are
well versed in WS-Addressing and read why WS-Addressing may be related to
communicating with Santa in the subsequent section.

Brief Overview of WS-Addressing

WS-Addressing is a family of specifications (as there are three!)
that is key for Web Services, like WSDL [WSDL
1.1], and SOAP [[SOAP 1.1] | #soap11], [[SOAP 1.2] | #soap12]. The intent of the WS-Addressing
specification is to enable the end-to-end transmission of messages in
a transport neutral manner to enable communication with endpoints. As
you may already know, an endpoint designates an entity or a resource
to which Web Service Messages can be addressed. An endpoint may be
accesible via multiple ports in multiple WSDL documents as it may have
many such descriptions.

WS-Addressing defines dereferanceable endpoint references (EPR) to
enable communication with endpoints. Being able to use references to
endpoints within messages or within protocol headers has a tremendous
value for other specifications, therefore WS-Addressing is a key
building block for Web Services. Today, many other Web Services related
specifications utilize the definition of EPRs within protocol
specifications, such as WS-Reliable Messaging [WS-RX]
or within messages to refer to other services, such as WS-Notification
[[WSN] | #wsn], WSDL 2.0 [[WSDL 2.0] | #wsdl20].

WS-Addressing also defines a set of abstract message delivery
properties. Abstract message properties define the recipients of
messages (such as response and fault messages) as EPRs well as the
message identity and relationships for correlationg messages with each
other for formulating message exchanges.

As indicated earlier, the intent of WS-Addressing is to be
transport neutral for addressing messages to an endpoint. While doing
so, however, WS-Addressing fundamentally changes the way that current
Web Services stacks must use known SOAP/HTTP bindings. This particular
aspect affects other key Web Services specifications, such as WSDL and
SOAP1.x/HTTP. An abstraction is only useful if the underlying layers
could provide the intended flexibility. The problem is with the
utility of the abstract message properties and whether they can be
used as intended in a transport neutral manner, where known bindings
on transports may not be providing the intended flexibility, yet.

There are 8 abstract message properties that "augment" a message that
may be communicated with an endpoint. Among these abstract
message properties, three of them are of interest since all of them
utilize EPRs:

source endpoint (designates the sender of the message)
reply endpoint (designates where the response must be sent)
fault endpoint (designates where the fault must be sent)

These properties get serialized as SOAP headers and allow the SOAP
binding to deliver the message to the appropriate destination, for
delivering a reply, etc. Further, other specifications may use EPRs in
protocol definitions, such as the definition of the AcksTo
header defined as an EPR in the WS-ReliableMessaging specification.

Anonymous URIs

WS-Addressing specifies a specific address value that designates
the address of an EPR: anonymous URI. When Anonymous URI is specified
as the address of an EPR, it designates a "special" address whose
meaning is specific to a protocol binding. In a SOAP/HTTP binding, the
anonymous URI indicates a "channel" to an endpoint, for example when
the binding supports the SOAP request/response pattern. In this case,
the reply messages would be tranmitted using the underlying HTTP
connection (and hence the HTTP response). In essence, the semantics of
using an anonymous URI as the reply endpoint's address indicates a
synchronous message exchange with the endpoint using SOAP/HTTP.

Current SOAP 1.x/HTTP bindings are inherently synchronous for
request-response. Therefore, WS-Addressing could not really be independent
of transports as the flexibility intended is not necessarily provided
by the current bindings.

With this in mind, you may wonder what happens when the response
messages should not be targeted to anonymous addresses? With SOAP
1.x/HTTP and WSDL 1.1 as well as WSDL 2.0, we get synchronous
request/response by definition and WS-Addressing does not really buy
much if we were to stick with this limitation (and use
anonymous-addresses within our response EPRs, such as reply
endpoint/fault endpoint). In essence, WS-Addressing would not provide
much utility as anonymous URIs designate what is available today,
using the HTTP backchannel for the response messages. Most of the
promised utility of WS-Addressing is when an endpoint can send replies
to either anonymous and non-anonymous addresses. Further, there is
also an expectation that an endpoint may support multiple transports,
such as SOAP/HTTP, SOAP/SMTP etc that could be used in sending a
response message. The latter issue affects how the WSDL that defines
the endpoint specifies message exchange patterns and whether different
protocol bindings could be in effect within a single message exchange
for this endpoint. Today, a request-response is inherently governed by
the same protocol and transport binding, but WS-Addressing allows an
endpoint to do more.

Well, how is this related to sending a letter to Santa Claus?

This diagram is part of the series of messages that constitute the
test suite for WS-Addressing message exchanges [[TestMessage] | #message]. Note that what is needed is known,
but not yet standardized within the protocol specifications so that
all Web Services stacks can implement the behaviour interoperably

Simple, isn't it? Wait, but can the HTTP response to the first
request (in) message contain a SOAP envelope or is it a plain HTTP
response with no SOAP envelope (obviously there must not be a SOAP
body in the acknowledgement)? Well, we are back to the questions (2)
above, as we are not quite sure how to formulate the one-way/request
(in) message exchange quite well, yet. If we were to follow the BP 1.0
rules as indicated above, this would mean that no additional headers
could be included in the HTTP response as there would be no SOAP
envelope. This would hinder other specifications that layer on top of
WS-Addressing to include additional headers as part of the
acknowledgement. Unfortunately, the community has not agreed on this
specific point as to whether WS-I BP rule has to be retained or broken
at the time this blog is written.

If you look at from Santa's perspective, Santa's Web Service
endpoint would unfortunately require anonymous addresses for reply
endpoints in order to comply with the current SOAP/HTTP specifications
and existing toolsets for interoperability even if WS-Addressing was
engaged . Using Santa's Web Service with anonymous URIs
as reply addresses would be somewhat analogous to using a special courier to
whom I will give my wish list and assume that it would be hand
delivered to Santa. The Courier would have to wait until Santa decides
about my fate for receiving the response and compose one. The same
courier would then get Santa's response to me indicating when my wish
list item would ever be will be delivered while I am waiting for the
special courier's return. It would be that crude and a big waste of
time for everyone as Santa will never be able to deliver the list for
all of us!.

Delay in answers to these questions will make WS-Addressing not
very useful in practice, unless a SOAP/HTTP binding extension for
SOAP1.1/HTTP or an errata for SOAP 1.2/HTTP or a new asynchronous
SOAP/HTTP binding is collectively agreed upon and standardized. Sadly,
the intended message exchanges are part of the WS-Addressing test
suite, but since they will require changes/updates to the existing
SOAP 1.x specifications, the debate as to who takes care of this
problem is still ongoing. We could hope to conclude the debate for
SOAP 1.1/HTTP in WS-Addressing, but SOAP 1.2/HTTP belongs to XMLP
working group. This issue is hotly debated [XML-discussion] and would take a while to solidify
in 2006.

The following specific wish is for Santa to
deliver next year:

I wish that asynchronous SOAP1.x/HTTP bindings to be
finally solidified in 2006, specifically for SOAP 1.1/HTTP by the
WS-Addressing working group itself since most of the Web Services are
built today using SOAP1.1/HTTP. This will make an interoperable
endpoint for Santa a reality sooner than later. Otherwise,
WS-Addressing will not be able to deliver on its promise, namely
providing transport independent message delivery in an interoperable
fashion.

I do not want
to wait until next December...