Re: [regrep] service discovery, finding an object's registry with only an ID...

Matt,

 

Well almost.

 

I've always viewed this as a directed search via 
classification and 

taxonomy tools - with linking and 
switching.

 

There is in fact a good example of this approach in 
the OASIS BCM

specifications.

 

So once you initiate a search for what you need - 
you actually enter

a directed response tree with agent smarts - to get 
you to the right

place - via prompts / decisions / selections - from 
what the registry

knows about the domain you are 
querying.

 

That probably all sits neatly above the middleware 
glue you are

probably talking about - but is vital in ensuring 
the right 'docking'

occurs.

 

DW.

  
----- Original Message ----- 

  
From: 
  Matthew MacKenzie 
  

  
To:  
  

  
Sent: Sunday, April 18, 2004 11:47 
  AM

  
Subject: [regrep] service discovery, 
  finding an object's registry with only an ID...

  

With ebR being the backbone for our version of what Service 
  Oriented Architecture is, it will become increasingly important to make 
  resolution of registry services something that can be done with absolutely no 
  initial software configuration. 

Many years ago, the internet community 
  realized that /etc/hosts or lmhosts files would not be a scalable way of 
  aliasing services and making applications impervious to hardware change and 
  movement. DNS was born as a result of that. Now, I cannot imaging the internet 
  without DNS. 

Fairly recently, some people at Apple Computer published 
  an Internet Draft, titled "DNS-Based Service Discovery" (DNS-SD). Its goal is 
  to define an interoperable way to find out about things in the application 
  layer from DNS. DNS-SD words with standard unicast DNS, so that means the well 
  established, tested and deployed DNS resolver libraries on every platform can 
  be leveraged for service discovery. DNS-SD relies on SRV and TXT records. To 
  find registry services in a given domain, a query against SRV records may be 
  made. Extended info about how to build a registry URL would be embedded into a 
  TXT record.

Sample Session

Step 1:
SRV query -> 
  _ebr._tcp.adobe.com
Response: 0..n PTR records

Step 2:
Given 
  returned PTR records, select one. Not sure if there should be a selection 
  criteria.

Step 3:
Interrogate TXT record from selected PTR to obtain 
  HTTP-binding info. TXT record may contain stuff 
  like:
Hostname=foo.adobe.com, Port=9080, 
  HBindPrefix=/ebxml-registry/http-binding

Step 4:
Do something 
  against the registry.

The session above illustrates more of an 
  'intra/extranet' model of finding a certain type of service. It would be 
  possible to use a central DNS service to allow applications to resolve 
  UUID/IDs into fully qualified URIs, 
  e.g.

urn:dnssd:oasis:ADBE:6677-999-888j-jhhh

The reason for 
  sending this message to this list is to solicit interest in this concept. If 
  others are interested, I would like to prepare some sort of proposal for the 
  3.0 timeframe.

Comments?

___________________________
Matthew 
  MacKenzie
Senior 
  Architect
IDBU Server Solutions
Adobe Systems Canada 
  Inc.
http://www.adobe.com/products/server/

+1 (506) 
  871.5409