advanced messaging

Advanced Messaging

CS409 Application ServicesEven Semester 2007

2

• Focused on the delivery of application data and the composable nature of SOA.

• Deal with issues of:– How to deliver reliable messages.– Creation and exchange of metadata.– Imposing security in message deliveries.– How to get notified upon delivery of message.

Advanced Messaging

3

WS-* for Advanced Messaging

• WS-Addressing.• WS-ReliableMessaging. • WS-Policy framework: WS-Policy Attachment,

WS-PolicyAssertions. • WS-MetadataExchange.• WS-Security. • WS-Notification: WS-BaseNotification, WS-

Topics, WS-BrokeredNotification. • WS-Eventing.

4

WS-Addressing

• Underlying reasons:– No standard way in SOAP to specify where a

message is going, how to return a response, or where to report an error up to the transport layer.

– Addressing at the transport level is a limiting factor in the development of others.

– Need standard ways to route a message over multiple transports or direct a response to another third party.

5

WS-Addressing (2)

• Provides a uniform addressing method for SOAP messages traveling over synchronous and/or asynchronous transports.

• Provides addressing features to help web service developers build variety of messaging patterns beyond the typical exchange of requests and responses.

• Addressing a SOAP message:– Where it’s coming from.– The address of where it is supposed to go.– The specific entity at the address who is supposed to receive it.– Where it should go if it cannot be delivered as planned.

6

WS-Addressing (3)

• Consists of:– Endpoint Reference

extension used to provide identifiers that pinpoint an instance of a service.

– Message Information/message addressingthe SOAP headers that establish message exchange-related characteristics within the messages themselves.

7

WS-Addressing (4)

• Endpoint Reference contains:– address: The URL of the Web service.– reference properties: property values associated with

the Web service instance.– reference parameters: parameter values to further

interact with a specific service instance.– service port type and port type: giving the recipient of

the message the exact location of service required for a reply.

– policy: A WS-Policy compliant policy that provides rules and behavior information relevant to the current service interaction.

8

WS-Addressing (5)

• Message Information contains:– destination: address to which the message is being sent.– source endpoint: endpoint reference to the Web service that

generated the message.– reply endpoint: which address its reply should be sent.– fault endpoint: set the address to which a fault notification should

be sent.– message id: uniquely identifies the message or the retransmission

of the message.– relationship: the message id of the related message to which a

message is replying.– action: A URI value that indicates the message’s overall purpose

(= SOAP HTTP action value).

9

WS-Addressing (6)

Example Endpoint Reference:<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2004/12/addressing" xmlns:example=“http://example.co.id"> <wsa:Address>http://example.co.id/weather</wsa:Address> <wsa:ReferenceProperties> <example:ServiceLevel>Basic</example:ServiceLevel> </wsa:ReferenceProperties> <wsa:ReferenceParameters> <example:CityCode>NYC</example:CityCode> </wsa:ReferenceParameters></wsa:EndpointReference>

10

WS-Addressing (7)

Example Message Information:<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>  </S:Body></S:Envelope>

11

WS-RM (Revisited)

• Underlying reasons:No standard ways to know– whether the message successfully arrived at

its intended destination.– whether the message failed to arrive therefore

requires retransmission.– whether a series of messages arrived in the

sequence they were intended to.

12

WS-RM (2)

• Establishes a measure of quality assurance of message deliveries.

• Guaranteeing:– service providers will be notified of the success

or failure of message transmissions.– messages sent with specific sequence rules

will arrive as intended.

13

WS-RM (3)

• Consists of:– sequence: establishes the order in which messages should be

delivered.– message number: identifies the position of the message within the

sequence. – last message: identifies final message in a sequence.– sequenceAcknowledgement: notifies that the delivery of message was

successful.– acknowledgementRange: indicate range of messages that were

received.– nack: negative acknowledgement, identifies that a specific message

was not received.– ackRequested: ask the recipient to send sequenceAcknowledgement

on demand.

14

WS-RM (4)

Sample message from sender:<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>  </wsu:Identifier> <wsrm:MessageNumber>  </wsrm:MessageNumber> <wsrm:LastMessage/>  </wsrm:Sequence> </Header> <Body> . . . </Body></Envelope>

15

WS-RM (5)

Sample message from recipient:<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>  </wsu:Identifier> <wsrm:AcknowledgementRange Upper=“5” Lower=“1” />  </wsrm:SequenceAcknowledgement> </Header> <Body> . . . </Body></Envelope>

16

WS-RM (6)

Sample message from sender:<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:AckRequested>



