The WMProxy service exposes operation through a WSDL interface:
http://trinity.datamat.it/projects/EGEE/wiki/WMProxy.wsdl
The most important purpose of SOA is to achieve loose coupling among interacting components allowing implementation of autonomous services. The loose coupling is achieved through a small set of simple and ubiquitous interfaces, and a set of descriptive messages.
In the interfaces only the generic semantics are described: the necessary semantic needed to anticipate possible server behaviour. These interfaces are theoretically available to the global Internet community.
The messages represent the way of communication between server and client, and must be descriptive and non-instructive: the server is the only one responsible for the specific design and implementation of the provided service. The messages must be also extensible to allow changes in the service, if needed.
To adhere to the SOA model during design and implementation of the WMProxy, the previous guidelines were adopted trying at the same time to provide good service performances to fulfil the user needs for Quality of Service (QoS).
Since the WMProxy is a SOAP Web service, the interface is described through the WSDL. A WSDL file represents the available interface needed by the client to access the service. In this file all the operations (services) provided by the WMProxy are described with their argument list, the return value (or structure) and the fault messages.
The WSDL file was written following the WS-I Basic Profile. This profile defines a set of Web service specifications that promote interoperability. WS-I Basic Profile addresses the most common problems that could generally affect interoperability, although conformance to it does not completely guarantee the interoperability of a particular service.
The profile defines a basic level of conformance based on artifacts. There are three kinds of artifacts, these are:
- MESSAGE
- DESCRIPTION
- REGDATA
WMProxy takes into account the DESCRIPTION artifact, i.e., the descriptions of types, messages and interfaces with protocols, bindings and access points are included in the WSDL file. Compliance of MESSAGE artifacts is assured by the used SOAP container (gSOAP), while the REGDATA principally refers to service registration and discovery with services like Universal Description, Discovery and Integration (UDDI). The latter aspect has not yet been considered exhaustively as it was not a requirement in the EGEE project where a proprietary service discovery mechanism is used.
Besides types, messages and interfaces a WSDL file also describes their protocol, data format bindings and the network access points.
An instance of a Web service (or a port, represented inside the WSDL file with the wsdl:port tag) is considered conformant if it produces conformant artifacts, and is capable of consuming conformant artifacts, as appropriate. The profile considers all the instances defined for the service (the ports), and verifies the conformance for any of them. Types of Web services (wsdl:binding and wsdl:portType tags) are considered conformant if they result in conformant instances.
These are basic rules completed by profile normative statements. In general, to implement a WS-I compliant service, the profile requires a WSDL file, which is composed of specific parts and both describes the service and follows a mandatory structure.
The WMProxy WSDL file defines two different ports to provide WMProxy-specific and delegation services (described through an imported WSDL file). This delegation service is the standard service used throughout all gLite, and it is being modified to be aligned with the GT4 delegation service.
WSDL type definition of operation arguments is provided to guarantee the correct behavior of all service operations, when accessed from varied language implementations of the requesting client (interoperability). Programming languages have different ways to treat with operation arguments, and different emitters create specific kinds of stub and skeleton (proxy).
In the WSDL file, fault messages are also described. These messages are sent back to the client in case of malformed client requests, or in case of service failure. To handle them with a simple, structured approach, an ad-hoc XML Schema type has been designed: the BaseFaultType. The specific fault complex types are developed to extend the BaseFaultType type, and any fault is handled as a BaseFaultType fault at higher level. Work is on-going to make the BaseFaultType definition fully compliant with the WS-BaseFaults specification.
