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


Overview

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


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


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


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>


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>

http://schemas.xmlsoap.org/wsdl/http/

http://www.w3.org/2001/XMLSchema

http://www.w3.org/2001/XMLSchema

http://skyservice.pha.jhu.edu/

http://schemas.xmlsoap.org/soap/encoding/

http://schemas.xmlsoap.org/soap/encoding/


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>


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


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>





<types><schema>

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

</schema></types>

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

</message>





RPC Document

Literal

Encoding


WSDL binding flavours (II)

<soap:envelope><soap:body>

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

</method></soap:body>

</soap:envelope>


<method><x>5</x>


</soap:envelope>


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

</soap:envelope>

RPC Document

Literal

Encoding


<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>




</operation></portType

WSDL binding flavours (III)


<method><x>5</x>

</method>></soap:body>

</soap:envelope>

Document/literal wrapped


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%)


Why not doc/literal wrapped? - I


</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>


<method><x>5</x>


</soap:envelope>


<method><x>5</x>

</method>></soap:body>

</soap:envelope>


<xElement>5</xElement>

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


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

</portType>

rpc/literal doc/literal doc/literal wrapped


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


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

http://www.ws-i.org/


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


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


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-*


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)


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


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


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/)


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)


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)


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)

http://ws.apache.org/wsrf




http://www.cs.virginia.edu/~gsw2c/wsrf.net.html






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)


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


Patterns for asynchrony (I)

• Fire and Forget:

• Request/response (Transport timeout)

C S C S

C S


Patterns for asynchrony (II)

• Polling:

• Callback:

C S

C S


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


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


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


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


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

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

Documents

nvo summer school

right slide

use wsdl

xml schema slide

graham cacrcaltech slide

business logic slide

wsdl file

wsdl binding flavours