DELIVERY MATRIX
Draft Version: 0.2
Date: October 22, 2000
Author: ebXML TR&P Group
PHASE ONE FUNCTIONAL REQUIREMENTS
USE CASES
The functional requirements
specified for phase 1 should be sufficient to support the following user
scenarios:
- A party wishing to send unacknowledged
messages to another party or set of parties (e.g. send a stock price
update every 15 minutes)
- A party offering a server with services
(e.g. RPC's) in which a "client" invokes a service on a server
and receives a response (e.g. a stock quote service where a party requests
a stock quote for a particular symbol)
- A party wishing to exchange data with
another party. Data is sent from originator to recipient, a transport
level positive acknowledgement is issued by the recipients messaging
service to the originator indicating a successful transfer.
- A party
wishing to exchange data with another party has agreed to encrypt the
payload. The PA specifies the agreements on the encryption keys and
algorithms. Data is encrypted by the originator and sent to the message
service handler. The message service handler creates the message header
and sends the message to the recipient. The receiving message handler
hands the message to the To recipient for decryption of the payload.
FUNCTIONAL REQUIREMENTS
Core Functionality
|
Functional
Requirement |
Reference |
Comments |
|
4.1.1) documents expressed in either XML or other digital format wrapped in message envelope... |
line 110 |
btdt (been there, done that, have the t-shirt to prove it;-) |
|
4.1.2) multiple document support |
line 112 |
btdt |
|
4.1.3 a) physical or logical address |
line 114-116 |
logical address support |
|
4.1.4) messages transported over variety of protocols (transport neutral) |
line 118 |
normative bindings for HTTPS SMTP & FTP initially, others later (possibly) |
|
4.1.5) messages with globally unique id |
line 120 |
this has been discussed and I believe all are on-board. |
|
4.1.6) reference to previous message |
line 121 |
btdt |
|
4.1.7) message timestamp |
line 122 |
btdt |
|
4.1.13) message manifest |
line 132 |
btdt |
|
4.3.2 serial or parallel delivery |
line 166 |
|
|
4.7 motherhood and apple pie |
line 234 |
platform independence is a given |
|
|
|
|
Reliability
note: references are to ebXML TRP Requirements document v0-96
note: Reliable Messaging Features are added to base and are not optional for interoperability
|
Functional
Requirement |
Reference |
Comments |
|
Delivery “At Most Once” |
4.2.1(a) |
Algorithm guarantees the same message is never passed more than once to the Receiving Party’s MSH |
|
Report failure to Sending Party |
4.2.1(b) |
Sending Party’s MSH will report failure (of delivery to Receiving Party’s MSH) to Sending Party if requested; not sure how to do this without timeouts… |
|
MS must support direct connections between MSHs |
|
Doesn’t support multi-node networks (e.g. intermediate pass-through MSH between the Sender MSH and Receiver MSH) |
|
MS does not recognize transport-specific properties (QoS, reliability functions, etc.) |
|
Sending Party just decides “send reliably or not” |
|
Message ordering not specified beyond simple ACK of each message |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Trading Partner/Discovery
|
Functional Requirement |
Reference |
Comments |
|
Include TPA-related message routing Information in message header |
See comments |
The basic TPA-related routing information is complete at this time. The Overview and Requirements specification should be updated to cover TPA requirements and connections between the TRP and TP teams. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Error Handling
|
Functional
Requirement |
Reference |
Comments |
|
failure to deliver
shall be reported, if the sending party requires it. |
section 4.2 |
|
|
inability to send a document may be notified to the party that sent the document |
section 4.2 |
|
|
Error messages should be capable of
reporting on: a) errors associated
with the underlying transport protocol, e.g. HTTP b) errors in the message
wrapper, message header or message routing information c) errors with the way
documents are wrapped inside their message envelopes d) errors associated
with failed attempts at reliable once-only delivery of messages e) errors in the documents
that are being transported g) abnormal errors
with the services that processed the documents (e.g. the
service crashed) |
section 4.2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Service Interface
|
Functional
Requirement |
Reference |
Comments |
|
Define a simple, conceptual service interface that maps incoming messages to unique actions within specified application service. |
5.2 |
Sections 5.2.2 though 5.2.5 describe choreography and process that belong in the BP requirements, not the TRP requirements. |
|
Define header elements that support phase 1 mapping. |
5.2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Transport/Packaging
|
Functional
Requirement |
Reference |
Comments |
|
Documents, expressed either in XML or other electronic formats, shall be able to be wrapped inside a message envelope for transporting between the parties involved in eCommerce. |
section 4.1 |
|
|
Messages may be transported
over many network protocols (e.g. HTTP, SMTP, CORBA, 118 JMQ, MQSeries, MSMQ, etc) |
section 4.1 |
Propose limiting scope in phase 1 to HTTP, SMTP, FTP |
|
Servers/systems that
support the exchange of documents shall be treated as "black boxes" |
section 4.7 |
|
|
The method used to
transport documents shall be completely independent of: a) the hardware used
by the server/services at each end b) the software or
systems architecture of the server/services at each c) the language used
for implementation of systems and applications. |
section 4.7 |
|
|
3) Support for a service
shall be expressible solely in terms of the type and sequence in which documents (and their message
envelopes) are to be exchanged |
section 4.7 |
|
|
4) The ebXML
Transport, Routing and Packaging specifications shall be suitable for implementation on
hardware that varies from a very simple device to a large
multi-processor/system complex |
section 4.7 |
|
|
1) The protocol shall
be extensible to support (by use of protocol versioning): c) additional types of
data in message headers and message routing information d) new values for
codes |
section 4.9 |
|
|
|
|
|
|
|
|
|
Security
|
Functional
Requirement |
Reference |
Comments |
|
Access controls to prevent unauthorized access |
|
when permissable by underlying transport mechanism |
|
Payload documents may be digitally signed as defined in the PA by the From Party |
|
Decided at Dallas F2F 9/2000 |
|
Payload can also be encrypted as defined in the PA by the From Party |
|
Decided at Dallas F2F 9/2000 |
|
On the wire encryption of message headers possible (SSL, TLS) through transport level security mechanisms as defined in PA |
|
Decided at Dallas F2F 9/2000 |
|
Signatures on digitally signed documents may be used by the To Party to: i. Verify the authenticity of the From Party
ii.
|
|
Decided at Dallas F2F 9/2000 |
|
|
|
|
|
|
|
|
Miscellaneous
|
Functional
Requirement |
Reference |
Comments |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PHASE TWO FUNCTIONAL REQUIREMENTS
USE CASES
The functional requirements
specified for phase 2 should be sufficient to support the following user
scenarios:
- A third party service bureau operating
as a proxy for one or more trading partners (multihop/multinode)
- Two trading partners engaged in
multi-message protocol exchanges where the multiple exchanges are
considered an atomic unit or related set (CHRIS FERRIS TO PROVIDE REVISED
WORDING)
- Two trading partners can
cryptographically process data (encrypt/sign and decrypt/verify)
before/after.
- Two trading
partners engaged in a message exchange may agree to cryptographically sign
and verify either the message header, the routing header(s) and/ or the
payload. The sending message handler or the originator may perform the
signing of the payload. The sending message handler signs the message
header. A routing header may be
appended to the message & message by the message service handler. The routing header may also be
signed by the message service handler.
Policy in the PA states which message service handler is
responsible for verification of the signature.
- Communication via multiple intermediaries.
Same as Scenario 3 but one of the hops is an intermediary, which forwards
the message to the recipient. The Sender wishes to enforce the
non-repudiation property of the route. Any intermediate message service
handler that appends a routing message must log the routing header
information. Signed routing headers and the message headers must be logged
at the message handler which passes the message to the “to” party to
provide the evidence of non-repudiation.
Real life examples: Sun and Cisco trading through their component
net markets. Slam Dunk Networks charge per KB of the transferred message.
- Communication via an
intermediary using a variety of transports. Same as Scenario 3 but the
intermediary forwards the message to the recipient using a different
transport (e.g. FTP). The Sender wishes to enforce the non-repudiation
property on the route. Real life example: connection to a remote partner
in Africa over an unreliable network segment (Intel).
FUNCTIONAL REQUIREMENTS
Core Functionality
|
Functional Requirement |
Reference |
Comments |
|
4.1.9 replyTo |
line 126 |
belongs in TPA, probably phase 1 |
|
4.1.8 message lifetime |
line 124 |
belongs in TPA, probably phase1 |
|
|
|
|
|
4.3.1.c intermediary router |
line 165 |
|
|
|
|
|
|
4.5 auditing/audit trails |
line 193 |
this needs some refinement IMHO |
|
4.6.8 message (set) status |
line 222 |
probably belongs in service interface discussion |
|
4.9 extensibility |
line 256 |
|
|
|
|
|
Reliability
|
Functional
Requirement |
Reference |
Comments |
|
MS supports multi-node networks, but each node is just pass-through |
|
Intermediate MSH handler nodes allowed, no processing |
|
Sending MSH can set time-out for message and will report error if MSH-level ACK not received within timeout |
|
Phase 1 just requires error notification if no delivery; this requirements allows setting of a specific timeout period |
|
Scalability |
|
Must scale to large networks |
|
Sequence of related messages can be established and forced for transmission |
4.2.1(e) |
|
|
Sending application may establish a group of unordered messages to be sent reliably |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| < |