web services foundations (2): soap, wsdl and uddiweb services foundations (2): soap, wsdl and uddi...

Web Services Foundations (2): SOAP, WSDL and UDDI

Helen Paik

School of Computer Science and EngineeringUniversity of New South Wales

References used for the Lecture:

Webber Book Chapter 7

Blue Book Chapters 5-7

Mike Book Chapter 6

http://www.soaspecs.com/ws.php

Acknowledgement: Some other materials is adapted from COMP9322 lectures in previous sessions, which are prepared byDr. Helen H-Y Paik, Dr. Sherif Sakr.

Week 3

H. Paik (CSE, UNSW) ws-foundation Week 3 1 / 56


Part I

More on SOAP/WSDL


Designing WS Interface with SOAP/WSDLGiven an operation:

Operation name: concat

Parameters: (st1: string, st2: string)

Return: string

More precisely as WS operation ...

Local name: concat

Namespace: http://sltf.unsw.edu.au/eg

Input message:

Part 1:

Name: st1

Type: string in http://www.w3.org/2001/XMLSchema

Part 2:

Name: st2


Output message:

Part 1:

Name: return



Designing WS Interface with SOAP/WSDL - RPC style

Local name: concat Namespace: http://sltf.unsw.edu.au/egInput message:Part 1: Name: st1 Type: string in http://www.w3.org/2001/XMLSchemaPart 2: Name: st2 Type: string in http://www.w3.org/2001/XMLSchemaOutput message: Part 1: Name: return Type: string in http://www.w3.org/2001/XMLSchema

<ese:concat xmlns:ese="http://sltf.unsw.edu.au/eg" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-Instance"> <st1 xsi:type="xsd:string">service</st1> <st2 xsi:type="xsd:string">foundry</st2></ese:concat>

<ese:concatResponse xmlns:ese ="http://sltf.unsw.edu.au/eg" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-Instance"> <return xsi:type="xsd:string">service foundry</return></ese:concatResponse>


Designing WS Interface w/ SOAP/WSDL: Document-style

(note - We first should define the message types)

Local name: concat Namespace: http://sltf.unsw.edu.au/egInput message:Part 1: Name: concatRequest Element: concatRequest in http://sltf.unsw.edu.au/egOutput message: ...

<xsd:schema targetNamespace="http://sltf.unsw.edu.au/eg" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="concatRequest"> <xsd:complexType> <xsd:sequence> <xsd:element name="st1" type="xsd:string"/> <xsd:element name="st2" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element></xsd:schema>

Type of concatRequest defined as a schema



Local name: concat Namespace: http://sltf.unsw.edu.au/egInput message:Part 1: Name: concatRequest Element: concatRequest in http://sltf.unsw.edu.au/egOutput message: Part 1: Name: concatResponse Element: concatResponse in http://sltf.unsw.edu.au/eg

<xsd:schema targetNamespace="http://sltf.unsw.edu.au/eg" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="concatRequest"> <xsd:complexType> <xsd:sequence> <xsd:element name="st1" type="xsd:string"/> <xsd:element name="st2" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="concatResponse" type="xsd:string"/></xsd:schema>

Type of concatResponse also defined as a schema



<xsd:schema targetNamespace="http://sltf.unsw.edu.au/eg" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="concatRequest"> <xsd:complexType> <xsd:sequence> <xsd:element name="st1" type="xsd:string"/> <xsd:element name="st2" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="concatResponse" type="xsd:string"/></xsd:schema>

<ese:concatRequest xmlns:ese="http://sltf.unsw.edu.au/eg"> <st1>service</st1> <st2>foundry</st2></ese:concatRequest>

<ese:concatResponse xmlns:ese ="http://sltf.unsw.edu.au/eg"> service foundry</ese:concatResponse>

These SOAP messages can be validated against the schema


RPC and Document Binding Options in WSDL

Option 1: (see SimpleConcatRPC as example)

soap:binding, style=rpc, transport=httpsoap:body, use=literal (’encoded’ option not supported)

Option 2: (see SimpleConcatDOC as example)

soap:binding, style=document, transport=httpsoap:body, use=literal

Note: communication pattern – both could be done in RPC/synchronousstyle


Fault Handling in SOAP

A SOAP Fault message is reserved for providing an extensible mechanismfor transporting structured and unstructured information about problemsthat have arisen during the processing of SOAP messages.

Because clients can be written on a variety of platforms using differentlanguages, there must exist a standard, platform-independent mechanismfor communicating the error. SOAP provides a platform-independent wayof describing the error within the SOAP message using a SOAP fault.

