Roy,
I've read v0.3 of the architecture overview. It's good: a nice description of what we are about. We should, I believe, avoid presenting it as a _definition_ of the architecture, which it isn't, and maintain it as an introduction.
Some points of detail follow.
Section 1, paragraph 4: NVO cone-search, SIAP and SSAP aren't exactly "services that exchange XML documents"; services that emit XML documents maybe. Is it worth emphasising that we'd prefer services with XML inputs in the future?
Section 1: I still find the diagram a little confusing. I don't think I understand all the detail that you've included and I can see ways that someone new to IVOA could infer things that you don't mean. I stand by what I said about the diagram in my previous email.
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?
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.
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.
Section 2, paragraph 11: it would help to state whether the grid middleware is visible to IVO clients and portals - i.e. the griddishness is a part of the definition of some IVO services - or whether the grid part is hidden behind a non-grid IVO service that acts as a facade.
Section 2, paragraph 12: is this the best description of MySpace? MySpace is useful even if all services are stateless. Try this:
"A vital part of the IVOA architecture is MySpace so that users can store data within the VO. MySpace stores files and DB tables between operations on services; it avoids the need to recover results to the desktop for storage or to keep them inside the service that generated them. Using MySpace estblishes access rights and privacy over intermediate results and allows users to manage their storage remotely."
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.
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.
Section 3, third bullet point after paragraph 1: GWSDL was part of OGSI, so it's dead. WS-RF won't need or use GWSDL. In fact, the need for GWSDL is one of the things that killed off OGSI. The "indirection mechanism for service location" is mainly missing from WS-RF.
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. There is, at least, the availability interface and there may be other required features.
Section 3, paragraph 3: I prefer "availablity" to "heartbeat". "Heartbeat" generally implies a pushed notification that the service is still up; we have only a poll check that it's still there. Q.v. Martin Hill's recent email.
Section 3, general: other things that may become standard aspects of a VO service are
For the latter two, I have a proposal to use emerging grid standards. For the first, I have a proposal to use the WS-I profile. We'll see how well these proposals are received at the meeting.
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.
Section 6, paragraph 2: as noted above, surely the VOResource feature is necessary but not sufficient.
Section 6, paragraph 4: we've been debating this a little in AstroGrid land; see
http://forum.astrogrid.org/read.php?TID=757
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.
Note also that grid services are typically a sub-set of SOAP services nowadays.
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? Section 7, sub-section "bulk access", paragraph 4: MySpace includes parts that map logical names to physical names.
Section 7, sub-section "Authentication", paragraph 2: in AstroGrid, we have "community" and "group" which seem to map to your "project" and "role".
Section 7, sub-section "Authentication", paragraph 3: I think (hope) we're headed for a scheme where a user logs on to a community service once per session and the user's agent (typically the web portal rather than the browser) gets PKI credentials from the community as a result of logging in. Authentication to data/compute/storage services is then all PKI but the user doesn't see this or have to handle the PKI credentials. I'll be proposing this to IVOA this week: watch grid-at-ivoa.net for details.
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.
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 hope this helps. If you'd like me to draft any sub-sections in better language than the above I'd be happy to help.
Cheers,
Guy
On Mon, 10 May 2004, Roy Williams wrote:
> Dear Architecture Group
>
> I urge you to please take a look at the new version of the Architecture
> document that has been revised in accordance with Andy Lawrence's very
> useful feedback. Please tell me what is missed out and what should not be
> listed as part of the IVOA world. I have also included Jim Gray in the list
> since I for one would value his take on this.
>
> Once I get feedback from more than one person, we might be in a position to
> add a Recommendations section.
>
> The document is at:
> http://www.ivoa.net/internal/IVOA/IvoaArchitecture/IVOarch3.htm
>
> The changes are mostly section 3 and subsequent, where we have moved away
> from the working group structure to this:
>
> -- 3. Web and Grid Services
> -- 4. Standard Data Models
> -- 5. Data Services
> -- 6. Registry
> -- 7. Compute Services and Grid
> -- 8. Semantics
>
> I believe it is section 7 that need the most attention in our working
> groups, with perhaps some new interest groups.
>
> Note:
> VOQL is covered in sections 5 and 8.
> VOTable is covered in 4.
> UCD is in 8.
>
> Looking forward to seeing you May 23 in Boston
> Thank You
> Roy
>
>
>
>
> --------
> California Institute of Technology
> roy-at-caltech.edu
> 626 395 3670
>
Guy Rixon gtr-at-ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523Received on 2004-05-11Z17:43:05