Re: [ebxml-dev] ebXML specifications interdendancies

[Pae Choi <paechoi@earthlink.net>]

+1

 

A CPA to the ebMS Message Package(i.e., packet, message frame, etc

in the conventional naming) is a payload to the message package.

 

For example, a TCP payload, e.g., SMTP, to the TCP packet.

 

You would not want to put the payload handlers in the payload container

handler as a same package. Nothing is stopping you if you prefer to do so.

But just remember that the payload container can contain the multiple type

of payloads, not just CPA.

 

Regards,

 

 

Pae

 

----- Original Message -----

From: Stefano POGLIANI

To: Anarkat, Dipan ; ebxml-dev@lists.ebxml.org

Sent: Wednesday, December 05, 2001 2:27 AM

Subject: RE: [ebxml-dev] ebXML specifications interdendancies

I, personally, wouldn't go that path.

 

Here is a "logical" description of how I personally see the scenario:

An MS Handler is, IMHO, driven by some other software that understands the CPA. Such software "reads" the CPA and, then, uses the MS Handler to deal with messaging. This software is the one that, based on the actual CPA content, properly uses the MSH features to account for messaging, security, reliability etc. This software may, also, use a specialised agent to interpret the BPSS choreography.

 

Now, this is obviously my interpretation and is a "logical view". I do not want to say that MS Handlers that are able to do everything are not possible. But, from a logical architecture point of view there is the possibility to manage the different parts of ebXML with different softwares that communicate.

 

Best regards

/stefano

 

-----Original Message-----
From: Anarkat, Dipan [mailto:DAnarkat@uc-council.org]
Sent: 04 December 2001 20:17
To: ebxml-dev@lists.ebxml.org
Subject: [ebxml-dev] ebXML specifications interdendancies

 Hi,

    I am trying to assess the functional interdependancies b/w the diferent systems in the ebXML stack from an implementation standpoint, used in an e-business framework.

    As we know, the ebCPPA spec does specify how a CPA is negotiated between 2 trading partners. I also understood from a couple of vendors that the CPA instance XML has to be loaded into the internal database (any form) of the MSH. It really doesnt matter how the CPA is negotiated or for that matter even if it is in XML form.

All that is required is a conclusion representing the CPA that can be in any format, as long as it can be loaded into the internal database of the MSH as provided by the vendor.

    This means that an ebMS compliant MSH has also to be compliant with the ebCPPA. Also since the ebCPP and ebCPA instances identify the Business Processes in an ebBPSS instance, it means that the ebMS compliant MSH will also have to be compliant with the ebBPSS if it has perform the intended function of being able to validate and process ebMS TR&P messages . 

    This means that the ebMS TR&P cannot be used independantly for TR&P and forces you to use ebCPPA and ebBPSS. As such, even though an agreement may not be required between trading partners , we still need a bare bones 'void agreement' .

Is my understanding right, or am I missing a point here !?

 

Dipan Anarkat
EC Systems Analyst
Uniform Code Council, Inc.
Tel: (609)-620-4509
http://www.uc-council.org/