Fault element is located inside body of the message

Two mandatory elements: Code and Reason

Code - e.g., VersionMismatch, MustUnderStand,

DataEncodingUnknown, Sender

Reason - Human readable description of the fault

and other elements (see documents: JAX-WS SOAP Faults)


SOAP faults appear in the SOAP body sectione.g., SOAP v1.2

<?xml version=’1.0’ ?>

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" ...

<env:Body>

<env:Fault>

<env:Code>

<env:Value>env:Sender</env:Value>

<env:Subcode>

<env:Value>rpc:BadArguments</env:Value>

</env:Subcode>

</env:Code>

<env:Reason>

<env:Text xml:lang="en-US">Processing error</env:Text>

</env:Reason>

<env:Detail>

<e:myFaultDetails xmlns:e="http://travelcompany.example.org/faults">

<e:message>Name does not match card number</e:message>

<e:errorcode>098</e:errorcode>

</e:myFaultDetails>

</env:Detail>

</env:Fault>

</env:Body>

</env:Envelope>H. Paik (CSE, UNSW) ws-foundation Week 3 10 / 56

SOAP faults appear in the SOAP body section

e.g., SOAP v1.1 (simpler structure)

<?xml version="1.0"?>

<soap:Envelope

xmlns:soap=’http://schemas.xmlsoap.org/soap/envelope’>

<soap:Body>

<soap:Fault>

<faultcode>soap:VersionMismatch</faultcode>

<faultstring, xml:lang=’en">

Message was not SOAP 1.1 compliant

</faultstring>

<faultactor>

http://sample.org.ocm/jws/authnticator

</faultactor>

</soap:Fault>

</soap:Body>

</soap:Envelope>


<definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://examples/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap… targetNamespace="http://examples/" name="HelloWorldService"> <types> <xsd:schema> <xsd:import namespace="http://examples/" schemaLocation="http://localhost:…/> </xsd:schema> </types> <message name="sayHelloWorld"> <part name="parameters" element="tns:sayHelloWorld" /> </message> <message name="sayHelloWorldResponse"> <part name="parameters" element="tns:sayHelloWorldResponse" /> </message> <message name="MissingName"> <part name="fault" element="tns:MissingName" /> </message> <portType name="HelloWorld"> <operation name="sayHelloWorld"> <input message="tns:sayHelloWorld" /> <output message="tns:sayHelloWorldResponse" /> <fault message="tns:MissingName" name="MissingName" /> </operation> </portType> <binding name="HelloWorldPortBinding" type="tns:HelloWorld"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" /> <operation name="sayHelloWorld"> <soap:operation soapAction="" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> <fault name="MissingName"> <soap:fault name="MissingName" use="literal" /> </fault> </operation> </binding> <service name="HelloWorldService"> <port name="HelloWorldPort" binding="tns:HelloWorldPortBinding"> <soap:address location="http://localhost:7001/HelloWorld/HelloWorldService" /> </port> </service>

Modelled SOAP faults - in WSDL definition (example from Oracle Docs)


Modelled SOAP faults - in service-side code

Web services throws the custom Exception- MissingName

package examples;import javax.jws.WebService;

@WebService(name="HelloWorld", serviceName="HelloWorldService")public class HelloWorld { public String sayHelloWorld(String message) throws MissingName { System.out.println("Say Hello World: " + message); if (message == null || message.isEmpty()) { throw new MissingName(); } return "Here is the message: '" + message + "'"; }}

Custom Exception (MissingName.java)

package examples;import java.lang.Exception;

public class MissingName extends Exception { public MissingName() { super("Your name is required."); }}


Modelled SOAP faults - in SOAP

The following shows how the SOAP fault is communicated in the resultingSOAP message when the MissingName Java exception is thrown.

<?xml version = '1.0' encoding = 'UTF-8'?><S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Body> <S:Fault xmlns:ns4="http://www.w3.org/2003/05/soap-envelope"> <faultcode>S:Server</faultcode> <faultstring>Your name is required.</faultstring> <detail> <ns2:MissingName xmlns:ns2="http://examples/"> <message>Your name is required.</message> </ns2:MissingName> </detail> </S:Fault> </S:Body></S:Envelope>


SOAP Message Processing Model

SOAP engines provide a message processing model that assumes thata SOAP message originates at an initial SOAP sender and is sent toan ultimate SOAP receiver via zero or more SOAP intermediaries.

The messages pass through a number of intermediate nodes betweenthe sender and the receiver.

