Summary

The eScience community has embraced Web portals as a means of exposing eScience infrastructure. Typical eScience workflow tools are desktop applications with a wide variety of data and configuration needs as well as, in some cases, the sophisticated graphical front-ends that users are accustomed to. This makes them the problem of integrating these tools with portal technologies far from trivial. The expectations of these workflow systems are also becoming more complex.

Beyond simply chaining tasks together and providing the workflow with some input data, it is becoming apparent that in order to be useful to the scientific process, workflow systems need to capture more than simple output data. Hence, eScience workflow tools face a two-pronged challenge:

1. They must integrate with Web-based interfaces, without compromising their capabilities, to be useable from a wide variety of available portals and integrated with other eScience systems.
2. Aggregations of data related to a workflow instance or execution (provenance data, for example), previous results and executable components along with the input and/or output data of the workflow itself need to be managed.

WHIP provides tools for creating and publishing compound objects at the client-side, and storing and exposing them at the server-side. 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:

1. A simple, language-independent, specification for referencing and physically aggregating compound artefacts. WHIP provides a simple mechanism for aggregating resources (WHIP bundles) based on the Zip file format and the Atom Syndication format. Related resources (e.g., documentation, executable code, XML component descriptions, research results) can be contained in the Zip file or externally referenced.
2. A set OS specific launchers for bridging between a browser or filesystem, and applications associated with WHIP. The metadata in the bundle (an Atom Feed document) is used to determine what local application should receive the bundle. If the application is running, it is passed the bundle. Otherwise it is launched and notified of the bundle’s arrival.
3. Java library code for making desktop applications WHIP-aware and building server-side systems.