Date post: | 13-Dec-2015 |
Category: |
Documents |
Upload: | christian-coram |
View: | 215 times |
Download: | 1 times |
IETF Trade Working Group
January 2000
XML Messaging Overview
January 2000
IETF Trade Working Group
January 2000
Topics
• Objective
• History
• Scope
• Wrapping Documents
• Exchanging Documents
• Reliable Messaging
• Security and Authentication
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
IETF Trade Working Group
January 2000
History
IETF Trade Working Group
January 2000
History - started with IOTPContents:
How to do purchasesoffers, 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)
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 !
IETF Trade Working Group
January 2000
Decided to split IOTP into two specs
Internet Open Trading Protocol
Specification(version 1.0)
XML MessagingSpecification
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
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
IETF Trade Working Group
January 2000
Wrapping Documents
IETF Trade Working Group
January 2000
Envelope
How to wrap documents
MessageHeader
MessageRouting Info
DigitalSignature(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
IETF Trade Working Group
January 2000
<?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
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
IETF Trade Working Group
January 2000
Message Routing Info<?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>
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.
IETF Trade Working Group
January 2000
Exchanging Documents
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
IETF Trade Working Group
January 2000
Basic Document Exchange
RequestMessage
Process the Request Message and Generate a Response Message
ResponseMessage
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
IETF Trade Working Group
January 2000
Document Exchange with use of persistent store
RequestMessage
Save the Request Message in persistent
store. Process the Request Message, generate a
Response Message and save in Persistent store
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
Generate the Request Message and save it in
persistent store
PersistentStore
PersistentStore
RequestMessage
RequestMessage
ResponseMessage
ResponseMessage
RequestMessage
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
IETF Trade Working Group
January 2000
Synchronous, Asynchronous Document Exchanges and
One-Way Messages
IETF Trade Working Group
January 2000
Synchronous Document Exchange
RequestMessage
Process the Request Message and Generate a Response Message
ResponseMessage
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.
IETF Trade Working Group
January 2000
RequestMessage
Process the Request Message and Generate a Response Message
ResponseMessage
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
IETF Trade Working Group
January 2000
RequestMessage
Process the Request Message and Generate a Response Message
ResponseMessage
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 Exchangewith Message Acknowledgement
IETF Trade Working Group
January 2000
One-way Message
One-wayMessage
The one-way message is processed but no
business document is generated in responsee.g. Request For Proposal
One-way Messages do not expect a reply ...but may be acknowledged
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
IETF Trade Working Group
January 2000
Multi-hop Messages
IETF Trade Working Group
January 2000
Intermediary
Synchronous Multi-hop Document Exchange
Buyer
Request Messagee.g. Purchase Order
Request Messagee.g. Purchase Order
Supplier
Process the Request Message and Generate a Response Message
IntermediaryBuyer
Response Messagee.g. PO Ack
Response Messagee.g. PO Ack
Supplier
1 2
34
IETF Trade Working Group
January 2000
Asynchronous Multi-hop Document Exchange
IntermediaryBuyer
Request Messagee.g. Purchase Order
Request Messagee.g. Purchase Order
Supplier
IntermediaryBuyer
Response Messagee.g. PO Ack
Response Messagee.g. PO Ack
Supplier
1 3
57
Message Ack. Message Ack.
Message Ack. Message Ack.
2 4
68
Process the Request Message and Generate a Response Message
IETF Trade Working Group
January 2000
IntermediaryBuyer
Request Messagee.g. Purchase Order
Request Messagee.g. Purchase Order
Supplier
IntermediaryBuyer
Response Messagee.g. PO Ack
Response Messagee.g. PO Ack
Supplier
1 3
45
Message Ack.
Message Ack.
2
6
Process the Request Message and Generate a Response Message
SynchronousAsynchronous
Mixed Asynchronous/Synchronous Multi-hop Document Exchange
IETF Trade Working Group
January 2000
Mixed Transport Protocol Multi-hop Document Exchange
IntermediaryBuyer
Request Messagee.g. Purchase Order
Request Messagee.g. Purchase Order
Supplier
IntermediaryBuyer
Response Messagee.g. PO Ack
Response Messagee.g. PO Ack
Supplier
1 3
45
Message Ack.
Message Ack.
2
6
Process the Request Message and Generate a Response Message
SMTPHTTP
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
IETF Trade Working Group
January 2000
Reliable Messaging
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
IETF Trade Working Group
January 2000
Failed Message Delivery Behavior(i.e. no response received in time)
1) Do a Transaction Status Inquiry2) 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.
IETF Trade Working Group
January 2000
Transaction Status Inquiry
Recovering from Delivery FailureExchangeMessage
Process the Large Document Part Message and Generate Response
Large Document Part
ExchangeMessage
Large Document Part Ack RequestMessage
Check to see if anything known about the transaction
and respond accordingly
ResponseMessage
Examine the response and work out what to do
Transaction StatusInquiry Request
TIMEOUT !!!
Transaction StatusInquiry Response
ExchangeMessage
Resend
IETF Trade Working Group
January 2000
Reliable “Once Only” Message Delivery
TransmitterHTTPClient
Internet
HTTPServer
Firewall
Listener
Failed Message Delivery Behavior
IdempotencyBehavior
Potential pointsof failure
“Failed Message Delivery Behavior” at the “Transmitter” combined with “Idempotency
Behavior” at the listener provides Reliable Once Only
delivery of the message
BusinessApplication
BusinessApplication
PersistentStore
PersistentStore
IETF Trade Working Group
January 2000
Security and Authentication
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
IETF Trade Working Group
January 2000
Current Status
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
IETF Trade Working Group
January 2000
Summary• Objective• History• Scope• Wrapping Documents• Exchanging Documents• Reliable Messaging• Security and Authentication• Current Status