Bob
Thank you for your nice remarks. Yes the chart is detailed, but I was thinking of a showing the pieces separately and describing each, with the whole chart revealed as a synthesis.
> What facilitates the big blue arrow on the right side, at the top,
the one
> pointing to Compute Services?
I am thinking the top layer is local to the user, and all the rest is remote. Services like source extraction and crossmatch would be built with standard interfaces, interfaces mediated by the data models of the entities that they manipulate. Therefore the portals interact with the remote services thru these standard interfaces.
> We have ADQL and XQuery as the transport
> mechanism to the Registry (which is not quite right),
These are standard protocols. Didn't we decide that these are two ways to query the registry? Another way to interact with the registry is thru a data model (blue arrow), i.e. by building a VOResource document and publishing it. The results of the ADQL/XQuery would be a set of VOResources -- one of our data model objects.
> ADQL and XQuery actually play a bigger role;
> In my diagram I showed
> ADQL connecting the DAL and the catalogs and archives directly
Agreed. These are valid Data Service query types that are implemented at Data Centers. But aren't they part of OpenSkyQuery?
> But back to Compute Services. In fact, I don't think there should
be a very
> direct link to Compute Services from the Portal. For the most part
Compute
> Services should be invisible to the Portal, invoked silently on
behalf of
> the user. The examples you've put under Compute Services are really
> Applications which request/invoke Compute Services as needed
(Montage,
> SExtractor,...). If Compute Services is relabeled as Applications,
which
> draw on Pipelines, Virtual Data, Grid Services, etc., that might fix
the
> problem. And the facilitator for Applications is the Registry,
right? How
> else does the Portal know what Applications are available? Am not
quite
> sure how to show this in the current representation. My diagram
puts all
> applications at the top, at the Portal level.
I see the computing activity as a combination of a portal (control from a user) and a pipeline. The pipeline is a connected collection of component services. Each service may have persistent state, authentication requirments, and run on a separate machine. Each service may be published and discovered from a registry.
> I DO believe we have all the essential VO components.
Yes I think so too. I'd like to hear from the other VO projects too, see if they can live with the basic diagram.
Roy Received on 2004-03-17Z03:46:12