Initial Sender: The message originatorUltimate Receiver: The intended recipientIntermediaries: Processing blocks that operate on the soap messagebefore it reaches the ultimate receiver

Sender Intermediatenext

Intermediatenext

UltimateReceiver...

Message Flow


SOAP processing model

In a SOAP server (handlers == nodes):

SOAP Server

Web Service Application Logic

Dispatch

body body

header

header

header

header

Handler

Handler

Handler

Handler

header(s)body

header(s)body

SOAP

Req

uest

SOAP R

esponseConsumes ... Produces ...

Network

Request: process the header blocks, Response: generates the header blocksH. Paik (CSE, UNSW) ws-foundation Week 3 16 / 56

SOAP Processing Model

The intermediaries work by intercepting messages, performing theirfunction, and forwarding the (altered) message to the ultimate receiver.

Common examples of intermediaries would be:

logging

encryption/decryption intermediary

auditing purpose (e.g., persisting messages for billing or compliance)

Above all, using this model, it is possible to build ‘extensions’ to basicSOAP (e.g., supporting transaction, different security standards) ...

A SOAP engine ’implements’ a model of their own based on these basics(cf. Axis2 or CXF architecture documentations).


e.g., Apache CXF - Interceptor model

Inbound, Outbound chains, Phases and Interceptors

Client

Outbound

Inbound

Server

Outbound

Inbound


e.g., Apache CXF - Interceptor model

Developing an interceptor, regardless of its functionality, always follows thesame basic procedure:

Determine which abstract interceptor class to extend.

Determine the phase in which the interceptor will run.

public class HelloWorldInterceptor extends AbstractPhaseInterceptor

public HelloWorldInterceptor()

super(Phase.INVOKE); // Put this interceptor in this phase

public void handleMessage(Message message) throws Fault

// do the intercepting here ...

Implement the interceptor’s message processing logic.

Attach the interceptor to one of the endpoint’s interceptor chains(configuration).


SOAP Headers - examples

Header blocks should contain information that influences payload processing (e.g.,WS-security standard: credentials info that helps control access to an operation)


SOAP Headers - examples

(e.g., WS-Addressing standard: sending address information (e.g., client callback,routing))


Summary

Binding in WSDL defines (i) message encoding format (ii) transportprotocol details. (...) and (...) are two options available in<soap:binding style=’...’>.

A SOAP server employs a pipeline based SOAP message processingmodel which includes: a sender, ultimate receiver and a series of (...).

Each (...) is responsible for processing a (...)

Can you roughly draw a diagram to illustrate how in-bound andout-bound SOAP messages are handled by a SOAP server?

Why, would you say, is this type of processing model important inusing SOAP for WS communication?

SOAP message body can contain a normal response or a faultthrough (...)

Where are the details of faults (if any) by a service declared ?


Part II

UDDI - Advertising/Discovering Services


Service Registries

To discover Web services, a service registry is needed. This requiresdescribing and registering the Web service.

Publication of a service requires proper description of a Web servicein terms of business, service, and technical information.

Registration deals with persistently storing the Web servicedescriptions in the Web services registry.

Two types of registries can be used:The document-based registry: enables its clients to publishinformation, by storing XML-based service documents such as businessprofiles or technical specifications (including WSDL descriptions of theservice).The meta-data-based service registry: captures the essence of thesubmitted document.


Service Discovery

Service discovery is the process of locating Web service providers,and retrieving Web services descriptions that have been previouslypublished.

Interrogating services involve querying the service registry for Webservices matching the needs of a service requestor.

A query consists of search criteria such as: the type of the desiredservice, preferred price and maximum number of returned results, andis executed against service information published by service provider.

After the discovery process is complete, the service developer or clientapplication should know the exact location of a Web service (URI), itscapabilities, and how to interface with it.


Types of service discovery

Static:

The service implementation details are bound at design time and a serviceretrieval is performed on a service registry.

The results of the retrieval operation are examined usually by a humandesigner and the service description returned by the retrieval operation isincorporated into the application logic.

Dynamic:

The service implementation details are left unbound at design time so thatthey can be determined at run-time.

The Web service requestor has to specify preferences to enable theapplication to infer/reason which Web service(s) to choose

Based on application logic quality of service considerations such as bestprice, performance or security certificates. The application chooses the mostappropriate service, binds to it, and invokes it.


UDDI

Universal Description Discovery and Integration

Service

ServiceRegistry

ServiceRequestor

ServiceProvider

ServiceDescription

