Kai Ruhl, Pablo Beltrami November 2009 Webservices for Distributed Access to Space Weather Models ESWW6, Bruges, Belgium

The Presenter Kai Ruhl Software engineer etamax space Braunschweig, Germany SWENET distributed computing

Goals of this talk The topic is space weather service provision... –i.e. provision of data or models –from a distributed computing perspective –what is possible for the future? Goals of this talk: –Awareness amongst service providers –What can be done with distributed computing? –RPC (remote procedure calls): Webservices and other methods

Part 1: Assumptions

Assumption 1: –You are a service provider –with a focus on nowcasts and forecasts –... less on events in the past

PC model impl (.exe) input data (files) input data (files) input parameters User output data (files) output data (files) Assumption 2: –You have implemented a space weather model –as software. –workflow: 

PC model impl (.exe) input data (files) input data (files) input parameters User output data (files) output data (files) Webserver raw data (FTP files) data processing Assumption 3: –You need regularly updated, recorded data –as model input: 

Programming-related definitions: –Function: A programmed method/function/procedure –Distributed: More than 1 computer –Remote: Somewhere on the internet Internet-related definitions: –Service or API: An interface to be called by program e.g. an Apache webserver called by a Firefox browser –Request, Response: Input and output parameters –XML: A text file looking mostly like HTML (a web page)

Part 2: Service provision choices

Service provision Basic service provision choices:... –a command line application –a Desktop application... –a website –a remote API local (1 computer) distributed (2+ computers & internet)

Service provision (1) User PC Cmd Model scientific implementation or classic engineering tool (with GUI mostly)

Service provision (2) User PC Cmd PC Browser Model WS Website Model SWENET services SPENVIS (common today)

Service provision (3) User PC Cmd PC Browser PC App Model WS Website WS RPC service Model operators, e.g. ESOC

Service provision (4) User PC Cmd PC Browser PC App PC Browser or App Model WS Website WS RPC service WS VO Model WS RPC service Model

Service provision (composite) WS RPC service WS e.g. Virtual observatory (VO) IPSAT WS RPC service SHIELD OSE WS RPC service SEDAT GOES protonsproton fluencesTID

Part 3: Distributed Computing

RPC: Remote Procedure Call Remote Procedure Call: –Inter-process communication –Usually to processes on other computers –Standard case: Calling a function on a server Basic remote procedure call choices: –binary formats –XML formats (standardised or proprietary)

RPC (1) User App DCOM service binary (propriet.) Model 1980s approach works only on one platform

RPC (2) User App CORBA service binary (standard) DCOM service binary (propriet.) Model 1990s approach platform independent (mostly)

RPC (3) User SOAP service App CORBA service binary (standard) XML (standard) DCOM service binary (propriet.) Model 2000s approach platform independent (more)

Part 5: Webservices

Web Services Web service characteristics –Function calls over HTTP(s) (in SOAP format) –XML messages for request and response –WSDL for service and data description SOAP service App (HTTP) 1. WSDL spec. 2. XML request 3. XML response

Developing a Webservice (1) Prepare WSDL (web service description): –Think about input (request) and output (response) –Think about functions (1 request, 1 response) –Document in WSDL (here: access to SWENET database) –Put WSDL file on your website

Developing a Webservice (2) Implement the webservice interface: –With any language of your choice (and an open source SOAP library), e.g. in Java or PHP –Functions and parameters must match WSDL

Developing a Webservice (3) Implement the webservice functions: –Make functions write input files (from request) –Make functions call model run –Make functions read output files (to response)

Webservice/SOAP assessment Advantages: –Platform and language independent –Easy to read, find bugs, protocol –Good connectivity (HTTP works everywhere) Disadvantages: –Text messages larger than binary messages, thus: –Relatively slow on the network

Webservice Libraries Open source webservice libraries: –Java: built-in since Java 6 older versions: Axis2 or Apache CXF (previously XFire)Axis2Apache CXFXFire –C++: gSoap2gSoap2 –C#: built into ASP.NET (attribute [WebMethod]) –PHP: built-in (class SoapClient) –Ruby: built-in (require 'soap/wsdlDriver') –Python: SOAPpySOAPpy –Perl: SOAP::LiteSOAP::Lite –Fortran:... not that ubiquitious

Part 5: Conclusion

Conclusion Webservices are good software practice –invites a wide variety of clients –supports practices like MVC, SOA Advantage for participating in SSA –or in any larger, distributed system. –your user interface is not the only one

Outlook In the future... –when all service providers have web services –when VOs and operators aggregate services Space weather still need common concepts. –a standardised vocabulary (“ontology”) –and common data interpretation Astrophysicists have begun this consolidation –Virtual observatories, SPASE ontology, VOTables data tables

Vispanet ESA is developing a virtual observatory prototype –space environment data from ground and space-based sensors –outputs from numerical models of the space environment –distributed system demonstrator allowing coupling of data & models providing warnings of space weather hazards for space systems Concepts from this talk: –will use ontology, maybe based on SPASE –will probably use web services or a custom variation

etamax space GmbH Richard-Wagner-Str. 1 D Braunschweig Tel +49 (0) Fax +49 (0)