Comments on implementation strategy

The technology recommendations by WP3 from autumn 2006 clearly define SOAP based Web Services as the main technology to be used in the EMBRACE Grid. The selected technology has convenient mechanisms for data and tool sharing between different sites as well as automated communication, machine-to-machine rather than involving human participation.

In our work on implementation of SOAP based Web Services we have had to face a number of choices where various aspects of the technology had to be taken into account. In the following we describe those considerations in detail. The following issues are discussed:

• Strong v. weak typing of Web Service input and output;
• Interoperability of Web Services.

Strong v. weak typing

The question here is how strongly typed the individual Web Services should be i.e. how much structure of the input and output data should be expressed in strictly defined data types. On one side we may choose to pass the output in one string, text or file object leaving it to the client to parse it at destination; on the other side we may pass the output in a strictly defined data structure leaving very little parsing effort to the client. The former way makes it convenient to create Web Services out of the existing command line applications but leads to extensive programming effort on the client side. The latter way has a higher development cost for the service provider but makes it much easier for the clients: the output arrives in an easy-to-access form - parsed on arrival - making it convenient to integrate with local routines and other Web Services. In fact, the WP3 recommendations discourage loose data typing as it weakens the advantages of the selected technology.

At CBS we have decided to implement strongly typed Web Services generally. However, we have identified a number situations where strong typing is not suitable:

• Designing structured output of a Web Service can be time consuming as it requires analysis of the semantics of the output. In most cases the person implementing the Web Service is an IT collaborator, not an expert on the scientific method itself. Therefore, for practical reasons, some Web Services should perhaps be implemented as loosely typed first and later modified, avoiding delays and allowing the community to start using them as soon as possible.
• Sometimes the output is a final product, not intended for further analysis by computer e.g. graphics, reports in PDF etc. There is no reason to spent time on giving such output further structure. However, even in such cases it is convenient for the client to receive some information on how to handle the output (see EMBRACEimage or EMBRACEdocument types).
• When the output is very large and/or very complex the parsing of XML can be so demanding that it creates problems on the client's computer, with memory and processor speed. In such cases it may be wise to pass the output as text, to be parsed later by dedicted scripts, perhaps on another server.

Interoperability of Web Services

The question here is related to the issue discussed above: if we are to use strictly defined data types are they to be defined by each service provider or should there be a common standard for all providers? Again, on one side, defining home-grown data types is a simple, distributed strategy where the implementation decisions are made locally by the service providers. On the other side, the clients will have to reformat the output from every service if they wish to use it as input to another service or integrate it with local software. Such effort is much smaller than parsing weakly typed data but it is nevertheless time consuming.

We have seen several examples of how easy it was to integrate Web Services where the output object on one service could be passed directly to another service as input. Therefore, in our own implementation effort we have tried to reuse data types whenever possible. We have defined a number of data types of general validity (see examples). We intend to use those data types consistently in our Web Services, simplifying implementation and usage.