ANÁLISIS DE LOS RESULTADOS

wsdl [33] is an xml grammar used to specify Web Services and how to access them. A wsdl _{document defines a service as a collection of endpoints, or ports.}

Each port exposes a number of operations which the service supports. An opera- tion is defined in terms of the input message it consumes and the output message it produces. A message has a number of uniquely named parts, the type of which is specified by a reference to an xml _{schema definition [41]. Custom schema defi-}

nitions may also be included in thewsdldefinition. The definition of the service, ports, operations and messages is done at an abstract level and bound to concrete execution models via the service bindings. The service binding specifies which type of protocol and datatype encoding is used for each operation, effectively stating how to invoke the service. By using a two tier model in which the service definition is given at an abstract level and its implementation is defined in terms of those abstractions, we are able to view many different Web Service implementations through a common interface. For example, asoap _over http_{binding, and a} jms

[55] binding could both be specified for the same operation allowing clients from different platforms to utilise the same service.

We give an example wsdldocument for the DDBJ-XML Bioinformatics service, used in our use case, in Listing 7.1. After the namespace declarations, the<types>

element declares the types used by the service. The <DDBJXML>element definition is imported from an external schema. Following the type specification, the wsdl

document declares two messages: the getEntryIn and getEntryOut messages, each of which has one part denoting the contents of the message. For the input mes- sage, there is only one part called accession id of type DDBJ:ACCESSION. The output message also contains one part of type DDBJ:DDBJXML - a custom type to hold the Sequence Data Record. The <portType name=’DDBJPortType’> el- ement describes an endpoint which offers an operation called “GetEntry” which can be used to get Sequence Data Records. The input and output of this op- eration is specified by a reference to the previously defined wsdl _{messages. The} <binding name=’DDBJBinding’ type=’tns:DDBJPortType’>element provides a binding for the abstractly defined portType GetEntry.

A typical Web Service is implemented using soap [52] encoding overhttp trans- port (as the DDBJ-XML service does). In this case, the service binding states that the message contents is placed inside a soap _{message and sent over} http_.

A soap message (or envelope) is an ordinary xml document that conforms to a specific schema defined at http://www.w3.org/2001/12/soap-envelope. The

<?xml version=’1.0’ encoding=’UTF−8’?> <definitions name=’DDBJService’ targetNamespace=’http://jaco.ecs.soton.ac.uk:8080/DDBJWrapper/ddbj’ xmlns:tns=’http://jaco.ecs.soton.ac.uk:8080/DDBJWrapper/ddbj’ xmlns:DDBJ=’http://jaco.ecs.soton.ac.uk/schema/DDBJ’ xmlns:soap=’http://schemas.xmlsoap.org/wsdl/soap/’ xmlns:http=’http://schemas.xmlsoap.org/wsdl/http/’ xmlns:mime=’http://schemas.xmlsoap.org/wsdl/mime/’ xmlns:xsd=’http://www.w3.org/2001/XMLSchema’ xmlns:soapenc=’http://schemas.xmlsoap.org/soap/encoding/’ xmlns:wsdl=’http://schemas.xmlsoap.org/wsdl/’ xmlns=’http://schemas.xmlsoap.org/wsdl/’> <types> <xsd:schema targetNamespace="http://jaco.ecs.soton.ac.uk:8080/DDBJWrapper/ddbj"> <xsd:import namespace="http://jaco.ecs.soton.ac.uk/schema/DDBJ" schemaLocation="http://jaco.ecs.soton.ac.uk/schema/DDBJ.xsd"/> </xsd:schema> </types> <message name=’getEntryIn’>

<part name=’accession id’ element=’DDBJ:ACCESSION’/> </message>

<message name=’getEntryOut’>

<part name=’record’ element=’DDBJ:DDBJXML’/> </message>

<portType name=’DDBJPortType’> <operation name=’GetEntry’>

<input name=’getEntryIn’ message=’tns:getEntryIn’/> <output name=’getEntryOut’ message=’tns:getEntryOut’/> </operation>

</portType>

<binding name=’DDBJBinding’ type=’tns:DDBJPortType’>

<soap:binding style=’document’ transport=’http://schemas.xmlsoap.org/soap/http’/> <operation name=’GetEntry’> <soap:operation soapAction=’GetEntry’/> <input name=’getEntryIn’> <soap:body use=’literal’/> </input> <output name=’getEntryOut’> <soap:body use=’literal’/> </output> </operation> </binding> <service name=’DDBJService’>

<port name=’DDBJPort’ binding=’tns:DDBJBinding’>

<soap:address location=’http://jaco.ecs.soton.ac.uk:8080/DDBJWrapper/ddbj’/> </port>

</service> </definitions>

Listing 7.1: WSDL Document describing the DDBJ-XML sequence retrieval

<soap:envelope> <soap:body>

<getEntryIn>

<DDBJ:ACCESSION>AB000059</DDBJ:ACCESSION> </getEntryIn>

</soap:body> </soap:envelope>

Listing 7.2: Example SOAP envelope using RPC style

<soap:envelope> <soap:body>

<DDBJ:ACCESSION>AB000059</DDBJ:ACCESSION> </soap:body>

</soap:envelope>

Listing 7.3: Example SOAP envelope using Document style

fundamental purpose of soap _{is to provide a standardised protocol for the ex-}

change of information between distributed system components. In terms of Web Services, these components are the client and the service provider. During the invocation of a soap _encodedwsdl_{Web Service, a} soap _{envelope is created and}

the message parts are placed inside it. The format of thissoap envelope depends on the binding style specified in the wsdl binding. The two types of style sup- ported are document and rpc. With rpc style (see Listing 7.2), the child element of the <soap:body> node in the soap envelope has the same name as the wsdl

operation name. The children of this operation node correspond to each of the message parts: each child element taking the same name as the message part name. With document style (see Listing 7.3), the children of the <soap:body>

node correspond directly to the message parts (there is no node corresponding to the operation name - usually the SOAPAction http _{header is used to distinguish}

different operations). They are not named according to the message part names, instead they are named after the xsd element they refer to.

In trivial cases the part type will be a simple, predefined type such as string or in- teger. However,xsd_{allows for the specification of complex types: an}xml_element

that contains other elements (simple or complex). Existing Web Serviceapis such as Apache orjax-rpc use classes to encapsulate thexsd type and serialisers are registered to transform an object instance into the desired format. With complex types, such classes have to be created and compiled prior to execution and their corresponding serialisers registered at runtime. In terms of dynamic invocation, the problem is simple: without hard-coded classes to represent the complex types

specified by the service provider, execution by the client is impossible. Therefore, we have developed an alternative message representation and invocation technique: instead of storing the message parts using classes, we define anxml_{representation}

of awsdl_{message that is independent of binding style. This allows us to specify}

inputs to a wsdl service without knowing its implementation and hence provide dynamic invocation. It also simplifies the integration of the dwsi _{with the} C- Mediator _{since all Web Services messages are instantiated in} xml_{format. Our} java based Dynamic Web Service Invoker (dwsi) is able to invokewsdlspecified services when given inputs in thisxml_{format, and returns the results in the same}

format. The following sections define the xml _{representation with examples and}

the interface to our dwsi.