OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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



I thought that this one is worth cross-posting to the MSG list server.

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
*************************************************************************************



"Anarkat, Dipan" <DAnarkat@uc-council.org> on 12/05/2001 10:20:32 AM

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



Pae Choi,
   I see a vendor lockdown over here. If my company and the trading
   partners
are using ebXML for everything then I need to find a vendor whose ebXML B2B
app supports all the modules on the ebXML stack . Since there are no
standard interfaces defined b/w an :
  #ebMS handler and an ebCPA handler
  #ebCPA handler and an ebCPP handler
  #ebCPP handler and an ebRR
  #ebCPA handler and an ebBPSS handler
  #etc.

how can I probably get a best-of-the breed solution from the market ? Maybe
JAVA may help here to define standard interfaces for communcation b/w
different ebXML handlers.
Any comments ?

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Wednesday, December 05, 2001 9:39 AM
To: Pae Choi
Cc: Stefano POGLIANI; Anarkat, Dipan; ebxml-dev@lists.ebxml.org
Subject: Re: [ebxml-dev] ebXML specifications interdendancies



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/












[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC