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

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

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

3. 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. Introduction

4. 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.

5. 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. Web services for communication

6. 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

7. 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. 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. RPC-type Web services: JAX-RPC & Axis (2) Service implementation Client app. Stubs Ties Axis/JAX-RPC runtime Axis/JAX-RPC runtime SOAP messages HTTP transport Service implementation Client app. Axis/JAX-RPC runtime Axis/JAX-RPC runtime SOAP messages HTTP transport

8. 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. Document exchange Web services SOAPMessage SOAPPart SOAPEnvelope SOAPHeader (optional) Header SOAPBody XML content (if any) SOAPFault (if any) SOAPFault (if any) AttachmentPart (optional) MIME header Content (e.g. pdf, JPEG)

9. SOAP messages are sent over a connection: SAAJ uses a SOAPConnection to send messages over a point-to-point connection (request-response messaging). JAXM uses a ProviderConnection to send messages via a messaging provider (asynchronous). 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. ebXML, SOAP-RP). Continuously active (can resend messages until delivered, and store incoming messages for application). Can send messages to multiple intermediate destinations. Document exchange Web services (2) request response Sender Receiver Messaging provider

10.  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). Experience

11. 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/QoS: 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 QoS.

12. 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