1. Part I Web Portals for Scientific and Engineering communities

2. Portals for scientific and engineering communities Seamless access to HPC resources Seamless access to instruments Data storage Application specific data base Visualization Tools Collaboratory Scientific notepads

3. Remote Resources Front-End FRONT-END: high-level user friendly - visual programming and authoring tools - application GUI RESOURCES: all hardware and software components needed to complete the user task, including, but not limited to, compute engines from workstations to supercomputers, storage, databases, instruments, codes, libraries, and licenses. Desktop/Laptop Seamless Access

4. Seamless Access Create an illusion that all resources needed to complete the user tasks are available locally. In particular, an authorized user can allocate the resources she needs without explicit login to the host controlling the resources. An analogy: NSF mounted disk or a network printer.

5. Example: Globus Advantages: - platform independent mini-language (RSL) for specification of resources - can be layered on top of different schedulers - enables interoperability between resources (can allocate many resources at a time, file transfer, monitoring, etc.) Disadvantage: - a bag of low level tools GRAM Client Gatekeeper Contact address Resource Language Specification MDS Directory Service GSS-API

6. Towards a complete solution... PSE: problem description (physics, chemistry,...) Task description: I need 64 nodes of SP-2 at Argonne to run my MPI-based executable “a.out” you can find in “/tmp/users/haupt” on marylin.npac.syr.edu. In addition, I need any idle workstation with jdk1.1 installed. Make sure that the output of my a.out is transferred to that workstation Middle-Tier : map the user’s task description onto the resource specification; this may include resource discovery, and other services Resource Specification Resource Allocation: run, transfer data, run

7. Remote Resources Front-End Middle-Tier Resource Specification Abstract Task Specification We need a third tier!

8. Target Architecture Middle-Tier Resource Specification Abstract Task Specification CTA specific knowledge databases Visual Authoring Tools User and Group Profiles Resource Identification and Access Visualizations Collaboration WebFlow Back-End Resources Problem Solving Environment

9. Example of a portal Navigate and choose an existing application to solve the problem at hand. Import all necessary data. Retrieve data Pre/post-processing Run simulations Select host Select model Set parameters Run

10. PSE Example: CCM IPSE Ken Flurchick, http://www.osc.edu/~kenf/Gateway 1.Define your problem 2. Identify resources (software and hardware) 3. Create input file 4. Run your application 5. Analyze results

11. QS Front End Compose interactively your application from pre-existing modules Data-Flow Front-End

12. Part II WebFlow

13. WebFlow design Object Oriented, follows JavaBeans model –everything is an object –objects interact through events Object A (event source) Object B (event target) Fire event E Method M(){ …} Firing event E by object A causes invocation of method M of object B. The association of event E and method M is achieved by an event registration mechanism. An event is also an object and it carries data.

14. A few words about CORBA (a digression) more information on Java, Corba, Distributed Object: http://www.npac.syr.edu/projects/cps616spring96/index.html

15. Distributed objects Typically WebFlow objects live in different address spaces. We use CORBA to invoke methods of the remote objects. Object A (event source) Object B (event target) Fire event E Method M(){ …} ORB

16. How is this possible? ORB2 Object A (event source) Object B (event target) Fire event E Method M(){ …} ORB1 IIOP - Objects A and B are CORBA objects (thus not Java objects) - Objects are defined in IDL (Interface Definition Language) - IDL definitions are compiled using (Java)IDL compiler - The IDL compiler generates new classes to be used by the Java compiler (javac) instead of the original ones, on both the client and server side - The IDL compiler generates either classes to be extended, or interfaces to be implemented Object Adapter serves also as a daemon

17. Example of IDL definition #include “..\BC.idl” module WebFlow { module lms{ interface runEdys:BeanContextChild { void run(); void receiveData(); void setParameter(in string p); }; interface runCasc2d:BeanContextChild{ void run(); void runAgain(); }; interface DoneEvent{ Object getSource(); }; }; }; We will create 3 CORBA objects * two modules: - runEdys - runCasc2d * one event - DoneEvent They will be added to package WebFlow.lms

18. We need more flexibility... WebFlow objects are developed independently of each other (reusable modules): we cannot assume that the event source knows anything about the event target and vice versa

19. Event binding addEventListener rmEventListener fireEvent(E,M) method M Event SourceEvent TargetAdapter Event ORB binding table DIIDSI

