WHIP is an OMII funded project running from June 2007 to the end of December 2008. The aim of WHIP is to act as a companion for integrating workflow systems in portals. A motivating example is enabling sophisticated workflow enactment for the MyExperiment project. It has recently been integrated with the MyExperiment Taverna Plugin. The MyExperiment Taverna Plugin allows Taverna users to seamlessly move between their locally installed version of Taverna and the MyExperiment website. More info on the plugin can be found here.
WHIP is a set of lightweight components that can together be used in a flexible way to achieve workflow, and more generally, artefact sharing between diverse entities such as Web Portals, Workflow Enactment engines, and Web services. Here, artefact refers to anything that is either output or input to some process or application and can include data, process description and resources.
This allows an application to opened, or passed data directly while running when a user clicks a link in their browser or opens a file in their file browser. A single native WHIP launcher can be used to associate any number of applications with different types of data.
WHIP is made up of three main elements:
A WHIP bundle is a JAR or ZIP file with a particular structure. At the top level of the entries there is a metadata.xml entry and a data entry. The metadata.xml entry when expanded is an XML document conforming to the Atom Feed Document (http://atompub.org/rfc4287.html) specification. The data entry is logically a directory containing application specific data.
mybundle.whip
|
|
|
|------metadata.xml
|
|
|
|-------data/
|
|--------------------|
| |
mydata1.dat mydata2.dat
The Atom Feed Document contains the entries in the ZIP file as Atom Entries in the Feed. Therefore there is a correlation between the Atom Feed Document and the bundle as a whole, and between Atom Entries and the individual contents of the bundle. Atom Entries do not have any in-line content (not even a src attribute). Instead, they have a link with a relation of alternate pointing to the location of the ZIP entry relative to the Feed document. In other words all entries are just URIs to the contents. The Feed document can also contain external URIs pointing to resources that are not physically contained in the bundle, but rather are accessible over the Web. Hence a bundle is a logical aggregation of resources that may be both locally present in the bundle as well as remote.
Physically aggregating resources in a bundle and linking them to remote resources benefits a number of use-cases not well-supported by simply exposing links to separately published resources:
WHIP bundles have an extension of ".whip" and a MIME type of "application/whip-archive". The association of applications with the data contained in a WHIP bundle is made via OS specific WHIP launcher applications.
The WHIP launcher application is registered with the file extension and MIME type when it is installed on the target platform. When a file with a ".whip" extension is encountered by the OS, or the browser is requested to download a file with a WHIP MIME type, then the native launcher application is started. This in turn determines the application to launch based on the metadata contained in the WHIP bundle.
The core of the WHIP code is the Whippet component. A Whippet acts as a local HTTP server and client. When a user clicks on a WHIP file or link in their browser, the native application is launched. This in turn triggers Java code that receives the WHIP bundle and then starts working out which application it should either start up, or send the bundle to. It does this by examining the metadata in the bundle and comparing it to its registry of applications it has on the local machine. WHIP maintains files in the user's application data directory. The exact location will depend on your operating system. For example, on Unix-like systems this will be in <user-home>.whippet, while on a Mac it will be in ~/Library/Application Support/Whip.
If a matching application is found, a Whippet HTTP server running under the application's name is looked for. If one is not running, then the application is started and the bundle is put in the registry ready for when the application has loaded.
By implementing a simple interface with a single method artefactArrived(String name, DataBundle bundle), an application can become WHIP aware. This method is called when a bundle is either received by the running Whippet server (either over the network, or more typically, on localhost) or when a bundle has been previously deposited in the registry, ready for when the application has started up.