1 / 43

Advanced Messaging

Advanced Messaging. CS409 Application Services. Even Semester 2007. Advanced Messaging. 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.

brasen
Download Presentation

Advanced Messaging

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Advanced Messaging CS409 Application Services Even Semester 2007

  2. Advanced Messaging • 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.

  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 Referenceextension 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> <!-- The message body of the SOAP request appears here --> </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> <!-- contain an ID value associated with the sequence of message --> </wsu:Identifier> <wsrm:MessageNumber> <!-- contain the position number of message within overall sequence order --> </wsrm:MessageNumber> <wsrm:LastMessage/> <!-- To identify if this is the last message --> </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> <!-- typically being sent upon receipt of LastMessage except requested on demand --> <wsu:Identifier> <!-- contain an ID value associated with the sequence of message --> </wsu:Identifier> <wsrm:AcknowledgementRange Upper=“5” Lower=“1” /> <!-- means that messageNumber 1 to 5 were received successfully --> </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> <!-- used to request an on-demand acknowledgement even prior to the arrival of the last message --> <wsu:Identifier> <!-- contain an ID value associated with the sequence of message --> </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> <!-- typically being sent upon receipt of LastMessage except requested on demand --> <wsu:Identifier> <!-- contain an ID value associated with the sequence of message --> </wsu:Identifier> <wsrm:Nack> 6 <!-- Nack=negative acknowledgement means that messageNumber 6 was not received successfully --> </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> <!-- indicate at least one policy must be chosen --> <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”> <!-- To reference employee policy definitions --> <wsp:PolicyReference URI= “http://www.mycompany.com/tls/EmployeeRule1.xml#Employee1” /> <wsp:PolicyReference URI= “http://www.mycompany.com/tls/EmployeeRule1.xml#Employee2” /> <!-- To place policies relating to Employee services --> </Employee> . . .

  25. WS-Policy (8) Example continues … <wsp:PolicyAttachment> <!-- Attach policy assertion to a specific endpoint reference of WS-A --> <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> <wsp:PolicyReference URI= “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. WS-MetadataExchange (3) Fig 1. Request and Response of WS-MetadataExchange

  29. WS-MetadataExchange (4) • 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. WS-MetadataExchange (5) Sample Get Metadata request message: <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> <!-- Request combined with WS-Addressing --> 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>

  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 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 WS-Security (2) 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> <!-- Indicator of a subscription request message --> http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe </wsa:Action> <wsa:MessageID> <!-- Unique request message ID --> uuid:e1886c5c-5e86-48d1-8c77-fc1c28d47180 </wsa:MessageID> <wsa:ReplyTo> <!-- Where to send reply to this request --> <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> <!-- Where to send the subscription end message if needed --> <wsa:Address>http://www.example.com/MyEventSink</wsa:Address> <wsa:ReferenceProperties> <ew:MySubscription>2597</ew:MySubscription> </wsa:ReferenceProperties> </wse:EndTo> <wse:Delivery> <!-- How and where to send the notifications --> <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> <!-- When the subscription would like to expired --> <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 <!-- Topic of interest is only about storm --> </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> <!-- Indicator of response for a subscription request message --> http://schemas.xmlsoap.org/ws/2004/08/eventing/SubscribeResponse </wsa:Action> <wsa:RelatesTo> <!-- message ID that was requesting subscription --> uuid:e1886c5c-5e86-48d1-8c77-fc1c28d47180 </wsa:RelatesTo> <!-- The response is sent to address specified by the requested message --> <wsa:To>http://www.example.com/MyEventSink</wsa:To> <ew:MySubscription>2597</ew:MySubscription> </s:Header> . . .

  42. WS-Eventing (5) Sample response to subscription message request continues … . . . <s:Body> <wse:SubscribeResponse> <wse:SubscriptionManager> <!-- Indicates the attributes of the subscription manager --> <wsa:Address> http://www.example.org/oceanwatch/SubscriptionManager </wsa:Address> <wsa:ReferenceParameters> <wse:Identifier> <!-- Global identifier --> uuid:22e8a584-0d18-4228-b2a8-3716fa2097fa </wse:Identifier> </wsa:ReferenceParameters> </wse:SubscriptionManager> <!-- The actual expiration date of the subscription --> <wse:Expires>2004-07-01T00:00:00.000-00:00</wse:Expires> </wse:SubscribeResponse> </s:Body> </s:Envelope>

  43. Thank You Doddy Lukito dlukito@infinitechnology.com dlukito@alumni.carnegiemellon.edu

More Related