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 simple specification for bundling compound artefacts.
  • a set OS specific launchers for bridging between a browser or filesystem, and applications associated with WHIP.
  • Java code for making applications WHIP-aware.

WHIP Bundles

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.

              |                    |
          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:

  • It helps the owner to remain in control of her data by publishing aggregated resources to a single repository, rather than scattering them across the Web.
  • Particular physical relationships may have to be maintained between resources, for example application resources or executable code which the application looks for in particular places.
  • Bundles compiled using the JAR specification can be digitally signed, allowing consumers to verify the contents.

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.

WHIP Launchers

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.

WHIP Application Components

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.

WHIP features relevant for Developers

  • Provides a wrapper for application data (WHIP bundle) that can be transferred to a desktop application from a Web site.
  • Browser independent implementation - The WHIP launcher is mapped to WHIP bundles at the OS level.
  • Bundles allows for both metadata and application-specific (meta)data of arbitrary complexity providing a complete encapsulation of data requirements for an application. Application data can be also referenced rather than contained directly in the bundle.
  • Allows flexible client-side control of how a local application is executed - applications can also choose to provide a custom execution procedure that acts upon a WHIP bundle.
  • Supports sending data to running applications. WHIP detects if a WHIP aware application mapped to the WHIP bundle type is running. If it is, the data is passed directly and the running instance.
  • WHIP provides a single install platform that multiplexes between one file format (WHIP) and multiple client-side applications. For example, in myExperiment this can be used to provide one WHIP link that supports multiple workflow engines e.g. Triana, Taverna, Kepler and so forth without further user configuration.
  • The WHIP current implementation provides a bundling service. A developer can use this service to bundle their application-specific data on-the-fly from their back-end Web site implementation or client-side application before transferring across the network.
  • The WHIP bundling specification is simple and uses well supported technologies. The WHIP metadata document uses the Atom syndication format - WHIP metadata is an Atom Feed.Hence:
    • Proprietary XML parsers are not required - Atom is widely supported.
    • WHIP metadata can be discovered, published and categorized using the Atom Publishing Protocol.

WHIP features relevant to Users

  • One-click install at the OS level - WHIP maintains native installers for Windows, Mac OS X and various versions of Linux.
  • A single native WHIP install can multiplex between any number of WHIP aware applications.
  • Allows any client-side application to be exposed from a Web site transparently. WHIP supports any client-side application (Java and non-Java) that can be passed data.
  • WHIP enables publishing of a compound artefact directly from your client-side application to a server repository using simple HTTP requests. The WHIP MIME type can be registered with the Web server to trigger specific behaviour.
  • WHIP enabled client applications support publishing and retrieval of compound artefacts, for example the complete workflow experience - data, metadata, enactment and workflow provenance - can be stored on myExperiment and retrieved for future client-side enactment/reference in a single WHIP bundle.
  • Supports contextualized artefacts and artefact lifetime through the use of the Atom Syndication Format.
  • Supports "live" experiment links from user's private Web sites. A hyperlink to a WHIP bundle on your own Web site will enable it to be enacted by others directly from within your on-line research papers and documentation.
  • Both local bundles (.whip files) and online links are mapped to the WHIP native application making associations between data applications seamless.