TAG Position for
Workshop on Web of Services for Enterprise Computing

Agenda

I normally open a presentation like this with a quick summary of what's to come. In this case, I propose:

• The role of the TAG and why we're interested in Web Services architecture
• Why is it important for Web Services to be part of the Web? What tradeoffs make most sense?
• The attempts the TAG and others have made to align Web Services with Web Architecture: TAG issues (whenToUseGet-7, endPointRefs-47, etc); TAG work with XMLP WG on SOAP; TAG agreement with Web Services Addressing WG on WSA Core; Recent concerns regarding WS-Transfer
• The TAG's concerns arise not just from a desire for architectural purity -- we believe there are important use cases that can be met when WS are appropriately aligned with the Web. Much of the presentation will discuss such use cases.
• Wrapup:
  • There are some very exciting use cases that become possible when the Web and Web services are well aligned.
  • We are open to practical compromises when there are good reasons.
  • The TAG is a resource, not just for negotiating features of specifications, but for understanding the tradeoffs available. Please work with us!

The following sections give a bit more detail on what would be covered on each of the points above. Please keep in mind this is very preliminary: comments are most welcome.

The TAG: Who are we? Why do we care about WS Architecture?

This section is in part to review our role for those W3C members who aren't clear, but especially to bring up to speed non-W3C members who may be attending the workshop.

• The roles and responsibilities of the TAG at the W3C
  • The TAG is the central coordinating body responsible for ensuring an effective and cohesive architecture for the World Wide Web. We are the senior technical body at the W3C.
  • Briefly explain role relative to the AB, the director, etc.
  • Point to Web Arch; TAG Findings list; Issues List. Highlight the ones pertinent to this discussion (whenToUseGet-7, etc.)
