WHIP - Workflow Hosted in Portals Kurt Mueller and Andrew Harrison School of Computer Science, Cardiff And Ian Taylor School of Computer Science, Cardiff & Center for Computation and Technology, CCT, LSU AHM 07 10th September 2007

Overview WHIP: Sharing Workflow in Portals What is WHIP? Generic Scenario Usage Scenarios Triana DART scenario Sharing music information workflows GridSphere portlet WHIP demonstrator - DEMO myExperiment web 2.0 WHIP’s Role RAVE Sharing distributed visualisations invoked from within BPEL WHIP Overview Current status: the WHIP API ( Conclusion

What is WHIP? OMII-UK funded 1-year project Based around the myExperiment philosophy Share workflows with fellow scientists Develop community, foster collaboration Facebook for scientists How does WHIP fit in? Allows arbitrary applications to be launched from a browser/web interface e.g. Java apps, legacy apps, command line, workflow app, etc. Allows these apps to exchange information back and forth with the web interface. e.g. a workflow engine (Triana) launched with workflow description, input data and executable code. Circumvents the need for custom application and mimetype integration with the browser for launching

remote local browserworkflow client Portal Plugin App Plugin Web Start 3. Launch Web Start (JWS) 4. Retrieve jar files 5. Launch whippet 6. Discover and send data 7. Notify app WHIP 1. Click link 2. Retrieve jnlp file WHIP and JWS - example

Scenarios in the WHIP Project WHIP was funded in the OMII portal call Driven by three core application scenarios: DART Portlet for sharing Music Information Retrieval Workflows Based around the Digital Audio Retrieval using Triana (DART) project DART programmers want to share Triana workflows within a portlet environment e.g. GridSphere Creating a prototype demonstrator for this - demo later myExperiment Sharing workflows in a Web 2.0 environment Sharing is about creating online communities WHIP can support workflow execution from myExperiment Remote Advanced Visualization Environment (RAVE) Collaborative, Web-based visualization environment Requires communication between web interface, and custom visualization tools

Scenario 1 - DART Distributed Audio Retrieval using Triana Background Joint Project, CCT and Cardiff Funding from STFC - mini-PIPSS (1 year) Digital Audio Retrieval using Triana (DART) P2p system (think Triana is the workflow manager running on end-user’s CPU Developer creates a workflow to analyse audio (MP3 files) The Workflow is uploaded to all participants in the network Potentially thousands of MP3 files on users’ machines Files analysed locally on clients machines by Triana Metadata returned e.g. collaborative filtering, audio analysis Application: music recommendation system - i.e. if you like “Band A”, then try “Band B”

DART Manager P2PS Network User New Packages Super Peers Package Repositories Super PeersPackage Repositories Workers Worker Song Suggestions Result Advertisements Consumer Audio Analyser/Provider

DART portal demo

2 - myExperiment

Slide courtesy of the myExperiment team myExperiment is a Web 2.0 Environment for Scientists to share experiments

26/2/2007 | myExperiment | Slide 11 What are we trying to do? Enabling scientists to be (more) creative. Enabling scientists to be scientists. And not programmers. Enabling mediocre scientists to become better and thus have better science. Enabling smart scientists to be smarter and propagate their smartness. Accelerate dissemination, pooling, insight. Encouraging sanctioned plagiarism. Slide courtesy of the myExperiment team

26/2/2007 | myExperiment | Slide 12 Focus on making it easy to publish information Discovering and sharing experimental artefacts Publishing results to standard community repositories Publishing scholarly output Familiar social networking / web paradigms Keeping it free and fluid and creative. Me-Science. Crossing system boundaries Trans-workflow Crossing discipline boundaries Multi-disciplinary, Inter-disciplinary, Trans-disciplinary Clustering expertise Intellectual fusion outside discipline. We-Science. Life Science, Social Science, Astronomy, Chemistry myExperiment principles Slide courtesy of the myExperiment team

Requirements & Design Decisions Easy to integrate into a variety of environments: Portals / portlets Web 2.0 environments Thick clients Make it: Lightweight Composable Simple A successful artefact sharing protocol already exists - HTTP - so use it as a starting point. Integrate web services later… Write as little XML as possible Provide application independent protocols/specs Provide APIs, tools and plugins for portals and applications

Core API - Modeling Artefacts Whip provides a metadata schema that facilitates both service-oriented and resource-oriented exchanges. This allows Web Services based interactions and transfer protocol specific interactions (e.g. HTTP, GridFTP) Whip also defines an archiving format for binary transfer that integrates the metadata schema. A bit like WAR files - uses the JAR file format Using the JAR format, data can be easily signed and verified.

WHIP Portal Plugin The portal plugin provides: a simple means of sharing data between portlets in different applications but in the same portal. A means of exposing an endpoint from which data can be transfered from the portal to an application running on the user’s machine. Currently this is implemented using Java Web Start (JWS)

WHIP App Plugin The WHIP Application Plugin provides: A simple means of receiving remote data. Does not necessarily require remotely accessible ports to be open e.g. the JWS component will locate a locally accessible Whippet to transfer the data to. A simple means of uploading data to a remote repository Combined with the Portal plugin, data transfer can be easily achieved between the application interface and the Web interface

remote local thick client thin client Shared Space Bridging Environments Local execution of workflow

Status: working on API, plugins and DART demonstrator now. begin myExperiment collaboration soon Further info: