Use cases being addressed by ebXML

After conferring with several people who are members of both ebXML and W3C
XP the consensus is that ebXML's use cases may prove useful to XP, so here
goes.

The ebXML Transport Routing and Packaging group created a three phase
delivery matrix that is used to guide the development of ebXML's
specifications. Each of the three phases has an associated set of
requirements and use cases which help to define the "scope" of functionality
being provided by the specification at each phase. Requirements and use
cases in later phases represent increasing levels of complexity and/or
functionality over earlier phases.

Phase 1 Use Cases:

The ebXML Messaging Service specifications delivered in phase 1 should be
sufficient to support the following user scenarios:

1.1 A party wishing to send unacknowledged messages to another party or set
of
    parties (e.g. send a stock price update every 15 minutes)

1.2 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)

1.3 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.

1.4 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.

Phase 2 Use Cases:

The ebXML Messaging Service specifications delivered in phase 2 should be
sufficient to support the following user scenarios:


2.1 A third party service bureau operating as a proxy for one or more
trading
    partners (multihop/multinode)

2.2 Two trading partners engaged in multi-message protocol exchanges where
the
    multiple exchanges are considered an atomic unit or related set.

2.3 Two trading partners can cryptographically process data (encrypt/sign
and
    decrypt/verify) before/after.

2.4 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 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.

2.5 Communication via multiple intermediaries. Same as Scenario 2.4 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.

2.6 Communication via an intermediary using a variety of transports. Same as
    Scenario 2.5 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).

Phase 3 Use Cases:

The ebXML Messaging Service specifications delivered in phase 3 should be
sufficient to support the following user scenarios:

3.1 A publish/subscribe scenario in which a publisher provides a service to
    subscribers. Information can be sent to interested parties using a
    distribution list type of processing.

3.2 Parties offer a quality of service capability so that trading partners
can
    query a server to determine the various options for communicating in a
data
    exchange. For example, a service may offer 15 minute stock quotes for
    one price and real time stock quotes for another price.

3.3 Communication via an intermediary. A party wishes to exchange a business
    message with another party. The sending party has defined a PA and the
    receiving party has accepted the agreement including a Confidentiality
Policy.
    The message header and the Payload is encrypted and sent from originator
to
    an intermediary message service which is responsible for routing the
request
    to the appropriate set of business partners defined by the recipients
    organization and documented in the PA.  A positive acknowledgement is
issued
    by the message service as well as the target recipients to the
originator
    indicating a successful transfer. All routing headers have been
digitally
    signed. Real life example: requested by Compaq at a RNIF meeting.




Dick Brooks (ebXML liaison to W3C XML Protocol Activity).
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

Received on Tuesday, 28 November 2000 18:29:40 UTC