Just thought of a couple of extra points:
- There is very little difference between ADAM and modern
web services. Remote ACTIONS performed on TASKs over a network
are fundamentally the same as methods invoked on a SOAP service.
You might want to stress that the Starlink task design lends itself
to the web services paradigm and evolution towards web service
applications is built upon previous experience. ie don't let people
tell you that web services are anything other than message passing
over a network
- I see that AG-II is bidding for "research into web service scripting"
This beggars belief. ORAC-DR is a web service scripting engine
optimised for certain instruments. Any soap-enabled scripting language
can be used now for any web service. If there is a WSDL for the service
it is even quicker (I have SOAP services running for our flexible
scheduling system and it reaally is 3 lines of perl to run it).
I don't understand what they are talking about. At the very least you
should note that web-enabling oracdr is trivial since it is already
based on message passing - it just so happens that the ADAM tasks are
local but that is really irrelevant. Nic's problem is that his idea of
pipeline is scripts using rsh.... You should be focussing on the cool
demo of running oracdr locally but calling engines on remote systems.
Tim
On Tue, 27 May 2003, Giaretta, DL (David) wrote:
> Dear all
>
> I have significantly changed and put more details in the AstroGrid 2 bid -
> see section 4.2 and its sub-sections in
> http://wiki.astrogrid.org/bin/view/AG2/AgVirObInf I believe that it now fits
> in better with the rest of the AstroGrid bid and clarifies and reduces
> apparent overlap with other areas.
>
> I have also added to the ESO bid - see
> http://wiki.starlink.ac.uk/twiki/bin/view/Starlink/ESODataProcessing
>
> I'd appreciate comments on both ASAP, and those who can, please add things
> directly to the ESO bid document.
>
> ..David
>
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|
