Cyberaide Shell: Interactive Task Management for Grids and Cyberinfrastructure Gregor von Laszewski, Andrew J. Younge, Xi He, and Fugang Wang Service Oriented Cyberinfrastruture Laboratory Rochester Institute of Technology 102 Lomb Memorial Drive, Rochester, NY 14623-5608 Corresponding Author E-mail:
[email protected] C ONTENTS I
Introduction
II
Related Research and Technologies II-A System Shells . . . . . . . . . II-B Distributed Computing, Grid, Cluster Shells. . . . . . . . . . II-C Scripting Language Shells. . .
2
. . . . . Cloud, . . . . . . . . . .
3 3 3 4
III
Requirements
IV
Design IV-A Design Overview . . . . . . . . . . . IV-B Architectural Design . . . . . . . . . . IV-B1 Resource Layer . . . . . . IV-B2 Shell Implementation Layer IV-B3 Shell Service Layer . . . . IV-B4 Language Layer . . . . . . IV-B5 User Layer . . . . . . . . .
. . . . . . .
5 5 5 5 6 6 6 6
Implementation V-A Command Line Interface . . . . . . V-B Literate Semantic Cyberaide Objects V-C Job Execution . . . . . . . . . . . . V-D Calendar Access . . . . . . . . . . . V-E Service Framework . . . . . . . . .
. . . . .
6 6 8 8 8 9
V
VI
Conclusion
References
4
. . . . .
9 10
Cyberaide Shell: Interactive Task Management for Grids and Cyberinfrastructure Gregor von Laszewski, Andrew J. Younge, Xi He, and Fugang Wang Service Oriented Cyberinfrastruture Laboratory Rochester Institute of Technology 102 Lomb Memorial Drive, Rochester, NY 14623-5608 Corresponding Author E-mail:
[email protected]
Abstract—A steep learning curve and a high entry barrier limit the use of Grid computing and advanced cyberinfrastructure. These barriers become a significant issue to scientists which benefit from advanced cyberinfrastructure the most. In order for the scientists to focus on actual scientific tasks, tools and services need to be developed to ease the integration of complex middleware. One such tool is Cyberaide Shell , an advanced but simple to use system shell which facilitates the use of current and future cyberinfrastructure. Cyberaide Shell is based on the integration of semantically enhanced commands and a dynamic interface that allows access to complex cyberinfrastructure in an easy and intuitive fashion on an ad-hoc. This is accomplished by abstracting the complexities of resource, task, workflow, and application management through a semantic command line interpreter. Through a service integration mechanism, the shell’s functionality is exposed to a wide variety of frameworks and programming languages. This includes client interfaces for Java, Ruby, Python, Matlab, R, JavaScript. e present our design and describe our use of the shell while integrating TeraGrid resources.
I. I NTRODUCTION Grid computing is a complex and diverse field where different technologies are constructed and combined to enable the use of distributed resources under different administrative domains. Applications of Grid computing include access to large-scale computing power and storage resources harnessed from otherwise unconnected resources in an efficient and organized manner. This is commonly facilitated by middleware solutions such as the Globus Toolkit [1] and g-Lite [?]. While sophisticated middleware solutions are necessary for today’s Grid computing, they add complexities to its use and seldom take into account user preferences. Thus, scientists and researchers are finding the development of applications on the Grid can be quite time consuming. We believe this is one of the reasons why Grids have not yet been as widespread as one would have hoped for. The biggest problem with today’s Grid middleware is that it does not support the infrastructure related concepts projected by Grid computing. Instead, the Grid computing environment leaves it up to a dedicated research team to develop custom tools to fufill this need. The absence of such teams in smaller projects requires the scientist to become an expert in Grid computing. In a typical Grid environment there are obstacles that need to be dealt with including task management, job
scheduling, resource monitoring and more. Many of these utilities could be abstracted to simplify the scientific user’s experience and enable them to perform their research in a more efficient and productive environment. However, it is important that the abstraction doesn’t interfere with the Grid infrastructure’s overall usability. These concepts are the foundation to Service Oriented Architectures (SOA) [2] and the Open Grid Services Architecture (OGSA) [3] where applications are loosely coupled together to mask the more complex underlying technologies. While this layer of abstraction is beneficial in many ways, it can also introduce unwanted overhead and the cost to master SOA tools and standards is still high. However, when we are going back to the roots for job coordination we find abstractions and tools that have been accepted for decades and are familiar to most scientists. One of these tools is a shell. A regular shell can support a variety Grid computing as tools such as Condor, Globus, and the CoG Kit as they already provide command line interfaces that can be reused within any shell. However, a regular UNIX shell typically does not support the common tools of a distributed environment projected by Grids and advanced cyberinfrastructure. Graphical User Interfaces (GUIs) are commonplace in most computing environments today. However, from our practical use of Grids we found that the tools provided lacked a number of essential functionality and flexibility and did not met our needs for creating ad-hoc virtual organizations and services easily. We believe the use of a semantic shell can provide this functionality without the need of a complex GUI. Thus, our notion of a shell is much more general and enhances the traditional Unix shell in several aspects. One of these aspects is the introduction of semantically enhanced commands. Such commands are aware of their environment and may act in accordance to it. Let us consider the following use case. A scientist likes to execute a number of compute intense tasks. He would like to be notified immediately when a task is competed regardless of time and location he is in. Thus, a command such as submit -cmd /home/greg/myprg -notify Gregor would look up an object called Gregor that specifies where
to send the notification to. This may not just be an email. The user may decide to have notifications forwarded to his cell phone via SMS messaging. The behavior where and how the notification is delivered is determined during runtime. Additional services can be integrated to help make the decision. Services such as iGoogle, Facebook, or LinkedIn may retrieve the address, or determine the location from a GPS enabled cell phone. This availability may also include a lookup to a calendar such as a Google calendar to block out times he may be in important meetings and thus be unavailable. Hence, the goal of the Cyberaide Shell is to bring the practice of service abstraction to the users environment while also integrating the newest Web 2.0 technologies. The paper is structured as follows. First we present some related research, followed by our requirements analysis. We present our architecture and describe our implementation. We discuss a use case scenario and conclude the paper. II. R ELATED R ESEARCH AND T ECHNOLOGIES The concept of the Cyberaide Shell is a novel combination of old and new technologies. Thus, it is important to investigate existing technologies of shells and grid environments. One of the oldest and most common tools in computing is a shell [4]. Typically, a shell is used to abstract the details of an operating system kernel by providing a unified interface and a set of tools to the system’s users. By doing so, a shield is created for the user to protect them from the intricate details of the underlying system. Shells are commonly found as part of open source developments. Most notably SourceForge [5] has almost 600 system related shells. There are noteworthy features in some of these shells that are not part of the more common system related shell in dominant use today. These features include distributed execution, object oriented shell manipulation and semantic parsing. Some of the more elementary feature comparisons for a small subset can be found at [?], [?], [6] Table I provides a classification of a number of shells in common use today. We distinguish Unix like shells with the emphasize on job control and file system management in a Unix like environment, distributed computing shells with the extensions to execute commands easily on distributed resources, language shells with the emphasize to use a given scripting language as part of the scripting abilities, domain specific shells that support a particular domain (we have listed a number of shells in the field of mathematics), and Portal shells that expose shell functionality through a portal. A. System Shells Current computer systems owe their success of usability to the original UNIX system shells. At the time, sh and csh were innovative and new ideas which made computing systems easier to use for both developers and non- developers. Many technologies today are based on shells, especially in the UNIX and Linux environments. Microsoft Windows owes much of its success on the original DOS shell of the 1980’s that is now continued in the PowerShell.
TABLE I L IST OF SHELLS BY CATEGORY
•
•
•
•
•
System Shells – sh [7], ksh [8], bash [9], zsh [10], csh [11], tcsh [12], rc [13], [14] Distributed Computing, Grid, Cloud, and Cluster Shells – TACC Gridshell [15], JXTA [16], dsh [17], pdsh [18], pssh [19], Language Shells – BeanShell [20], IRB [21], Python CLI [22], iPython [23], groovysh [24], Domain Shells – gnuplot [25], R [26], Matlab [27], Mathematica [28], Portal Related Shells – GShell [29], Ubiquity [30], Legion Portal [31], TeraGrid Portal [32]
A system shell provides a scripting framework to automate tasks in a coordinated way. A user can automate a number of tasks by writing an initial script and then using and modifying the code as needed. B. Distributed Computing, Grid, Cloud, Cluster Shells. Traditional system shells were developed for use on a single system. Over time, some shells have been enhanced to execute jobs on a variety of remote systems. The frameworks to address this distributed execution are numerous, so we focus only on listing a few examples and highlighting features that are important to the design of Cyberaide Shell. a) Distributed Computing and Cluster Shells: In order to easily utilize many resources distributed computing and cluster shells typically provide functionality to execute jobs simultaneously on many machines. This allows a user to specify a single command, but use all of the machines in parallel. This is beneficial not only for an end-user but also for the deployment of a compute system. b) Globus and CoG Kit Commands: There have been a number of efforts to try to simplify Grid computing for the scientific community. Early on, the Globus Toolkit and the Java CoG Kit [33] provided a set of command line tools that could be used to manage jobs in a Globus-enabled Grid. This includes commands for authentication, file transfer, and job submission. In the CoG Kit we even developed a python-based Cyberaide Shell prototype, which we will replace with the effort described in this paper. c) GSI enabled SSH: One of the important efforts in making Grids more accessible is the introduction of an ssh client that uses the Grid Security Infrastructure(GSI) as part of the authentication process [?]. However, it is not a shell and thus limited in its scope. The benefit of GSISSH is its ability to authenticate to a remote machine using GSI. d) Gridshell (TACC): A GridShell developed by Texas Advanced Computing Center (TACC) [?], [34] is as an ex-
tension to the tcsh and bash shells. It supports access to elementary Grid commands within the shell and integrates it into the shell language. For example, the use of the file redirection syntax allows users to access GridFTP servers. To execute a command on a remote machine the keyword on followed by the machine name can be used to execute a job on another Grid resource. e) Portal Shells: One of the mayor deployments of Grid technologies is the TeraGrid [35], which is sponsored by the National Science Foundation (NSF). While the TeraGrid has a portal that provides project and resource management tools to the user, actual interactive job management on the TeraGrid remains an unsolved task. TeraGrid provides access to all of the tools listed in this section. In addition, it allows the access to remote machines through a terminal using mindterm [?] integrated into the portal. Typically, a portal is orthogonal to a shell, while providing an easy method of viewing the Grid at a glance and a large array of information in an easy to use system. Thus, adhoc scripting is often not supported easily. Instead users may achieve this by using sophisticated workflow frameworks that have a steep learning curve. f) Cloud Shells: A new term used in the community is Cloud Computing [36].1 In cloud implementations, services are available to the user through predefined APIs and Web services and hide all underlying hardware technologies. This is typically accomplished by the use of virtualization [37] and exposing functionality as services. A number of tools have been developed to access clouds from the command line or from scripting languages.
Based on our consideration for the target audience for Cyberaide Shell and the efforts reported on in Section ?? we have identified a number of essential requirements that we need to consider in our design. These requirements include the following items: •
•
•
•
C. Scripting Language Shells. A wide variety of shell interpreters exist in scripting languages such as Python, Ruby, and Groovy. These languages feature an interpreter by default and can function as basic system shells if used correctly. Third party shells such as Python CLI, iPython, and IRB also exist which use these languages to provide an easier interface and added support for customization through objects.
•
•
III. R EQUIREMENTS The intended user community shapes the requirements of the Cyberaide Shell . We identify three groups: • Scientific power users that have to develop advanced solutions that are best formulated with the help of scripts. These scripts can be exposed as part of a SOA to novice users. • Grid developers and deployment experts that use the scripts to provide new functionality to the scientists and administrators. • Intermediate scientific users or Grid developers that use the Grid sparingly, but have an wealth of background in shell usage or scripting language experience. 1 Although the is a debate in the community about the differences between Cloud and Grid computing, it is beyond the scope of this paper to participate in this discussion.
•
•
•
•
Simple, intuitive, and user friendly – Cyberaide Shell must be simple to use and expandable for the users who are not experts in cyberinfrastructure. Furthermore it must be intuitive to users and must be user friendly. Unifying and integration – Cyberaide Shell must provide a framework to unify various Grid, cloud, and commodity shell efforts. The ability to integrate programming, scripting, languages, and scientific problem solving environments or workflow frameworks is essential. Hence, it must be integrated with the state-of-the- art cyberinfrastructure tools such as clusters, Grids, and Clouds. However, it must also be able to utilize established shell backends like ssh in order to utilize remote resources. In addition, integration with scripting and programming languages is a must as it will provide different user communities with a much richer set of functionality and expose the commands of the through an API for the target languages. Examples of these target languages include Python, Ruby, Matlab, and R. Extensible – Cyberaide Shell must be extensible not only by providing scripts in a user path, but also by adding modules and APIs at a late time. Batch processing – Many scientific jobs are too complicated to be started in an interactive mode. Hence Cyberaide Shell will need to support batch processing. In addition it must be able to run jobs in the background. These background jobs must be uniquely identifiable to obtain information about specific the jobs and their progress. Interactive – Cyberaide Shell must provide an interactive mode for the user to communicate with and probe the cyberinfrastructure in order to design ad hoc solutions. Status and Information – Cyberaide Shell must provide easy access through an information management system. This system should query and report upon the status of the cyberinfrastructure and the tasks being performed. Event management – Cyberaide Shell must have an event system to provide users with the ability to subscribe, monitor and react to the ever-changing activities. Exception Handling – It is desirable to provide an exception model to deal with the uncertainties associated with a Grid computing framework. Fault Recovery and Debugging – It is desirable to include features for debugging and fault recovery to assist the scientist through technology limitations. These limitations include the sporadic nature of Grids and Clouds that make it difficult to guarantee resource availability at any moment in time based on location. Integration with Web 2.0 – A great variety of tools to manage user contacts, calendars, and communication
pathways are already existing as part of Web 2.0 related efforts. The Cyberaide Shell will integrate with such available frameworks. Once we implement these requirements in our design Cyberaide Shell can lower the entry barrier to Grids and Cyberinfrastructure. IV. D ESIGN The Cyberaide Shell contains 4 high level design components that make it unique when compared with any other current technology. The four components areto object management, cyberinfrastructure backends, comandline interpreters, and services as depicted in Figure 1.
manage jobs, resources, and people. In reality, Cyberaide Shell is an application that launches separate sub-applications. Each sub application or command is accompanied by a manual page which accurately outlines its usage. Using this command CLI in a consistant manner allows for detailed scripts to be executed, which further enriches the end user’s experience. As a fourth component to Cyberaide Shell , we provide within our shell a new concept that we term Literate Semantic Objects (LSO ), which is used as part of the internal design of the Cyberaide Shell . These objects are semantic, as an identifier can easily specify them, but the way an operation is applied to these objects depends on the attributes at runtime. We envision a command sequence such as: set -resource teragrid set -scheduler QBETS submit /usr/bin/myprg -I 1 ... submit /usr/bin/myprg -I N
Fig. 1.
High level design with the essential components of Cyberaide Shell
A. Design Overview Typical shells provide a command line interpreter to expose system functionality. The goal of Cyberaide Shell is to provide the same functionality, but instead to be used in cyberinfrastructure. We have designed Cyberaide Shell to enchance the typical functionality by integrating three more important concepts. First, the design of Cyberaide Shell contains components to access a variety of new cyberinfrastructures, Grid, and Cloud toolkits. This includes Globus, Condor, BOINC, Amazon EC2, and the CoG Kit. We have also designed an abstraction framework that will make it possible to integrate other backends for future cyberinfrastructure needs. Second, we expose much of the functionality of the Cyberaide Shell as service. This allows other computing frameworks to easily access our shell through independent entry point via another tool or even another programming language. Naturally, an API based binding can also be provided through our abstractions. However, we envision that most interactions will be conducted through secure Web services. Third, users and high-level applications interface with Cyberaide Shell through its standardized command line interface (CLI). This interface allows users to have an easy way to
In the example above, the user simply specifies the resource and the scheduler by using LSO names. The set command will search for the objects in runtime and load the specified behavior. Then the user uses the submit command to send tasks to the specified grid infrastructure without concern of the underlying technology. The second feature of a LSO is that all of them must be defined through a documentation page. No semantic object may be defined without documentation. Thus we actually derive the objects directly from their specification with in the Manual page and make them also independent from their actual implementation. At present we use an attribute value pair notation for the objects that includes required and optional attributes. We found that this simple scheme of validation is sufficient for our implementation efforts. However, in future we will expand our object framework to also obtain a full type system. B. Architectural Design Based on the high level design goals we want to interact with the Cyberaide Shell in a variety of ways. To support this, we follow a layered architectural service and component based design where different services interact with each other in predefined channels. These services are provided through a number of components. An overview of this architectural design can be seen in Figure 2. 1) Resource Layer: Cyberaide Shell is designed to use a variety of resources through different service abstractions. This may include Grid and Cloud resources such as Globus, Condor, and BOINC, and Amazon AWS, and traditional ssh daemons. However in this paper we focus mainly on the integration with the Teragrid, which uses the Globus Toolkit and simple remote execution using SSH. In addition Cyberaide Shell is able to utilize Web 2.0 services such as calendars, address books, and other services provided for example by Google, and Facebook.
Service Use Cases
User Layer Portal
Program
languages to a Cyberaide Shell Web service by providing a useful application interface. This can be implemented many different languages such as Java, Python, Ruby, Matlab, C#, or others.
Direct Access Use Cases System Shell
WSDL
Program
Shell Service Layer
Python
Ruby
Matlab
Java
Groovy
Language API's Language Layer
WSDL Cyberaide Shell Service
Firewall
Cyberaide Shell CLI Cyberaide Shell Objects
Shell Implementation Layer
Cyberaide Shell Remote Service Mediator
Firewall Resource Layer
Cloud Services
Fig. 2.
Grid Services
Commodity Services (sshd, ...)
Web 2.0 Services
Use diagram of Cyberaide Shell
2) Shell Implementation Layer: Our shell is based on a simple abstraction model that has proven to be useful based on the lessons learned from the CoG Kit [38]. This includes abstractions for job submissions, file transfers, and authentication. In addition to these traditional abstractions we have introduced a new set of abstractions that are related to managing people of a virtual organization and jobs that are based on real time requirements that can be easily incorporated as part of a calendar system. Naturally, the Cyberaide Shell includes a command line interface through which all commands are controlled and managed. Our semantic literate objects are used to interface between the various components and provide a convenient mechanism of access even from other languages as explained later. 3) Shell Service Layer: An important feature of the Cyberaide Shell is its ability to be used within a Web service. This allows the shell functionality to be also exposed to other services and application interfaces using this service. Thus a very flexible way exists to integrate through a service-oriented architecture other services. This includes the possibility to access Web 2.0 services to significantly enhance the functionality of the shell and make these services accessible easily through a command line or other interface that is provided as part of the Cyberaide Shell . 4) Language Layer: The application interface and the service provide an ideal way to expose the functionality of the shell and its internal components through language bindings. Thus it is possible to create a direct interface for new target
Fig. 3. Interfacing to different frameworks is achieved by a Cyberaide Shell Web service
5) User Layer: Through the interplay of components and services our design enables interacting with the command shell in a variety of ways. This includes an interactive command line interface used by the end users, a Web service interface used by portal developers, and an application programming interface used by developers to interface directly with the command line shell (see Figure 2). V. I MPLEMENTATION As stated previously in this paper, we present a prototype implementation of the design outlined above. The current state if a functioning Cyberaide Shell with the main components already in place. Additional features such as language bindings and additional cyberinfrastructure frameworks are currently in the design phase. We hope to release a fully functioning application within one year from now. This section will focus only on the features that currently exist in Cyberaide Shell. Table II contains a listing of all the commands that currently exist in the prototype. A. Command Line Interface The Command Line Interface (CLI) is the central component fof Cyberaide Shell. All incoming commands, either directly through the CLI or through the Cyberaide Shell Web service are interpreted through the CLI. Cyberaide Shell is built using Apache CLI 1.1 [39]2 . We have implemented enhancements to Apache CLI that make it easier to develop and manipulate command lines from within our code. This includes 2 In our original implementation we used Apache CLI 2.0, but as it has net been officially released we reverted back to 1.1 due to its greater acceptance within the community and its better integration with common maven repositories.
TABLE II C OMMANDS OF THE C YBERAIDE S HELL
calendar ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ person ◦ submit ◦ ◦ ◦ ◦ queue ◦ object ◦
command to interface with a real time calendar -search all lists all events entered in the calendar -search keyword -from from -to to searches the calendar for all events with the given keyword between the dates specified. -search -label keyword searches the calendar for an event with a specific label. -create -group name creates a new group of events with the given name. -search -group name searches the calendar for all events in a group with the specified name. -server start Starts the service that monitors the calendar and executes the events. -server stops Stops the server. -schedule -search options schedules all events that match the given option. command to manage people. -label label -name name -address address Adds a person to the people database. A label can be set to conveniently identify the person. command to manage jobs. -w launches the job and watches the input within the shell. -task myTask launches a specified task. -jcmd /bin/date launches a specific command. -resource uses a specific resource name to submit the job. command to manage shared queues. option description command to manage objects. option description
the definition of a framework that requires the creation of short and long command line arguments as well as a mandatory documentation for all commands. Apache CLI is based on three stages of command line processing: (a) definition, (b) parsing, and (c) interrogation. The definition stage is based on a convenient Java API that allows us to define options and parameters to commands. The parsing stage takes a given command and splits it apart to gather precise information about the options and parameters specified. The interrogation stage is defined by the programmer and allows querying options and parameters to execute the appropriate actions. We have provided an additional stage that we named registration stage allowing commands to be loaded at runtime. This enables us to load in commands at startup via a specification in the cyberaide properties file, or during the execution of the CLI. Cyberaide Shell users are able to integrate commands created by others that are either distributed with cyberaide, or placed into a runtime repository. Similar to other UNIX environments, Cyberaide Shell uses the notion of of a PATH variable that allows users to place scripts in a directory accessible as part of the PATH. While using these features, we have defined a number of basic commands that simplify the use of the CLI. These commands include man, history, cat, alias, sysinfo, and exit. Furthermore, we provide a shell path through to the underlying operating system with the in other shells customary ! character proceeding the command. A key component of Cyberaide Shell is the explicit use of nested shells, or a shell-within-a-shell. This means that each command has its own shell interpreter and that Cyberaide
Shell CLI handles the execution of subordinate CLI’s. These CLI instances are dynamically loaded upon startup of the shell. This means that the implementation of dynamic loading and the creation of a nested shell is a straightforward extension. Thus, within the main shell the user can specify either the full command with arguments, or just the command name. If a full command plus arguments is used, the CLI will interrogate the options and will execute in the way specified. If just the command name is given, a new shell for that command will open within the main shell, allowing users to issue a sequentially different parameters while not leaving the context of the command. This can lead to a significant reduction in scripting for repetitive commands. Users will be familiar with regular shells that essentially execute the following commands, each in one line (which Cyberaide Shell is also able to do): cybershell> set -f people_a cybershell> set -f people_b cybershell> Users can also take advantage of the nested shells like so: cybershell> set set> -f people_a set> -f people_b set> return cybershell> In the first case execution is achieved by starting two separate set commands with an internal quit that is not visualized to the user. The second case the contents of the super command are preserved and multiple invocations of the commands with different parameters can be issued.
B. Literate Semantic Cyberaide Objects
both Web services and other data storage techniques.
Typical shells contain string variables to be used as placeholders. In Cyberaide Shell we have introduced objects that contain a map of attribute-value pairs and is categorized by an object type. Our type system is dynamic, which allows users to addnew types or modify existing types at runtime. Each type has a set of mandatory attributes that must be defined at time of object creation. These attributes are: • this.id Unique identifier (serialization independent) • this.label User defined label for the element • this.type Object type name in which included e.g. Cyberaide.Person • this.name Name of the system • this.version Version number of this object in form of X.Y (major, minor). Start at 0.1. • this.keyword A list of keywords that can be associated with this object, keywords are seperated by ”,” In addition, each type contains a list of object-specific mandatory and optional attributes. An object is considered to be valid when all mandatory attributes are defined. Through this simple definition it is obvious that our objects can be represented in a variety of easy formats. They include XML, JSON, YML, and ASCII. A variety of transform operators and function exist that convert the object from one format to the other. Thus, the developer is given a choice of interacting with the objects. At present, we prefer the JSON format as it allows us to also access the Cyberaide Shell through JavaScript. These objects must be defined as part of a mandatory manual page describing the purpose and the use of the object. From this definition the objects can be integrated into the command shell at runtime. Thus, only objects that are literately defined will be able to be used within the shell. However, the definition of the objects as part of a manual page is simple and provides little overhead. The objects become semantic when they are evaluated dynamically at runtime. The earlier example of reading from an object that may contain the e-mail, the phone number, and the SMS contact of a person will allow us to use the notification option of the submit command in a semantic context. This context may be derived while integrating other services that determine which of theses contact methods could be chosen at the time. Cyberaide Shell allows for predefined objects to exist together with the shell itself. A list of predefined types is available in Table III. These objects are defined by explicit types using a standardized specification manual. The specification manual is processed and creates a predefined type for each object type defined. The set command is responsible for reading in the predefined types at runtime and correctly instantiating new object and modifying current objects to include all the desired attributes. The set command can also organize groups objects into a set. These sets can be filtered based on one or more values to aggregate pertinent information at runtime. Both the objects or the object sets can be exported in JSON, XML, and ASCII format files to enable interoperability with
C. Job Execution The current prototype of Cyberaide Shell supports two resource types for remote job execution, performed by the submit and execution commands. The first job submission is using the Teragrid. This is done using a combination of tools that are part of the Globus Toolkit. Login is managed through MyProxy [?], a x509 credential management service that works with the Grid Security Infrastructure (GSI). Job submission and monitoring is done by the globusrun-ws command, which uses the WS-GRAM protocol to submit jobs to a wide variety of batch queueing systems, such as Condor or PBS. The other job execution resource is through SSH. The SSH extension simply logs into a remote computer and spawns off a new job. Monitoring the status and getting the results are done by separate login attempts as requested by the user. In the design of Cyberaide Shell the difference between a task and a job are highlighted. A task in Cyberaide Shell is simply an event that needs to occur at some point. This is analogous to your friend asking you to buy a candy bar. A job in Cyberaide Shell is a task that is executed on a specific resource, typically with an implied time requirement. This resource is typically either a Teragrid cluster or a SSH endpoint. This can be related to the milk example by having your friend tell you to go buy a candy bar at Walmart within the next two hours. A job’s status is represented by a few simple but important states: • Queued A task has been submitted using Cyberaide Shell, however it has not been assigned to a specific resource. • Pending A job has been assigned to a specific resource and awaiting execution • Running A job is currently executing on a resource • Finished A job has finished its execution and is returning to the user • Done A job has finished execution and all results have been received by the user • Failed A job has failed for any reason and cannot execute. D. Calendar Access One of the features of the Cyberaide Shell is the ability to access calendar related functionality. We can create arbitrary calendars that can be shared with other users and manipulate calendar events from the command line. To do so we provide a calendar command with a variety of options. This command allows us to create calendar events, user groups, and listings of calendar events based on regular expressions and time restrictive searches. A calendar can also be exported in JSON object format or iCal. This was done to interface with a number of other client tools to manipulate the calendar as the user desires. One of the more advanced features of our calendar is the option to store in the note section of a calendar event the object that represents an actual job submission on a Grid. To execute the Grid job our design includes a calendar execution service,
TABLE III C YBERAIDE S HELL O BJECTS
users ◦ ◦ ◦ ◦ resources ◦ ◦ tasks ◦ ◦ ◦
objects to manage user settings cyberaide.user Information about user personal data. teragrid.user.dn Information about user X.509 Distinguished Names. cyberaide.user.action User data used in the TeraGrid registration process. teragrid.allocation Information about the TeraGrid allocation. objects to manage resources teragrid.account Information about a TeraGrid account on a resource. cyberaide.resources Information about a resource on the TeraGrid. objects to manage task scheduling and execution cyberaide.task Information about a generic task. cyberaide.workflow Information about a workflow settings. cyberaide.calendar.job Information about job scheduled in the calendar.
which is accessible through the command line interface. The service can be started and stopped with the corresponding commands calendar -service start and calendar -service stop. Such a service can also be run as part of an ad-hoc virtual organization that allows users to share a calendar to which the users can upload their jobs. Such an environment is of special interest to groups that need to share a resource in exclusive mode. Hence the group can easily set up through our framework a shared calendar for such a resource or device. At present we have implemented the calendar while interfacing with the Google calendar service which provides us an easy to use interface to calendars. In a related effort we are developing Microsoft Project to determine time dependent tasks that can be exported and included in our calendar service [?]. E. Service Framework In order to enable Cyberaide Shell in higher-level services such as programming language APIs or Web Portals, we use a specialized Web service to provide remote connectivity to the underlying CLI. This functionality can be exposed through a Javascript framework that we are also developing [?]. This allows for the creation of a Cyberaide Portal based on JavaScript. Figure 4 depicts a possible interface being used in activities that are commonly conduced with the help of the Cyberaide Shell . The Web service is implemented using the Apache CXF platform [?], which is an efficient and powerful framework. CXF uses the Jetty HTTP server [?] as a platform for hosting the Web services. Jetty is designed entirely in Java, which allows for Java-specific APIs to be used, which allow for standalone Web services to be deployed automatically. CXF is compliant with the JAX-WS standard and implements many of the Web Service Interoperability (WSI) standards including WS-Addressing, WS-Policy, WS-ReliableMessaging, WSSecurity and MTOM. Cyberaide Shell makes special use of the WS-Security standard, which uses SOAP-level encryption to ensure endpoint-to-endpoint security. The current web services implementation works by passing using Cyberaide Shell scripts in realtime. The following commands make this possible:
Fig. 4. A Cyberaide Shell Portal enabled through JavaScript and the Cyberaide Shell Web service
• • • • • •
submit() Loads the script into Cyberaide Shell . run() Starts the script loaded into the Web service. kill() Unconditionally stops the script currently running. getStatus() Queries for the current state of the script. getOutput() Returns all the output generated by the script getError() Returns any erroneous output generated by the script
Web service is set up as an executable jar file where one simply specifies the hostname of the machine the Web service will be running on. After starting jar Web service, the WSDL is published and the web service itself is ready to process requests. Client connecting need to also implement the WSSecurity standard defined by WSI over the secure HTTPS protocol and authenticate using an X.509 certificate. VI. C ONCLUSION Advanced but simple to use tools are needed to further ehance the usibility of Grid computing for application users. This may lower the entry barrier to Grid computing like never before. If this enhanced usability is created, it could cause
an explosion in the scientific community by making Grid computing practical to a larger user group. Cyberaide Shell was created to deal with the challenges of using advanced cyberinfrastructure. Many ideas of the shell implementation were borrowed from various shell environments, which allows an experienced shell user to quickly become familiar with Cyberaide Shell . The shell also employs advanced tools which utilize the full potential of Grid computing. It is important to realize that Cyberaide Shell is a prototype. There remains much work to be done. If Cyberaide Shell is completed based on the design outlined in this paper, it may change the face of grid computing and cyberinfrastructure as we know it. ACKNOWLEDGMENT Cyberaide Shell would not be possible without the hard work and dedication of the Service Oriented Cyberinfrastructure Lab at Rochester Institute of Technology. Noteworthy members include Sanket Patel, Paresh Khatri, Akylbek Zhumabeyev and Litze Wang. Work conducted by Gregor von Laszewski is supported (in part) by NSF CMMI 0540076 and NSF SDCI NMI 0721656. R EFERENCES
[20] “beanshell.” [Online]. Available: http://www.beanshell.org/manual/ contents.html [21] “RubyShell.” [Online]. Available: http://www.rubycentral.com/pickaxe/ irb.html [22] G. van Rossum and F. D. Jr, Python Reference Manual. Centrum voor Wiskunde en Informatica, 1995. [Online]. Available: http: //208.109.184.181/Files/Documents/Python/ref.pdf [23] “iPython.” [Online]. Available: http://ipython.scipy.org/moin/ [24] K. Henry, “A Crash Overview of Groovy,” Crossroads, vol. 12, no. 3, pp. 5–5, 2006. [25] A. Liaw and D. Crawford, “gnuplot 3.5 User’s Guide,” Texas A&M University, Tech. Rep., 1995. [Online]. Available: http: //carina.fcaglp.unlp.edu.ar/∼zyserman/manuales/imprimir/gptug.pdf [26] “The R Project.” [Online]. Available: http://www.r-project.org/ [27] “Matlab.” [Online]. Available: http://www.mathworks.com/products/ matlab/ [28] “Mathematica.” [Online]. Available: http://www.wolfram.com/products/ mathematica/index.html [29] “Geronimo GShell.” [Online]. Available: http://cwiki.apache.org/ GSHELL/ [30] “Ubiquity.” [Online]. Available: https://wiki.mozilla.org/Labs/Ubiquity [31] A. Natrajan, A. Nguyen-Tuong, M. Humphrey, and A. Grimshaw, “The Legion Grid Portal,” in Grid Computing – Grid 2001, ser. Lecture Notes in Computer Science, vol. 2242, ACM, IEEE. Denver, Colorado: Springer-Verlag, Heidelberg, Germany, November 2001. [Online]. Available: http://legion.virginia.edu/papers/HPCS01.pdf [32] M. Dahan, E. Roberts, and J. Boisseau, “TeraGrid User Portal v1. 0: Architecture, Design, and Technologies,” in Second International Workshop on Grid Computing Environments GCE06, November 2006, pp. 12–13. [33] G. von Laszewski, “A Loosely Coupled Metacomputer: Cooperating Job Submissions Across Multiple Supercomputing Sites,” Concurrency, Experience, and Practice, vol. 11, no. 5, pp. 933–948, Dec. 1999, the initial version of this paper was available in 1996. [Online]. Available: http://www.mcs.anl.gov/∼gregor/papers/ vonLaszewski--CooperatingJobs.pdf [34] E. Walker, T. Minyard, and J. Boisseau, “GridShell: A Login Shell for Orchestrating and Coordinating Applications in a Grid Enabled Environment,” in Proceedings of the International Conference on Computing, Communications and Control Technologies, Austin, Texas, Aug. 2004, pp. 182–187. [35] “TeraGrid,” 2001. [Online]. Available: http://www.teragrid.org/ [36] R. Buyya, C. S. Yeo, and S. Venugopal, “Market-Oriented Cloud Computing: Vision, Hype, and Reality for Delivering IT Services as Computing Utilities,” Arxiv preprint arXiv:0808.3558, vol. 08, pp. 35– 58, 2008. [37] VMware, “Understanding Full Virtualization, Paravirtualization, and Hardware Assis,” VMware, Tech. Rep., 2007. [38] K. Amin, G. von Laszewski, R. A. Ali, O. Rana, and D. Walker, “An Abstraction Model for a Grid Execution Framework,” Euromicro Journal of Systems Architecture, Apr. 2005, accepted for publication. [Online]. Available: http: //www.mcs.anl.gov/∼gregor/papers/vonLaszewski-abstraction-jsa.pdf [39] “Apache Commons CLI,” Vesrion 1.1. [Online]. Available: http: //commons.apache.org/cli/introduction.html
[1] I. Foster and C. Kesselman, “Globus: A Metacomputing Infrastructure Toolkit,” International Journal of Supercomputer Applications, vol. 11, no. 2, pp. 115–128, 1997, ftp://ftp.globus.org/pub/globus/papers/globus.pdf. [2] D. Krafzig, K. Banke, and D. Slama, Enterprise SOA: Service-Oriented Architecture Best Practices, Krafzig, Ed. Prentice Hall Ptr, 2004. [3] I. Foster, C. Kesselman, J. Nick, and S. Tuecke, “The physiology of the grid - an open grid service architecture for distributed systems integration.” [4] A. Taddei, “Shell choice a shell comparison,” Guide CN/DCI/162, CERN, Geneva, Geneva, SW, Tech. Rep., September 1994. [Online]. Available: http://www.hep.phy.cam.ac.uk/lhcb/LHCbSoftTraining/ documents/ShellChoice.pdf [5] “SourceForge.net System Shell Categroy.” [Online]. Available: http: //sourceforge.net/softwaremap/trove list.php?form cat=294 [6] R. Burk and D. B. Horvath, UNIX Unleashed, System Administrator’s Edition. Macmillan Computer Publishing, 1997, ch. Which Shell Is Right for You? Shell Comparison. [Online]. Available: http: //athena.vvsu.ru/docs/unix/unix adm/ch13.htm [7] “sh.” [Online]. Available: http://www.grymoire.com/Unix/Sh.html [8] “ksh.” [Online]. Available: http://www.kornshell.com/doc/ [9] “Bash - Bourne Again Shell.” [Online]. Available: http://www.gnu.org/ software/bash/manual [10] “zsh.” [Online]. Available: http://zsh.sourceforge.net/Doc/ [11] “csh.” [Online]. Available: http://www.hmug.org/man/1/csh.php,http: //www.kitebird.com/csh-tcsh-book/csh-intro.pdf [12] “tcsh.” [Online]. Available: http://www.tcsh.org/Home [13] T. Duff, “Rc - The Plan 9 Shell,” AT&T Bell Labs, Tech. Rep., 1991. [Online]. Available: http://netlib.bell-labs.com/sys/doc/rc.html [14] “Microsoft PowerShell,” http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx. [15] E. Walker, T. Minyard, and J. Boisseau, “GridShell: A Login Shell for Orchestrating and Coordinating Applications in a Grid Enabled Environment,” The University of Texas at Austin, Tech. Rep., 2002. [Online]. Available: http://www.tacc.utexas.edu/publications/gridshellcoordinatingapps.pdf [16] L. Gong, “JXTA: A Network Programming Environment,” IEEE Internet Computing, vol. 5, no. 3, pp. 88–95, May 2001. [Online]. Available: http: //pompone.cs.ucsb.edu/∼wenye/majorexam/Architecture/Gong01.pdf [17] “dsh.” [Online]. Available: http://www.penguin-soft.com/penguin/man/ 1/dsh.html [18] “pdsh.” [Online]. Available: http://linux.die.net/man/1/pdsh [19] B. Chun, “Pssh HOWTO,” webpage. [Online]. Available: http: //www.theether.org/pssh/docs/0.2.3/pssh-HOWTO.html
