Ace104 Lecture 9 Overview of WS-* Overview of REST.

Ace104Lecture 9

Overview of WS-*

Overview of REST

First Generation Web Services

• To this point we have studied what is often called first generation web services

• These are built off of fairly mature standards– XML– XML Schema– http– SOAP– WSDL– UDDI (we’ll discuss briefly, but not very important)

Why first generation?

• Preceding capabilities are very powerful– Give possibility of true interoperability among distributed

applications with minimal effort– Many gotchas still, both with portability and performance, but

overall story is quite good compared to CORBA, proprietary rpc, etc.

• However, they are still quite limited– No way to guarantee reliability and consistency– Do not support most of the features of Enterprise Applications

Servers• Transactions, atomicity, security, etc.

Recall our simple XML-based Architecture from class 1

webbrowser

WebServer

http

“hand-rolled”XML

XML

pyth

on C

GI

“hand-rolled”XML

File system

• How does a web service call compare?• This will be relevant for understanding REST

Topic of this lecture

• This class could be appropriately called “First Generation Web Services”, focusing in depth on the well established foundations outlined in previous slide.

• A good follow-up would be “Second Generation Web Services”– Not clear if the field is mature enough to warrant a university class

– I will give an overview to give sense of what is being worked on, level of maturity, etc.

– Erl books have some perspective on this, but it is spotty.

Real World Web Services

• This is not to say that first-gen web services have no value– Browse http://code.google.com/apis as example– Broad list of functionality provided by google servers

that are exposed through WSDL files– Comes also with sample programming language API– Many of these do not need transaction, security, state,

reliability, etc. (ie not everything fits EAS model!)– Also, SOAP headers can be used in ad-hoc way to

provide much of this functionality (see our SOAP-lite lecture for examples)

Deeper into SOAP Headers

• In SOAP lecture we only glossed over SOAP header role

• Need to study more deeply to see how extensibility potentially enables second-generation web service capabilities

General (Basic) Structure SOAP Message

• Envelope– Defines the content of the

message

• Header (optional)– Contains destination

information, versioning, extensions

– Good place for security

• Body– Contains payload

SOAP Envelope

SOAP Header

SOAP Body

Payload Document(s)

SOAP Fault

<xs:element name="Header" type="tns:Header" /><xs:complexType name="Header" > <xs:sequence> <xs:any namespace="##other" minOccurs="0"

maxOccurs="unbounded" processContents="lax" />

</xs:sequence> <xs:anyAttribute namespace="##other"

processContents="lax" /></xs:complexType>

SOAP Schema, Header element

General (Basic) Structure SOAP Message

<soap:Envelopexmlns:soap="http://schemas.xmlsoap.org/soap/encoding/"soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<soap:Header>... ...

</soap:Header><soap:Body>

<!-- User request code here --><soap:Fault>

... ...</soap:Fault>

</soap:Body></soap:Envelope>

Header• If present, must immediately follow the SOAP Envelope

XML element followed by any header entries

• Uses same namespace as Envelope

• May contain meta-information regarding the method call.

• Examples:– Security– Transaction IDs– Policy statements

Header

• actor attribute – defines the URI for which the header elements are intended (i.e. who should

process a Header element)

• mustUnderstand attribute – how to process (default is “0” if not present)

• encodingStyle attribute

<env:Header><t:TransactionID

xmlns:t="http://www.cs.uchicago.edu/dangulo/transact" env:mustUnderstand="1" env:actor="http://www.cs.uchicago.edu/dangulo/transact"

>42

</t:TransactionID><m:localizations xmlns:m="http://www.cs.uchicago.edu/dangulo/localize/" env:actor="http://www.cs.uchicago.edu/dangulo/currency">

<m:language>en</m:language><m:currency>USD</m:currency>

</m:localizations></env:Header>

actor Attribute

• The SOAP message often gets passed through several intermediaries before being processed– For example, a SOAP proxy service might get the message before

the target SOAP service

• Header may contain information for both– intermediary service– target service

• actor attribute specifies which service should process a specific Header element

• actor attribute is replaced by role attribute in SOAP 1.2

Intermediary Services• SOAP requires that an intermediary strip off Header elements specified for

that intermediary before passing the message to the next service in the chain.

• If information in a Header element targeted for an intermediary is also needed by another service in the chain

– The intermediary service may insert additional Header elements with an actor attribute that specifies the downstream service

