Re: [ebxml-dev] ebXML specifications interdendancies

[Pae Choi <paechoi@earthlink.net>]

+1


Pae


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