Using Web services in the European Grid of

Using Web services in the European Grid of Solar Observations (EGSO) Simon Martin & Dave Pike Rutherford Appleton Laboratory, UK

Outline • • Introduction to EGSO architecture Using Web services in EGSO Web services examples – RPC type & document exchange • Experiences & problems • Summary

Introduction • The problem in solar physics: – Researchers need data from multiple instruments (see right). – These data are heterogeneous & stored in very large archives. • EGSO is a Grid test-bed, whose aims are: – To federate multiple data archives and provide users with tools to locate and retrieve data sets. – To reduce the amount of data to be transferred to users by providing processing facilities within the Grid.

EGSO Architecture • EGSO architecture (right) defines 3 roles: – Consumer (represents user interaction). – Broker (contains provider information). – Provider (data access & services). • Roles communicate exclusively via an External Interaction Subsystem. – Information to be exchanged includes metadata catalogue fragments (XML), strings, images and SQL queries. – Web services will provide the communication infrastructure in the trial version of EGSO.

Web services for communication • Why use Web services? – Relatively simple and lightweight to implement. – Loose coupling. – Promote modularity. – Open standards promote interoperability. – Use Internet protocols. – Globus Toolkit 3 is implementing OGSA, based on Web services. – … • We have investigated RPC and document exchange type Web services for use in EGSO: – Java Web Services Developers Pack (JWSDP) is an integrated toolkit for building Web services. • Includes APIs and reference implementations for both types of Web service, and tools for deployment and configuration. – Apache Axis is a SOAP processing engine for building RPC-type Web services. • Includes APIs and tools for developing RPC-type Web services.

RPC-type Web services: JAX-RPC & Axis • JAX-RPC (Java API for XML RPC) and Apache Axis provide APIs and tools to allow easy development of RPC-type Web services: – Hide complexity of SOAP, XML, HTTP from developer. – Serialize/de-serialize Java types to XML representation and vice-versa. – Use SOAP messaging over HTTP. • RPC services are classes with public methods exposed as Web services: public class RPCExample{ public String response(){ return (“Hello World!”); } } • Web Services Description Language (WSDL) documents for RPC services can be obtained by: – Command line tools, or – Appending ? WSDL to URL of Web service. • WSDL can be used by third party developers to create clients, or by service developer to create stubs and ties for their client and service.

RPC-type Web services: JAX-RPC & Axis (2) • JAX-RPC & Axis clients can be written in 3 ways: – Dynamic invocation interface (DII) (bottom right). • No stubs/ties; WSDL not necessary. • More coding • Flexible. Service implementation Client app. Stubs Ties Axis/JAX-RPC runtime SOAP messages HTTP transport – Using static stubs (top right). • Tool creates stubs and ties c. f. RMI; client operates on proxy (stub). • Less code than DII. – Dynamic proxy. • No stubs, client creates proxy class at runtime from WSDL. • More portable than static stubs. Axis/JAX-RPC runtime Client app. Service implementation Axis/JAX-RPC runtime SOAP messages HTTP transport

Document exchange Web services • JWSDP provides JAXM (Java API for XML Messaging) & SAAJ (SOAP with Attachments API for Java). – SAAJ creates and manipulates SOAP messages (right), and can send them between SAAJ applications (synchronously). – JAXM adds functionality of using messaging providers for reliability, asynchronous messaging, use of profiles. • Information can be sent as part of the SOAP body (XML), or as an attachment (any content type). – It can be more efficient to send XML as attachments to save parsing the SOAP message. SOAPMessage SOAPPart SOAPEnvelope SOAPHeader (optional) Header SOAPBody XML content (if any) SOAPFault(if any) Attachment. Part (optional) MIME header Content (e. g. pdf, JPEG)

Document exchange Web services (2) • SOAP messages are sent over a connection: – SAAJ uses a SOAPConnection to send messages over a point-topoint connection (request-response messaging). request Sender response Receiver – JAXM uses a Provider. Connection to send messages via a messaging provider (asynchronous). Messaging provider • JAXM applications (peers) send messages using a messaging provider. – Providers take care of routing and transmission of messages. – Application must be in a Web container (Tomcat in JWSDP). • Benefits of using providers: – Transparency (does not require extra code). – Support profiles (e. g. eb. XML, SOAP-RP). – Continuously active (can resend messages until delivered, and store incoming messages for application). – Can send messages to multiple intermediate destinations.

Experience • • Once the basics of the APIs, deployment tools etc. have been learnt, it is quite straightforward to develop new services. We have successfully sent messages between applications with domain typical information using Axis, JAX-RPC, SAAJ and JAXM. JAX-RPC/Axis useful for simple functions (synchronous). SAAJ & JAXM can send XML fragments, images etc. – JAXM adds reliability, asynchronicity and ability to propagate messages to multiple actors. • Documentation is poor in parts. • Bugs in APIs/tools. • Large number of platforms to choose from, with different methods to learn (e. g. Axis, JWSDP, GLUE, WASP…). – Different levels of support, documentation etc. • Several potentially significant drawbacks (see below).

Potential Problems • Web services are still a young technology, and there are several areas of concern: – Security: authorisation, authentication, integrity, confidentiality. • Web services standards (e. g. SOAP) do not include security, but much work is being done e. g. WS-Security, SAML. – Performance: scalability, XML (bigger than binary files), SOAP parsing. . – Reliability/Qo. S: HTTP, availability…. • However, many of these are minor problems, or can be overcome. – Performance issues may be minor compared to time taken searching large archives. – Messaging providers can improve Qo. S.

Summary • Web services have the potential to fulfil the communications needs of EGSO. • Web services are relatively easy to develop and deploy. • Security needs serious consideration for use in ‘real’ system. • Need to examine performance and possible optimisations. http: //www. egso. org simon. martin@rl. ac. uk