Guy
Thank you for your careful reading.
I have used your comments to build a version 0.4, which also includes some "Vision of the VO" text generated by Szalay and myself.
New version is
http://www.ivoa.net/internal/IVOA/IvoaArchitecture/IVOarch4.htm
See responses below
Roy
Good point. New text:
Thus IVOA-compliant services are built to exchange messages that can be XML
documents and dictionaries (sets of keyword-value pairs), as well as
traditional binary formats such as FITS files.
> Section 2, bulletted list after paragraph 2: is "registry layer" a good
> description? It sounds as though a client calls the registry and the
registry
> uses the data/compute/storage services on the client's behalf, which is
> untrue. Would "registry services" be better?
I don't think there is an implicaiton of registry executing on client's behalf .... however I have changed "Layer" to "Services"
> Section 2, paragraph 4: best to qualify "filling out forms" as "filling
out
> web forms in a web portal". Otherwise it sounds like paperwork keyed in
by
> admin staff.
done
> Section 2, paragraph 7: ADQL may evolve to cover more than just tabular
data
> and explicit RDBMS. For example, one could implement the query part of
SIAP in
> ADQL. It's not obvious that ADQL will abways be a derivative of SQL.
I changed it so the SQL derivative is just a part of the ADQL.
> Section 2, paragraph 12: is this the best description of MySpace? MySpace
is
> useful even if all services are stateless. Try this ......
Good call. Change is made.
> Section 3, first bullet point after paragraph 1: HTTP-get/post services
can
> have WSDL too. W3C have a standard binding for HTTP-get/post.
The document doesn't contradict this -- to me the point is that in reality the Get/Post services do NOT have WSDL (even though they *could*)
> Section 3, second bullet point after paragraph 1: another benefit of SOAP
is
> that it allows routing through gateways. This may turn out ot be crucial
in
> linking up bits of IVO and linking those bits to external grids. The
> SOAP-header mechanism is very useful in defining security protocols and
such.
Good point. Change made.
> Section 3, third bullet point after paragraph 1: GWSDL was part of OGSI,
so
> it's dead.
GWSDL is deleted
> Section 3, paragraph 2: I would say that supplying a VOResource on demand
is a
> necessary but not sufficient condition for being a VO-compliant service.
I don't want to be so hard-nosed about this right now. I would like to say that there must be a VOResource *somewhere* -- either supplied on demand (qua WSDL), or in a registry.
> Section 3, paragraph 3: I prefer "availablity" to "heartbeat". "
Change made.
> Section 3, general: other things that may become standard aspects of a VO
> service are
>
> - how we do authentication and authorization;
> - how we deal with asychronous, long-running activities;
> - how we do notification of events;
I added a little text about these -- also section 7 (compute services andf grid) coveres these.
> Section 5, sub-section OpenSkyQuery and ADQL, paragraph 1: as I noted
above,
> it's possible that ADQL may eveolve to be more than an SQL dialect.
text is changed
> Section 6, paragraph 2: as noted above, surely the VOResource feature is
> necessary but not sufficient.
Revised to this:
If a service is one of the IVOA standard types and is associated with a
VOResource description, then it is a <i>VO-compliant</i> service.
> My instinct is that "self-describing services" don't describe their
semantics
> well enough to support automated use and we need other mechanisms for
> recording how a service works. WSDL certainly isn't enough by itself.
Right. The VOResource, Dublin Core, and METS are other types of description. However, the WSDL is enough for the computer to build a client stub or a web form.
> Section 7, paragraph 1: where you say "The NVO data services" do you mean
"The
> IVOA data services" or are you specifically referring to cone-search, SIAP
and
> SSAP?
Oops that slipped in with my cutting and pasting. I changed it to IVOA.
> Section 7, sub-section "Authentication", paragraph 2: in AstroGrid, we
have
> "community" and "group" which seem to map to your "project" and "role".
I have changed project to community, and role to group.
> Section 7, subsection "persistency", paragraph 1: in OGSI, persistent
services
> expired. In WS-RF, the state held by stateful services expires but the
> services themselves don't. This is reckoned to be one of the advantages
of
> WS-RF over OGSI.
Very illuminating. I have made this change.
> Section 7, subsection "persistency", paragraph 2: there are three ways to
> deploy a function to a grid node. One is to send an executable to a
"bare"
> processor (i.e. where there is no astronomical software) using a
> job-submission service that already exists on that node. The second is to
send
> a script that calls astronomical software pre-installed at the grid node;
the
> script is sent via the job-submission service in the same way as the
> executable could be. The third option is to somehow temporarily install
an
> astronomical web-service on the grid node for a short time. My take is
that
> we'll do the second option first, then the first and the third will have
to
> wait for the grid-middleware people to work it out. It might be good to
spell
> out these options in your document.
I have put these ides into that paragraph. Received on 2004-05-13Z21:04:05