<wsu:Identifier>



</wsrm:AckRequested>

</Header>

<Body>

. . .

</Body>

</Envelope>

17

WS-RM (7)

Sample message from recipient:<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>  </wsu:Identifier> <wsrm:Nack> 6  </wsrm:Nack> </wsrm:SequenceAcknowledgement> </Header> <Body> . . . </Body></Envelope>

18

WS-Policy (revisited)

• Underlying reasons:– How to identify restrictions of message delivery

• actual business-level requirements.• the nature of the data being exchanged.• organizational security measures.

– How to identify a service unique characteristics that may be of interest to other services

• behavioral characteristics.• preferences.• technical limitations.• quality of service (QoS).

19

WS-Policy (2)

• Establishes extensions that control the assembly and structure of message policy description.

• Provides a means of attaching properties (such as rules, behaviors, requirements, and preferences) to Web services.

• WS-Policy framework also forms part of the WS-Security framework (WS-SecurityPolicy specification defines a set of policy assertions intended for use with WS-Security).

20

WS-Policy (3)

• Consists of:– WS-Policy.– WS-PolicyAttachments.– WS-PolicyAssertions.

• Policies can be applied into:– Context coordination WS-Coordination.– Orchestration and choreography WS-

Choreography.– Message delivery WS-ReliableMessaging.

21

WS-Policy (4)

• Elements and common assertions:– Policy: the root construct– TextEncoding: dictates the use of a specific text

encoding format.– Language: preference for a particular language.– SpecVersion: need for a specific version of a

specification.– MessagePredicate: indicates processing rules

using XPath statements.

22

WS-Policy (5)

• Elements and common assertions (cont’d):– ExactlyOne: in case of multiple policy assertions, to

indicate that at least one must be chosen.– All: states that all the policies must be met.– Usage: indicate whether a given policy assertion is

required, optional, rejected, ignored, or observed.– Preference: to rank assertions in order of preference.– PolicyReference and PolicyURIs and PolicyAttachment: to link an element with one or more policies.

23

WS-Policy (6)

Example:<wsp:Policy> xmlns:wsp=“http://schemas.xmlsoap.org/ws/2002/12/policy”> <wsp:ExactlyOne>  <wsp:All ID=“Invoice1”> <!-- indicate that all policies must be met --

> <wsp:SpecVersion wsp:Usage=“wsp:Required” wsp:Preference=“10” wsp:URI=“http://schemas.xmlsoap.org/ws/2004/03/rm” /> <wsp:TextEncoding wsp:Usage=“wsp:Required” Encoding=“iso-8859-5” /> </wsp:All> <wsp:All ID=“Invoice2”> <wsp:SpecVersion wsp:Usage=“wsp:Required” wsp:Preference=“1” wsp:URI=“http://schemas.xmlsoap.org/ws/2003/02/rm” /> <wsp:TextEncoding wsp:Usage=“wsp:Required” Encoding=“iso-8859-5” /> </wsp:All> </wsp:ExactlyOne>. . .

24

WS-Policy (7)

Example continues … <Employee wsp:PolicyURI=

“http://www.mycompany.com/tls/policy1.xml#Employee1”

“http://www.mycompany.com/tls/policy2.xml#Employee2”>



<wsp:PolicyReference URI=

“http://www.mycompany.com/tls/EmployeeRule1.xml#Employee1” />


“http://www.mycompany.com/tls/EmployeeRule1.xml#Employee2” />



</Employee>

. . .

25

WS-Policy (8)

Example continues … <wsp:PolicyAttachment>



<wsp:AppliesTo>

<wsa:EndpointReference

xmlns:emp=“http://www.mycompany.com/tls/Employee”>

<wsa:Address> “http://www.mycompany.com/Emp1” </wsa:Address>

<wsa:PortType> emp:EmployeeInterface </wsa:PortType>

<wsa:ServiceName> emp:Employee </wsa:ServiceName>

</wsa:EndpointReference>

</wsp:AppliesTo>


“http://www.mycompany.com/EmployeePolicy.xml” />

</wsp:PolicyAttachment>

</wsp:Policy>

26

WS-MetadataExchange

• Underlying reasons:Inefficient ways to request metadata provides by a service such as:– manually locating it by searching for published

documents then programmatically retrieving it via a public service registry.

– manually requesting it by contacting the service provider then programmatically retrieving it by interacting with proprietary interfaces made available by the service provider entity.

27

WS-MetadataExchange (2)

• Allows service requestor to issue a standardized request message that asks for some or all of the meta information relating to a specific endpoint address.

