Containers and Web Services Grid Middleware 7 David Groep, lecture series 2005-2006.

Containers and Web Services

Grid Middleware 7

David Groep, lecture series 2005-2006

Grid Middleware VII 2

Outline

Why web services? Web services revisited

SOAP, WS-I basic profile, encoding styles Envelope versus body

Containers why containers pluggable frameworks (e.g. the GT4 security stuff) some leaky abstractions: file ACLs in the (Globus) RLS

Implementing grid middleware where to put the abstractions (crunching paper stuff) is stuff in the envelope really standard? syntax vs. semantics of the interface

Performance: Java, C, Python, .NET


Why web services came about in grid

The definition of WSRF means that the Grid and Web services communities can move forward on a common base.


Web Services

WS are just one implementation of a SOA we could have done ASN.1 over BEEP over avian carriers

(which might even have been faster ) but we don’t, to help interoperation

Web services are basically RPC using XML largely self-describing


Web Services hints

Web Services are just a syntax

Define proper sementics and document that to make your service re-useable

Match up the semantics with related services

Make sure your services are compliant with relevant standards (like WS-I Basic Profile) with the chosen hosting system (GT4)

WSDL Styles

thanks to the EGEE WS tutorial…


Types of WSDL SOAP binding

RPC/encoded

RPC/literal

Document/encoded

Document/literal


Java method example

public void myMethod (int x);


RPC/Encoded WSDL

<message name=“myMethodRequest”><part name=“x” type=“xsd:int”/>

</message>

<message name=“empty”/>

<portType name=“PT”><operation name=“myMethod”>

<input message=“myMethodRequest”/><output message=“empty”/>

</operation></portType>

Binding is RPC/encoded


SOAP message

<soap:envelope>

<soap:body>

<myMethod>

<x xsi:type=“xsd:int”>value</x>

</myMethod>

</soap:body>

</soap:envelope>


Advantages/disadvantages

Advantages Simple WSDL Operation name appears in the message

Disadvantages Type encoding information overhead SOAP message cannot be validated except against WSDL


RPC/Literal WSDL

<message name=“myMethodRequest”>

<part name=“x” type=“xsd:int”/>

</message>

<message name=“empty”/>

<portType name=“PT”>

<operation name=“myMethod”>

<input message=“myMethodRequest”/>

<output message=“empty”/>

</operation>

</portType>Binding is RPC/literal


SOAP message

<soap:envelope>

<soap:body>

<myMethod>

<x>value</x>

</myMethod>

</soap:body>

</soap:envelope>


Advantages/Disadvantages

Advantages WSDL is simple Operation name appears in the message Type encoding information is minimal

Disadvantages Nearly all the definitions in WSDL so not independently

validatable


Document/encoded

Not implemented !


Document/literal WSDL

<types><schema>

<element name=“xElement” type=“xsd:int”/></schema>

</types>

<message name=“myMethodRequest”><part name=“x” element=“xElement”/>

</message><message name=“empty”/>





SOAP message

<soap:envelope><soap:body>

<xElement>value</xElement></soap:body>

</soap:envelope>


Advantages/Disadvantages

Advantages No type encoding information The body of the soap message is all defined in a schema and

so can be validated independently

Disadvantages WSDL is more complicated Operation name is lost


Document/wrapped WSDL

<types><schema>

<element name=“myMethod”/><complexType>

<sequence><element name=“x” type=“xsd:int”/>

</sequence></complexType>

</element></schema>

<types><message name=“myMethodRequest”>

<part name=“parameters” element=“myMethod”/></message><message name=“empty”/>




WSDL schema has a wrapper around the parameters


SOAP message

<soap:envelope>

<soap:body>

<myMethod>

<x>value<x>

</myMethod>

</soap:body>

</soap:envelope>


Characteristics

Input message has a single part Part is an element Element has the same name as the operation Element’s complex type has no attributes


Advantages/disadvantages

Advantages No type encoding information Soap body is defined in a schema – validation Method name in the soap message

Disadvantages WSDL is complicated

Generally this is the best style to use.


When not to use document/wrapped

Document literal wrapped style does not allow for overloading

Cannot have two elements with the same name in XML (element has to have same name as operation)

In this case you may wish to use RPC/literal so that the operation name is available.


SOA Editor

Cape Clear SOA Editor, Cape Clear 2003WSDL © EGEE Consortium and partners, see www.gLite.org

Deploying web services

Containers and invocation


Container

A framework to accept, interpret, (de-)marshall the I/O for your application or service


Container

Various vendors Oracle Application Server SUN Application Server IBM WebSphere Apache Catalina/Tomcat Apache Axis .NET

although the WS on the outside may be the same, tools and interface on the business end vary


Containers

Many containers, but not all the same

Vary in what they support, e.g., Platform: JVM, .NET, Unix Language (Java, C, Python) WSDL bindings (rpc or document/literal) Security mechanisms (none or GSI)

VL-e supplied container GT4 (Axis 2.0-RC2++) Modified to do WS-RF, -Addressing, -Notification With GSI Security framework Almost like standard Axis 2


Data structures

All data structures in the language (Java, C, &c) need to be serialized

Easy when you stick to:Global types (int, double, String, array etc.) Java beans (set and get methods)

