[MOBY-l] service = method ?

[Mark Wilkinson]

Martin Senger wrote:

>   Disregarding the remark about Perl (what about services written in a
>different language?) 
>
Clearly, SOAP will support other languages also; although MOBY Central 
does not have a WSDL, the API is (I believe) sufficiently well described 
both online and in the POD documentation that clients in other languages 
should not be particularly difficult to write.

I do agree with one comment you made to me offline that the current MOBY 
Central API has an unnecessary "new" function.  There is really no 
reason for MOBY Central to be OO, since the MOBY Central object 
currently does not hold any useful information... it just looked 
prettier, and I assumed that it would be ~equally easy to implement in 
all languages.  If this is not the case, I can change the interface.

>it seems to mean that only services represented by a
>single method are supported.
>   I have asked Mark about it and he confirmed that "...that is correct,
>and it was a design decision.  Services are single calls - atomic
>interactions.  Atomic interactions may, however, be pipelined together in
>various useful ways."
>  
>
Right.  The "MOBY philosophy" of:  

    object in --->  transform --->  object out

lends itself to atomic operations... in fact, I can't think of 
operations that are not "atomic" in this sense.  Granted, in our 
favorite programming languages we are able to write things like:

$x = $y->operation1->operation2->operation3

but this is just a pipeline of 3 atomic operations that could equally 
well be broken into three separate calls.  

>   My opinion on this is slightly different. I think that having a
>single-method services is surely useful and makes the communication much
>simpler
>
simplicity is good  :-)

> and I understand that the service providers may be encouraged to
>design their services in such way. But in the same time, an IMHO, the Moby
>registry (central) should not be restricted only to such kind of services
>because simply other kinds will exist and it would be pity if the Moby
>Central cannot accomodate them.
>
I think we can find a happy compromise between completely restructuring 
MOBY Central to allow registration of complex operations, and supporting 
the type of interaction which I believe you are talking about 
(...actually, if you could send a specific example of what it is you 
want to do we would be able to talk in less abstract terms...)

Let me assume that what you want to do is register the service "EMBOSS", 
that consists of a large number of potential method calls with various 
inputs and outputs, yet are all related in some way under the banner of 
being an EMBOSS service.  Since MOBY Services are organized in a 
hierarchical/DAG manner, we could sensibly register all of the EMBOSS 
services under a common node "EMBOSS", as well as under other relevant 
nodes.  We could then add a new function call at MOBY Central that 
generates a combined WSDL for every service downstream of a given 
node... that way you would get what I believe you are looking for - a 
single interface describing the entirety of EMBOSS.  At the same time, 
we would get what we want - the ability of a *single* EMBOSS function 
("sub-service") to be presented to a user when they have the appropriate 
data type in-hand.  Moreover, we would not have to change the registry 
structure to accomodate "non-atomic" servivces (which I don't believe 
exist in any case... I think they are perhaps better described as 
"service suites")...

The goal is integration...  there is no single datatype that is 
appropriate for *all* of EMBOSS, so in that sense, individual functions 
*must* be registered in MOBY Central in order to be discovered by the 
locateServiceByInput call of MOBY Central (and of course, a service that 
can't be discovered wont be very useful ;-) )

>   May I ask the others for their opinions?
>  
>
Oops!  Sorry... you got mine again :-)  

I'll shut up at this point and let others wade in on the topic.  I just 
wanted to suggest the compromise above as part of the ensuing discussion 
to see if that might be an acceptable and simple solution.

Cheers!

Mark