[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.pdf
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>



-----Original Message-----
From: michael.mahan@nokia.com [mailto:michael.mahan@nokia.com]
Sent: Friday, July 12, 2002 11:11 AM
To: www-ws-arch@w3.org
Subject: RE: [hst] harvest list (repost Wed 07/10/2002 03:16 PM)



[this is a repost to the public list of a message sent earlier
to the member list]

Thanks for pitching in Suresh! I will put your name aside 
ebXML.

Follow the links I sent Joel. Basically, we want to capture the 
hard architectual elements of connectors and components, along 
with descriptions of their roles and responsiblities. Also, we 
want to try to capture any other architectural feature often 
described in other 'views' of the architecture. From this I mean 
things like MEPS, process models, etc. We/I am open to some 
interpretation here, so grab what seems relevant to the ebXML 
architecture. We will try to normalize after the harvesting is
completed.

Thanks again. 

Mike 

>-----Original Message-----
>From: ext Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
>Sent: July 10, 2002 11:28 AM
>To: Mahan Michael (NRC/Boston)
>Subject: RE: [hst] harvest list
>
>
>Michael,
>
>As you may know, I have a fairly good understanding of most 
>standards in
>ebXML.
>If you give me a brief idea about what is expected of 
>harvesting, I can help
>with ebXML.
>Please let me know.
>
>Regards,
>
>-Suresh
>Sterling Commerce   
>
>
>
>-----Original Message-----
>From: michael.mahan@nokia.com [mailto:michael.mahan@nokia.com]
>Sent: Wednesday, July 10, 2002 8:46 AM
>To: joel.d.munter@intel.com; distobj@acm.org; Hao.He@thomson.com.au;
>gdaniels@macromedia.com; jones@research.att.com
>Cc: chrisfer@us.ibm.com; w3c-ws-arch@w3.org
>Subject: RE: [hst] harvest list
>
>
>
>Thanks Joel, your help is appreciated. Please have at it with UDDI.
>
>There have been discussions on what harvesting entails[1][2]. For an 
>example, Mark has harvested REST [3]. Our overall approach is at [4], 
>which we are entering step 2.
>
>Hope this helps - we are trying to figure this out as we go, 
>so feel free 
>to chime in with suggestions.
>
>[1] http://lists.w3.org/Archives/Member/w3c-ws-arch/2002Jul/0017.html
>[2] http://lists.w3.org/Archives/Member/w3c-ws-arch/2002Jul/0028.html
>[3] http://lists.w3.org/Archives/Member/w3c-ws-arch/2002Jul/0023.html
>[4] http://lists.w3.org/Archives/Member/w3c-ws-arch/2002Jul/0001.html
>
>>-----Original Message-----
>>From: ext Munter, Joel D [mailto:joel.d.munter@intel.com]
>>Sent: July 09, 2002 02:02 PM
>>To: Mahan Michael (NRC/Boston); distobj@acm.org; 
>Hao.He@thomson.com.au;
>>gdaniels@macromedia.com; jones@research.att.com
>>Cc: chrisfer@us.ibm.com; w3c-ws-arch@w3.org
>>Subject: RE: [hst] harvest list
>>
>>
>>As I am a little unclear of precisely what you are looking 
>>for, I would be
>>happy to help someone "harvest" UDDI.  
>>Joel
>>
>>-----Original Message-----
>>From: michael.mahan@nokia.com [mailto:michael.mahan@nokia.com]
>>Sent: Monday, July 08, 2002 2:20 PM
>>To: distobj@acm.org; Hao.He@thomson.com.au; gdaniels@macromedia.com;
>>jones@research.att.com
>>Cc: chrisfer@us.ibm.com; w3c-ws-arch@w3.org
>>Subject: [hst] harvest list
>>
>>
>>
>>Hi All,
>>
>>It seems like there is a concensus to harvest both types of 
>>architectural
>>entities - 
>>both components/connectors and relevant arch features of the system
>>(processing model,
>>MEPs, etc.)
>>
>>Moving on, the current list to harvest:
>>1. SOAP/XMLP
>>2. WSD
>>3. OMG/Corba
>>4. REST
>>5. Meerkat
>>6. XML-RPC
>>7. UDDI
>>8. ebXML
>>
>>Any others?
>>
>>Mark Jones mentioned that he is going through the SOAP spec. In the
>>democratic 
>>spirit of divide and conquer, are there volunteers for the other
>>systems/specs?
>>
>>Mike
>>
>

Received on Monday, 22 July 2002 15:33:50 UTC