[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] Re: ebBP 2/7/2005: Updated Combined Summary of BSI-MSI
David Webber (XML) wrote: >Duane, > >I'm not so sure you do follow what Sacha is driving at! > > Me neither anymore. Everytime somebody writes a new email the details of what is proposed seem to be clear as mud again. BTW - I had $20 bet that you would have interjected with CAM earlier ;-) I concur with your understanding below of what I though the MSI was. However, John has defined it as the "external" (not internal) interface. Accordingly, the external interface will not talk to the BP* engine. Quote: "Message(ing) Service Interface (MSI): the set of messages exchanged between partners, and the interface defined rules governing sequencing and processing, used to support a business process." Monica's draft she circulated seemed to have a few loose definitions, then there is the loose definition in the eb MS 2.0 spec (only one sentence describing it as abstract...) and then the proprietary notion of an internal facing interface. If this were American football, I think its' time to call "time out" and have a strategy session before this goes anywhere else. It would make sense to standardize the API's between implementations of BP* management tools and messaging tools. The JAXM approach had a good idea. Anyways - I am dropping the torch on this one. I've been on this train far too long and should have got off sooner ;-) Good luck with it. Duane >Even within a single server - if I have a BPM engine, >and ebMS, a Registry and some CPAs and CAM >templates how do I make this all run smoothly together? > >If I am talking from my ebMS to a partners different ebMS, >will their backend BPM engine manage state in the same >way that mine is - given the signals and transactions we >are using? Can he use rule templates that I have? > >If I replace the ebMS with another ebMS - what configuration >is needed? > >We answered a lot of these Q's in the XML2004 interop for >the six tools we configured - and created integration components >based on particularly the features in CPA. But we did not >link in a BPM engine - and that is another whole level of detail. > >Right now with BPSS V2 I think we can do some interesting >and useful things - but its going to take BPSS V3 before a >much richer environment can be specified here. > >2005 is beginning with a lot of cool stuff happening! > >Cheers, DW > >----- Original Message ----- >From: "Duane Nickull" <dnickull@adobe.com> >To: "Sacha Schlegel" <sschlegel@cyclonecommerce.com> >Cc: "ebXML BP" <ebxml-bp@lists.oasis-open.org> >Sent: Tuesday, February 08, 2005 11:44 AM >Subject: Re: [ebxml-bp] Re: ebBP 2/7/2005: Updated Combined Summary of >BSI-MSI > > > > >>Sacha: >> >>ebXML is a component based architecture, we tried not to enforce >>specific programming styles when building the specs. >> >>I do not see a high value in a concrete interface between messaging and >>BPM. Since this is behind a corporate firewall, it is unlikely someone >>would incur a SOAP + XML hit to have those components talk to each other. >> >>What is far likelier is that it will be in some specific language such >>as Java and use RMI. Nothing in either inteface should be dependent >>directly upon the data model in the BPSS schema or eb MS XML. >> >>I think I now understand what it is you are trying to do. An >>implementation guide may be a good way to do this. Probably a good idea >>for all instances of MSI and BSI to be dropped from the spec since they >>have caused far too much confusion over the years. >> >>Duane >> >>Sacha Schlegel wrote: >> >> >> >>>ebBP team, Duane, >>> >>>comments inline ... >>> >>>Am Montag, den 07.02.2005, 13:26 -0800 schrieb Duane Nickull: >>> >>> >>> >>> >>>>Monica J. Martin wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Section 4: Language Overview >>>>>================ >>>>>FROM: >>>>>The BSI is completely separate from the Message Service Interface >>>>>(MSI). In particular an MSI MAY be used without a BSI. A CPA, which >>>>>contains a reference to a ebBP definition serves as the basis for the >>>>>configuration of the BSI to enforce the protocol and semantics of the >>>>>ebBP definition, as depicted in Figure 1. >>>>> >>>>> >>>>> >>>>> >>>>I would caution you that there are companies who have prior use of the >>>>term "MSI" in the context of a programmers interface to ebXML MS >>>>software. Accordingly, it may be subject to trademark and/or >>>>copyright. I cannot verify this any further at this time. >>>> >>>>Discussing concrete interfaces also violates one of the core principles >>>>of ebXML in the architecture which was not to impose any specific >>>>implementation style *where unnecessary* upon those building software. >>>>Prescribing interface based design is one constraint that is not in >>>>alignment with either the core requirements or architecture of ebXML. >>>> >>>> >>>> >>>> >>>I cannot argue against the "principles of ebXML" as I have not been >>>there at that time the pricnciples were put into stone. >>> >>>But I can ask why? What was the rationale to not have components based >>>ebXML building software? >>> >>>Why are is a Message Service Interface mentioned. This interface is that >>>abstract that not even the interface is described. Guess it is not even >>>an interface if it is not defined. >>> >>>With everything being so abstract everyone tends to do whatever he/she >>>thinks is right. And because it is so abstract, virtual, logical, >>>everyone is having a valid solution. >>> >>>Please excuse me but I see value for ebXML end users to be able to pick >>>their building ebXML components. >>> >>>I feel silly because it is currently just one interface the one between >>>the MSH and an ebXML business process component. The one between an >>>ebXML business process component can follow thereafter. >>> >>> >>> >>> >>> >>>>Accordingly, it may be a better idea to discuss this as the association >>>>with the messaging component of the architecture, not the interface. >>>>Align the functionality abstract of the implementation. Interface >>>>descriptions are probably better handled in a JSR type group than the >>>>core standard. >>>> >>>> >>>> >>>> >>>OK so there is a place for interface descriptions. The thing to me is if >>>they are not part of the core standard they are simply of less >>>importance, in particular to the Independet Software Vendors (ISV's). >>> >>>JSR as in Java Specification Request is not what I am looking for as >>>that is language specific. >>> >>>But I recognise you saying that there is room for interface >>>descriptions. >>> >>>Regards >>> >>>Sacha >>> >>> >>> >>> >>> >>>>Duane >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>-- >>*********** >>Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com >>Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/ >>Adobe Enterprise Developer Resources - >> >> >http://www.adobe.com/enterprise/developer/main.html > > >>*********** >> >> >> >> >> > > > > -- *********** Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/ Adobe Enterprise Developer Resources - http://www.adobe.com/enterprise/developer/main.html ***********
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]