• In fact, any service may insert any Header elements that it deems necessary

• If a Header element has no actor attribute– It is assumed to be destined for the final recipient

– This is equivalent to adding an actor attribute with the URL of the final recipient

mustUnderstand Attribute

• Also put on a Header element

• If its value is "1"– recipient is required to understand and make proper use of the

information supplied by that element– intended for situations where recipient can't do its job unless it knows

what to do with the specific information supplied by this particular element

• Examples of use– Client is upgraded to a new version which includes extra information– username– security

mustUnderstand Attribute

• If the recipient does not understand this element– Must respond with a SOAP Fault

HTTP/1.0 500 Internal Server ErrorContent-Type: text/xml; charst="utf-8"Content-length: 287

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Body>

<env:Fault><faultcode>env:MustUnderstand</faultcode><faultstring>SOAP Must Understand Error</faultcode><faultactor>http://www.cs.uchicago.edu/dangulo/transact</faultactor>

</env:Fault></env:Body>

</env:Envelope>• faultactor indicates where fault took place• We'll look at Faults in more detail later• Attribute values change to "true" / "false" in SOAP 1.2

Some examples

Taken from W3C primer

Sample SOAP message for travel reservation

<?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <m:reservation xmlns:m="http://travelcompany.example.org/reservation" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true"> <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference> <m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime> </m:reservation> <n:passenger xmlns:n="http://mycompany.example.com/employees" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true"> <n:name>Andrew Siegel</n:name> </n:passenger> </env:Header> Next slide ..

<env:Body> <p:itinerary xmlns:p="http://travelcompany.example.org/reservation/travel"> <p:departure> <p:departing>New York</p:departing> <p:arriving>Los Angeles</p:arriving> <p:departureDate>2001-12-14</p:departureDate> <p:departureTime>late afternoon</p:departureTime> <p:seatPreference>aisle</p:seatPreference> </p:departure> <p:return> <p:departing>Los Angeles</p:departing> <p:arriving>New York</p:arriving> <p:departureDate>2001-12-20</p:departureDate> <p:departureTime>mid-morning</p:departureTime> <p:seatPreference/> </p:return> </p:itinerary> <q:lodging xmlns:q="http://travelcompany.example.org/reservation/hotels"> <q:preference>none</q:preference> </q:lodging> </env:Body></env:Envelope>

…

Sample SOAP reply<?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <m:reservation xmlns:m="http://travelcompany.example.org/reservation" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true"> <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference> <m:dateAndTime>2001-11-29T13:35:00.000-05:00</m:dateAndTime> </m:reservation> <n:passenger xmlns:n="http://mycompany.example.com/employees" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true"> <n:name>Andrew Siegel</n:name> </n:passenger> </env:Header> Next slide …

<env:Body> <p:itineraryClarification xmlns:p="http://travelcompany.example.org/reservation/travel"> <p:departure> <p:departing> <p:airportChoices> JFK LGA EWR </p:airportChoices> </p:departing> </p:departure> <p:return> <p:arriving> <p:airportChoices> JFK LGA EWR </p:airportChoices> </p:arriving> </p:return> </p:itineraryClarification> </env:Body></env:Envelope>

…

Reply continuing conversational exchange

<?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <m:reservation xmlns:m="http://travelcompany.example.org/reservation" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true"> <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference> <m:dateAndTime>2001-11-29T13:36:50.000-05:00</m:dateAndTime> </m:reservation> <n:passenger xmlns:n="http://mycompany.example.com/employees" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true"> <n:name>Andrew Siegel</n:name> </n:passenger> </env:Header> <env:Body> <p:itinerary xmlns:p="http://travelcompany.example.org/reservation/travel"> <p:departure> <p:departing>LGA</p:departing> </p:departure> <p:return> <p:arriving>EWR</p:arriving> </p:return> </p:itinerary> </env:Body></env:Envelope>

WS-*

Get ready for a mess …

Second Generation Web Services

• Security, reliability, transactional support, complex addressing, statefulness, etc. are common features needed by a broad class of distributed applications

• Developers are accustomed to having server side programming models that provide high-level support for these programming models

• Note that none of this is explicitly present in First Generation Web Services

Second Gen, cont.

• Many developers ask: “these web services are nice, but how can I do real work”.

• For the most part, the truth is that, where web services have succeeded, we have added these capabilities using custom solutions