Otherwise need write custom serializers commands like WSDL2Java generate (amonst other things)

stubs to fill with the serialization code

slide source: Machiel Jansen, Vrije Universiteit Amsterdam: VL-e web services induction 2006


Wrapping existing application

Define input and output of the application write the appropriate WSDL

Generate the Java stubs Execute application from Java Redirect the output Deploy as webservice



Wrapping existing application

public int run(String cmd, Writer out) throws IOException {RunTime r = Runtime.getRuntime(); Process p = r.exec(cmd); FileIO.copyFile(new InputStreamReader(p.getInputStream( )),

out, true);try { p.waitFor( ); // wait for process to complete } catch (InterruptedException e) { return -1; } return p.exitValue( ); }



WS Clients – 3 types

Stub based (easy: use WSDL2Java) Service endpoint is static

Dynamic proxy Service endpoint dynamically at runtimeDynamic Invocation Interface (DII) Discover services at runtime then invoke methods



Clients - DII

Axis user guide uses Call object (DII) in examples.WSRF and GT4 examples uses stubs.



WSRF and GT4

GT4 uses the WSCore library.http://www-128.ibm.com/developerworks/edu/gr-dw-gr-eclipseide-i.html

Notes: GT4 WSRF is a little different from Apache WSRFGT4 uses GAR files and JNDI deployment.Eclipse has a GT4 plugin…



Moving into the container

GT4 puts most of the grid elements in the container support for resource properties support for the AuthZ framework information system/MDS4 …

makes application service development easier if the service is independent of those features otherwise, lots of callouts are needed

as in the RLS security interface from lecture #6


Container capabilities

Axis 1.x, x<2 support RPC/encoded deployment of services requires restart

Axis 1.3 support Document/literal still no hot deployment

GT4 Like Axis 1.3, but with grid services built-in, WS-RF support

Tomcat5, Axis2 hot deployment of services WS-RF, WS-Notification, WS-Addressing in the pipeline somewhere

Sun & Oracle Application Server Hot deployment supported


Implementation

Remember that web services are stateless

Model state via Resources Don’t keep running after the service invocation is complete Use database/memory based storage, not process-based state

retention Much more friendly on the CPU Resilient to machine/VM restarts

The ultimate horror scenario: R-GMA producer & consumer threads, see Concurrency P&E paper on the web

Using containers


Container deployment issues

Container needs inbound connectivity to get to the services most sites & compute clusters provide only outbound

connectivity how to get to the service?

proxy box inside the network perimeter needs specific site support opens a security hole in the perimeter

a better protocol unlikely that beep will ever replace http …

tunnel layer on top of protocols like, e.g., jabber, and push messages through

that with a proxy box

overlay network build a ‘quasi-VPN’ for your grid, e.g. using the GCB


Typical Facility topology


Service Deployment Example

Farm of GT4 containers provided on the edge of the site Based on the concept of “VO Boxes” For now: login to these boxes via gsissh Not for compute-intensive work

You cannot run a container continuously on worker nodes No inbound IP connectivity Resource management and utilization

And you should not want to, because All services in a container content for CPU and (disk) bandwidth JVM does not insulate services from each other


Other constraints

Worker nodes are allocated in a transient way

Jobs run in a one-off scratch directory No shared file system for $HOME

(and if it happens to be there don’t use it!) Jobs will be queued

Short jobs get to run faster Small jobs get to run faster Priority depends on your VO affiliation

You can connect out, but cannot listen Your job is limited in wall time


Central Hosting

A hosting environment can offered on a set of edge boxes Visible from the outside world Highly monitored systems for security reasons Can talk to the ‘inside’

Requirements for deployment on the CF Appropriate AuthN/AuthZ must be used for all services

(this is available by default in GT4) Allow for request tracability (e.g. via log files) then, these services are allowed to talk to the ‘inside’

Wrapping

Making the world into a service


Some general caveats

Re-use services Use generic services where possible

‘job submission service’, ‘data location srv’ Don’t over-do it

WS are not suitable for low-latency HPC or bulk file transfer We’re not running a course on WS-RF …

Not all services (nor architectures) are mature jet Be prepared to make compromises … … as long as it’s in-line with long-term trend


Brokered Job Submission Service Submit brokered jobs in JDL

through WS-interface to the Matrix Resource Broker WSDL specification

http://mu7.matrix.sara.nl/SaraGridService/SaraGridServiceLCG.wsdl

For detailed info: ask Bart Heupers, SARA Future version of the basic Grid middleware will have a

native WMS WS interface


Defining and building Services in WS-*

[See Introduction to Web Services Tutorial]

1. Start with the WSDL2. Then, generate your interfaces

• E.g. with GT4 tools or JWSDP• See appropriate tutorial(s): “Technologies for Building Grids” or

“Sotomajor”

3. Fill the stubs with an implementation4. Deploy your services in a container

EGEE NA3 Training Home has plenty of material:http://www.egee.nesc.ac.uk/trgmat/

Containers and Web Services Grid Middleware 7 David Groep, lecture series 2005-2006.

Documents

Transcript of Containers and Web Services Grid Middleware 7 David Groep, lecture series 2005-2006.