Preliminary Ocean Project Page 1 WGISS SG May 15, C. Caspar G. Tandurella P. Goncalves G. Fallourd I. Petiteville Preliminary Ocean Project Phase 2 Status W. Cudlip M. Hatcher

Preliminary Ocean Project Page 2 WGISS SG May 15, POP (Oil Spill Drift) Context The POP allows any user to visualize the predicted drift of selected oil slicks, using a Web browser Prediction made possible thanks to a combination of calls made to several services (e.g. meteo, drift model,..) Technology tested in POP: SOAP, XML, WSDL, Web Services, Service chaining,..

Preliminary Ocean Project Page 3 WGISS SG May 15, POP Project Status (1/2) Phase 1 demoed in Toulouse (QINETIQ & ESA) Progress made since: Improve services interface using standards such as WSDL and SOAP instead of proprietary XML interface Service chaining: recursive service calls

Preliminary Ocean Project Page 4 WGISS SG May 15, POP Project Status (2/2) Current limitations: –Only drifting service implemented with WSDL/SOAP. Interface access to Oil Slick and Meteo Information still via conventional WMS/WFS I/F –Meteo data still returned GML 2 (target : GML.3 gridded coverages) –Client application not yet able to make direct SOAP calls to the service (Use of proprietary XML interface + bridge servlet to convert XML into SOAP messages) –Both IE and Netscape/Mozilla claim availability of Javascript support for SOAP and WSDL in practice (see later) not very mature yet or at least poorly documented, and not compatible !

Preliminary Ocean Project Page 5 WGISS SG May 15, POP Architecture ESA Drifting ServiceQINETIQ Drifting Service Any Oil Slick Data Server Any Meteo Server Oil Slick Drift simulation overlayed Metadata for a particular Oil Slick Static layer Combination Any GIS WMS server XML proprietary Service + parameters (value, services,..) ESA XML/SOAP bridge Services Descriptions (WSDL) SOAP request WMS, WFS (later SOAP) requests SOAP answer: URL (image), GML WMS, WFS (later SOAP) answers

Preliminary Ocean Project Page 6 WGISS SG May 15, POP Generic interfaces (1/3) TAnyFeature Name : string Value : anyType Unit : string TService Name : string Url : string Params TParamArray TParam Service or … Feature 0..n A request to a POP service is passed as an array of parameters (TParam) Each Parameters specifies either a “feature” (terminal value) a “service” (WMS, WFS …) Besides an URL and a name identifying its specific function (e.g.) WindDataServer, a Tservice may further specify an array of Tparam allowing to built service chains.

Preliminary Ocean Project Page 7 WGISS SG May 15, POP Generic interfaces (2/3) Corresponding Schemas in WSDL file

Preliminary Ocean Project Page 8 WGISS SG May 15, POP Generic Interface (3/3) Advantages –Abstract definition that can be used for any type of service –A single and simple schema can be shared for all services –Convenient for the definition of service chains. But –Because the calling interface is only described as an array of services or values : –No possibility to discover from the WSDL description what are the actual parameters expected by a service. => Definition of a second service specific interface

Preliminary Ocean Project Page 9 WGISS SG May 15, POP Specific Interface (1/2) TParamsTAnyFeatureTService TLatSpill TWind

Preliminary Ocean Project Page 10 WGISS SG May 15, POP Specific Interface (2/2) Advantages –WSDL describes both the generic interface using an array of parameters and the specific interface listing actual accepted services and values. –Allows a precise definition of a service specifying all allowed parameters including types and default or supported units. –Specific types are derived by restriction from generic type TAnyFeature and TService. Therefore even if a client does not make use of the specific interface, it can use its definition from the WSDL file to find out the parameters actually supported in the generic call.

Preliminary Ocean Project Page 11 WGISS SG May 15, POP Server Side development Several tools used to map WSDL interfaces to classes in java or other languages : –AXIS, GLUE, DELPHI No major problems but: –Automatic class generation from WSDL generally requires manual modifications. In particular : Some Schema constructions not supported E.g. definition of subclasses by restriction. Interoperability still to be verified.

Preliminary Ocean Project Page 12 WGISS SG May 15, POP Client Side development Primarly objective: –Direct SOAP call from client to avoid need for another interface definition (proprietary XML) –Simpler than passing XML code in HTTP/POST in particular to process the answer from the server (see next slide). –Use a generic web browser as client as this is the most common entry point to the internet for users. Feasibility: –WSDL/SOAP seemed supported by both from (IE 5.0) and Netscape (7.1) /Mozilla (1.4) –No compatibility between IE and Netscape code.

Preliminary Ocean Project Page 13 WGISS SG May 15, POP Client SOAP vs HTTP/POST When submitting an XML in HTTP/POST the browser expects to update the complete page or at least a frame. Work around solution existing using IFRAME for e.g. (as in the POP client demonstrated in Toulouse but quite heavy). When using SOAP APIs, server answers are collected into javascript objects which can then be processed to update any part of a page.

Preliminary Ocean Project Page 14 WGISS SG May 15, POP Client dev. (IE sample) Javascript example: var iCallID = 0; function init() { wgiss.useService(" iCallID = wgiss.MyHello.callService("ZipCodes","19355"); } function onWSresult() { alert(event.result.value["CITY"]); } WSDL file Webservice Behavior Operation (see WSDL) Parameter requested (see WSDL) Input value

Preliminary Ocean Project Page 15 WGISS SG May 15, POP Objects & Protocols WSDL example:

Preliminary Ocean Project Page 16 WGISS SG May 15, POP lessons learned - client (1/3) Direct use of WSDL and SOAP is not straightforward on the most generic clients: web browsers. From IE 5 supports WSDL hiding SOAP details but: –Very little documentation available. No example could be found for messages with complex types Netscape / Mozilla –Rather serious SOAP API allowing simple declaration of SOAP arrays and structures. –But a lot of time was lot because some of the required functions proved to be implemented only in the latest Mozilla implementation (v1.5 Beta) !!

Preliminary Ocean Project Page 17 WGISS SG May 15, POP lessons learned - client (2/3) Difficulty to find examples of non-trivial implementations it seems that very few people use web browsers to access web services.

Preliminary Ocean Project Page 18 WGISS SG May 15, POP lessons learned - client (3/3) Client SOAP requests cannot be sent to remote Web Servers (located in domains different from client’s) Can be sent only to a single local Web server (e.g. ESA gateway) Gateway acts as proxy to remote servers e.g. QINETIQ drift prediction server © Microsoft

Preliminary Ocean Project Page 19 WGISS SG May 15, POP Objects & Protocols WSDL example:

Preliminary Ocean Project Page 20 WGISS SG May 15, POP demos Demo from QINETIQ Demo from ESA