Slides Martin

8/14/2019 Slides Martin

1/12

Using Web services in theUsing Web services in the

European Grid of SolarEuropean Grid of Solar

Observations (EGSO)Observations (EGSO)

Simon Martin & Dave Pike

Rutherford Appleton Laboratory, UK


2/12

OutlineOutline

Introduction to EGSO

EGSO architecture

Using Web services in EGSO Web services examples RPC type & document

exchange

Experiences & problems

Summary


3/12

IntroductionIntroduction 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 dataarchives and provide users withtools to locate and retrieve datasets.

To reduce the amount of data tobe transferred to users by

providing processing facilitieswithin the Grid.


4/12

EGSO ArchitectureEGSO Architecture

EGSO architecture (right)defines 3 roles: Consumer (represents

user interaction). Broker (contains provider

information).

Provider (data access &services).

Roles communicateexclusively via anExternal InteractionSubsystem.

Information to beexchanged includesmetadata cataloguefragments (XML), strings,images and SQL queries.

Web services will providethe communication

infrastructure in the trialversion of EGSO.


5/12

Web services for communicationWeb 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 isimplementing OGSA, based

on Web services.

We have investigated RPC anddocument exchange type Webservices for use in EGSO:

Java Web ServicesDevelopers Pack (JWSDP) isan integrated toolkit forbuilding Web services.

Includes APIs and referenceimplementations for both typesof Web service, and tools for

deployment and configuration.

Apache Axis is a SOAPprocessing engine forbuilding RPC-type Webservices.

Includes APIs and tools for

developing RPC-type Webservices.


6/12

RPC-type Web services: JAX-RPC & AxisRPC-type Web services: JAX-RPC & Axis

JAX-RPC (Java API for XML RPC)and Apache Axis provide APIsand tools to allow easydevelopment of RPC-type Webservices: 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 Webservices:

public class RPCExample{

public String response(){

return (Hello World!);

}

}

Web Services DescriptionLanguage (WSDL) documentsfor RPC services can beobtained by: Command line tools, or

Appending ?WSDL to URL of Webservice.

WSDL can be used by thirdparty developers to create

clients, or by servicedeveloper to create stubs andties for their client andservice.


7/12

RPC-type Web services: JAX-RPC & Axis (2)RPC-type Web services: JAX-RPC & Axis (2)

JAX-RPC & Axis clients can bewritten in 3 ways: Dynamic invocation interface

(DII) (bottom right).

No stubs/ties; WSDL notnecessary.

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.

Client app.

Stubs

Axis/JAX-RPC

runtime

Service

implementation

Ties

Axis/JAX-RPC

runtime

SOAP messages

HTTP transport

Client app.Service

implementation

Axis/JAX-RPC

runtimeAxis/JAX-RPC

runtime

SOAP messages

HTTP transport


8/12

SOAPFault (if any)

SOAPBody

Header

Document exchange Web servicesDocument exchange Web services

JWSDP provides JAXM (JavaAPI for XML Messaging) &SAAJ (SOAP withAttachments API for Java). SAAJ creates and manipulates

SOAP messages (right), and cansend them between SAAJapplications (synchronously).

JAXM adds functionality of usingmessaging providers forreliability, asynchronousmessaging, use of profiles.

Information can be sent aspart of the SOAP body (XML),or as an attachment (anycontent type). It can be more efficient to send

XML as attachments to save

parsing the SOAP message.

AttachmentPart (optional)

SOAPPart

SOAPEnvelope

MIME header

Content (e.g. pdf, JPEG)

SOAPHeader (optional)

SOAPMessage

XML content (if any)

SOAPFault (if any)


9/12

Document exchange Web services (2)Document exchange Web services (2)

SOAP messages are sent over aconnection: SAAJ uses a SOAPConnection to

send messages over a point-to-point connection (request-

response messaging).

JAXM uses a ProviderConnectionto send messages via a messagingprovider (asynchronous).

JAXM applications (peers) sendmessages using a messagingprovider. Providers take care of routing and

transmission of messages.

Application must be in a Webcontainer (Tomcat in JWSDP).

Benefits of using providers: Transparency (does not require

extra code).

Support profiles (e.g. ebXML,SOAP-RP).

Continuously active (can resendmessages until delivered, andstore incoming messages forapplication).

Can send messages to multipleintermediate destinations.

Sender Receiver

request

response

Messaging provider


10/12

ExperienceExperience

Once the basics of the APIs,

deployment tools etc. have beenlearnt, it is quite straightforward

to develop new services. We have successfully sent

messages between applicationswith domain typical informationusing Axis, JAX-RPC, SAAJ andJAXM.

JAX-RPC/Axis useful for simple

functions (synchronous). SAAJ & JAXM can send XML

fragments, images etc. JAXM adds reliability,

asynchronicity and ability topropagate messages to multipleactors.

Documentation is poor in parts.

Bugs in APIs/tools.

Large number of platforms tochoose from, with differentmethods to learn (e.g. Axis,JWSDP, GLUE, WASP). Different levels of support,

documentation etc.

Several potentially significantdrawbacks (see below).


11/12

Potential ProblemsPotential 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 muchwork 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/12

SummarySummary

Web services have the potential to fulfil thecommunications needs of EGSO.

Web services are relatively easy to develop anddeploy.

Security needs serious consideration for use in realsystem.

Need to examine performance and possibleoptimisations.

http://www.egso.org

[email protected]

Documents

Slides Martin