• Almost all involve manipulations of the SOAP header element

What are WS-* projects?

• Many “standards” have and are emerging to systematize this process. I list some of the common standardization projects on the next page

• Note that it is virtually impossible to keep up with these and is the main reason many people find web services a complete mess

• We’ll discuss in some depth only the most mature ones.

Some of the WS-Jungle

• WS-Addressing

• WS-AtomicTransaction

• WS-BaseNotification

• WS-BrokeredNotification

• WS-BusinessActivity

• WS-Choreography

• WS-Coordination

• WS-Discovery

• WS-Eventing

• WS-Federation

• WS-Inspection

• WS-Management

• WS-Notification

• WS-Policy

• WS-PolicyAttachment

• WS-PolicyAssertions

• WS-Provisioning

• WS-ReliableMessaging

• WS-SecureConversation

• WS-Security

• WS-SecurityPolicy

• WS-Transaction

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

WS-* By Category

• Context and transaction management– WS-Coordination– WS-Transaction– WS-AtomicTransaction– WS-BussinessActivity

• Business process definition and execution

– WS-BPEL– BPEL4WS

• Policies and metadat– WS-Policy– WS-PolicyAssertions– WS-PolicyAttachments– WS-MetaDataExchange

• Security– WS-Security– WS-Federation– WS-SecureConversation– WS-Trust

• Reliability and messaging– WS-ReliableMessaging– WS-Addressing– WS-Attachments

• Other– WS-Notification– WS-Eventing– WS-Resource

WS-Addressing

• Managed by W3C– Let by BEA, IBM, and Microsoft.

• History– First submitted August 2004– W3C recommendation status as of May 2006

• Broken into two separate standards– WS-Addressing Core

• http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/

– WS-Addressing SOAP bindings• http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509/

How does it work?• Defines schema (namespace) that can be embedded in SOAP envelope Header

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2004/12/addressing"> <S:Header> <wsa:MessageID> http://example.com/SomeUniqueMessageIdString </wsa:MessageID> <wsa:ReplyTo> <wsa:Address>http://myClient.example/someClientUser</wsa:Address> </wsa:ReplyTo> <wsa:FaultTo> <wsa:Address>http://myserver.example/DemoErrorHandler</wsa:Address> </wsa:FaultTo> <wsa:To>http://myserver.example/DemoServiceURI</wsa:To> <wsa:Action>http://myserver.example/DoSomething</wsa:Action> </S:Header> <S:Body> <!-- The message body of the SOAP request appears here --> </S:Body></S:Envelope>

What problem does it solve?

• SOAP does not provide a standard way to specify – where a message is going– how to return a response– where to report an error

• Usually left up to the transport protocol, JMS (e.g.) message headers, packaged in SOAP body in ad-hoc way, etc.

• This is adequate for some applications but can be a limitation for others.

For example …

• Imagine an application that sends a request via JMS but wants a reply either as email or SMS

• WS-Addressing allows this by defining standard way to specify delivery, reply-to, and fault handler information within the SOAP header

WS-Coordination

• Standard developed by BEA, IBM, MSN and later contributed to by Arjuna, Hitachi, and IONA

• Appear to now be an approved OASIS spec as of February 2007

• See– http://docs.oasis-open.org/ws-tx/wscoor/2006/06

What problem does it solve?

• First gen WS defines protocols for Web Service interoperability.

• Web Services increasingly tie together a large number of participants forming large distributed computational units -- activities.

• Activities are often complex in structure, with complex relationships between their participants.

• The execution of activities often takes a long time to complete due to business latencies and user interactions.

• Defines extensible framework for coordinating activities using coordinator and set of coordination protocols.

– Enables participants to reach consistent agreement on outcome of distributed activities, e.g. protocols for simple short-lived operations and for complex long-lived business activities.

How does it work?

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

• Communicates through SOAP headers

• Uses Coordination Framework• Activation Service• Registration Service• Coordination Service

• Allows extensible use of

• WS-AtomicTransaction• WS-BusinessActivity• WS-AnythingNew

• Relies heavily on tooling

WS-AtomicTransaction

• Same participants as WS-Coordination– Works with (plugs into) WS-Coordination

• History– First draft September 2003

– Last revised August 2005

• Location of relevant documents– XSD file:

• http://www-128.ibm.com/developerworks/library/specification/ws-tx/wsat.xsd

