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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

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


Subject: Re: two questions concerning cpp/cpa


Hi Markus

> ive got two questions concerning ebxml...maybe someone can help me.
>
> 2nd: how exactly are CPAs created? i know that you need two or more cpps
> and
> i have a figure where it is explained. but i guess the figure is quite
> theoetic...how is it managed in the daily doing? how much is automated and
> how much has to be done by a human being?

See also Matthews and Dales email.

I have been interested in the automated way of getting from two CPP's to
one CPA (see http://www.schlegel.li/ebXML).

The CPA formation process
-------------------------

This process is called CPA formation process. This process is composed of
the CPA composition process and the CPA negotiation process.

If your look at the ebXML framework, it is important to get from two CPP's
to a CPA, somehow. The more you can automate of that process, the easier
for you.

The CPA composition process
---------------------------

The CPA composition process takes the two CPP's and starts to match them.
Checks each element and attribute of each CPP's and if they match, the
element of attribute go into a (temporary) CPA template. If they do not
match, they go into a gap list (the problem list). An algorithm can check
certain elements and attributes easily (for example a transport protocol
name must be equal, HTTP must match with HTTP, not with FTP), other
elements and attributes are a bit difficult to check (for example the
roles, as they are specified in another Business Process XML document).

An algorithm can do some work for you, but you might end up finishing the
CPA template.

What you also have to do is to fix all serious conflicts. Serious
conflicts can indicate, that the two CPP's are just not compatible with
each other (for example they are used for different business processes).
Other not that serious conflicts can be fixed. For example if one party
uses HTTP and the other party uses FTP as transport protocol, one party or
both have to change their transport protocol. It does not matter which
party, in the end, both transport protocol have to be the same, no matter
what protocol it is.

The CPA composition process ends with a (temporary) CPA template and
possibly a gap list.

As you might know, a CPP can have lots of elements and attributes, so
there is quite a bit of room for conflicts. For example can you have more
than one ChannelID elements in your CPP. You list more than one ChannelId
to indicate your ability to support several different delivery channels.
The other party might also have a list of different ChannelId elements. In
the CPA on the other hand, there shall be only one ChannelId element.
Somehow, you have to get from lots to one. This is a typical task of the
CPA negotiation.

In the advanced scenario (as described in the Automated Negotiation of CPA
specification with version 0.10! watch out, might change again), each
party has a Negotiation Descriptor Document (NDD) associated with its CPP.
This document allows a party to further set options and values to elements
and attributes of their CPP.

In the advanced sceanrio, the CPA composition not only has to provide a
(temporary) CPA template but also a new NDD, just for that new CPA
template. This new NDD will have a list of items, which are negotiable in
the CPA negotiation.


The CPA negotiation process
---------------------------

This is the advanced (future) sceanrio.

The CPA negotiation starts with one party sending the (temporary) CPA
template and a new NDD for that CPA template to the second party. The NDD
lists which elements and attributes of the CPA template the parties have
to negotiated. The first message is called the initial offer. The CPA
negotiation continues with counter offers following counter offers, until
all elements and attributes (which are listed in the NDD) of the CPA
template are set (negotiated). Then the CPA template will become the CPA.

Thats the CPA which both parties will deploy.

There is lots going on and the Specification for the CPA negotiation is
still under development. Please have a look at
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebxml-cppa and
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebxml-cppa-negot

The more you can automate, the better. If there are serious problems in
the CPA formation process, then the best help is personal (human) help.

Kind regards.

Sacha

> thank you very much and have a nice day
> markus
>
>
> The ebxml-dev list is sponsored by OASIS <http://www.oasis-open.org> The
> list archives are at http://lists.ebxml.org/archives/ebxml-dev/
> To subscribe or unsubscribe from this list use the subscription manager:
> <http://www.oasis-open.org/mlmanage/>
>
>
>
>
> !DSPAM:402a4d73174721922251030!
>
>
>



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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC