Writing Grid Portlets

Grid Portlet Overview Previously we looked at writing JSR 168 portlets using JSP and Velocity. Grid Portlets are just portlets Use the Java CoG to make calls from the portlet code to the desired Grid service. Can also make non-COG calls, such as to GridPort API. These APIs should not be portlet-specific, since you should be able to reuse the Grid APIs from other Java clients. NCSA’s OGRE (general), Trebuchet (application specific) are examples

This Is Not a COG Tutorial We will be using the COG to illustrate some basic portlet programming features. We use the COG4 APIs in our ProxyManager, Job Submission, and GridFTP portlets Hides differences between Globus Toolkit versions. Is also structured to handle task-based workflow and job composition. But for in-depth COG questions, we defer to Gregor’s group. Available through AG session today. Or docs available through www.cogkit.org OGCE is an open consortium, and there are other alternatives. OGRE job management builds on COG for Workflow GridPort uses the GGF Community Scheduling Framework and higher level tools (job sequencers, for instance). Use what you like

Getting Proxy Credentials The key ingredient is getting proxy credentials into the portal and sharing between different portlets. We use MyProxy for this Advantage: you don’t have to store users’ long term keys on the web server. Disadvantage: you have to run a separate MyProxy server; users have to put keys there outside the portal. You must include the OGCE2 MyProxy portlet (or a variation of it) in your Grid portal to do any other Grid stuff. OGCE1 also had support for grid-proxy-init. Would be able to add this, but you would need to manage your users’ long term keys.

Why No Portal Single Sign-On? We have not unified the uPortal (or GridSphere) logins with the credential fetching in OGCE2. Reason is not profound Every portal vendor does login differently We would have to provide modified login modules for every vendor. Can be added if desired.

Proxy Manager Under the Hood See ogce2/indiana/extreme/ProxyManager/modules/portlet/src for templates and code. Templates illustrate several Velocity scripting concepts. Control structures, variables But the action code is more interesting. This is where you do your Grid coding. Use Velocity’s Context object to communicate strings back to your templates.

Proxy Manager Code Key part here is the doGet_proxy() method. Abbreviated code on the right. MyProxy class: import from CoG kit. GSSCredential class: standard Java security class. ProxyManager class: used by us to pass credentials between portlets. public void doGet_proxy() { MyProxy myproxy= new MyProxy(…); GSSCredential proxy= myproxy.get(…); ProxyManager.addProxy(…); }

Writing Simple Job Submission Portlets For portlets, you have to deal with two main Grid issues: Getting the credential from the proxy store. And then using it. The CoG APIs provide an additional nice layer of Grid abstraction for Grid tasks. We will look at this for wrapping GRAM calls. We will assume the following: You have your project set up to be warred with maven. You have chosen a development technology (like JSP + portlets or Velocity portlets). You will be collecting the necessary input information from an HTML <form>. You will be putting the action code in either the portlet (perhaps as a JavaBean) or Velocity action handler. All code snippets below go in this portlet/action code.

Write the Method Skeleton In your action code, write a method to do job submission. For Velocity, this maps to the “eventSubmit_” form parameter in your template. In portlets, this code is called by your processAction method. You will need to pass it, minimally, the ActionRequest and ActionResponse objects. public void doSubmitJob( ActionRequest req, ActionResponse resp,…) { //Next, get proxy //Then, run command. }

Get the Proxy Now get the proxy from the local store. The ProxyManager class calls the static method getDefaultProxy to look up your credential using your portlet session. You need these imports org.ietf.jgss.GSSCredential xportlets.proxymanager.ProxyManager. javax.portlet.* for everything else. This assumes that you have retrieved a credential from the MyProxy server. public doSubmitJob( ActionRequest req, ActionResponse res) { //Get the proxy PortletSession sess= req.getPortletSession() GSSCredential cred= ProxyManager.getDefaultProxy(sess); //Next, run command }

Run the Command The CoG4 interfaces now come into play. You should first understand the general CoG approach. The COG4 interfaces attempt to abstract things at several layers Tasks: a generic Grid function Remote command execution, file operation, or information inquiry. Has a specification and service Is run by a handler Specification: set the type of task (job submit, etc.) and its specific parameters. Service: sets the Globus Toolkit (or other) provider, security context, and service contact information. TaskHandler: runs the task. Note this scheme is intended to shield you from programming differences of different Globus toolkits.

Making Contact with the Portal The remaining issue is getting information from the HTML forms to the appropriate CoG calls. This is done through the PortletRequest object. Typically, it is actually the ActionRequest subclass. In your doSubmitJob() command, just use String param=request.getParameter(“Param-Name”); “Param-Name” is replaced with the input parameter name in your HTML form. <input type=text name=“Param-Name” value=“rm -r *.*”> In following code snippets, “quoted strings” are usually what you would pass in from the Web form.

An Extended Code Example: 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);

Extended Code Example: 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);

Extended Example: 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);

Monitoring Tasks Monitoring running tasks submitted by the COG is done through a status listener. Write a class that implements StatusListener interface Create an instance of your listener and add it to the task: task.addStatusListener(myListener); There is a small problem with doing this in a portal application The listener must be instantiated in the action code, along with the rest of the COG classes. But these are lost after the action completes. Simple solution: store it in the PortletSession This will keep the listener object alive after the action completes Get the session from the PortletRequest (more typically, its subclass, ActionRequest) Sample code PortletSession session=request.getPortletSession(); session.setAttribute(“mytask”,myListener); When you are curious about your task’s status, fetch it out of the session by name. Better solution: Store in persistent object store. The above solution does not work if you log off, since your session is invalidated. So you can’t monitor jobs across long term applications. Currently not implemented.