Report PoC Mashup-Technology

Transcription

1 indi Report PoC Mashup-Technology Project : SURFworks Project Year : 2010 Project Manager : Wladimir Mufty Author(s) : Bas Steen, Peter Clijsters (Everett) Completion Date : December 2010 Version : 1.1 Summary This report describes the result of the Proof-of-Concept Mashup-Technology. To enhance the use of Mashup technology within the scientific research community we have developed a Mashup gadget. This gadget, based on the OpenSocial standard, combines two services into a new service (requesting workflows online and running them on shared hardware). While the Proof-of-Concept has been successfully implemented, some specific issues surfaced. Contacting remote services brings the need to register the contact details of these services in a way that is flexible and can be queried by the gadget (for example a service registry, possibly combined with group definitions). When these services require authorization, these service details cannot be determined at runtime but need to be predefined. This publication is licensed under Creative Commons Attribution 3.0 Unported. More information on this license can be found at

2 Colophon Programme line : SURFworks 2010 Part : Proof of Concept Collaboration Infrastructure Activity : 5.1 Deliverable : Report Proof of Concept Mashup-Technology Access rights : Public External party : Everett This project was made possible by the support of SURF, the collaborative organisation for higher education institutes and research institutes aimed at breakthrough innovations in ICT. More information on SURF is available on the website 2

3 6 things you should know about PoC Mashup-Technology Scenario This report describes the outcomes of the Proof of Concept (PoC) Mashup-Technology that was conducted in line with the conclusions of the report Mashup Technology for Research and Education (2010). That report gives an overview of several mashup platform types, gives insights on user requirements and analyzed the platform types that best suit the needs of scientific researchers. This Mashup-Technology PoC report will cover the outcomes and results of a mashup platform with enhanced features. What is it? This report contains a description of the use case, the technical setup and implementation, and the results and conclusion after implementing this PoC. Who is it for? The PoC Mashup-Technology is written for the internal SURFnet organization with an interest in improving an existing mashup/workflow platform through the use of a webportal with OpenSocial support. Besides the internal SURFnet organization the PoC Mashup- Technology can be of value to scientific researchers (with some basic development skills) who are interested in running a webbased scientific workflow mashup tool within their own portal. How does it work? The PoC creates a new service (in the form of an OpenSocial gadget) from two seperate services. It retrieves workflows from the myexperiment site and executes them on a SURFnet defined Taverna server. What can you do with it? This PoC proves the feasibility to create mashup type gadgets. Some issues were encountered which have been documented and can be used to further develop the SURFconext infrastructure. More information Mashup Technology for Research and Education; Arjan Peddemors; Ref: indi ; 3

4 1 Introduction Background Goals Reading Guide Mashups Context Use case PoC setup PoC implementation details Getting workflows from my experiment Getting the runners available to the current user Posting the workflow to the Taverna server Getting the status of workflows from the Taverna server PoC results and conclusions Use case criteria and functionality Results and findings Conclusion and recommendations Appendix A. Mashups use case Appendix B. References

5 1 Introduction 1.1 Background In the first half of 2010, SURFnet performed the technology scouting Mashup Technology for Research and Education. This technology scouting was performed as part of SURFnet s Collaboration Infrastructure project (Project COIN) within the SURFworks program. In this project the SURFconext service has been developed. The technology scouting Mashup Technology for Research and Education [ref 1] has shown that there is not one mashup product that directly fits the needs of the target audience (researchers) and could be included in SURFconext. Mashup functionality that is available online does not seem sophisticated enough to incorporate into SURFconext while more sophisticated tools are not available through a web based interface which makes integration with SURFconext difficult. It was determined that further research was necessary to examine how the desired functionality could be incorporated into SURFconext. Based on the findings of the technology scouting, SURFnet wanted to perform a Proof-of- Concept (PoC for short). This PoC have been named PoC Mashup-Technology and this document describes the results. 1.2 Goals A Proof-of-Concept need to be developed based on the Mashup Technology for Research and Education Technology Scouting. SURFnet has defined the use case that needs to be addressed (see Appendix A). The goal of this project is not only to implement the use case, but also to document the development and to detect technical or conceptual difficulties in realizing the use case. Extra attention needs to be given to the integration of the solution in the SURFconext framework. 1.3 Reading Guide Chapter one introduces the background and goals of the PoC Mashup-Technology. Chapter 2 describes the specific context of this PoC, the setup and implementation details and the results. Chapter 3 contains the conclusion and evaluation of the performed use case. Appendix A contains the use case for Mashup Technology as defined by SURFnet. Appendix B contains the references used in this report. 5

