PURD/PERD (was Re: ebXML registry and UDDI comparisons)

[Paul Denning <pauld@mitre.org>]

At 10:54 AM 2005-06-22, Farrukh Najmi wrote:
>Imagine now, given that any two ebXML Registries can organically federate 
>together and a user can query the federation of registries as if it were a 
>single registry,
>that our WSDL Discovery queries can now search for WSDL across any number 
>of registries and return a unified result. And all this with very fine 
>grained ability to do access control.
>
>In a nut-shell, ebXML Registry is about "Enabling, Secure, Federated 
>Information Management".

Federation could be an advantage of ebXML over UDDI.  I am still trying to 
grok what is meant by "federation" in ebRIM/ebRS and how it might work.

One thing I would like to see is a standard profile or TN/BP (call it what 
you like) for how to register a registry in UDDI or ebXML Registry.

I like to think of UDDI as a universal starting point in my quest to 
discover stuff about services (not limited to "web" services).

First there is the issue of how to bootstrap to a UDDI server, preferably 
automatically (with ubiquitous support in the OS, like the OS supports DNS 
resolvers today).
It could be DHCP, some sort of DNS query (e.g., DNS-SD), JXTA, uPnP, 
WS-Discovery, ....

Once you have your UDDI server, you may want to locate other UDDI or ebXML 
servers to dynamically form a federation.  (Lets not get into trust issues 
yet; there could be a human in the loop that approves use of the other UDDI 
servers discovered from the initial server.)

So how do you look in UDDI to find other UDDI servers or to find ebXML 
Registries?

Enter PURD and PERD.

PURD = Private UDDI Registry Discovery
PERD = Private ebXML Registry Discovery

I have been tossing around the PURD idea for years, and have some TN text 
drafted (mostly addressing UDDI v2; need to address UDDI v3).

For ebRIM/ebRS, I have commented on the UDDI TN's lack of keyValues for 
discovery of ebRS endpoints; it only accommodates three values:

ebXML:CPPA ebXML Collaboration Protocol Profile and Agreement
ebXML:MS ebXML Message Service
ebXML:BPSS UN/CEFACT - ebXML Business Process Specification Schema

see http://www.oasis-open.org/committees/uddi-spec/doc/tns.htm#regForebXML 
(section 2.2.3)

I don't know why they did not include

ebXML:RS

in the list of valid keyValues.  It is essential for PERD.

Essentially it would be like discovering any SOAP service.  Add a tModel 
with wsdlSpec in the categoryBag that points to the WSDL (for UDDI, or ebRS).
Add that tModelKey to the technical fingerprint of the bindingTemplate, and 
voila!

To find UDDI endpoints, you do find_binding with a tModelBag that includes 
the key for your UDDI or ebRS tModel.  With UDDI v3, you also have a 
categoryBag in the bindingTemplate where you can use a taxonomy to express 
that the binding is an <x>, where <x> is UDDI or ebRS.  (Details of exactly 
which taxonomy to use is left for another time).  I think the pattern to 
agree on is using a tModelKey in the technical fingerprint of the 
bindingTemplate.

Once you have found the bindings, you probably want to do more drill-down 
(or drill-up to go up to the service or business level for the 
binding).  There may be other things to search on, for example, whether the 
ebRS endpoint adheres to a particular profile of ebXML Registry (e.g., OGC 
CSW).  The pattern would be the same: define a tModel, add it to the 
technical fingerprint of the binding.

A few more UDDI thoughts before Iose them:

1.  nodeID should be a URI

and

2.  we need to agree on a way to identify the "registry" for which the node 
is a member; we should not assume single node registries.

I can search UBR using the PURD technique.  I did it a long time ago and 
found only 5 businesses.  Four of the 5 were UBR Nodes, but there is no 
good way to tell that those 4 nodes are part of UBR (the logical 
registry).  An inquiry to any of the four should return the same results 
(+/- depending on replication latency).

Paul