[Fwd: Re: [ebxml-msg] Status of MSH configuration by CPA and MSH API]

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Dale's response to Sacha today.

>Moberg: Hi Sacha,
>You posed two questions.
>
>a) Is it implicit that a MSH could/should be configured with a CPA? Do
>you push this in the ebMS specification 3.0? Do you have real world
>experience how todays MSH's are configured? eg. Hermes from
>www.freebxml.org uses a properties.xml file or similar but no CPA.
>
>Each ebXML TC is supposed to be able to work with other ebXML
>specifications as well as work independently of them. So in principle a
>MSH can be produced that does not make use of CPAs, but instead acquires
>configuration information from other sources (such as from GUI user
>input routines). (Even including a CpaId value that is not actually the
>value of a CPA!)
>
>However, some ebXML user communities require that ebMS MSHes are capable
>of using CPPs or CPA templates or the like. So many ebMS products now
>provide support for "import" support for CPAs or CPA templates. The
>export support
>and exchange support tend to vary more widely. As you know, the
>negotiation specification will provide one way to allow different
>products to exchange information, and using Registry/Repositories
>provides another way.
>
>To some extent product features in this area will probably be driven by
>adopters, and their requests and priorities are still arriving. I
>wouldn't count on being able to use properties.xml files in an
>interoperable way.
>
>
>b) Will you provide an API of the MSH? Without practical experience I
>would think that current ebMS systems communicate straight with the
>backend applications. As I am interested in an ebXML Business Service
>Interface (BSI) which executes (or monitors) a BPSS I am wondering of a
>standardiesd interface between BSI and MSH. In the sense that I could
>easily exchange an MSH. Any attempts to specify this in version 3.0?
>
>The BSI is an interface that, in a sense, is expressed by the
>combination of a MSH with backend systems.
>The distribution of BSI functions over those two components is currently
>not specified, nor are the APIs for  communication among these two (or
>more!) components documented. [One API for communication among the
>components, sometimes called the MSI, has been discussed and started
>several times. At the moment, the 3.0 convergence efforts have greater
>priority than cleaning up the BSI/MSI situations. I don't think the API
>issues are resolved yet in detail or even at an architectural level.]
>  
>