From:  kimball@stsci.edu (Timothy Kimball)

Hi everybody,

(In what follows, I abbreviate "interoperability" as "i14y". I've also
attached a short glossary.)

This is good, but it doesn't look very far ahead.  While it's true that
we're not trying to create the NVO with this project, we should
consider that NVO and i14y are both going to need the same thing:
uniform, self-describing access to information.  In fact, my
understanding of NVO is that it will be built on top of the access
methods of the data centers.  One thing I would like us to avoid doing
is solving this problem once for us, and then having to solve it
another way for NVO. If we're smart- and we are- we can do this once,
creating a tier of uniform access to the data centers that can be used
for interoperability *and* for NVO. That should be the focus of this
project.

I suggest, then, using industry standards to build the uniform access
tier.  Standards like SOAP, for which software already exists for many
languages, will enable us to build an i14y layer very quickly, with a
minimum of agreement needed. This layer would comprise SOAP-based web
services (RPC using XML and HTTP) and some i14y applications, like
spatial cross-correlations, literature queries, and so on.

(I would further suggest that we skip the cross-links step. It's a bit
superficial, and we can easily do it later with a uniform access tier.)

The nice thing about this approach is that it makes access to services
simpler- simpler, in fact, than CGI.  SOAP lets you take a class that
you already have and, with little or not alteration, publish it as a
web service. It can then be used by any other data center as an object
whose methods are accessible to the client.  SOAP is language
independent, so a Perl service can talk to a Java client, or whatever.
The class can also be used in server programs as a regular class,
because it doesn't (or shouldn't) have anything SOAP-specific in it;
SOAP is simply a wrapper that makes it into a service.

We would need to agree on what methods the class would need to provide,
and what parameters to supply. We can also incorporate Astrores, but
it's not entirely necessary for the first cut; SOAP already delineates
simple data types like string, float, integer, and date. Astrores XML
can be added later. We can start simple, and build on it as needed.

Description and discovery can be handled by GLU in the short term, but
I would strongly suggest migrating to WSDL and UDDI for these as they
mature.  They're still in development, but are growing fast, as many
major players in the computer industry are throwing significant weight
behind them.

What I like about a services architecture is that it solves a number of
problems simultaneously.  At MAST, we are laying the groundwork for
using web services to support for the StarView Java application and our
web user interfaces. Also, it means that i14y is not limited to those
who have a copy of the GLU dictionary.  WSDL and UDDI will allow anyone
to find and use available services.  Finally, it will make NVO easier,
because we will have already built a foundation for it, which is easily
adoptable at other data centers, even those outside of astrophysics.

Glossary
--------

SOAP - Simple Object Access Protocol, or Services Oriented Architecture
	Protocol, depending on who you talk to. Normally uses HTTP,
	though it can also use other protocols, like TCP sockets or
	SMTP. The service query and response are wrapped in XMXL
	envelopes, but most packages hide that from you.
	See: http://www.w3.org/TR/SOAP/
http://www.oreilly.com/catalog/progwebsoap/chapter/ch03.html
(sample chapter from a forthcoming O'Reilly book on SOAP)

WSDL - Web Services Description Language. An XML DTD that describes
	what methods a service has and how to use them. Intended to be
	read by machines, but a description can be included for
	carbon-based agents as well.
	See: http://www.w3.org/TR/wsdl

UDDI - Universal Description, Discovery and Integration. A directory
	service that collects WSDL descriptions of services and
	supplies a searchable interface to them.
	See: http://www.uddi.org/


-- tdk