Re: [Taverna-hackers] LSID authority location, workflow LSID problems

[Jun Z. <zh...@cs...>]

Tom Oinn wrote:

>Stian Soiland wrote:
>  
>
>>Now that provenance is becoming important, we should also take care of
>>the LSID authority issue.
>>
>>
>>1) Move the service to say http://www.mygrid.org.uk/authority   on port
>>80. Apache rewrite rules can do this even if the underlying Tomcat is on
>>say :8081, but I couldn't get it to work now as the service returns a
>>URL with port :8081 inside the XML.
>>    
>>
>
>Potentially we could run this at EBI if we could persuade our external 
>services people that this was an important service, we'd then get the 
>redundant hardware system that the main web servers use which should be 
>extremely reliable.
>
>  
>
>>2) Add a LSID proxy class in Taverna. If the mygrid authority (or
>>whatever is configured) cannot be used, step back to locally generated LSIDs
>>    
>>
>
>Should be easy, just need to add a bit of failback code that creates the 
>naive ID provider instead if there are any problems with the LSID proxy 
>(which is already there)
>
>  
>
>>3) Provide a LSID provider class that generates random LSIDs instead of
>>just incremental ones. Then at least two runs of Taverna won't produce
>>duplicate IDs.
>>    
>>
>
>Or use the standard hack of picking time in milliseconds + hostname or 
>object ID as a base.
>
>  
>
Previously I had problems with this identity assignment scheme, as I was 
running two workflows almost at the same time. They were given the same 
identities at the end. We should randomize the ID.

Jun

>>4) We need to define what the LSID of a workflow really identifies. As
>>it is now, the LSID is generated when a new workflow is created. If a
>>worflow is loaded and then heavily modified, the LSID is still the same.
>> (Unless the user presses the "New LSID" button, but since probably only
>>2% of our users know what an LSID is, why would they?)
>>    
>>
>
>This should be a lot cleaner with t2, mostly because we'll be using an 
>edit model so rather than having setFoo you have doEdit(new 
>FooEdit(..)). This makes tracking of actual model changes a lot easier 
>and of course gives us the ability to track provenance of the evolution 
>of the model as well. At this point we can autogenerate the ID in a 
>CVS-like fashion by detecting branches in the edit provenance and 
>keeping a base ID as originally assigned. We'd probably have to move to 
>a dual format approach analogous to the difference between photoshop and 
>png, the former keeping the edit information (so a user could load and 
>immediately undo the last change) and the latter being smaller and more 
>compact but losing edit information.
>
>We could enforce the creation of an entirely new LSID if a non 
>edit-enabled workflow was loaded and modified, and create branch style 
>IDs if the full one was changed. Of course, some concept of user would 
>help avoid issues here. One option would be to back the entire workflow 
>repository with CVS, something we talked about a couple of years back 
>and never quite got around to doing, I still think there are potential 
>advantages to this.
>
>Cheers,
>
>Tom
>
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>_______________________________________________
>Taverna-hackers mailing list
>Tav...@li...
>https://lists.sourceforge.net/lists/listinfo/taverna-hackers
>  
>