20. Controlling a module Applet Module Controls Proxy Module Module ActionButton1 ActionButton2 …. IIOP Another complication: Java sandbox!

21. Adding a remote module Local Host Add module Module Factory Proxy Module Remote Host FE request Add module Module Factory Module

22. Back to WebFlow design

23. CORBA Based Middle-Tier Mesh of WebFlow Servers implemented as CORBA objects that manage and coordinate distributed computation. Front End Gatekeeper Authentication Authorization

24. WebFlow Server The WebFlow server is a container object, a.k.a. context - in fact it implements JavaBeanContext class (Java1.2) The BeanContext acts as a logical container for JavaBeans (“WebFlow modules and services”) and BeanContexts.

25. User 1User 2 Application 1 Application 2 App 2App 1 WebFlow Server WebFlow server is given by a hierarchy of containers and components WebFlow server hosts users and services Each user maintains a number of applications composed of custom modules and common services WebFlow Services

26. WebFlow Context Hierarchy Master Server (Gatekeeper) Slave Server User Context Application Context Module Slave Server Proxy

27. Gatekeeper

28. Services User Modules Browser based Front-End Middle-Tier modules serve as proxies of Back-End Services Browser based Front-End User Space Definition and Task Specification Metacomputing Services Back-End Resources

29. Modules Similar to JavaBeans –full power of Java (or C++) to implement functionality –can encapsulate legacy applications May serve as Proxies –JDBC –metacomputing services (such as Globus) –schedulers (such as PBS, CONDOR, etc)

30. Services Services are modules provided by the system and offers a generic functionality –job services (submit,monitor,kill,... a job) –file services (edit,copy,move,… a file) –XML parser –database access –mass storage access –...

31. Example of a proxy module &(rsl_substitution = (MYDIR “/tmp/haupt”)) (DATADIR $(MYDIR)/data) (EXECDIR) $MYDIR)/bin)) (executable = $(EXECDIR)/a.out) (arguments=$(DATADIR)/file1) (stdout=(MYDIR)/result.dat)) (count=1) GRAM resource description Generate Data Run Job Analyze The Run Job module is a proxy module. It generates the RSL on-the-fly and submits the job for execution using globusrun function. The module knows only exec name, location and its arguments/parameters.

32. WebFlow over Globus In order to run WebFlow over Globus there must be at least one WebFlow node capable of executing Globus commands, such as globusrun Jobs that require computational power of massively parallel computers are directed to the Globus domain, while other jobs can be launched on much more modest platforms, such as the user’s desktop or even a laptop running Windows NT. Bridge between WebFlow and Globus

33. Secure Access: terminology Access Control (or Authorization) –Assurance that the person or computer at the other end of the session is permitted to do what he asks for. Authentication –Assurance that the resource (human or machine) at the other end of the session is what it claims to be Integrity –Assurance that the information that arrives is the same as when it was sent Accountability (or non-repudiation) –Assurance that any transaction that takes place can subsequently proved to have taken place Privacy –Assurance that sensitive information is not visible to an eavesdropper (usually achieved using encryption)

34. Secure Access Mutual authentication of servers and users –Certificates, Keberos/SecurID Access control –Full autonomy of the resources owner(s) –Akenti Privacy Integrity

35. SECIOP Security Model Front End Applet https authentication & authorization Gatekeeper delegation Stakeholders HPCC resources GSSAPI Layer 1: secure Web Layer 2: secure CORBA Layer 3: Secure access to resources Policies defined by resource owners https (SSL) AKENTI CORBA security service GSSAPI (Globus)

36. Distributed Objects are less secure can play both client and server –in client/server you trust the server, but not the clients evolve continually –objects delegate parts of their implementation to the other objects (also dynamically composed at runtime). Because of subclassing, the implementation of an object may change over time interactions are not well defined –because of encapsulation, you cannot understand all the interactions between objects are polymorphic (ideal for Trojan horses!) can scale without limit –how do you manage the access right to millions of servers? are very dynamic

37. CORBA security is built into ORB Secure Communications Authentication ClientUser EncryptionAuditAuthorization Server Encryption Credentials Object Adapter ORB

38. Authentication A principal is authenticated once by ORB and given a set of credentials, including one or more roles, privileges, and an authenticated ID. An authenticated ID is automatically propagated by a secure ORB; it is part of the caller context PrincipalCredentials Current ClientServer set_credentialsget_attributes authenticate

