Using Web services in the

European Grid of Solar

Observations (EGSO)

Simon Martin & Dave Pike

Rutherford Appleton Laboratory, UK
 Outline

• Introduction to EGSO
• 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 Client app.

Service
implementation
written in 3 ways:
– Dynamic invocation interface Stubs Ties
(DII) (bottom right). Axis/JAX-RPC Axis/JAX-RPC
• No stubs/ties; WSDL not runtime runtime
necessary. SOAP messages
• More coding HTTP transport
• Flexible.
– Using static stubs (top right). Service
• Tool creates stubs and ties c.f. Client app. implementation
RMI; client operates on proxy
(stub). Axis/JAX-RPC Axis/JAX-RPC
• Less code than DII. runtime runtime
– Dynamic proxy.
• No stubs, client creates proxy SOAP messages
class at runtime from WSDL. HTTP transport
• More portable than static stubs.
 Document exchange Web services
• JWSDP provides JAXM (Java SOAPMessage
API for XML Messaging) &
SAAJ (SOAP with SOAPPart
Attachments API for Java). SOAPEnvelope
– SAAJ creates and manipulates
SOAP messages (right), and can SOAPHeader (optional)
send them between SAAJ Header
applications (synchronously).
– JAXM adds functionality of using SOAPBody
messaging providers for
reliability, asynchronous XML content (if any)
messaging, use of profiles.
SOAPFault(if
SOAPFault (if any)
any)
• Information can be sent as
part of the SOAP body (XML),
or as an attachment (any AttachmentPart (optional)
content type).
– It can be more efficient to send MIME header
XML as attachments to save
parsing the SOAP message. 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-to-
point connection (request-
response messaging).
request
response
Sender Receiver
– JAXM uses a ProviderConnection
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. ebXML,
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/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.
 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