ebxml-tp message


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

 


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: RE: Special note for CPP members


> The problem many people are starting to see is that Vendor A and vendor
>B need to have a definition of what the correct CPA should look like
>given two CPP's as input.  More than likely,  the two tools will produce
>two different CPAs unless there is a specification or set of rules
>(perhaps in the non normative section as you suggested) to guide the
>vendors.  

1. A CPP is a collaborator's 
advertized capabilities for 
conducting BPs. CPP software
is not required to advertize
all capabilities. So, each
collaborator may posess 'knowledge'
of its capabilities beyond what is
in its CPP and that knowledge may
permit it to propose a CPA that would
not be proposed if an agent were restricted
to using just the information visibly
advertized in two public accessible CPPs. 

2. Putting point 1. aside for the moment, suppose
the CPPs are the full capabilities.
Without knowing the specifics of what BP(s) A and B as
collaborators want to do together, two CPPs could 
only be merged
to obtain a 'maximal' match of what collaborations
they could do together. The actual CPA would presumably
reflect the business context between A and B and could
be a subset of collaborations that are technically feasible.

3. Putting aside points 1 and 2, there is hope that we
can eventually provide
non-normative comments on computing the maximal
match of two CPPs by explaining  how to check  (1) that
the roles complement, (2) that an interoperable transport
exists, (3) that some compatible security solution exists, 
(4) that matching capabilities exist for document generation/parsing
(packaging and schema/dtds match), and (5) that the grabbag of
other factors  (reliable messaging, signals, timeouts, etc
etc) are available or not. It seems likely that some
human fine-tuning will be needed for the end-game, but
the configuration decisions faced by the user may be
reduced dramatically in complexity. 
So even without complete automation,
configuration should be easier for end users. 
I think this is as ambitious as the current
deadline admits us to get. And we are still quite
a bit off on getting this much finished.


>It is the "same procedures" wording that causes the majority
>of concerns.  What are those "same procedures" and where do I find them
>if I am building a CPA negotion engine?



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC