Docstoc

Grid Portals – A Gateway to Grid

Document Sample
Grid Portals – A Gateway to Grid Powered By Docstoc
					Building Web Portals as
  Science Gateways
                    Marlon Pierce
               mpierce@cs.indiana.edu
with slides from Dennis Gannon, Ahmet Sayar, Galip
                        Aydin
                  Indiana University
                Outline of Talk
• Overview of computing portals as gateways to
  cyberinfrastructure.
  – With several example projects
• Architectures and standards of computing
  portals.
  – Review of portal architectures
  – Review of JSR168
• Building science portals.
  – With a motivating example
• New technologies and techniques
  – JSF
  – AJAX
 Computing for the Greater Good
• Recent devastating natural disasters have
  demonstrated the need for large scale,
  distributed scientific computing.
  – Katrina, Rita, …
  – Christmas 2004 tsunamis
  – Earthquakes in Pakistan and future major
    earthquakes in California, Japan, …
     • 1906 was 99 years ago…
• Research in large scale distributed computing
  can make a difference in people’s lives.
• But many challenges lie ahead.
 Cyberinfrastructure (CI) Overview
• Cyberinfrasture combines
   – Grid computing:
      • Globus toolkit, Storage Resource Broker, Condor, UK OMII, OGSA-
        DAI, etc.
      • Provides the software for tying together distributed computing
        resources
   – High speed networking
   – Hardware: supercomputers, clusters, workstations
   – Applications: modeling, simulation, data analysis codes in many
     fields.
   – Data: raw, cooked, shared, derived, cataloged, etc.
   – Information/Internet Technology: web services, portals,
     databases, XML, semantic web/grid, audio/video collaboration,
     shared Web spaces, etc.
   – People
      • Cyberinfrastructure is supposed to enable remote collaborations
        and distributed teams.
      • This is the reality of a lot of science (and science funding)
                 Scientific Challenges                                            Genetics and Disease Susceptibility


                    Science Communities and Outreach
• The current and future                                                Phenotype 1    Phenotype 2   Phenotype 3 Phenotype 4



  generations of scientific                                    Age
                                                              Gender
                                                                                                                                    Ethnicity
                                                                                                                                  Environment
     • Communities
  problems are:                                       • Partners                            Identify Genes

        •                                                    • Caltech
   – DataCERN’s Large Hadron Collider
           Oriented (CI challenge)
          experiments                                        • UniversityMetabolism
                                                                                              Pharmacokinetics
                                                                                        of Florida Endocrine
       •
                                                                                               Biomarker
           Increasingly stream HEP and                       • Open Science Grid and Grid3
           • Physicists working in based.
                                                                                  Phy siology                   Proteome
                                                                                               Signatures
                                                                                         Immune             Transcriptome
                                                             • Ferm ilab
       •   Often need petabyte archives
             similarly data intensive scientific
                                                                                               Morphometrics

                                                             • DOE PPDG e Dise ase Susce ptibility
       •   But linking data to applications
             disciplines                                     • CERN
                                                                               Pre dictiv
                                                             Source: TerryMagnuson, UNC
                                                                                              Storms Forming
           across groups is a general
           • National collaborators and those                • NSF GriPhy n and iVDGL
           problem. digital divide in
             across the                                      •
                                                    Streaming EU LCG and EGEE
                                                                                                                Forecast Model



   – In need of on-demand                          Observations              Data Mining
           disadvantaged countries                           • Brazil (UERJ,…)
                                                             • Pakistan (NUST, …)                                      On-Demand
     computing resources (CI
      • Scope                                                • Korea (KAIST,                  …)
                                                                                                                    Storm predictions

     challenge)
         • Interoperation between LHC
   – ConductedHierarchy and ETF
           Data Grid by                                                      LHC Data Distribution Model

         • Create and Deploy Scientific
     geographically distributed
     teams of specialists
           Data and Services Grid Portals
         • Bring the want to become
       • Who don’tPower of ETF to bear
           on LHC Physics Analysis: Help
         experts in grid computing.
            discover the Higgs Boson!
           Science Web Portals
The goals of a Science Web Portal are
  – To give a community of researchers easy access to
     •   Computational applications and tools
     •   Primary data, shared data, derived data
     •   Computational resources
     •   All are needed to solve today’s scientific and engineering
         problems.
  – To do this in a discipline specific language that is
    common to the target community.
• Science Portals are “gateways” to underlying
  Grid tools
  – Grids provide access to computing resources
  – Gateways manage the user’s interaction with the grid.
    What is a Science Portal?
• A standards-based web portal
  – Provides each user with
     • a secure way to login and authenticate identity
     • A view of a private workspace for accessing and
       managing data and tools
• Tutorials and community news
  – Announcements of new services
• Collaboration tools
  – Chat, calendaring, group messaging
• Core Science Functions …
    Portal Science Capabilities
• Data Access is the most important
  – Allow the user community access to important shared
    data resources
     • Visualize it, publish it, download it, curate it.
  – Data Discovery
     • Searchable metadata directories.
• Web access to important tools
  – Web-form interfaces to allow users to run important
    community codes
  – Webstart access to common java-based tools
• Workflow tools
  – Allow users to combine community codes into
    workflows managed by the portal back-end
    resources.
Let’s look at a few real
       examples
(about a dozen … many more
           exist!)
ServoGrid Portal
                        NEESGrid
Realtime access to earthquake
Shake table experiments at remote sites.
Geological Information Grid Portal
            Mesoscale Meteorology
NSF LEAD project - making the tools that
are needed to make accurate predictions of
tornados and hurricanes.
 - Data exploration and Grid workflow
                        Renci Bio Portal
Providing access to biotechnology tools running on a back-end Grid.

- leverage state-wide
  investment in
  bioinformatics
- undergraduate &
  graduate education,
  faculty research
- another portal
  soon:
  national evolutionary
  synthesis center
               SCOOP ADCIRC Interface

                                               Set Run Dates




                                                                                    Katrina Storm Surge Prediction
                                              Current ADCIRC grid                   (Leuttich/Blanton)
                                                Decomposition




•   SURA SCOOP
     –   Southeastern Coastal Ocean Observing Program
•   Advanced Circulation Model (ADCIRC)
     –   Finite Element Hydraulic Model for Coastal Areas, Inlets and Rivers
           •   Rick Luettich (UNC), Joannes Westerink (Notre Dame)
           •   Randall Kolar (Oklahoma), Clint Dawson (Texas), Corps of Engineers
•   Collaborators:
     –   Leuttich/Blanton (UNC Marine Sciences)
     –   Ramakrishnan/Lander (RENCI)
X-Ray Crystallography
                          Flood Modeling
                                                                             • University of
                                                                               Texas
                                                                                 •TACC
                                                                                 •Center for
                                                                                  Research in
                                                                                  Water Resources
                                                                             • ORNL
                                                                             • Purdue




Large-scale flooding along Brays Bayou in central Houston triggered by
heavy rainfall during Tropical Storm Allison (June 9, 2001) caused more
than $2 billion of damage.
                  Gordon Wells, UT; David Maidment, UT; Budhu Bhaduri, ORNL, Gilbert Rochon, Purdue
      Teragrid Gateway Portals
• TeraGrid
  – The largest “public” super-
    computing grid in the US.
    • 50 TFlops
  – Massive Data storage capability
    • Over 1 Petabyte on-line storage
• TeraGrid Gateways
  – Access points for communities.
  – Two types:
    • A gateway between 2 grids
       – Open Science Grid gate way is one example.
  – Science Community Portal is the other type
    • Includes LEAD portal, Nanohub, Renci Bioportal, NVO
• An additional set of new science portals just being
  developed.
The Portal as a Service Framework
• Many important science portals are
  designed to access and orchestrate stand-
  alone web services and databases
• Others are service frameworks that sit on
  top of an existing Grid, such as TeraGrid.
• In both cases:
  – The architecture is similar
  – Common portal services are often shared
• A Common architecture is emerging
    The Architecture of Gateway Services
The Users Desktop.

                                                      Grid
                                                  Portal Server


  Proxy Certificate                                Gateway Services                               User Metadata
   Server / vault                                                                 Application
                                    Application                                                      Catalog
                                                                                  Workflow
                                    Deployment

       Application Events                                        App. Resource
                                    Resource Broker                                             Replica Mgmt
                                                                   catalogs


                                                  Core Grid Services

  Security            Information       Self                 Resource             Execution      Data
  Services              Services     Management             Management           Management     Services

                                                      OGSA-like Layer




    Physical Resource Layer
              Next Steps
• Many components of this architecture are
  now shared between different portal
  groups.
• We now look at some of the technology
  behind these portals.
A Portal Architecture
      Review
A Famous Web Portal
A Famous Portal, After Login
                What to Notice
   After logging in, my colors, layouts, and
    content all changed.
    • I get my stock list, my Bloomington weather, my
      news stories, etc.
    • I got rid of “Garfield”
   As we will see later, each of these content
    fragments (encircled) is managed by a thing
    called a portlet…
    • … I don’t guarantee that this is true for Yahoo’s
      web site but it is true for a large class of
      enterprise Java portal systems.
   Portlets are the key to portal software reuse.
       Let 10,000 Flowers Bloom
   Many portal projects have been launched
    since late ’90s.
    • First Generation: HotPage from SDSC, NCSA
      efforts, DOD, DOE Portals, NASA IPG
    • 2002 Special Issue of Concurrency and
      Computation: Practice and Experience.
   The field continues to be active
    • Global Grid Forum 14 Science Gateway workshop
      in June 2005.
    • About 15 gateways will be described in upcoming
      issue of Concurrency.
    • GCE2005 workshop at Supercomputing 05.
   How do we share and reuse all of this work?
                        Three-Tiered Architecture
                                  Grid and                       JDBC,
                                    Web                         Local, or
                                  Protocols                     Remote
                                                               Connection

                         Portal
Portal User Interface




                                                Database
                         Client                                                Database
                                                 Service
                         Stub


                         Portal                                                 HPC
                                              Grid Resource
                         Client                                                  or
                                              Broker Service
                         Stub                                               Compute Cluster


                         Portal                Information
                                                                            Grid Information
                         Client                    and
                                                                            Services, SRB
                         Stub                 Data Services


                         Three-tiered architecture is accepted standard for
                           accessing Grid and other services
JSR 168 Overview
 Java Portlet Standard
                What Is a Portlet?
   A portlet is a piece of Java code that manages the
    content of one section of a web portal’s HTML.
   It can do anything else that a Java web application
    can do.
    • You can connect a portlet to a database, invoke a web
      service, download an RSS feed, etc.
   It lives in a portlet container, which creates,
    manages, and destroys all the portlets of the portal.
   Portlet containers are part of portals.
    • Portals must do other things like manage login, users,
      groups, layouts, etc.
   JSR 168 standardizes two main things:
    • How the portlet container manages portlet lifecycles
    • How the portlets are programmed.
                What is JSR 168?
   From the portlet development point of view,
    it is really very simple:
    • You write a java class that extends
      GenericPortlet.
    • You override/implement several methods
      inherited from GenericPortlet.
    • You use some supporting classes/interfaces
          Many are analogous to their servlet equivalents
          Some (portletsession) actually seem to be trivial
           wrappers around servlet equivalents in Pluto.
   A complete example is available from
    • http://www.servogrid.org/slide/iSERVO/NMI/OG
      CETutorialMaterial
       Some Open Source JSR 168
              Containers
   GridSphere
    • http://www.gridsphere.org
   uPortal
    • http://www.uportal.org
   LifeRay
    • http://sourceforge.net/projects/lportal
   eXo platform
    • http://www.exoplatform.com
   StringBeans
    • http://www.nabh.com/projects/sbportal
   Jetspeed2
    • http://portals.apache.org/jetspeed-2/
 Some GenericPortlet.java Methods