• Is the word Web in Web Services anything more than markitechture? We'll show today why it matters.
• Why can there be only one Web (Metacalf's Law, network effects, etc.)?
• But, is there really synergy between the resources that are Web Services, and other Resources that comprise the Web?
  • We think so.
  • We'll show why with concrete examples later in this presentation.
  • Properly integrating Web Services with the rest (pun intended?) of the Web brings real value to users.
  • We also realize that part of the reason for WS is to achieve uniform application integration across reliable messaging systems, etc., and to enable transactions involving more than two parties, or that run over hours, days and months as opposed to the few seconds maximum typical of HTTP.
• We have a responsibility to ensure that all concerned are working effectively together.

History of TAG's work on WS-related issues

• Key technology issues that arise when aligning WS with the Web:
  • Uniform identification with URIs: each resource of interest should be identified by a URI (not a URI+Ref Parms!)
  • Standardized interaction (typically using HTTP or HTTPs as an application protocol, not a tunnel).
  • Challenge: finding the right architectural balance when WS requirements go beyond what HTTP can easily deliver.
• The TAG worked with the XMLP Workgroup to enable SOAP to make proper use of URIs and HTTP GET: results not widely implemented (though the design seems workable)
• The TAG worked with the WSA workgroup to agree on a note that would clarify good practice in constructing EPRs. Unfortunately, indications are that many implementations ignore this advice. Indeed, one of the first examples in the WS Transfer submission seems to violate the agreed guidelines.
• These experiences suggest there is an opportunity to work toward a more frank and constructive relationship between the TAG and the Web Services communities. We'd like to do that.

Technology issue and use case: uniform identification

• The Web Architecture requires that each resource of interest be identified by a distinct URI.
• Tradition in Web Services is: one URI for the service (StockQuotesRUs); use cookies, EPRs, XML elements, etc. to identify individual resources (the stock quote for company X on day D).
• Use case: what can I do if we use URIs that I can't do if we use EPR Ref Parms?

  There is a a service that provides control for hardware devices. The service is identified by an HTTP URI, and it supports SOAP interactions, and maybe (see next use case) other HTTP interactions as well. The URI of the service is:

  http://iocontroller.example.com/controllerService

  The question is: should we identify each particular disk drive managed by the service with its own URI such as

  http://iocontroller.example.com/controllerService?device=diskDrive1

  or should we use an EPR such as:

  <epr:epr>
    <epr:address><http://iocontroller.example.com/controllerService</epr:address>
    <io:device>diskDrive1</io:device>
  </epr:epr>
  

  Here are some of the things that become possible if we use uniform naming with URIs that don't work with EPRs.:
  • When I send you a link to the device, I don't need to know why you're going to interact with it. Otherwise, I need to know in advance whether you're going to want an EPR or a URI.
  • There are many important technologies that work with URIs:
    • You can use HTTP to interact with the resource (next use case).
    • You can bookmark the resource.
    • Your Web page can link to the resource
    • Google can discover your resource by finding that link.
    • You can email a link to the resource and many mailers will know it's a link.
    • You can make RDF statements about the resource.
    • The device can support interaction through HTML Web pages as well as SOAP controllers -- see next use case.
    • Not bad for a start, but when you use URI's you are future-proofing: when new Internet technologies come along, they will almost surely work with URI-named resources first.
    • There is synergy among these uses: they add value to each other.

Technology issue and use cases: uniform interaction

• HTTP has important qualities that make it uniquely suited to Web-scale interactions.
• HTTP GET:
  • A distinguished operation for retrievals that are safe to do anytime
    • Web crawlers would be impossible without GET
    • If you want your resource to be discoverable, consider proper use of GET
  • Retrievals are strongly typed and self-describing. You can try interacting with a resource and then safely interpret (or know you can't safely interpret) whatever comes back.
  • Content negotiation allows the same URI name to be used for interactions using different formats: the same URI can get you a stock quote or control interface as text/html, as a SOAP envelope (application/soap+xml), as Plain Old XML (POX), or even as an image (image/jpeg).
• Use case: uniform interaction

  The disk drive resource discussed above is correctly named with a URI, and following the TAG's advice, safe retrievals for information such as the temperature of the drive, its online/offline status, the name of the device, etc. are implemented by issuing an HTTP GET to that resource. For the benefit of SOAP-based software, the device can use content negotiation to return a SOAP envelope using media type application/soap+xml. The power of SOAP headers is still available: e.g. the drive parameters may be encrypted using WS-Security, digitally signed, etc. The temperature is also available from the same URI as application/xml, which provides for easy integration with AJAX clients, and in a simple text/html page that displays the drive's temperature.

  Many of the advantages of this approach have been signaled above:

  • A user who is concerned about the status of the disk drive can email a link to support staff without knowing what sorts of tools will be used to query the device.
  • Support staff can paste the link into a SOAP based management tool, and AJAX-based interactive front end, or can just click on the link in an email to launch a browser to display the drive's status.
  • Later, when an RDF-based system is adopted for tracking information about device performance, the same URI can be directly used in making RDF statements about the device. Indeed, the device can respond to an HTTP GET by returning its status in the form of RDF XML or N3, which can be automatically retrieved and interpreted by RDF tools.
  • Depending on the information being returned, the results may be cacheable for some period. Because HTTP is being used in the standard manner, the HTTP proxies already deployed in the organization do the right thing, caching the information for whatever the server has indicated is a reasonable period of time. Such caching works not just for the HTML format, but also for the SOAP and XML forms.

• Anti-use case: nonuniform interaction

  The disk drive resource discussed above is correctly named with a URI, but even safe retrievals for information such as the name or the temperature of the drive are implemented by HTTP POSTing SOAP retrieval requests to the drive resource.

  Many of the advantages in the above use case are lost.

  • The cacheing infrastructure of the Web is not used. Indeed, except for the SOAP layer itself, none of the communications software involved can see that a "safe" retrieval is being done, or can optimize accordingly.
  • The opportunities to integrate SOAP support with existing tools such as browsers are greatly reduced. In the use case above, browsers need merely be configured to process application/soap+xml media types, and then ordinary links can be used for SOAP integration. With the "anti" use case, the user agent must know in advance that a POST is to be done.
  • Cacheing is one of the known hard problems in computer science. Insofar as caching is needed, much of the hard work that went into making URI and HTTP-based caching work will wind up being duplicated for the framework of EPRs plus SOAP.

Conclusions

• There are some very exciting use cases that become possible when the Web and Web services are well aligned.
• The TAG understands that the goals of Web Services go somewhat beyond what traditional Web infrastructure has been engineered to support; we are open to practical compromises when there are good reasons.
• The TAG is a resource, not just for negotiating features of specifications, but for understanding the tradeoffs available.
• Please work with us!