set up registry service for ecogrid
Review possible registry implementations - UDDI, LDAP, Globus, ...
Experiment with a simple implementation
* jUDDI (http://www.juddi.org/ , was built by bowstreet.com now appears to be
SF project) * http://www.themindelectric.com/glue/index.html (supports LDAP authentication)
Install one of these for testing.
Target deadline: April 18
#2 Updated by Jing Tao about 18 years ago
Set up another UDDI server - WASP. It has a friend web interface and user can
use it to register, publish and find business, service, binding template and
TModel. It also has a client package and developer can use it to access the
server. Howerver, it is only testing and evaluation version.
The url is http://pine.nceas.ucsb.edu:8080
#3 Updated by Jing Tao about 18 years ago
Wrote a client program using GLUE standard library(free) to search IBM and
Microsoft testing uddi registry. In Microsftsoft, I registered a TModel named
EcoGridAPI. Then I registered a service named metacat which bound EcoGridAPI
in business NCEAS. And I registered another service named morpho which bund
EcoGridAPI in business UCSB. Given the EcodGridAPI key, the program can find
both of them.
I sent an email to IMB to ask why user ouldn't add a service into a business.
I just got a general reply which said to forward the email to the webmaster.
But I still tried to search IMB UDDI test server by given a TModel key. The
result is nothing found - that is what we want, i didn't bind it to any
Now I am working on JWSDP lib to write the program. The API of GLUE is much
more friend than JWSDP and it is free too. But I know, JWSDP is standard.
#5 Updated by Matt Jones almost 18 years ago
Agreed to pursue the OGSA service based registry approach to integrate it with
the rest of the OGSA stuff we are doing. So... need to implement the registry
operations that will be deinfed in bug 1165 using some of our existing systems.
As metacat can already sotre arbitrary XML documents, Matt agreed to start with
an implementation of it there. Raja also is going to look into doing this with
the Sleepycat XML database.
#6 Updated by Matt Jones over 17 years ago
Here's the description of the registry backend that I promised on the phone
today. Using the EcoGrid Query API will allow us to switch around the backend
if we desire, but as we discussed it will be pretty simple to use Metacat to
store the XML documents that constitute the registry information. For now,
because we don't have an EcoGrid write API defined yet, you can use the
Metacat-specific client library described below to write to the Metacat.
Update your CVS version of the metacat module, and make sure you have an updated
copy of the utilities module as well. With those in place, you should be able
to type "ant clientjar" and build the metacat client. This will produce
metacat-client.jar and utilities.jar and httpclient.jar -- putting these in your
classpath will allow you to access metacat from any java program. There are
some detailed examples of using the API in the JUnit tests that I wrote (see
metacat/test/edu/ucsb/nceas/metacattest/client/MetacatClientTest.java). For the
common cases you'll need of inserting, updating, and deleting registry
documents, it boils down to this (lots of exception handling not shown):
String testdocument = "version=\"1.0\"?><some><random><xmldoc>hi</xmldoc></some></random>";
Metacat m = MetacatFactory.createMetacatConnection(metacatUrl);
String identifier = "testid.1.1";
String response = m.insert(identifier,
new StringReader(testdocument), null);
identifier = "testid.1.2";
String response = m.update(identifier,
new StringReader(testdocument), null);
String response = m.delete(identifier);
The response is an XML document itself with either a root node of "<success>" or
"<error>" and some messages explaining the result.
Of course, you can use the EcoGrid client API to query the metacat server (or
you can use the metacat client "query()" method).
Registry XML document
The registration process should include information found in bug 1166, bug 1165,
and bug 1167 and consider the discussion in bug 1040. That said, some of the
info that should be included probably includes:
1) A GSH endpoint for the service
2) A pointer to a WSDL document for the service, or a copy of the WSDL
3) A human readable name for the service
4) An optional coverage section for the service
-- base this on the EML coverage module, including space, time, taxa
5) For data services, an optional estimate of number of data sets (possibly by
6) For computational services, some optional terms from an analysis
classification ontology that describe what the sevice does (e.g.,
SpeciesDistributionPredictionModel): see bug 1167
Lets chat about this and revise it when you digest it some.