Transcript slides-martin

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
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
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
any)
SOAPFault(if
(if any)
AttachmentPart (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 (requestresponse messaging).
request
Sender
response
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
[email protected]