39. Privilege Delegation No delegation –The intermediary uses its own credentials Simple delegation –The intermediary impersonates the client Composite delegation –The intermediary uses both Client TargetClientTargetClientTargetClient Target Object IIOP

40. CORBA access model Based on a trusted ORB model: you must trust that your ORB will enforce the access policy on the server resource The ORB determines: if this client on behalf of this principal can do this operation on this object Server uses Access Control Lists (ACL) to control user access PrincipalRoleRightsOperation

41. Part III WebFlow Applications

42. Applications vary by the functionality of their Front-Ends –Front-End Applications must be pre-installed run fast, no restrictions –Front-End Applets no installation, but may take time to download sandbox restrictions apply, unless signed

43. Applications vary by how they are composed from modules –statically can by prepared in the Middle-Tier –dynamically the user composes them from reusable components

44. The modules can interact with each other in different ways: –through events (object oriented approach) –through ports (data flow model) –through message passing

45. Applications vary on how the Front-End interacts with the Middle-Tier –A complete task description is sent to the middle-tier composed of reusable modules predefined –Objects are added to the user context one at a time, and Front-End keeps their references

46. Landscape Management System (CEWES)

47. LMS Objectives To develop a web based system that implements a “navigate-and-choose” paradigm and allows the end user to: –Select (a set of) computational modules that provide answers to the problem at hand –Retrieve input data sets from remote sources –Use adequate (remote) computational resources –Visualize and analyze output data on the local host Anytime, anywhere, using any platform (e.g., a connected to the Internet laptop PC)

48. LMS: Changes in Vegetation lA decision maker (the end user of the system) wants to evaluate changes in vegetation in a geographical region over a long time period caused by short term disturbances such as a fire or human activity. lOne of the critical parameters of the vegetation model (EDYS) is soil condition at the time of the disturbance. lThis in turn is dominated by rainfall that possibly occurs at that time (CASC2D simulation) lInput data for the simulations are available from the Internet, such as Data Elevation Models (DEM) from USGS web site or from custom databases (spices characteristics)

49. LMS: Changes in Vegetation lData retrieval lData preprocessing lSimulation: two interacting codes ¶ EDYS · CASC2D lVisualization WMS EDYSCASC2D DEM Land Use Soil Texture Vegetation EDYS: vegetation modelCASC2D: watershed model WMS: Watershed Modeling System

50. LMS Front End Data retrievalData pre- and post-processingSimulations

51. Data Retrieval The data wizard allows the user to interactively select the data and download them to the local machine. The raw data are then fed to the WMS system launched from the browser to generate input files for simulations.

52. Launching coupled simulations on different Back-End computational resources Select host Select model Set parameters Run

53. WMS based Visualizations The results of the simulations are send back to the Front-End, and can be visualized using tools included in WMS package

54. Implementation of LMS Front-End (client) is a Java application –Data wizard, EDYS and WMS are run locally “navigate and choose” - no interactive composition of applications –EDYS, CASC2D, EDYS and CASC2D modules exchange data through message passing mediated by WebFlow client keeps the module references

55. slave Running LMS runCasc2d master UNIX WinNT slave runEdys lms.class Data wizard WMS exeCasc2d Web Server Web Server WebFlow Servers Client - WebFlow modules

