A standard interface for Agents.
For a list of all members of this type, see AgentInterface Members .
| Type | Description |
|---|---|
| AutoReplyAgent | This agent sets itself up to receive messages from a ReceiveEmailAgent and automatically respond to the sender using the SendEmailAgent. In most cases, this will be subclassed and the getReply method should be overridden. |
| EmailBugReportAgent | This agent registers itself with the Service Manager as a BugReportInterface and periodically submits the bug reports collects as an email message to a list of recipients using the SendEmailInterface registered with the Service Manager as "send_email". |
| EmailReporter | This is a Reporter Agent that extends FileLoggerAgent in order to log AK agent output to sequentially named text files. Upon loading, this agent replaces the default Reporter. |
| ReceiveEmailAgent | This agent receives SMTP messages on a server socket (port 25 by default) and forwards them to RequestAgents registered to the Service Manager using the recipients email address (ie: name@domain) or email account name only (ie: name). On UNIX operating systems, root access is required to serve on port 25. You will also need to kill sendmail or any other SMTP servers that may already be using port 25. It may also be necessary to add a MX DNS entry for your server in order to allow SMTP messages to be routed properly to your server (read "DNS & BIND" from O'Reilly publishing for a good reference on DNS). |
| ReceivePOP3EmailAgent | This agent periodically checks for new POP3 messages, passing routing the message to the registered RequestAgent matching the message recipient's email address. |
| RequestDumperAgent | This is a simple agent which dumps the contents of the requests it receives. This can be used for debugging messages received by the ReceiveEmailAgent. |
| RequestFilterAgent | This agent proxies requests to another request agent and in the process, it caches the props for each request. When this agent starts up, it grabs a reference to the RequestAgent that its requests are proxying to from the ServiceManager, then registers itself. Cached requests are filtered depending on the filter_interval property and the requests that made it through the filter are emailed to the list of email addresses provided by the recipients property. Note: It may be a bad idea for this agent to proxy AgentRequests that may contain references to resources that needs to be released. The props from AgentRequests are not released for garbage collection until the filtering has been done. |
| SendEmailAgent |
This agent queues up email messages and sends them to the smtp_host at regular intervals. There are a variety of properties that can be configured which define how and when these messages are sent. This agent implements the SendEmailInterface and registers with the Service Manager for other agents to use. The SendEmailAgent supports the following properties:
|
| HTTPAuthenticationAgent | This agent is used by the WebServer to handle authorization of password protected resources. The authentication file defines the realms and the usernames and passwords which are used to authenticate clients to the paths associated with each realm. The authentication file is delimited by newlines and must end with a newline. Each realm is declared with a PATH and the REALM name separated by spaces, followed by usernames and passwords on new lines, separated by a space. PATHs must begin with a slash and end with a slash. The HOSTNAME field at the beginning of the file indicates to the HTTPAuthentication agent what hostname the realms should be mapped to. In Virtual Host (multihoming) configurations, use multiple authentication files with different HOSTNAME values for each file. The default hostname is default. Here is an example authentication file:HOSTNAME PATH0 REALM0 username0 password0 username1 password1 username2 password2 username3 password3 PATH1 REALM2 username0 password0 username1 password1 The following example shows an example of an authentication file with two realms, 'My realm' and 'Main Realm'. If any access is made to files or directories in /private/, this agent will ask for the username jonlin with the password mainpassword, except for accesses to /private/mine/, which is under the /private/ path but is its own realm and requires its own usernames and passwords. If default is used as the hostname then the authentication map will apply to all virtual hosts on this server. default /private/mine/ My realm john johnpassword santos halper /private/ Main Realm john mainpasswordThis agent supports the following Props settings:
|
| HTTPFileServerAgent |
This agent is used by the WebServer and SecureWebServer to handle requests for files from the file system. If the file is an ASP.NET file, it will be executed using the ASP.NET environment on the server and the output will be sent to the requestor. If the ASP.NET code references other assemblies or .dlls, include copies of these .dlls in the same folder as your ASP.NET file. The HTTPFileServerAgent supports the following Props:
For virtual hosts (serving different websites with unique domain names a.k.a. multihoming), start multiple HTTPFileServerAgent instances and give each one unique service_name and html_directory prop values. Include the domain name (or the protocol, http:// or https://) with the URI in the agent's service_name. Here are some examples of valid service_names:
http://www.server.org/
http://www.server.org:8080/
https://www.server.org/
www.server.org/
www.server.org:8080/
/
|
| HTTPProxyAgent |
HTTPProxyAgent handles proxies to other web servers. It can provide complete http proxy services to browsers and other clients connecting on the addresses and ports specified in the listeners property, and it can proxy specific URLs from the http.proxy file while the WebServer handles other requests normally. The http.proxy file lists full URLs or URIs to proxy and where they should be proxied to if the WebServer is running. It consists of name/value pairs separated by newlines. Lines beginning with the # character are ignored as comments. The value of each name/value pair must be a complete URL. Here are some valid name/value pairs that might be used in the http.proxy file: http://myserver/proxy_me=http://proxy:1099 http://myserver/proxy_me2=http://proxy1:9000 http://myserver/proxy_me2=http://proxy2:9000 http://myserver/proxy_me2=http://proxy3:9000When a browser requests /proxy_me, the HTTPProxyAgent contacts the web server at proxy on port 1099 and proxies the request to that server. When a browser requests /proxy_me_too, the HTTPProxyAgent cycles through the 3 web servers indicated, so that the first time the URL is accessed, the connection is proxied to proxy1:9000. The second time, the request is proxied to proxy2:9000, the third request goes to proxy3:9000, the fourth request goes to proxy1:9000, and so on. Both the name and the value of each name/value pair are assumed to be literal, so they will only match the exact path/hostname of the http request. The servers listed in the http.proxy file are periodically checked to ensure that they are up and responding. The HTTPProxyAgent will not proxy requests to hosts from the http.proxy file that aren't responding. HTTPProxyAgent also supports listeners, which operate independently of the WebServer to proxy traffic for browsers configured to use a proxy server. Any number of listeners can be started to provide proxy services on specific ports or IPs. Listeners are specified using the listeners prop of the HTTPProxyAgent. This agent supports the following Props entries:
|
| HTTPPutAgent | This agent can be loaded to support traditional HTTP Put functionality, saving uploaded files to the directory specified in the html_directory prop. To run this agent, the WebServer must have a prop called http_put.agent that matches the HTTPPutAgent's service_name.
|
| HTTPRedirectAgent |
This Request Agent is used by the WebServer to determine whether a web request should be redirected and to actually redirect the request by returning the proper redirect code to the client. If an HTTPRedirectAgent is running and the WebServer's redirect_agent prop is the same as the HTTPRedirectAgent's service_name, the agent will redirect requests for URLs in the http.redirect file. This file lists where to redirect to; URIs with multiple redirects listed in the file will be cycled between the listed redirects, providing a round-robin load distribution scheme. The file format is name/value pairs delimited by newlines; lines starting with '#' are ignored. Complete URLs must be used to specify redirected URLs and the redirect targets. Here is an example of a redirect file: http://myserver/redir1/file.htm=http://yahoo.com/ http://myserver/redir2/=http://redirect1:9000/ http://myserver/redir2/==http://redirect2:9000/ http://myserver/redir2/==http://redirect3:9000/When a browser requests /redir1/file.html, it is redirected to http://yahoo.com. When it requests /redir2, it is redirected to http://redirect1:9000/. The next request for /redir2 is redirected to http://redirect2:9000/. The third incoming request is redirected to http://redirect3:9000/. The fourth request is redirected to http://redirect1:9000/, and the cycle is started again. In this way, the HTTPRedirectAgent can be used for round-robin style load balancing. There are 2 kinds of name/value pairs used in the redirect configuration file. The first is a direct mapping in the format NAME=VALUE. This mapping tells the redirect agent to redirect PATH NAME to PATH VALUE. A directly mapped NAME that contains a hostname must have a host in its VALUE. A direct mapping will not recurse subdirectories in a path and each path is regarded as literal. Directly mapped names can by mapped to multiple values if the values are separated by commas. The agent will cycle through each of the different paths given as the value. The second kind of mapping maps only hosts to hosts, and passes the requested URL along with the redirected request for the mapped host to handle. This is an example of host-to-host mapping syntax: http://myhost.com>http://www.myhost.comNo path information is included in the syntax of this mapping, only the host names. Any path intended for myhost.com will be mapped to the host www.myhost.com. Note: Cyclical references in the redirect mappings are not checked, if the redirect file has cyclical references, clients can be put into an infinite loop of redirects.
|
| SecureWebServer | SecureWebServer extends WebServer with SSL security features. You must provide a certificate suitable for server authentication, and any passwords or key files needed to access the certificate. SSL3 and TLS3 are the only supported protocols. This agent supports the following Props entries:
|
| WebServer |
The Neokernel web server services http requests. If an incoming request is for a static file like an HTML file, the web server delivers it. If the request URI ends in .agent, the web server uses a custom C# or Visual Basic object to generate the response. Objects that generate responses in this way implement the RequestAgent interface. If the server can't find a file or a RequestAgent to match the client's request, a 404 (file not found) error is returned. Typically, an HTTPFileServerAgent is used to serve static files like images or HTML. The HTTPFileServerAgent also handles ASP.NET pages if the file ends with the .aspx extension. Custom RequestAgents are commonly used in conjunction with the WebServer and SecureWebServer classes to handle HTTP requests dynamically. Here's an example of a simple RequestAgent written in Visual Basic: Imports com.neokernel.nk
Imports com.neokernel.util
Public Class SimpleVBPage
Inherits RequestAgent
Overrides Sub handleRequest(ByVal Request As AgentRequest)
Dim title, body As String
body = getString("body")
Request.println(body)
End Sub
Overrides Sub initProps()
setDefault("service_name", "/simple.agent")
setDefault("body", "This is output from the SimplePage agent!")
End Sub
End Class
If a browser requests http://localhost/simple.agent from a server that has started the above SimpleAgent, the browser will display the text This is output from the SimplePage agent! Here is the exact same agent written using C#: using System;
using com.neokernel.nk;
public class SimplePage : RequestAgent
{
public override void initProps()
{
setDefault("service_name", "/simple.agent");
setDefault("body", "This is output from the SimplePage agent!");
}
public override void handleRequest(HTTPAgentRequest request)
{
String body = getString("body");
request.println( body );
}
}
WebServer supports the following Props entries:
|
| FileLoggerAgent | This agent handles logging. Currently, the only method of logging available is to a file. A logging requests are sent to this agent via the log(String) method and the agent will synchronize and log it to the file. Because logging is synchronized, applications that need to be optimized for speed will want to minimize their logging output. FileLoggerAgent supports the following Props entries:
|
| FileReporter | This agent implements IReporterInterface so it can capture output generated by the kernel. If you start this agent, all Kernel output will be routed to log files instead of the standard output console. It extends FileLoggerAgent in order to log agent output to sequentially named text files. Upon loading, this agent replaces the default Reporter so kernel output is logged instead of showing up in the console. The supported Props are:
|
| Agent | This abstract implementation of the AgentInterface provides the base class for all components in the Neokernel. There is built-in support for routing agent output to Neokernel output and error streams, and masking output using hide_println, hide_debug, and hide_warningProps. This implementation of AgentInterface recognizes the following Props entries:
|
| AgentReplicator | Used to create multiple instances of the same kind of Agent.
|
| RequestAgent |
A RequestAgent is a ServiceAgent that implements RequestAgentInterface. Create agents that extend this class to inherit the basic functionality for registering them with the ServiceManager at startup and making it available to other agents as a request based service. RequestAgents are commonly used in conjunction with the WebServer and SecureWebServer classes to respond to HTTP requests. Here's an example of a simple RequestAgent written in Visual Basic: Imports com.neokernel.nk
Imports com.neokernel.util
Public Class SimpleVBPage
Inherits RequestAgent
Overrides Sub handleRequest(ByVal Request As AgentRequest)
Dim title, body As String
body = getString("body")
Request.println(body)
End Sub
Overrides Sub initProps()
setDefault("service_name", "/simple.agent")
setDefault("body", "This is output from the SimplePage agent!")
End Sub
End Class
If a browser requests http://localhost/simple.agent from a server that has started the above SimpleAgent, the browser will display the text This is output from the SimplePage agent! Here is the exact same agent written using C#: using System;
using com.neokernel.nk;
public class SimplePage : RequestAgent
{
public override void initProps()
{
setDefault("service_name", "/simple.agent");
setDefault("body", "This is output from the SimplePage agent!");
}
public override void handleRequest(HTTPAgentRequest request)
{
String body = getString("body");
request.println( body );
}
}
|
| ScheduledAgent |
Abstract implementation of a scheduled agent, or an ISchedulable agent that wakes up periodically at the dates and times specified by it's schedule prop. This agent implements ISchedulable; it creates and uses a Schedule using the value of it's schedule prop to initialize the Schedule. The schedule prop must be a valid Schedule string, for instance: starting 10/31/2003 every 2h until 10/20/2004 starting 10/31/2003 between 10:00:00 and 11:00:00 every 20s until 12/01/2003 between 0:0:0 and 23:59:59 every 5mSceduledAgents all have the following prop:
|
| Scheduler | This is a ServiceAgent that implements the IScheduler interface. It maintains a pool of threads that periodically wake up any ISchedulables that have been scheduled. Look at ISchedule and Schedule to learn about supported scheduling features. |
| ServiceAgent | Abstract agent that automatically registers with the ServiceManager using the service name specified in it's service_name prop.
|
| ServiceManager | The default implementation of ServiceManagerInterface. Agents use the ServiceManager to obtain references to other Agents and to register so that other Agents can access them. Agents register with the ServiceManager using a String to identify themselves; other Agents use that string to request a reference from the ServiceManager. |
| AgentServer | A server interface to the neokernel. |
| FileObjectManager |
The FileObjectManager manages Props objects and stores them as files in the specified directory using FilePropsContainers. The FilePropsContainer keeps the file on the hard disk in sync with its corresponding Props in memory. To get a Props that is managed by the FileObjectManager, call createObject. The only ObjectType supported by this IObjectManager implementation is the PropsType; using other types will fail. Props objects can be retrieved by calling getObject with the ObjectID for the desired Props. ObjectIDs can be created from Props like this: new ObjectID(props.getString("type"),props.getString("id")); You can list all or a subset of the Props by calling listObjects. The object passed as an argument will be used as a queryObject. If the queryObject is null (Nothing in Visual Basic), all ObjectIDs in this IObjectManager will be listed. If the queryObject is of type ObjectType, all ObjectIDs with the specified type will be returned. If queryObject is a Pair, an ObjectID will be returned for a Props that includes a prop name matching the string First and a prop value matching to the string Pair.second(). Props objects are removed by calling removeObject with the ObjectID of the object to be removed.
The Props objects stored in the FileObjectManager are cached in a Hashtable called allprops using their ObjectIDs as keys. The id prop of each Props is appended to its filename on disk, i.e. prop001 is the filename of the Prop with an id of 1. |
| ObjectManager | This is a reference implementation of a non-persistent IObjectManager implemented as an agent. Normal operations are reported through debug for educational purposes. If you are using it in production, set the hide_debug prop to true for significantly faster performance. |
| SessionManager | This agent is the reference implementation of the SessionManagerInterface. |
| SessionReaper |
The SessionReaper is a ScheduledAgent that periodically checks for expired sessions created by the SessionManager. Although this agent has no direct interactions with the SessionManager, it knows that session information stored in an IObjectManager is tagged with a prop called timestamp. Any session Props that has a timestamp value greater than the SessionReaper's session_timeout_ms prop is removed from the ObjectManager. The SessionReaper checks for expired objects using the schedule, ObjectManager service, and session object type specified by it's Props. This agent supports the following Props entries:
|
| PropsListAgent | This agent creates and registers a PropsList to the service manager. It can be extended to provide alternate storage layers, or used externally with associated Import and Export agents. |
| PropsListIteratorAgent | This agent can be extended to iterate over a PropsList passing each Props value to the handleRequest method when the agent is started, or it's iterate method is called. |
| XMLPropsList |
XMLPropsList is an agent that provides persistent storage of Props in XML format. It includes methods for loading Props from an XML file, writing Props to an XML file, and parsing streams of XML data to obtain additional props. XMLPropsList supports the following Props entries:
|
| XMLRequestAgent | This is an abstract implementation of RequestAgent with convenience methods for producing streamed XML-based responses of indeterminate length. |
Namespace: com.neokernel.nk
Assembly: Neokernel (in Neokernel.exe)
AgentInterface Members | com.neokernel.nk Namespace