Centralized Registry Discovery Mechanism

["Petit, John" <jpetit@kpmg.com>]

Scott,

Is this progressing? I have not seen any discussion about centralized
registry discovery on this or the other boards. I would be happy to help
this effort if needed. Has the idea of a registry CPP been broached to the
TP group?

I believe the "who" is quite important. Leaving it to unknown private groups
will dilute the usefulness. For example, in our home town, we have left the
yellow pages business to the private sector and the result is a dozen books,
with none giving a comprehensive listing! More than likely there are several
companies that want to cash in on this aspect of ebXML (perhaps even some
ebXML contributors) but I believe that leaving it to the general private
sector, and leaving this to be decided after May is a mistake. If there is a
private organization, be it UDDI or other, one should be chosen, the
registration process briefly outline, and that organization recommended in
the ebXML registration process description. If this includes a special CPP,
then it should be described and referenced as well.

-----Original Message-----
From: Nieman, Scott [mailto:Scott.Nieman@NorstanConsulting.com]
Sent: Tuesday, February 27, 2001 9:01 AM
To: 'Krishna Sankar '; 'Petit, John '
Cc: 'ebxml-regrep@lists.ebxml.org '
Subject: RE: ebXML and UDDI - Making the Whole Greater than the Sum


I don't disagree about the scope of UDDI vs. ebXML.  

From looking at our requirements statements, I do think that a fundamental
need is distributed registries.  We have that planned for the May release.
I believe the requirement is to be able to "publish" a query to a set of
distributed registries, and retrieve links back to the result set.  In doing
so, not all registries should execute each query, only the "types" of
queries that it knows it could potentially return a resultset.

In order to accomplish that, I believe that there needs to be a mechanism to
resolve registries via the "registry of registries" that John is suggesting.
Combine that with  pub/sub plumbing and I believe we are set.  I am
suggesting that a form of CPP for a given registry needs to be included in
the "registry of registries", perhaps including "types" of queries,
"subscriptions" (maybe not) etc.  Keyword is "perhaps" since this discussion
has yet to occur.

I don't care about the "who" aspect.  Just the "how".  Who hosts this is
another topic altogether.  Also, we need another acronymn for the "registry
of registries" if that is the architecture going forward.  I am having
trouble typing "registry of registries" over and over.

Is this the architecture?  Alternatives for debate?

This is parallel work that needs to be started soon, if not now.

Scott

-----Original Message-----
From: Krishna Sankar
To: Petit, John; 'Nieman, Scott'
Cc: ebxml-regrep@lists.ebxml.org
Sent: 2/27/01 1:28 AM
Subject: RE: ebXML and UDDI - Making the Whole Greater than the Sum

Guys,

	Aren't we missing the point ? UDDI is more into registering web
services -
a Technical discovery. The Yellow/White pages are more to find
addresses, et
al. You could argue that an ebXML registry can be registered as a
Registry
Web Service. But interoperability is not about registering registries -
at
least I do not see it that way.

	John, interoperability at the frameworks level is not analogues
to cross
entries in the registries. I see it as interoperability at the
API/Message
layer i.e. a framework issues rather than an implementation related
issue.
Your point is about actual physical registries and cross entries are
well
taken. But the concentration now should be one registry specification we
all
can write to.

	my 2 c

cheers

|-----Original Message-----
|From: Petit, John [mailto:jpetit@kpmg.com]
|Sent: Monday, February 26, 2001 10:34 AM
|To: 'Nieman, Scott'
|Cc: 'ebxml-regrep@lists.ebxml.org'
|Subject: RE: ebXML and UDDI - Making the Whole Greater than the Sum
|
|
|The only contents on the Registry of Registries would be pointers to
the
|ebXML registries and associated industry codes for those
|registries. Perhaps
|a CPP. If this is feasible, and desirable, then I would hope that ebXML
RAs
|are strongly encouraged to register this basic information within UDDI.
We
|are not talking about a great deal of data, so a centralized source is
|desirable for search engines and agents to "walk the web" looking for
their
|targets.
|
|-jp
|
|-----Original Message-----
|From: Nieman, Scott [mailto:Scott.Nieman@NorstanConsulting.com]
|Sent: Monday, February 26, 2001 11:21 AM
|To: 'Petit, John'
|Cc: 'ebxml-regrep@lists.ebxml.org'
|Subject: RE: ebXML and UDDI - Making the Whole Greater than the Sum
|
|
|John, thanks for bringing this up again.  I do agree that there needs
to be
|a mechanism as you describe, and I have "borrowed" your slide in the
past
|renaming it "DNS-like Registry of Registries".  Specifically,
|there needs to
|be a mechanism to 1) identify that a registry exists, and 2) identify
the
|types of requests that the registry will accept, e.g, specific types of
|queries, for a particular industry, (context?), etc.  I view the vision
of
|the ebXML Registry to be the "Napster of Registries" (without the legal
|issues of course), promoting peer to peer interactions between
registries
|and between businesses.  In my mind, the plumbing you describe is part
of
|the puzzle.
|
|Who will implement this?  That is another story altogether which there
are
|no immediate answers.  I think UDDI is also looking for a home.
|Does it have to be one centralized mechanism though?  Perhaps not.
|What are the contents of the registry of registry?  I suggest a
registry's
|CPP of its capabilities.
|Can every web site have its own ebXML registry containing its CPP and
|contents?  That could/ should be our vision.
|
|Scott
|
|-----Original Message-----
|From: Petit, John [mailto:jpetit@kpmg.com]
|Sent: Monday, February 26, 2001 10:36 AM
|To: 'ebxml-regrep@lists.ebxml.org'
|Subject: ebXML and UDDI - Making the Whole Greater than the Sum
|
|
|If this proposed UDDI/ebXML summit shows that we can interoperate with
UDDI
|then there are clearly many ways in which the two frameworks can
augment
|each other. One element of a global eCommerce framework that I have
been
|pushing within ebXML is the existence of a centralized mechanism that
will
|provide a comprehensive interface into the vast number of independent
and
|distributed ebXML registries that will spring up around the world. I
was
|hoping that OASIS would provide this "registry of registries" service
|initially to get ebXML going (see attachment). However, it  is not
clear
|what will happen to ebXML organizationally after May. There is a
|good chance
|that UN/CEFACT and OASIS will choose not to create a "registry of
|registries." If not, then perhaps UDDI can fill that role as they have
|proclaimed that they will be the global "yellow pages" (as well as
|white and
|green). While UDDI is not the ideal industry/vendor neutral
|organization, it
|is up and going and had gained significant momentum. So the question is
can
|UDDI act as the central registry of registries for ebXML? Will our
|taxonomies map to theirs?
|
|While we are hoping that the use of UUID mapping will allow agents to
link
|up various documents and information models within an industry
category,
|this depends on developers to put this together in an ad-hoc manner.
The
|looseness of the ebXML approach precludes assured, comprehensive
|searches in
|the early days.
|
|Cheers, John Petit
|Manager, KPMG
|XMLfs
|Office: 970 728 9468
|Mobile: 312 961 8956
|*******************************************************************
|**********
|The information in this email is confidential and may be legally
|privileged.
|It is intended solely for the addressee. Access to this email by
|anyone else
|is unauthorized.
|
|If you are not the intended recipient, any disclosure, copying,
|distribution
|or any action taken or omitted to be taken in reliance on it, is
prohibited
|and may be unlawful. When addressed to our clients any opinions or
advice
|contained in this email are subject to the terms and conditions
|expressed in
|the governing KPMG client engagement letter.
|*******************************************************************
|**********
|
|------------------------------------------------------------------
|To unsubscribe from this elist send a message with the single word
|"unsubscribe" in the body to: ebxml-regrep-request@lists.ebxml.org
|

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-regrep-request@lists.ebxml.org
*****************************************************************************
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized. 

If you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it, is prohibited
and may be unlawful. When addressed to our clients any opinions or advice
contained in this email are subject to the terms and conditions expressed in
the governing KPMG client engagement letter.         
*****************************************************************************