A Retrospective on the Development of Web Service Specifications

Web Services have gained considerable traction over the past several years, and are being increasingly leveraged within the academic, business and research communities. The Service Oriented Architecture (SOA) model engendered within Web Services provides a simple and flexible framework for building sophisticated applications. A slew of specifications addressing several core areas – such as reliable messaging, addressing, security etc – within distributed systems have emerged recently. The term WS-* is used as an umbrella term to collectively refer to these specifications. The use of XML throughout the Web Services stack of specifications facilitates interactions between services implemented in different languages, running on different platforms, and over multiple transports. This use of XML distinguishes Web Services from previous efforts such as CORBA (Common Object Resource Broker Architecture) to simply building distributed systems. In this chapter we describe our experiences with several Web Service specifications. In general lessons learnt, and design decisions made, during these implementations would be applicable to several other specifications. We begin this chapter with some observations regarding Web Service specifications in section 2. This includes a discussion on the SOAP-centric (Simple Object Access Protocol) [Gudgin 2003] nature of the specifications, their reliance on oneway asynchronous message exchanges, how a specification can itself leverage other specifications, and, finally, how these specifications are intended to be stackable to facilitate use in tandem with each other. Several specifications leverage the WS-Addressing [Box 2004a] specification and this specification has, in recent years, become the de facto standard to target Web Service instances; we also include a brief description of this specification. WS-* specifications are XML-based and have schemas associated with them. In section 3 we describe the choices available to designers for processing these schemas. In subsequent sections we describe the implementation strategy for various specifications that we have implemented. These include WS-ReliableMessaging [Bilorusets 2004] (hereafter WSRM), WS-Reliability [Oasis-WSR 2004] (hereafter WSR), WS-Eventing [Box 2004b] (hereafter WSE), WSContext [7], the Universal Description, Discovery and Integration (UDDI) [Bunting 2003], WS-Management [Arora 2005] and WS-Transfer [Alexander 2004a]. Depending on the interactions and exchanges that are part of these specifications the complexity of the implementation and corresponding deployments varies. The WSRM and WSR specifications pertain to providing support for reliable messaging between Web service endpoints. These aforementioned specifications guarantee delivery of messages in the presence of failures and disconnects; endpoints can also retrieve lost messages after a failure. The WSE specification provides a mechanism for routing notifications from the producers to the registered consumers. Consumers can register their interest in specific messages using XPath queries; only messages that satisfy the previously specified constraint are routed to a consumer. Implementation of the WSRM, WSR and WSE specifications are outlined in section 4. WS-Management facilitates the efficient management of distributed systems; this specification identifies a core set of Web Service specifications and usage requirements to expose a common set of operations central to all systems management. Our implementation is described in section 5. WS-Context models session metadata as an external entity where more than two services can access/store highly dynamic shared metadata. Extensions to the WS-Context specification and implementation are described in section 6. The UDDI specification defines a searchable repository of Web Service Description Language (WSDL) [Christensen 2001] specifications of Grid/Web Services. We have designed and implemented a hybrid information service that provides semantics for both types of information that are defined by the WS-Context and UDDI Specifications; this is described in section 7. Issues related to the use of Web Services in power and compute constrained devices such as mobile devices are described in section 8. In section 9, we discuss issues within a dominant Web Service container – Apache Axis – vis-a-vis support for interactions mandated within Web Service specifications. We also describe deployment strategies to cope with the constraints imposed within the container. In section 10, we describe use cases for these specifications. Specifically, we outline how we leveraged implementations of various WS-* specifications in various projects and settings. Finally, in section 11 we outline our conclusions.