[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: Re: [ebxml-msg] Status of MSH configuration by CPA and MSH API]
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.] > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]