Upload
gerard-shelton
View
215
Download
0
Tags:
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
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
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.
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.
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