TITLE: A Discovery Service For DAS2 Services Author: Brian Gilman Date: 13 August 2001 The DAS1 protocol lacks the ability to auto discover other DAS servers located on local or remote networks. This facility will become increasingly important as more and more DAS servers appear on the web decreasing the likelyhood that one will be able to find all DAS services which are relevant to their research goal. This document describes a registry based facility based on UDDI to serve as the basis for the DAS2 registry and lookup service. The DAS2 specification should support the ability to register a service with a central registry server(s). This server should take a description of the service in the form of an XML SOAP message. This message should contain: 1) uid (calculated using the UDDI uid encoding method) 2) Long description of the service 3) Short description of service (key words) 4) Type of service provided (machine readable XML encoded) 5) Type of data provided (machine readable XML encoded) 6) URL or service 7) Interface description of service with method signatures which this service provides 8) Private or public entry in the registry A uid for each service shall be computed and assigned once for each service which is registered with a central registry service. Uid's may not be reused so that synchronization between registries is simple and uniform across registry servers. Short and long descriptions shall be provided for search engine style lookup and discovery of services (google search, yahoo etc.). Service type is a machine readable description of the service for use in auto-determining the kind of service provided my this entry. This should be used as the default identifier for a service when querying the registry by service type (data service, analysis service etc.). Data type is also a machine readable description of the data type provided by this service (fasta, gff, xff, mixed). This will allow clients of this service to register the proper parsing interfaces with the system before calls are made to each service. A url must be provided for each entry in the registry service. This must be specified in the form specified in RFC 2396, "Uniform Resource Identifiers (URI): Generic Syntax". This allows for a common mechanism to contact a service after initial lookup in the registry. A description of the programmatic interface which a client must use to transact with each service will be provided for each entry in the registry. This will allow a client application to use this interface without having to pre-determine the methods used to retrieve/submit data to a registered service. An entry in the registry can be flagged as private to a registry or institution. An authentication mechanism (as yet unspecified) will be used to allow access to these private registry entries. Whole registries should also be able to flag themselves as private to an institution. Future registry abilities: Registries should be able to auto-discover other registries on the network. Registries located on the same network should auto register themselves with each other (a federated registry system) forming public federations and private federations. The public federations, located in an institution, shall choose one representative to register the group with a public registry (located externally and agreed upon by the DAS community. Perhaps reference servers should host the public registries). Private registries also choose to register themselves with a public registry on the internal network as a single private registry entry. This allows all client applications to search their public registry servers for services located on internal and external networks. -Brian ----------------------- Brian Gilman Sr. Software Engineer MIT/Whitehead Inst. Center for Genome Research One Kendall Square, Bldg. 300 / Cambridge, MA 02139-1561 USA phone +1 617 252 1069 / fax +1 617 252 1902