Discussing current architecture
Present: Donal, Rob, Alex, Stian, Alan, ..., David, ..., Rishi
Alan asks: What is missing? Difficult to answer
What bits does the server need?
Engine, Data manager, Provenance, Activities, Security, (Workflow Execution - calling the server instead of the engine?), Mapping from Scufl2->t2engine (but only for event relations), Scufl2
Donal: Component vs. Objects? Being a facade for the server.
Seeing the server as a workflow executor?
Run manager - do X - well, it's over there, so do Server.X.
Donal's server view: Document comes in - is it allowed to run (policy? signature?). Scufl2 to have a profile of what is the capabilities.
So - Workflow Execution
Rob: 'Thing that runs workflow' - should it be moved out of the workbench? Sufficiently disconnected.
Stian: Should be possible from workbench to switch smoothly between embedded execution or server execution
David: Some features would be slower or different
Donal: Server just runs workflows - does (minimal) data/provenance management, but just because it is needed
Run Manager talks to different Workflow Executions, some of them on the server.
One Workflow Executor knows how to run (many) workflow - the Run Manager would know about one or more of these.
Taverna Server to appear as one of the
Action David/Donal: Make sure Taverna Server and Run Manager can hook up
Not business of Taverna server: Activity editing, Activities UI, Service Registry, Editing, Taverna 1, File Manager,
What is Infrastructure? Infamous Raven - to be replaced to infamous OSGI.
Initial idea - many possible mappings (scufl2/t2flow/t1) - but now we want only SCUFL2 for the Executor interface.
Executor takes SCUFL2 model and does mapping to t2engine - but future talking about monitoring etc. will talk about scufl2 objects.
Taverna Server purpose to be a Workflow Executor with an open (REST/SOAP) interface. Clients might know about SCUFL2 for deep details, but they could also just 'discover' such details from the server.
What is missing? Monitoring of workflow execution. Workflow engine gives you monitorable properties, what is going on inside. Would allow you to update progress etc. in the workbench/web/etc.
Some kind of whiteboard of workflow state. Any errors/events etc posted there. Needs to use Mapping.
Report Manager/Reporter - checking the state of scufl2. X might go wrong, Y is bad, Z is down. Sits near Run Manager - but Workflow Execution does not need to check workflow (Again).
Editing not really a non-UI - move towards SCUFL2.
Security on server vs. workbench?
Configuration Manager? What does it do?
Run execution environment.
Setting up Workflow Execution - like which RShell server, Proxies, Server configuration.
Exposing of configurable properties - so that it can be passed along to the server.
Action David: Look at configuration
Alex to explain on Monday what is "Security".
What happens on the server - a pool of engines? Some optimal number of simultaneous executions. Could potentially be in different virtual machines. Need to ship off some kind of security context. Different UNIX users (for accounting purposes as well as security). Must be authenticated to access server. (Not yet implemented). If going in without credentials, access to little stuff.
Say deploying to NGS - can't run anything unless it is authenticated.
Say someone using a portal with OpenId etc. - establish identity - hiding certificate magic.
If server uses delegation then it could be.
Get credentials from the whiteboard? Pause/etc until client comes back with credentials.
Currently security architecture allows for SPI implementations (now: just UI) to return the credentials needed.
Access Control on the server. Also know who is coming in, who can run which kind of workflow. Some kind of pluggable interface.
Will the server tell what it can do *and* what it will allow to do, or will it say what it will specifically not allow? Possibility - send across workflow for inspection and say yes/no. That might be too black and white.
Should no longer have Taverna 1 libraries - but depends on SCUFL2 translation being possible without t1.
It talks to the server. Does it fit to the diagram?
No, the server components are not really.
What granularity is the gem talking? Quite coarse.
Expose the RESTful interface to look like an API. Hide XML magic.
A Run is on a Server.
Server (in Ruby) does not
A method on the Run can query itself on the Server.
The Server object does all XML and HTTP.
Need a 'clear all runs' method. Need to delete only 'my' runs.
Rob explains why expiry is a good idea. Anything monitoring a run can keep the expiry running ahead.
Server need some kind of default (currently 20 mins) - but whoever runs can set the expiry to whatever they want.
State is on the server - so everything needs to be checked with the server.
Need a way to enumerate 'my' runs on the Server.
Two types of users.
Does the Server instance keep all the Runs? No, it asks the Server. No caching at the moment.
Activities editing box to be moved closer to Scufl2.
Activities box moved to inside Engine, behind Mapping.
Activities UI discovering Activite
Long discussion about profiles and hardware/software restrictions
Just do it.
Plan at the moment is that :
David is specifying run and workflow manager.
Alan is trying to make the engine use consistent versions of external libraries.
Start at moving engine into OSGi and move out from there.
Engine currently relies on Raven infrastructure - first to be replaced.
Report, Editing, etc - should they be pulled out immediately, or wait.
Need SCUFL2 in there.
Workbench in OSGi? Need SCUFL2 at least.
If we do a 2.3 - what is needed?
David to continue on run manager and executor.
Alan sort out versions of engine.
Engine into OSGi and see what happens.