EP1350165A2 - Architecture de bus d'evenements - Google Patents

Architecture de bus d'evenements

Info

Publication number
EP1350165A2
EP1350165A2 EP01953583A EP01953583A EP1350165A2 EP 1350165 A2 EP1350165 A2 EP 1350165A2 EP 01953583 A EP01953583 A EP 01953583A EP 01953583 A EP01953583 A EP 01953583A EP 1350165 A2 EP1350165 A2 EP 1350165A2
Authority
EP
European Patent Office
Prior art keywords
adapter
activ
message
rules
msg
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP01953583A
Other languages
German (de)
English (en)
Inventor
Edward Jung
Tom Butcher
Sami Khoury
Sanjeev Katariya
Fajen Kyne
Rob Bearman
Steve Bush
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
OpenDesign Inc
Original Assignee
OpenDesign Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by OpenDesign Inc filed Critical OpenDesign Inc
Publication of EP1350165A2 publication Critical patent/EP1350165A2/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2805—Home Audio Video Interoperability [HAVI] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2807—Exchanging configuration information on appliance services in a home automation network
    • H04L12/2814—Exchanging control software or macros for controlling appliance services in a home automation network

Definitions

  • a problem with existing application platforms is the difficulty of writing applications for the platforms. Take for example of the Windows platform.
  • programmers worked under the constraints of DOS, hogging the full screen one application at a time, writing their own printer drivers, managing memory, dealing with TSRs - all a nasty set of problems that each vendor had to solve independently.
  • Windows made many things easy for applications writers, including shared access to the screen through window management and memory segmentation for multiple processes, a shared printer driver model and abstracted access for applications to name a couple. The benefit to the consumer was a common user experience with an abundance of applications made available by the relative ease and low cost of development compared to the DOS world.
  • Figure 1 is a block diagram illustrating the functions of the Kernel.
  • Figure 2 is a block diagram representing the five module types that together may be part of an application deployment.
  • Figure 3 is a block diagram illustrating a small configuration with the Open Design platform installed on existing servers.
  • Figure 4 is a block diagram representing a possible large deployment configuration.
  • FIG. 5 is a block diagram illustrating interactions with a deployment tool ("DT").
  • Figure 6 is a block diagram representing some of the deployment elements possible with Open Design application development.
  • Figure 7 is a block diagram illustrating communications between adapters, applications, and the Event Bus.
  • Figure 8 shows a high-level flow of control between the Network Layer, the Event Bus, the Rules Engine, and private calls between instances of the Network Layer across a network.
  • Figure 9 is a block diagram illustrating the addressing layers of an Open Design Message.
  • Figure 10 illustrates a more complete diagram that includes all of the architecture elements involved in node-to-node message exchanges between applications hosted on nodes A and B.
  • a programmable high-level network computer infrastructure on which distributed applications and services are hosted is provided.
  • the network computer infrastructure is built out of active machines connected together using existing networking technologies and protocols. These networked machines are called nodes.
  • Applications and services run on one or more nodes, and communicate by exchanging messages.
  • Applications and services are named and registered on the network. Nodes are also named and registered on the network. A single named application or service may span multiple nodes.
  • the network uses:
  • OS applications are applications written to run on a specific OS and hardware platform. Examples of these applications are traditional desktop applications such as Word, or server applications such as an Apache Web server.)
  • Methoda- applications are rules-based applications, also called modules.
  • Messages may contain platform-supplied instructions, a payload, and destination addresses
  • Application communication supports several message patterns, which include request/response, one-way sends, or may be built up of combinations of requests and responses between multiple elements of the network or multiple exchanges with any one element of the network
  • Each node supports a routing processor infrastructure - router - which forms a platform for routing messages, evaluated according to meta-application, and routed to other nodes, or to a node local application processor
  • Applications and meta-applications may be composed of services exposed by other meta-applications.
  • the Application Network Router a specialized high scale message router, is an element of the computer infrastructure or platform. It may run on each node and may be capable of passing events to one or multiple end points, intra, or inter machines/nodes with control of quality of service delivery and content.
  • the quality of service provides for controlling the duplex channel, authenticating communicating entity identities, distributing messages appropriately to distributed services based on system and application provided criteria, applying application and platform policy, and securing the content of messages.
  • the message passing fabric is capable of emulating concepts of unicast (single destination) and multicast (multi- destination) messaging. Plug in logical modules are associated with inbound or outbound messages (This programmable routing may not be XML routing. XML routing and messaging middleware route on the basis of messages and subjects.
  • the routing may be a fixed function and not programmable.
  • Messages are sent between connection points called ports. Ports can be unicast or multicast end points.
  • the router controls inbound, outbound, and forwarded traffic by applying these modules in stages based on the direction of message flow, in-bound or out-bound.
  • Modules types may be of many types. The common module types include, but are not limited to, routing, performance control based (performance metric based), configuration based, security policy, application policy, and proxy (specialized message forwarding).
  • the network uses rules bundled together into 'modules' and an inference engine to program the router. These elements may be part of the Kernel.
  • the network uses an XML-based rule language for application and system logic that controls (or programs the router for) message forwarding, message instruction parsing, and message delivery.
  • Figure 1 is a block diagram illustrating the functions of the Kernel. Use of rules allows the providing of two core values based on rules based router programmability:
  • Open Design Applications run (potentially) everywhere - under Windows, on Unix, under Macintosh, on Palm Pilots, on Internet-ready phone, and are distributed/distributable at runtime.
  • the Open Design system can host and manage applications and services on a network.
  • the system is built of a network of connected nodes that run a set of core infrastructure services. Services, under a single name may span multiple nodes.
  • the services can expand and contract to make best use of network bandwidth, connection, and node resources under the policy control specified for the nodes and the application within an administrative domain.
  • the applications, and the policy associated with the applications are distributed in concert, so policies established for the application may remain in effect regardless of the topologies or resources applied to hosting the service. Both the policies and application or service logic is expressed in an Open Design Rules language, and processed by the Open Design distributed platform.
  • the Open Design platform can be described as using the "distributed management” approach to control hardware resources and the “runtime or loosely-coupled approach” to hardware-software integration.
  • a software programmer does not need to know details of the network architecture to write a program.
  • a programmer can map their software concepts like user names to network concepts like filters, IP addresses, and port numbers.
  • a hardware designer does not have to worry about mapping their features to application objects.
  • a designer can map MPLS tags to user priority levels. Currently, each mapping needs to be redone when changes occur in the software or hardware.
  • a system without these features is likely to be fragile because frequent centrally managed changes to the application are needed, which destabilizes the application. It is also likely to be unattractive to partners since the cost and risk of co-deployment and centrally managed applications is higher.
  • the most successful example of this kind of system is the Internet for data networking.
  • the disadvantages are that distributed systems are more complex, and runtimes are a distribution and reliability dependency (i.e., the runtime has to be everywhere your application is, and has to be at least as stable as your application).
  • the points of control provided by the Open Design platform for control and management of distributed applications on the network are derived from the same as the set of module classes enumerated above - that is: routing, performance (performance metric based), configuration (node, or system policy based), security policy, applications, application policy, and proxy (specialized message forwarding.)
  • the Open Design platform provides a consistent mechanism, and language, and multi-platform runtime with which to control, extract, route, and process data, as messages, on the network.
  • FIG. 2 is a block diagram representing the five module types that together may be part of an application deployment. Each module type, and its attendant benefits are described in the following sections.
  • the application adapter, its features and interfaces are described in the Router Architecture section. Sample code for each of the rule types described below: routing, network configuration, security, application integration, and user profiling are provided in the Event Bus section of this document.
  • the Open Design System provides application naming services and infrastructure to allow applications to specify the name of their service, the basis by which application request messages are routed throughout the network. Routing updates may be required when policy or network management rules cause service partitioning and/or replication.
  • the Open Design infrastructure provides automatic routing updates, service names and associated routing data, to all nodes within the network that require the update.
  • a single program for a directory service namespace can:
  • This type of module is called a routelet.
  • the Open Design platform is built up of a set of connected nodes, each with the Open Design rules based programmable router.
  • the nodes run routing algorithms that move programs, data, connections, and session state. These routing and distribution rules (described above) are supplied by administrators, application developers, and system management developers. The logic in these rules can effect not only application and message distribution and routing, but also to the selection of network peers, and responses to connection or request overload. These rules, such as response to load, connection requests, CPU or disk full responses, are called network management modules.
  • the Open Design System provides OS and system event messages against which network management modules may be written.
  • the Open Design System provides a platform by which application and system supplied routing criteria can be used to tailor routing and service distribution to make best use of hardware and communication resources.
  • the Open Design System provides mechanisms by which policy for access to any part of the platform and service may be controlled.
  • Rules to access services, OS, or node facilities may be written to include directives that disallow or restrict access to specified modules, users, domains, adapters, etc. These policy expressions evaluated at the destination, as one stage of rules processing, before activation occurs. The activation of the rule is not invoked if the policy expression fails.
  • Policy rules are expressions that appear on the LHS ("left hand side") of any of the other rule types.
  • the Open Design applications are modules. Modules invoke the name registration mechanism, and provide the message matching for events on the event bus of Open Design services. This means that modules are effectively the actual implementation of any service hosted by the Open Design platform.
  • the service logic to either directly handle a request message or forward it to an OS-application are expressed as the activation, or RHS of a rule.
  • Servicelet is the name used to indicate that the logic of the service is entirely expressed as rules.
  • a proxy module is one that forwards requests to adapters to invoke the appropriate logic to handle a request.
  • profiling data available to the rules engine provide interesting and controversial business opportunity.
  • Use of a rules engine as the mechanism for programming the router makes this opportunity possible.
  • the kinds of profiling data available to a rules application may include user, application, node, message source, message destination, etc. Each of these data types, in combination with rules to respond to patterns that are developed by the data, represent interesting technical and business opportunities.
  • Open Design Platform for user profiling makes available to Open Design Applications the event history and user profile of the consumer. No new OS Applications need to be written to make this a compelling environment.
  • the user's browser activity alone provides a richness of interactions. The user could benefit if their interaction with the browser resulted in an implicit user profile. Items the user buys, sites the user visits, the number of times the user causes an operation to occur - all of these actions stored and analyzed under the privacy of the user's machine can make for a much more customized, personalized experience when browsing the web. This combined with the contributions of user actions under other OS Applications, you get an even richer, more detailed version of who the user is.
  • the Open Design Platform leverages these existing OS Applications rather than needing new OS Applications to be written.
  • the Open Design platform provides is a mechanism by which OS Application-specific events and user actions are converted to a higher-level, abstracted Open Design event stream that can be analyzed and compiled into a rich user profile. As the profile grows in detail, rules can then be applied to cause new semantic actions to occur.
  • the Open Design platform may be installed in both small and large deployments, using existing hardware resources, or with the addition of specialized configurations of nodes.
  • Node configurations may include hosting, proxy, router, storage, and management.
  • Figure 3 is a block diagram illustrating a small configuration with the Open Design platform installed on existing servers.
  • FIG. 4 is a block diagram representing a possible large deployment configuration.
  • DMF Distributed Management Framework
  • Open Design Applications are, for the most part, expressed in rules which may be chunks of XML in a specific format.
  • the rules are managed by the Open Design Platform in a repository on the client machine, and are triggered in response to the abstracted events in the Open Design event stream.
  • the Open Design Platform constructs a ticket that represents the transient state of the sets of rules it comprises.
  • Rules are chunks of text. They are relatively easy to read, easy to edit, and easy to put together. Because they are XML, they are also very extensible along many axes. There is no compilation involved, no binaries to build. A set of like-minded rules, a module, forms a logical application under the Open Design Platform. There may be no compiled code to create or run an Open Design application or service.
  • the modules that represent Open Design Applications contain declarative structures that define their UI, including DHTML for insertion in web pages, instructions for overriding the behavior of existing web pages, commands for controlling existing scriptable applications, policy, configuration, management and routing rules.
  • an application writer can provide customized UI, new application logic, or an adapter to an existing third-party legacy application.
  • the code may be delivered in binary format for a particular OS platform to complement interactions with existing OS Applications.
  • FIG. 5 is a block diagram illustrating interactions with a deployment tool ("DT").
  • Figure 6 is a block diagram representing some of the deployment elements possible with Open Design application development. Not all applications require all elements, but the ability to not only provide application logic, but also add routing, policy, and fine grain distribution control to an application enable the deployment of rich, highly capable, available, and reliable applications and services in a distributed environment. 2.0 Router Architecture
  • Elements of the Open Design architecture may include:
  • Adapters are the elements that translate raw application events to a standard form understood by the Open Design platform. They also translate activations into application specific commands or messages.
  • the Event Bus captures Open Desig ⁇ i-formatted messages as they are generated through application adapters.
  • the Event Bus processes commands fired from rules and routes them to application adapters.
  • the Rules Engine processes rules based on events and the data (or facts) in the Rete network and causes either new facts to be asserted into the Rete network, or actions, through adapter-specific activations, to occur based on those events.
  • the Rules Repository contains the set of rule bundles or modules configured on a node.
  • the module types are: default and site configuration modules, routing modules, and application modules.
  • the Local Storage is an area of working memory accessible to modules to store session or persistent data.
  • the Modules are the logic interpreted by the Rules Engine to control the router. Modules reside in the Rules Repository
  • Figure 7 is a block diagram illustrating communications between adapters, applications, and the Event Bus.
  • OS applications spawn raw events unique and specific to that application, and each application may support a specific set of commands.
  • the Open Design adapter object provides a means for abstracting those events and commands for general use.
  • An adapter is an object that enables procedural code to talk to the Open Design Event Bus (and indirectly to the Open Design Rules Engine). Through the adapter, an application can issues messages (events) to the Open Design platform for processing.
  • the adapter has knowledge of its corresponding OS application, and also has understanding of Open Design platform structures and schemas. Therefore, it can bridge the gap between OS application events and Open Design abstracted events.
  • Adapters can be written in a couple of different ways. First, they can be incorporated directly into an OS application, the adapter code written as part of the application mainline code. In this case, the OS application writer knows about the Open Design platform during the design and implementation of the application and builds this translation layer directly into the code.
  • adapters can be written for existing OS applications through whatever extensibility mechanisms the application provides.
  • an application might provide an automation interface from which events can be detected.
  • the application's window can be subclassed or hooked to obtain raw events.
  • a programmer can write a Browser Helper Object in order to tap into the DHTML DOM to watch for raw events of interest.
  • adapters Just as adapters convert raw events to an abstracted Open Design message, adapters also convert Open Design activations into application-specific commands or messages for processing. This allows the Open Design platform to make calls on applications through a generalized command interface. These activations are issued in response to rules being fired, with the activations written by rules authors who understand the capabilities and activation schema of the target OS application.
  • the set of events and commands the Open Design platform can manage is infinite in size.
  • the Open Design platform does not specifically understand the semantics behind a particular event or command. Rather, it provides the transport mechanism to move that event or activation between an adapter and the Open Design Rules Engine.
  • the adapter writer defines the event schema and activation schema particular to an OS application, and the knowledge is shared with the rule author.
  • the platform allows the transport of events and activations between the Rules Engine and adapters. Rule authors understand the capabilities of the particular adapters they are targeting. They understand what events the adapter can issue, and what activations it can accept. The rule author builds rules that act on these events and issue activations based on the command sets of adapters. The rule author typically knows about these schema through the documentation shipped with each adapter.
  • the adapter defines that schema.
  • the schema is particular to the adapter, the overall schema of the platform is extensible. Only the endpoints (adapters and rules) need to understand the schema.
  • adapter denotes a piece of code connected to the message bus.
  • An adapter may take many forms: web pages can include an adapter as part of their scripts, a Visual Basic application can implement adapter code directly, ASP pages can include adapters, and so on. The important point is that the adapter is the piece of code that allows messages to be issued to the message bus. Messages can also be routed back to the adapter by the kernel. 3.1 Adapter reguirements
  • Adapters may only adhere to a small set of requirements.
  • An adapter that connects to the message bus has an ID. This ID is represented as a GUID string.
  • Each distinct class of adapter has a unique GUID. Internally, this GUID ('id') is used to route messages to adapters. The set of actions that an adapter can carry out in response to a message is specific to a particular adapter class.
  • the adapter In order for the kernel to route messages to an adapter, the adapter provides an object model on which the kernel can dispatch messages. Messages processed by an adapter are method calls on the adapter's object model. This object model, however, need not be provided when the adapter only issues messages.
  • the programming model used to develop an adapter may be left to the choice of the adapter writer.
  • Any programming language that supports the use of COM objects on Win32 can be used to write an adapter. This includes traditional programming languages like C/C++, Java, and Visual Basic, macro languages like Visual Basic for Applications, and script languages like PERL, JavaScript, and VBScript.
  • ⁇ adapter new ActiveXObj ect ("odi .AdptProx”) ; adapter.Register(" ⁇ CD24FC5C-5C36-4b9d-B098-F41F0227CCEE ⁇ ",
  • This adapter creates itself whenever the HTML browser displays the page and registers with the message bus. Also, when the browser unloads the document, the adapter unregisters itself and goes away.
  • the first step to create an adapter is to create an instance of the adapter proxy object. This is the object that 'sits between' the kernel and the adapter code itself.
  • the adapter registers itself with the kernel. This is accomplished through the Register() call on the adapter proxy object. There are four parameters to Register(); the last two parameters are optional. This code snippet chose to omit the last two parameters: adapter.Register(" ⁇ CD24FC5C-SC36-4b9d-B098-F41F0227CCEE ⁇ ",
  • the first parameter is a well-formed GUID that uniquely identifies this class of adapter. Developers should use the guidgen.exe utility to create unique adapter GUIDs. This parameter will be used in the kernel to identify messages that are generated by the adapter as well as to route messages back to the adapter.
  • the second parameter to Register is a friendly human-readable name for the adapter. This parameter is used for convenience and can be null.
  • the adapter has connected to the kernel. At this point, the adapter is ready to issue messages and to receive incoming messages.
  • an adapter Whenever an adapter wishes to disconnect from the kernel, it calls Unregister. There are no parameters to Unregister, but the adapter may call Unregister before being destroyed to avoid memory leaks that will not be cleaned up until the host processes exits.
  • Register If an adapter is already connected to the kernel and attempts to call Register again, Register returns an error. It is invalid to change an adapter's ID, name, activation interface, or Running Object Table ("ROT") behavior while the adapter is registered. The adapter may Unregister itself before calling Register a second time.
  • ROT Running Object Table
  • the kernel has a built-in mechanism that allows adapters to be registered even when the kernel is not running.
  • the fourth parameter to Register is a Boolean value that enables this feature when set to true. If this parameter is omitted, it defaults to true.
  • the Running Object Table is used to register adapters; this can be used by programs to "see" what objects are running.
  • the kernel looks at this table for any adapters that might need to be registered. If it finds any, the kernel attempts to connect to the adapters so they can send and respond to messages.
  • the fourth parameter to Register is true, an entry is placed for the adapter on the Running Object Table. If the parameter is omitted or set to false, no entry is placed on the ROT for the adapter.
  • adapters specify that they wish to allow deferred connections by the kernel, it is possible for the adapter to register when the kernel is not running. Whenever the kernel starts, it looks for adapters that allow deferred connections and connect the adapters at that time. The adapter writer can sink the onConnect and onDisconnect events that the kernel generates. When the adapter calls Unregister, the kernel no longer attempts to connect to the adapter if its process is created.
  • the following table shows the return values from the adapter proxy as well as the state of the adapter as it pertains to the kernel.
  • Adapters issue messages by invoking another method on the proxy object called SendMessage.
  • the following JavaScript executed in the context of our hypothetical adapter HTML page issue a message of the type "hello world" with no parameters: adapter.
  • SendMessage (“hello world') ;
  • BSTR bstrType SysAllocString ("hello world'); PAdapter->SendMessage (bstrType) ; SysFreeString (bstrType) ;
  • the SendMessage returns an error.
  • MsgParams message parameter object
  • the MsgParams object is another kernel object that is used to pass parameters that are available as criteria in rules.
  • MsgParams is an array object. This is a simple function that the HTML page adapter uses to issue parameterized events: function sendParameterizedMessage (paramO, paraml, param2)
  • Adapters in the platform are logical "end-points" for messages on the event (message) bus. Messages can be addressed to adapters if they register any message listeners when they connect. The following illustrates message listeners: function sayHello ( )
  • adapter new ActiveXObject ("odi .AdptProx”) ; adapter.Register(" ⁇ CD24FC5C-SC36-4b9d-B098-F41F0227CCEE ⁇ ",
  • the kernel can append text to the page by issuing messages "addSomeText('hey there from the kernel');” or say hello by issuing "sayHelloQ”.
  • HTML pages could register the document object model as the activation interface to couple full control of the DHTML page to the message bus.
  • a Visual Basic application could expose a status bar or notification label in the form as the activation interface. Any object that is available for automation (IDispatch) in the programming environment of the developer's choice can be registered as the activation interface.
  • the kernel does not support property-get message listeners, but both property-put and methods are supported.
  • the kernel process, and therefore the event bus may be halted at any time; the adapter writer may not safely assume that the even (message) bus is available.
  • the adapter proxy object supports a property called AdapterlsConected that returns true when connected to the message bus: if (! adapter .AdapterlsConnected) alert ("oops!') ; else adapter. SendMessage ("hi !' ) ;
  • Another alternative is to use the language's error handling features to catch the error generated by SendMessage: try ⁇ adapter. SendMessage ("hi ! ' ) ; ⁇ catch (e) ⁇ if (! adapter.AdapterlsConnected)
  • the adapter writer can use whatever error handling constructs fit the requirements for a particular adapter.
  • the adapter proxy supports two events that the adapter writer can trap to receive notifications when the message bus becomes available and when it becomes unavailable. These two events are called OnConnect and OnDisconnect.
  • OnConnect is fired by the proxy whenever the message bus becomes available.
  • OnDisconnect is fired by the proxy whenever the message bus becomes unavailable.
  • the adapter writer can use these events to manage allocation of resources.
  • activation messages that are directed from the kernel to adapters are called activations. Because activations are dispatched from the kernel to adapters by way of rules firing in the rules engine, activation messages have additional information associated with them that help the adapter extend functionality in the event (message) bus. This extra information is called the activation context.
  • Adapters can use the activation context to access application data declared in module rules, data in the message that caused the activation, and information about the module that caused the activation.
  • the adapter proxy object exposes the activation context to the adapter host through a property called ActivCtx.
  • ActivCtx a property that specifies the activation context to the adapter host through a property called ActivCtx.
  • the activation context object is valid for the lifetime of the activation method call.
  • the context object is cleaned up by the JavaScript runtime. Also, if the adapter proxy is not currently processing an activation when the host calls ActivCtx, the call returns an error.
  • the adapter writer can choose to keep a reference to the activation context in memory, if required. Each activation creates a new activation context object, so if an adapter keeps a reference to an activation context in memory, the data within the cached activation context will not change as new activations are dispatched from the kernel.
  • an adapter can display the ID of the module that caused the activation: alert (myCtx . mod. guid) ;
  • alert myCtx . od. path
  • the Decls object is a standard collection, so it supports enumeration in a for.. each loop, for example:
  • the activation context also exposes all the fields of the message that were matched by a rule in the kernel to cause the activation. This allows the adapter writer to "peer" in to the event data.
  • Some adapters may exist as code integrated directly with an application. In this situation, it may be useful to programmatically determine if the kernel is the invoking caller on adapter code.
  • An adapter might be implemented as a window that does not allow the user to close it — only the kernel. If the adapter uses the same function to process this message as it does to handle the onClose event generated by user interaction, it needs to tell whether it is processing an activation message or not. To do this, the adapter code can query another property on the adapter proxy object called ProcessingActivation: function onClose ( )
  • a script host adapter may expose an activation method called SendMessage: function SendMessage (type) ⁇ adapter. SendMessage (type) ; ⁇
  • the adapter may call another method on the proxy called SendModuleMessage.
  • SendMessage type
  • SendModuleMessage type
  • Module messages "look" like other messages. The only difference is that messages issued from SendModuleMessage have the activating module's ID as the message source instead of the adapter's ID. SendMessage and SendModuleMessage have the same signature, which means that the adapter could send a module message with parameters just as it would using SendMessage for a non-module message.
  • SendModuleMessage has an optional third parameter that can be used to specify a module ID to use in the generated message. This can be useful for adapters that, say, queue activations to be processed asynchronously. When the activation is ready to be processed, the adapter can make its SendModuleMessage call with the third parameter specified:
  • channel messages allow constrained inter-module communication.
  • the constraint is that only the modules that establish the channel will be allowed to 'see' channel messages on the event bus; the adapter proxy supports a SendChannelMessage method. This method can be used by adapters to issue messages over message channels.
  • the adapter proxy supports request-response messages.
  • Request-response is a message exchange pattern in which a specific class of message is issued (MC_REQUEST) and a response is expected.
  • the kernel instruments request-response rules such that only rules that match a given request will catch responses to those requests.
  • Request messages can be issued using the SendRequestMessage adapter proxy method.
  • response messages can be issued by using the SendResponseMessage method.
  • the adapter driver is a kernel module, a rules file that routes node messages to the adapter.
  • the adapter driver is a kernel module, a rules file that routes node messages to the adapter.
  • application writers wish to communicate with adapters, they do not issue messages directly to the adapter. Instead, they issue messages according to a logical programming interface defined by the driver.
  • This call invokes the file adapter activations.
  • a driver may implement much more sophisticated routing rules.
  • Such a driver might be required for a complex adapter, such as an email queue adapter or a payment transaction adapter.
  • Drivers also allow adapters to "version" API's or even incrementally add features without changing the compiled adapter code.
  • Adapter classes are distinguished from each other by their IDs. Duplicate instances of the same adapter are distinguished from one another by a run-time registration cookie and an adapter instance ID when it connects to the kernel.
  • the kernel issues a message upon registration called "AdapterRegistered” that module writers (and adapter driver writers) use to track a particular adapter instance.
  • All adapter messages issued in the kernel are assigned a source and a source instance "cookie.”
  • the message source is either the adapter ID or the module ID (for module events), and the source-cookie is set to the registration instance value described above.
  • the kernel In the case that the kernel is activating against an adapter that has the same ID as the event source, the kernel automatically routes the activation to the instance of the adapter that issued the original message. If the kernel is activating against an adapter that is not the adapter that cause the original message, the kernel directs the activation to the first adapter registered with that particular ID.
  • the module writer can override this behavior by specifying the destination cookie as part of the activation in a rule. Because the instance cookie is not known until run-time, the module writer may determine which instance cookie to use.
  • the module can identify adapter cookies for adapters currently participating in a message exchange by caching the source cookie in a tree-node. In general, it should not be necessary for module writers to implement custom instance handling, but the feature is available for special circumstances.
  • some adapters can be loaded and unloaded from rules. This is supported through the kernel activations LoadAdapter and UnloadAdapter. In order for adapters to implement this functionality, they support the lAdapterControl interface.
  • the adapter control interface has two member methods: Startup and Shutdown.
  • the kernel loads an adapter through the LoadAdapter, it creates a new adapter control process, passing in the adapter's CLSID (guid) or ProglD as a parameter.
  • CLSID guid
  • ProglD ProglD
  • the process attempts, on Windows, to create the adapter using standard COM CoCreatelnstance calls. If this call succeeds, the process then calls lAdapterControl:: Startup on the newly created object. At this point, the adapter registers itself with the kernel. Likewise, whenever an UnloadAdapter activation is called, the kernel calls lAdapterControl:: Shutdown on the object. The process then exits. In general, it is not usually necessary to implement an adapter using lAdapterControl.
  • This section describes each method and property exposed by the adapter proxy in one embodiment. This section uses a form of the methods and properties that is taken directly from an IDL file. For non-C++, the following explanation of IDL syntax will help with the interpretation the API described below.
  • HRESULT This is familiar for C++ Windows COM developers, but not for VB or script developers.
  • VB or script a non-success HRESULT results in a run-time exception can be trapped with try/catch in JavaScript and On Error., in VB.
  • Successful calls do not throw a run-time exception.
  • Parameters that are listed here with [in] mean they are an input parameter.
  • Parameters listed with [out] denote an output parameter.
  • Some property-get methods have [out, retval] parameters. These parameters will be the return value of the call from VB or script.
  • Some parameters are listed as [optional]. This means that the parameters may be omitted from the call.
  • Other parameters list a [defaultvalue(... )].
  • lAdapter is an interface for the adapter proxy object. It supports sending message methods from an adapter. Methods
  • VARIANT vtActivationlnterface [in, optional]
  • the adapter's ID may be a GUID, formatted as a string. On Windows Guidgen.exe or uuidgen.exe may be used to create new GUIDs.
  • the second parameter is a friendly name for the adapter. This parameter is not used for addressing — only for human-readable adapter names. It may be null.
  • the third parameter is an optional activation interface for the adapter. It also may be null.
  • the activation interface may support IDispatch — VB objects and JavaScript objects both support IDispatch.
  • the last parameter is a true/false variant that describes whether or not the adapter wishes to allow deferred connections.
  • This method disconnects an adapter from the kernel.
  • This method sends a broadcast message.
  • the type of the message is the first parameter (string), and a message parameter object (see IMsgParams) may be passed as the optional second object.
  • VARIANT vtMsgParams [in, defaultvalue (-1) ]
  • This method sends a module message.
  • the type of the message is the first parameter (string), and a message parameter object may be passed as the optional second argument.
  • the last argument is the instance id of the module to target for the module message.
  • SendModuleMessage while processing an activation this parameter may be omitted.
  • the adapter proxy automatically uses the module id from the activation context in this case. If called outside of processing an activation, the instance id parameter may be specified.
  • HRESULT SendCorrelatedMessage [in] BSTR bstrType,
  • This method sends a broadcast message. This method is identical to SendMessage, only that the correlation ID of the message generated is passed back to the caller.
  • This method sends a request message.
  • the type of the message is the first parameter (string), and a message parameter object may be passed as the optional second argument.
  • VARIANT vtMsgParams [in, defaultvalue (NULL) ]
  • This method sends a response message.
  • the type of the message is the first parameter (string), and a message parameter object may be passed as the optional second argument.
  • the last argument is the response ID of the message that will be generated.
  • SendResponseMessage while processing an activation, this parameter may be omitted.
  • the adapter proxy automatically uses the correlation ID from the message in the activation context in this case. If called outside of processing an activation, the response ID parameter may be specified.
  • This method sends a channel message.
  • the instance ID of the targeted module is the first parameter.
  • the second parameter (string) is the channel name over which the message will be issued.
  • the third parameter is the message type to issue, and the last parameter is an optional message parameter object.
  • This method returns true if the adapter is connected to the kernel and returns false if the adapter is not connected to the kernel.
  • This method returns true if the adapter is processing an activation and returns false if the adapter is not processing an activation.
  • This method returns the activation context for the current activation. If called while the adapter is not processing an activation, a run-time error is generated.
  • the adapter control interface allows the kernel to manage the lifetime of the adapter through the kernel LoadAdapter and UnloadAdapter activations.
  • the kernel calls Startup whenever the adapter process is created.
  • Register should be called to register the adapter with the kernel.
  • the kernel calls Shutdown whenever the adapter process is being terminated.
  • Unregister should be called to unregister the adapter from the kernel.
  • IMsgParams is the interface exposed by the message parameter object.
  • the message parameter object is a collection of parameters that are attached to a message.
  • Adapters use the message parameter object to issue messages with parameters to the kernel through SendMessage and to access message parameters through the activation context when processing an activation.
  • This method initializes the message parameter object.
  • An optional size may be passed as the sole parameter. It is not required to call initialize in order to use the message parameter object.
  • This method clears the message parameter object, releasing all parameters. Sets the parameter count to zero. This method is used when the same message parameter object is used in more than one SendMessage call.
  • This method returns the number of parameters in the message parameter object.
  • This method returns the parameter value at the given index.
  • the first parameter is the zero-based index of the parameter to return.
  • This method assigns a parameter value to the parameter object.
  • the first parameter is the zero-based index of the parameter to set. 3.18.4 lActivCtx
  • the activation context is an object that provides meta-data associated with the current activation to the adapter.
  • the activation context object model provides hooks to determine the module that caused the activation to occur, the message that caused the activation to occur, any session declarations in the rule that fired the activation, and any persisted declarations in the rule that fired the activation.
  • This method returns the module object for the activation.
  • This method returns the message object for the activation.
  • This method returns the session declarations in the rule for the activation.
  • This method returns the persisted declarations in the rule for the activation.
  • the module interface is one child of the activation context.
  • the module interface provides information about the module that caused an activation to occur.
  • This method returns the module's GUID (string). Not supported in activations.
  • This method returns the module's name. Not supported in activations.
  • This method returns the module's filename. Not supported in activations.
  • This method returns the module path for the module.
  • This method returns the ring-level of the module. Not supported in activations.
  • This method returns the instance ID of the module that caused the activation.
  • HRESULT isLibrary ( [out, retval] unsigned int * pnLib)
  • This method returns true if the module is a library, false if not. Not supported in activations.
  • the message interface exposes the message that generated the activation through activation context.
  • This method returns the source of the adapter that generated the message.
  • This method returns the date and time the message was created (local timezone)
  • This method returns the source instance of the adapter that generated the message.
  • This method returns the correlation id for the message.
  • This method returns the module id for the message. This is only valid for messages having a class value of MC_MODULE or MC_CHANNEL.
  • This method returns the response id of the message. This is only valid for messages having a class value of MC_RESPONSE.
  • This method returns the channel name for the message. This is only valid for messages having a class value of MC_CHANNEL.
  • This method returns the class value of the message (see MSG_CLASS enumeration).
  • This method is used to access a parameter of the message.
  • the first parameter to this call is the zero-based indexed of the message parameter to access. Identical to using params in the message params object.
  • This method returns the number of parameters in the message.
  • Declarations and Persisted Declarations interface are knowledge declared in a rule that is passed through the activation context object. It is used to allow adapters access to the declarations in rules.
  • the Declarations interface is a standard Collection interface. Collection interfaces are those that allow you to use For each.. Next constructs. They also support indexed access.
  • This method returns the number of declarations or persisted declarations.
  • This method returns the value of a declaration or a persisted declaration.
  • the first parameter can be a zero-based index.
  • This method returns the value of a declaration or a persisted declaration.
  • the first parameter can be a zero-based index. Identical to data().
  • the message class enumeration relates numeric values to each class of message that may be generated. For example, SendModuleMessage results in a message that has a message class value of 32.
  • the network layer is a component of the system, serving as the extension of the event (or communication) bus between devices on the network.
  • user-level modules cannot directly access the network layer - they can only talk to the network in terms of logical names.
  • the Open Design system does not have an explicit network adapter, but rather exposes select network functionality through the kernel adapter.
  • the network adapter communicates with the system by sending messages to the Event Bus, and receiving messages from the Rules Engine via the Event Bus.
  • the network adapter connects the router on each node to one or more peers nodes on the network.
  • adapters communicate with the Event Bus through the Open Design Message schema.
  • Each adapter presents its own message schema that is understood by the rules written against it in the Rules Engine.
  • the Network Layer is somewhat special in that it is a system-provided adapter that converses primarily with system-provided rules.
  • the Network Layer is like any other adapter, sending events to the Event Bus containing Network Layer-specific schema.
  • Events can be thought of as system events, generated directly by the Network Layer; system-supplied rules are compiled in the Rules Engine to deal with them.
  • These sorts of events support the Open Design platform semantics such as "The network is on/offline,” “The network bandwidth rate is XXX,” an so on. These events are somewhat rare, but provide system-specific activities and UI presentation.
  • the Network Layer can receive a packet of data from across the network.
  • This packet is wrapped in a Network Layer-specific schema and it is the job of the Network Layer to unwrap that packet into an Open Design Message structure.
  • This Open Design Event is a wrapper for a remote message specified by a rule that had fired on the outbound machine.
  • a system-provided rule on the receiving machine handles the event and uses the message header and payload to either forward the message on to another peer, or to deliver the message to the local event bus which in turn delivers the message to the appropriate adapter or destination application.
  • This action taken (activation) is precisely what was specified on the originating machine, except that now it is instantiated on the receiving machine.
  • Figure 8 shows a high-level flow of control between the Network Layer, the Event Bus, the Rules Engine, and private calls between instances of the Network Layer across a network.
  • the Network Layer posts Open Design Events to the Event Bus as messages.
  • the Event Bus communicates with the Rules Engine, supplying input events as messages.
  • the Rules Engine fires activations embedded in messages to the Network Layer.
  • the Network Layer communicates with a Network Layer across a network through the Open Design Network Services. These calls (which may pass through a proxy server layer) are represented by the dotted lines of Figure 8. Implied in this figure is that the data received by one Network Layer from another is convertible to an Open Design Message.
  • Figure 9 is a block diagram illustrating the addressing layers of an Open Design Message.
  • the event element below is the internal representation of the message as it appears on the local Event Bus.
  • the specific elements of any of the message headers, including tag names and values, may change.
  • the transport, physical and logical headers that precede the event body provide inter node and hop-by-hop addressing information and instructions. These additional addressing elements are the wrappers for the event on the wire.
  • Figure 10 illustrates a more complete diagram that includes all of the architecture elements involved in node-to-node message exchanges between applications hosted on nodes A and B.
  • Open Design Messages are the internal message, unwrapped, from the on-the-wire format illustrated above.
  • a schema for Event Bus messages follows.
  • event-ctx denotes the event's source. —> ⁇ event-ctx>
  • rules may be written against event types—> ⁇ ! — by the same name with the rules engine. —> ⁇ event-type>visits ⁇ /event-type>
  • parameter lists may be nested —>
  • LHS left hand side
  • RHS right hand side
  • Rule 1 and 42 could be authored by separate developers or at separate times, and the system will "link” them together by their shared "person. adult” criterion. This ability to extend the rules of others is called composibility.
  • a rule engine will link together rules in such a way as to determine what rules need to fire automatically very efficiently. In fact, a good rule engine scales better than linearly to the number of rules, so a system with 100,000 rules runs nearly as fast as a system with 2,000 rules.
  • the Open Design event bus is an application message communication medium based on a rules engine for message dispatching, and application and system supplied modules that provide the rules by which message dispatching and forwarding within and between nodes is accomplished.
  • RETE a data-driven optimization
  • a router policy filter is based on rule conditions
  • rules can be used to add to criteria without changing the protocol globally. For example:
  • routers in the network do not update to the new routing rule, the global system continues to work.
  • the routers that do update to the new routing rule can now differentiate between high priority and lower priority traffic.
  • Open Design system allows third parties to add new conditions to routing, such as application-specific criteria (customer number, time of day, order type).
  • application-specific criteria customer number, time of day, order type.
  • Traditional models would ask them to write procedural code, with the inherent loss of rules benefits of: safety, optimization, composibility, invertability, conflict checking, and so on.
  • Rules are used to add and modify criteria used for routing o As new schemas for information that should impact routing are added, that information is put into a "database" that the rules can access
  • Rules can be distributed o If rules are moved from one node to another, we can check them to see what data they access and what data they assert. This allows determination of some level of safety checking.
  • Rules can interact with programs o Unlike routing tables, rules can interact with programs by specifying program data or object attributes on their LHS or RHS. This allows a rule to "call" a program, or a program to cause a rule to fire. This integration with programs while keeping some level of safety and scalability is a feature beyond routing tables or traditional "layer 7" routing. o Interaction may occur at the protocol and/or XML level, i.e. programs emit or consume information using XML.
  • Rules are used to create distributed algorithms o When a directory of users is distributed, rules can be used to express when the directory should be moved around.
  • Rete is an algorithm used by rule engines. There are two parts to the Rete algorithm:
  • Rules are written against a "working memory” - the set of facts known about the world.
  • the working memory is made up of session and persisted data created by modules and the event-stream.
  • a rule is the bottom-most node in an expression tree.
  • platform language is an XML schema coupled with additional semantics imposed upon the contents of certain elements within that schema. (This means that ⁇ expr>msg.params(2) ⁇ /expr> is interpreted differently than ⁇ expr>"Hello, world. " ⁇ /expr>.)
  • a program written in this language is called a "module.”
  • the module is the unit of programmability for the platform.
  • BNF Backus-Naur Form
  • the BNF is interpreted as follows:
  • the start symbol of the grammar is denoted by "START”.
  • the productions for a given symbol are terminated by ";”.
  • Multiple productions for a given symbol are separated by "[”. Symbols that are followed by "?” may appear zero or one times.
  • activ-param may contain activ-params, or expr, or simple XML character data.
  • activ-dest No special processing or interpretation is done on the XML character data content of this element.
  • activ-dest-instance The XML character data of the element may conform to the rules for the content of ⁇ expr>; that is, the data may parse as a number, string, or symbol.
  • activ-recpt-reqd The content of the element is ignored - the presence or absence of the element is what is important.
  • app-desc and app-name The XML character data content of the element is escaped for use within the inference engine as a valid string.
  • app-uuid All lower-case letters are converted to their upper-case equivalent.
  • app-ver No special processing or interpretation is done on the XML character data content of this element.
  • Expressions form a dynamic part of the platform language, where the run-time substitution of symbols and the authoring-time use of literals combine to affect the behavior of the module.
  • the module translation engine uses regular expressions to determine at translation time the type of each expression.
  • the language supports string literals (e.g., "Hello, world.”), decimal and hexadecimal integer literals (e.g., 7 and Oxa), and floating-point literals (e.g., 3.14).
  • string literals e.g., "Hello, world.”
  • decimal and hexadecimal integer literals e.g., 7 and Oxa
  • floating-point literals e.g., 3.14
  • the language also supports a number of specially interpreted symbols for accessing the values of the fields of messages and declarations at runtime, for accessing properties of the current module, and for notational convenience.
  • user-defined symbols are supported.
  • the supported symbols are: msg . params ⁇ non-negative integer) msg . s re msg. srclnstance msg. correlationID msg. type msg. responselD msg. channel msg. els decls .data (non-negative integer) pdecls .data (non-negative integer) mod. guid mod. name mod. ver mod. desc mod. path mod. instancelD true false null
  • the language supports expressions that are function-valued. That is, the "func" production of "expr” is used rather than the literal or symbolic productions.
  • Functions have a name and an argument list.
  • the argument list is itself a set of expressions - it is in this way that the grammar permits arbitrarily complex expressions.
  • the platform language supports the functions below. Each function is listed with the number of arguments that it expects and a short description.
  • expressions are typed
  • functions are typed
  • functions are typed return- values.
  • the module translation engine is a sequence of transforms that each take the output of the previous transform as input, perform some type of processing, and hand the output to the next transform in the sequence.
  • this pipeline of transforms generates code that can be loaded and run by the platform.
  • the code-generation transform is omitted, for example.
  • the module translation engine permits applications to be built on top of it that create sequences of transforms and invoke them one-by-one for a given input.
  • the base will expose the following (virtual) methods: int Transform ([in] buffer, [out] buffer); int GetName([out] buffer);
  • This section covers each of the transforms in the module translation engine.
  • This transform takes a filename as input and returns the contents of the file as output.
  • This transform takes a buffer of well-formed XML as input, executes pre-processing directives found in the buffer, and returns the result of having executed on these directives as the output.
  • this tag may include a "symbol" attribute. When it is encountered, add the symbol that is specified to the symbol table for the pre-processor for the current transformation invocation.
  • this tag may include a "symbol" attribute. If the specified symbol exists in the symbol table, the contents of the opening and closing ⁇ ifdef> tags are included in the output buffer. If not, the contents are omitted. If the ⁇ ifdef> tag is within an enclosing ⁇ ifdef> or ⁇ ifndef> directive that has switched off output, then output remains off.
  • this tag may include a "symbol" attribute. If the specified symbol exists in the symbol table, the contents of the open and closing ⁇ ifndef> tags are omitted from the output buffer. If not, the contents are included. If the ⁇ ifndef> tag is within an enclosing ⁇ ifdef> or ⁇ ifndef> directive that has switched off output, then output remains off.
  • this tag may include a "file” attribute.
  • the contents of the file (“.ri") are placed in-line in place of the include directive.
  • the maximum inclusion depth that will be supported is fifty.
  • the pre-processor directives are omitted from the output buffer that is returned. As a general rule, these directives are semantically identical to those found in the C pre-processor.
  • This transform takes a buffer of well-formed XML as input, validates it according to the platform language grammar, and returns the buffer unchanged as its output if all is well. An error is returned if the buffer is not well-formed XML or if it invalid with respect to the platform language grammar.
  • This transform takes a buffer of well-formed XML as input, translates it into Eclipse code, and returns the buffer of Eclipse code as output.
  • This transform takes an arbitrary buffer as input, writes the file to disk, and returns the buffer unchanged as output.
  • the filename that is used is based on the name of the file currently being processed. All path-delimiters are converted to underscores; a leading ".” is removed; and ".rea” is appended.
  • the module translation engine is linked into the platform binary at compile for use in loading modules at run-time.
  • This tool is called “appgen” (or, “appgen.exe” on Win32). It instantiates five transforms listed above and connect them in the following order:
  • -sourcefile Expects a single filename argument. If this option is specified then the -sourcedir and -targetdir options are ignored. The filename that is specified is used as the input to the ReadFile transform.
  • -sourcedir Expects a single directory name argument and defaults to ".” if left unspecified. If the -sourcefile option is not specified, then appgen traverses the file-system below the specified directory and processes every .r file that is encountered.
  • -targetdir Expects a single directory name argument and defaults to ".” if left unspecified. Translated files are deposited in this directory.
  • -ring Expects a single argument between 0 and 10, inclusive. Defaults to 10. This value is passed to the Translate transform.
  • This section is to describe how code is generated from the constructs of the platform language. It is organized into sections according to each major unit of code-generation.
  • Decimal and hexadecimal are supported formats for integer expressions. Regardless of which format is used, the representation may be converted to decimal before being output.
  • Strings may come in two forms: simple, double-quoted strings formatted according to the regular-expression listed in section 2.1 , and CDATA sections.
  • the first case might appear like so:
  • the second case is the following:
  • msg.channel Resolves to "?channel”.
  • msg.cls Resolves to one of the possible message class strings.
  • msg.correlationID Resolves to "?cid”.
  • msg.params(n) Resolves to "?pn”.
  • msg.responselD Resolves to "?rid”.
  • msg.src If the rule specified msg-src, this symbol resolves to what was specified. If not, this symbol resolves to "?source”.
  • msg .srclnstance Resolves to "?source-cookie”.
  • msg.type If the rule specified msg-type, this symbol resolves to what was specified. If not, this symbol resolves to "?type”.
  • decls.data(n) Resolves to "?decln”.
  • pdecls. data( ⁇ ) Resolves to "?pdecln”.
  • mod.desc mod.guid mod.name mod.ver Resolves to what was specified for app-desc, except that the data is escaped exactly as CDATA-delimited string-valued expressions are.
  • mod.instancelD Resolves to two zero bytes.
  • Open Design module An XML-based schema called an Open Design module defines Open Design Applications. ⁇ module> is the entry tag into this schema, and it contains tags for identifying the name of the application, the author, the version, the sets of rules defining the application, and other schema that allows the Open Design kernel to provide entry points into the system user interface.
  • Additional rule elements that could be added to this application include routing rules, policy rules, etc. Examples of these additional rule elements to build up a more realistic application appear within the Event Bus Section.
  • the Event Bus is the messaging interface exposed by the Open Design Application Router.
  • the interfaces allow each module type described earlier to be written and installed within the Rules Repository on any Open Design node. These interfaces are invoked by rules installed within the system.
  • the basic capabilities of the event bus are to:
  • the module file can be a translated file which may have a ".rea” extension or a raw ODI XML file that has a “.r” extension. If the module has a ".r” extension it may be automatically be run through the translator.
  • the interface Load Module is one mechanism by which new rules are added to the Repository.
  • the expression part of this rule expresses the conditions under which the actions below, invoking LoadModuleFromFile, occur.
  • the SendMessage interface is used to send messages to a destination.
  • the destination is expected to understand the parameters of the call.
  • the parameter is a simple string that could be displayed by the destination application for this message.
  • RegisterLogicalResource ( "myLogicalResource” , szFunc, szCrit, szlnstructions , szDescription) ;
  • This interface is invoked form application supplied name registration rules. This is an example call to register an application name:
  • Some of the parameters to the call are rule snippets themselves.
  • the C logic used to build up the parameter list, and then fire the rule, via an adapter to the event bus, to match the register name rule above is: var msgparams; var initialNodeData;
  • initialNodeData(l) GetCurrentNodelD ( ) ;
  • This name registration combed the parameters in the name registration call with a routing rule template to form a complete routing rule.
  • This routing rule is propagated by the infrastructure to any clients invoking the 'AddressBook' service. Calls to the service are via the SendMessage activations described above.
  • Client routing rule catches the invoke message and activates the syssvc adapter _SendLogicalMessage activation:
  • CSyssvc :_SendLogicalMessage (szLogicalName, szService, pParams)
  • the final call to NetSend invokes the network 'adapter' to wrap, and encode the message for delivery to a peer connection (if appropriate.)
  • the eb_Loadlncreased event is fired when the number of pending events on the event bus is greater than the threshold value. First time it fires when the threshold is first hit, and then each time the load increases by the interval value.
  • system services After the number of pending events on the event bus grows greater than threshold value, system services start sending EBLoadlncreased/Decreased events.
  • the events are issued as the load changes by the "interval" number of events. Default value for threshold is 1000 events. Default value for interval is 200 events.
  • the EBLoadlncreased/Decreased events are not added to event bus but go directly to the rules engine for immediate processing.
  • the CreateChannel interface creates a channel for messages between one module and another. Channels are used to ensure that messages sent to the event bus will only be received by the intended recipient of the message.
  • the event bus is a 'broadcast' bus, where any rule supplied by any application may fire against messages on the bus.
  • Channels provide a mechanism by which communication may be targeted. This prevents snooping or inappropriate rule firings for private messages.
  • the EBLoadThreshold Activation sets the event bus load threshold value. After the number of pending events on the event bus grows greater than threshold value, system services start sending EBLoadlncreased/Decreased events. The events are issued as the load changes on the "interval" number of events. Default value for threshold is 1000 events. The EBLoadlncreased/Decreased events are not added to event bus but go directly to the rules engine for processing.
  • threshold There is no minimal value for the threshold. If an attempt is made to set threshold to a negative value, the activation fails with ODIKRNL_E_ILLIGALTHRESHOLDVALUE result value.
  • This activation resets value of the threshold to 100 events.
  • This rule invokes the interface MakeConnection exposed by the Open Design router kernel.
  • a rule of this type could be supplied by an administrator to ensure that a highly connected central node is one of the configured peers of all Open Design nodes within an administrative domain. The left-hand-side of this rule would be written to ensure that only entities with the right access would cause this rule to fire.
  • Policy is used here as a general term referring to the processing of messages that pass through the system that is conditionally applied based on the contents of those messages. This conditional application of policy is accomplished through rules defined both by the system and by the user.
  • the lifetime of a message is modeled as a set of state-transitions in order to partition the types of processing that may occur on the message as it moves through the system.
  • the set of states that have been defined to model this lifetime are referred to collectively as the message states.
  • the message states have been divided into two complementary classifications based on their direction: the message has either been issued by an application and is headed outbound towards the routing infrastructure, or the message has been lifted off the wire and is headed inbound towards an application.
  • intra-node messages issued between processors and modules transition through no other states than in
  • the states and their definitions are listed below. They are listed by directionality. Within each direction, they are listed in the order through which messages will transition.
  • I wire The message has just been lifted off the wire.
  • the physical routing infrastructure has determined that it is destined for the node and has marshaled the message into the rule engine.
  • I instructions The instructions that the message carries are to be processed.
  • I logical The logical routing header of the message is to be processed.
  • I app The message is to be dispatched to an application for processing.
  • Outbound out
  • logical The message may be processed in order to generate its logical routing header.
  • out I instructions The message may be processed such that it includes the instructions that cause it to be handled properly at its destination.
  • out I wire The message is ready to be serialized onto the wire.
  • a field is added to the data-model used to represent messages in the rule engine.
  • the purpose of this field is to mark the current state of the message. Messages in the system are actually represented using an aggregate data-model to permit arbitrarily long parameter lists, so only the header component of the model may carry this field:
  • logical is a state-transition rule that matches against messages in the old state and advances them to the new state: (defrule in-instructions-to-in-logical ?message-header ⁇ - (message-header
  • This rule does properly affect the state-transition on the message, but it is incomplete for two reasons: it may fire before the policy rules that were intended for the in
  • Policy rules are defined by the system and by the user. A given policy rule is written against a particular message state. The actions that can be taken given a matching message are limited by the supported verbs at a given state.
  • Policy rules are defined both by the system and by the end-user. Further, there may be multiple, independent end-user policy authors. Policy rules that conflict with each other (say, one policy that asserts that a message should be consumed and another that asserts that it should be discarded) are likely.
  • State-transition rules are tagged with a low salience value to ensure that the policy rules for the old state fire before the state- transition rule is activated.
  • the rule that moves the message from the state at which we would like to detect conflicts to the next state contains a call-out in its actions that scans the action-dispatch queue maintained by the rule engine wrapper object.
  • the action-dispatch queue contains all the actions that will be taken for that stage.
  • a verb is an abstract way to refer to an operation to perform on a message.
  • Conflict detection may be constrained to a sub-set of the message- states, and in those states, only certain high-level actions are permitted to be taken (forward, discard, consume, etc).
  • the call-out removes all actions from the action-dispatch queue that were placed there by rules from the current state and issues a new conflict-detected message with the offending message as the payload.
  • the detect-conflicts function takes as its first argument the message state for which it is to search in the rule engine's outbound queue of actions.
  • the rest of the arguments to the detect-conflicts call are those verbs that are to be considered mutually exclusive - so if two or more of those verbs appear on the outbound rule engine queue as actions to take on the message, there is a conflict.
  • the detect-conflicts function removes all the actions for the specified state in this case, issues a "conflict-detected” message, and returns false to prevent the firing of the state-transition rule.
  • the detect-conflicts arguments are system-defined but well-known. That is, policy authors have enough knowledge to write non-conflicting policy, but the system decides what verbs are mutually exclusive.
  • in-wire discard in-instructions: deliver, request, response, forwarded
  • execute in-logical discard
  • dispatch in-app discard
  • dispatch out-app discard out-logical: discard
  • a module is a set of rules, as described earlier.
  • a service here is an external process that hosts service logic. This may be in addition to the logic of a service expressed in the Open Design .r language.
  • the application service router provides the connection between the elements listed above, i.e. there is preferrably no mechanism by which Open Design messages 'short circuit' the router core rules engine to communicate outside the policy infrastructure imposed by the router.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Computer And Data Communications (AREA)
  • Multi Processors (AREA)

Abstract

La présente invention concerne un système de traitement distribué dans lequel une pluralité d'applications sont connectées à un bus d'événements par l'intermédiaire d'une interface de carte. Les messages échangés entre les applications sont transmis sur le bus d'événements et sont traités en fonction de règles stockées dans une unité d'archivage de règles.
EP01953583A 2000-07-19 2001-07-19 Architecture de bus d'evenements Ceased EP1350165A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US21930400P 2000-07-19 2000-07-19
US219304P 2000-07-19
PCT/US2001/022971 WO2002025440A2 (fr) 2000-07-19 2001-07-19 Architecture de bus d'evenements

Publications (1)

Publication Number Publication Date
EP1350165A2 true EP1350165A2 (fr) 2003-10-08

Family

ID=22818728

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01953583A Ceased EP1350165A2 (fr) 2000-07-19 2001-07-19 Architecture de bus d'evenements

Country Status (5)

Country Link
EP (1) EP1350165A2 (fr)
JP (1) JP2004520641A (fr)
AU (1) AU2001276017A1 (fr)
CA (1) CA2454254A1 (fr)
WO (1) WO2002025440A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107783849A (zh) * 2017-09-27 2018-03-09 武汉斗鱼网络科技有限公司 事件处理方法及客户端

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7669120B2 (en) 2002-06-21 2010-02-23 Microsoft Corporation Method and system for encoding a mark-up language document
US7962918B2 (en) 2004-08-03 2011-06-14 Microsoft Corporation System and method for controlling inter-application association through contextual policy control
US7475150B2 (en) 2004-09-07 2009-01-06 International Business Machines Corporation Method of generating a common event format representation of information from a plurality of messages using rule-based directives and computer keys
JP5617586B2 (ja) 2010-12-10 2014-11-05 富士通株式会社 情報処理プログラム、中継装置及び中継管理装置
JP5609730B2 (ja) 2011-03-18 2014-10-22 富士通株式会社 情報処理プログラム及び方法、転送処理装置
CN114756495B (zh) * 2022-06-16 2022-09-06 中国人民解放军国防科技大学 基于分层消息软总线模型的操作系统及实现方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2304944A (en) * 1995-09-12 1997-03-26 Ibm Support for application programs in a distributed environment
AU9426998A (en) * 1997-10-29 1999-05-17 Siemens Schweiz Ag System for connecting network elements of communications installations to a telecommunications management network

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0225440A3 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107783849A (zh) * 2017-09-27 2018-03-09 武汉斗鱼网络科技有限公司 事件处理方法及客户端
CN107783849B (zh) * 2017-09-27 2021-01-01 武汉斗鱼网络科技有限公司 事件处理方法及客户端

Also Published As

Publication number Publication date
CA2454254A1 (fr) 2002-03-28
AU2001276017A1 (en) 2002-04-02
WO2002025440A3 (fr) 2003-08-07
WO2002025440A2 (fr) 2002-03-28
JP2004520641A (ja) 2004-07-08

Similar Documents

Publication Publication Date Title
US11726828B2 (en) Managing a virtualized application workspace on a managed computing device
US11171897B2 (en) Method and apparatus for composite user interface generation
US9256353B2 (en) Providing application and device management using entitlements
US8091097B2 (en) Distributed virtual machine architecture
Ameur-Boulifa et al. Behavioural semantics for asynchronous components
US11552868B1 (en) Collect and forward
Di Marzo et al. The Messenger paradigm and its implications on distributed systems
EP1350165A2 (fr) Architecture de bus d'evenements
Bennaceur et al. A unifying perspective on protocol mediation: interoperability in the future internet
Krishnamurthy et al. Programming frameworks for Internet of Things
Bettini Linguistic constructs for object-oriented mobile code programming & their implementations
Suzuki et al. Design and implementation of a scalable infrastructure for autonomous adaptive agents
Krishnamurthy JAMScript: A Programming Framework for Cloud of Things
Thoelen An Application Platform for Multi-purpose Sensor Systems
Zhou et al. A middleware platform for the dynamic evolution of distributed component-based systems
Monaco Enabling Seamless Autoscaling of Service Function Chains in Kubernetes
Allam et al. A message-passing model for service oriented computing
Suzuki et al. Middleware support for super distributed autonomic services in pervasive networks
Lin Transparent Componentisation: A hybrid approach to support the development of contemporary distributed systems
Nacar et al. Designing a Grid Computing Environment Shell Engine.
Mokdad et al. The computational object approach for network and systems management
Blair et al. Service Architectures
Hasan Distributed Programming Using CORBA Services
Funaro A reference model and a run-time support for pervasive adaptive systems
Duarte Um serviço de self-healing baseado em P2P para manutenção de redes de computadores

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20030219

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

17Q First examination report despatched

Effective date: 20080207

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20150706