Although agents seem to work magically behind the scenes, it's really the Agent Manager that keeps things on course. And Julie Kadashevich is also there behind the scenes, making sure the Agent Manager stays on track. To make the Agent Manager less of a mystery to users, she's written several Notes.net articles, including "Controlling the agents in your system," "Minimizing the delays in the Agent Manager," and "Troubleshooting agents." We recently talked with Julie about the Agent Manager and where it's going in R5.0.

Let's start with the basics. How would you describe the Agent Manager to new users?
The Agent Manager is the main harness for agents. It determines who can run the agents, where they should run, and when they should run. It sets up the context for the agents to run in, checks security, and handles loading, invocation, caching, error reporting, and logging.

What are the different components that are necessary to make agents run?
Well, the Agent Manager sets up the general infrastructure to support agents. The Agent Builder hooks into the Agent Manager, and allows the end user to create and save agents. Depending on the type of agent, the Agent Manager may perform database operations for simple actions, evaluate formulas, or call back-end classes. For event-triggered agents, the Agent Manager monitors events and then determines when the agents should be invoked. It also watches the clock and invokes scheduled agents when the right time comes.



What about agents written in Java vs. agents written in LotusScript? Does the Agent Manager care how they were written?
The amount of agent code that is Java-specific is (perhaps surprisingly) small. Obviously, you need to account for the multi-threading and the different type of internal format, but the bulk of the code is shared by all agents. Which is, of course, good, because we want as much consistency between different types of agents as possible. Users can pick and choose the language they want to use, and they don't have to remember different rules for each type of agent.

How does the Agent Manager work differently for Web-based agents vs. agents that stay within the Domino/Notes environment?
There are two main differences between Web-based agents and Domino/Notes server agents. First, the Web does not have a scheduling mechanism, so Web agents cannot run based on a schedule and that part of the Agent Manager is never exercised. Also, there's another security option for Web agents, where designers can control whether the agent will run with the authority of the agent signer (just like Domino/Notes server-based agents) or with the rights of the agent invoker (the Web user). This authentication determines what the agent can do in different databases.

The only other thing is that the Agent Manager runs as a separate task on the Domino/Notes server, and it is linked in as part of the HTTP server for Web operations. This means that users don't see the Agent Manager loaded when they run Web agents.

What one feature of the Agent Manager do you think people don't know about, but should?
How about two? The two most helpful things that some people don't know about are the server console commands and the Notes.ini variables that can help you to troubleshoot and tune the Agent Manager. I've covered these features in my articles for Notes.net: "Troubleshooting agents" and "Minimizing delays in the Agent Manager."

What kind of competitive advantages do users get with Domino/Notes agents and the Agent Manager?
The main advantage of Domino/Notes agents is their sophisticated and flexible security mechanism. The administrator can control who can create agents, who can run agents, and what operations the agents are allowed to do. In addition, the administrator can control whether users can create agents that can be executed by other people (shared agents) or only create agents for themself (personal agents).

Replication is another unique strength of Notes agents, because it allows the agents to be distributed. Agents live in Notes databases, which means they get all of the advantages of the Notes databases -- they get replicated to different servers, they are administered as part of the database, and all database utilities are agent-aware.

Notes agents are also good about logging their activities, so agents are very trackable. The server log contains information about which agents ran and who ran them. You can turn on various debugging settings to get more or less information about various agent activities.

Also, Notes agents offer a lot of flexibility. If you have never written a line of code before, you can write agents by chaining some simple actions together. Or if you are a seasoned programmer, you can write agents with LotusScript or Java, and develop some rather sophisticated applications. So just about anyone can write an agent. Once the agent is written, it can run at a scheduled time, or based on events (such as new mail arriving, or documents being modified) or by invocation from the UI (for example, from a button on a form or from the agents menu). The agents can run on the client, on the server, or on the Web. They can be called from other agents. You can make things as simple or as complex as you like.

You mentioned security. How does the security get set up? What does the administrator have to do?
In a production system, the administrator controls the rules that control the agents. (A production system is where Notes is used to run the business, in contrast to a development system, where agents are developed and tested.) The administrator sets up agent security by first specifying information in the Agent Manager section of the Server document. Then, they need to set up appropriate database ACL rights for the agents to do the job they are supposed to do, and yet not be able to access databases they are not supposed to access. In addition to security, they need to set up the parameters that control the Agent Manager load, the number of concurrent agents running, and the maximum amount of time LotusScript and Java agents are allowed to run (all of this information goes into the Server document). They might want to fine tune various Notes.ini variables to customize how the agents are running on their system.

What do the users have to do?
In a production system, the users are the ones who run or create agents. In a development system, the user may do some of the operations that an administrator might do in a production system.

What are some of the customer requests you were able to implement in R4.6?
We added support for Java agents in 4.6. Java is cool, and everybody wanted to do Java. We added new methods to the object model, for example, the methods that allow users to enable agents programmatically (IsEnabled), as well as programmatically set the name of the server on which they should run (ServerName). The NotesRichTextStyle class and NotesRegistration class were also feature requests from customers. And, we added support for a wildcard character as the name of the server on which the agent is allowed to run. We added a hidden method RunOnServer(), which allows a foreground agent to invoke a server-based agent. This was done because our business partners told us they needed it (particularly when interfacing with relational databases). It was such a hit that we made it unhidden in 4.61 release. I am sure there are others which I am forgetting at the moment.

What do you see as the biggest challenge for R5?
Picking the right things on my long wish list. Hopefully these will be the things that would make the largest number of people happy.

So, what are some of those things? What changes do you see happening in the Agent Manager for R5?
The main new feature that we hope will make a lot of people happy is support for a new type of mail trigger. This new trigger will allow users to write agents that will process mail before it reaches their mail box. So, for example, they will be able to file mail into folders other than the InBox, or even delete messages that are too large or inappropriate for some reason.

There are also UI improvements in the Agent Builder and changes in the overall look of the Agent Manager. I am also doing a lot of behind-the-scenes type of improvements in performance and debugging tools.

What else are you working on for R5?
To keep my Java skills sharp, I am doing a bit of Java coding. I am working on handling international issues in the Java Virtual Machine interface layer, like making sure that error messages we generate come out in the appropriate language.

Any final thoughts on the future direction of agents and the Agent Manager?
Our goal is to continue to improve the performance of agents and to make them easier to use -- whether that means setting different system defaults or tweaking the UI. We'll do whatever we can to make the Agent Manager less of a mystery.

BIOGRAPHY
Julie Kadashevich came to Iris in March of 1997 after working at FTP Software on Java and C++ mobile agent technology. Previously, she worked in the area of applied Artificial Intelligence at Wang Labs and received five patents in the field. She has Bachelor's and Master's degrees from Boston University, both in computer science. Outside of the Agent Manager, her two main interests are photography and quilting. She's a computerized quilter who develops her designs on a PC. Her photographic work is devoted primarily to nature subjects and portraits -- including the self-portrait that accompanies this interview.