28
Towards a Javascript CoG Kit Gregor von LaszewskiFugang WangMarlon PierceGerald Guo laszewski @gmail.com http ://grid.rit. edu 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.

Towards a Javascript CoG Kit Gregor von Laszewski Fugang Wang Marlon Pierce Gerald Guo [email protected] [email protected]

Embed Size (px)

Citation preview

Towards aJavascript CoG Kit

Gregor von LaszewskiFugang WangMarlon PierceGerald Guo

[email protected] http://grid.rit.edu

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

CloudserverCloudserver

Cloud clientCloud client

GridGrid

BenchmarkExecute

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

CollaborationQueue

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: http://grid.rit.edu/demo

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