56. Client code try { //add modules p1 = slaveNT.addNewModule("runEdys"); //as defined in conf.file runEdys re = runEdysHelper.narrow(p1); p2 = slaveUNIX.addNewModule("runCasc2d"); //as defined in conf.file runCasc2d rc = runCasc2dHelper.narrow(p2); //bind events master.attachEvent(p2,"Casc2dDone","Casc2dDone",p1,"run"); master.attachEvent(p1,"EdysStarted","EdysStarted",p2,"run"); master.attachEvent(p1,"EdysDone","EdysDone",p2,"runAgain"); //invoke methods of runCasc2dImp rc.run(); } catch(COMM_FAILURE ex) {System.err.println(ex.getMessage()); System.exit(1);}

57. Write slave Interactions between components runCasc2d master UNIX WinNT slave runEdys lms.class Data wizard WMS exeCasc2d Web Server Web Server casc2d IIOP http Write http

58. Quantum Simulations

60. QS: WebFlow implementation

62. Implementation of QS Front-End (client) is a Java applet applications are created dynamically from pre- existing modules modules exchange data through ports (data flow model) server keeps the module references; the references are published on a web site

63. QS: Front-End

64. Building an application XML A visual representation is converted into a XML document XML service Web Server save parse ApplContext Generates Java code to add modules to ApplContext Publishes IOR Front-End Applet Middle-Tier

65. Document Type Definition <!DOCTYPE taskspec [ <!ATTLIST taskspec UserContextRef CDATA #REQUIRED AppName CDATA #REQUIRED> <!ATTLIST module modulename CDATA #REQUIRED host CDATA #REQUIRED > <!ATTLIST out modulename CDATA #REQUIRED eventname CDATA #REQUIRED <!ATTLIST in modulename CDATA #REQUIRED method CDATA #REQUIRED > ]>

66. Example XML document

67. Object Oriented Applications

68. Mobility System’s Applications Coordinates transformations databases Remote HPCC resources - object oriented approach - implementation: - CORBA based Middle-Tier - bean-box type API - JDBC proxy modules - Web interface to store data in DB in variable format - Data transfer from DB to a visualization engine - Coordinates transformations on a remote server - Launching simulations on remote hosts with interactive input

69. Part IV Gateway: Portal for Computing

70. Target Architecture Middle-Tier Resource Specification Abstract Task Specification CTA specific knowledge databases Visual Authoring Tools User and Group Profiles Resource Identification and Access Visualizations Collaboration WebFlow Back-End Resources Problem Solving Environment

71. Design Issues Support for a seamless access (security) Support for distributed, heterogeneous Back-End services (HPCC, DBMS, Internet,...) managed independently from Gateway Variable pool of resources: support for discovery and dynamical incorporation into the system Scalable, extensible, low-maintenance Middle Tier Web-based, extensible, customizable, self-adjusting to varying capacities and capabilities of clients (humans, software and hardware) front end

72. Gateway Implementation Distributed, object-oriented middle tier –CORBA objects (Gateway Containers, Gateway Modules and Gateway Services) implemented in Java. [ Scalable, extensible, low-maintenance middle tier] –Containers define the user environment. –Modules and Services serve as proxies: they accept the user requests (Front End) and delegate them to the Back End. [ Support for distributed, heterogeneous back-end services managed independently from Gateway] Note: modules can be implemented in C++; also can be DCOM components

73. Gateway Implementation (2) Gateway operates in a keberized environment [Support for a seamless access] –tickets are generated on the client side –Keberos-based CORBA security service is used to manage the user sessions –Globus GSSAPI implemented over Keberos is used for resource allocation

74. Gateway Implementation (3) Task Specification is expressed in XML –CTA independent –Decouples implementation of the Front End and the Middle Tier –Allows for an abstract (platform independent) task specification, and thus the Middle Tier may act as a resource broker Resource Specification is expressed in XML –Simplifies match-making and resource discovery –Simplifies generating Globus RSL in-the-fly [Support for distributed, heterogeneous Back-End services; Variable pool of resources; Scalable, extensible, low-maintenance Middle Tier]

75. Gateway Implementation (4) Component-based Front-End [extensible] Front-End Components (“toolbox interfaces”) are –applets (interfaces for common services) –XML pages or frames [Web-based, extensible, customizable, self-adjusting] All components (Front End, Middle-Tier) are defined in XML and contain metadata (used for component mining)

76. Front End

77. CTA specific knowledge database –requires server side support (both the middle tier and the back-end) through well defined interfaces –should be constructed from reusable or cloneable components –allows for identification of software components best suited to solve the problem at hand

78. Visual Authoring Tools Allows for composition of the computational task from components (reusable modules) Different tools to support various programming models such as data parallel, task parallel, data flow, object oriented No assumption on granularity Metadata about components and support for archiving and mining the components Support for instrumentation and steering

79. Example: Data Flow

80. Example: DARP

81. User and Group Profile Controls the user/group environment –file access –job monitoring –... Allows for customization –preferences –users with disabilities –... History of actions Scientific notebook

82. Resource Identification and Access Computational resources –hardware, software, licenses –desktop applications Data –file systems, mass storage, distributed databases –Internet data repositories Networks

83. Front-End infrastructure

84. Front-End Support Portal Page User Context Control Applet Navigator (extensible, customizable) PSE specific toolboxes –A placeholder for the Problem Description toolboxes –A placeholder for the code toolbox –Resource request toolbox –Data postprocessing toolbox Other (Collaboration, Visualizations, …)

85. User Context Represents a Gateway session. The session is associated with a user (or group) profile. WebFlow extends the notion of the UNIX profile via the 'User Data Base' (UDB). This UDB contains information about submitted jobs, history of the users actions, and other user state information. The user context may also contain application/front-end specific information.

87. Control Applet The control applet is responsible for maintaining the session, and direct communication with the middle-tier. Direct communication is the most efficient, but since it is buried into an applet, this mechanism is not readily customizable. The generic services, such as file service (upload, download, edit, copy, move, delete) and job services (show current jobs/show queues/kill jobs) will be supported this way. [combination of the user context and a query] The Gateway will also support a non-direct communication with the middle-tier through servelts.

88. Screen Dump of the Control Applet

89. Navigator The navigator allows the user to select and customize toolboxes. Embedded in a separate frame, it consists of menus, buttons, links, etc, derived from an XML document. The navigator is a hierarchical, extensible and customizable.

91. Problem description toolboxes The problem description is application specific, and the Gateway only provides a general framework for creating a PSE. The most important part is the specification of what services (middle and back tier) are needed, what is their API, and how to add new services. Example services: access to databases, XML parsing, generating HTML in-the-fly, file services.

92. Code toolboxes The end user see it as a mapping between the problem description and software to be used to solve the problem. Actually, it identifies WebFlow modules and their parameters to be used to construct the application (see resource request toolbox below). The module parameters may include input files, and if necessary, the input files are generated at this stage (using this or a separate toolbox). In addition, some parameters will be constructed from information stored in data bases, including UDB, and other sources.

93. Resource Request Toolbox The front-end activities result in an abstract task specification. Abstract in the sense that the user may not know nor care what actual resources are used. The task is composed of independently developed modules and services following different programming models.

94. Other toolboxes Visualizations Collaboration Scientific notebook...

95. Middle-Tier

96. User 1User 2 Application 1 Application 2 App 2App 1 WebFlow Server WebFlow server is given by a hierarchy of containers and components WebFlow server hosts users and services Each user maintains a number of applications composed of custom modules and common services WebFlow Services

97. CORBA Based Middle-Tier Mesh of WebFlow Servers implemented as CORBA objects that manage and coordinate distributed computation. Front End Gatekeeper Authentication Authorization

98. Back End

99. Back End Services Access to HPCC (via Globus) Access to distributed databases (via JDBC) Access to mass storage Access to the Internet resources Access to desktop application and local data Access to code repositories

100. Gateway Security

101. SECIOP Security Model (Keberos) Front End Applet SECIOP authentication & authorization Gatekeeper delegation HPCC resources GSSAPI Layer 1: secure Web Layer 2: secure CORBA Layer 3: Secure access to resources Policies defined by resource owners

102. Building Gateway Components

103. Middle-Tier is given by a mesh of WebFlow Servers that manage and coordinate distributed computation. Gateway applications are composed of independent reusable modules Modules are written by module developers who have only limited knowledge of the system on which the modules will run. The WebFlow system hides module management and coordination functions

104. How to develop a Gateway component (or a toolbox) Back-end service Middle-tier proxy Front-end controls

105. How the Back-End interacts with the rest of the system? Often, your job do not need to interact. –Using GRAM and GASS you stage data and executable, submit the job and retrieve output. –Using DUROC you can coallocate resources and run MPI-based parallel/distributed codes. The messages between nodes are sent outside Gateway control or support. –HPF runtime will distribute your job and facilitate interprocess communication.

106. Implementing Back-End Services If you need to interact –Using a separate module, you may move files between nodes while your jobs are executing –Your job may be a server (e.g., database, GRAM) [if socket listener - be careful about security!] –Your job my be a CORBA client (Java, C++) –...

107. What does it take to develop a Gateway module (a proxy) ? Many come as a standard Gateway modules User’s modules –Are CORBA objects Define IDL (as an XML document) Compile IDL (in the tie mode) Implement the functionality of the module Implement events Develop Front-End controls that invoke methods of the module

108. Selecting a Predefined Task

109. Gateway/WebFlow Mission seamless access to remote resources –through a Web based user interface –customized application GUI high-level user friendly visual programming and runtime environment for HPDC portable system based on industry standards and commodity software components

110. Updates Contact person: Tomasz Haupt haupt@npac.syr.edu voice (315) 443-2087 http://www.npac.syr.edu/users/haupt/WebFlow/