webservices.xml.com: Web Services and Sessions

Web Services and Sessions
by Sergey Beryozkin | Pages: 1, 2, 3

In .NET

Time to REST

Representational State Transfer (REST) is an architectural style underlying the way the Web is built. It encourages thinking in terms of URIs and resources, but not in terms of messages, procedures, and objects, and may help in building web-friendly web services.

Acknowledging this fact, SOAP 1.2 Working Draft introduced the Web Method Specification Feature that allows the identification of the HTTP method (such as GET or POST) being used, currently supported by SOAP HTTP binding. Particularly, it recommends the use of the GET method in conjunction with the SOAP Response message exchange pattern for information retrievals that are safe and have no side effects, for which no parameters other than a URI and no SOAP request headers are required. SOAP 1.2 Part 0 Primer explains well how and when this feature can be practically applied.

Simon Fell, an author of a PocketSOAP toolkit, has done some experiments with a server implementation of the SOAP 1.2 GET HTTP binding for the SOAPBuilders Interop Registration and Notification Service, which allows toolkits builders to register server implementations and client results for a specific service used for interoperability tests. The service, which allows clients to query the registry for information about which servers provide implementations of a particular service is a good candidate for being accessed using the GET HTTP binding.

This is a fragment of an experimental XML schema types definition:

<xs:schema   targetNamespace="http://www.pocketsoap.com/registration/12/">
 <xs:import namespace="http://www.w3.org/1999/xlink"   schemaLocation="xlink.xsd"/>
 
<!-- not all elements and types are shown -->
<xs:element name="Toolkits" type="tns:Toolkits"/>
<xs:complexType name="Locator">
  <xs:simpleContent>
   <xs:extension base="tns:Empty">
      <xs:attribute ref="xlink:href" use="required"/>
      <!-- two other attributed are not shown -->
   </xs:extension>
  </xs:simpleContent>
</xs:complexType>
 
<xs:complexType name="Toolkits">
 <xs:sequence>
   <xs:element name="Toolkit" type="tns:Locator" minOccurs="0"  maxOccurs="unbounded"/>
 </xs:sequence>
</xs:complexType>
 
<xs:complexType name="Toolkit">
  <xs:sequence>
      <xs:element name="Name" type="xs:string"/>
      <xs:element name="Version" type="xs:string"/>
      <xs:element name="Homepage" type="tns:Locator"/>
  </xs:sequence>
</xs:complexType>
</xs:schema>

This schema defines several resource types such as a Toolkit and a Test (not shown in the above fragment), which can be identified by URIs. When an HTTP GET query about a particular type of resources is executed, a sequence of references (of type Locator) to resource instances is returned, which allows the retrieval of information about individual resources, each of them possibly providing links to other resources. For example, a response to a GET request to http://soap.4s4c.com/registration/toolkits/ looks like this.

<s:Envelope xmlns:s="http://www.w3.org/2002/06/envelope/">
 <s:Body>
  <q:Toolkits xmlns:q="http://www.pocketsoap.com/registration/12/" 
                  xmlns:x="http://www.w3.org/1999/xlink">
   <q:Toolkit x:href="19d3e126-317c-4680-9bad-0035cbf44c35"/>
   <!-- many more toolkits -->
  </q:Toolkits>
 </s:Body>
</s:Envelope>

Each <q:Toolkit> element refers to a particular Toolkit resource. By appending a value of an XLink x:href attribute to the original URI, information about the toolkit, such as its name, version and homepage, can be obtained.

It would be nice if it were possible to automate this process of the information retrieval, which requires type-safe proxy generation at run-time. For this to happen, it is necessary to identify at compile or deployment time a WSDL binding which can be used for accessing the resource instance a particular element, such as <q:Toolkit>, refers to. In fact, this is in essence (at least as seen by some people) of a WSDL requirement R085, which states that "a description language should allow describing messages that include references (URIs) to strongly typed referents, both values and Services".

This can probably be achieved by annotating locator elements with information about the relevant WSDL bindings using schema extensions. An annotation may be done only once per every specific locator. However, it might require all such locators be declared as global elements and referenced from elsewhere, as the same locator may appear as part of different elements. Also, some bindings may not be known at a schema design time.

Alternatively, this might be done by adding an element or attribute of type anyURI to a corresponding complex type, and stating in a WSDL port type definition that this element (attribute), identified by applying an XPath expression to an output/input of an operation, serves as a reference to a binding required for accessing a particular port type.

The proposal by Arthur Ryman shows how the requirement R085 can be resolved with the introduction of a new <wsdl:endpoint> element, which can identify URIs included either as hyperlinks using XLink or as part of endpoint references defined by WS-Addressing.

Resolving R085 will likely make it easier to write session-based web services. For example, another way to expose our application would be to GET a required device from a management service (assuming that obtaining a device handle can be regarded as a safe operation!) and then send the control requests to that device service with HTTP POST. This is nearly identical to the way we did it with one major difference: an application method is now GET rather than connect(). What is also interesting to observe is that in this case REST interactions can be considered as factory-based: each resource can implicitly serve as a factory by explicitly providing references to other resources in its state representation.

An interesting aspect of the REST approach to programming stateful web services is that it can make custom conversational policies unnecessary, as the current state of a conversation/session is normally represented by a resource addressable by a URL. A RESTful web service "guides" the clients through its state machine. More thoughts on this can be found here or by reading A Web-Centric approach to State Transition by Paul Prescod.

It may not always be possible or easy to commit to building web services the REST way, for example, when transport or different application protocols are used, SOAP headers need to be present. In such cases it's still worth putting some efforts into maximizing a visibility of a web service.

Conclusion

In this article I tried to assess different approaches toward building session-based web services. In general, it is recommended that web services be designed according to the principles of a service-oriented architecture. However, it is sometimes desirable to build services capable of referencing each other, which may lead to a finer-grained, session-oriented services design. When building a new service, it is worth considering carefully the pros and cons of both design styles, which can result in a better integration solution for a targeted domain.

Acknowledgments

This article was inspired by many other peoples' implementations, specifications and discussions of various session-related aspects of web services.

Many thanks to Steve Tuecke for detailed critical comments to the earlier version of this article.

Many thanks to Simon Fell, Jacek Kopecky and Zdenek Svoboda for reading the article and commenting on its various parts.

Resources

Web Services Interaction Models by Steve Vinoski.
A Young Person's Guide to SOAP by Don Box.
A Web-Centric approach to State Transition by Paul Prescod.

Share your comments on this article in our forum.
(* You must be a member of XML.com to use this feature.)
Comment on this Article