• Type of request message:– Get Metadata = Get WSDL + Get Schema +

Get Policy

28


Fig 1. Request and Response of WS-MetadataExchange

29


• Order of activities:– Requestor sends GetMetadata request

message.– Provider returns GetMetadata response

message that contains the essential piece of service meta information.

– Requestor then request selective retrieval of metadata to obtain which metadata it further requires (save bandwidth & time).

30


<s:Envelope xmlns:s12=”http://www.w3.org/2003/05/soap-envelope” xmlns:wsa=”http://schemas.xmlsoap.org/ws/2004/08/addressing” xmlns:wsx=”http://schemas.xmlsoap.org/ws/2004/09/mex”> <s:Header> <wsa:Action>  http://schemas.xmlsoap.org/ws/2004/09/mex/GetMetadata/Request </wsa:Action> <wsa:MessageID> uuid:73d7edfc-5c3c-49b9-ba46-2480caee43e9 </wsa:MessageID> <wsa:ReplyTo> <wsa:Address>http://example.com/MyEndpoint</wsa:Address> </wsa:ReplyTo> <wsa:To>http://server.example.org/YourEndpoint</wsa:To> <ex:MyRefProp xmlns:ex='http://server.example.org/refs' > 78f2dc229597b529b81c4bef76453c96 </ex:MyRefProp> </s:Header> <s:Body> <wsx:GetMetadata> <wsx:Dialect> http://schemas.xmlsoap.org/ws/2004/09/policy </wsx:Dialect> </wsx:GetMetadata> </s:Body></s:Envelope>

Sample Get Metadata request message:

31

WS-MetadataExchange (6)Sample Get Metadata response message:<s:Envelope xmlns:s12=”http://www.w3.org/2003/05/soap-envelope” xmlns:wsa=”http://schemas.xmlsoap.org/ws/2004/08/addressing” xmlns:wsp=”http://schemas.xmlsoap.org/ws/2004/09/policy” xmlns:wsx=”http://schemas.xmlsoap.org/ws/2004/09/mex” > <s:Header> <wsa:Action> http://schemas.xmlsoap.org/ws/2004/09/mex/GetMetadata/Response </wsa:Action> <wsa:RelatesTo>uuid:73d7edfc-5c3c-49b9-ba46-2480caee43e9</wsa:RelatesTo> <wsa:To>http://client.example.com/MyEndpoint</wsa:To> </s:Header> <s:Body> <wsx:Metadata> <wsx:MetadataSection Dialect=”http://schemas.xmlsoap.org/ws/2004/09/policy”> <wsp:Policy xmlns:wsse=”http://schemas.xmlsoap.org/ws/2002/12/secext”> <wsp:ExactlyOne> <wsse:SecurityToken> <wsse:TokenType>wsse:X509v3</wsse:TokenType> </wsse:SecurityToken> </wsp:ExactlyOne> </wsp:Policy> </wsx:MetadataSection> </wsx:Metadata> </s:Body></s:Envelope>

32

WS-ME & Service Discovery

• Service registries (even provide location information for the actual WSDL), can be used in conjunction with metadata exchange messages.

• Possible scenario:– Requestor could first query a public registry to retrieve

the endpoint addresses of any Web service candidates that meet certain search criteria.

– Requestor then use metadata exchange to contact each candidate to their endpoint addresses.

• Give the service requestor more information to better assess which service provider it should be working with.

• Provide the service requestor with all of the details it needs to begin interacting with the chosen service.

33

WS-Security (Revisited)

• Underlying reasons:– SOA also need the traditional security

demands of protecting information and ensuring access is only granted to those permitted.

– SOAP messaging communications framework, emphasizes aspects of security that need a security framework designed specifically for Web services.

34

WS-Security (2)

• WS-Security• WS-SecurityPolicy• WS-Trust• WS-SecureConversation • WS-Federation• Extensible Access Control

Markup Language (XACML)

• Extensible Rights Markup Language (XrML)

• XML Key Management (XKMS)

• XML-Signature• XML-Encryption• Security Assertion Markup

Language (SAML)• .NET Passport• Secure Sockets Layer

(SSL)• WS-I Basic Security

Profile

Some security specifications for Web Services:

35

WS-Security (3)

• Core specifications for security:– WS-Security.– XML-Signature.– XML-Encryption.

Please refer to class 4.2 slides and read: Building Web Services with Java : Making Sense of XML, SOAP, WSDL, and UDDI (2nd Edition) by Steve Graham, et al. Chapter 9, page 474 to 495.

