On 25/01/2013 17:54, Lahiru Gunathilake wrote:
I am doing research about scientific workflows and how to run rules in each workflow node based on the status of the application run. So before dig in to that level I just want to understand how existing scientific workflow tools handle the application status...Mainly what I want to know how you monitor the state of the application run in Taverna ? If application through an exception and stopped how you know something went wrong ? If application stop responding due to wrong input or something how you get to know that something is going wrong ? If someone can explain me how Traverna handling this that would be great.
You are aware that this is a very difficult question for ugly reasons, yes? I'll try to explain... It all really depends on the relationship of the application to Taverna. If the application is a sub-process that has been started by Taverna (through the use of the "Tool Service", which is a wrapper around the fundamental java.lang.Process class when working with the simple case of local execution) then it would be considered to be executing until it terminates: the exit code of the subprocess would indicate whether the processing was successful or not (there are conventions for this that long pre-date Taverna). Which isn't to say that that *actually* indicates success; not all programs are nearly as cooperative in that way as one might hope. In some cases, the only way to determine whether a program succeeds or not is to look for key phrases in its output stream (this is really nasty, and always application-specific; it's the sort of thing that you'd do through the use of a "Beanshell Service", and would probably wrap the details of into a component — one of the features that we're working on right now but which hasn't yet made it to production release — so that you could avoid having to think about it too much). If the application wasn't started through Taverna, monitoring of it would have to be done through either sending messages to the application or by checking if the process still existed (probably by running subprocesses again). In the former case, a successful response would be an indication that it is healthy, and there being a wide range of technologies that could be used to actually perform the communication (Taverna provides built-in support for some of them, such as SOAP and REST — they can be used locally as well as remotely — and others can be implemented using Beanshells or via plugin libraries). Alas, the scope of ways in which one application might monitor another (and the actual description of what it means for an application to be properly operational, a key aspect of any monitoring strategy) is really horribly non-trivial. This means that doing the job properly will lead into application-specific code. There are similar basic problems with the other questions you asked. Determining the actual failure mode is in general a hard thing to do in general (though *much* easier to do in most specific cases) precisely because the applications that you might wish to run that way are themselves highly inconsistent. (Indeed, there are some applications that require additional layers of wrapping to work in that way, and things get much more complex on Windows — compared with on Unix — due to the far more complex ways in which those apps can interact with the system. External GUI applications are really outside the scope of what Taverna tries to do, though there are some ways even there. For automation experts only though.) Even within the specific context of dealing with things like SOAP or REST calls, there's a... well... whimsical array of ways in which applications can indicate failures. I've worked with services in the past that would indicate failures by returning success and giving a reference to a document on an FTP site (!!!) which were substantial XML documents that included, buried within, a failure element describing the problem. And this was done even for fundamental things like not supplying sufficient arguments in the SOAP message[*]. It's niceties like this which are why making reliable workflows is a hard problem to solve in a general fashion. (Some workflow systems hide the truly nasty state of things a bit more, but that's either papering over the cracks or restricting the ways in which services can fail, and hence the set of services which can be supported.) Donal Fellows. [* I'm naming no names, but if you're a service author who is reading this and you recognize that interaction style, *pretty please* switch to returning the errors that you detect during at least the initial phase of processing of the SOAP message as SOAP faults. It's far nicer for clients! ]
<<attachment: donal_k_fellows.vcf>>
------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________ taverna-hackers mailing list [email protected] Web site: http://www.taverna.org.uk Mailing lists: http://www.taverna.org.uk/about/contact-us/ Developers Guide: http://www.taverna.org.uk/developers/
