ADASS discussions

[Alasdair Allan]

> > Why make life difficult for people trying to access your service? It
> > would be rather nice if you could talk to a service endpoint using
> > straight SOAP as well as a full OGSI compliant toolkit if persistence
> > isn't needed for your query...
> 
> Quite. I never expected to deploy dynamic grid services where stateless
> web services would do the whole job.  I've been expecting to have a
> mixed architecture with some OGSI services (e.g. AstroGrid mySpace)
> amongst ordinary web-services.

Thats good to know, I was hoping that this was the case!
 
> Recently, I'm beginning to wonder if OGSI is worth the bother.  Here in
> Java land, we're stuck with GT3 as the only implementation...

You're better off than those of use in Perl country, we currently don't 
have an implementation at all...

> ...which makes development slow and difficult. 

There also isn't a DIME implementation, although SOAP::MIME does exist and 
works well with the testbed services I've tried.

> Parastatidis et al. 

Is this conference proceedings/journal paper? I haven't seen it, do you 
have a full reference handy?

> ...have questioned the usefulness of OGSI as a standard, proposing an
> alternative that matches better to web services standards.  If we don't
> do OGSI now, I'm wondering if it will have become obsolete by the time
> we need to exploit it.

I was sort of thinking about this as well, and had come to a similar 
tentative conclusion.

The eSTAR prototype used GlobusIO for its transport layer, this has
disappeared (for good reasons, it was bloody horrible to use), and we're
now totally SOAP based, with a mixture of document literal and RPC
interfaces depending to which bit of eSTAR you're talking to, with the
"external" interfaces tending to be document literal, although this isn't
globally adopted, yet...

...virtually veryone can talk SOAP, OGSA is a different matter.

> AstroGrid's new tack is to be able to use OGSI services at the bottom of
> the architecure, mainly as data-selection services.  E.g., we want to be
> able to talk, via some gateway to be designed in detail next month, to
> an OGSA-DAI instance as if it were one of the catalogue services in our
> data-access layer. (Which is not yet the IVOA DAL, BTW.)  This puts us
> in the position of wrapping grid services inside advanced web services.  
> We probably won't be using OGSI at critical locations elsewhere in the
> architecture.

I think this is a good interim compromise, it puts the external API as 
SOAP (presumably!?) which at least has had a little time to settle down, 
rather than something which is "subject to change without notice". 

This at least means that the infrastructure is usable _now_ which is
starting to become very, very, important. If persistance becomes vital
it can be introduced by using cookies at the web service level in the
short term, before moving to a full Grid-enabled service (although perhaps 
still allowing simpler queries to the service to be via a pure-SOAP 
call?). 

Al.
-- 
Dr. A. Allan, School of Physics, University of Exeter