[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-cppa] The importance of the CPA
Thanks to Dale and the CPPA TC to invite me to todays meeting to discuss the idea of a ebXML CPPA TC Technical Note (TN) titled something like: "Using ebXML Registry to Manage CPP/A Artifacts " Following are some specific use cases that could be addressed by the proposed TN: -CPPs and CPAs automatically get validated upon submission to registry via business rules defined by the proposed TN (e.g. role MUST be Buyer, Seller or Intermidary - just a poor example to illustrate the point). The CPP submission is rejected if validation fails. The business rule could be whatever you want it to be and is not simply XML schema validation. -CPPs and CPAs automatically get cataloged upon submission where selected content in CPP or CPA is converted into metadata as specified by the TN. For example, this could be used to it could be automatically classify a CPP by its supported Roles and enable queries like: "Find me all CPPs where the role is 'Buyer'". -Discovery of CPP and CPA can be supported via custom queries defined by the TN. Example is, find me all Plumbing Suppliers in North Dakota. -Discovery of BPSS related to a CPA or vice-versa -CPP and CPA can be automatically versioned in a controlled way. Version management is handled by the registry. -Relationships can defined between Organizations and the CPPs and CPAs associated with them -Interested parties may be automatically notified when a CPP or CPA they are interested in, changes in some way (submitted, updated, approved, versioned, deprectaed, undeprecated, deleted, used). For example an interested party may be notified whenever a CPP for a Buyer in Auto industry is published. -Complete access control can be defined for CPPs and CPAs managed by the registry. This supports Role Based Access Control where roles may be defined by the TN or partners. -All CPP and CPA are available over an HTTP and SOAP interface (modulo access control) in a federated environment The above list can provide a basis for our discussion on the proposed TN in today's meeting. Look forward to meeting you all today. Thanks. ebXML Registry Links: Suggested minimal reading order is: [6], [10] and [9]. [6] is a good short reading to catch up on ebXML Registry [10] is a good source to see how to map between a domain specific model and ebXML Registry [9] is similar in concept to the proposed TN [0] [Ann] freebXML Registry version 3.0-alpha2 release http://sourceforge.net/forum/forum.php?forum_id=385589 [1] freebXML Registry http://ebxmlrr.sourceforge.net [2] Reference Deployments of freebXML Registry http://ebxmlrr.sourceforge.net/aboutFAQ/About_freebXML_Registry.html#Deployments [3] ebXML Registry 2.1 Specifications (Approved OASIS and ISO Standard) http://www.oasis-open.org/committees/regrep/documents/2.1/specs [4] ebXML Registry 2.6 Specifications (Latest preliminary 3.0 drafts) http://www.oasis-open.org/committees/download.php/8475/ebRIM-2.6.doc http://www.oasis-open.org/committees/download.php/8476/ebRS-2.6.doc http://www.oasis-open.org/committees/regrep/documents/2.5/specs [5] ebXML Registry Technical Committee http://www.oasis-open.org/committees/regrep/ [6] Web Content Management using ebXML Registry (XML Europe 2004): http://ebxmlrr.sourceforge.net/presentations/xmlEurope2004/xmlEurope2004-webcm-ebxmlrr.ppt http://ebxmlrr.sourceforge.net/presentations/xmlEurope2004/xmlEurope2004-webcm-ebxmlrr.sxi http://ebxmlrr.sourceforge.net/presentations/xmlEurope2004/04-02-02.pdf [7] Java API for XML Registries http://www.jcp.org/en/jsr/detail?id=93 [8] LDAP, UDDI and ebXML Registry feature comparison matrix http://ebxmlrr.sourceforge.net/tmp/Registry_Capability_Matrix.html [9] Using ebXML Registry to Manage WSRP Artifacts http://www.oasis-open.org/committees/download.php/7538/wsrp-pfb-ebxml-tn-draft-05.pdf [10] ebXML Registry Tutorial (Draft) http://ebxmlrr.sourceforge.net/tmp/regrep-tutorial-draft-04.pdf -- Regards, Farrukh Farrukh Najmi wrote: > Sacha Schlegel wrote: > >> Hi CPPA team >> >> Working with a real world commercial ebXML system it becomes obvious >> that the CPA becomes a very very important document for runtime. The >> ebXML Message Service Handler runs based on information found in the >> CPA. If ebXML collaboration systems support collaborative business >> processes, they will use the ProcessSpecification element of the CPA. >> So the CPA is the central document for the ebXML runtime environment. >> >> To me the current most important job is to make sure that a CPA >> instance is correct. >> >> It is not sufficient that the CPA passes the ebXML CPPA schema >> validation. >> >> I start to call these additional test "CPA integrity" tests. >> >> o One example is, that the value of the OtherPartyActionBinding must >> be present in the other party Info element as a ThisPartyActionBinding. >> >> Was there ever an intention of this TC to have other normative >> deliverables than the CPPA schema? >> >> I think of normative Schematron rules. Or is the intention to leave >> this to the implementors. A public place for core normative "CPA >> integrity" rules would foster ebXML collaboration systems >> interoperability. >> >> What do people think? >> >> >> > Hope you dont mind an observer to respond. > > Such validation rules are exactly what can be enforced when the CPA is > maintained within an ebXML Registry. The registry supports Content > specific validation of arbitrary content via pluggable Content > Validation Services. > > I have long hope that the CPPA team would define a TN titled something > like "Managing ebXML CPP/A in an ebXML Registry". Such a TN would > describe the specific validation rules that must be enforce when a > CPP/A is submitted to the registry. A CPP/A Validation Service could > be defined using the TN and registered with the ebXML Registry. When > someone submits a CPP/A the registry automatically runs it through the > CPP/A validation service and decides whether it passes or fails. If it > fails then the request is rejected. If it passes then it is stored in > the registry. > > Another thing the TN could describe is CPP/A Cataloging Service. Such > a Service would automatically convert selected CPP/A content into > metadata. For example, it could look at the <cpp:Role> element (not > sure if that is still the right name) and use it to automatically > classify the CPP as Buyer, Seller, Intermediary or whatever based upon > a canonical ClassificationScheme specified by the same TN. > > The TN could also describe standard parameterized stored queries such as: > > -Find me all CPPs for Buyers that support specified BusinessProcess. > > If all this was defined in such a TN then a project like freebXML > Registry could support the TN functionality out-of-the-box within the > ebXML Registry or as a pluggable module. > > The neat thing about all this is that the ebXML pieces work together > where the Sum of parts is greater than the whole. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]