RE: [ebxml-cppa] A big issue

["Hayes, Brian" <Brian.Hayes@Commerceone.com>]

     I firmly believe that registries & repositories are an essential part
of the b2b architecture.  However, it's implementation can vary.  Global
registries/repositories are very nice; and enterprises are going to have
their own registries/repositories (I would recommend using them to cache
information from the public registries to improve performance).  Naturally,
enterprise local registries/repositories are needed in the abscence of
public/global registries/repositories.  These enterprise local registries
may be implemented using file systems, databases, LDAP, and any other
technology.
     Note that I'm not saying that the registries are the *center* of
operations.  I am saying that they are inherit to the problem being solved.
Of course, globally accessable ebXML compliant registries/repositories would
be very helpful.
     I agree with Chris' last paragraph about URI resolution and
registry/repository.  URNs carry important semantics (thus, I believe better
than UUIDs).  Registries/repositories will help enforce the semantics.

Cheers,
Brian


> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@sun.com]
> Sent: Friday, February 01, 2002 10:13 AM
> To: Duane Nickull
> Cc: Brian Hayes; CPPA
> Subject: Re: [ebxml-cppa] A big issue
> 
> 
> Duane,
> 
> I'm not convinced that a "registry centric view of
> operations" is necessarily a "good thing(tm)".
> 
> I believe that there are many who believe that
> the registry has a primarily a design-time usage.
> 
> That said, I believe that the appropriate usage of
> the UUID identifier of a BPSS instance would be
> with the xlink:role attribute, which appears to
> be absent from the xlink.grp definition.
> 
> I do feel strongly that a) the registry/repository should
> provide for URI resolution of artifacts stored within
> and b) that any runtime retrieval/resolution of
> artifacts such as the BPSS instance should be accessible
> via web protocols. I think that adding in the complexity
> of having to use a registry API.
> 
> Cheers,
> 
> Chris
> 
> Duane Nickull wrote:
> 
> > Guys:
> > 
> > I found something else that is contrary to establishing a Registry
> > centric view of operations.
> > 
> > In the 1.05 document, it states:
> > 
> > "7.5.4 ProcessSpecification element
> > The ProcessSpecification element provides the link to the
> > Process-Specification document that defines the 
> interactions between the
> > two Parties.  It is RECOMMENDED that this Business-Collaboration
> > description be prepared in accordance with the ebXML 
> Business Process
> > Specification Schema[ebBPSS]. The Process-Specification 
> document MAY be
> > kept in an ebXML Registry.
> > 
> > NOTE:  A Party MAY describe the Business Collaboration 
> using any desired
> > alternative to the ebXML Business Process Specification 
> Schema. When an
> > alternative Business-Collaboration description is used, the 
> Parties to a
> > CPA MUST agree on how to interpret the Business-Collaboration
> > description and how to interpret the elements in the CPA 
> that reference
> > information in the Business-Collaboration description.  The affected
> > elements in the CPA are the Role element, the ActionBinding 
> element, and
> > some attributes of the BusinessProcessCharacteristics element.
> > 
> > The syntax of the ProcessSpecification element is:
> > 
> > 	<tp:ProcessSpecification 
> >     tp:version="2.0"
> >     tp:name="PIP3A4RequestPurchaseOrder" 
> >     xlink:type="simple" 
> >     xlink:href="http://www.rosettanet.org/processes/3A4.xml" 
> >     <ds:Reference 
> ds:URI="http://www.rosettanet.org/processes/3A4.xml">
> >         <ds:Transforms> 
> >             <ds:Transform 
> > 
> ds:Algorithm="http://www.w3.org/TR/20002001/REC-xml-c14n-20010315"/> 
> >         </ds:Transforms>
> >         <ds:DigestMethod 
> >             ds:Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
> >         
> <ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:DigestValue>
> >     </ds:Reference>"
> > 
> > <SNIP>
> > 
> > I believe that this is not the best solution.  The BPSS should be
> > referenced via its' UID, not an xlink.  This allows applications to
> > recognize it based on that unique value.  At Design time, this is a
> > valuable feature.
> > 
> > A fixed link is also not the best way to do anything.  Links break. 
> > ebXML has designed a Registry for this purpose.  
> > 
> > Another problem with this is that the Discovery phase 
> relies on this UID
> > for discovery. 
> > 
> > I strongly advocate replacing this with a UID.  Let the physical
> > location reside in the "extrinsicURI" attribute of the RIM 
> where it was
> > designed to go.
> > 
> > Duane Nickull
> > 
> > 
> 
>