The International RuleML Symposium on Rule Interchange and Applications

Orlando, Florida: October 30-31, 2008

Rule Responder:
RuleML-2008 Architecture


Architecture Diagram:


Click on image to enlarge it.

      Rule Responder's architecture is implemented by the use of personal agents, organizational agents, communication middleware and external agents. The rule-based personal agents represent different members of the RuleML-2008 Organizing Committee. These agents are implemented by a rule engine, which acts as an inference and execution environment for the rule-based decision and behavioral logic of the semi-autonomous agents. The organizational agents constitute an intelligent filtering and dispatching system, using a rule engine execution environment, for blocking incoming queries or delegating them to other agents. The communication middleware implements an Enterprise Service Bus (ESB) supporting various transmission protocols (e.g., JMS, HTTP, SOAP). The ESB implementation for Rule Responder is Mule, an efficient open source communication middleware. External agents can interact with the Rule Responder-enabled virtual organization via its public communication interface (e.g., an HTTP endpoint interface of an organizational agent as single point of entry).

      The personal agents used by Rule Responder contain FOAF-extending profiles for each person of the organizational team. Beyond FOAF-like facts, person-centric rules are used. All clauses (facts and rules) are serialized in Naf Hornlog RuleML, the RuleML sublanguage for Horn logic (allowing complex terms) enriched by Naf (Negation as failure). These FOAF-extending profiles have access to RDF (BibTeX, vCard, iCard, Dublin Core) and RDFS/OWL (role and responsibility models). The following is a query that a personal agent can be expected to answer: "What is the best (fastest response time) method to contact a committee member?" For answering it, the corresponding personal agent's FOAF profile must be queried to find the most convenient contact method.

      The organizational agent contains a rule set that describes the organization. The following is a query that an organizational agent can be expected to answer: "Who should be contacted about the symposium’s panel discussion?" When this incoming query is received by the organizational agent, the agent must first determine who the correct contact person is for the panel discussion. When the contact person has been confirmed, the organizational agent sends a subquery to that committee member's personal agent. The personal agent could then respond with a contact method (e.g., email or telephone number, depending on contact preferences in their FOAF profile). Alternatively, if that contact person was on vacation or currently busy, then the personal agent would respond back to the organizational agent that the contact person is unavailable. If the first-line contact person cannot be reached, then the organizational agent will use the responsibility matrix (i.e., which committee members are responsible for certain tasks, and what members can fill their role of if they are unavailable) to try to contact the next personal agent.

     External agents can communicate with the virtual organization by sending messages that transport queries, answers, or complete rule sets to the public interface of the organizational agent (e.g., an HTTP port to which post and get requests can be sent from a Web form). The standard protocol for intra-transport of Reaction RuleML messages between Rule Responder agents is JMS. HTTP SOAP is used for communication with external agents, such as Web services or HTTP clients (Web browsers).