Well, for those who visit ~Sterling, you may have noticed my MS Report. I "cheated" a slight bit in that I mixed my academics with work. The basis of my work was an agent-based system for managing accounts. Basically, I designed a system that used a centralized workflow system to create jobs. Then, multiple independent agents would carry out the duties of these jobs. The original implementation wasn't very nice to work with or very robust. It was also grossly incomplete.
In the time since, I finished implementing the rest of the system and revamped the implementation a few times. Originally, I thought it would be neat to be language independent through the use of a simple HTTP communication protocol using simple text that could be parsed by even Bash with little fuss. Well, that wasn't such a great idea because it required implementing both ends of a communication protocol with any change. So, I gave in and reimplemented agent to workflow communication using SOAP over HTTP---far superior and still mostly language independent. The likelihood of wanting a bash-based agent is slim anyway. I've also added a protocol for automatically installing agent updates and handling of a number of new fields, etc.
Tonight I just finished the basis for a mini-language for writing new agents. The problem was that all the agents were written in Perl and it took between one and three days to write new ones, test them, and install them. Initial installation also required touching each agent-running machine to update the crontab. Furthermore, I had to be careful with the updates because a change that failed compilation could prevent automatic updates from functioning, which meant I needed to manually reinstall.
Thus, I've written an extremely simple language that embodies the needs of all agents. It includes a header (I call the "exordium" 'cause I'm a dork) with metadata information about the agent, such as name, description, version, etc. This information may be used for automatic updates and scheduling, but doesn't affect the actual agent execution. The rest of the file contains the agent program itself (I call the "coadjutor" also 'cause I'm a dork).
The coadjutor language includes a very few commands to do things. The REQUIRE command requires that a ticket in the workflow system contain certain basic information prior to being acted upon at all. The CHECK command validates the information in a ticket and reports an error if there are problems. The SET command alters information in a ticket. The WHEN and FOREACH commands allow for limited control of program flow. The COMMAND, OPTION, and EXEC commands execute an external program. These can also utilize a very simple set of boolean and scalar expressions. Any complicated work or extensions can be done through the use of external programs and Perl functions defined in a special package.
At this point, I think the direction of the system needs to change. Development up to this point has been completely proprietary for CIS. I think I'm going to start generalizing the system and then I'll probably release it under the Artistic License and I think I'm going to start looking now for places to formally publish some information about it.
The next directions I will be heading are to completely generalize the engine beyond account administration. It could quite easily be used to run programs on groups of machines in the department or recover backup files or notify users of other problems.
The new system won't depend upon a workflow system, but upon more general data sources. A data source would be any system that can provide distinct records to the agents such that each agent iterates over the records and takes action on the basis of the information in those records. A workflow system might be one such record system. An LDAP directory might be another. A SQL table could be another. The agents will also have a hook either to the workflow or some sort of logging system where the agent can put in requests for jobs to be undertaken by other agents or even the systems administrators themselves. In this way, I can generalize the system so that it no longer depends directly upon RT and so that the agents can do new things like, check that all users have a username that matches the campus wide eID system, or check that all users have a high enough quota and notify them if not. I could even have an agent that attempts to install agents on all machines in the department for which it knows the administrative password.
This will also make it general enough to be useful beyond our little department. I think I may have something more general available this summer.
Leave a comment