Re: [ebxml-bp] Re: ebBP 2/7/2005: Updated Combined Summary of BSI-MSI

["David Webber \(XML\)" <david@drrw.info>]

Duane,

I'm not so sure you do follow what Sacha is driving at!

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