Web Services

r.menday@fz-juelich.de

IntroductionResearch Centre Jülich

Big contributors to the

Grid system

A-WARE :

An Easy Way to Access Grid Resources

20082007200620052004 2009

UniGridsNextGRID

DGI

VIOLA

OMII-EuropeEGEE-II

A-WARE

CoreGRID

ChemomentumLUCIFER

eDEISA

DEISA

Outline• Motivation & History

• SOA

• Web services

• SOAP & WSDL

• Standardisation, WS-*

• Utopia ?

• Toolkits

MotivationLots of different computers, different platforms, all around the world, all wanting to communicate …

One could try with Java RMI …

• this might be ok in a tightly controlled (and java only!) world

• but take it further and interoperability, robustness, scalability, etc, would all be problems.

HistoryOther technologies existed before Web services doing similar things (RPC, CORBRA, DCOM, Java RMI)

SOAP first emerged in 1999

XML as the on-the-wire encoding for remote procedure calls, [1]

Initially expanded to : “Simple Object Access Protocol”

Which was quite accurate at the time

Since then things have moved, and now SOAP is SOAP …

1. http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=396

Service Oriented ArchitectureSelf-contained, self-describing, modular applications

Published, located, and invoked across the internet

Loosely coupled

Well-defined external contracts

Combination of services make up an SOA - Composable

Independent development and management of client and provider

Loose Coupling

"the state in which the impact of change (change in consumers, providers, or cross-cutting policies) is minimized across dependencies.“ [1]

… like pornography ? [2]

API vs. Service [3]

1. http://www.soa-zone.com/index.php?/archives/16-Defining-loose-coupling.html

2. http://www.rds.com/doug/weblogs/webServicesStrategies/2002/11/18.html

3. http://www.itworld.com/nl/xml_prac/04182002/pf_index.html

Web ServicesA manifestation of a SOA

… or a ‘grounding’ of the SOA principals

A world of (loosely coupled) Web services

Triangle

Sending XML messages between services over the internet

SOAP used to package and send an XML messages to a service

WSDL used to describe the service

UUDI used to find a service (although UDDI hasn’t really taken off …)

FIND PUBLISH

BIND

1. http://www-306.ibm.com/software/solutions/webservices/pdf/WSCA.pdf

* [1]

Source: http://www-128.ibm.com/developerworks/autonomic/library/ac-mgmtsoa/

Divide large-scale architectures into flexible services that can be combined, configured, and reused -> service components

Example use-case : Pizza<soap:Envelope><soap:Header>…</soap:Header><soap:Body>

<p:pizzaOrder> <p:pizza type=“americano” /> </p:pizzaOrder></soap:Body></soap:Envelope>

<soap:Envelope><soap:Header> … </soap:Header><soap:Body>

<p:pizzaOrderResponse> <p:orderNum>243432</p:orderNum> </p:pizzaOrderResponse></soap:Body></soap:Envelope>

<soap:Envelope><soap:Header> <wsa:To>http://pizzaworld.com</wsa:To> <wsa:FaultTo>http://errorbox.com</wsa:FaultTo> <wsa:ReplyTo>http://mycomputer.com</wsa:ReplyTo>

<wss:Security> ….. </wss:Security> <wsrm: … > </soap:Header><soap:Body>

<p:pizzaOrder> <p:pizza type=“americano” /> … </p:pizzaOrder></soap:Body></soap:Envelope>

XML<pizza xmlns="http://www.pizza.org">

<menuitem>125</menuitem>

</pizza>

(Actually, XML infoset is the data model, of which there are a number of representions, via encodings. The example above is an the most common encoding. Others are possible, see [1] for example)

1. http://msdn.microsoft.com/winfx/technologies/communication/default.aspx?pull=/msdnmag/issues/06/08/servicestation/default.aspx

XML-Schema<xsd:complexType name=“pizza">

<xsd:sequence>

<xsd:element name=“menuitem" type="xsd:integer" minOccurs="0" maxOccurs="1/>

</xsd:sequence>

</xsd:complexType>

SOAPProtocol for packaging and exchanging messages

Familiar terms from the postal service : Envelope, Header, Body …