Method           Description
Init             Called when the portlet is created.
                 Override if you need to set initial params.

doView           Controls what happens immediately
                 before the portlet is displayed in view
                 mode. Normally you override this.


doHelp, doEdit   Other portlet display modes

processAction    Place for handling any <form> actions
                 before turning over to the display mode
                 method (like doView). You should override
                 this for web forms.
Some Supporting Classes/Interfaces
Class                 Description
PortletContext        Similar to servlet context; get context info and
                      the RequestDispatcher from here.
PortletSession        Stores attribute information for a single portlet
                      application across multiple requests.
RenderRequest,        The request and response objects available to
RenderResponse        the doView() method. Similar to the normal
                      servlet request
ActionRequest,Actio   The request and response objects available to
nResponse             the processAction() method. Similar to the
                      servlet request and response objects.
PortletURL            Use this to create URLs that reference the portal.


PortletRequestDispa   Use this to include/forward to a JSP or servlet in
tcher                 the same portlet app.
WindowState           See if you are in minimized, maximized, normal
                      state.
                  The Big Picture
   As a portlet developer, the previous set of classes are all you
    normally touch.
   The portlet container is responsible for running your portlets.
    • Init, invoke methods, destroy.
   Portlets have a very limited way of interacting with the
    container.
    • The API is basically one-way.
          In Action: Get started.
public class JunkPortlet extends GenericPortlet {
  public void init(){
     //Do any initialization.
   }
  //Rest of the methods on following slides go
  here.
…
}
            Override doView()
protected void doView( RenderRequest req, RenderResponse
  res)
  throws PortletException, IOException {
  //Include the desired JSP or HTML page.
  //We could also use out to write directly to the response.
  WindowState state=req.getWindowState();
  if(!state.equals(WindowState.MINIMIZED)) {
     res.setContentType("text/html");
     PortletRequestDispatcher rd=

      getPortletContext().getRequestDispatcher(“MyJSP.jsp
 ”);
    rd.include(req,res);
 }
 }
                  The JSP Page
<portlet:defineObjects/>
<%
PortletSession
   portletSession=renderRequest.getPortletSession();
portletSession.setAttribute("localattname","localattval");
PortletURL url=renderResponse.createActionURL();
String theActionString=url.toString();
%>
HTML Content is here.
A form is below.
<form method=post action="<%=theActionString%>">
<input type=…>
</form>
                      Some Notes
• Include the <%portlet:definedObjects/%> tag, which will
  instantiate renderRequest, renderResponse, and
  portletConfig objects.
   – You can then just use them, as with request, response, and other
     JSP implicit objects.
• The renderRequest gives you access to the PortletSession,
  if you want to store session variables.
   – One of the trouble points.
• The renderResponse gives you access to the PortletURL
  object.
• Use the PortletURL to generate a URL for the <form
  action>
   – So that it points to portlet container and gets handled by the
     processAction() method, rather than going of into space.
   – Handle href URLs similarly.
   – This is one of the sticking points.
 Lastly, Override processAction()
• When you invoke the form on       public void processAction
  the previous JSP, the portlet       (ActionRequest request,
  container will pass the action
  handling to the processAction       ActionResponse
  method.                             actionResponse) throws
• The ActionRequest can be used       PortletException,
  to get any of the <input>           java.io.IOException {
  parameters in a way similar to      //Process request parameters
  the usual HttpServletRequest.
• When the processAction              …
  method returns, the container       //Add other params
  then invokes the appropriate do
  method (usually doView).            // to the renderRequest
• If you need to pass <form>          actionResponse.setRenderPar
  parameters on to doView, add        ameters(request.getParameter
  them to the ActionResponse.         Map());
    – This will give them to the
      RenderRequest.                }
    – The example shows how to
      add ALL parameters.
    A Comment on Portlet Coding
   JSR 168 seems to make some important and
    dubious assumptions
    • Developers will gladly ignore other development
      methodologies/frameworks like Velocity, Struts, and Java
      Server Faces.
    • Developers instead want to write a GenericPortlet extension
      for every single portlet they develop.
          And write really complicated processAction() and doView()
           methods.
    • Developers will like the specific JSR 168 portlet-style
      Model-View-Controller that it forces on them.
   Fortunately, these other development environments
    can be mapped to portlet actions.
    • In the OGCE project, we have developed support for
      Velocity portlets.
    • We are transitioning to Java Server Faces
A Grid Portlet Scenario
  Developing a Simple Grid
     Portlet Application
      A Quantum Chemistry Code
          Submission Form
   You have been asked to develop a
    submission form for the Democritos
    group’s Quantum Espresso (QE) package.
   These forms should help users set up and
    run QE applications on the TeraGrid and
    other Grid installations.
    • Mix of GT 2, GT 4, Condor, etc., for submission
   You are told to initially support the Plane
    Wave Self Consistent Field (PWSCF) code.
   Other QE applications may follow.
    • These may be coupled with PWSCF into simple
      workflows, but this is a later problem.
    Your Deployment Architecture

                    It acts as a common Gateway to
Your portal         different grid toolkit
server runs         installations and resources
at FSU.
                 GT 4         TeraGrid
                 @TG            LSF
        Portal
        Server
        @FSU
                  GT 2          MSI
                 @UMN           PBS
                Some Issues
   You decide the JSR 168 style portlets are
    the way to go…
    • But of course the PWSCF portlet doesn’t exist
      yet.
   You will need to also support other
    Quantum Espresso codes.
    • Would like to reuse as much code as possible.
    • But your PWSCF portlet isn’t reusable at that
      level.
   You also would like to simplify saving user
    input data and session archiving.
