7 sep 2006nvo summer school 20061 t he us n ational v irtual o bservatory building web services...

7 Sep 2006NVO Summer School 2006 1

THE US NATIONAL VIRTUAL OBSERVATORY

Building Web Services

Matthew J. GrahamCACR/Caltech

7 Sep 2006NVO Summer School 2006 2

Overview

• WSDL• Attachments• Security• State• Asynchrony• Message orientation

7 Sep 2006NVO Summer School 2006 3

Design styles

• Contract-last development– Implement service– java org.apache.axis.wsdl.Java2WSDL

<interface> contract coupled to service implemenation’s

interface

• Contract-first development– Write XSD and WSDL– java org.apache.axis.wsdl.WSDL2Java -s <wsdl>– Fill in business logic

7 Sep 2006NVO Summer School 2006 4

What is WSDL?

• Web Services Description Language• An XML grammar for describing a web

service as a collection of endpoints capable of exchanging messages in a particular fashion

• W3C specification (http://www.w3.org/TR/wsdl)

• Use WSDL 1.1• http://www.xmethods.net

7 Sep 2006NVO Summer School 2006 5

Anatomy of a WSDL file

<definitions>

</definitions>

<message>* - model data exchanged<part></part>*

</message>

<binding>* - formatting and representation of SOAP

<operation>* message on the wire<input></input><output></output>

</operation></binding><service>* - identifies actual

endpoint for WS<port></port>*

</service>

<import>* - include other WSDLs<types> - define datatypes used in

<message><schema></schema>*

</types>

<porttype>* - describe interfaces supported for<operation>* an endpoint

<input></input> - define input and output parameters<output></output><fault></fault>*

</operation></porttype>

7 Sep 2006NVO Summer School 2006 6

WSDL example<definitions xmlns:http=http://schemas.xmlsoap.org/wsdl/http/ xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s=http://www.w3.org/2001/XMLSchema

xmlns:s0=http://skyservice.pha.jhu.edu xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/

targetNamespace="http://skyservice.pha.jhu.edu" xmlns="http://schemas.xmlsoap.org/wsdl/"> <types><s:schema elementFormDefault="qualified" targetNamespace="http://skyservice.pha.jhu.edu"> <s:element name="ComovingLineOfSight">… <s:element minOccurs="1" maxOccurs="1" name="z" type="s:float" /> <s:element minOccurs="1" maxOccurs="1" name="hubble" type="s:float" /> <s:element minOccurs="1" maxOccurs="1" name="omega" type="s:float" /> <s:element minOccurs="1" maxOccurs="1" name="lambda" type="s:float" /> …</s:element> <s:element name="ComovingLineOfSightResponse”>… <s:element minOccurs="1" maxOccurs="1" name="ComovingLineOfSightResult" type="s:float" /> …</s:element> </s:schema></types> <message name="ComovingLineOfSightSoapIn"> <part name="parameters" element="s0:ComovingLineOfSight" /> </message> <message name="ComovingLineOfSightSoapOut"> <part name="parameters" element="s0:ComovingLineOfSightResponse" /> </message> <portType name="DistanceSoap"> <operation name="ComovingLineOfSight"> <documentation>Return the comoving line of sight distance...</documentation>

<input message="s0:ComovingLineOfSightSoapIn" /> <output message="s0:ComovingLineOfSightSoapOut" />

</operation> </portType> <service name="Distance">

<port name="DistanceSoap" binding="s0:DistanceSoap"><soap:address location="http://voservices.net/Cosmology/ws_v1_0/Distance.asmx" />

</port> </service></definitions>

7 Sep 2006NVO Summer School 2006 7

What about the binding?

<binding name="DistanceSoap" type="s0:DistanceSoap"><soap:binding

transport="http://schemas.xmlsoap.org/soap/http" style="document" />

<operation name="ComovingLineOfSight”><soap:operation

soapAction="http://skyservice.pha.jhu.edu/ComovingLineOfSight" style="document" />

<input><soap:body use="literal" />

</input><output>

<soap:body use="literal" /></output>

</operation></binding>

7 Sep 2006NVO Summer School 2006 8

Binding attributes

• Style (representation on the wire)– rpc: the endpoint treats child elements in the

body as XML representation of method call (SOAP 1.1, sec. 7)

– document: the body can contain arbitrary XML

• Use (how data is serialized across the wire)– encoded: rules in a URL specified by

encodingStyle attribute– literal: rules specified by XML schema

7 Sep 2006NVO Summer School 2006 9

WSDL binding flavours (I)

<message name=“Request”><part name=“x” type=“xs:int”/>

</message>

<message name=“empty”/>

<portType name=“foo”><operation name=“method”>

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

</operation></portType>

<message name=“Request”><part name=“x” type=“xs:int”/>

</message>

<message name=“empty”/>

<portType name=“foo”><operation name=“method”>

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

</operation></portType>

<types><schema>

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

</schema></types>

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

</message>

<message name=“empty”/>

<portType name=“foo”><operation name=“method”>

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

</operation></portType>

RPC Document

Literal

Encoding

7 Sep 2006NVO Summer School 2006 10

WSDL binding flavours (II)

<soap:envelope><soap:body>

<method><x xsi:type=“xs:int”>5</x>

</method></soap:body>

</soap:envelope>

<soap:envelope><soap:body>

<method><x>5</x>

</method></soap:body>

</soap:envelope>

<soap:envelope><soap:body>

<xElement>5</xElement></soap:body>

</soap:envelope>

RPC Document

Literal

Encoding

7 Sep 2006NVO Summer School 2006 11

<types><schema>

<element name=“method”><complexType>

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

</complexType></element>

</schema></types>

<message name=“Request”><part name=“parameters” element=“method”/>

</message>

<message name=“empty”/>

<portType name=“foo”><operation name=“method”>

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

</operation></portType

WSDL binding flavours (III)

<soap:envelope><soap:body>

<method><x>5</x>

</method>></soap:body>

</soap:envelope>

Document/literal wrapped

7 Sep 2006NVO Summer School 2006 12

Which flavour to use?

• Doc style can pass entire transaction as an XML document (state)

• Doc style not constrained by RPC-oriented encoding

• Doc style can be validated at call time• Processing overhead in encoding payloads with

RPC• Doc style can use low memory parsers such as

SAX and StAX• RPC’s natural tendency to expose programming

language object structures doc/literal wrapped (95%)

7 Sep 2006NVO Summer School 2006 13

Why not doc/literal wrapped? - I

<message name=“Request”><part name=“x” type=“xs:int”/>

</message>

<types><schema>

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

</schema></types>

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

</message>

<types><schema>

<element name=“method”><complexType>

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

</complexType></element>

</schema></types>

<message name=“Request”><part name=“parameters”

element=“method”/></message>

<soap:envelope><soap:body>

<method><x>5</x>

</method></soap:body>

</soap:envelope>

<soap:envelope><soap:body>

<method><x>5</x>

</method>></soap:body>

</soap:envelope>

<soap:envelope><soap:body>

<xElement>5</xElement>

</soap:body></soap:envelope>

<portType name=“foo”><operation name=“method”>

<input message=“Request”/></operation>

</portType>

rpc/literal doc/literal doc/literal wrapped

7 Sep 2006NVO Summer School 2006 14

Why not doc/literal wrapped? - II

• Overloaded operations:public void myMethod (int x, float y);public void myMethod (int x);

• Number of parameters:public void someOtherMethod(int x, float y);

• Data graphs:<complexType name=“Node”> <sequence>

<element name=“name” type=“string”/> <element name=“left” type=“Node”/> <element name=“right” type=“Node”/> </sequence></complexType>

RPC/encoding: <A> Literal:<A><name>A</name> <name>A</name><left href=“9999”/> <left><right href=“9999”/>

<name>B</name> </A> </left> <B id=“9999”> <right>

<name>B</name> <name>B</name>

</B> </right> </A>

A

Left Right

B

Left Right

7 Sep 2006NVO Summer School 2006 15

Interoperability

• Suitable for and capable of being implemented in a neutral manner on multiple operating systems and in multiple programming languages

• Not all web services are interoperable!• Web Services Interoperability

Organisation (http://www.ws-i.org)• WS-I Testing Tools

7 Sep 2006NVO Summer School 2006 16

WS-*• WS-I Basic Profile• WS-I Basic Security Profile• WS-Manageability• WS-Management • WS-MetadataExchange• WS-Notification• WS-Policy• WS-PolicyAssertions• WS-PolicyAttachment• WS-PolicyFramework• WS-Polling• WS-Provisioning• WS-Reliability• WS-ReliableMessaging• WS-RemotePortals• WS-ResourceFramework• WS-ResourceLifetime• WS-ResourceProperties• WS-Routing• WS-SecureConversation• WS-Security• WS-SecurityPolicy

• WS-Addressing• WS-AtomicTransaction• WS-Attachments• WS-BaseNotification• WS-BPEL• WS-BrokeredNotification• WS-BusinessActivity• WS-CAF• WS-Choreography• WS-CDL• WS-Context• WS-Coordination• WS-CoordinationFramework• WS-Discovery• WS-DistributedManagement• WS-Enumeration• WS-Eventing• WS-ExperienceLanguage• WS-Federation• WS-GAF• WS-Inspection• WSIL

• WS-Semantics• WS-Topic• WS-Transaction• WS-Transaction Management• WS-Transfer• WS-Trust • ASAP • ebXML• MTOM• SAML • SOAP• SwA• UBL• UDDI• WSDL• XACML• XML Encryption• XML Signature• XKMS

7 Sep 2006NVO Summer School 2006 17

Attachments: opaque data

• “By value” – XML representationor– use xs:hexBinary or xs:base64Binary within the body– data expansion by a factor of ~1.33 - 4– anything within SOAP body gets parsed– processing costs of encoding/decoding

• “By reference”– attach pure binary data as external unparsed entity

outside SOAP message– use reference URI within the body

7 Sep 2006NVO Summer School 2006 18

Reference solutions

• SwA (SOAP with Attachments)– Multipart MIME message: SOAP (0), data (1-n)– Use Content-Id as reference in body– Lack of length header on message sections– No recommendation just W3C Note

• DIME (Direct Internet Message Encapsulation)– Uses faster and more efficient binary encoding– No standard, disowned by Microsoft

• Both introduce a data structure outside realm of XML data model: no rules to specify how attachment content related to SOAP envelope so incompatible with WS-*

7 Sep 2006NVO Summer School 2006 19

MTOM

• Message Transmission Optimization Mechanism• Uses MIME - backwards compatible with SwA• Uses XOP:Include as reference mechanism

(XOP = XML Binary Optimized Packaging)• Conceptually binary data is base64-encoded in

SOAP XML document compatible with WS-*• Implementations:

– Axis2 (http://ws.apache.org/axis2)– Xfire (http://xfire.codehaus.org)– WSE 3.0

(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwse/html/newwse3.asp)

7 Sep 2006NVO Summer School 2006 20

Security

• Transport level (https)• Message level:

– End-to-end: allows for unlimited intermediaries– Data origin authentication– Different types of security tokens/credentials:

• unsigned (username/password)• binary (X.509 certificate) • XML (SAML token)

– Multiple credentials

7 Sep 2006NVO Summer School 2006 21

WS-Security

• OASIS standard(http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss))

• Security token validation (authentication):– validate authentication assertions made by principals

• Message integrity (signing):– verify message origin– validate encryption keys– confirm security token claims

• Message confidentiality (encryption)• Introduces extra XML into SOAP header

7 Sep 2006NVO Summer School 2006 22

WSS Implementations

• Java:– WSS4J (http://ws.apache.org/wss4j) used by Axis2/XFire

• C#:– WSE 2.0

(http://msdn.microsoft.com/webservices/webservices/building/wse/default.aspx)

– WSRF.Net (http://www.cs.virginia.edu/~gsw2c/wsrf.net.html)

• Perl :– WSRF::Lite

(http://www.sve.man.ac.uk/Research/AtoZ/ILCT)

• Python:– pyGridWare (http://dsd.lbl.gov/gtg/projects/pyGridWare/)

7 Sep 2006NVO Summer School 2006 23

State

• Stateless is good:– In case of failure, just restart without concern of

previous interactions (reliability)– New service instances can be created/destroyed in

response to system load (scalability)

• How to handle state?– Separate web service and state information (resource)– Identify resource with a unique key– Use message exchanges with the service to interact

with the resource (manipulate state)

7 Sep 2006NVO Summer School 2006 24

WS-Resource

• An entity composed of a web service and a stateful resource

• The address is called an endpoint reference (WS-Addressing)

• ACID:– Updates made in all-or-nothing fashion (atomicity)– Consistent state even after failure (consistency)– Updates isolated within a given work unit (isolation)– Permanence of updates (durability)

7 Sep 2006NVO Summer School 2006 25

WS-RF: the nuts and bolts

• WSDL for a stateful service:<definitions><import>*<types>

<xs:schema><xs:element

name=“StatefulResourceProperties”>…</xs:element><xs:schema>

<types><porttype wsdlpp:extends=“…”

wsrp:ResourceProperties=“tns:StatefulResourceProperties”>

• Implementations:– Java: GT4 (htttp://www.globus.org); Apache WSRF (http://ws.apache.

org/wsrf)– .NET: WSRF.Net (http://www.cs.virginia.edu/~gsw2c/wsrf.net.html)– Python: pyGridWare (http://dsd.lbl.gov/gtg/projects/pyGridWare/)– Perl: WSRF::Lite (http://www.sve.man.ac.uk/Research/AtoZ/ILCT)

7 Sep 2006NVO Summer School 2006 26

Asynchrony

• Real world is asynchronous• No current standards for asynchronous services but

most promising is OASIS ASAP (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=asap)

• Toolkits exist which facilitate asynchronous activities:– WS-RF (see above)– Axis2 (http://ws.apache.org/axis2)– JMS (http://java.sun.com/products/jms) /

Caffeine (http://caffeine.berlios.de/site/)– WSIF (http://www.apache.org/wsif)

7 Sep 2006NVO Summer School 2006 27

Messaging operations

• WSDL 1.1 defines four types of messaging operation that an endpoint can support:– One-way: endpoint receives a message– Request/response: endpoint receives a

message and sends a correlated message– Solicit/response: endpoint sends a message

and receives a correlated message– Notification: endpoint sends a message

• One-way/two-way transport behaviour

7 Sep 2006NVO Summer School 2006 28

Patterns for asynchrony (I)

• Fire and Forget:

• Request/response (Transport timeout)

C S C S

C S

7 Sep 2006NVO Summer School 2006 29

Patterns for asynchrony (II)

• Polling:

• Callback:

C S

C S

7 Sep 2006NVO Summer School 2006 30

WS-Addressing

• No standard SOAP way to specify:– where a message is going– how to return a response– where to report an error

• WS-Addressing provides:– To– ReplyTo– FaultsTo– Anonymous– MessageId / RelatesTo– Standard for including service-specific

attributes

7 Sep 2006NVO Summer School 2006 31

What’s wrong with WSDL (for SOAP)?

• Focuses on interface abstraction to describe services (‘RPC mindset’)

• Limited modelling of interaction patterns (no more than 2 message exchanges)

• No choreographical information (x y z)• Difficult to describe infrastructure protocols

that use SOAP headers• Technologies that use WSDL as a basis tend

to be more verbose and complex than necessary

7 Sep 2006NVO Summer School 2006 32

MEST (MESsage Transfer)

• Messaging:– No notion of client/server: just peers– Largely time independent: messages delivered

when peer is available– Messages can be duplicated and delivered to

multiple peers

• Messages and services are first class abstractions (no interfaces, data and operations)

• SSDL (http://www.ssdl.org)• Indigo: dual contracts are beyond WSDL

7 Sep 2006NVO Summer School 2006 33

SSDL

• SOAP is the messaging vector over arbitrary transport (and transfer) protocols

• WS-Addressing used for embedding addressing information within SOAP envelopes and binding those addresses onto underlying transport protocols

• XML Infoset is the underlying component model

• Use Xinclude for contract modularization• Promotes protocol framework extensibility

7 Sep 2006NVO Summer School 2006 34

SSDL structure

• Schemas– XML Schemas

• Messages– SOAP documents

• Protocols (how messages relate to each other)– MEP (WSDL 2.0)– Communicating Sequential Processes– Rules (uses preconditions on send and receive events)– Sequential Constraints

• Endpoints– WS-Addressing Endpoint Reference