RECAMBIO DE LUMINARIAS LEDS POR LAS LUMINARIAS DE

2.6.1 Web Services

Web Services [52,53] define Service-Orientated techniques for the description, discovery and integration of remote software components, see Figure2.5. They have many benefi- cial characteristics suitable to Grid and distributed applications; such as, programming language and model independence, and platform neutrality. Moreover, Web Services’

UDDI

RegistryUDDIRegistryUDDI Registry

Client

Web Service Server Disc over y (Fi nd) De_scr iptio n (P ubli_sh) Integration (Interaction) WSDL WSDL

Implementation

Wire

Direct Discovery and Publish With WSIL WSDLWSDL

WSDLWSDL

Figure 2.5: Web Service usage of XML Technologies.

simplicity are their greatest strength; designed specifically to facilitate creation, deploy- ment, testing and utilisation within client and server software using widely available visual development [54] and client proxy generation tools [55].

2.6.1.1 Web Service Description Language

The Web Service Description Language (WSDL) [56] is an XML Document that provides a standardised means to formally define the interface and the endpoints of a Web Service. It is the IDL for software components (i.e. services) of SOA environments. Unlike IDLs in point-to-point architectures (see section 2.3.2), interfaces of Web Services defined in WSDL are independent from the underlying platform and programming language. This hiding of services vendor specific implementation facilitates the coupling of service which, in addition, to WSDL’s standards-compliance makes Web Services very reusable and interopable. Although originally designed to describe Web Services, WSDL is a flexible and extensible language that may be used to describe other service based distributed technologies like Grid Services [57]. WSDL 1.2 is now being adopted by the OGSI Working Group instead of GWSDL.

2.6.1.2 Universal Description, Discovery and Integration

The Universal Description, Discovery and Integration (UDDI) [58] specification defines a way to publish and discover information about web services. It is a collaboration between Ariba, IBM, and Microsoft, who each provides UDDI services. The UDDI project includes a UDDI business registry and a set of operations on it. The UDDI registry, an XML file, identifies a Web Service and provides information about the service. Other programs use the registry to get the information about the Web Service and check compatibility with it. Categorisation of web services in the registry enables location and discovery. UDDI together with WSDL provides the ability to locate and programmatically interface to the Web Service. This allows programmatical access to the Web Service in a similar way that a coder accesses software component, simplifying service collaboration.

2.6.1.3 WS-Inspection and Web Service Integration Language

WS-Inspection [59] consists of a simple XML language and conventions for locating ser- vice descriptions published by service providers. The language, Web Service Integration Language (WSIL), may contain a list of service descriptions and links to other service descriptions. These are links to WSDL documents through URLs and may reference an entry within a Universal, Description, Discovery, and Integration (UDDI) registry. Service providers make there WSIL documents accessible through normal Internet pro- tocol such as HTTP GET enabling document retrieval and discover of the advertised providers services.

2.6.1.4 Security

Efforts on ensuring security of Web Services have been focused on the standardisation of the WS-Security [60] protocol. WS-Security is a message-level security mechanism, which identifies enhancements to SOAP messaging to provide security through message integrity, message confidentiality, and single message authentication. WS-Security is designed to support a wide variety of security tokens, security models and encryption technologies. The specification has already been accepted as an OASIS standard. In addition, in order to enable the service to publish its security requirements, the WS- SecurityPolicy [61] specification is drafted as a supplement to WS-Policy.

2.6.1.5 Data Delivery

The XML format is not suitable for delivering large sections of data, especially binaries, due to its redundancy. To facilitate data transfer with Web Services and remain human- interpretable, an abstract model called SOAP Message Transmission Optimization (sic) Mechanism (SOAP MTOM) [62] is proposed to define how to encapsulate SOAP mes- sages and its associated attachments. This model has already been supported in Web Service tools from major software vendors.

2.6.1.6 Business/Application Process Orchestration

A series of proposals have been made to provide standard methods for composing multiple Web Services for sophisticated business/application processes. These include WSFL [63], and BPEL4WS [20]. At the current stage, BPEL4WS has received wide support from the Web Service community. It defines a model and a grammar for de- scribing the behaviour of a business process based on interactions between the process and its partners. It also defines how multiple service interactions are coordinated to complete an operation, how business exceptions and processing faults should be dealt with, and how compensation to participants in the process should be made in cases of exceptions and service cancellation.

2.6.1.7 Message Routing

To support asynchronous delivery of SOAP messages over a variety of transport methods such as TCP, UDP, and HTTP, the WS-Routing specification is proposed to make it possible to describe directly in the SOAP header the entire message path for a SOAP message. It is therefore possible to carry out SOAP messaging in different modes such as request/response and peer-to-peer conversations over extended period.

2.6.1.8 Reliable Messaging

The WS-ReliableMessaging [64] specification is proposed to ensure quality in service communications. It defines mechanisms to guarantee the delivery of SOAP messages, and to make sure that messages are only received once, and are processed in the right order. WS-ReliableMessaging is extensible to allowing integration of additional func- tionality such as security. The current specification is used with other Web Services specifications such as WS-Security and WS-Policy to provide secured and reliable ser- vice communications.

G rid P ro to co l A rc hi te ct ur e Application Collective Resource Connectivity Fabric Application Transport Internet Link In te rn et P ro to co l A rc hi te ct ur e

Figure 2.6: Shows the relationship between the Grid architecture and the Internet protocol architecture. There is a mapping from Grid layers to Internet layers because

the Internet protocol layer extends from network to application.