6 2 Mashups 2.1 Context A growing number of web users are combining different online information resources. Combining two (or more) information resources on the Internet can be viewed as a "mashup" of information. The characteristic of a mashup is that it is a fast and accessible way to combine existing information. The mixing of information within mashups can have multiple levels, from a mere presentation of two combined web-resources to scientific analysis, calculations and modification of information using multiple datasets. To create a mashup a user can use a mashup tool. These tools have a graphical interface and can often be used without advanced programming skills or knowledge about creating web applications. The current mashup tools have a variety of functionalities and user options. In the Technology Scouting "Mashup Technology for Research and Education" ([ref 1]) research and analysis was conducted on these tools. The Technology Scouting covered the applicability and usefulness of mashup tools for SURFnet users, with the focus on the scientific researchers. The Technology Scouting has shown that the available mashup tools can be divided into three main categories: General purpose Mashup environments. Enterprise Mashup platforms. Scientific Workflow environments. To analyze which type of mashup tools best fitted the needs of the scientific researcher s requirements were set and analyzed. These requirements included the desired mashup platform characteristics and properties that are of great importance to researchers. It was concluded that the studied mashup tools differed in their available functionality. In addition, none of the tested tools actually fulfilled all of the requirements. The type of mashup tool that currently best suited the needs of researchers was found within the Enterprise Mashup Platforms & Scientific workflow environments. The set of identified requirements were presented and discussed with some mashup (technology) experts within the scientific community. Within different research fields several factors appear to influence the importance of the defined requirements. The interviews showed that the success of a mashup platform does not depend on being able to handle very large amounts of data and dealing with a variety of user types and the diversity of the visiting public. 6

7 More important requirements were that of (open) protocol support, the possible use of domain specific tools and the availability of mashup platforms. These requirements were often already met within today s mashup tools. The Technology Scouting had a few requirements which were endorsed by the researchers but which are still not available within the current platforms. There are still requirements to be met on flexible authentication, tracing the scientific process and the extensibility options of a mashup platform. 2.2 Use case Before the actual work for this PoC could start, a clear view of the use case was needed. The use case, stated in [appendix A], involved a scenario where a researcher uses a scientific mashup workflow platform. The platform that best suited this scenario is Taverna [ref 2]. Taverna is an open source software tool for designing and running scientific workflows. It is a standalone client-side program, typically running on the machine of the user, which uses local as well as remote (internet) data sources and data processing functionality. Workflows can use multiple data sources as input and perform various operations on this data to generate an output, something which is very similar to what Mashups do. During the start of the PoC the use case was discussed with the developers of Taverna, they acknowledged the need for some feature enhancements and encouraged the development of them. SURFnet also found out that the Taverna developers were at that time planning to incorporated several major enhancements on their developmentroadmap for The items planned (e.g. web-based workflow editor, new Run/Execution Manager and Edits API) had a very clear overlap with the defined use case in [appendix A]. To prevent overlapping activities or the development of (complex) functionality that will be incompatible in the near future, the use case now focuses more on combining the workflow storing and sharing capabilities of the myexperiment 2 website with the ability to actually run the workflow on a Taverna server instance. There will be no focus on making the workflows editable through a web based interface as this will now be covered by the Taverna developers. Although the focus was adjusted, the use case still aims at accomplishing the original goals but without the possibility of editing or creating new workflows through a web browser. The use case still enhances the use of a mashup platform by making it easier to share and run workflows and the possibility of sharing hardware resources with the use of open standards. Figure 1 shows the adjusted Mashup-technology use case where the gadget interacts with the myexperiment website and a Taverna server myexperiment is a (social) web site for researchers sharing research objects such as scientific workflows 7

8 Figure 1 Mashup use case 2.3 PoC setup The use case as shown in Figure 1 has been developed using the setup as shown in Figure 2. Here, the running of workflows is initiated by the gadget. It is also possible to let myexperiment do this; within myexperiment a user can select a pre-defined runner server for a workflow. MyExperiment then creates a job that is posted to the selected runner server. This flow was not chosen as it merely shows that an interface can be build onto the myexperiment website. It was more interesting to let the gadget post the job to the Taverna server as this is more Mashup like. Additionally, there were some technical limitations that prevented the gadget from posting jobs to myexperiment: The myexperiment API does not yet contain job functions When the gadget tries to use a retrieved runner configuration from myexperiment, the gadget needs to supply the username/password for the runner. A user might not always have this information, certainly not when the runner was defined by someone else in myexperiment and shared with the user through a group relation 8

9 Figure 2 Mashups PoC setup Figure 2 shows an overview of the Mashup PoC implementation. The Mashup gadget, shown in yellow. The gadget is hosted on a different SURFnet machine. Note that hosting does not mean it was running on that machine; the gadget runs inside the OpenSocial container. The OpenSocial container that runs the Mashup gadget. When developing this PoC, this was a Shindig container running in tomcat 7 on the developer s laptop. Later on, the gadget was also added to the gadget repository of the SURFconext development environment. The myexperiment website. This is where the end-user stores and shares his workflows. For development purposes, the myexperiment sandbox was used which exposes the same REST API as the production website. The Taverna Server (version 1.7) including the remote execution plugin running on tomcat 7. This software can only be used to run workflows and does not contain a user interface. It can only be accessed through a REST API. 2.4 PoC implementation details The Mashup PoC contains four basic functionalities: 1. Getting the current workflows of the user from myexperiment; 2. Getting the runners available to the current user; 3. Posting the workflow to the Taverna server; 4. Getting the status of workflows posted by the user from the Taverna server. The sections below will explain how this information is retrieved in the Mashup PoC for each of the 4 functionalities. 9

10 If not stated otherwise, each call stated below is executed using the gadgets.io.makerequest method of the OpenSocial API. NOTE: The current SURFconext demo portal does not support storing of activities for a person. These activities are used by the Mashup gadget for storing the location of a job that is executing on Taverna (see section 2.4.4). Therefore, when running this Mashup gadget from within the SURFconext demo portal, no status updates can be seen from the job. When the Mashup gadget runs in igoogle, this does work as igoogle has implemented activities for a person Getting workflows from my experiment Before the workflows of the current user can be retrieved the user first has to enter his myexperiment user id in the gadget settings as shown in Figure 3. Figure 3: myexperiment gadget settings myexperiment Opensocial container (with myexperiment gadget) GET /user.xml?id=[userid]&elements=workflows,groups (1) Workflow and group list GET /workflow.xml?id=[workflow id from list]&elements=components (2) Workflow information GET /group.xml?id=[group id from list]&elements=shared-items (3) Shared item list Figure 4: REST calls for getting workflow information from myexperiment Figure 4 shows the REST calls that are used to retrieve all the workflows of the current user and the workflows that are associated with the groups of the current users. None of these calls require authentication. The first call (1) gets the workflows and groups that are associated with the user. The workflow information that is retrieved from this call is restricted to the workflow title, id and uri. This PoC also requires that the workflow can be executed; therefore additional information is needed about the input parameters that are required to run each workflow. 10

11 This information is retrieved using the second (2) call. This call is repeated for each workflow returned by the first call. The workflow list retrieved by the first call (1) does not include the workflows that are associated with the groups of the current user. This information is retrieved using the third call (3). This call results in a list of shared items, from this list the group workflows are extracted and additional information is then retrieved using call 2. The third call is repeated for each group returned by the first call. Figure 5 shows how the results are displayed in the gadget. Figure 5: myexperiment gadget workflows Getting the runners available to the current user Due to technical limitations there is only one runner available in this PoC. All the information of the runner is stored in the gadget itself. The information that should be stored for each Taverna server is: Base URL (example.org:8080/taverna/v1/) Username Password or complete authentication String Posting the workflow to the Taverna server Figure 6 shows the REST calls that are used to post a job to a Taverna server. 11

