Roy -
I have reviewed the NVO and Astrogrid architecture diagrams as well as your synthesis of the two.
The Astrogrid diagram doesn't attempt to say much about relationships and structure other than identifying 5 levels: interface; applications; VO-specific infrastructure; middleware, including VO computational frameworks and grid/web infrastructure (the VO computational frameworks probably belong in the VO-specific level as the explanation states); and on the bottom astronomical datasets. The Astrogrid diagram doesn't attempt to get into important details such as data models and data model-based data access.
The NVO diagram (the one I am looking at is from Bob's recent presentation here at NRAO) has a similar flow from top to bottom but focuses more on the structure and relationships of the VO infrastructure. Technology which is widely used to implement the VO infrastructure is factored off to the right (e.g., data models, UCDs, metadata, and HTTP/Web/Grid services).
It seems to me that the Astrogrid and NVO diagrams are more or less consistent in terms of architecture (the actual systems produced may differ). The NVO diagram does a more thorough job of illustrating the structure of the VO infrastructure since this is what it focuses on.
The synthesis diagram seems to have all the right elements in it but the structure and relationships are not clear, and possibly inconsistent with the NVO diagram. Maybe this is because it is just hard to fit everything in one diagram. Some specific points:
o Data Services (is this the Data Access Layer?) deal primarily
with virtual data and involve computation. We can execute a
pipeline to produce an image. In general data access may involve
any amount of computation, including things like transformation,
or source detection to produce catalogs. This is necessary to
be able to move the computation close to the data.
o Maybe Compute Services should be renamed Application Services?
(or maybe Analysis Services). That is, astronomy-related services
such as a cross-matching service. Unlike the DAL services, which
are finite in number, application services are open ended. There is
no clear distinction between applications services and tools.
Data services and analysis services in principle can share all
the same technology and be implemented in similar ways. The main
difference is that data services have a uniform interface and are
oriented towards returning data in some standard VO data model,
whereas analysis services may each have a custom interface and can
in principle return anything. Analysis services are applications
which have been wrapped as services.
o HTTP, SOAP, and Grid Services are variations on the same thing,
there is no real distinction.
o ADQL is a lower level technology we would like to integrate into
the DAL services to allow more complex queries. Maybe I am just
misreading the diagram, but it appears to suggest ADQL is specific
to the registry. (ADQL and data models can in principle be used
all over the middle level; maybe that is what the think and thick
arrow are supposed to signify).
One thing that is missing in most of these diagrams is some indication that the set of top-level applications or tools is completely open, with many such tools to be contributed by the user community. The things we list are of course mere examples of standard tools. Maybe this is what is meant by WorkBench in the Astrogrid diagram.
My biggest issue with the synthesis diagram is the apparent distinction between "data" services and "compute" services. The biggest issue with the NVO diagram is that it is not clear where analysis services fit in. If it were possible to draw the diagram such that data and analysis services could share similar technology then this would be closer to our actual architecture.