[MOBY-l] service = method ?

[David Block]

I vote for 1b.  Provide a standard interface so that all of the various 
caching schemes look the same to the client, and then tell the service 
providers to decide which of their services require session state, and 
which are stateless, single request/response pairs.

Then clients will pretty much get what they expect, the service 
providers will usually give results back immediately, and in the case of 
someone providing a service that takes a long time (they must be truly 
selfless to give away that many compute cycles for nothing), the 
provider can use one of hopefully several drop-in implementations of a 
simple interface that

a) returns a bookmark/cookie/placeholder/state-holding object to the 
client

b) takes that object and returns
	i)status of query
	ii)query results
as appropriate.

Then, those that have lots of cycles but not much storage can expose 
only immediate results, while those who want to let people do long 
searches (or whatever) and store the results can create objects with 
expiration dates, like HTML cookies, that can be garbage-collected when 
they are out of date.

Of course, this would work much better if someone were to provide a 
reference implementation...

And a J2EE server would probably be able to handle much of the caching, 
etc., without a lot of overhead.  This looks like a job for OmniGene.  
Brian?  :-)

Dave

On Friday, October 25, 2002, at 01:53  PM, Mark Wilkinson wrote:

> Yabbut...
>
> Realistically, most service providers are not going to want to store
> query results on their servers waiting for the client to get around to
> picking them up.  The simple services are going to just send back the
> originating object as their "bookmark" and say "take this back and give
> it to me again when you are really ready to accept the result".
>
> Maybe this is okay, though... because you gain that intermediate
> opportunity for the service provider to examine what you have given them
> and send you back some metadata if they, for example, know that they are
> going to puke on it... Still, two SOAP calls to do what is effectively a
> single transaction is not very efficient.
>
> Hmmmmmm....
>
> M
>
>
>
>
> Lukas Mueller wrote:
> > I like solution (2) a lot. Every moby service would just result in a
> > pointer, that also may hold some metadata about the result-set (if the
> > result set can be generated that fast), for example the length of the
> > response (and we would not need something like a virtualSequence
> > object). For the queries that would take a long time to run, just the
> > pointer would be given, as no metadata will exist at that point.
> > However, methods should exist to query the metadata of the data the
> > pointer points to, once the result becomes available. The client could
> > then decide what part of the result it wants transmitted.
> > Cheers
> > Lukas
> >
>
> --
> --------------------------------
> "Speed is subsittute fo accurancy."
> ________________________________
>
> Dr. Mark Wilkinson, RA Bioinformatics
> National Research Council, Plant Biotechnology Institute
> 110 Gymnasium Place, Saskatoon, SK, Canada
>
> phone : (306) 975 5279
> pager : (306) 934 2322
> mobile: markw_mobile at illuminae dot com
>
>
> _______________________________________________
> moby-l mailing list
> moby-l at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-l
>
>
David Block                                  dblock at gnf.org
GNF - San Diego, CA             http://www.gnf.org
Genome Informatics / Enterprise Programming
Weblog:      http://radio.weblogs.com/0104507/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3793 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-l/attachments/20021028/2dc0837c/attachment-0001.bin>