– WSDL file: • http://www-128.ibm.com/developerworks/library/specification/ws-tx/wsat.wsdl

What problem does it solve?

• Used for typical short-lived transactions

• Coordination type that supplied three coordination protocols for two-phase commit transactions across multiple service participants– Completion, Durable 2PC, and Volatile 2PC protocols

• Atomic Transaction Coordinator makes ultimate commit/rollback decision.

• Can be used for ACID-type transactions

How does it work• Plugs into WS-Coordination framework as particular

<CoordinationType>

<CreateCoordinationContext> <ActivationService> <wsu:Address> http://Business456.com/tm/activation </wsu:Address> <myapp:MyPrivateState> 1234 </myapp:MyPrivateState> </ActivationService> <RequesterReference> <wsu:Address> http://fabrikam123.com/app1 </wsu:Address> </RequesterReference> <CoordinationType> http://schemas.xmlsoap.org/ws/2002/08/wstx </CoordinationType></CreateCoordinationContext>

Can also be BusinessActivity

WS-BusinessActivity

• Same participants as WS-Coordination– Works with (plugs into) WS-Coordination

• History– Accepted OASIS standard February 2007

• Location of relevant documents

– http://docs.oasis-open.org/ws-tx/wsba/2006/06

What problem does it solve?

• Similar to AtomicTransaction (both are types of WS-Coordination) but– Business Activities gover long-running, complex

service activities

– Hours, days, weeks can pass before activity is complete

– Business activities do not offer rollback• Instead provide compensation (Plan B).

• Compensation plan is invoked when e.g. operations cannot complete in certain time period, etc.

How does it work?

• See WS-AtomicTransaction

WS-ReliableMessaging

• Managed by OASIS– Original specification was written by IBM, Microsoft, BEA

Systems and Tibco.

• History– This was submitted to OASIS and was ratified as an OASIS

standard on 15 November 2004 as WS-ReliableMessaging 1.1

– Made WS-Reliability essentially obsolete

• Location of relevant documents– http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-rddl-200608.html

What problem does it solve?

• Often two Web services must communicate reliably in the presence of software component, system, or network failures.

• The primary goal of this specification is to create a modular mechanism for reliable message delivery.

• It defines a messaging protocol to identify, track, and manage the reliable delivery of messages between exactly two parties, a source and a destination.

• This specification integrates with and complements the WS-Security, WS-Policy, and other Web services specifications. Combined, these allow for a broad range of reliable, secure messaging options.

How does it work?• Definition of namespaced Schema to extend SOAP• e.g. see transmission below, includes wsa and wsrm

<?xml version="1.0" encoding="UTF-8"?> <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"> <S:Header> <wsa:MessageID> http://Business456.com/guid/71e0654e-5ce8-477b-bb9d-34f05cfcbc9e </wsa:MessageID> <wsa:To>http://fabrikam123.com/serviceB/123</wsa:To> <wsa:From> <wsa:Address>http://Business456.com/serviceA/789</wsa:Address> </wsa:From> <wsa:Action>http://fabrikam123.com/serviceB/123/request</wsa:Action> <wsrm:Sequence> <wsrm:Identifier>http://Business456.com/RM/ABC</wsrm:Identifier> <wsrm:MessageNumber>1</wsrm:MessageNumber> </wsrm:Sequence> </S:Header> <S:Body> <!-- Some Application Data --> </S:Body> </S:Envelope>

Message1:

?xml version="1.0" encoding="UTF-8"?> <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">

<S:Header> <wsa:MessageID> http://Business456.com/guid/daa7d0b2-c8e0-476e-a9a4-d164154e38de </wsa:MessageID> <wsa:To>http://fabrikam123.com/serviceB/123</wsa:To> <wsa:From> <wsa:Address>http://Business456.com/serviceA/789</wsa:Address> </wsa:From> <wsa:Action>http://fabrikam123.com/serviceB/123/request</wsa:Action> <wsrm:Sequence> <wsrm:Identifier>http://Business456.com/RM/ABC</wsrm:Identifier> <wsrm:MessageNumber>2</wsrm:MessageNumber> </wsrm:Sequence> </S:Header> <S:Body> <!-- Some Application Data --> </S:Body> </S:Envelope>

Message 2:

<?xml version="1.0" encoding="UTF-8"?> <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"> <S:Header> <wsa:MessageID> http://Business456.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546819 </wsa:MessageID> <wsa:To>http://fabrikam123.com/serviceB/123</wsa:To> <wsa:From> <wsa:Address>http://Business456.com/serviceA/789</wsa:Address> </wsa:From> <wsa:Action>http://fabrikam123.com/serviceB/123/request</wsa:Action> <wsrm:Sequence> <wsrm:Identifier>http://Business456.com/RM/ABC</wsrm:Identifier> <wsrm:MessageNumber>3</wsrm:MessageNumber> <wsrm:LastMessage/>

</wsrm:Sequence> </S:Header> <S:Body> <!-- Some Application Data --> </S:Body> </S:Envelope>

Message 3:

WS-BPEL

• OASIS standard– Developed by IBM, Miscrosoft, BEA, SAP, Seibel

• History– Developed from WSFL (IBM) and XLANG (Microsoft)– These merged into BPEL4WS

• Submitted to OASIS• Name changed to BPEL 2.0 in 2004

• Location of relevant documents– http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel

What problem does it solve?

• Given a collection of services, how does work get done -- that is, how does one execute a workflow that allows the services to form part of a larger application?

• This includes things like invoking several services simultaneously, setting up synchronization points, callbacks, conditional execution, etc.

• Note that BPEL can be used both for orchestration and choreography

How does it work?

• BPEL is an XML-based programming language

• BPEL allows you to write programs that invoke web services … chained in a certain way, with switch statements, etc.

• BPEL also allows you to have same program _be_ executed as a webservice

<?xml version="1.0" encoding="UTF-8"?><process

xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"xmlns:print="http://www.eclipse.org/tptp/choreography/2004/engine/Print"

<!--Hello World - my first ever BPEL program -->

<import importType="http://schemas.xmlsoap.org/wsdl/" location="../../test_bucket/service_libraries/tptp_EnginePrinterPort.wsdl" namespace="http://www.eclipse.org/tptp/choreography/2004/engine/Print" />

<partnerLinks><partnerLink name="printService"

partnerLinkType="print:printLink" partnerRole="printService"/>

</partnerLinks>

<variables><variable name="hello_world"

messageType="print:PrintMessage" /></variables>

<assign><copy>

<from><literal>Hello World</literal></from><to>$hello_world.value</to>

</copy></assign>

<invoke partnerLink="printService" operation="print" inputVariable="hello_world" /></process>

WS-CDL

• “Choreography Description Languge”

• W3C candidate recommendation– As of November 2005– Authored by Oracle, Commerce One, Novell,

Choreology, W3C, Adobe

• Location of relevant documents– http://www.w3.org/2002/ws/chor/

What problem does it solve?

How does it work?

<interaction name="QuoteElicitation" operation="getQuote" channelVariable="tns:Buyer2SellerC"> <description type="documentation"> Quote Elicitation </description> <participate relationshipType="tns:Buyer2Seller" fromRoleTypeRef="tns:BuyerRole" toRoleTypeRef="tns:SellerRole"/> <exchange name="QuoteRequest" informationType="tns:QuoteRequestType" action="request"> <description type="documentation"> Quote Request Message Exchange </description> <send variable="cdl:getVariable('quoteRequest','','')"/> <receive variable="cdl:getVariable('quoteRequest','','')"/> </exchange> <exchange name="QuoteResponse" informationType="tns:QuoteResponseType" action="respond"> <description type="documentation"> Quote Response Message Exchange </description> <send variable="cdl:getVariable('quoteResponse','','')"/> <receive variable="cdl:getVariable('quoteResponse','','')"/> </exchange> <exchange name="QuoteResponseFault" informationType="tns:QuoteResponseFaultType"

action="respond" faultName="InvalidProductFault"> <description type="documentation"> Quote Response Fault Exchange </description> <send variable="cdl:getVariable('faultResponse','','')"/> <receive variable="cdl:getVariable('faultResponse','','')"/> </exchange></interaction>>

Like BPEL, an WS-CDL is an XML-based programming language

WS-Policy

• W3C standard as of March 2006– BEA, IBM, Microsoft, SAP AG, Sonic, Verisign

• Part of family of WS-Policy framework– WS-Policy

– WS-PolicyAttachments

– WS-PolicyAssertions

• Location of relevant documents– http://schemas.xmlsoap.org/ws/2004/09/policy/

What problem does it solve?

