Towards a Javascript CoG Kit Gregor von Laszewski Fugang Wang Marlon Pierce Gerald Guo Please note not everything is yet available. This is a prototype and shows that we can handle Grid Jobs via Javascript. The APIs are not yet released.

Outline Why JavaScript? - Alternatives Design Implementation Javascript CoG API Demonstration Future Conclusion

Demonstration Goal: – Develop simple demonstration program to evaluate if a Javascript CoG Kit is possible – Answer is yes Status: – We are taking our demonstration and develop now APIs for reuse in Javascript.

Demo: Grid Job Execution Uses Java CoG Kit Uses Myproxy Works on Teragrid Uses a server on which we installed the serice

Authenticate

Simple workflow

Job History

Waiting for results

Viewing the result

Ad-hoc Grid / Cloud Computing Managing your own Grid

Preparing for Cloud services Easily access information about the resources and computing power of clusters and grids. Cloud Services – Collect Grid Data – Serve Grid Data – Coordinate User Benchmarks Cloud Service Client – Table – Google Maps – Javascript Cloud server Cloud server Cloud client Grid Benchmark Execute

Alternatives Current OGCE distribution Java CoG Kit … other Grid related solutions …

DISCLAIMER What comes next is under development and not yet officially available.

Why JavaScript CoG Benefit: Lower the entry threshold for Grid computing –Enable user friendly Grid Web 2.0 portals –Zero installation in client side –Seamless upgrade Challenge –Restricted privilege due to the security model MVC model. –Client side provides only a view. –Data and control is through the API and mediator service –Security Cross-site Scripting (XSS), Cross-site Request Forge (XSRF) What we need to do: A set of design rules to deal with these. Verification, Input sanitation, Output sanitation, etc.

The Architecture

Grid Abstractions We introduce a convenient subset of abstractions that we found useful within the CoG Kits We developed new abstractions that increase the functionality and abstraction level to the users Abstractions are expressed in Javascript through “objects”

JavaScript CoG Objects - Job / Authentication “Executable” is an abstraction for all executable entities, jobs or workflows. –It has fields Attributes, and Provider. Provider could be system, Karajan or another workflow engine’s name. Attributes would be commands or the content of the workflow description while using workflow stated in Provider. “Authenticator” is used to do the authentication. –It has fields Attributes, and Provider. And function authenticate(). Provider could be MyProxy for example, while Attributes contains necessary info to authenticate the user through the specified provider.

Javascripit CoG Workflow “KarajanWorkflow” represents a Karajan workflow. It supports hierarchical workflow, which means a workflow can be a “job” in another workflow. –addJob (jobname, job) – A new job is appended to this workflow. –deleteJob (jobname) – The job with the name specified by parameter jobname is deleted. As a result, all related dependency is deleted as well. –listJobs( ) – List all jobs in a workflow. –searchByName(jobname) – Search job in terms of name. –addDependency (jobparent, jobchild) – Add dependency which says that job jobparent should be executed before job jobchild. –removeDependency(jobparent, jobchild) – Remove dependency between job jobparent and job jobchild.

JavaScript CoG Workflow Queue “WFQueue” represents a client side queue of Executable objects that have no dependency on each other. –addWorkflow(name, workflow)– Append the workflow specified by parameter to a workflow queue. –removeWorkflowByIndex(index) – Remove a workflow according to parameter index. –removeWorkflowByName(name) – Remove a workflow with name specified by parameter name. –clearAll( ) – Remove all workflows in the queue. –searchByName(name) – Return the index of the workflow with the name specified by parameter. If no corresponding workflow exists, return -1.

JavaScript CoG API Jobs and their status (“CoGJob”) –authenticate(Authenticator) – The Authenticator’s authenticate() function will be called to authenticate the user. –execute(Executable, resources) – Submit a workflow to server side to execute. The resources specify necessary resources associated with the jobs. –transfer(from, source, to, dest) – transfer data “source” from “from” to “dest” in “to”. –query( ) – Get state of all workflows that were submitted to execute by the user. –query(workflowids) – Get state of specified workflows that were submitted to execute by the user.

JavaScript CoG API “CoGQueue” - Collaboration Queue –listQueues( ) – List all the public queues and/or queues that the user are participating. –grantAccess(queueID, userlist) – The owner of a queue can give some other users access privilege to the queue. –add(queuename, Executable) – Submit a workflow to store for future use or share with other users. –remove(queueID, sharedWorkFlowID) – The owner of a workflow can remove it. list(queueID); list all workflows’ metadata shared in the queue. –listParticipants(queueID) – List all the participants of the queue. –listByUser(queueID, username) – List the workflows’ metadata owned by a user from one queue.

JavaScript CoG API “CoGQueue” - cont’d –getStatus(queueID, sharedWorkFlowID) – Query the specified workflow’s status. It could be being edited by other user or not. –browseWorkflow(queueID, sharedWorkFlowID) – Download the workflow to client side to browse. –obtainWriteToken(queueID, sharedWorkFlowID) – The user try to obtain the write token. –editWorkflow(queueID, sharedWorkFlowID) – The user will try to obtain the write token and then to edit the workflow. –updateWorkflow(queueID, sharedWorkFlowID, workflowObj) – Update the workflow when complete editing.

…… Ownership of a queue Ownership of a workflow Currently editing shared workflow workflow being edited user Scenario for the use of collaboration queue Collaboration Queue

Implementation We have developed a prototype of the system –Authenticate users from a web client through (a TeraGrid) MyProxy server. –Handles job submission and job status queries from a web client. –Contains a prototype client side GUI-based environment to mange and edit the jobs/workflows to demonstrate it works. –The services are currently integrated into Axis2 and Tomcat as part of a standard web service.

Demo Web page:

Conclusion and Future Work Mediator service – handles credential management, job submission, status query – Workflow preprocess on the server side and persistence using DB4O Web services interface Client side web services consuming JavaScript Cog API Defined a collaborative job queue Service/API

Planned and current activities RESTful result retrieval (via Jersey) Finer grained status query Use of Dojo to enhance client side workflow composition Reorganize client side JS code to form API User account management Collaboration queue implementation (and integration with GridShib) Integrate Grid information service Multiple workflow types support Alternative authentication and authorization approach