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

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

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