Points to discuss
- Machiel starts the discussion by explaining the SARA point of view (see below)
- Disentangling of solutions, what is needed for what?
- Collaborative plan of action
Stuart, working on data and provenance
Machiel, working in SARS, working on eScience support, looking at grid in the Bioassist program
Points to discuss
Machiel: Explain SARA point of view
Alex: There are also SOAP headers for WS-Security etc. Would have to say where it is to be put! It's a problem for the activity.
Marco: I like insecurity!
Alex: It makes life easier..
Stuart: Why can't we all just thrust eachother?
Marco: Will talk to Stuart and Stian about the other issues with data for the long-term plan. The bioinformatics are not always going to use the grid correctly.
Machiel: Not an urgent issue, but it will come up.
Stuart: Not urgent, but we need to know that when we start development now that we don't go down the wrong path. Part of this meeting was initiated because Carole came back with problems about references for data
Marco: ..and a provenance usecase. Talked to Morris about larg edata, if the legacy web services where the provider is not willing to change, then you are stuck - but if they are willing to change then there could be a solution. If the web services are not yet written then you can do it "properly" - and this is where BioAssist is now.
Stuart: For legacy web services there's not much we can do, we still ahve to send the data, but when services are to be written, we need to come up with guidelines about how the services can be written to support t2's reference schemes - annotations in WSDL etc.
Marco: Ask two things - ask the service provider to add an extra set of services that Taverna could use the extra service that does dereferencing.
Stuart: It should be so that if you call a service outside Taverna it should pass the data by value, but with Taverna by reference. Using "mustAccept" fields in the WSDL? There must be some way of Taverna to know that it supports referencing, most likely in the WSDL.
Morris: Can you write such a service now?
Stian: Well, there is no standard for this yet, but we would have to write something ourselves, it wouldn't be that hard to get something up and running. We would basically be writing the standard as we go along.
Marco: Wrapping the legacy service behind a proxy that hides the big data. (Basically the data proxy) - would this be a way to make legacy services
Stuart: The service itself would need to get hold of the big data.
Stian/Stuart: If the legacy service has not been designed for large data it will properly fall over no matter which way you proxy the big data in the front - if it does say a string operation internally, that would pull in gigabytes of data straight to memory no matter what. So in this case you would always need to rewrite the service anyway.
Marco: So we need to change the culture of the service provider. Could we use vBrowser?
Machiel: Integrating vBrowser with Taverna? It is a general structural 'file system' with all kinds of 'files' (resources), GridFTP, SRB, etc, all kind of storage systems can be handled within a simple GUI, where you can copy files around. It has an API.. vBrowser is an open source project, but with an unclear license currently.
Marco: Would it help with what Bharathi asked about?
Machiel: It would be easy with your mouse to say where your data should go.
Marco: I'm building a workflow, and a service is producing data. How would I use vBrowser for this?
Machiel: Let's say you drag a location from vBrowser to a Taverna input.
Marco: If it works by reference it would be vBrowser that would take care of the up/downloading.
Stian: This sounds very relevant for t2's data references, say you drag a location in to Taverna, it would occur as a data reference in t2. And t2 should be able to do translations/transports between incompatible reference schemes, for instance dragging a GridFTP reference to a service that expects a SRB reference, t2 could do the dereferencing and uploading.
Machiel leaves, Scott will join in tomorrow.