RE: [ebxml-dev] ebXML specifications interdendancies

[Krishna Sankar <ksankar@cisco.com>]

Hi,

	Actually I do not see any vendor lock down just because all the components
are decoupled.

	Let us start with the registry which could be from one vendor. As the RSS -
the client interface is well defined, any other software (from any other
vendor) would be able to interact with it.

	CPA & CPP in the end are just XML documents and so any program can read
them and interpret them as per the CPP/CPA specs. (BTW, we could use another
vendor's CPP/CPA product to perform all the collaboration related
activities)

	Now potentially, another vendor's ebXML MSH can interact with the registry,
read the CPAs et al and exchange documents.

	Now going back to you question of *handlers*, any engine (which does
whatever part of ebXML - for example a message engine or a collaboration
engine or a registry engine) will have to implement it's own handler to the
required ebXML components. We really do not want to replace just the
*handlers*, for a best of breed approach. What we could do is to buy
different engines for different functionalities and *expect* them to work
seamlessly, which they will.

	Also on a related note, your thought about the Java APIs is right on the
money ! The good news is that all the ebXML interfaces are (or in the
process of being) Java APIs - JAXM,JAXR,...

	<soapbox>
		Usually we defined interoperability or cohesion based on APIs - method
calls or an abstraction of the methods defined through an external scheme
(like the IDL). In the XML world, we define the vocabulary and the message
syntax & semantics for a functionality. We then, of course, talk to these
engines using standard protocols and transports thus making them universal &
interoperable.
	</soapbox>

	Hope this helps.

cheers

 | -----Original Message-----
 | From: Anarkat, Dipan [mailto:DAnarkat@uc-council.org]
 | Sent: Wednesday, December 05, 2001 7:21 AM
 | To: 'Martin W Sachs'; Pae Choi
 | Cc: Stefano POGLIANI; 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/
 |
 |
 |
 |
 |
 |
 |
 |
 | ----------------------------------------------------------------
 | 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>
 |