PWSCF Web Forms for
    Submission
                        Your Choices
   JSR 168 will allow you to share your portlet code
    with other collaborators.
   The Java COG Kit will help hide the differences
    between Grid toolkits for common tasks.
   Vanilla JSF will help simplify your portlet
    development in several ways.
    • JSF decouples your backing code from the Servlet API
          You can write your backing code as pure Java Beans/Plain Old
           Java Objects.
          You don’t have to adopt, maintain HTTP parameter name
           conventions.
    • Your form input backing beans can be serialized/deserialized
      with Castor.
   Coupling JSF and COG will allow you to compose
    your Grid actions using simple JSF taglibs.
    • You can reuse your Grid taglibs in other Quantum Espresso
      portlets.
    • You can compose composite actions
The Java CoG Kit
  Gregor von Laszewski
 Argonne National Laboratory
    University of Chicago
     gregor@mcs.anl.gov
    http://www.cogkit.org
   (as interpreted by MEP)
                         CoG Kits
   CoG Kits make Grid programming simple and
    new technologies are easy to integrate
   We focus on a CoG Kit for Java
    • Python also available (K. Jackson, LBNL)
    • Availability: Java CoG Kit since 1997
   The CoG provides two important things
    • A higher level client programming environment
      than stubs.
    • A shield against different versions of the Globus
      toolkit
          Same high level API works with GT 2.4, GT 3.0.2, GT
           3.2.0, GT 3.2.1, GT 4.0.0
       CoG Abstraction Layers
                                                           Development
    Nano              Bio-         Disaster                  Support
                                                 Portals
   materials      Informatics    Management
                        Applications



CoG Gridfaces Layer
CoG Gridfaces Layer




                                                                         CoG GridIDE
                                                                         CoG GridIDE
CoG Data and Task Management Layer
CoG Data and Task Management Layer



CoG Abstraction Layer
CoG Abstraction Layer

 CoG
 CoG      CoG
         CoG      CoG
                  CoG      CoG
                           CoG     CoG
                                   CoG     CoG
                                           CoG        CoG
                                                     CoG
          GT3                                       Others
                   GT4
 GT2     OGSI             Condor Unicore   SSH      Avaki
                  WS-RF
        classic                                      SETI
      Task                                Task
                                Task
     Handler                           Specification



The class diagram
is the
                                         Security
same for all grid           Service
                                         Context
tasks (running jobs,
modifying files,
moving data).


Classes also abstract toolkit
provider differences. You set            Service
these as parameters: GT2,                Contact
GT4, etc.
Setting Up Task and Specification
Task task=new TaskImpl(“mytask”,
                Task.JOB_SUBMISSION);
task.setProvider(“GT2”);
JobSpecification spec=
          new JobSpecificationImpl();
spec.setExecutable(“rm”);
spec.setBatchJob(true);
spec.setArguments(“-r”);
…
task.setSpecification(spec);
Setting Up the Service and Security
              Context
Service service=new
  ServiceImpl(Service.JOB_SUBMISSION);
service.setProvider(“GT2”);
SecurityContext securityContext=
  CoreFactory.newSecurityContext(“GT2”);
//Use cred object from ProxyManager
securityContext.setCredentials(cred);
service.setSecurityContext(
  (SecurityContext)securityContext);
    Set Up Service Contact and
              Finish
ServiceContact serviceContact=
  new ServiceContact(“myhost.myorg.org”);
service.setServiceContact(serviceContact);
task.setService(
  Service.JOB_SUBMISSION_SERVICE,
  service);
TaskHandler handler=new
  GenericTaskHandler();
handler.submit(task);
          Coupling CoG Tasks
   The COG
    abstractions also
    simplify creating
    coupled tasks.
   Tasks can be
    assembled into
    task graphs with
    dependencies.
    • “Do Task B after
      successful Task A”
   Graphs can be
    nested.
              Java COG Summary
   The Java COG 4 interfaces provide high level
    abstractions for building Grid clients.
    • Abstract out differences between Grid toolkits.
    • Provide task abstractions that form the basis for
      constructing DAG-style, file-based workflow.
   The COG can be used to build a wide range
    of clients
    • Desktops, grid shells, and of course portals.
    • Portlets are a well known way to build reusable
      portal components.
 Building Grid Portlets
with Java Server Faces
             Limitations of Portlets
   Portlets provide a way to bundle and share a
    complete application.
    • RSS portlet, GridFTP portlet, SRB portlet, etc.
    • Portlets combine the user interface view and
      action code.
   But in science gateway development, we
    often need finer grained components.
    • “When user clicks button, upload file, launch code,
      and move data someplace when done.”
    • Combines “GridFTP” and “Job Submit” portlets…
    • Or maybe OGSA-DAI or SRB or ….
   We need a way for the view and action code
    to be developed from reusable parts.
           JSF and Science Gateways
   JSF enables you to back your science
    application input form portlets with Java
    Beans.
    • These are independent of the servlet container, so
      are easy to test and to reuse in other applications.
   But also, Java Beans can be easily serialized
    with XML.
    • Castor, XML Beans
    • Marshal and un-marshal user input for persistent
      storage in XML storage services
          OGSA-DAI, GPIR, WS-Context
    • Potentially, can develop backing code as XML
      Schema and generate the code.
           JSF for Grid Enabled HTML
                    Widgets
   Natural program: develop Java Bean
    wrappers around Java COG kit, OGSA-DAI
    client API, SRB Jargon, etc.
    • Allows simple integration with JSF.
   Some issues exist
    • JSF only manages individual bean instances.
    • But grid portlets will need to manage an unknown
      number of bean instances.
          You may launch and monitor many different jobs.
    • We need a way of scripting composite actions
      created out of multiple reusable actions.
          COG Bean Wrappers
   Recall the COG structure
    • Executable tasks abstract basic grid
      actions and hide toolkit version
      differences.
    • These tasks can be collected into file-
      based DAG workflows.
   First problem is simple: wrap tasks as
    beans to make them available to JSF.
    • GenericGridBean defines the interface
   Second problem is managing multiple
    individual tasks.
     Managing Multiple Grid Tasks
   We must create and manage multiple beans
    for each task.
    • That is, I submit the job four times in one session.
    • Similarly, we can create multiple task graph
      clones.
   We do this by cloning and storing each bean.
   Beans have listeners and maintain state.
    • Unsubmitted, submitted, active, suspended,
      resumed are “live”
          Stored in live repository
    • Failed, canceled, completed, unknown are “dead”
          Stored in archive (WS-Context or other)
   Alternative approach: use one bean that is a
    bean factory for GenericGridTask beans.
                                            Corresponding JSF snippets
                                            <o:taskGraph id="myGraph" method="#{taskgraph.test}" >
                                                <o:task id="task1" method="task.create"
                                                        type="FileTransfer" />
                                                <o:task id="task2" method="task.create"
                                                        type="JobSubmit" />
                                                <o:task id="task3" method="task.create"
                                                        type="FileTransfer" />
                                                <o:taskAdd name="task1" method="taskgraph.add" />
                                                <o:taskAdd name="task2" depends="task1“
                                                        method="taskgraph.add" />
                                                <o:taskAdd name="task3" depends="task2"
                                                        method="taskgraph.add" />
                                             </o:taskGraph>



                                                        <h:panelGrid columns="3" >
                                                            <h:outputText value="Hostname (*) "/>
                                                            <h:inputText
                                                                    value="#{task.hostname}"/>
                                                          </h:panelGrid>
                                                          <h:panelGrid columns="3" >
                                                            <h:outputText value="Provider (*) "/>
                                                            <h:inputText value="#{task.provider}"/>
                                                        </h:panelGrid>
<h:panelGrid columns="2">
   <h:commandButton id="submit" value="Submit"
           action="#{taskgraph.submitAction}"/>
   <h:commandButton value="Clear" type="Reset"/>
</h:panelGrid>
                                        Task Monitoring with JSF
                                              Data Model
                               <h:dataTable value="#{jobData.jobs}" var="job">
                                   <h:column>
                                    <f:facet name="header">
                                      <h:outputText style="font-weight: bold" value="Job ID" />
                                    </f:facet>
                                    <h:outputText value="#{job.jobId}"/>
                                   </h:column>
                                   <h:column>
                                    <f:facet name="header">
                                      <h:outputText style="font-weight: bold" value="Submit Date"
Corresponding Java class.      />
                                    </f:facet>
public class Job {                  <h:outputText value="#{job.submitDate}"/>
  private String jobId;            </h:column>
                                   <h:column>
  private String status;            <f:facet name="header">
  private String submitDate;          <h:outputText style="font-weight: bold" value="Finish Date"
                               />
  private String finishDate;        </f:facet>
}                                   <h:outputText value="#{job.finishDate}"/>
                                   </h:column>
                                   <h:column>
                                    <f:facet name="header">
                                      <h:outputText style="font-weight: bold" value="Status" />
                                    </f:facet>
                                    <h:outputText value="#{job.status}"/>
                                   </h:column>
                                  </h:dataTable>
    Using AJAX
Galip Aydin, Ahmet Sayar, and
        Marlon Pierce
     Community Grids Lab
      Indiana University
                   What Is AJAX?
   Asynchronous JavaScript and XML is a combination
    of standard Web technologies
    • JavaScript, CSS, DOM, XML
   When done properly, it provides apparently seamless
    interactivity in browser clients.
    • No browser reloads
    • Much smoother than standard request-wait-response for
      browser forms.
   Several Google tools are a very well known
    examples.
    • Google maps, Gmail, etc.
   The real key is the standardization of the
    XMLHttpRequest Object
    • Originally developed for Internet Explorer
    • Now supported by all major browsers.
   Seminal article from Adaptive Path
    • http://www.adaptivepath.com/publications/essays/archives/
      000385.php
                    AJAX Architecture




Taken from http://www.adaptivepath.com/publications/essays/archives/000385.php
      The Main Idea: Asynchronous
        JavaScript Calls to Server
   AJAX’s key concept is the use of
    XMLHttpRequest to buffer requests and
    responses within the browser.
    • Use XMLHttpRequest to make a call to the server
      and get back the response without displaying it.
    • The response is stored locally as either plain text
      (plain or HTML), or XML.
    • JavaScript + DOM can be used to walk the HTML
      or XML tree to handle most user interactions.
   The XMLHttpRequest object in turn can issue
    requests and process responses
    independently of the user’s interaction.
    • Go and fetch additional maps, for example.
Asynchronous Invocations
How it Works
    Simple Example: GIS and Google
                Maps
   The Web Feature Service is a standard
    geographical information system service.
    • It stores geographic features and metadata used
      to construct maps.
    • Features are represented with the Geographic
      Markup Language
    • For example, the location and properties of
      earthquake faults and seismic events.
   The Feature Service is typically constructed
    around traditional request-response.
   We would like to combine this with Google
    Maps to make more interactive user
    interfaces.
   So let’s get started.
Integrating Google Maps and GIS
             Services


                            Simple Architecture



                           Client                    Google Map
                        MAP interface                  Server




                  Supported
                  Feature Data              OGC WFS
                                        Feature Data Server
                  by the WFS

                       Layer specific
                       parameters
                       for filtering
               Making the request
   Creating an XMLHttpRequest Object
    • For any browser, except IE
          var requester = new XMLHttpRequest();
    • In IE
          var requester = new ActiveXObject("Microsoft.XMLHTTP");
   Transporting Data using an XMLHttpRequest
    Object
    • To retrieve data from the server we use two methods:
      open() to initialize the connection,
      send() to activate the connection and make the
      request.
      requester.open("GET", "getFaultNames.jsp?State=CA");
      requester.send(null);
   This request is for all California fault information
    in the Feature Service.
    • It will be encoded in GML
    • It may take a bit of time to download….
