Preliminary Ocean Project Page 1 WGISS SG May 15, 2003 1 C. Caspar G. Tandurella P. Goncalves G....

1Preliminary Ocean Project WGISS SG May 15, 2003

C. CasparG. TandurellaP. Goncalves G. FallourdI. Petiteville

Preliminary Ocean Project

Phase 2

Status W. CudlipM. Hatcher


POP (Oil Spill Drift) ContextPOP (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,..


POP Project Status (1/2)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


POP Project Status (2/2)POP Project Status (2/2)• Current limitations:

– Only drifting service implemented with WSDL/SOAP. Interfaceaccess 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 !


POP ArchitecturePOP Architecture

ESA Drifting ServiceQINETIQ Drifting Service

Any Oil Slick Data Server

Any Meteo Server

Oil Slick Drift simulationoverlayed

Metadata for a particularOil Slick

Static layer Combination

Any GIS WMS server

XML proprietaryService + 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


POP Generic interfaces (1/3)POP Generic interfaces (1/3)

TAnyFeature

Name : stringValue : anyType

Unit : string

TService

Name : stringUrl : stringParams

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.


POP Generic interfaces (2/3)POP Generic interfaces (2/3)

Corresponding Schemas in WSDL file


POP Generic Interface (3/3)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


POP Specific Interface (1/2)POP Specific Interface (1/2)TParams

TAnyFeature

TService

TLatSpill

TWind


POP Specific Interface (2/2)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.


POP Server Side developmentPOP 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.


POP Client Side developmentPOP 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.

14Preliminary Ocean Project Page 14WGISS SG May 15, 2003

POP Client dev. (IE sample)POP Client dev. (IE sample)

Javascript example: <script language="JavaScript"> var iCallID = 0; function init() { wgiss.useService("http://webservices.instantlogic.com/zipcodes.ils?wsdl","MyHello");

iCallID = wgiss.MyHello.callService("ZipCodes","19355"); } function onWSresult() { alert(event.result.value["CITY"]); } </script>

<body onload="init()"> <div id="wgiss" style="behavior:url(webservice.htc)" onresult="onWSresult()"> </div> </body></html>

WSDL file

WebserviceBehavior

Operation (see WSDL)

Parameter requested (see WSDL)

Input value


POP lessons learned - client (1/3)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) !!


POP lessons learned - client (2/3)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.


POP lessons learned - client (3/3)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


POP demosPOP demos

• Demo from QINETIQ http://phyreworks.ath.cx:8080/pop

• Demo from ESA http://mapserv2.esrin.esa.it/map/pop/

Preliminary Ocean Project Page 1 WGISS SG May 15, 2003 1 C. Caspar G. Tandurella P. Goncalves G....

Documents

Transcript of Preliminary Ocean Project Page 1 WGISS SG May 15, 2003 1 C. Caspar G. Tandurella P. Goncalves G....