TAG directions

I offer my thoughts for directions of the TAG.  I think there are some
discrete areas that are worthy of focus.  

- New architectures emerging, particularly Web services, Blogging/Atom,
and P2P

- Extending and describing existing architectures, such as Web
applications, Semantic Web, XML itself

- Elaborating on Architecture Properties, such as
Extensibility/Versioning, Asynchrony, and Stateful services.

 

Web services

Effectively, the Web services architecture is a separate architecture
from the Web architecture.  There are almost no services that are
generally considered Web services (that is use SOAP and/or WSDL) that
are on the Web.  Further, Web services clients rarely see Web
applications.  The attempt to unify the architectures in SOAP 1.2 with
the SOAP-response MEP simply have not been deployed.  This could be
because the community has not moved to SOAP 1.2, perhaps partially
because of the lack of WSDL 2.0 deployment.  However, I think it is much
more that Web services authors perceive little benefit in offering their
services on the Web.  For example, the WS-ResourceFramework[1] and
WS-Transfer[2] provide generic operations in SOAP for achieving state
transfer, despite proposal such as WS-REST [3] that could have
integrated the resource framework with the Web.

 

This separation, based upon SOAP and WSDL, is growing with the expected
widespread adoption of WS-Addressing.  WS-Addressing uses the SOAP
extensibility model for soap headers and endpoint reference structure
for primarily asynchronous interactions.  

 

To which that TAG should decide whether it thinks this separate
architecture is something that it can or should seek to address.  There
are some potential solutions, such as a SOAP HTTP Transfer Binding [4].
However, the combination of the SOAP extensibility model and the desire
for asynchronous interactions makes it difficult to cleanly map
ws-addressing into HTTP [5].

 

A great deal of the motivation for WS-Addressing design is to enable
asynchronous stateful services.  More on this in the properties section

 

Web applications, including good REST design

A significant percentage of new application design is termed Web
applications, typified by Amazon, Google, Yahoo, Atom, and others.
There is emerging interest in describing this, with WSDL 2.0[6], a
variety of other proposals[7], and a W3C Mailing list[8].  

 

Additionally, Peer to Peer networks, like BitTorrent and Gnutella
networks have created their own identifier schemes and protocols for
decentralized retrieval of resources.  To what extent has the web
architecture failed or been successful in achieving these protocols.

 

Architecture Properties

It is apparent that each new set of technology that either extends web
architecture or replaces web architecture does so to achieve certain
different architecture properties.  It is worthy of the TAG to describe
how to achieve certain architecture properties within current technology
and to motivate new designs to achieve the properties.  The TAG already
is focusing on Extensibility and Versioning, with positive results.  

 

Two other properties of interest are asynchrony and state.  A simple
summary of WS-Addressing is that it provides for protocol independent
asynchronous stateful services.  At a core, these are very different
requirements and properties than achieved by existing HTTP and REST
architecture.  Indeed, stateless architecture is a key constraint in
REST.   I have offered motivations for async[9] and stateful services
[10].  

 

However, a variety of technologies have emerged that have steadily moved
technology away from stateless synchronous HTTP-centric patterns.
Firstly, a very significant portion of the web is deployed using HTTP
Cookies to achieve stateful applications.  This is not acknowledged in
the Web or REST architecture and it is worthy of being addressed by the
TAG.   

 

Rohit Khare shows how REST can be extended for asynchrony [11], but this
doesn't appear to have caught on.  The limitations of HTTP Cookies, the
deployment of SOAP and it's XML based extensibility model, and the
desire for asynchrony have resulted in Web service specifications.  One
of the first was SOAP-Conversations [12], and we now have
WS-Addressing[13] at the W3C.

 

The TAG can have as significant a role as it wants in helping or guiding
application development to achieve these properties, and the extent to
which they are considered part of Web architecture.

 

[1] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrf

[2]
http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-transfer.pdf

[3] http://lists.oasis-open.org/archives/wsrf/200405/msg00018.html

[4]
http://www.pacificspirit.com/blog/2005/03/01/wsrest_continued_do_we_need
_an_http_transfer_soap_binding_and_simplified_wsdl

[5]
http://www.pacificspirit.com/blog/2004/12/20/ruminations_on_wsaddressing
_and_transfer_protocols

[6] http://www.w3.org/2002/ws/desc/

[7] http://www.pacificspirit.com/Authoring/REST/

[8] http://lists.w3.org/Archives/Public/public-web-http-desc/

[9] http://www.pacificspirit.com/Authoring/async/

[10]
http://www.webservicessolutions.com/index.php/ws/content/view/full/49955
/#2

[11] http://www.ics.uci.edu/~rohit/ARRESTED-ICSE.pdf

[12] http://dev2dev.bea.com/pub/a/2002/06/SOAPConversation.html

[13] http://www.w3.org/2002/ws/addr/

--------------------------------------------------------------------------------

Join CEO Alfred Chuang and CTO Mark Carges on June 15 for a unique online 
event, giving you the first look at a new category of enterprise software 
built specifically for Service-Oriented Architecture (SOA).

Register Now.  It's Free!

http://www.bea.com/events/june15