When new software resources are developed, they must be distributed to potential users in order to be of any benefit to anyone other than their creators. There is a traditional method for doing so in which a version is made available – for example as a download or an item for purchase – and is then deployed as the new user sees fit. However there is a further possibility, employing the developing Web Services standards, under which resource creators instantiate the resource personally and provide a public interface to allow interaction with the resource. I will now provide an overview of how to deploy and utilize such a service.

Web Services is often misconstrued as meaning some page on the internet that provides a service to a user, such as a package holiday bookings site. However it is not the provision to a customer of details about particular available package holidays that should be referred to as Web Services, but the methods by which the bookings site can pass queries to and receive answers from other available resources. For example querying an airline company database for a list of available flights within given parameters may be possible via Web Services, if the airline company provides a public interface to their database – and the bookings site may take advantage of that service.

Web Services can be viewed as a form of distributed computing – like GRID services, they are services developed by disparate groups across varying regions, sharing common methods for interaction. As such, it is necessary for both functionality and development that some standard criteria are met. Thus in order, for example, for my research group to make available a public interface to some useful resource that we have developed, we should follow the available protocols. This would allow a member of a separate research group to use our interface by following the same protocols. The current standards are :

• XML (Extensible Markup Language)
• UDDI (universal description, discovery and integration)
• WSDL (web services description language)
• SOAP (simple object access protocol)

XML 1.0 is now quite well known and is the basis for many standard methods, as it provides a pretty stable basis to build on. Although there has been a shift from Document Type Definitions to Schema Definitions, XML itself has remained virtually unchanged for over ten years. SOAP is in version 1.2 and defines methods for accessing objects, and has developed over the years to provide a well recognised method for doing so. WSDL too, is becoming more common – it is currently in transition from the well used 1.2 version to a new, as yet unaccepted 2.0 version. UDDI – now in version 3 – then adds a method to make services available to new users. Further useful standards that one may come across in the Web Services business world are BPEL 1.1 – a Business Process Execution Language and a choreography description language for web services workflows is under development.

With these standards, we can make our service available. The first stage in doing so is to publish it somewhere, to enable new users to discover it and to query the requirements for using it. This is done using UDDI, publishing the details in a registry. A user can query such a registry to find services that a research group or business has made available, based on the type of service provided.

The actual format of such a service description is written using WSDL. We can write out a standard description of the methods and arguments that our public interface provides for users to interact with. This will specify the XML, via a Schema, that must be used in a message that is passed to the service.This description could then be followed to write a valid message that could be passed to our service, which we make available, for example, by putting it on an internet connected server running apache tomcat.

SOAP messages can then be passed to the service. SOAP is basically a protocol for remote services to communicate and transfer information with one another, thus allowing distributed applications to interact. However, it is only a communication method – once messages are received at either end, there must be something present that knows how to deal with the information contained.

Hence, Web Services are actually communications services that build on the likes of HTTP, SMTP and TCP/IP to provide additional functionality. They are services which, once set up, provide methods for machines to automatically pass information. They utilise modern standards implementation, all based on an XML foundation. This means that, like GRID services, they should be interoperable and extensible. However, there are some inherent limitations to such services that must be taken into account when considering them as a solution for software development or distribution.

A major issue is that of coupling – the concept of how tightly linked processes are. A telephone conversation, for example, is tightly coupled – there is a continuous connection between both users whilst messages are passed back and fore, whereas an email conversation is loosely coupled – the connection is dropped after each message is passed. Web Services, by their nature, fall into the loosely coupled category, as they are services that are developed by autonomous groups and then made publicly available via the internet as a communication medium – and the internet operates on passing individual messages. Each time a service is to be queried, a message is sent to it and then the connection is dropped, like an email. The service then creates a new connection for the reply. It is therefore necessary to consider the granularity of each interaction, as enough work must be done to compensate for the time taken to communicate.

Furthermore, the development of such a service requires maintenance of interoperability and availability. There is little point publishing a Web Service that is unavailable due to server downtime on 70% of attempts to contact it. Likewise, any changes made to the service should not change the public interface too greatly, or other services that depend on that interface will fail. Any changes to the interface must be documented and propagrated in order to maintain interoperability. Also, by the definitions of XML standards, it should be possible for older versions to maintain their level of interoperability with newer versions of the same service, rather than being broken by updates to the interface.

These aspects then have an implication for the design of Web Services, and for the design of software that relies on communication with such services. Parallels with the Object Oriented Design practices should be clear. Each service is an object, and messages should be passed between objects; variables are not shared; granularity is coarse – hence messages need to initiate a suitably sufficient amount of work to justify the communication overhead; standards are shared and must be adhered to; and one must consider the availabilty of standard repositories. Thus it makes sense to utilise an OOP principles in the development of software that is or that relies on a Web Service. Hence, Java is a commonly used language for such a process, though it is by no means a requirement – any language can be used, as long as it can sustain a suitable public interface.

In order to succeed in actually utilizing a Web Service provided by my research group, for example, one must first know the specification for interacting with the public interface. This may be provided by a member of the research group through some form of collaboration, or retrieved via the UDDI method from a registry. The WSDL document will then provide definitions of the methods and procedures the interface supports, and the data formats that must be adhered to when passing information to the methods. This activity is referred to as stub generation -essentially a set of stubs, or small methods, are defined by which the user specifies the interaction required from the service. Once the stubs are known, the user can write software – perhaps a new Web Service – to interact with the service based on those stubs. At this point, for example, one may write a Java program that utilizes a stub to make a call to the remote service, and retrieve and translate a reply.

It would be necessary for such a Java program not only to correctly utilize the stubs, but to ensure that suitable data is passed. The request that gets sent, and the response received, are the SOAP messages and, as such, the message body should meet the WSDL definitions for the service. The structure of the SOAP message should contain a header for additional content such as any authentication requirements, a body which contains the actual request to be executed, and a specially defined SOAP Fault element, defining a fault code and string content. Additionally, larger amounts of binary data can be sent as an attachment to the SOAP message.

Once the message is successfully received via the public interface, the SOAP XML will be used to specify the method to be called on the service server. The method will be executed with the provided data, and a new XML SOAP message will be created for reply. The reply will then be returned to the client – which may be the Java program that initiated the request – and the client must translate that SOAP message to retrieve the useful information.

Receipt of such a response would constitute a successful Web Service interaction, having utilised the published XML, UDDI, WSDL and SOAP standards. Clearly, this is a complex procedure and one may wonder whether it is worth all the effort over and above a traditional remote procedure call. Whilst it may seem, on a small scale, that it is not, the overall goals of interoperability, backwards compatibility and availability can only be met by adhering to such a stringent standards-based methodology. As the foundations for such services grow, the effort required to instantiate interaction between them should reduce, resulting in a richer, more robust suite of interoperable applications for future use. It would be of benefit to anyone hoping to make use of such Web Services to perform some examples before proceeding to utilize or develop services further. There is a great deal of information available on the internet, such as the standards definitions, and examples can also be found. Useful sites are listed in the below references.

REFERENCES

1. XML specification
2. UDDI specification
3. WSDL specification
4. SOAP specification
5. BPEL specification
6. WSDL definitions and example SOAP messages available at xmethods.com