Notes based on taverna1.0 & ouzo1.0 last checked out 2004-04-29 09:41 BST

++ General

The Taverna Workbench is the current default user client for myGrid. It is a single heavy-weight Java application. The main shared internal state is a singleton workflow model instance. The main window hosts multiple specialised panels. These are coordinated (where required) via access to the shared workflow model. Tom suggests that most other data interaction between panels (and between panels and other applications on the desktop) should be via drag and drop/clipboard.

++ Adding New Panels

To provide fuller support for the myGrid infrastructure Taverna requires additional panels, at least some of which already exist in some form:

• registry/view panel to find/publish workflows and services
• notification client panel, to manage subscriptions and receive programmatic notifications
• information model panel, exposing information model entities such as Person, Organisation, Programme etc, backed by the mIR.

Currently org.embl.ebi.escience.scuflui.workbench.Workbench creates initial desktop panes and menu items using idiom:

new org.embl.ebi.escience.scuflui.workbench.GenericUIComponentFrame(workbench.model, new ScuflDiagram^?());

where second arg is of type (interface) org.embl.ebi.escience.scuflui.ScuflUIComponent. This interface allows the new component to expose a name, and methods to attach/detach org.embl.ebi.escience.scufl.ScuflModel.

+++ Chris Wroe's discovery view extensions

adds uk.ac.man.cs.img.discoveryview.gui.taverna.ServiceRegistrationTabbedPane (discoveryview in myGrid CVS) and org.embl.ebi.escience.scuflui.workbench.SessionContextPane (also not yet in myGrid CVS) as view options by modifying Workbench.

-- ChrisWroe - 04 May 2004 It is in myGrid CVS but not in Taverna CVS. --

Note: adds Workbench member variable 'context' (i.e. new shared state) of type org.embl.ebi.escience.scuflui.SessionContext (has URNs for current user, workflow Definition, experiment, project, organisation).

+++ Proposed extension mechanism

based on org.embl.ebi.escience.scuflui.renderers.RendererRegistry create a ScuflUIComponentRegistry^? which is queried by the Workbench to populate menus. The SPI would be org.embl.ebi.escience.scuflui.ScuflUIComponent. This is based on org.apache.commons.discovery.tools.Service, which requires the JAR containing a given implementation to have a file META-INF/services/org.embl.ebi.escience.scuflui.ScuflUIComponent which contains (one per line) the names of the class(es) implementing the SPI.

+++ Proposed extension mechanism II

Chris Wroe's addition of the 'context' variable to the Workbench needs to be generalised to support sharing of state models between UI components that are unknown at Taverna compile time. For example, this might be a singleton SharedStateRegistry^? which manages a Map of name (and/or class) to reference to (eventing) shared state instance of arbitrary classes. This should provide thread-safe initialisation on demand. E.g. the SessionContextPane^? would request the current shared 'context', and the SharedStateRegistry^? would create an initial value on first use. This should also (probably) become persisted by default (?!).

++ Data interoperability - current

+++ File drag and drop

org.embl.ebi.escience.scuflui.workbench.Workbench uses org.embl.ebi.escience.scuflui.workbench.FileDrop to respond to dropping of files from windows desktop onto the Taverna frame, and presumes that they are XScufl files and attempts add them to the current workbench Scufl model. This supports pre-java 1.4 drag and drop to awt components as well as swing jcomponents. It accepts drop (Copy only) of built-in flavour java.awt.datatransfer.DataFlavor.javaFileListFlavor (java.util.List of java.io.File).

Note: more general file drag and drop would be useful, e.g. to inputs, from results.

+++ Data thing drag and drop

org.embl.ebi.escience.scuflui.DataThingConstructionPanel has nested class TreeTransferHandler^? which accepts (drop only) org.embl.ebi.escience.baclava.factory.Flavours.DATATHING_FLAVOUR (XML DataThing^? doc, currently MIME type "text/lsid", name "An LSID!") and Flavours.LSID_FLAVOUR (not yet implemented, currently MIME type "text/dataThing", "A DataThing^?").

NOTE: These MIME types should probably standardised/changed.

supported by org.embl.ebi.escience.baclava.factory.DataThingTreeTransferHandler; org.embl.ebi.escience.scuflui.ResultItemPanel instantiates this for each results tree. This is pre-java 1.4 drag and drop, and uses org.embl.ebi.escience.baclava.factory.TransferableDataThing which exposes the XML from DataThing^?.getElement as the DATATHING_FLAVOUR value, and the LSID from DataThing^?.getLSID(DataThing^?.getDataObject()) as the LSID_FLAVOUR.

Note: drag/copy of LSID as string from results objects is needed to facilitate desktop 'integration' of haystack/launchpad.

+++ Other drag and drop

org.embl.ebi.escience.scuflui.ScuflModelExplorer has a simple (mainly default) org.embl.ebi.escience.scuflui.ScuflModelExplorerDragHandler which is not currently useful for much (drags to text fields as simple text; nothing else).