12 myexperiment Opensocial container (with myexperiment gadget) Taverna server (example.org) GET /workflow.xml?id=[workflow id from list]&elements=content (1) Base64 encoded Scufl workflow file POST /users/[taverna user]/workflows (2) Url of posted workflow POST /users/[taverna user]/data (3) Url of posted input POST /users/[taverna user]/jobs (4) Url of posted job Figure 6:REST calls for posting job to Taverna server The first call is used to get the workflow file of the selected myexperiment workflow from myexperiment. This call results in a base64 encoded string that represents the scufl xml workflow that is required by the Taverna server. No authentication is required for this call. The second call posts the workflow to the Taverna server. The information that is posted is the base64 decoded scufl workflow returned by the first call. The following headers must be set in this request: Content-type: application/vnd.taverna.scufl+xml Authorization: Basic (base64 encoded username:password of the selected Taverna server) This call returns (among other things) the URL of the created workflow in the Taverna server. This URL will be used by the fourth call 3. The third call posts the input parameters associated with the workflow to the Taverna server. The information that is posted is the input parameters entered by the users wrapped in the following XML format: <?xml version='1.0' encoding='utf-8'?> <b:datathingmap xmlns:b=' <b:datathing key='[input ELEMENT NAME 1]'> <b:mygriddatadocument syntactictype='' lsid=''> <b:dataelement lsid=''> <b:dataelementdata>[base 64 ENCODED INPUT ELEMENT VALUE 1] </b:dataelementdata> </b:dataelement> </b:mygriddatadocument> </b:datathing> <b:datathing key=[input ELEMENT NAME 2]'> 3 At this moment the workflow is posted to the Taverna server each time the workflow is run. The Taverna server does not check if a workflow has been posted before and as a result many duplicate workflows exist on the Taverna server. 12

