+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:]
> | Sent: Wednesday, December 05, 2001 7:21 AM
> | To: 'Martin W Sachs'; Pae Choi
> | Cc: Stefano POGLIANI;
> | 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:]
> | Sent: Wednesday, December 05, 2001 9:39 AM
> | To: Pae Choi
> | Cc: Stefano POGLIANI; Anarkat, Dipan;
> | 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 <> on 12/05/2001 06:16:11 AM
> |
> | To: Stefano POGLIANI <>, "Anarkat, Dipan"
> | <>,
> | 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 ;
> | 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:]
> | Sent: 04 December 2001 20:17
> | To:
> | 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>
----------------------------------------------------------------
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>
