[MOBY-l] service = method ?

[Mark Wilkinson]

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