Re: Resubmission of Distributed Registry Approaches.ppt

[Scott Hinkelman <srh@us.ibm.com>]

To add some additional clarity to my post regarding community-based ebXML
Registries,
the simple (recently discussed) pattern that could materialize here is to
register ebXML Registries in UDDI in order to
'find' ebXML Registries. Each community-based ebXML Registry would not have
to
know about every other one, would serve some appropriate user community,
and appropriately registered in UDDI.
Together, these registries can satisfy anyone from any sector querying the
combined model and obtaining meaningful
answers, as in a somewhat modified Klaus's statement, and relieves the
ebXML Registry from focusing on a federated query issue as
an immediate solution.

In fact, I see this combination as very complementary in scale and in
tolerance to change. UDDI
is likely to reflect replicated change in a relatively slow (~12 hours)
cycle but will scale in record content volume.
Non-replicated community-based ebXML Registries would likely reflect change
more quickly, and not need to scale
with volumes appropriate across all sectors. I also believe this two-tiered
approach sets direction on path for any
future ultimate integration.

Note that nobody is saying this is the *only* usage pattern, but leveraging
UDDI this way could satisfy what is required,
and *perhaps* even documented by May 15. If the workgroup leadership is
willing, this could be a topic for Friday's
call on how to proceed.

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



Scott Hinkelman/Austin/IBM@IBMUS on 04/03/2001 09:29:29 AM

To:   Lisa Carnahan <lisa.carnahan@nist.gov>
cc:   "Nieman, Scott" <Scott.Nieman@NorstanConsulting.com>,
      "'ebxml-regrep@lists.ebxml.org '" <ebxml-regrep@lists.ebxml.org>
Subject:  Re: Resubmission of Distributed Registry Approaches.ppt



I completely agree with Lisa's comments. Further, to add to her point 2), I
don't see OASIS, already operating their .org registry, or even CEFACT
(judging from Ray W's Vancouver comment about minimal resources) operating
some BIG registry. Do not under-estimate the operating costs. Some of us
have concluded that an instance of an ebXML Registry will most likely be
community-based, as Lisa well describes, unlike some global directory like
UDDI. That said, if you believe this to be the most likely topology, you
would agree as I do that Klaus's comment is misdirected.

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



Lisa Carnahan <lisa.carnahan@nist.gov> on 04/03/2001 09:05:34 AM

To:   "Nieman, Scott" <Scott.Nieman@NorstanConsulting.com>,
      "'ebxml-regrep@lists.ebxml.org '" <ebxml-regrep@lists.ebxml.org>
cc:
Subject:  Re: Resubmission of Distributed Registry Approaches.ppt



Hi Scott and All,

A few questions:

1. Is your slide showing that all queries intending to get back a
'federated' answer must use the BIG registry (I'm not typing 'registry of
registries' each time)?  Couldn't this be a source of bottle-neck?   Is you
model showing that a BIG registry exists within a given sector, or all of
ebXML?

2. Given that you have defined a BIG registry, is OASIS or UN/CEFACT going
to build/bless one?

I'm not significantly involved in any one specific industry sector.
However my impression from those that I deal with is that one distributed
model for registries is not going to satisfy them all.   With all due
respect to Klaus, I believe that the requirement of 'anyone from any sector
can query any ebXML registry and get back a meaningful answer (rather than
'not found here')'  is a bit much.  I agree with this as a goal when we
talk about a  given sector.  However, the decision of which distributed
model to implement should be left to those serving the given industry so
that it fits their business cases. (We can specify services to support
various models, however I don't know if it makes sense to mandate any one.)
Being part of a federation should be voluntary, not mandatory (unless it is
a requirement for a brand).   Once registries for industry sectors are
established we can discuss the need for a federation of BIG registries. I
view most of this as a policy issue and that if registries see a business
case for cooperating with each other, they will.

Having said this,  I agree with Mike Rawlins that given our time frame, if
we have to specify something then we could write a policy in the RIM that
for the intial phase, ebXML registries mat be found through the UDDI
mechanism.   I view most of this as a policy issue and that if registries
see a business case for cooperating with each other, they will.  We can
then revisit this in phase II, after we gain some experience in this area,
and see how registries are used, and the need for registry cooperation (or
ebXML policy).

Scott, we need to come to closure on this quickly.  If folks want to go
beyond the UDDI option (and I can't determine consensus either way) then
proposals that are ready to be dropped into the specifications need to come
forward ASAP.     Looking at the schedule, is it correct that we only have
until April 23rd?

--lisa

At 10:02 PM 4/2/01 -0500, Nieman, Scott wrote:

All,

Since no has replied to my powerpoint emailed earlier today, I have taken
the liberty to update it.  I have added a pass/fail acknowledgement back
from the registries to the registry of registries (RofR), and also another
potential approach involving client side filtering vs. putting the burden
on
the RofR.

I am still more in favor of server side filtering but am throwing this out
as another alternative to debate.

Regards,

Scott


Lisa Carnahan
National Institute of Standards and Technology
Information Technology Laboratory
100 Bureau Drive Stop 8970
Gaithersburg, Md. 20899
301-975-3362 voice
301-948-6213 fax
lisa.carnahan@nist.gov



------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-regrep-request@lists.ebxml.org