On Tue, Apr 21, 2009 at 14:05, Jerzy Orlowski <[email protected]> wrote:
> 1. Is this information necessary? T1 would check corresponding > activities and add processor ports automatically. What will happen if I > delete info about processor ports in T2? In Taverna 1 a workflow was composed of linked processors. There were different kind of Processor implementations, such as WSDLProcessor, BioMartProcessor, etc. Each of these maintained the ports themselves, typically discovered by parsing a WSDL service description or similar. In Taverna 2 a workflow is still composed of processors, but there's only one type of processor. Inside the processor there's one or more Activities, which are the actual service implementations, like WSDLActivity, etc. A processor therefore has it's own input ports, which may or may not match the ports of the activities inside it. The activity therefore has a port mapping between the processor ports and the activity ports. The advantage of this becomes more obvious when you consider the case of several alternative activities/services. This is something that is not yet exposed in the UI of Taverna 2.0, but you could do a similar thing in Taverna 1 with "Alternative processors". You can have two or even more activities in the same processor, and the Failover mechanism will flip over to the the next activity if the first one fails. So if you are doing a BLAST search, but you don't care too much about which service you're actually using, you can add several activities to that processor. From a workflow point of view we're still talking about a single processor, do a single task in your workflow, namely the sequence search. Now the problem is if those activities don't have all the same input ports. Say that Activity A1 has the ports "sequence" and "parameters", and Activity A2 has "seq" and "params". The processor input port names can be arbitrary, but typically they are the same as for the first activity, so "sequence" and "parameters" in this case. In the activity's port mapping, we can map "sequence" to "sequence" and "parameters" to "parameters". (And vice versa for the output ports). Now for A2, let's assume the sequence format is the same, so it will map "sequence" to "seq", but as we're mapping "parameters" to "params" we notice that A2 takes a different kind of parameters. We solve this by adding a third processor input port, and we call it something like A2Parameters. We rename the second one to A1Parameters as well. Now A1 has "A1Parameters" mapped to its "parameters", and A2 has "A2Parameters" mapped to its "params". You can easily extend this for services that takes additional inputs. As you see there's a fair amount of UI to be added to support this properly in Taverna 2.x, which is why we have not yet exposed this. (but it's in the plan!) I believe some simple drop-down boxes for the ports, with guessed-mapping where the names are matching, would be a good enough approach. In Taverna 1 you only had "Alternative processors", which in deed would have a mapping of it's ports to the original processor, but the problem then was what to do with additional ports that didn't exist in the original service. Additionally, the processor also has stuff such as iteration strategy, retry/failover settings, etc. that should apply to all of the services, which is why we introduced this separation. Another special case we had in Taverna 1 was an "Abstract processor" - the idea about this was to use it as a place-holder for when you don't know quite which service to actually use yet. In Taverna 2 you could potentially do this as simple processors that just don't have any activities added to them yet. (which would require a Beanshell-like UI for specifying those processor ports). To go back to your question: If you delete a processor port, that port will not be there anymore. The datalinks go between processor ports, so deleting the port would also remove the connection. Even if there is a mapping in the activity, it is no longer valid as the processor input port is missing. The service will probably not work, unless this was an optional input parameter. > 2. If I cannot delete all processor ports because of datalinks, can I > delete the ports that do not have any links? What would happen If I try > to open such workflow in T2? The dataflow would probably still open nicely, but the question is if it would run. Why do you want to delete processor ports? You can delete ports that don't have any links, but typically you will see that they are not even there in the first place. When you construct your workflow in the 2.0 Workbench, processor input ports are created on demand as links are made. The reason for this is that when executing a processor, there will have to be data on all it's input ports, so that the iteration strategy works, etc. So in the workbench, if you delete an incoming link to a processor port, we also remove again that processor port. The activity may or may not work without that input, that depends on if it is an optional input. For the processor output ports, there's no harm in them being there without being connected, as they will just go through their 0 connections out to propagate the output data. I'm not sure if they can be removed, at least not without also modifying the activity output port mapping. -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ taverna-hackers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/taverna-hackers Developers Guide: http://www.mygrid.org.uk/usermanual1.7/dev_guide.html FAQ: http://www.mygrid.org.uk/wiki/Mygrid/TavernaFaq