ServiceDescription

In UDDI

UsingSOAP

In YourOwn

Language

In WSDL

Find

Bind

Publish


UDDI and the big idea

UDDI Business Registry

1. SW companies, standard bodies,and programmers populate theregistry with description of various types of services

2. Businesses populate the registry withdescriptions of the services they support

3. UBR assigns a unique identifier to each service andbusiness registration

4. Marketplaces,search engines and

business apps query theregistry to

discover services atother companies

5. Business uses this datato facilitate easier

integration with each other over the web

BusinessRegistrations

Service TypeRegistrations


UDDI and the big idea

How to find the service you want among a potentially large collection ofservices and servers. The client does not necessarily need to know a prioriwhere the server resides or which server provides the service.

ServiceRegistry

ServiceRequestor

ServiceProvider

(1) Registration requestfor service description

(2) Query for allmatching services in

the registry

(3) Discoveryresults

(4) Requestfor selected

service information

(5) Serviceinformation of

selected service

(6) Invocation requestincluding inputs

(7) Invocation resutls

SEARCH

INVOKE

PUBLISH


UDDI

UDDI is a registry (not repository) of Web services

IBM and Microsoft *used* to host public UDDI registry

Before UDDI, there was no standard way of finding documentation orthe location of a particular remote object. Ad-hoc documentationmay look like:

Contact person: John Smith

COM+ Object: GetWeatherInfo

COMP+ Server: http://bindingpoint.com

Relative URL: /metero/weather

Proxy Location: /Instal/GetWeatherInfo.dll

Description: Returns today’s weather. It requires a zip code ...

UDDI is not part of W3C standard (unlike SOAP, WSDL)

The main standard body for it is OASIS http://www.oasis-open.org,http://uddi.xml.org


http://www.oasis-open.org

http://uddi.xml.org

UDDI

UDDI shares similarities with telephone directories.

White Pages: Contact information about the service providercompany. This information includes the business or entity name,address, contact information, other short descriptive informationabout the service provider, and unique identifier with which tofacilitate locating this business

Yellow Pages: Categories under which Web services implementingfunctionalities within those categories can be found

Green Pages: Technical information about the capabilities andbehavioral grouping of Web services


UDDI - overview of its data structure

UDDI Registry Entry

Business Entity name contacts description identifiers categories

Business Entity name contacts description identifiers categories

Business Service service key business key name description categories

Business Service service key business key name description categories

Binding Template binding key description access point



tModel name description overview document URL to specifications

WSDL document(located at the service provider's site)

white page information

yellow page information

green page information


WSDL and UDDI Mapping (e.g., jUDDI Apache Project)

<import>

<service>

<port>

<import>

<binding>

<types><messages><portType>

businessEntity

businessService

bindingTemplate accessPoint=[access point] portType=[portType tModel] binding=[binding tModel] local name=[port local name]

tModel name=[binding local name] overviewURL=[wsdl location]

categoryBag type=binding namespace=[namespace] portType=[portType tModel]

tModel name=[binding local name] overviewURL=[wsdl location]

categoryBag type=portType namespace=[namespace]

<port>

WSDL

Service Implementation

Service Binding

Service Interface

UDDI


UDDI

UDDI registry can be browsed by human

UDDI registry can be programmatically accessed

Inquiry API: enable lookup of registry information

Publishers API: allow applications to register services

an XML schema for SOAP message is defined

SOAP is used as the communication protocol

An example implementation (jUDDI by Apache)http://juddi.apache.orghttp://juddi.apache.org/docs/3.2/juddi-client-guide/html/


UDDI’s provided APIs

UDDI provides a SOAP-based API to the business registry.

UDDI Inquiry APIs: includes operations to find registry entries.

Browse, Drilldown, Invocation Patterns

UDDI Publish APIs: operations to add, modify and delete entries inthe registry.

UDDI Security API: for access control to the UDDI registry.

UDDI Subscription API: for clients to subscribe to changes ofinformation in the UDDI registry.

UDDI Replication API: to perform replication of information acrossnodes in a UDDI registry.


UDDI’s provided APIs

White pages info.White pages info.

Yellow pages info.Yellow pages info.

Green pages info.Green pages info.

Technical info.Technical info.

Pointer to service descriptionPointer to service description

UDDI entryUDDI entry

ServiceService

UDDIserviceregistry

ServiceServicedescriptiondescription

Servicerequestor

Serviceprovider

WSDLWSDLserviceservicedescriptiondescription

Inquiry URL Publishing URL

SOAP-HTTP SOAP-HTTPS


Interaction with and between UDDIs

Service ProviderService Consumer

Web Service Interface

Web Service DescriptionWeb Service Description

Web Service Interface

Web Service DescriptionWeb Service Description

Publisher APIInquiry API

Subscription,Replication,Transfer API(HTTPS/SOAP)

HTTP/SOAP SOAP/HTTPS


How UDDI could play out: an opinion (Webber Book pp.136-141)

Question: Is it reasonable to assume that “people” will search a serviceregistry using APIs to select a service during design time?

Most likely no ... that’s just not how “people” do business

You will browse, ask around (word of mouth), google, etc.

Oftentimes, the selection criteria can be tricky (e.g., existing businessrelationships, cutting deals, etc.)

If UDDI is not going to be useful in selecting services ... then what?

Note: Most of the UDDI registries in place today are private registriesoperating inside companies or maintained by a set of companies in aprivate manner



... UDDI might be useful at runtime ...

Case 1: Service Life-cycle Management

Consider the issues you have to deal with after Web services are deployedand clients are using them

Overtime, some changes might have to be made (not only the code,but also the physical environment that the service is deployed in)

e.g., migration to a new server, multiple mirror servers, routinemaintenance on the server ...

Applications that rely on Web services need to stay updated with thelatest access end-point information

How do we propagate the changes to the access point?

UDDI can play the runtime broker/middleman in handling and propagatingthese changes ...



Scenario: Service Life-cycle management with UDDI

A Web service is selected for use (searched in or outside UDDI)

Save (in your local database) the bindingTemplate information of theservice from UDDI

Develop an application using the service

If the service call fails (or times out):

query UDDI for the lastest information

compare the info. with the saved info.

if different, try calling the service again with the new info.

update your local bindingTemplate if needed



... UDDI might be useful at runtime ...

Case 2: Dynamic access point management

Not only when a service call is failed, you may want to dynamicallymanage and select the most appropriate access point for a service.

A service may be available from multiple geographical locations

The client application may have been developed in one country andlater used in another county

The concept is similar to downloading files from different mirror sites.The access point can be hardwired in the client application, but bydynamically selecting the most appropriate access point (based on certaincriteria) may lead to increased performanace.



UDDIRegistry

Service Aggregator

Access

Web PortalAccess

Direct Programmatic

Acess

Direct Programmatic

Acess

Design-timeAccess to UDDI

Run-timeAccess to UDDI

Accessing UDDI:

Desgin time access – via manual search or direct API acccess, to searchand discover services during the application design phase

Runtime access (UDDI playing a brokering/middleman role) – via directAPI access, it offers possibilities to build more robust and flexibleapplications


Static Discovery of Web Services ...

There are some public Web service registries operating (not followingUDDI):

XMETHODS (seems to be offline nowadays):http://www.xmethods.net/ve2/Directory.po

WebserviceX.NET:http://www.webservicex.net/WS/wscatlist.aspx

WebServiceList:http://www.webservicelist.com (with user rating info)


http://www.xmethods.net/ve2/Directory.po

http://www.webservicex.net/WS/wscatlist.aspx

http://www.webservicelist.com

Summary

Can you describe a service registration process and a service discoveryprocess?

What is the purpose of a WSDL to UDDI mapping model?

Can you list some of the operations in UDDI API?

Alternative/suggested use of UDDI ...?


Part III

WS-*: Web Service Extensions


Web Service Standards: WS-* extensions

The term “WS-*” refers to the second generation of Web servicesstandards/specifications.On top of the basic standards (WSDL, SOAP and UDDI), theseextensions focus on providing supports for various issues in enterprisecomputing environment

Transports

Messaging

Description and Discovery

Transactions Reliability Security

Business Processes Management

First Generation WS

Second Generation WS

http://www.ibm.com/developerworks/webservices/standards/


Web Service Standards: WS-* extensions

e.g., http://www.ibm.com/developerworks/webservices/standards/Standards Maze

WS-Addressing

WS-Attachments

WS-Transfer

WS-ReliableMessaging

WS-Reliability

WS-Acknowledegment

ebXMLBPMLSPML

WS-Provisioning

WSDL

Cool! But,What

Standards I use?

We should integrate our systems using Web Service Technologies …

Manager

UDDI

WSRP

WS-InspectionWS-DiscoveryASAP

SOAP

SOAP MTOM

WS-Routing

WS-Referral

XrML

WSXL

WS-Coordination

WS-Enumeration

WS-NotificationWS-Eventing

WS-Topics

WSCI

WSCDLBPEL4WS

WS-MetadataExchange

WS-PolicyFramework

WS-PolicyAssertionsWS-PolicyAttachment

XACMLWS-SecurityPolicy

WSCL

WS-Manageability

WS-ResourceWSDM

WS-BusinessActivityWS-Transaction

WS-AtomicTransactions

BTP

use?

WS-Federation

WS-Security

WS-Trust

WS-SecureConversation

SAML

XKMSWS-NonRepudiation

WS-MessageDataWS-CallBack

Too many, Overlap, Conflicts, Convergence (WSDL, SOAP) (See ``Interoperability Specifications’’, May 06, IEEE Computer, by. Motahari,

Benatallah, Casati and Toumani)

OWL Fat OWL Light


WS-* extensions and their relationships

WSDL

WS-Reliable

Messaging

WS-Coordination

BPEL4WS

UDDI

WS-Transaction

WS-Security

WS-Policy

SOAP

WebServices

enablesdiscovery of

describesthe service for

describes

uses

governs

managescontext for

provides protocol for

providesend-to-endsecurity for

providesguaranteeddelivery for

uses

uses

binds to

enablescommunication

between

uses

orchestratesdescribes

the services for

improvesreliability ofenables

distributedtransactions for

provides protocol for

managescontext across

uses

uses

is accessed using



WS-* extensions: Reliable Messaging (Blue Book Chap. 7)

After a Web service transmit a message, it has no immediate way ofknowing whether:

the message successfully arrived at its destination

the message failed to arrive and therefore requires a retransmission

a series of messages arrived in the sequence they were intended to

Web service reliable messaging is a framework that enables an applicationrunning on one application server to reliably invoke a Web service runningon another application server, assuming that both servers implement theWS-ReliableMessaging specification.

Reliable is defined as the ability to guarantee message delivery between thetwo endpoints (Web service and client) in the presence of softwarecomponent, system, or network failures.


Reliable Messaging (Blue Book Chap. 7)

ApplicationSource

ApplicationDestination

RM Source

RM Destination

SEND RECEIVE

TRANSMIT

WS-RM separates/abstracts ‘initiating messaging’ from ‘performingactual transmission’

e.g., application source is the service that sends the message to theRM source (the physical processor/node that performs the actual wiretransmission.



Sequences:

A sequence establishes the order in which messages should bedelivered

Each message is labeled with a message number, the last one being alast message identifier.

Acknowledgements:

A core part of reliable messaging is a notification system used tocommunicate conditions from the RM dest. to the RM source.

The acknowledgement message indicates to the RM source whichmessages were received.

All this information is “injected” into SOAP headers within the messagesthemselves.



SEQUENCE

ApplicationSource


RM Source

RM Destination

SEQUENCEACK.

A sequence acknowledgement sent by the RM dest. after the successfuldelivery of a sequence of messages.



Incomplete Sequence

ApplicationSource


RM Source

RM Destination

failed delivery

Successful delivery

negative acknowledgement delivery

A negative ack. sent by the RM dest. to the RM source, indicating faileddelivery prior to the completion of the sequence.



Delivery assurances:

the nature of a sequence is determined by a set of reliability rulesknown as Delivery Assurances.

They are predefined message delivery patterns that establish a set ofreliability policies


Reliable Messaging (Blue Book Chap. 17)An example:<Envelope

xmlns="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"

xmlns:wsrm="http://schemas.xmlsoap.org/ws/2004/03/rm">

<Header>

<wsrm:Sequence>

<wsu:Identifier>

http://www.xmlrc.com/railco/seq22231

</wsu:Identifier>

<wsrm:MessageNumber>

15

</wsrm:MessageNumber>

<wsrm:LastMessage/>

</wsrm:Sequence>

</Header>

<Body>

...

</Body>

</Envelope>


Reliable Messaging (Blue Book Chap. 17)An example:<Envelope

xmlns="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"

xmlns:wsrm="http://schemas.xmlsoap.org/ws/2004/03/rm">

<Header>

<wsrm:SequenceAcknowledgement>

<wsu:Identifier>

http://www.xmlrc.com/railco/seq22231

</wsu:Identifier>

<wsrm:AcknowledgementRange Upper="4" Lower="1"/>




</wsrm:SequenceAcknowledgement>

</Header>

<Body>

...

</Body>

</Envelope>


web services foundations (2): soap, wsdl and uddiweb services foundations (2): soap, wsdl and uddi...

Documents