DNS like distributed search for RegistryObjects

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

Dear Colleagues,

Attached is an email from John Hardin whom many of you may know already.

John's email has reminded me of the the need for the TC to define a DNS 
like distributed search for RegistryObjects.
He shares a very real use case from Electronic Patient Records world on 
how important this functionality is.

I share this sense of importance and would like to propose that we as a 
TC consider starting a work item focused on
defining a normative spec addressing this requirement. As a starring 
point we could study past work by Matt MacKenzie on the subject:

http://www.oasis-open.org/committees/download.php/6852/tn-ebreg-dnssd-02.html 


What do Matt and TC colleagues think?

-- 
Regards,
Farrukh

--- Begin Message ---

• From: Farrukh Najmi <farrukh.najmi@sun.com>
• To: john@maphin.net
• Date: Thu, 13 Apr 2006 08:04:10 -0400

John Hardin wrote:

> Farrukh and all on the ebXMLrr list -
>
> As most of you are aware, the healthcare industry is moving rapidly 
> towards implementation of a national health information network. All 
> indications point to organic growth, with small regional or affinity 
> based domains springing up across the country, where electronic health 
> records information will be stored for individuals. The best models 
> (particularly from HIMSS and the Integrating the Healthcare Enterprise 
> groups) are building the core framework with ebXML reg/rep at the 
> heart of the storage mechanism.
>
> The need to locate complete records for persons who reside in multiple 
> places, or who have moved, vacation, etc. is a real use case, and the 
> condition will result in storage of an individuals' information in 
> multiple domains. This will create the need for federation across the 
> entire ecosystem of domains, in realtime.


This is very well put John and in the fewest words I have seen to 
describe it :-)

>
> Models for federated patient identity based record locator services 
> are being floated. 

I would be grateful if you can send me any links to your favorite model(s).

> This looks to me like the DNS hierarchy, where there will be a patient 
> locator query broadcast across the entire trusted ecosystem of 
> registries.


The thinking in the ebXML Registry TC is along similar line. Though I 
must say we are behind on defining a formal spec for this. Here is a 
draft document by Matt MacKenzie on the subject:

http://www.oasis-open.org/committees/download.php/6852/tn-ebreg-dnssd-02.html

I think that regrep TC needs to define one of the following as a 
normative spec:

1. How to use existing DNS to find RegistryObjects in any registry. If 
this is possible it would be ideal because it leverages existing 
infrastructure.

2. Define a distributed search mechanism that is modeled after how DNS 
works

I will lobby for this work to be made a priority in the regrep TC as I 
see it as very important to our federated features.

If any one in the community has skills in this area and would like to 
contribute to the spec work please contact me.

>
> I am curious about the OASIS or ebXMLrr communities' experience in 
> this sort of large scale test, pilots or proofs of concept. Has there 
> been any work that we can reference to understand the characteristics 
> of mass traffic across an ecosystem of dozens or hundreds of federated 
> registries?


I am personally not aware of any significant examples of federated 
registries thus far. I am told that KIEC in Korea has done some testing 
on federated registries. Government of Canada and Government of Ontario 
had plans to start with a 2-3 registry federation. I have not heard 
anything definitive on it yet either. Maybe someone else has more 
information?

> Any ideas about performance or gotchas in implementing this type of 
> infrastructure would be very helpful.


Currently, our federated query mechanism works only within a group of 
registries declared as a federation. A query marked as a federated query 
to any federation member is dispatched in parallel to all other members 
by the first member registry which then waits for all the results and 
collates them and return the unified result. This in itself scales 
because queries are processed in parallel across multiple servers. 
However, we have not done any calculations on how things scale if every 
query to every member is a federated query. That scenario can be avoided 
if there is some control over when a federated query is used vs. when a 
non-federated query is used.

There is much more to this issue as you know. Lets work together in 
regrep TC to move this support for these requirements to completion. We 
can implement the draft specs as they emerge in freebXML Registry.

Thanks for reminding of this important issue.

-- 
Regards,
Farrukh

begin:vcard
fn:Farrukh Najmi
n:Najmi;Farrukh
email;internet:farrukh.najmi@sun.com
tel;work:781-442-9017
url:http://ebxmlrr.sourceforge.net/tmp/DSCN0278.JPG
version:2.1
end:vcard

--- End Message ---

begin:vcard
fn:Farrukh Najmi
n:Najmi;Farrukh
email;internet:farrukh.najmi@sun.com
tel;work:781-442-9017
url:http://ebxmlrr.sourceforge.net/tmp/DSCN0278.JPG
version:2.1
end:vcard