Checking the Connection Status
   To find out if the data retrieval is done we check
    the status of the readyState variable. Object’s
    status may be any of the following:
    0   –   Uninitialised
    1   –   Loading
    2   –   Loaded
    3   –   Interactive
    4   –   Completed
    • requester.onreadystatechange monitors the readyState
            variables status.
             if (requester.readyState == 4){
                 if (requester.status == 200){
                   success();
                }
               else{
                   failure();
                  }
              }
                 Parsing the Data
   After a successful request XMLHttpRequest object may hold
    data in one of the two properties: responseXML or
    responseText.
   responseXML stores a DOM-structured XML data.
       <Fault>
           <Name>San Andreas</Name>
       </Fault>
   We use JavaScript XML parsing methods such as
    getElementsByTagName(), childNodes[], parentNode…
      var faultNameNode =
       requester.responseXML.getElementsByTagName(“Name")[0];
       var faultName = faultNameNode.childNodes[0].nodeValue;
   We can then use Google Map JavaScript functions to create
    the browser display.
   responseText stores the data as one complete string in
    case the content type of the data supplied by the server
    was text/plain or text/html.
     Ajax Calls From JSP Pages
   In the 1st JSP page         In the 2nd JSP page
function checkForMessage()
  {
                                 (relay.jsp)
                                 <%
  var url = "relay.jsp";
                                 Bean.getNames(response);
  initRequest(url);
  req.onreadystatechange =       %>
  processReqChange;
  req.open("GET", url,          The response object
  true);
  req.send(null);
                                 will contain the XML
 }                               result object.
   The request is
    forwarded to relay.jsp
                                   Integrating Web
                                   Feature Service
                                     Archives and
                                     Google Maps

                                   Google maps can be
                                   integrated with Web
                                   Feature Service
                                   Archives to browse
                                   earthquake fault
                                   records.


Faults are typically stored by segment number, so map
interfaces are convenient for both verifying continuity
and setting up input files for computing problems.
        Other Useful Examples
   AJAX is also useful for simulating server
    data pushing.
    • Browser interface is updated periodically from
      locally stored data.
    • XMLHttpRequest periodically requests updates
      asyncrhonously.
   Replace annoying browser reload polling
    and fragile, non-standard server push.
   The browser is always available for user
    interactions while the XMLHttpRequest
    object is being updated.
   Examples: Chat applications and GPS
    streams
 Real Time GPS
and Google Maps
Subscribe to live GPS
station. Position data
from SOPAC is
combined with Google
map clients.



                         Select and zoom to
                         GPS station location,
                         click icons for more
                         information.
                  Conclusions
   Computing portals  scientific gateways.
    • Gateways include both user interface components
      and supporting services.
    • Manage user interactions with Grid infrastructure.
   We reviewed standards for building portals
    out of reusable components.
    • JSR 168 portlet standard
   Several new techniques can be used to build
    portlets.
    • Java Server Faces: reusable components for
      portlets.
    • AJAX: better interactivity for portlets
            More Information
   mpierce@cs.indiana.edu
   Open Grid Computing Environments
    • http://www.collab-ogce.org
   Geographical Information System
    services
    • http://www.crisisgrid.org
   QuakeSim
    • http://quakesim.jpl.nasa.gov
Integrating JSF and COG 4

 Mehmet Nacar and Marlon Pierce
      JSF for Grid Enabled HTML
               Widgets
• Natural program: develop Java Bean wrappers
  around Java COG kit, OGSA-DAI client API, SRB
  Jargon, etc.
  – Allows simple integration with JSF.
• Some issues exist
  – JSF only manages individual bean instances.
  – But grid portlets will need to manage an unknown
    number of bean instances.
     • You may launch and monitor many different jobs.
  – We need a way of scripting composite actions created
    out of multiple reusable actions.
         COG Bean Wrappers
• Recall the COG structure
  – Executable tasks abstract basic grid actions and
    hide toolkit version differences.
  – These tasks can be collected into file-based
    DAG workflows.
• First problem is simple: wrap tasks as beans
  to make them available to JSF.
  – GenericGridBean defines the interface
• Second problem is managing multiple
  individual tasks.
          JSF Task Management Class
                   Structure
TaskListenerBean                       «interface»                    1       TaskGraphListenerBean
                                     GenericGridBean

                   1




               TaskBeanManager                         TaskGraphBeanManager        *


     *

                        *
                        1                                         *
                                                                  1

                   TaskBean                               TaskGraphBean


                                 1                *
   Managing Multiple Grid Tasks
• We must create and manage multiple beans for
  each task.
  – That is, I submit the job four times in one session.
  – Similarly, we can create multiple task graph clones.
• We do this by cloning and storing each bean.
• Beans have listeners and maintain state.
  – Unsubmitted, submitted, active, suspended, resumed are
    “live”
     • Stored in live repository
  – Failed, canceled, completed, unknown are “dead”
     • Stored in archive (WS-Context or other)
• Alternative approach: use one bean that is a bean
  factory for GenericGridTask beans.
           Managing Multiple Tasks
                                                    HashMap
JSF Form              Task Manager

                JSF                      retrieve
                                                    Task Bean 1




                                                    Task Bean 2
                      Task Bean

                JSF                      register
                                                    Task Bean 3




                         Managed Beans
          Creating Task Graphs
• COG Task Graphs correspond to composite
  JSF Web Form actions.
  – Do X, Y, and then Z when user clicks the button.
• Each of these actions may be reused, but the
  entire action is new.
• We must do two things
  – Wrap the COG TaskGraphHandler with a bean
    and bean manager.
  – Provide tag bindings for defining the custom
    actions.
             Constructing Task Graphs
                                                            HashMap
JSF Request Form         TaskGraph Manager

                   JSF                           retrieve
                                                            TaskGraph 1


                                                 register
                                                            TaskGraph 2
                         TaskGraphBean
JSF Monitoring
Form
                                                            TaskGraph 3




                         JobSubmit Bean
                          FileTransfer Bean
                            FileOperation Bean




                              Managed Beans
  Expressing Task Graphs with Tags
<%@taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
<%@taglib uri="http://java.sun.com/jsf/html" prefix="h"%>
<%@taglib uri="http://www.ogce.org/gsf/task" prefix="o"%>
………
………


<o:taskGraph id="myGraph" method="#{taskgraph.test}" >
    <o:task id="task1" method="task.create" type="FileTransfer" />
    <o:task id="task2" method="task.create" type="JobSubmit" />
    <o:task id="task3" method="task.create" type="FileTransfer" />
    <o:taskAdd name="task1" method="taskgraph.add" />
    <o:taskAdd name="task2" depends="task1" method="taskgraph.add" />
    <o:taskAdd name="task3" depends="task2" method="taskgraph.add" />
</o:taskGraph>
                                            Corresponding JSF snippets
                                            <o:taskGraph id="myGraph" method="#{taskgraph.test}" >
                                                <o:task id="task1" method="task.create"
                                                        type="FileTransfer" />
                                                <o:task id="task2" method="task.create"
                                                        type="JobSubmit" />
                                                <o:task id="task3" method="task.create"
                                                        type="FileTransfer" />
                                                <o:taskAdd name="task1" method="taskgraph.add" />
                                                <o:taskAdd name="task2" depends="task1“
                                                        method="taskgraph.add" />
                                                <o:taskAdd name="task3" depends="task2"
                                                        method="taskgraph.add" />
                                             </o:taskGraph>



                                                        <h:panelGrid columns="3" >
                                                            <h:outputText value="Hostname (*) "/>
                                                            <h:inputText
                                                                    value="#{task.hostname}"/>
                                                          </h:panelGrid>
                                                          <h:panelGrid columns="3" >
                                                            <h:outputText value="Provider (*) "/>
                                                            <h:inputText value="#{task.provider}"/>
                                                        </h:panelGrid>
<h:panelGrid columns="2">
   <h:commandButton id="submit" value="Submit"
           action="#{taskgraph.submitAction}"/>
   <h:commandButton value="Clear" type="Reset"/>
</h:panelGrid>
                                        Task Monitoring with JSF
                                              Data Model
                               <h:dataTable value="#{jobData.jobs}" var="job">
                                   <h:column>
                                    <f:facet name="header">
                                      <h:outputText style="font-weight: bold" value="Job ID" />
                                    </f:facet>
                                    <h:outputText value="#{job.jobId}"/>
                                   </h:column>
                                   <h:column>
                                    <f:facet name="header">
                                      <h:outputText style="font-weight: bold" value="Submit Date"
Corresponding Java class.      />
                                    </f:facet>
public class Job {                  <h:outputText value="#{job.submitDate}"/>
  private String jobId;            </h:column>
                                   <h:column>
  private String status;            <f:facet name="header">
  private String submitDate;          <h:outputText style="font-weight: bold" value="Finish Date"
                               />
  private String finishDate;        </f:facet>
}                                   <h:outputText value="#{job.finishDate}"/>
                                   </h:column>
                                   <h:column>
                                    <f:facet name="header">
                                      <h:outputText style="font-weight: bold" value="Status" />
                                    </f:facet>
                                    <h:outputText value="#{job.status}"/>
                                   </h:column>
                                  </h:dataTable>
Extended Slides
The Java CoG Kit
 Gregor von Laszewski
 Argonne National Laboratory
    University of Chicago
     gregor@mcs.anl.gov
     http://www.cogkit.org
   (as interpreted by MEP)
                       CoG Kits
• CoG Kits make Grid programming simple and new
  technologies are easy to integrate
• We focus on a CoG Kit for Java
  – Python also available (K. Jackson, LBNL)
  – Availability: Java CoG Kit since 1997
• The CoG provides two important things
  – A higher level client programming environment than
    stubs.
  – A shield against different versions of the Globus toolkit
     • Same high level API works with GT 2.4, GT 3.0.2, GT 3.2.0, GT
       3.2.1, GT 4.0.0
       CoG Abstraction Layers
                                                           Development
    Nano              Bio-         Disaster                  Support
                                                 Portals
   materials      Informatics    Management
                        Applications



CoG Gridfaces Layer
CoG Gridfaces Layer




                                                                         CoG GridIDE
                                                                         CoG GridIDE
CoG Data and Task Management Layer
CoG Data and Task Management Layer



CoG Abstraction Layer
CoG Abstraction Layer

 CoG
 CoG      CoG
         CoG      CoG
                  CoG      CoG
                           CoG     CoG
                                   CoG     CoG
                                           CoG        CoG
                                                     CoG
          GT3                                       Others
                   GT4
 GT2     OGSI             Condor Unicore   SSH      Avaki
                  WS-RF
        classic                                      SETI
      Task                                Task
                                Task
     Handler                           Specification



The class diagram
is the
                                         Security
same for all grid           Service
                                         Context
tasks (running jobs,
modifying files,
moving data).


Classes also abstract toolkit
provider differences. You set            Service
these as parameters: GT2,                Contact
GT4, etc.
             Java COG Summary
• The Java COG 4 interfaces provide high level
  abstractions for building Grid clients.
  – Abstract out differences between Grid toolkits.
  – Provide task abstractions that form the basis for
    constructing DAG-style, file-based workflow.
• The COG can be used to build a wide range of
  clients
  – Desktops, grid shells, and of course portals.
  – Portlets are a well known way to build reusable portal
    components.
Building Grid Portlets with
   Java Server Faces
            Limitations of Portlets
• Portlets provide a way to bundle and share a
  complete application.
  – RSS portlet, GridFTP portlet, SRB portlet, etc.
  – Portlets combine the user interface view and action code.
• But in science gateway development, we often need
  finer grained components.
  – “When user clicks button, upload file, launch code, and
    move data someplace when done.”
  – Combines “GridFTP” and “Job Submit” portlets…
  – Or maybe OGSA-DAI or SRB or ….
• We need a way for the view and action code must
  be developed from reusable parts.
PWSCF Web Forms for
    Submission
   Java Server Faces Overview
• JSF can solve the reusable portlet widget
  problem.
  – JSF can also work in “standalone” mode outside
    of portlets.
  – Potentially independent of Web applications.
     • XUL and Swing widget bindings
• We will first examine JSF generally
• Conclude with integrating JSF and COG
              Advantages of JSF
• JSF hides communication details that connect
  HTML forms with backing code.
  – You don’t have to worry about servlet specific request,
    response, and session objects.
  – You don’t have to maintain fragile naming conventions for
    <input> tags.
• Developers only need to develop JavaBeans and
  tag libraries.
  – Beans are independent of Web applications.
  – Can be easily written and tested outside of servlet
    containers.
  – Compatible popular “Inversion of Control” based systems
    like JSF and Spring
       JSF and Science Gateways
• JSF enables you back your science application input
  form portlets with Java Beans.
  – Again, these are independent of the servlet container, so
    are easy to test and to reuse in other applications.
• But also, Java Beans can be easily serialized with
  XML.
  – Castor, XML Beans
  – Marshal and un-marshal user input for persistent storage in
    XML storage services
     • OGSA-DAI, GPIR, WS-Context
  – Potentially, can develop backing code as XML Schema and
    generate the code.
                       A JSF Example
<HTML>
  <HEAD> <title>Hello</title> </HEAD>
  <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
  <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
  <body bgcolor="white">
  <f:view>
  <h:form id="entryForm" >
     <h2> Enter some text in the form below</h2>
     <h:inputText id="userSt"
                   value="#{multiEventBean.userString}"/>
      <h:commandButton id="submit"
                   action="success" value="Submit" >
       <f:actionListener type="multiEventTest.Listener1"/>
       <f:actionListener type="multiEventTest.Listener2"/>
      </h:commandButton>
  </h:form>
  </f:view>
  </body>
</HTML>
                      The JSF Page
• Note everything with <f:> or <h:> namespace prefix is a JSF
  tag.
   – Usually, <h:> tags mimic HTML widgets.
   – <f:> is for non-rendered stuff.
   – Everything else is good old HTML.
• There are three different Java classes here.
   – They are all in the package multiEventTest
   – multiEventBean.java is just a bean with typical get/set methods.
   – Listener1.java and Listener2.java implement the
     javax.faces.event.ActionListener interface.
• All 3 classes are called when you click the command button.
• Also, take a look at <inputText>. This is roughly equivalent
  to <input name=“” value=“”>.
   – But no name needed. JSF handles parameter names for you and
     connects them to the beans you specify.
   – This greatly simplifies writing generic actions.
     A Simple Example: HtmlDataGrid
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<f:view>
      <h2> This shows an example of how to use
      HtmlDataTable to display some results.
      </h2>
   <h:dataTable value="#{ValueBean.itemList}" var="values" border="1">
   <h:column>
      <f:facet name="header">
       <h:outputText value="Column 1"/>
      </f:facet>
      <h:outputText value="#{values.value1}"/>
   </h:column>
   <h:column>
      <f:facet name="header">
       <h:outputText value="Column 2"/>
      </f:facet>
      <h:outputText value="#{values.value2}"/>
      <h:outputText value="#{values.value2}"/>
   </h:column>
   </h:dataTable>
</f:view>
It Looks Like This
                 Some Explanation
• The <h:dataTable> binds to a particular data set with
  value=“ValueBean.itemList”.
   – ValueBean.itemList must be java.util.List, java.sql.ResultSet or
     similar.
   – The values of these lists may be beans also.
• The var=“” just defines a useful internal value.
   – Here, each entry in the list is set equal to “values”.
   – In the example, the items in the list happen to be simple beans with
     member variables “value1” and “value2” along with appropriate
     getter/setters.
• When you load the page, it just iterates through the entries
  in ValueBean.itemList and creates the table, as you
  instructed.
• Note again there are no loops in the actual page. Also, you
  don’t know anything about the data you are getting.
             JSF Magic: Data Models
• The M in MVC is the Data Model
   – “Abstract” representation of a data structure
        • That is, not tied to the display of the data (“view”)
• JSF DataModel extension classes include
   –   Arrays: wrap arrays of Java objects
   –   Lists: wraps a java.util.List of Java objects
   –   Results: for JSTL’s Result object, which itself wraps SQL ResultSets.
   –   ResultSets: also for JDBC, wraps the ResultsSet object directly.
   –   Scalar: Wraps an individual Java object.
• Typically, these should follow Bean patterns for naming member data
  and their associated getter/setters.
• You can write your own specialized Data Models.
   – XMLDataModel, for wrapping an XML data bean, comes to mind.
   – RSSDataModel is another that I found.
• These are associated with UIData classes in the JSF page for display.
   – HtmlDataTable is an example.
            JSF Form Validators
• The user interface stuff (<f:> and <h:>) has
  lots of built-in validators
  – Verify that input entries are integers, doubles, etc.
  – Verify that input entries fall within the correct
    range (1 to 10 in the guessNumber example).
  – Verify the string has the right length.
• You can extend to write your own specialized
  validators

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:3
posted:3/18/2012
language:
pages:111