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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Edi complexity, does ebxml really reduce it?

[ Lists Home | Date Index | Thread Index ]

Thanks, i actually found a paper by you on the subject via google,  your  link
#2 looks especially promising. 





Quoting Sacha Schlegel <sacha_ml@schlegel.li>:

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








 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS