[kepler-dev] Re: Fw: Practical work at Link Up meeting
ludaesch at sdsc.edu
Wed Nov 10 10:04:56 PST 2004
Soaplab fans (and others: please chime in!):
I'm still trying to figure out a bit more about the soaplab "trinity":
start, wait, retrieve
when invoking soaplab services.
It seems that this sequence of soaplab services can provide a finer
level of control than what standard web services allow. So that's a
BTW: How do standard WS deal with long running invocations (says
on the order of hours)?
Does the usual request/response pattern have a time-out associated?
Certainly for those long running WS invocations an asynchronous
pattern a la soaplab is preferrable. But then again standard WS also
have an asynchronous way of invocation -- some quick links:
However, I suspect that many service providers might not implement
that pattern!? Is that right?
In either case, as a matter of 'separation of concerns', in a workflow
setting I would think that a component (actor) should not have to
worry much about the communication mechanism (synch or asynch) but
instead this should be left to the overall workflow coordinator
(director in PT2/Kepler speak); this is of course the point of
"actor-oriented modeling" PT2-style.
For example in a process network (PN) workflow, maximal parallelism is
-- any process WS2 sitting downstream of a long running web service
WS1 will have to wait for its inputs anyways: [WS1]-->[WS2]-->..
-- any other processes WS3, WS4, ... on parallel branches will not be
slowed down by [WS1]: [WS3]-->[WS4]-->..
So it seems that the details of asynch communication can be hidden at
the WF level. The director, on the other hand, might be dealing with
the details of synch/asynch calls and might have different treatment
for each of synch WS, asynch WS, and soaplab WS ... right?
>>>>> "BL" == Bertram Ludaescher <ludaesch at sdsc.edu> writes:
>>>>> "TO" == Tom Oinn <tmo at ebi.ac.uk> writes:
TO> Efrat Jaeger wrote:
>>> Hi all,
>>> One question that came up from the meeting was about the benefits of SoapLab
>>> services. Could you please elaborate on the advantages of wrapping a command
>>> line application as a soaplab service over standard web services.
TO> Hi Efrat,
TO> The primary advantage is exactly that - it's wrapping an existing asset
TO> rather than coding a new one. Bioinformaticians tend to have significant
TO> existing work in the form of shell scripts, native executables, PERL
TO> etc, so we needed a way for these resources to be accessed remotely.
BL> yep -- understood.
TO> In addition, we get some level of descriptive information as a byproduct
TO> of the soaplab service creation - free text description and
TO> categorisation for now but we're enhancing soaplab to include semantic
TO> metadata as well regarding input and output types and their
TO> inter-relations. Soaplab exposes these metadata through an explicit
TO> 'describe' operation which toolkits such as Taverna can use to get
TO> information about the service above and beyond that available through
TO> standard WSDL.
BL> also good.
BL> Is it also conceivable to use a "WSDL++" for the same purposes? For
BL> example, you might have a standard WSDL (so that standard WS clients
BL> can handle the WSDL as well) and then add the extra (ACD) information
BL> in whatever places you might put them "without harm" (if nothing else
BL> as a "formatted comment") ...
BL> Wouldn't this combine the best of both worlds?
BL> Or do the WSDLs you publish for soaplab services already contain the
BL> additional ACD info somewhere?
TO> There are also arguably technical advantages from being able to set
TO> inputs individually, most notably that we can have default values and
TO> that we can request only the output data we're interested in in the case
TO> of multiple potential return types. With a native web service we'd be
TO> forced to supply all parameters (or have multiple versions of each
TO> operation) and also forced to fetch all results in one operation,
TO> possibly resulting in considerably more traffic than is required.
BL> I see. Wouldn't the use of complex XML Schema types provide a possible
BL> alternative route? For example a WS input, given as a complex XML
BL> Schema type could have optional fields, default values, and even
BL> "list valued" inputs etc...
BL> Seems that one problem with this is the mapping of such complex XML
BL> Schema types to the programming language types (say in Java)
TO> We actually had (I'm not sure if it's around anywhere now) a workflow
TO> which did exactly what you suggest - showed the single actor versus
TO> multiple finer grained actors for two equivalent operations, there's a
TO> diagram of the workflow here :
TO> although this is obviously a rather elderly version.
BL> I was looking at the image -- could you point out the which parts you
BL> mean here (i.e., where is the "standard" WS and were are the more
BL> fine-grained ones?)
BL> Coming back to Efrat's original question:
BL> Looking at the soaplab java client, the invocation of a soaplab service
BL> seems to be a sequence of three web service methods invocations, start, wait
BL> and getResults. I was wondering why can't the native web service actor be
BL> used for invoking soaplab services.
BL> Let me make a wild guess: with 'start' you launch a remote
BL> service. I guess 'wait' would do a polling (and if so, should probably
BL> be renamed!?), Then with getResults you retrieve the results.
BL> Seems this is implementing a simple async protocol so that a client
BL> doesn't have to wait for the completion?
BL> Is that right?
BL> An alternative approach in Kepler might be to push such low-level
BL> communication issues to the director level. For example, if a workflow
BL> has something else to do during the 'wait', it would already do so
BL> (since it's a multi-threaded/multi-process network) Conversely, a
BL> downstream process (i.e., "behind" the 'wait') would have to block
BL> anyways until the result is available.
BL> Did I get that right?
BL> cheers and thanks again for the insightful discussion..
BL> PS Can I cross post this thread to the kepler-dev list? I think others
BL> might benefit from this discussion as well (and might have
BL> addtl. feedback)
More information about the Kepler-dev