36

WS-Notification & WS-Eventing

• Underlying reasons:– Necessities to know the availability of an item

of interest in a complex MEP.– An item of interest is often tied to the

occurrence of an event.– When an item of interest becomes available,

the publisher broadcasts it to all consumers that have subscribed to that topic.

37

WS-Notification (revisited)

• Three specifications for WS-Notification:– WS-Topics– WS-BaseNotifications.– WS-BrokeredNotifications.

Please refer to class 5 slides for more complete information.

38

WS-Eventing

• Addresses publish-and-subscribe requirements by focusing on an event-oriented messaging model.

• When an event related to one service occurs, any other services that have expressed interest in the event are subsequently notified.

• A subscription may be leased to a subscriber, and it may expires over time.

• Subscription manager allows subscribers to renew or cancel the subscription before it expires.

39

WS-Eventing (2)Sample subscription message:<s:Envelope xmlns:s12=”http://www.w3.org/2003/05/soap-envelope” xmlns:wsa=”http://schemas.xmlsoap.org/ws/2004/08/addressing” xmlns:wse=”http://schemas.xmlsoap.org/ws/2004/08/eventing” xmlns:ew=”http://www.example.com/warnings” > <s:Header> <wsa:Action>  http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe </wsa:Action> <wsa:MessageID>  uuid:e1886c5c-5e86-48d1-8c77-fc1c28d47180 </wsa:MessageID> <wsa:ReplyTo>  <wsa:Address>http://www.example.com/MyEvEntsink</wsa:Address> <wsa:ReferenceProperties> <ew:MySubscription>2597</ew:MySubscription> </wsa:ReferenceProperties> </wsa:ReplyTo> <wsa:To>http://www.example.org/oceanwatch/EventSource</wsa:To> </s:Header>

40

WS-Eventing (3)Sample subscription message continues . . . <s:Body> <wse:Subscribe> <wse:EndTo>  <wsa:Address>http://www.example.com/MyEventSink</wsa:Address> <wsa:ReferenceProperties> <ew:MySubscription>2597</ew:MySubscription> </wsa:ReferenceProperties> </wse:EndTo> <wse:Delivery>  <wse:NotifyTo> <wsa:Address> http://www.other.example.com/OnStormWarning </wsa:Address> <wsa:ReferenceProperties> <ew:MySubscription>2597</ew:MySubscription> </wsa:ReferenceProperties> </wse:NotifyTo> </wse:Delivery>  <wse:Expires>2004-06-26T21:07:00.000-08:00</wse:Expires> <wse:Filter xmlns:ow=“http://www.example.org/oceanwatch” Dialect=“http://www.example.org/topicFilter” > weather.storms  </wse:Filter> </wse:Subscribe> </s:Body></s:Envelope>

41

WS-Eventing (4)Sample response to subscription message request

<s:Envelope xmlns:s12=“http://www.w3.org/2003/05/soap-envelope” xmlns:wsa=“http://schemas.xmlsoap.org/ws/2004/08/addressing” xmlns:wse=“http://schemas.xmlsoap.org/ws/2004/08/eventing” xmlns:ew=“http://www.example.com/warnings” xmlns:ow=“http://www.example.org/oceanwatch” > <s:Header> <wsa:Action>  http://schemas.xmlsoap.org/ws/2004/08/eventing/SubscribeResponse </wsa:Action> <wsa:RelatesTo>  uuid:e1886c5c-5e86-48d1-8c77-fc1c28d47180 </wsa:RelatesTo>  <wsa:To>http://www.example.com/MyEventSink</wsa:To> <ew:MySubscription>2597</ew:MySubscription> </s:Header>

. . .

42

WS-Eventing (5)

. . . <s:Body> <wse:SubscribeResponse> <wse:SubscriptionManager>  <wsa:Address> http://www.example.org/oceanwatch/SubscriptionManager </wsa:Address> <wsa:ReferenceParameters> <wse:Identifier>  uuid:22e8a584-0d18-4228-b2a8-3716fa2097fa </wse:Identifier> </wsa:ReferenceParameters> </wse:SubscriptionManager>  <wse:Expires>2004-07-01T00:00:00.000-00:00</wse:Expires> </wse:SubscribeResponse> </s:Body></s:Envelope>

Sample response to subscription message request continues …

Thank You

Doddy [email protected]

[email protected]

advanced messaging

Documents

related message

message id

message informationmessage

message deliveries

example message information

wspolicy attachment

wspolicy framework

wspolicy compliant policy