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
- 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.