[
Lists Home |
Date Index |
Thread Index
]
Hi Bry
See my comments below.
On Tue, 2004-07-13 at 10:52 +0200, bry@itnisk.com wrote:
>
> Whenever one examines one of the ebxml specs or reads an article on the subject
> there is likely to be a reference to how edi had problems with being accepted
> because it was too complex, but luckily ebxml, being based on xml, solves all
> this. A very suspect class of assertion it seems like to me. I'm wondering if
> anyone who has familiarity with these technologies can clarify exactly how and
> in what ways ebxml reduces the complexity of edi.
>
> Basically my understanding is that ebxml just wrapped the edi model in xml, so I
> have a hard time seeing how it could be simpler.
>
> Also am wondering about CPAs in Ebxml, it strikes me that this process could
> actually be somewhat onerous, does anyone know of any case studies etc. on
> problems with making CPAs between two companies?
>
In my research (masters degree) I am/was looking at the "ebXML
Collaboration Protocol Agreement formation process".
This is the process to get from two ebXML Collaboration Protocol
Profiles (CPP) to a Collaboration Protocol Agreement (CPA).
This process can be divided into 2 subporcesses:
1) The CPA (template) composition
2) The CPA negotiation
Some more comments on these two processes:
1) CPA composition
------------------
The algorithmic CPA composition process is described in the ebXML CPPA
Specification in Appendix E. Basically a tool reads two CPPs and checks
their XML elements and attributes to make sure they match. Matching
elements and attributes go into a new CPA template. Problematic elements
and attributes go into a gap list (a problem or conflict list).
So this algorithm can check two CPP's pretty good and finds
inconsitencies in the two input documents. The CPP describes how a ebXML
Business process for example is technically realised. For example the
CPA composition algorithm has to check if the selected transport
protocol of the two CPP's is the same, that the version of the transport
protocol is the same etc. Also such an algorithm has to check that one
party sends a business document and that the other side can receive that
business document.
One important part is the business process which is referenced in the
two CPP's. Bascially if they reference a different business process the
two CPP's are incompatible. There is/was a research project "Matching of
ebXML Business Processes" from Dennis Krukkert, Version 0.31, Status: In
Progress which tried to look at two different business process and to
evaluate if even two different business process are somewhat compatible
(some comments here[1]).
Concerning the gap list ... these are conflicts which most likely have
to be solved by a phone call, or meeting. So no full automation here,
BUT a way to look at 2 CPP's and create a CPA template and a gap list.
So this is a start.
2) CPA negotiation
------------------
There is a subcommittee of the OASIS CPPA technical committee looking at
the automated negotiation of a CPA. The "Automated Negotiation of CPA"
specification of that subcommittee has version 0.10 (so still early
stage).
This specification introduces the CPA negotiation. Each CPP has already
a limited set of negotiation capabilites, such as listing alternatives.
Eg. one party can list several supported ways to deliver documments but
in the end (in the CPA) two parties select only ONE way to deliver
documents.
This specification introduces Negotion Description Document (NDD) which
are associated with a CPP or a CPA template. An NDD lists elements and
attributes of a CPP or CPA template which can be negotiated. In the CPA
composition process these new NDD docuemnts are included to maybe find a
solution of problems that would go into the gap list otherwise. The CPA
composition tool will have to merge the two NDD's of the input CPP's to
a NDD for the CPA template.
This specfication does further introduce the CPA negotiation. In the CPA
negotiation one party sends a CPA template (from the CPA composition
tool) as well as the NDD associated with that CPA template to the other
party. This is called the "initial CPA offer". The second party then has
3 options:
o reject intitial offer (results in a failure of the negotiation)
o accept intitial offer (if there are no open issues the CPA template
will become the final CPA)
o send a counter offer.
The two party's can send counter offers back and forth until, hopefully,
they reach a final CPA.
Please remember that the CPA negotiation is a negotiation on a technical
level (we use http version 1.1 as transport protocol) and not on a
business level (eg if you buy within 5 days you get 10% discount).
This negotiation process is itself a collaborative business process and
is described as an ebXML collaborative business process. The
sepcification does provide the ebXML Business Process XML instance
(negotiation business process), a CPA Skeleton, the structure of
negotiation messages, the negotiation protocol and negotiation rules.
Actually the specification DOES provide the infrastructure to negotiated
a CPA. Unfortunately the specification DOES NOT provide negotiation
algorithms or negotiation strategies how to actully negotiate over those
elements and attributes listed in the NDD.
Thoes negotiation algorithms and strategies have to be provided by
implementors. More input and research in this area is necessary.
Knowledge from the negotiation filed of Artificial Intelligence and Game
Theory should be evaluated and/or applied.
Summary:
--------
It is possible to algorithmically create a CPA from two CPP's. The
completness of the resulting CPA is based on the quality of the CPA
composition tool and the complexity of the input CPP's.
The CPA negotiation will allow parties (or their negotiation systems) to
negotiate a CPA but more work and experience is necessary to get this
happen.
The final thesis of the research is not out yet but the research is
done. Please find more info at [2]
Kind regards.
Sacha Schlegel
[1]
http://www.oasis-open.org/apps/group_public/email/ebxml-cppa-negot/200405/msg00024.html
[2] http://www.schlegel.li/ebXML
>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
|
