Re: Distributed Registry Proposal Approach

[Mike Rawlins <rawlins@metronet.com>]

Hello again,

I'll stick my nose in again since it looks like Farrukh still feels his question
isn't getting answered, and some of the other messages still seem not quite on
track.  My statements here reflect my own views only and should not be taken to
represent the view of the Steering Committee.

It seems to me that the way Farrukh has laid out the "use cases" in the attached
message much more describes 3 different *solutions* to one requirement than three
different *requirements*.   As I understand it, the simple requirement is that a
client should be able to go to *one* entry point and find whatever is needed,
regardless of where it is registered or stored.   I think that is all that StC
cares about, and not *how* you do it.

As to a previous question that was raised about the business need for a distributed
registry architecture - I think that's a very good question, but this is probably
not an appropriate time to ask it.  That requirement in the Requirements Spec came
from the R&R team, so I will defer to Mr. Nieman to answer it if/when he has time.
All I know is that you have specified how a single registry works but that your
requirements and architecture assume that there will be several registries.
Without specifying how they are going to work together you have an incomplete
solution.

I suggest that for phase 2 you can revisit and further analyze your requirements
and architecture as deeply as you feel necessary.  However, for phase 1 my opinion
is that you have the following fairly simple requirements:

1)  Specify how someone is going to be able to find/manipulate the information they
need in an environment where there is more than one ebXML compliant registry.

2)  Do it in a time frame and in a fashion appropriate for May approval.  I add the
"in a fashion appropriate" to indicate that you should be extremely cautious about
adding complex new functionality since there will not be sufficient review cycles
to make sure that you get it right.

Specifically regarding UDDI, my proposal that you use UDDI is very much related to
my qualification in #2.  It is available now and all you have to do is to say how
you are going to use it.  I personally don't think you have time to invent anything
new.  In the long term it may not be a best fit or even a very good fit - I don't
know, I'm not an expert in that area.  But right now the long term is much less a
consideration than getting *something* done in the short term.  Without *anything*
to satisfy requirement #1 you don't have a solution.

I have some comments in-line below regarding your particular solutions, but they
are incidental to my comments above.

Regards,

Mike

Farrukh Najmi wrote:
...

>
> 1. Registry of Registries
> ----------------------
> The use case is that the user goes to a (or the) registry of registries and
> discovers the registry that is likely to have the kind of content they care
> about. For instances an automotive buyer may search for automotive registries.
> Once they find an appropriate registry they go to it and discover potential
> parties.
>
> The team felt this option may be doable within our time constraints. John Petit
> took an action item to make a proposal to the team.

Feeling that you *may* be able to do it within the time constraints does not mean
that you *can*.  To satisfy the requirement you need to pick something that you
*can* do.  Negative:  It is only a partial solution since some organizations may
not fit neatly into one category and therefore may either be hard to find or else
may need to be listed/hosted in several places.

>
>
> 2. Federated Registries
> ---------------------
> The use case is that a user sends a federated query to a group of registries
> that have voluntarily united in a federation based on some common purpose or
> specialization. A federation may be viewed by the client as a single logical
> registry. A federated query from a client to any federation member produces a
> unified response from the members of the federation as if they were logically
> one registry. Thus the user can search multiple registries in a federation with
> a single federated query.
>
> Although there is a proposal in this area, the team felt this may be better
> left for phase 2.

Better left for phase 2 since you don't have time for it in phase 1?  I can't argue
with that at all.  I think it still has the same negatives as #1.

>
>
> 3. List *ALL* Businesses in UDDI with pointer to ebXML Registry for Details
> -------------------------------------------------------------------------------
>
> The use case is that every business that is in an ebXML registry is also in the
> UDDI registry. The user discovers it in UDDI and then using some handle in UDDI
> to the ebXML registry goes to the ebXML registry for the details. Note that
> this use case is different from registry of registries since what gets
> discovered is the business and not the registry. The registry is just an
> association from the business that was discovered.
>
> This use case generated the most confusion. The team felt that this use case
> essentially makes the ebXML registries, classification and discovery not get
> used since *ALL* discovery to find the business happens in UDDI. If we did this
> what would have been the point of building a substantial classification and
> discovery mechanism in our registry. The team agreed that this option did not
> make sense.

You don't say whether or not you agree with the suggestion that you *can* do this
in time for May approval.   I do, however, agree with your assessment of the long
term negatives.

Unless you can get the Exec and StC to compromise on your satisfying the
requirement (which I think is unlikely), you are going to have find the compromise
you can best live with.  Unfortunately, there isn't time for perfection.  You have
to settle for "good enough".

--
Michael C. Rawlins, Rawlins EC Consulting
http://www.metronet.com/~rawlins/