e-Science workbench: an Approach to Build Domain-specific Problem Solving Environments

1. e-Science workbench: an Approach to Build Domain-specific Problem Solving Environments 2008. 12. 11 Dongsoo Han1, Soonwook Hwang2 1Information and Comunication University 119 Munjiro, Yuseong-Gu, Daejeon, Korea 2Korea Institute of Science and Technology Information 335 Gwahangno, Yuseong-gu, Daejeon, Korea dshan@icu.ac.kr, hwang@kisti.re.kr Samsung-ICU E-Health Research Center Dongsoo Han, School of Engineering, ICU

2. Introduction

3. Backgrounds • The GRID infrastructure matures, and remote • devices such as sensors and electron • microscopes that can be handled through the • internet proliferates. • Scientists usually have no sufficient programming • skills to integrate available devices and services. • GRID toolkits are not successful for supporting • general scientists who are not familiar with • programming. • Need a new e-Science working environment.

4. General Issues in e-Science and Motivations • How can we put all the resources together so that researchers can easily access the resources to accomplish their research goals? • Provide the resources in a form of easily accessible services and provide tools to find and integrate such services. • Currently available Workflow, Web services and GRID technologies are not enough to support the needs from specific domains.

5. Our approaches • Develop domain-specific problem solving environments to facilitate the use of available services and resources for scientists to develop services and applications in their research domain. • Understand the characteristics and requirements of e-Science services and develop an e-Science workbench that satisfies such requirements. • In developing the e-Science workbench, adopt layered architecture so that we can use currently available technologies as long as possible.

6. e-Science Service Characteristics(1/2) • Service users often develop their own services by themselves. • Should be flexible in integration and development • Usually takes try and error approaches • Handles not only structured data but also semi-structured or unstructured data. • Often processes raw files and data • Thus filters, converters, auxiliary functions and facilities such as special purpose parsers often needed in the process • Involves huge data and high cost devices or computing resources. • Recovery is usually not a big concern.

7. e-Science Service Characteristics(2/2) • Focused more on the service process development rather than the service process automation. • Eg) Taverna Project, U-health service process development • Incorporation of GRID infrastructure and resources in service process. • Thus the key features of e-Science workflow should come out from the support of the service development process in GRID environment. • need to understand the development process of each domain • sometimes collaboration support is essential

8. Business Workflow vs Science Workflow business workflow feed back design, validation, simulation, running, monitoring science workflow area to focus Modeling/Design,validation, simulation, running, monitoring? developing stage running stage

9. e-Science Workbench

10. e-Science Workbench • Software system that helps scientists design • and automate their e-Science experiments on • the GRID or internet environments without the • support of programmers. • Equipped with a way of richer facilities than • conventional GRID toolkits • Need mechanisms or structures to • accommodate diverse e-Science requirements • - Layered architecture, Incremental approach

11. Workflow vs Workbench • e-Science workbench is usually positioned on the top of GRID workflow system that supports ad hoc workflow. • Workflow system is domain neutral, whereas e-Science workbench is better to be domain specific. • Bio workbench, U-health workbench, e-Airs workbench, .. • Workbench should be equipped with not only process modeling tool but also domain specific service development templates and associated facilities. • Health service process vs health service development templates • Unlike workflow system, e-Science workbench should be equipped with interfaces for process modeling, execution, monitoring/administration, and modification in integrated manner.

12. KISTI e-Science Workbench • Supports multi-grid platforms • gLite, Globus Toolkits • Separates common and specific parts of application domains for the efficient construction of workbench for each domain • Common part: Ontology, Web services incorporation • Specific part: Parameter sweeping, Analysis methods, … • Supports service development process for each domain • Based on flexible GRID workflow system that supports ad hoc workflow • Provides a unique means for the flexible and centralized control of distributed and autonomous resources • Ubiscripts

13. KISTI e-Science Workbench e-Airs workbench Life/Health workbench Bio workbench Applications e-Science Workbench Common Platform GRID workflow(WebVine) Ubscript Globus gLite

14. WebVine Workflow Management System • Workflow system adopted for KISTI e-Science workbench. • Provides facilities to access Globus or gLite toolkit and supports ad hoc workflow. • Incorporates web services and ontology technologies. • Light workflow management system • No transaction support • May not have a recovery mechanism • May not have an exception handling mechanism