org.embl.ebi.escience.scufl.AlternateProcessor, InputPort^?, OutputPort^?, Processor and ScuflModel^? all implement Serliazable and Transferable.

++ Chris Wroe's discovery view patches to Taverna

These are currently in mygrid CVS under discoveryview rather than Taverna

+++ Drop onto ScavengerTree^?

org.embl.ebi.escience.scuflui.workbench.ScavengerTree (a ScuflUIComponent^?) has drag enabled, and transfer handler set to an instance of org.embl.ebi.escience.scuflui.workbench.ScavengerTreeTransferHandler. This uses Flavour/MIME type DataFlavor^?.javaJVMLocalObjectMimeType+";class=uk.ac.man.cs.img.discoveryview.gui.taverna.BasicServiceModel", i.e. in-JVM-only instances of uk.ac.man.cs.img.discoveryview.gui.taverna.BasicServiceModel. Drop currently assumes a WSDLBasedScavenger^? using the dropped BasicServiceModel^?'s getServiceInterfaceLocation().

-- ChrisWroe - 04 May 2004 Yes only WSDL services can be dropped onto the ScavengerTree^?. Changing to an XML fragment should not cause any problems for me. --

Tom proposes http://www.ebi.ac.uk/~tmo/mygrid/DragNDrop.html that this should actually be a SPEC ELEMENT http://www.ebi.ac.uk/%7Etmo/mygrid/XScuflSpecification.html XML fragment.

+++ Drag from ScuflModelExplorer^?

Supported by org.embl.ebi.escience.scuflui.ScuflModelExplorerDragHandler as the above BasicServiceModel^? flavour or string flavour.

Not sure if this is instantiated/active at present.

-- ChrisWroe - 04 May 2004 No not used at presented by the registry panel. --

-- TomOinn - 04 May 2004 This component is not used anywhere anyway, shouldn't be referenced by anything any more as it's been replaced with the treetable form --

+++ Drop onto ScuflModelTreeTable^?

Supported by org.embl.ebi.escience.scuflui.ScuflModelExplorerDragHandler which is insantiated as tree table and tree transfer handler by org.embl.ebi.escience.scuflui.ScuflModelTreeTable.

This supports drop of BasicServiceModel^? flavour (above) for serviceType WORKFLOW and serviceLocation which is an URL of a Xscufl script.

Tom proposes http://www.ebi.ac.uk/~tmo/mygrid/DragNDrop.html that this should actually be a SPEC ELEMENT http://www.ebi.ac.uk/%7Etmo/mygrid/XScuflSpecification.html XML fragment.

-- ChrisWroe - 04 May 2004

Again I see no problems in using an XML fragment. The main problem we have had is getting the equivalent entities from the registries. i.e. you insert service operations into a workflow but the registry returns services. --

+++ Drag from ScuflModelTreeTable^?

The above also appears to support drag using Flavour/MIME type DataFlavor^?.javaJVMLocalObjectMimeType+";class=uk.ac.man.cs.img.discoveryview.gui.taverna.QueryCriteriaModel", i.e. in-JVM-only, where query is dragged from an input port (INPUT_CRITERIA_TYPE, and name of port) or an output port (OUTPUT_CRITERIA_TYPE, and name of port).

This does not appear to be addressed in Tom's drag and drop proposals http://www.ebi.ac.uk/~tmo/mygrid/DragNDrop.html .

(Chris Wroe can add some more documentation here

-- ChrisWroe - 04 May 2004 There is an incomplete drag implementation into the registry query panel. This is to support building a registry query along the lines "What is sensible to include after this operation?". It would be handy if the XML fragement transfered had semantic information included. Otherwise we depend on the registry to retrieve these semantics as attached to the service. --

-- TomOinn - 04 May 2004 I think it should go back to the registry for the semantics. At present there is no definition in the language to explicitly bind the operational semantics of a processor to that particular implementation. While this may be a deficiency I'm reluctant to expand the format much more at the moment. The other point is that a drag from the service panel onto here would by definition not have any user defined semantics, so the query builder is going to have to be able to go back to the registry anyway. --

++ Tom's drag and drop proposals

http://www.ebi.ac.uk/~tmo/mygrid/DragNDrop.html

Tom suggest DnD^? of XML fragments which are Xscufl SPEC ELEMENTS http://www.ebi.ac.uk/%7Etmo/mygrid/XScuflSpecification.html . Such a fragment represents the specification required to instantiate a Processor or equivalently a Processor Factory which will in turn instantiate that kind of processor. Processors occur in the Scufl Model, which Processor Factories occur in the Scavenger model.

This would address linking from find/registry/view to workflow/scavenger, and from workflow/scavenger to registry/view (publishing). It does not appear to address query creation (above, Chris Wroe's drag from ScuflModelTreeTable^?).

-- ChrisGreenhalgh - 30 Apr 2004 last updated -- ChrisGreenhalgh - 04 May 2004