You are a master of PPTmanship, Roy. The chart is a nice synthesis of the
AstroGrid and NVO diagrams. It may be a bit overwhelming in detail, but I
think it captures the key relationships well.
What facilitates the big blue arrow on the right side, at the top, the one pointing to Compute Services? We have ADQL and XQuery as the transport mechanism to the Registry (which is not quite right), and data models facilitating access to data services. ADQL and XQuery actually play a bigger role; you can see it in the diagram (through Registry, and Semantics, and Existing Data Centers, and finally to Databases, but it seems a longer and more tortuous route than is really the case. In my diagram I showed ADQL connecting the DAL and the catalogs and archives directly
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.
This is mainly graphsmanship...it is hard to show a number of complex relationships in one view. I like some features of the AstroGrid diagram, though it is both a bit obscure (What is "Community" within VO Infrastructure? Why is Registry above Resource Discovery? Seems to me that things are upside down here. And I don't understand why a CLI would feature so strongly at the interface level.) and imprecise (use of specific services and protocols is not shown at all). One presumes that there are links between the layers, but none are shown -- they all float in an assumed hierarchy, and without our knowing what connects them.
I DO believe we have all the essential VO components. I also believe we understand their relationships pretty well, even if we cannot draw them quite right. Critics might say if you can't draw it, you don't understand it. But there are certainly physicists who understand a 4-dimensional space-time, or a 9-dimensional string theory, who cannot draw a 9-dimensional cube!
Cheers,
Bob
> I have been tasked to make a statement of the "Architecture of the
> IVO" so that our national projects can try to stay on the same track
> as everyone else. I would like to make something that we can all agree
> to -- otherwise it is just a Roy/NVO statement and not really
> international at all.
>
> I have decided to take the following path.
> (1) To build a 1-page diagram of the general architecture (see
> attached).
> (2) To describe the components and how they interact (not started
> yet).
>
> So what I would like is to first reach an agreement on the Big Diagram
> (1), then try to get the working group leads to write some text
> describing their pieces of it. So far, I have integrated the
> architecture diagrams from Hanisch (NVO) and from Linde (Astrogrid2).
>
> Therefore, please take a look at this attached picture, and ask if
> your view of the VO architecture fits in it somewhere.
>
> Please respond by comments to this group rather than by modifying the
> PPT.
>
> Thank you
> Roy
>
> --------
> Caltech Center for Advanced Computing Research
> roy-at-cacr.caltech.edu
> 626 395 3670
>
Received on 2004-03-17Z02:36:00