11a.1 Grid Portals Copyright B. Wilkinson, This material is the property of Professor Barry Wilkinson (UNC-Charlotte) and is for the sole and exclusive use of the students enrolled in the Fall 2008 Grid computing course broadcast on the North Carolina Research and Education Network (NCREN) to universities across North Carolina. Oct 24, 2008

11a.2 Grid Portal Web page designed to provide a user- friendly interface to a Grid computing environment rather than a command line interface.

Dynamic Content Portal must support dynamic content, that is, Web pages that can be altered to display different information during viewing. 11a.3

Hosted as a dynamic Web page on a server. Accessed by user through a Web browser from anywhere. The portal should: – Hide details of the Grid middleware – Provides single sign-on to access to Grid computing services, distributed resources and Grid information. 11a.4

11a.5 Provides access to Grid computing services: Security Services –Management of certificates Remote File Management –Access to files and directories –Moving files Remote job management –Job submission –Workflow management Grid information services –Static information (machine type, etc.) –Dynamic information (machine load, etc.)

11a.6 Access to Information Portals also provide access to information -- anything related to tasks at hand, including communication with virtual organization. In fact, some portals started simply as informational portals in the same vein as web portals such as yahoo.

Generic layout of a Grid portal 11a.7

A Grid portal comes in one of two forms: 1.General-purpose portal - front-end to a Grid computing platform in non-specific application domains, e.g.: –SURAGrid portal –Our Grid computing course portal 2.Portal tailored to a particular application domain, e.g. a bioinformatics portal. –Application-specific portal should provide access to specific tools of application domain. Terms Science portal - emphasis in science domain. Gateway also used to describe a portal, e.g. Science gateway for scientists. Scientists in this context could mean many scientific disciplines such as physics, chemistry, biology, etc. Any self-respecting Grid computing project has a portal. 11a.8

11a.9

Portal Toolkits A software framework and components to put together a portal easily. Ideally re-useable software components Potentially components developed by others can be incorporated. Ideally, standard interfaces should exist. Ideally, presentation layer that the user sees should be separated in software construction from back-end. 11a.10

11a.11 Available Technologies for putting together portal toolkits

Dynamic Content Refers to a Web page display that can be altered as opposed to static content. Dynamic content can be done: 1. At client side, that is, after the page is downloaded. –Downloaded HTML page has embedded code –JavaScript language specifically for such embedded code –All browsers support JavaScript. 2.At server side –When Web client makes request within a Web page, server receives this request and sends appropriately altered HTML page, which is then displayed. Client-side and server-side methods can be used together. Grid portals can use client-side dynamic content but generally require server-side dynamic content. 11a.12

Generating server-side dynamic content Can use languages such as C and Java to create HTML pages. Technologies specifically for generating server-side dynamic content : CGI (Common Gateway Interface) –Oldest - standard protocol between Web servers and client applications PHP (originally Personal Home Page, now Hypertext Preprocessor) – Scripting language specifically designed for server-side dynamic content –non-Java technology ASP.NET (Active Server Pages.NET framework) – Microsoft Web application framework that can provide dynamic content – Successor to ASP (Active Server Pages). – Non-Java technology Java Servlets JSP (Java Server Pages) Many Grid portals focus on Java implementations using Java Servlets/JSP 11a.13

Java Servlets Small Java programs (objects) that receive requests from Web clients and generate responses, usually handling HTTP requests/responses. Allows a software developer to add dynamic content to a Web server using Java platform.* Generate content commonly HTML but may be other data such as XML.* Can maintain state across server transactions by various means. javax.servlet package defines required methods that must be implemented for client-servlet interaction. * 11a.14

Servlet container A Web server that provides environment for servlets Maps URLs to specific servlets. servlet engine - Another term for servlet support. e.g. Apache Tomcat, used in assignment 7 with Gridsphere portal 11a.15

Using Java servlets alone would typically require invoked Java programs to create HTML using println statements. Java Server Pages (JSP) A complementary SUN technology to Java servlets. Used to create Java servlet code from static content. JSP file is an HTML page with embedded JSP tags. JSP tags provide for creating servlet Java code. This Java code created automatically from JSP file by JSP compiler. Code might be fully compiled machine-executable code or Java byte code executed by a JVM. 11a.16

JSP/Java servlet environment 11a.17

JSP tags Five tags, Three tags available for inserting code. declaration tag ( ) Used to declare variables and methods, i.e.: <%! Java variable declarations or/and Java methods %> 11a.18

