On Thu, Jan 6, 2011 at 20:13, Alvaro Graves <[email protected]> wrote: >> Do you mean that you need a shared configuration across the services >> in a workflow (defined at design time) or that at workflow runtime you >> need to pass along some additional data (which are not user-defined) >> from A to B? > I mean at design time
OK, then there are a few approaches, depending on the nature of the shared configuration. Here I'll assume that the shared item is something like a hostname. If your services are added to the workflow from a Service Provider (dragged in from Available Services) you could make all of them have individual configuration beans with the hostname set. (Assuming the service provider knows this hostname - you could use Configurable Service Providers to this - like the WSDL activity - the user does Import Service for the given hostname). If you want the user to specify the parameter when adding - or to edit it across several connected services, you have a couple of options. There are (at least currently) no shared configuration saved in the workflow, only configurations per activity instance. You could of course have the shared configuration in Preferences - that would make it local to your Taverna installation, and would not allow you to have two parallel set of services or different workflows without them having the same shared configuration. So if you want to achieve a common configuration, editable across all inter-connected services, what you could do is to do a customized configuration editing panel, and from there look up 'upstream' and 'downstream' processors. There are methods in net.sf.taverna.t2.core.utils.Tools that can help you find all upstream and downstream processors (recursively). The editing panel could then allow you to edit the common configuration across all the activities, using a CompoundEdit to do all the activity re-configurations as one big edit (so that you can undo it as one operation). Another alternative would be to 'cheat' and allow some kind of configuration identifier (like a UUID) that is set on all the activities that are in the same 'configuration group' - and use some static weak hashmaps to link them together. I'm not so sure of this approach, as you'll quickly end up with problems if two activities claim to be in the same group, but disagree about what is the true configuration - to avoid this you would have to make sure you look up in the weak hashmap from Activity.getConfiguration(). Note that I didn't have time to check all the class/method names above, apologies if some of them are wrong! -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester ------------------------------------------------------------------------------ Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ 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/