Transport independent(which unfortunately doesn’t seem to be exploited enough, although see http://msdn.microsoft.com/winfx/technologies/communication/default.aspx)

Commonly uses HTTP POST, although could use sockets, Email, etc (although its not really how HTTP POST should be used)

Protocol allows passage through multiple intermediaries on its route between Requester and Receiver (again similarities with the postal service can be noted)

SOAP Header control information(e.g., address, transaction ID,

security)SOAP Body Payload (e.g., pizza order)

SOAP Envelope

WS-Addressing

Transport-independent way of describing addresses and addressing messages.

Endpoint Reference (EPR)

Can be used to send indicate replies go to a different endpoint

<wsa:EndpointReference> <wsa:Address> http://www.abc.com/service/pizza </wsa:Address> </wsa:EndpointReference>

WSDL – Web Service Description LanguageMachine readable contract for a web service

Defines message syntax for messages sent to a service

Used by tools, IDE’s, etc

types schema for the types which make up the messages

message the input /output /fault messages for the operations defined in the portTypes

portType consisting of a number of operations

binding how to talk to the portTypes at the service endpoint

service describes the endpoint where the service lives

1. http://www.intertwingly.net/stories/2002/02/15/aBusyDevelopersGuideToWsdl11.html

Orchestration

Multiple invocations of services

This composition of services can then also be published as a service

see, BPEL [1]

1. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel

Security

Either at the transport-level - SSL, etc

Or, at the message level - WS-Security, etc

Signing, Encryption all inside the SOAP message

Lots of ‘standards’(some not fully ‘standardised’ – others competing)

XML, XML Schema, SOAP, WSDL, MTOM, UDDI, BPEL, XKMS, WS-Policy, WS-MetaDataExchange, WS-SecurityPolicy, WS-Addressing, WS-Trust, WS-Federation, WS-Secure Conversation, WS-SecureExchange, WS-Privacy, WS-Authorization, WS-Transfer, WS-Addressing, WS-Reliability, WS-ReliableMessaging, WS-ReliableExchange, WS-Notification, WS-BaseNotification, WS-BrokeredNotification, WS-Topic, WS-Eventing, WS-Enumeration, MTOM, WS-AtomicTransactions, WS-BusinessActivity, WS-Coordination, WS-Composite Application Framework, WS-Coordination Framework, WS-Transaction Management, WS-Context, WS-Remote Portal, WS-Resource Framework, WS-Resource Properties, WS-Resource Lifetime, WS-BaseFault, WS-ServiceGroups, WS-Inspection, WS-Discovery, WS-PolicyAttachment, WS-PolicyAssertions, WS-Provisioning, WS-Manageability, WS-Distributed Management, WS-Choreography, WS-Choreography Description Language, WS-I, phew …

(It seems that which ever way you want to use Web services, there’s a standard out there for you …)

Standardisation W3C - XML Infoset, XML, XML Schema, SOAP, WSDL

WS-I - WS-Security, other WS-*, WSRF

OASIS - WS-I Base Profiles

GGF - Grid specifics, OGSA profile of WSRF, WS-Naming, etc

Microsoft pictureWS-* covers Web services discovery, eventing, attachments, security, reliable messaging, transactions, and management.

1. http://msdn.microsoft.com/library/en-us/dnwebsrv/html/wsmsplatform.asp

* taken from [1]

Messaging - XML, SOAP, WS-Addressing, MTOM

Metadata - WSDL, WS-MetadataExchange, WS-Policy

Security - WS-Security, WS-Trust, WS-SecureConversation

Reliability - WS-ReliableMessaging

Transactions - WS-Coordination, WS-AtomicTransction

Web Services Utopia*everything* is (or can be) in the message – addressing, security, reliability, etc. Such information is added into the SOAP header.

So, for example, if datagram transport is used, it is still possible to ensure once-only reliable delivery, which is authenticated and protected.

(fully transport independent – you could even print the SOAP message on to a piece of paper, and send it using the normal snail-mail)

Everything the service requires in able to communicate with it published (WSDL, WS-Policy, etc). With good tool support the relevent WS-* specification is ‘switched-on’.

-> no longer simple, requires tools, but the result is powerful.

Toolkits Java

Axis (1 & 2) [1]

Also, ActiveSOAP [2], XFire [3,] GLUE

.net

Windows Communication Foundation (formally Indigo) [4]

Lots of others, in other languages …

1. http://ws.apache.org/axis/

2. http://activesoap.codehaus.org/

3. http://xfire.codehaus.org/

4. http://msdn.microsoft.com/winfx/technologies/communication/default.aspx

The ‘Web’ in ‘Web services’ … ?Somewhat misleading(there is a ‘movement’ called REST putting the Web back into Web services …)

“Internet Services” is more accurate

Pessimists

“I Still Don’t Buy It · No matter how hard I try, I still think the WS-* stack is bloated, opaque, and insanely complex. I think it’s going to be hard to understand, hard to implement, hard to interoperate, and hard to secure.” [1]

Have Web services ‘made it’ ? – they have had long enough …

1. http://www.tbray.org/ongoing/When/200x/2004/09/18/WS-Oppo

The Web services architecture is sufficiently generic that lots of different types of systems/philosophies/approaches can be implemented/mapped/re-engineered using XML, SOAP, etc. One community is the Grid community. Their Web services specification family is called the Web Services Resource Framework (WSRF), and that’s next …

Web Services Resource Framework

… create, address, inspect, discover, and manage stateful resources.

Outline• State

• Factories

• Publishing state as XML

• WSRF Specifications

• UniGrids

• Outlook

StateStateful Entities Exist, particularly on the Grid

But no Web service standards for State Management

• Each system does it in an “idiosyncratic way”

• Integration impediment

OGSA Needs to

• Formalize a mechanism to represent “state”

• WSRF specifications provide this

• A ‘special’ kind of Web service –> a ‘Grid Service’

In ‘regular’ Web services :

• Service defined in terms of the operations it implements

• Operation execution available at an endpoint address

• Lifecycle of a Web service is described in terms of deployment

• It is there or it isn’t. No factory pattern, only discovery

The Web Service itself is typically Stateless

BUT

Grids Need Access to Stateful Resources

Factory PatternOGSA provides for dynamic creation of resources.

Find it or Create it? The difference is moot:

• FindMeAThing (Description) -> HandleToThing

or

• MakeMeAThing (Description) -> HandleToThing

Creates a Resource when you need it

• Start a Job to do this...

• Pizza shop (factory) creates a pizza order resource

• Get me management interface for this experiment...

A Resource …A specific set of state data expressible as an XML document

This is not typically all of the resource’s state!

Has a well-defined identity and lifecycle

Known to, and acted upon, by one or more Web services.

It has many possible instancesFiles, database tables, EJB entities, XML documents, compositions of multiple data sources, virtualized executions of applications, etc.

A WS-Resource …Combination of a Web service and a Resource

Identity Can be uniquely identified/referenced

Lifetime Often created & destroyed by clients

State Part of the state can be projected as XML

Type Its Web service interface

Resource PropertiesUse XML to model elements of resource state

Associate state with a WSDL portType

Use standard operations for getting, setting, querying

Use standard mechanisms to subscribe to state changes (notification)

Why ?Basis for standard resource inspection, monitoring, and state management

Intuition:

Think of Resource Properties as an XML projection of the actual state of the resource

WS-Resource has a ResourceProperties document attached to it

XML of the RPD reflects the state of the underlying resource

Elements of the state modelled as child elements of the RPD root

Schema type of the RPD found in the WSDL

Back to pizzas … <p:createPizzaOrder> <p:pizza type=“americano” /> … </p:createPizzaOrder>

<p:createPizzaOrderResponse> <wsa:EndpointReference> http://www.pizaaworld.com </wsa:EndPointReference> <p:pizzaorderid>45345345345</p:pizzaorderid></p:createPizzaOrderResponse>

<wsrf-rp:getResourceProperty> p:status</wsrf-rp:getResourceProperty>

<wsrf-rp:GetResourcePropertyResponse> <p:status> COOKING </p:status></wsrf-rp:GetResourceProperty>

+ Lifetime management of Pizza order+ Subscription to status RP -> Notifications when it changes

WSRF SpecificationsWS-Resource defines a WS-Resource as a combination of a Resource and a Web service through which the resource can be accessed

WS-ResourceProperties resource state as XML with standard operations for getting, setting, querying

WS-ResourceLifetime lifetime management of a WS-Resource

WS-ServiceGroup aggregations information about multiple WS-Resources or

Web services

WS-BaseFaults standisation of information contained in fault message

WS-Notification mechanism for publishing events to interested parties

GetResourcePropertySimple single resource property element getter

May return multiple instances of the named RP.<wsrf-rp:GetResourceProperty> job:handle</wsrf-rp:GetResourceProperty>

<wsrf-rp:GetResourcePropertyResponse> <job:handle> 1577 </job:handle></wsrf-rp:GetResourceProperty>

GetMultipleResourcePropertiesMore sophisticated multiple property value retrieval<wsrf-rp:GetMultipleResourceProperties> <wsrf-rp:ResourceProperty>job:handle </job:handle> <wsrf-rp:ResourceProperty>job:executionState </ …> <wsrf-rp:ResourceProperty>job:JobName </job:JobName></wsrf-rp:GetMultipleResourceProperties>

<wsrf-rp:GetMultipleResourcePropertiesResponse> <job:handle> 2824 </job:handle> <job:executionState> Submitted </job:executionState> <job:JobName> xclock </job:JobName></wsrf-rp:GetMultipleResourcePropertiesResponse>

QueryResourcePropertiesExecute an expression against the resource properties document<wsrf-rp:QueryResourceProperties> <wsrf-rp:QueryExpression Dialect=”URI”> xsd:any </wsrf-rp:QueryExpression></wsrf-rp:QueryResourceProperties>

QueryExpression defines dialect by URI

XPath 1.0, 2.0, XQuery, SQL, SPARQL

SetResourcePropertiesThree modes can be applied many times in any order in a single message.

Insert Add a new resource property

Update Replace all properties with a given name.

Delete Remove all properties with a given name.

However they must appear to happen in order.

The final version of the RPD must validate.

Whole Document OperationsGetResourcePropertyDocument

Get the entire resource property document

PutResourcePropertyDocument

Replace the entire RPD with a new one

The semantics are service specific, and very loose (could be quite ‘dangerous’. PutResourcePropertyDocument arbitrarily adjusts the projected state of the resource – quite possibly putting the resource into an confused/incoherent state)

If the resulting document is different than the provided document, the resulting document is returned.

Resource LifetimeImmediate, synchronous destruction operation

Time-based, scheduled destruction operation

Resource properties:

CurrentTime Can be used to determine clock skew

TerminationTime Current scheduled termination time

Notification of resource termination

Define clear means by which resources can be destroyed

Allow the Grid to “Garbage Collect” itself automatically

Resource Lifetime OperationsImmediate Destruction<wsrf-rl:Destroy/>

Scheduled Termination<wsrf-rl:SetTerminationTime> <wsrf-rl:RequestedTerminationTime xsi:nil=”xsd:boolean”?> xsd:dateTime </wsrf-rl:RequestedTerminationTime>

<wsrf-rl:RequestedLifetimeDuration> xsd:duration </wsrf-rl:RequestedLifetimeDuration></wsrf-rl:SetTerminationTime>

Notification Publish / Subscribe pattern

Interest in some events – Subscription

Events sent from Producer to Consumer(s)

Example events :

• Changes to RP values

• WS-Resource lifetime events

• Addition or removal of entries from ServiceGroup

1. http://www.oasis-open.org/committees/wsn

ServiceGroupA general purpose WS-Resource which aggregates information from about multiple WS-Resources or Web services

A SG entry includes member EPR + associated content (abstract)

WSRF-RP used for representing the entries

Members may be homogenous or heterogeneous

Can have rules constraining membership and content

Has a registration interface for adding entries

WSRF-RL used for removing entries

Can be used by registries, collective operations, etc

BaseFaultsSet of “common” properties of a fault

Convention for specializing “common” fault

How “common” fault type is used in WSDL

Why?

Increases the likelihood that service requestors to automatically (without human intervention) understand and/or adapt to faults requires interface designers to define rich, structured fault messages

Standard fault messages encourage tooling that can assist interface designers, service implementers, and client implementers

UniGrids Atomic Services Apart from the TSF everything is stateful

Target Systems, Jobs, Transfers, etc, have a lifetime

Lots of factories – TSS factory for JMS, SMS factory for FTS

State published as RP’s

Notification messages

Real world usage !

1. http://www.unigrids.org

Unicore/GS Hosting Environment

Target System Factory

TSF

Target SystemService

TSS

JobMgmt

ServiceJMS

StorageMgmt

ServiceSMS

ServiceRegistry

Resource Broker

BPEL Workflow Service

Globus Toolkit 4 Hosting Environment

Higher-level

Services

FileTransferService

FTS

Target System Factory

TSF

Target SystemService

TSS

JobMgmt

ServiceJMS

StorageMgmt

ServiceSMS

FileTransferService

FTS

UniGrids Atomic Service Interfaces (WP1&WP2)

Doubters Kind of like a XML version of CORBA

A distributed objects system is too fine-grained

Service-oriented systems are more course-grained

1. http://www.neresc.ac.uk/ws-gaf/

WSRF Future1.2 Oasis Specification

Good to use for next 2-3 years

WSRF 2.0 ?

Maybe WS-Transfer based [1]

1. http://devresource.hp.com/drc/specifications/wsm/index.jsp

Summary

Web services are great !

Thanks… to F.Wolf (FZJ), D. Snelling (FLE)

For some of the slide material