SEEK

Set up JWSDP in my local machine - pine. But JWSDP come with a tomcat two. Now
I am figuring that put the two tomcats into one apache server in dev machines.

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

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
service.

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.

Decided that UDDI was probably overkill for what it provides, and that instead
we might be better served with a simple XML document that is stored in an XML
database, or, if feasible, install the Grid Resgistry service.

Who: Matt
Target: June 2

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.

Rod,

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.

Metacat Client
--------------
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";
m.login("username", "password");
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
coverage area)
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.

• Bug 1061 has been marked as a duplicate of this bug. ***

Initial impl done in with GT3 and Metacat.

Next up: Using the GTw fully

Bing has done this already

Original Bugzilla ID was 1040