[ebxml-mktg] FW: [hst] ebXML

[bhaugen <linkage@interaccess.com>]

Suresh Damodaran of Sterling Commerce
presented a "harvest" of ebXML concepts
to the W3C Web Services Architecture Group.

Suresh gave me permission to forward his
message - see below.

I think he did a great job, and hope others
find it interesting and useful.

Moreover, the WS-Arch group will most likely
be very influential in charting the future direction
of "Web services", so I am very happy
that somebody is (at last) putting ebXML
on their agenda.

Thanks, Suresh!

-Bob Haugen


----- forwarded message -----
URL: http://lists.w3.org/Archives/Public/www-ws-arch/2002Jul/0365.html
Message-ID:
<40AC2C8FB855D411AE0200D0B7458B2B07C598AB@scidalmsg01.csg.stercomm.com>
From: "Damodaran, Suresh" <Suresh_Damodaran@stercomm.com>
To: "'michael.mahan@nokia.com'" <michael.mahan@nokia.com>,
www-ws-arch@w3.org
Date: Mon, 22 Jul 2002 14:34:02 -0500
Subject: [hst] ebXML


Mike,

Here is a brief write-up on ebXML. Please change into a format that
you have adopted in HST as appropriate because I have not spent much
time
on getting the format right.
If there are questions on this, please let me know in a day or so,
because I won't be able to respond much afterwards.

Cheers,

-Suresh
Sterling Commerce

<harvest name ="ebXML">

In brief: The ebXML suite of specifications enables enterprises to
conduct
business over the Internet using a service based architecture. ebXML
(http://www.ebxml.org/ and http://www.oasis-open.org) consists of 5
specifications currently, addressing different aspects of B2B e-commerce
over the Internet: ebXML Message Service (ebMS), ebXML Collaboration
Protocol Profile and Agreement (ebCPPA), ebXML Registry (ebR), ebXML
Business Process Specification Schema (ebBPSS), and ebXML Core
Components
(ebCC). Each specification is designed to be implementable independent
of
other specification, though appropriate mappings and hooks are provided
to
support efficient integration of components built using other ebXML
specifications.

Components: Party, Role, Service, Actions, Collaboration Protocol
Profile
(CPP), Collaboration Protocol Agreement (CPA), Registry, Attachment.

Connectors: Message Service Handler (MSH), Business Service Interface
(BSI)

Data Elements: ebXML Message, Business Process Specification, Business
Document, Business Transaction, Binary Collaboration.

There are several name spaces used in all the specifications, and I
haven't
pulled them out.

Architectural Concepts:

 Concept of Operation:  An ebXML Message from a Party A invokes an
Action within a Service at Party B. The message is received and
processed by
the MSH at Party B according to a prior agreement  (CPA) between Party A
and
Party B. This agreement is a CPA. The agreement between Party A and
Party B
may be arrived at by negotiation (ebXML does not specify the details how
this negotiation happens) between them based on the CPP of Party A and
CPP
of Party B. The integration of the MSH and the business application
executing at a Party is carried out through a BSI (not fully specified
by
ebXML). An ebXML Message may be in a conversation consisting of multiple
messages that implements a Business Transaction. A Business Transaction
may
include at a request, and the corresponding response, and
acknowledgements
for the request/response. A Binary Collaboration contains an aggregation
of
related Business Transactions. A Binary Collaboration and/or CPP may be
used
to identify and  implement the Services. Party A and Party B may
retrieve a
specified Binary Collaboration and CPPs from Registry.

 Message based service invocation - ebMS:
http://www.oasis-open.org/committees/ebxml-msg/
- An MSH is implemented conforming to ebMS. ebMS specifies
peer-to-peer, asynchronous, synchronous, reliable interactions between
Party
A and Party B. An ebXML Message extends SOAP 1.1
(http://www.w3.org/TR/2000/NOTE-SOAP-20000508/) for such specification.
An
ebXML message can be signed. Signature processing  is specified in ebMS,
and
extends  XML Signature (http://www.w3.org/TR/xmldsig-core/). An ebXML
Message may have attachments (per "SOAP with Attachments"
http://www.w3.org/TR/SOAP-attachments) that are Business Documents such
as
Purchase Order. These Business Documents may be in EDI, XML, or any
other
format. MIME is used to physically package the ebXML Message with the
Attachments. ebMS provides an XML Schema for a ebXML Message. ebMS uses
a
CPAId to identify the CPA that governs the ebXML Message reception and
processing.

Implementation independent Service specification - ebCPPA:
http://www.oasis-open.org/committees/ebxml-cppa/
A CPPA specifies XML Schemas for CPP and CPA, and also guidelines to
form a
CPA from two CPPs. The CPP contains elements that specify Roles (e.g.,
Seller, Buyer), Services, Actions, and message attributes  (e.g., number
of
retries, time out interval, and so on for reliable messaging,
certificates
for trust management). It is possible to derive WSDL from CPP
(http://www.oasis-open.org/committees/ebxml-cppa/documents/presentations
/ind
ex.shtml - see 4th F2f Web Services Zip File).

 Registry : http://www.oasis-open.org/committees/regrep/
 Registry is a registry ("catalog") as well as a repository
("warehouse"). Interfaces to manage the lifecycle of Registry entries
and to
support queries on Registry entries are provided. Primarily, a Registry
is
intended as a repository of CPPs and public business processes, though
information in any format may be stored in the repository and registered
in
the Registry.

ebBPSS: http://www.geocities.com/ebtwg_bp/
ebBPSS is used to specify the externally visible ("public") business
process
between Party A and Party B. It provides an XML Schema to specify Binary
Collaboration between Party A and Party B. A Binary Collaboration may
consist of multiple Business Transactions. Each Business Transaction is
specified in terms of Business Envelopes, Business Documents, and
Business
Signals that are communicated between Party A and Party B.

ebCC:
http://www.ebtwg.org/projects/documentation/core/CoreComponentsTS1.80.pd
f
ebCC specifies the semantic elements of a Business Document to eliminate
dependencies on syntax (e.g., EDI) of Business Documents.

Architectural Decisions:
- Modular specifications: each specification can be independent of
another to facilitate easy adoption
- The operations described in the "Concept of Operation" earlier are
divided into three phase: Implementation, Discovery, and Run-time. A CPA
formed during the discovery phase is not changed during the execution of
business transactions in run-time phase.
- Mappings among specifications: Whenever an ebXML specification can
use a component built to another ebXML specification, the necessary
mappings
between the specifications are specified.
- Evolve the current state of the art instead of impose a new
infrastructure - In B2B world EDI is still used heavily, and the best
practices of such usage is used in the design of ebXML.
- Never reinvent the wheel - use other specifications (use of SOAP 1.1
and XMLDSIG in ebMS, for example) whenever available and appropriate.

</harvest>