Thanks for answering 1. I am trying to modify workflows in offline mode. Assume I am adding another processor. I might miss some of its input or output ports but I might still get all the links right.
2. Is there any default-value mechanism in T2? What happens to default values in the process of translation? Jerzy Orlowski Stian Soiland-Reyes wrote: > 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. > ------------------------------------------------------------------------------ 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
