[MOBY-l] service = method ?

Fri Oct 25 20:54:42 UTC 2002

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

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

> Lukas Mueller wrote:
>
>> On Friday, October 25, 2002, at 01:22 , Martin Senger wrote:
>>>    Could they really? Only if the operations return a handler to an 
>>> object
>>> which must be used in the next operation call. Which means that the
>>> operations are *not* independent - but at the moment they are still
>>> registered as individual services.
>> Couldn't this be handled on the object level instead of moby central 
>> (if I understand the problem correctly)? Instead of a real moby 
>> object, the service would return a moby object (of the appropriate 
>> type -- such as Sequence etc.)  that contains a pointer to the object 
>> that can then be fetched with a defined moby service.
>> I'm not sure if the discussed scenarios wouldn't make service 
>> discovery more complex?
>
> I tend to agree... but being more complex is not necessarily bad if it 
> solves a problem that we feel it is within the scope of this project to 
> solve.
>
> Similar issues have come up a couple of times on the list in the past 
> few months - e.g. Paul G. wanting MOBY Services that do simple 
> registration of information with no 'real' output (other than, perhaps, 
> an "OK").  I'm not sure that this scenario is what we had in mind when 
> we planned MOBY, but that doesn't make it an invalid request if we can 
> find a simple way to accomodate these things.
>
> In my opinion, we can approach such requests from several different 
> perspectives:
>
> (1) These services are not "unusual", and that the MOBY paradigm of 
> Object_In -> transform -> Object_Out is just too simplistic to 
> accomodate the wide variety of services that are out there, and hence 
> we need to re-think it entirely from scratch... perhaps there is 
> another way to achieve the "awesome power of MOBY" using a more 
> inclusive architecture
>
> (2) The MOBY paradigm is sufficient to accomodate these "unusual" 
> services, as long as the service provider uses their imagination and 
> finds a way to fit their service provision into our model
>
> (3) The number of "unusual" services is insufficient for us to break 
> our heads worrying about them
>
> (4) The "unusual" cases are providing services, or providing them in 
> ways, that are beyond the scope of what the project is trying to 
> accomplish (here I am thinking of the conspicuous and perfectly valid 
> link on the Gene Ontology page to "What GO is *not*")
>
>
> I think that all four of these persepctives are valid in one way or 
> another.  MOBY, similar to GO and DAS, must be aware of, and focus on, 
> the problem it is trying to solve, and more importantly understand what 
> problem it is NOT trying to solve - otherwise we will end up paralyzed 
> in the planning stages as we try to accomodate everyone and their dog. 
> Similarly, service providers have to accept that their "status quo", 
> while efficient and perfectly designed for their particular purpose, 
> may have to be re-thought if they want to play the MOBY game - a little 
> inconvenience on their part, with the reward of greater 
> interoperability and service provision for their end-user community.  
> At the same time, we MOBY developers have to not be so rigid in our own 
> "status quo" that we can't accomodate reasonable and non-destructive 
> changes if they seem appropriate and within the scope of what we are 
> trying to accomplish... and finally we have to be willing to say 
> "hey... we can't please all the people all the time" and simply accept 
> that there will be some services that we can not MOBYcize.
>
> But for the moment let's aim high :-)
>
> I think the situation that Martin is describing is one that we will 
> face frequently - services which take a long time to execute are 
> problematic... even Blast is a pain in the butt!  Of course, on the web 
> this is solved by giving you a temporary URL that you can periodically 
> check to see if your job is done.  Should we try to deal with this 
> situation at all?  I think it is going to be common enough that MOBY 
> will be a complete failure without having some way to deal with it! 
> So...how do we accomplish this?  I can think of three solutions:
>
> (1) We try to mimik this CGI/Web behaviour by having some sort of 
> "bookmark" object returned in these special cases where a job must be 
> started and left running.  If so, do we
>
> 	(1a) make this bookmark object-type a special case, where the 
> registry itself interprets the object to get you back to the correct 
> service for result retrieval, or...
> 	
> 	(1b) do we have each such service register their own unique 
> bookmark object-type so that their particular job-retrieval service can 
> be discovered (i.e. RE-discovered) through a normal MOBY Central 
> locateServiceByInput() call?
>
> (2) Alternately, we could make *all* services behave this way
> 	: object_in -> job start -> bookmark out
> 	: bookmark_in -> result_retrieve -> result_returned
>
>
> there are probably many other MOBY-ish solutions to the problem as 
> well...
>
> I'm going in circles in my mind about what I think is the best 
> solution... can everyone weigh in with their opinions because I think 
> this is a "biggie" and will be difficult to change if we don't get it 
> right the fist time...
>
> M
>
>
>
> -- --------------------------------
> "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
>