13 <b:mygriddatadocument syntactictype='' lsid=''> <b:dataelement lsid=''> <b:dataelementdata>[base 64 ENCODED INPUT ELEMENT VALUE 2] </b:dataelementdata> </b:dataelement> </b:mygriddatadocument> </b:datathing> etc.... </b:datathingmap> The following headers must be set in this request: Content-type : application/vnd.taverna.baclava+xml authorization : Basic (base64 encoded username:password of the selected tavern server) This call returns (among other things) the URL of the created input in the Taverna server. This URL will be used by the fourth call. The fourth call posts the job to the Taverna server. After this call the workflow is run on the Taverna server. The information that is posted is the workflow URL returned from call 2 and the input URL returned from call 3 wrapped in the following XML format: <?xml version='1.0' encoding='utf-8'?> <job xmlns:xlink=' xmlns=' <inputs xlink:href='[input URL]' /> <workflow xlink:href='[workflow URL]' /> </job> The following headers must be set in this request: Content-type : application/vnd.taverna.rest+xml authorization : Basic (base64 encoded username:password of the selected tavern server) This call returns (among other things) the URL of the created job in the Taverna server. We have chosen to store this URL together with the workflow title and the URL of the Taverna server as an activity in the OpenSocial container. This information is stored using the osapi.activities.create call as can be seen below: osapi.activities.create({ userid : '@owner', appid : 'myexpgad', activity : { title : [workflow title], streamurl : [runner URL], url : [job URL] }); Getting the status of workflows from the Taverna server Figure 7 shows the REST calls that are used to get the job status from the Taverna server that were posted by the user. 13

14 Opensocial container (with myexperiment gadget) Taverna server (example.org) Get activities (jobs) (1) GET job url (2) Job XML GET output url (3) Output XML Figure 7: Calls to get the current job information The first call (which is an internal call) is used to get all the jobs that have been posted by the gadget user. The call used is osapi.activities.get as can be seen below: osapi.activities.get({ userid : '@owner', appid : 'myexpgad'); This results in a list of jobs, and for each job the title, the job URL and the Taverna server URL. Before the second call is made to a Taverna server the gadget first verifies that the Taverna server URL returned by the job is also currently listed as a runner. Then the job information is retrieved from the Taverna server using the job URL and the following additional request headers: Accept : application/vnd.taverna.rest+xml authorization : Basic (base64 encoded username:password of the given Taverna server) This results in an XML document containing job information such as the job status and (URL) references to the input and outputs. If the XML contains a reference to an output this information is retrieved in the third call (using the same headers as in the second call). Figure 8 shows how this information is displayed in the gadget. 14

15 Figure 8: myexperiment gadget 15

16 3 PoC results and conclusions 3.1 Use case criteria and functionality As stated previously in paragraph 2.2, the focus of the use case was partially shifted from being able to online edit and create workflows, to combining the workflow storing and sharing capabilities and the ability to actually run the workflow online on a (shared) dedicated platform. As a result, not all required functionalities stated in [Appendix A] have been implemented. The PoC setup does not provide a solution for the creation and modification of workflows. However, with the slightly changed focus of the use case this Mashup PoC has successfully implemented the basic idea of combining different services into a new application that is exposed through an OpenSocial gadget. The demand for (open) protocol support was successfully met by using the OpenSocial standard for the end-user interface and the open source mashup workflow platform from Taverna. By choosing the Taverna platform users can use domain specific tools and with the current PoC-setup each domain, or group, could share its own (hardware) resources for running there tools. There is better availability for the end user. The (web) interface in the form of a gadget can be placed in an (OpenSocial) portal of choice, and there is now a dedicated environment to execute the workflows. The user does not have to install software on the local client and he does not need to possess the workflows or have it available on his own system. The (central) Taverna server, that is actually executing the tasks, can be equipped with the proper resources depending on the amount of users or the expected complexity of tasks. The user can relatively easy run potentially very powerful workflows that produce mashups. By using workflows the user enables the tracing of the scientific process and can track the current state and results of his tasks. The authentication of the user is done within the portal. The criteria to use services like SURFfederatie are met but are not mandatory for the provided solution. This will be highly dependable on the used gadget-portal. The PoC-setup grants access to the complete repository of myexperiment workflows. The initial requirement of creating new and separate user accounts for each user for saving workflows on the mashup platform was for that reason obsolete. 3.2 Results and findings An important issue revealed in this PoC was discovering the access and security details of an external service. The access details (including username/password) for the Taverna server were incorporated into the gadget code. In a real-world scenario, the access details of a service would have been defined by one person (or institution) and shared with a group of people that need access to the service. But in the current OpenSocial specification and SURFconext setup, there is no mechanism to store data specific to a group. A solution or at least some best practices should be defined that would help gadget developers tackle this specific issue. For example, SURFteams could be extended 16

17 to include team specific data or a SURFconext generic data service could be created that allowed storage and retrieval of shared data based on groups defined in SURFteams. Requesting data from myexperiment requires the gadget to know the user s ID at the myexperiment website. In this PoC, the user specifies his myexperiment user ID in the gadget s settings. A more preferred way would be to get the user ID from the SURFfederation, through the user s login into the portal. However, myexperiment is not connected to the SURFfederation and using the OpenID authentication method in combination with OAuth does not work correctly as was discovered in a user story from the 2009 COIN PoC4 (the redirects necessary for an OpenID authentication broke the OAuth redirect flow). A possibility is to leverage account or identity mapping in the SURFfederation. This would register alternate accounts for the same identity on the SURFfederation level and this information would be accessible to authorized services. In the meantime, the approach could be taken to let a user register different userid s from different services in the OpenSocial data, more specifically the Accounts data structure. This is the preferred location within OpenSocial to store a user s alternate account data. Gadgets could then utilize this data to connect to services with the appropriate userid. 3.3 Conclusion and recommendations The PoC Mashup-Technology has been completed and the results could enhance the use of Mashup technology within the scientific research community. Especially users with an interest in running and sharing workflows within there own (research) group can benefit from the accomplished results. Mashup platform users with an interest in sharing hardware resources could implement a similar setup as shown in this PoC. It would be very interesting for SURFnet to follow the upcoming releases of the Taverna software and its enhancements. The platform is already of very big interest to a part of SURFnet s users, the scientific researchers. They are already the early adopters of mashup and workflow platforms and are now looking to use them in an even more sophisticated manner. With exciting enhancements to Taverna, and a growing user base in social communities like myexperiment, it s recommended that SURFnet should explore the possibilities of Taverna as e-science tool within the Enabling Dynamic Services project (GigaPort3 program). The current version of the Taverna (remote execution) server lacks the support for group functionality and basic user authentication. This makes it very difficult to fully integrate/connect to the SURFconext (demo) portal as an end-user service. With the availability of a proper user authentication mechanism Taverna will also be interesting for further investigation within the context of SURFconext

18 Appendix A. Mashups use case This text has been taken from a non-published SURFnet document called Use-cases Proof of Concept Collaboration Infrastructure ; Hulsebosch, Wladimir Mufty, Frank Benneker;v0.9 Besides the Mashup use case the document contained several use-cases that were conducted within SURFnet s Collaboration Infrastructure project. A.1 Introduction A growing number of web users are combining different online information resources together. Combining two (or more) information resources on the internet can be viewed as a "mashup" of information. The characteristic of a mashup is that it is a fast and accessible way to combine existing information. The mixing of information within mashups can have multiple levels, from a mere presentation of two combined webresources to scientific analysis, calculations and modification of information using multiple datasets. To create a mashup user can use a mashup tool. These tools have a graphical interface and can often be used without programming skills or knowledge about creating web applications. The current mashup tools have a variety of functionality and user options. In the Technology Scouting "Mashup Technology for Research and Education" (SURFnet 2010) research and analysis was conducted on these tools. The Technology Scouting covered the applicability and usefulness of mashup tools for SURFnet users, with the focus on the scientific researchers. The Technology Scouting has shown that the available mashup tools can be divided into three main categories: General purpose Mashup environments. Enterprise Mashup platforms. Scientific Workflow environments. To analyze which type of mashup tools best fitted the needs of the scientific researcher s requirements were set and analyzed. These requirements include the desired mashup platform characteristics and properties which are of great importance to researchers. It can be concluded that the studied mashup tools differ in their available functionality. In addition, none of the tested tools actually fulfilled all of the requirements. The type of mashup tool that currently suits the needs of researchers the best can be found within the Enterprise Mashup Platforms & Scientific workflow environments. This deliverable contains a use case scenario that covers the usage of a mashup platform by scientific researchers. The related criteria are defined and shall be applied on a Proof of Concept that will be part of SURFwork s project COIN. The use case will be described from the point-of-view of an end-user. A.2 Context, conditions and criteria The set of identified requirements were presented and discussed with some mashup (technology) experts within the scientific community. Within different research fields several factors appear to influence the importance of the defined requirements. 18

19 The interviews showed that the success of a mashup platform does not depend on being able to handle very large amounts of data and dealing with a variety of user types and the diversity of the visiting public. More important requirements were that of (open) protocol support, the possible use of domain specific tools and the availability of mashup platforms. These requirements are most often already met within today s mashup tools. The Technology Scouting had a few requirements which were endorsed by the researchers but which are still not available within the current platforms. There are still requirements to be met on flexible authentication, tracing the scientific process and the extensibility options of a mashup platform. A.3 Use case: Mashup Technology for Research and Education In line with the results of Technology Scouting "Mashup Technology for Research and Education" plus the field study within the group of mashup experts a use case has been formed. The use case covers a combination of requirements that are not met yet or are still not available the in mashup platforms of interest. The use case illustrates the need for a web-based mashup platform with a strong focus on the scientific process and simple authentication method. The availability of open standards and the possible reuse of mashups by the user community is also an important factor. Isis is a researcher at the University of Leiden. She works within the escience research department. Just like her colleagues Isis uses a web based workflow tool with extensive mashup functionality. Because Isis is already logged on to her personal computer account she does not have to register for a separate account to make use of the workflowmashup tool. The tool is associated with the SURFfederation system, just like the other services she is using. The workflow-mashup tool is a web based version of the (client) application Taverna. Isis and her department have used Taverna for the past years, each on their own local computers. The tool gives her the same possibilities to mashup information resources and save them as part of a (scientific) workflow. She can create new flows, modify existing flows and save or export them. For her current project Isis logs on to the workflow-mashup tool via the SURFfederation system and creates a new flow, within the flow she combines 1 local dataset with an external data repository. She executes the flow and saves the mashup results to her local computer. She saves the flow and exports it for sharing purposes on the myexperiment.org website. On this website, scientific workflows are shared with other community members (figure 1). A.3.1 Required functionalities Based upon the above use case the following required functionalities can be identified: The user should be able to have access to the webbased Workflow-mashup tool. The available functionality of the tool should correspond with the offline client version of the tool. 19

20 The user is able to join the teams/groups and access them. Existing services like SURFteams en SURFfederatie can facilitate this. The user should have an own account within the workflow-mashup tool where her own files can be saved and stored for later use. The data processing and tooling should run on a remote machine and not as a local service on the machine of the user. A.3.2 Key criteria for Proof of Concept success The GUI layout and functionality should correspond with the offline version of the tool. This will make it easier for current users to find their way and continue with their current knowledge. The workflow-mashup tool should be bug free so it can execute workflows with its mashups without any problems. The speed and stability of the platform should be sufficient enough to support regular usage. The possibility to save and reuse the workflows. Figure 1. Web based Workflow-Mashup Tool Taverna Server Workflow-Mashup Tool Local information resources External information resources 20

21 Appendix B. References 1. Mashup Technology for Research and Education; Arjan Peddemors; Ref: indi ; (TS Mashuptechnologie v1.1).pdf 2. Taverna workflow system, 3. myexperiment Virtual Research Environment, 21