Thebes

This example is a large chain of small auto service shops. Each shop has approximately 20 employees, a small network with a local point of sale system writing to a local database. Each shop maintains its own security and identity store, under rules and oversight from the corporate offices. There are senior employees at each shop with permissions to write to the financial portion of the database, all employees are able to check in cars, detail what has been done at each visit, and review previous work.

Historically, there may be a single database under corporate control with each store writing to this database periodically. Or, there may be no communications between each store and the central office. Assuming some sort of routine data transfer from stores to home office, employees would need a second set of credentials to connect to the corporate database. Data would be uploaded to the corporate office from each database either in near real time or in batches.

Rather then maintaining a monolithic database, Thebes allows for a widely distributed solution. Each shop maintains it’s own identity store and a local copy of the database. Data entry is done locally and data is stored locally. Data is never transferred to the home office; instead it is retrieved in real time when needed via searches that can span the entire system. It may be useful to keep multiple copies of each shop’s data at one or more other shop to improve data access speed and protect from a single node dropping out. Data transfer would only be of data relevant to a query, the results can be saved or not depending upon the needs of the requester.

Actors:

Systems administrators: Administrators at each shop will connect the identity provider to the local identity store, install the local instance of the database, and connect the database to the nearest resource discovery node. Each client computer at each shop and corporate offices needs custom client software that plugs into the Thebes infrastructure. Authorization to the database will be accomplished via the Thebes plug-in. This is equally true of local users and remote queries.

Technicians: The junior technician logs in to the database using the same username and password pair that they use to connect to corporate email and the local area network. The level of access the technician receives will be based upon the attributes in their LDAP entry. When a customer arrives at the shop, the technician will collect a minimum set of information about the vehicle. Possible data collection points might be VIN number, license plate number, or owner name and phone number. This can even be accomplished on a hand-held device. If the vehicle has a local history, the local details will be immediately displayed, a search of the data grid will immediately commence. All work done by that company at any location to that vehicle will be returned to the technician’s workstation. Remote databases are located dynamically via the resource discovery network. The technician uses this data to make service recommendations to the customer.

As work is completed, it is entered into the database. Because this is local data, the response time is fast. It is also available in real time to senior management for evaluation.

When the work is completed, a senior technician/manager logs in to check the customer out. The senior manager has additional attributes in the LDAP directory. These attributes automatically grant access to make entries in the financial area of the system. The work performed that session is displayed. If there are warranty issues, the senior technician will have the necessary data available, no matter where the previous work was performed.

Customers: When a customer is checked in, the entire history of the vehicle (in that company’s shops) is available to the technician. The technician will check the customer in to the local, comparatively lightweight database, at local area network speeds. The customer will receive a quick high quality experience. In the background, the system will recover any work done to that vehicle anywhere in the network. At the end of the visit, a senior technician will handle checkout and financial transactions based upon that technician’s higher level of access.

This also gives the customer other opportunities. There are a variety of reasons a customer may want access to data about work done on a vehicle. Individual owners may want to use this system to track maintenance to their vehicle and plan for upcoming routine maintenance expenses. Corporate fleet managers may want detailed reports about the maintenance done to their vehicle. This is possible via a web portal interface to the database system. Usernames and passwords would be assigned when a customer is actually in the shop, giving a higher level of assurance to the security mechanism. This is a possible sales tool for this company, and will ensure customer loyalty, just because it can provide a single source for maintenance records.

Local Management: Local managers will have access in real time to all transactions being handled in their shop. This access will be available using the same client and authorization mechanism the other players have, but their attributes grant them a higher level of access. The data available to local management will be real time to the level of being to study how many cars are in the shop at any given moment.

Senior Staff: Prior to the installation of the system, senior management will have decisions to make. A single data structure will be created. This is executed in a standardized database that all shops in the system will use. A Thebes enabled client to the database system will allow senior staff to collect and analyze data from all distributed databases via queries to the data grid. Once these decisions are made and the system is installed, management will have immediate, real time, access to all details of the entire system and each individual shop in the system. The level of detail will be as rich as the design of the database will allow.

This is a very minimal Security Token Service based on the STS that ships with Apache Rampart. This is generally not usable as a generic STS yet.

The Thebes Client can be called from a command line or from a Swing based GUI.

Installation
The Thebes Client depends on the Axis2 distribution available from the Axis2 Home Page

Command Line Client

java Thebes [options...]
-f INPUT : JSDL file for request
-p VAL : Password to connect to the STS
-policy VAL : Policy file for request security
-r VAL : ID of the job to retrieve the result
-s VAL : ID of the job to retrieve the status
-sts VAL : Endpoint URL of Security Token Service (STS)
-stspolicy VAL : Policy file for requesting security token from STS
-u VAL : Username to connect to the STS
-url VAL : Endpoint URL of Thebes SP

Each command line argument can also be stored in thebes.properties

Swing GUI

java edu.georgetown.middleware.thebes.gui2.ThebesTool2

There is a script file in the etc directory to launch the GUI (ThebesGui.sh or ThebesGui.bat)

The thebes service is built on Apache Axis. The AAR file is a deployable Axis service.

This section will be where downloads and instructions are placed.

This is the final repost of missing GridsWatch postings:

So, it seems to me, imho, that the closely held definition of the word grid by the keepers of truth in the grid world, combined with the ham-handed misuse of the term by vendors, has pretty much killed "Grid". At least the word, but not the concept.

I don't find it surprising. The original software was built to satisfy a specific use case. A small group of well funded big science academic researchers gobbling up all the resources they can lay their hands on. Some papers and a couple of big books later, we have a highly complex system that only a developer could love. But...the word got buzz, it was exciting, excellent analogies were built (power grid, transit grid), stories grew up around the concept. So corporations got curious and started asking, and vendors starting writing their own definitions.

The most successful grids in the world aren't. They emulate security by limiting how many scientists can ask questions. The rules are that the scientist has to have altruistic needs and a good story. If the story is good enough, these grids can attract joe and jill computer owners to connect. GU is the 115th largest team on World Community Grid based upon a 5 point extra credit assignment given to the Intro to CS for non-majors class.

It's time to evaluate the use cases and build something valuable. A computational Internet. A place where owners of resources can allow groups of researchers to run applications safely. If you want your computer to be used to help cure cancer, you should have the power to give ALL cancer researchers access.

All it takes is a way to prove a person is a cancer researcher. Resource owners don't need to know each researcher's name, they just need to know where cancer research is being performed. Identity providers at each research center can handle proving whether or not a person is a cancer researcher.

SAML provides the tools to do this, but tacking SAML solutions onto existing grid solutions adds more complexity. Let's see about making job schedulers, file systems access, sensors, and license managers SAML aware. Let's see about building a simple to join consortium of resources that publishes resources to be discovered by a resource discovery network made available to all researchers.

Let's make whatever replaces 'grid' look like the Internet. Even the playing field. Rip the grid out of the hands of big science and make shared resources available to everyone.

Arnie Miles