Presentation is loading. Please wait.

Presentation is loading. Please wait.

IETF Trade Working Group January 2000 XML Messaging Overview January 2000.

Similar presentations


Presentation on theme: "IETF Trade Working Group January 2000 XML Messaging Overview January 2000."— Presentation transcript:

1 IETF Trade Working Group January 2000 XML Messaging Overview January 2000

2 IETF Trade Working Group January 2000 Topics Objective History Scope Wrapping Documents Exchanging Documents Reliable Messaging Security and Authentication

3 IETF Trade Working Group January 2000 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 IETF Trade Working Group January 2000 History

5 IETF Trade Working Group January 2000 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... Internet Open Trading Protocol Specification (version 1.0) Domain Specific 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 IETF Trade Working Group January 2000 Decided to split IOTP into two specs Internet Open Trading Protocol Specification (version 1.0) XML Messaging Specification Internet Open Trading Protocol Specification (version 2.0) Domain Specific  Current Status: Informational RFC, pilot implementations in Japan, Germany and Canada 80% of ideas from IOTP

7 IETF Trade Working Group January 2000 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 IETF Trade Working Group January 2000 Wrapping Documents

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

10 IETF Trade Working Group January 2000 (MessageType) (TransactionIdentityData) (MessageIdentityData) (To) (From) (AuthorizationData) (ServiceType & Intent) (MessageManifest) (Related Transaction) Message Header Message Header is root element has document URN to identify it 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 Message Manifest identifies the other documents in the 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 Message Type, e.g. Request, Response, etc Authorization Data identifies who authorizes message to be processed Service Type & Intent identifies the that is being invoked and reason for sending the message Related Transaction identifies other transaction to which this one is related

11 IETF Trade Working Group January 2000 Message Routing Info (To) (From) (MessageSend) (MessageReSend) (MessageReceipt) (MessageForward) (MessageReceipt) Message Routing Info is root element has document URN to identify it 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 IETF Trade Working Group January 2000 Exchanging Documents

13 IETF Trade Working Group January 2000 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 IETF Trade Working Group January 2000 Basic Document Exchange Request Message Process the Request Message and Generate a Response Message Response Message Process the Response Message e.g. Purchase Order e.g. Purchase Order Acknowledgement Each Request Message or Response Message follows the structure of a Message described earlier

15 IETF Trade Working Group January 2000 Document Exchange with use of persistent store Request Message Save the Request Message in persistent store. Process the Request Message, generate a Response Message and save in Persistent store Response Message 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 Generate the Request Message and save it in persistent store Persistent Store Request Message Response Message Request Message Note. The rest of the diagrams won’t include use of persistent store, but usage is always assumed... e.g. Purchase Order e.g. Purchase Order Acknowledgement

16 IETF Trade Working Group January 2000 Synchronous, Asynchronous Document Exchanges and One-Way Messages

17 IETF Trade Working Group January 2000 Synchronous Document Exchange Request Message Process the Request Message and Generate a Response Message Response Message Process the Response Message e.g. Purchase Order e.g. Purchase Order Acknowledgement In a Synchronous Document Exchange, the Response Message is generated immediately over the same transport session.

18 IETF Trade Working Group January 2000 Request Message Process the Request Message and Generate a Response Message Response Message Process the Response Message Check the Request Message is OK... some time later... e.g. Purchase Order e.g. Purchase Order Acknowledgement In an Asynchronous Document Exchange, the Response Message is generated some time later over a separate connection. Asynchronous Document Exchange

19 IETF Trade Working Group January 2000 Request Message Process the Request Message and Generate a Response Message Response Message Process the Response Message Generate and send a Message Ack.... some time later... 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. e.g. Purchase Order e.g. Purchase Order Acknowledgement Message Ack. Check the Message Ack. Message Ack. Check the Message Ack. * If the Transport Protocol supports open sessions Asynchronous Document Exchange with Message Acknowledgement

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

21 IETF Trade Working Group January 2000 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 IETF Trade Working Group January 2000 Multi-hop Messages

23 IETF Trade Working Group January 2000 Intermediary Synchronous Multi-hop Document Exchange Buyer Request Message e.g. Purchase Order Supplier Process the Request Message and Generate a Response Message IntermediaryBuyer Response Message e.g. PO Ack Supplier 12 34

24 IETF Trade Working Group January 2000 Asynchronous Multi-hop Document Exchange IntermediaryBuyer Request Message e.g. Purchase Order Supplier IntermediaryBuyer Response Message e.g. PO Ack Supplier Message Ack Process the Request Message and Generate a Response Message

25 IETF Trade Working Group January 2000 IntermediaryBuyer Request Message e.g. Purchase Order Supplier IntermediaryBuyer Response Message e.g. PO Ack Supplier Message Ack. 2 6 Process the Request Message and Generate a Response Message Synchronous Asynchronous Mixed Asynchronous/Synchronous Multi-hop Document Exchange

26 IETF Trade Working Group January 2000 Mixed Transport Protocol Multi-hop Document Exchange IntermediaryBuyer Request Message e.g. Purchase Order Supplier IntermediaryBuyer Response Message e.g. PO Ack Supplier Message Ack. 2 6 Process the Request Message and Generate a Response Message SMTP HTTP

27 IETF Trade Working Group January 2000 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 IETF Trade Working Group January 2000 Reliable Messaging

29 IETF Trade Working Group January 2000 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 IETF Trade Working Group January 2000 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 IETF Trade Working Group January 2000 Transaction Status Inquiry Recovering from Delivery Failure Exchange Message Process the Large Document Part Message and Generate Response Large Document Part Exchange Message Large Document Part Ack  Request Message Check to see if anything known about the transaction and respond accordingly Response Message Examine the response and work out what to do Transaction Status Inquiry Request TIMEOUT !!! Transaction Status Inquiry Response Exchange Message Resend

32 IETF Trade Working Group January 2000 Reliable “Once Only” Message Delivery Transmitter HTTP Client Internet HTTP Server Firewall Listener Failed Message Delivery Behavior Idempotency Behavior Potential points of failure “Failed Message Delivery Behavior” at the “Transmitter” combined with “Idempotency Behavior” at the listener provides Reliable Once Only delivery of the message Business Application Persistent Store

33 IETF Trade Working Group January 2000 Security and Authentication

34 IETF Trade Working Group January 2000 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 IETF Trade Working Group January 2000 Current Status

36 IETF Trade Working Group January 2000 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 IETF Trade Working Group January 2000 Summary Objective History Scope Wrapping Documents Exchanging Documents Reliable Messaging Security and Authentication Current Status


Download ppt "IETF Trade Working Group January 2000 XML Messaging Overview January 2000."

Similar presentations


Ads by Google