[MOBY-l] service = method ?

[Lincoln Stein]

We need use cases to discuss.  Lots of use cases!

Fiona, Andrew and myself have started writing use cases.  Is there a place on 
MOBY central to post them?

Lincoln

On Friday 25 October 2002 04:28 pm, 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

-- 
========================================================================
Lincoln D. Stein                           Cold Spring Harbor Laboratory
lstein at cshl.org			                  Cold Spring Harbor, NY
========================================================================