<Rel use="value" uri="cbe:creationTime"/>

![0_image_0.png](0_image_0.png)

<Ind type="owlTime:Year">2007</Ind> <Ind type="owlTime:Mont">6</Ind>
...

</Atom>
...

<Atom>
<oid>
<Ind type="cbe:CommonBaseEvent">i000000</Ind>
</oid> <Rel use="value" uri="cbe:msg"/> <Ind type="xsd:String">Hello World</Ind>
</Atom>
</And>
</content>
</Message>
The **RuleML Interface Description Language** (RuleML
IDL), as a sublanguage of Reaction RuleML, adopts ideas of interface definition languages such as CORBA's IDL or Web Services' WSDL. It describes the signature of public rule functions together with their mode and type declarations, e.g. the public rule heads which can be queried in backward-reasoning style or monitored and matched with patterns in forward reasoning style.

Modes are instantiation patterns of predicates described by mode declarations, i.e. declarations of the intended input-output constellations of the predicate terms with the following semantics:
- "+" The term is intended to be input
- "−" The term is intended to be output - "?" The term is arbitrary (input or output)
We define modes with an optional attribute @*mode* which is added to terms in addition to the @*type* attribute. By default the mode is arbitrary "?". An interface description is represented by the function interface(*QueryLiteral, Description*), where QueryLiteral is the signature of the publicly accessible literal.

Thus, the interface definition for the function add(Result, Arg1, Arg2) with the modes add(−, +, +) is as follows:
Example

## <Atom> <Rel>Interface</Rel>

<Expr>
<Fun>add</Fun> <Var type="java:java.lang.Integer" mode="-">Result</Var>
<Var type="java:java.lang.Integer" mode="+">Arg1</Var>
<Var type="java:java.lang.Integer" mode="+">Arg2</Var>
<Expr> <Ind>Definition of the add function which takes two Java integer values as input and returns the Integer result value</Ind>
</Atom>

## 7. Rule-Based Cep Middleware In This Section We Will Implement The Main Components Of The

rule-based middleware which makes use of the homogenous reaction rule language. As in a model driven architecture (MDA) the middleware distinguishes:
- a platform specific model (PSM) which encodes the rule statements in the language of a specific execution environment
- a platform independent model (PIM) which represents the rules in a common (standardized) interchange format (e.g. a markup language)
- a computational independent model (CIM) with rules in a natural or visual language.

We focus on the technical aspects of the middleware and on the machine-to-machine communication between automated rule inference services deployed on the middleware. The homogenous reaction rule language is used on the PSM layer and RuleML/Reaction RuleML on the PIM layer. For an visual RuleML/Reaction RuleML
editor on the CIM layer see [15]. Figure 2 illustrates the architecture of the middleware.

Several rule engines (e.g. Prova [7] or other rule execution environments) might be deployed as distributed web-based services. Each service dynamically imports or pre-compiles and loads the distributed rule bases (RuleML scripts published on the web or stored locally) which implement the decision and reaction logic. External data from data sources such as Web resources or relational databases and external enterprise application tools, web services and object representations can be directly integrated during runtime or by translation during compile time by the expressive homogenous and heterogenous integration interfaces of the rule engine or via publish-subscribe and monitoring processes using the ESB and event messages. The ESB is used as object broker for the web-based inference services and as asynchronous messaging middleware between the services. Different transport protocols such as JMS, HTTP or SOAP (or Rest)
can be used to transport rule sets, queries and answers as payload of event messages between the internal inference services deployed on the ESB endpoints or external systems and applications. RuleML/Reaction RuleML is used as common rule interchange format between the services.

## 7.1 Enterprise Service Bus As Communication Middleware

Our middleware is based on the Mule open-source ESB [10] in order to handle message-based interactions between the deployed rule-based services and with other external applications, tools and services using disparate complex event processing (CEP) technologies, transports and protocols. The ESB allows to deploy the rule engines as highly distributable rule inference services installed as Web-based endpoints on the Mule object broker and supports the Reaction RuleML based communication between them. That is, the ESB provides a highly scalable and flexible application messaging framework to communicate synchronously but also asynchronously with external and internal services.

Mule is a messaging platform based on ideas from ESB architectures, but goes beyond the typical definition of an ESB as a transit system for carrying data between applications by providing a distributable object broker to manage all sorts of service components. A transport provider enables Mule components to send and receive information over a particular protocol, repository messaging or other technology. Mule supports a great variety of transport protocols such as JMS, HTTP, SOAP, TCP. Autonomous components such as Java Beans or components from other frameworks are managed within the object broker and configured to