Re: [ebxml-bp] [Fwd: Re: [ebxml-msg] Status of MSH configurationby CPA and MSH API]

["Anders W. Tell" <anderst@toolsmiths.se>]

Hi Sacha,

For your library of ebMS usages.

In the Swedish project run by SFTI (local goverment in sweden) we have 
defined a Base Transportprofile which a subset of ebMS.
<http://eh.svekom.se/nyheter/nyheter.html>. This effort is now also 
being presented on european level.

Here we are not using CPP/A and BPSS (except Receipt). Instead we have 
defined a simple Profile which was deemed as a more cost effective start 
than full CPP/A support:
Here is an example
<http://www.toolsmiths.se/company/Collaboration/collaboration.html>
(works with explorer)

The Swedish Interest group for ebXML has also started to work on how 
parties can find each others through an "organized" website.
<http://www.ebxml.nu>
<http://www.ebxml.nu/index.php?option=content&task=view&id=4&Itemid=>


thanks
/anders

Monica J. Martin wrote:

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


-- 
/////////////////////////////////////
/ Business Collaboration Toolsmiths /
/ website: <www.toolsmiths.se>      /
/ email: <anderst@toolsmiths.se>    /
/ phone:  +46 8 562 262 30          /
/ mobile: +46 70 546 66 03          /
/////////////////////////////////////