ietf trade working group january 2000 xml messaging overview january 2000

IETF Trade Working Group

January 2000

XML Messaging Overview

January 2000


January 2000

Topics

• Objective

• History

• Scope

• Wrapping Documents

• Exchanging Documents

• Reliable Messaging

• Security and Authentication


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


January 2000

History


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 !


January 2000

Decided to split IOTP into two specs



XML MessagingSpecification



Domain Specific

Current Status: Informational RFC, pilot implementations in Japan, Germany and Canada

80% of ideas from

IOTP


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


January 2000

Wrapping Documents


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


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


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.


January 2000

Exchanging Documents


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


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


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



January 2000

Synchronous, Asynchronous Document Exchanges and

One-Way Messages


January 2000

Synchronous Document Exchange

RequestMessage


ResponseMessage


e.g. Purchase Order


In a Synchronous Document Exchange, the Response Message is generated immediately over the same transport session.


January 2000

RequestMessage


ResponseMessage


Check the Request Message is OK

... some time later ...

e.g. Purchase Order


In an Asynchronous Document Exchange, the Response Message is generated some time later over a separate connection.

Asynchronous Document Exchange


January 2000

RequestMessage


ResponseMessage


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


Message Ack.

Check the Message Ack.

Message Ack.

Check the Message Ack.

* If the Transport Protocol supports open sessions

Asynchronous Document Exchangewith Message Acknowledgement


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


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


January 2000

Multi-hop Messages


January 2000

Intermediary

Synchronous Multi-hop Document Exchange

Buyer

Request Messagee.g. Purchase Order


Supplier


IntermediaryBuyer

Response Messagee.g. PO Ack


Supplier

1 2

34


January 2000

Asynchronous Multi-hop Document Exchange

IntermediaryBuyer



Supplier

IntermediaryBuyer



Supplier

1 3

57

Message Ack. Message Ack.

Message Ack. Message Ack.

2 4

68



January 2000

IntermediaryBuyer



Supplier

IntermediaryBuyer



Supplier

1 3

45

Message Ack.

Message Ack.

2

6


SynchronousAsynchronous

Mixed Asynchronous/Synchronous Multi-hop Document Exchange


January 2000

Mixed Transport Protocol Multi-hop Document Exchange

IntermediaryBuyer



Supplier

IntermediaryBuyer



Supplier

1 3

45

Message Ack.

Message Ack.

2

6


SMTPHTTP


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


January 2000

Reliable Messaging


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


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.


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


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


January 2000

Security and Authentication


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


January 2000

Current Status


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


January 2000

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

ietf trade working group january 2000 xml messaging overview january 2000

Documents

ietf trade working group

xml documents

electronic documents

message identity data

wrapping documents

iotp slide

actual documents

documents ways