• Allows a service to publicize/assert requirements about things beyond what appears in the WSDL– Capabilities, requirements, characteristics, rules

– Examples• What version of a message format is required, preferred, etc?

What date will the old format no longer be accepted?

• What are the security expectations for clients?

• What are limitations on how the component can be used, other components it can be used with.

How does it work?

<wsp:Policy xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" > <wsp:ExactlyOne> <sp:Basic256Rsa15 /> <sp:TripleDesRsa15 /> </wsp:ExactlyOne> </wsp:Policy>

From WS-SecurityPolicy

WS-Security

• OASIS standard– Originally led by Microsoft, IBM, and VeriSign

• History– First accepted in 2004

– Version 1.1 released in 2006

• Location of relevant documents– http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf

What problem does it solve?

• How can a web service limit who invokes its operations based on security restrictions

• How can data be secured for any interaction?

• This is usually divided into– Identification, authentication, authorization

– Confidentiality, integrity

How does it work?

<?xml version="1.0" encoding="utf-8"?> (002) <S11:Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu="..." xmlns:ds="..."> <S11:Header> <wsse:Security xmlns:wsse="..."> <wsse:BinarySecurityToken ValueType="http://fabrikam123#CustomToken " EncodingType="...#Base64Binary" wsu:Id=" MyID "> 425 FHUIORv... (007) </wsse:BinarySecurityToken>(008) <ds:Signature> 428 (009) <ds:SignedInfo> 429 (010) <ds:CanonicalizationMethod 430 Algorithm= 431 "http://www.w3.org/2001/10/xml-exc-c14n#"/> 432 (011) <ds:SignatureMethod 433 Algorithm= "http://www.w3.org/2000/09/xmldsig#hmac-sha1"/> 435 (012) <ds:Reference URI="#MsgBody"> (013) <ds:DigestMethod Algorithm= "http://www.w3.org/2000/09/xmldsig#sha1"/> (014) <ds:DigestValue>LyLsF0Pi4wPU...</ds:DigestValue> (015) </ds:Reference> (016) </ds:SignedInfo> (017) <ds:SignatureValue>DJbchm5gK...</ds:SignatureValue> (018) <ds:KeyInfo> (019) <wsse:SecurityTokenReference> (020) <wsse:Reference URI="#MyID"/> (021) </wsse:SecurityTokenReference> (022) </ds:KeyInfo> (023) </ds:Signature> (024) </wsse:Security> (025) </S11:Header> (026) <S11:Body wsu:Id="MsgBody"> (027) <tru:StockSymbol xmlns:tru="http://fabrikam123.com/payloads"> QQQ </tru:StockSymbol> (028) </S11:Body> (029) </S11:Envelope>

WS-ReliableMessaging

A more in-depth look

Sun, along with Fujitsu, Hitachi, NEC, Oracle, Sonic Software, published a Web Services Reliability (WS-Reliability) specification in January 2003. Microsoft, IBM, BEA and TIBCO this week published the WS-ReliableMessaging specification, which analysts say is different, but equally important.

The WS-Reliability approach by Sun and its partners calls for guaranteed "message ordering, message delivery and the removal of duplicate messages." The new WS-ReliableMessaging spec aims to provide the "necessary protocol for ensuring that unreceived and duplicate messages can be detected, and received messages can be processed in the order in which they were sent."

Despite the fact that the specs work to meet the same end -- proper message delivery -- Sun is incensed about the overlap and different approach, which it said will drive a wedge in an industry already fraught with uncertainty and tentativeness.

In a public statement, Sun said: "The announcement by Microsoft, IBM, BEA and TIBCO regarding the publication of two new specifications stands in stark contrast to Sun's philosophy and the larger industry need for standards convergence among vendors in this space."

The Santa Clara, Calif.-based firm went so far as to call IBM and Microsoft a "disruptive force" that has "now moved away from a leadership position in Web services standards."

"These specifications clearly replicate work already underway in OASIS to address WS-Reliability and we do not understand why this wasn't taken into consideration before these specifications were published," Sun …

DeveloperMarch 14, 2003

WS-ReliableMessaging

• A web services framework for delivery assurance– To assure that a message sent from service A arrived at service B

– Be careful: WS-RM cannot make your network more reliable -- it merely simplifies the process of finding this out

• XML, XSD, http, SOAP do not provide this by themselves– Though you can program “by hand” on per-application basis

• Can define bindings to arbitrary transport protocol– Standard specifies a SOAP binding, others possible

