Using Web services in the European Grid of Solar Observations (EGSO)

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

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

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

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

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
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)
SOAPFault (if any)
AttachmentPart (optional)
MIME header
Content (e.g. pdf, JPEG)
9
Document exchange Web services (2)

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

request
response
Sender
Receiver
Messaging provider
10
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).

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_at_rl.ac.uk