Hi all,
What I've been thinking is to share the same interface/protocol to do simple 
tasks on distributed CKMs like:
Adding an artifact (archetype, template, termset, terminology service, process 
definition, gui template, etc.), lets think only about archetypes for 
now.Updating an archetype (with version management)Listing all the 
archetypesListing all the archetypes for one RM type (i.e. composition, entry, 
action, etc.)Listing all the archetypes that archetype_id match a regexpListing 
all the archetypes that match some text (free text search)Retrieve archetype in 
ADL/XML/JSON/YAML by archetype_id

Ian, about the requirements you mention:
> Basic requirements
> 
> 1. Query across multiple repositories using multiple criteria, based
> on something similar to the CKM ontology.
For this I think something like DNS protocol will do the job 
(http://en.wikipedia.org/wiki/Domain_Name_System). DNS could do a distributed 
search by redirecting the query if some server doesn't have the answer. So, if 
we have a service to register artifacts on CKM servers (service 1. on the list 
above), with an "artifact registered notification protocol", and another 
protocol for "CKM server discovery", we could implement the distributed search.
> 2. Establish references to remote assets, almost certainly caching the
> referenced asset locally
This would be the a mix of "adding and artifact" and "artifact registered 
notification protocol".
> 3. Establish subscriptions to remote assets, to enable change notification etc
> And this would be included in the "CKM server discovery protocol", that could 
> defined like some services provided by the NDP protocol, using messages like 
> RA, NS, NA, ... to discover CKM servers to create a CKM network over 
> Internet: 
http://fengnet.com/book/CCIE%20Professional%20Development%20Routing%20TCPIP%20Volume%20I/ch02lev1sec5.html
 
I think some of these services could be found also in the ICMP protocol: 
http://www.networksorcery.com/enp/protocol/icmp.htm

Just to clarify my thoughts, I don't think we need a network protocol!!! I 
think we could create our protocols to handle artifacts in a distributed way 
reusing some ideas from those proven protocols that our machines run everyday 
to connect to the Internet and access distributed resourses.

How this stuff could work in reality?
We need a set of "root CKM servers", always online, that could answer our 
queries or redirect to some another server that could answer (like DNS).In 
those servers (could be only one, like openEHR.org CKM), other servers could 
advertise themselves to form part of the CKM network, this could be done like 
an ICMP or NDP router advertisement. Those servers could download also a list 
of servers currently connected to the network, and update the list anytime.The 
children servers could be not always online, so each entry on the root server 
registry should have a lifetime, that when reached, the entry is eliminated 
from the list (like in ICMP 
http://www.networksorcery.com/enp/protocol/icmp/msg9.htm ). This could trigger 
a notification to the other members of the network, to update their server 
list.When an artifact is added to a server, it should notify other servers in 
the network, so they could know what server has the original copy of the 
artifact, and maybe they can make a copy of the artifact that sould be 
read-only on those servers that cache a copy. The cached archetype could have a 
lifetime, that when reached, a new copy of that archetype should be downloaded 
from the original server, if the server is still online, or renew the lifetime 
if the original server is offline.Then a query received by any CKM could be 
responded or redirected to other server, and all servers in the network could 
keep up with all the archetypes created worldwide.

I don't know if this is crazy talk or if it's seems reasonable to you. Please 
let me know :D

Kind regards,Pablo.

                                          
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120202/3d5bc75e/attachment.html>

Reply via email to