More on WS-RM

• Best for – Asynchronous exchanges with long delay– Exchanges with multiple hops

• Notice this does not cover all possible failures– Can answer: did message make it to other side?– Cannot say whether recv app actual got message

• Could have died between RM and app, disk failure, etc.

• Good example is sending an invoice– Response might take days or weeks– Need to know if invoice was received or not

Types of Delivery Assurance

• There are four basic delivery assurances that endpoints can provide– AtMostOnce Messages will be delivered at most once without duplication

or an error will be raised on at least one endpoint. Some messages in a sequence may not be delivered.

– AtLeastOnce Every message sent will be delivered or an error will be raised on at least one endpoint. Some messages may be delivered more than once.

– ExactlyOnce Every message sent will be delivered without duplication or an error will be raised on at least one endpoint. This delivery assurance is the logical "and" of the two prior delivery assurances.

– InOrder Messages will be delivered in the order that they were sent. This delivery assurance may be combined with any of the above delivery assurances. It requires that the sequence observed by the ultimate receiver be non-decreasing. It says nothing about duplications or omissions.

Preconditions

• The correct operation of the protocol requires that a number of preconditions MUST be established prior to the processing of the initial sequenced message:

– The RM Source MUST have an endpoint reference that uniquely identifies the RM Destination endpoint; correlations across messages addressed to the unique endpoint MUST be meaningful.

– The RM Source MUST have knowledge of the destination's policies, if any, and the RM Source MUST be capable of formulating messages that adhere to this policy.

– If a secure exchange of messages is required, then the RM Source and RM Destination MUST have a security context.

Invariants

• During the lifetime of the protocol, two invariants are REQUIRED for correctness– The RM Source MUST assign each reliable message a

sequence number (defined below) beginning at 1 and increasing by exactly 1 for each subsequent reliable message.

– Every acknowledgement issued by the RM Destination MUST include within an acknowledgement range or ranges the sequence number of every message successfully received by the RM Destination and MUST exclude sequence numbers of any messages not yet received.

QuickTime™ and aTIFF (LZW) decompressor

are needed to see this picture.

Definitions

Reliable Messaging (RM): The act of processing the set of transport-agnostic SOAP Features defined by WS-Reliability, which results in a protocol supporting quality of service features such as guaranteed delivery, duplicate message elimination, and message ordering.

Reliable Messaging Processor (RMP): A SOAP processor and other infrastructure capable of performing Reliable Messaging as described by this specification. With regard to the transmission of a Reliable Message from one RMP to another, the former is referred to as the Sending RMP and the latter as the Receiving RMP. An RMP may act in both roles.

Reliable Message: A SOAP message containing a <wsrm:Request> header block.

Payload: A subset of the message data intended for the Consumer or Producer of the Reliable Message and provided by the Producer or Consumer respectively.

QuickTime™ and aTIFF (LZW) decompressor

are needed to see this picture.

REST

Representational State Transfer

What is REST?

• Like SOA, an architectural model for building scalable applications

• Typical presented as SOA vs. REST, or SOAP vs. REST– Warning: among the hottest (and most irrational) debates

around

• Warning– Like SOA, REST is used in different ways by different

people. Core ideas are reasonably clear, though.

Basic idea

• Do not expose remote services via domain specific interface (a la rpc):– getStockQuote(…)

– makePayment(…)

– Etc.

• Rather use standard interface for all services– Get, Post, Delete

– Yes, just like the http interface

Basic idea, cont.

• Then, have the application locate resources rather than return SOAP message

• Yes, resources identified by URL

• Once resource is located application changes to new state.

• New state has embedded links (via xlink) to hone in on data (ie change to other states).

What we will do

• Of course, there is a little more to it than this.

• We will cover Costello tutorial slides (included on web page with copyright). They are pretty good.

• We will then study several debates on different web sites and argue among ourselves.

Web sites for debates

• MS Ignoring developer demand for REST tools?– http://blogs.msdn.com/xmlteam/archive/2005/02/15/372982.aspx

• Rebuttals to “Google’s Gaffe”– http://diveintomark.org/archives/2002/04/25/soap_vs_rest

• O’Reilly chimes in– http://www.regdeveloper.co.uk/2006/04/29/oreilly_amazon/

• Interview with Weerawarana– http://www.infoq.com/articles/sanjiva-rest-myths