OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Steve,

I'm providing a similar approach with the VisualScript CPA
template - where a default model is available that can
be quickly adapted to the specifics of the business
agreement and BPSS.

It's simpler since no need for the BCF/FSV prelude - and
also - is neutral to the ebMS implementation.  Lesson
learned there is that each ebMS has varience in the XML
CPA syntax they handle - and it has to match.  So you
need to be context sensitive to the ebMS implementation
in the XML generated from the CPA model.

Thanks, DW

----- Original Message ----- 
From: "Steve Capell" <steve.capell@redwahoo.com>
To: "'Martin Sachs'" <msachs@cyclonecommerce.com>
Cc: "'Monica J. Martin'" <Monica.Martin@Sun.COM>; "'ebXML BP'"
<ebxml-bp@lists.oasis-open.org>; "'ebxml-cppa'"
<ebxml-cppa@lists.oasis-open.org>
Sent: Sunday, July 25, 2004 8:44 PM
Subject: RE: [ebxml-bp] [Fwd: [ebxml-msg] Status of MSH configuration by CPA
and MSH API]


> Martin,
>
> No, there is no CPP in our framework.  The process looks like this:
>
> 1 Start with BCF modelling of "public standard process" (encapsulating
> existing information models if approriate).
> 2 Generate a BPSS instance (from the BTV)
> 3 Generate a Template (partyA/partyB) CPA from the FSV
> 4 Publish BPSS, template CPA, XSDs etc to a UDDI registry according to
> a standard data model.  This collection defines the "public process"
> 5 A software vendor or consulting house generate "private process"
> schema (BPEL, XSLT, X-FORMS, etc) that permit specific back office apps
(eg
> SAP, Quicken) to comply with the previously published "public process".
The
> private process schema collections are also publishe to the UDDI registry
> according to a standard data model.
> 6 "ACME Corp" uses a hosted service on the registry to publish a
> complete UDDI technical profile - but because of the public / private
> process data model, they need only provide very minimal information and
the
> rest is generated.  Pretty much they just say "I have quickbooks v12 and
my
> e-mail address for B2B messages is b2b@acme.com".
> 7 ACME corp invites widget corp to collaborate in a particular process
> (eg order process).  A hosted partner manager service generates a
deployment
> CPA for ACME/Widget from one or more template CPAs.
> 8 The deployment CPAs (together with the BPSS and the necessary
> private process schema) are sent to both parties for automatic middleware
> configuration.
> 9 ACME & Widget co exchange business transactions.
>
> So, in effect, the UDDI profile for ACME / Widget is the "CPP" because it
> carries the necessary meta-data to generate a deployment CPA from a
> template.  The reson we went this way is because we considered it unlikely
> that partners will have the tools or smarts to create CPPs and go through
> the CPA computation & negotiation process.  Too many variables and just
much
> simpler to provide a hosted CPA computation service.  Added benefit is
that
> the registry knows about trading relationships and can proactively manage
> change.
>
> You can find some whitepapers on this at www.redwahoo.com
>
> Regards,
>
> Steve Capell
> Red Wahoo Pty Ltd
> +61 410 437854
>
> -----Original Message-----
> From: Martin Sachs [mailto:msachs@cyclonecommerce.com]
> Sent: Monday, 26 July 2004 12:58 AM
> To: Steve Capell
> Cc: 'Monica J. Martin'; 'ebXML BP'; ebxml-cppa
> Subject: RE: [ebxml-bp] [Fwd: [ebxml-msg] Status of MSH configuration by
CPA
> and MSH API]
>
> Steve,
>
> Does the CPP play a part in your process of generating a partner-specific
> deployment CPA? A CPP contains a prospective trading partner's preferences
> and requirements on a CPA.
>
> Regards,
> Marty
>
>
> At 01:55 AM 7/25/2004, Steve Capell wrote:
>
>
> >For my 20c, the automated configuration of an ebXML MSH from a CPA is one
> of
> >the key values of the the whole ebXML architecture and so should remain a
> >part of any future specs.  The only little issue is that this
pre-supposes
> >that you have an easy way to get a CPA in the first place.  After some
> >"experiments" we believe that the best route to a CPA is to generate
> partner
> >specific deployment CPA's from "abstract" template CPAs that are, in
turn,
> >generated from UMM (FSV) model data.  In this way we are pretty much able
> to
> >automate the entire deployment from model data.
> >
> >Steve Capell
> >Red Wahoo Pty Ltd
> >+61 410 437854
> >
> >
> >-----Original Message-----
> >From: Monica J. Martin [mailto:Monica.Martin@Sun.COM]
> >Sent: Wednesday, 21 July 2004 2:54 AM
> >To: ebXML BP
> >Subject: [ebxml-bp] [Fwd: [ebxml-msg] Status of MSH configuration by CPA
> and
> >MSH API]
> >
> >FYI: Questions to ebMS team, good insight Sacha.
> >
> >Sacha Schlegel wrote:
> >
> > >Hi ebXML Messaging Team
> > >
> > >I was wondering what the status of the following two questions are:
> > >
> > >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.
> > >
> > >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?
> > >
> > >Kind regards
> > >
> > >Sacha Schlegel
> > >
> > >
> > >
>
> *************************************
> Martin Sachs
> standards architect
> Cyclone Commerce
> msachs@cyclonecommerce.com
>
>
>
>
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]