Re: [ebxml-dev] ebXML specifications interdendancies

[Martin W Sachs <mwsachs@us.ibm.com>]

Chris,

Of course, you are right.  I omitted the point because I believe that Pae
Choi was talking about deployment and not negotiation or exchange of CPPs.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Christopher Ferris <chris.ferris@sun.com> on 12/05/2001 10:29:22 AM

To:    Martin W Sachs/Watson/IBM@IBMUS
cc:    Pae Choi <paechoi@earthlink.net>, Stefano POGLIANI
       <stefano.pogliani@sun.com>, "Anarkat, Dipan"
       <DAnarkat@uc-council.org>, ebxml-dev@lists.ebxml.org
Subject:    Re: [ebxml-dev] ebXML specifications interdendancies



Marty,

Actually, if you had a CPA for negotiation that supported
a business process for said negotiation, you could carry
an unrelated CPA as payload in a message exchange. In this
context, the payload CPA is just application data for
the negotiation process.

We have also had some discussions in the MSG TC that
noodled on possible approaches for having the CPA for
an exchange carried with the first message exchanged,
and identified by a URI that corresponded to the
Content-Location (or Content-ID) of the payload part
that carried the CPA to be used. Again, this was just
noodling in context of a brainstorming session which we
had, I believe in Tokyo.

Regardless, an automated negotiation of a CPA would
require that *some* protocol carry proposed CPA as payload.
ebXML MSH seems to me to be as good as any other;-)

Cheers,

Chris

Martin W Sachs wrote:

> Pae Choi,
>
> The CPA should NEVER be carried in a business message.  That would mean
> that the runtime configuration information would have to be populated
again
> for each new message.  The CPA's job is to document an agreement on the
> static configuration information and, via a CPA deployment tool, populate
> the two partners' runtime configuration once for the duration of an
entire
> business relationship.
>
> Regards,
> Marty Sachs
>
>
*************************************************************************************

>
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287;  IBM tie line 863-7287
> Notes address:  Martin W Sachs/Watson/IBM
> Internet address:  mwsachs @ us.ibm.com
>
*************************************************************************************

>
>
>
> Pae Choi <paechoi@earthlink.net> on 12/05/2001 06:16:11 AM
>
> To:    Stefano POGLIANI <stefano.pogliani@sun.com>, "Anarkat, Dipan"
>        <DAnarkat@uc-council.org>, ebxml-dev@lists.ebxml.org
> cc:
> Subject:    Re: [ebxml-dev] ebXML specifications interdendancies
>
>
>
>
> +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/
>
>
>
>
>
>
>
>
>
> ----------------------------------------------------------------
> The ebxml-dev list is sponsored by OASIS.
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.ebxml.org/ob/adm.pl>
>