JSP tags scriptlet tag ( Used to include Java code including variable declarations and methods, but broader to include any Java code fragment, i.e.: <%! Any Java code fragment %> 11a.19

JSP tags expression tag ( ) Will compute a Java expression and convert result into a string that is inserted in-line into HTML code, i.e. HTML code 11a.20

Other JSP tags directive tag ( ) - Provides information about the JSP page. Can extend functionality of tags and include other files. Example action tag - To invoke server-side JavaBeans, transfer control to another page, and support for applets. More information: 11a.21

11a.22 JavaBeans Java classes used to encapsulate many objects into a single object (the bean), so that the bean can be passed around rather than the individual objects.

Commodity Grid (CoG) Kits Conceived during Globus development from 1996 – Objective Combining commodity software technologies with Grid components (hence the name “Commodity Grid Kit”) and providing a higher-level interface to Grid components. 11a.23

“Commodity technologies” Accepted software components –Common libraries, –Programming languages such as Java, C, and Python –Standard distributed computing frameworks Standard network protocols Should not be confused with hardware commodity components. 11a.24

Java CoG kit First most prevalent Commodity Grid Kit Provides Java APIs that enable one to: –Submit and monitor Globus jobs –Transfer files by CoG calls within a Java application program Avoids lower level Globus APIs, which change from one version to another CoG kit development continued during same time period as Globus. Python version. 11a.25

11a.26 Commodity Grid (CoG) Kits Used within GT3.2 and GT4: Java-based GSI, gridFTP, myProxy, GRAM. A part of CoG kit, known as JGlobus now included in Globus 4 distribution. CoG kit provides support for portal developers.

CoG kit program to transfer files (Villalobos 2007)

11a.28 Early Portal Toolkit Examples Late 1990s: Grid Portal Development Kit (GPDK) – JSP for presentation layer – JavaBeans and Java CoG back-end. – GPDK is not now supported NPACI Grid Portal Toolkit (Gridport) (National Partnership for Advanced Computational Infrastructure) – HTML for presentation layer and Perl/CGI Ninf/Gridspeed portals –JSP/Java Servlet for presentation layer – Java CoG back-end

11a.29 From (Li and Baker, 2005).

11a.30 Examples

11.31 MPI program Starting job From a paper”Building GridPortals: The NPACI Grid Portal Toolkit” by M. P. Thomas and J. R. Boisseau. NPACI Hotpage Grid portal (based upon GridPort)

11a.32 Adapted from slides “The NCSA Alliance Portal and the Open Grid Computing Environment Project” by D. Gannon, G. Fox, B. Plale, M. Pierce, M. Thomas, C. Severance, G. von Lazewski, and J. Alameda.

11.33 DOE Fusion Grid Portal Adapted from slides “Reuseable Grid Portral Components” by M Thomas.

11a.34 Linked Environments for Atmospheric Discovery (LEAD) Adapted from slides “Reuseable Grid Portral Components” by M Thomas.

11a.35 Early grid portals “tools” not very flexible. Tied to specific programming tools and Grid software, such as Globus 2.4. Specific programming structure not suitable for users to develop portals themselves. Not standardized APIs.

11a.36 Portal Implementation Should be flexible, meet grid industry standards, be able to be extended using parts developed by others. General approach currently is to use “software components” called portlets.

Portlets A general approach for portal design developed in the early-mid 2000’s Presentational layer of portal constructed with portlets – software components Each portlet provides specific functionality and a window within portal Each portlet can be associated with a particular service User can have any number of portlets (will be associated with user’s persistent context). 11a.37

11.38 Portal Layout

11a.39 Portlets provided for all the functionality expected to access Grid resources, including: Proxy certificate management Job submission and run-time management Remote file transfers Access to information services (resource status…) Collaborative tools ( , chat, discussion boards…) and also depending upon application, specialized portlets for interfacing to domain specific applications.

Portlets 11a.40

Portlet server and portlet container Portlets can be compared to servlets and requires a similar environment called a portlet container managed by a portlet server. In general, portlets do not communicate with each other, only with the services they front-end, and only provide for the presentation-level. With the portlet approach, it should be easy to reconfigure user’s view. Different portlets from different sources should be able to be plugged into portal. 11a.41

Portlet development Several groups developed portlet API’s including: IBM’s Websphere portlet API’s Open-source Apache Jetspeed project. After early experiences of portal designs in mid-late 1990’s, effort made to develop a Java portlet specification in period leading to Java Specification Request JSR 168 Portlet Specification released in Oct JSR 168 Based upon Apache Jetspeed portlets. 11a.42

Java Specification Request JSR 168 Portlet Specification (Also called Java Portlet Specification version 1.0) Portlet code generally has the following structure: 1. Initialize 2. Render portlet 3. For a request received: Accept request and perform required back-end actions Render display according to result 4. Finalize and destroy portlet 11a.43

11a.44

11a.45 National Science Foundation Middleware Initiative (NMI) Started in 2001 initially over 3 years “to create and deploy advanced network services that simplify access to diverse Internet information and services.” Provided a centralized location for important grid software including Globus, Condor, MPI-G2, and: – A new grid portal project called OGCEGrid (funding started Sept 2003).

11a.46 Consortium established “Fall 2003 to foster collaborations and shareable components with portal developers worldwide”

OGCE portal release 2 Consisted of a core set of JSR 168 compatible Grid portlets. Portal independent of specific container. Two portal containers supported: –uPortal –GridSphere Originally GridSphere and OGCE2 together described as a OGCE2/GridSphere portal, but subsequently isimply referred to as GridSphere. 11a.47

11a.48 GridSphere Portal framework provides an open- source portlet based Web portal.

11a.49

11a.50 Core GridSphere portlets Login Locale, profile and layout personalization Administration portlets for creation of users, groups, portlet management Localization support French, English, Spanish, German, Dutch, Czech, Polish, Hungarian, Italian, Arabic, Japanese, and Chinese onto which many other portlets can be installed from various sources, for example: myProxy server portlet, Globus job submission and control portlets, information services portlets collaborative tools such as Sakai, etc.

11a.51 Assignment 7 Goal: To learn how to deploy portlets within Gridsphere. Makes underlying software structure of JSR 168 grid portals more concrete. Design a portlets for specific front-ends

11a.52 Structure Apache Tomcat servlet engine Gridsphere portal framework Deploy Portlet

11.53 Step 1: Download and Install Tomcat Testpage:

11a.54 Step 2: Download and Install Gridsphere After downloading and installing Gridsphere, Gridsphere located at:

11.55 Goto to get set-up screen:

11a.56 After filling details, get usual Gridsphere screen. Similar to course portal except PURSe registration portlet not installed (a separate package):

11a.57 Creating your own portlet Goal Create and deploy a portlet that will accept one number and say whether it is odd or even (“oddeven” portlet) The code for this portlet is given. You simply have to deploy it. Later you will to ceate your own portlets.

11a.58

Portlet layout 11a.59

11a.60 Files Gridsphere provides tool to create template files. Portlet designer then needs to provide java source file that does the required evaluation, and Provide/modify three portlet deployment descriptor files.

11a.61 HTML/JSP file HTML page layout defined in JSP file called MainPage.jsp Mostly simple HTML code modified with JSP tags added at beginning.

11a.62 MainPage.jsp This portlet will figure out if the inputed number is even or odd.

11a.63 JSP tags added at beginning. creates renderRequest, renderResponse and portletConfig objects. declares that custom tags used defined in a tab library given by URI,and provides prefixes names.

11a.64 Java portlet code public class OddEven extends ActionPortlet { private static final String DISPLAY_PAGE = "MainPage.jsp"; public void init(PortletConfig config) throws PortletException { super.init(config); DEFAULT_VIEW_PAGE = "prepare"; } public void action(ActionFormEvent event) throws PortletException { TextFieldBean value1 = event.getTextFieldBean("valueTF1"); TextBean answer = event.getTextBean("answer"); int val = Integer.parseInt( value1.getValue() ); if (value1.getValue() == null ) { answer.setValue(""); } else { if( isEven(val) ) { answer.setValue("The number: " + value1.getValue() + " is Even"); } else { answer.setValue("The number: " + value1.getValue() + " is Odd"); } setNextState(event.getActionRequest(), DISPLAY_PAGE); } public void prepare(RenderFormEvent event) throws PortletException { setNextState(event.getRenderRequest(), DISPLAY_PAGE); } public boolean isEven(int val) { return val % 2 == 0; }

11a.65 Deployment descriptor files Three deployment descriptor files needed to create a portlet: Portlet.xmlJSR 168 standard, describing portlet Layout.xmlGridsphere file describing layout of portlet within page Group.xmlGridsphere file describing collection of portlets (There are other deployment files, which generated automatically during deployment.)

11a.66 Odd Even Odd Even edu.uncc.abw.portlets.OddEven Layout.xml Specified columns and rows of a table in portlet. Components are in cells of table. Path to portlet code (There is an alternative format using # symbol)

11a.67 group.xml Specifies group for portlet demo The demo group PUBLIC edu.uncc.abw.portlets.OddEven USER Group name Portlet

11a.68 Portlet.xml … Odd Even Portlet OddEven Odd Even Portlet edu.uncc.abw.portlets.OddEven 60 text/html edit help en Odd Even odd even Portlet

11.69 Directory Structure src holds directory structure leading to java source file webapp holds deployment descriptor files

11.70 webapp\WEB-INF directory Layout.xml Portlet.xml Group.xml

Web Services for Remote Portlets (WSRP) Standard introduced by OASIS for defining a Web service interface for interacting with “presentation- oriented Web services” in 2003 (version 1) Uses WSDL for its interface description. WSRP Version 2 introduced in a.71

JSR 286 Portlets Specification v2.0 Updated version of JSR 168 released in June 2008 after about fives years of development. Backward compatible with JSR 168 portlets JSR 168 portlets can be deployed in JSR 286 portlet containers. JSR 286 incorporates inter-portlet communication, which was absent in JSR 168. JSR 286 includes an alignment with WSRP v 2. 11a.72

11.73 More Information on Gridsphere See the links on the Gridsphere portal page

11.74 Questions