1 / 37

XML Messaging Overview

XML Messaging Overview. January 2000. Topics. Objective History Scope Wrapping Documents Exchanging Documents Reliable Messaging Security and Authentication. Objective.

maja
Download Presentation

XML Messaging Overview

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. XML Messaging Overview January 2000

  2. Topics • Objective • History • Scope • Wrapping Documents • Exchanging Documents • Reliable Messaging • Security and Authentication

  3. Objective “XML Messaging provides a generic approach to the reliable, resilient, secure, tamper resistant, authenticated exchange of XML or other electronic documents over insecure, unreliable transport mechanisms” Under development by the IETF TRADE Working Group

  4. History

  5. Internet Open Trading Protocol Specification (version 1.0) History - started with IOTP • Contents: • How to do purchases • offers, brand selection, payments, delivery ... • How to exchange messages: • How to use Digital Signatures • Reliable and resilient message transfer • How to report errors • How to do audit trails • ... DomainSpecific Generic Members of IETF Trade Working Group thought that there were many good ideas in the way IOTP handled messages that would be generally applicable ... but everything in a single document made it hard to use !

  6. Internet Open Trading Protocol Specification (version 1.0) XML MessagingSpecification Internet Open Trading Protocol Specification (version 2.0)Domain Specific Decided to split IOTP into two specs 80% of ideas from IOTP  Current Status: Informational RFC, pilot implementations in Japan, Germany and Canada

  7. XML Messaging Scope • Protocol • How to wrap documents • Ways in which documents get exchanged • Reliable Messaging • Behavior of systems at each end for reliable once only delivery • Security and authentication • Types of exchanges supported • Synchronous & Asynchronous Response • One-way messaging • Message Acknowledgements

  8. Wrapping Documents

  9. How to wrap documents Envelope Contains the additional data needed so that documents can be sent to and successfully processed by a Party MessageHeader MessageRouting Info Contains information about the route taken by a message in order to get from its origin to its destination DigitalSignature(s) Optional, digitally signs the Message Header, and Message Routing Info, document(s) and/or data on the web. Built on forthcoming IETF/W3C standard Document The actual documents, e.g. a Purchase Order, may be XML Documents or some other electronic document

  10. Message Header <?xml version="1.0"?> <!DOCTYPE schema SYSTEM ”ietf.org/trade-wg ... .dtd"> <MessageHeader DocumentUrn="urn:C1GTW-138w93j" > (MessageType) (TransactionIdentityData) (MessageIdentityData) (To) (From) (AuthorizationData) (ServiceType & Intent) (MessageManifest) (Related Transaction) </MessageHeader> Message Header is root element has document URN to identify it Message Type, e.g. Request, Response, etc Transaction Identity Data identifies the set of related messages, e.g. PO and PO Ack. Message Identity Data contains data to uniquely identify and describe an individual message To identifies the source organization and optionally the service that created the Message.From identifies the destination organization, service and intent.All Id’s are logical rather than physical Authorization Data identifies who authorizes message to be processed Service Type & Intent identifies the that is being invoked and reason for sending the message Message Manifest identifies the other documents in the Message Related Transaction identifies other transaction to which this one is related

  11. Message Routing Info Message Routing Info is root element has document URN to identify it <?xml version="1.0"?> <!DOCTYPE schema SYSTEM ”ietf.org/trade-wg ... .dtd"> <MessageRoutingInfo DocumentUrn="urn:C1GTW-23409fdj23" > <CopiedMessageHeaderData MessageHeaderDocUrn= ... > (To) (From) </CopiedMessageHeaderData> <MessageRoutingEntries> (MessageSend) (MessageReSend) (MessageReceipt) (MessageForward) (MessageReceipt) </MessageRoutingEntries> </MessageRoutingInfo> Copied Message Header Data refers to Message Header and copies of To and From. Avoids need to open Message Header Message Send/Resend/Forward contains URL of where to send message to and where response should go.Message Receipt contains record of when/where received. New entries added to end for each “hop” or attempt at sending.Individual entries can be digitally signed.

  12. Exchanging Documents

  13. Exchanging Documents • Basic Document Exchange • Document Exchange with Persistent Store • Synchronous, Asynchronous Document Exchanges and One-Way Messages • Handling Errors • Canceling a Transaction • Exchange Messages • Sending Large Documents • Multi-hop Messages

  14. Basic Document Exchange Process the Request Message and Generate a Response Message RequestMessage e.g. Purchase Order ResponseMessage Process the Response Message e.g. Purchase Order Acknowledgement Each Request Message or Response Message follows the structure of a Message described earlier

  15. Document Exchange with use of persistent store Generate the Request Message and save it in persistent store RequestMessage Save the Request Message in persistent store. Process the Request Message, generate a Response Message and save in Persistent store PersistentStore RequestMessage RequestMessage PersistentStore RequestMessage ResponseMessage e.g. Purchase Order ResponseMessage Save the Response Message and then check the Response Message is OK against the Request Message in persistent store, if OK save the Response Message and process it ResponseMessage e.g. Purchase Order Acknowledgement Note. The rest of the diagrams won’t include use of persistent store, but usage is always assumed ...

  16. Synchronous, Asynchronous Document Exchanges and One-Way Messages

  17. Synchronous Document Exchange Process the Request Message and Generate a Response Message RequestMessage e.g. Purchase Order ResponseMessage Process the Response Message e.g. Purchase Order Acknowledgement In a Synchronous Document Exchange, the Response Message is generated immediately over the same transport session.

  18. Asynchronous Document Exchange RequestMessage Check the Request Message is OK e.g. Purchase Order Process the Request Message and Generate a Response Message ... some time later ... ResponseMessage Process the Response Message e.g. Purchase Order Acknowledgement In an Asynchronous Document Exchange, the Response Message is generated some time later over a separate connection.

  19. Asynchronous Document Exchangewith Message Acknowledgement RequestMessage Generate and send a Message Ack. e.g. Purchase Order Check the Message Ack. Message Ack. Process the Request Message and Generate a Response Message ... some time later ... ResponseMessage Process the Response Message e.g. Purchase Order Acknowledgement Message Ack. Check the Message Ack. In an Asynchronous Document Exchange with Message Acknowledgement the acknowledgement is generated immediately over the same transport session*. The Response Message is generated some time later over a separate connection. * If the Transport Protocol supports open sessions

  20. One-way Message The one-way message is processed but no business document is generated in response One-wayMessage e.g. Request For Proposal One-way Messages do not expect a reply ...but may be acknowledged

  21. Document Exchange Variations • Handling Errors • Define an error document to report on errors in XML and transient errors • Canceling a Transaction • Define how either party can cancel a started transaction, if allowed • Exchange Messages • Allow extended swapping of messages between request and final response

  22. Multi-hop Messages

  23. Synchronous Multi-hop Document Exchange 1 2 Buyer Request Messagee.g. Purchase Order Intermediary Request Messagee.g. Purchase Order Supplier Process the Request Message and Generate a Response Message 4 3 Buyer Response Messagee.g. PO Ack Intermediary Response Messagee.g. PO Ack Supplier

  24. Asynchronous Multi-hop Document Exchange 1 3 Buyer Request Messagee.g. Purchase Order Intermediary Request Messagee.g. Purchase Order Supplier Message Ack. Message Ack. 2 4 Process the Request Message and Generate a Response Message 7 5 Buyer Response Messagee.g. PO Ack Intermediary Response Messagee.g. PO Ack Supplier Message Ack. Message Ack. 8 6

  25. Mixed Asynchronous/Synchronous Multi-hop Document Exchange 1 3 Buyer Request Messagee.g. Purchase Order Intermediary Request Messagee.g. Purchase Order Supplier Message Ack. 2 Process the Request Message and Generate a Response Message 5 4 Buyer Response Messagee.g. PO Ack Intermediary Response Messagee.g. PO Ack Supplier Message Ack. 6 Synchronous Asynchronous

  26. Mixed Transport Protocol Multi-hop Document Exchange 1 3 Buyer Request Messagee.g. Purchase Order Intermediary Request Messagee.g. Purchase Order Supplier Message Ack. 2 Process the Request Message and Generate a Response Message SMTP HTTP 5 4 Buyer Response Messagee.g. PO Ack Intermediary Response Messagee.g. PO Ack Supplier Message Ack. 6

  27. Document Exchange Summary • Basic Document Exchange • Document Exchange with Persistent Store • Synchronous, Asynchronous Document Exchanges and One-Way Messages • Handling Errors • Canceling a Transaction • Exchange Messages • Multi-hop Messages

  28. Reliable Messaging

  29. Reliable Messaging • Reliable Messaging uses: • Standard Document Exchanges: • Transaction Status Inquiry • Service Availability Check • Quality Of Service Negotiation • ... and defined behavior for: • idempotency (handling of duplicate messages) • failed message delivery • ... to provide reliable robust “once-only” delivery of messages

  30. Failed Message Delivery Behavior(i.e. no response received in time) 1) Do a Transaction Status Inquiry 2) If "Not Known", then re-send the original 3) If "In Progress" or “Not Yet Started” then wait. If no response is received then repeat from step 1. 4) If any other response (e.g. "Completed Ok", "Failed", etc.) then re-send first Message - response should be resent. If no response then repeat from step 1. 5) If no response at all to Transaction Status Inquiry then carry out a Service Availability Transaction. 6) If the Service Availability Transaction does not work then in all probability the Service not working. So either: a) wait and try again, or, b) send using another transport protocol 7) If, after several re-tries, still doesn’t work notify creator of original message.

  31. Recovering from Delivery Failure ExchangeMessage Process the Large Document Part Message and Generate Response  Large Document Part ExchangeMessage TIMEOUT !!! Large Document Part Ack Transaction Status Inquiry Check to see if anything known about the transaction and respond accordingly RequestMessage Transaction StatusInquiry Request ResponseMessage Examine the response and work out what to do Transaction StatusInquiry Response Resend ExchangeMessage

  32. Reliable “Once Only” Message Delivery PersistentStore Failed Message Delivery Behavior BusinessApplication Transmitter HTTPClient Internet “Failed Message Delivery Behavior” at the “Transmitter” combined with “Idempotency Behavior” at the listener provides Reliable Once Only delivery of the message Firewall Potential pointsof failure PersistentStore HTTPServer BusinessApplication Listener IdempotencyBehavior

  33. Security and Authentication

  34. Security and Authentication • Three techniques (may be used in combination) • Secure channel (e.g SSL/TLS) • can authenticate sender with SSL certificates • Digitally sign documents to prove authenticity • Documents can then be sent over insecure channels • Using XML Document for the signature (vs MIME) means can pass through any number of servers without damage • Authenticate sender • use “standard” Authentication” Transaction to verify sender using “Challenge-Response” - means can verify individuals at site beyond SSL “gateway” • Encryption out of scope - assumed within XML Document

  35. Current Status

  36. Current Status • XML Messaging Requirements Specification submitted as Internet Draft to the IETF • Other parts of specification in progress • Common XML Message Elements • Document Exchange and Transactions • Reliable Messaging • Secure Messaging • Document Choreography Definitions • Common Document Exchanges • Transport Protocol Supplements

  37. Summary • Objective • History • Scope • Wrapping Documents • Exchanging Documents • Reliable Messaging • Security and Authentication • Current Status

More Related