15. e-Science Workbench Common Platform • Placed on the top of workflow system and contains common modules for e-Science workbenches. • Integrates user interfaces of workflow system. • Includes modules to support ontologies and other modules for the support of advanced features.

16. e-Science Workbench Platform e-Airs workbench Life/Health workbench Bio workbench • Ontology Based BPMT • Runtime Client • Admin/Monitoring Tool • Ontology Editor • Service Broker • Service Recommendation • Service Registration • Service Repository e-Science Workbench Common Platform GRID workflow(WebVine) Ubscript Globus gLite

17. Bio-Workbench

18. Ontology and Process Modeling Process Template Service Broker Process Manager Application Developers A Sub-process Service Pool Service Development Tool Service Developers

19. Bio-Workbench

20. Bio-Pipe • The first domain specific workbench developed on our e-Science workbench. • Supports biologists who want to find valuable information by integrating bioinformatics Web services. • Bio-pipe enables biologists to search and choose available Web services, and integrate the chosen Web services for the final results.

21. Biologists External Systems Users Internal User Admin/Moni tor ing Por tal Monitoring Web server mgm. DB mgm. Genome Viewer File/FTP mgm. Research Institutes • Genome viewer • Phenomeviewer • SNP viewer • Project • creation • Bio-pipe • design • Service • ontology • Service • import/export • Document • Board • WIKI • Monitoring • Program • User • Mail • 스카마관리 • 데이터의 조회 • 서버상태조회 • 이용자현황조회 • 리소스사용, • 활성화 조회 • 네트워크 부하 • 자료의 관리 • FTP 자료서비스 General Users KADO Portal Science-Technology Integration DB Servers Bio Workbench and Surrounding Components BioManager Bio Workbench BioPortal Participant E-Science Workbench Interoperaton WorkFlow Bioinformatics Web Server BioCell BioBody Search Engine Cell Data Human Body Info. Administrator 생명정보 시각화 정보 추출기 생명정보 색인 처리기 생명정보 지식 추출기 • 단백질상호작용 표현 • 대사, 신호전달경로 표현 • 해부학적 온톨로지 기반분류 및 시각화 • 질병학적 온톨로지 기반분류 및 시각화 National Knowledge Portal Genome DB Proteome DB Phenome DB SNP DB Library DB Drug DB

22. e-Science Workbench Platform A web site for Bio-Pipe contest: a hundred of bio-pipes are successfully submitted and deployed at http://biocommunity.kr.

23. Bio-Workbench Demo

24. U-Health Workbench

25. U-Health Workbench • U-health workbench aims to support doctors or medical experts in designing and delivering their proprietary u-health services to users. • Deals with various components such as bio-sensors, gateways, cellular phones, and service modules to support the construction of service scenarios. • Implemented on our e-Science workbench. • Assumptions • U-Health service requires various personalized services • The users of the workbenches are not programmers but doctors who have no skills in programming

26. Architecture of U-Health Workbench Application Level STRESS OBESITY DEPRESSION DIABETES ETC… Web Applications (Web Portal) Mobile Applications edit Process Level store execute retrieve u-Health Process u-Health Process Asset Library Process Designer WebVine BPM Engine XML messages (SMM, SQM, …) Service Level + u-Health Service Registry t1 t5 Web Services + Start Health Program Analysis t2 t3 t4 register Check Bio Data Type Store Data Validation Check User Registration develop /register discover Service Developer

27. U-Health Application Model • The U-health workbench provides a guideline based on a u-health application model. • The guideline is implemented in a form of a process template. U-health application model

28. An Application on U-Health Workbench U-Health 워크벤치 도구

29. Diagnosis Framework (DCAP)

30. User Interfaces

31. U-Health Workbench Demo

32. Commonly Used Technologies • Workflow based service integration and enactment. • Ontology based inference and service construction. • Integration of distributed DBs and devices. • Portal service incorporation. • Supports not programmers but domain experts in designing and running their services.

33. Summary • We developed an e-Science workbench on the GRID environment. • Two domain-specific workbenches are successfully developed on e-Science workbench common platform. • The three-layer structure of e-Science workbench was revealed useful in systematically stacking modules for building the entire e-Science workbench. • In order to announce the e-Science workbench to the public, more functions and modules must be prepared and more domain-specific e-Science workbenches should be developed in the e-Science workbench.

34. Thank you!