Knowledge oriented programming

Abstract

A method, apparatus, and program product for designing, implementing, distributing, and deploying computer programs that consist of packaged knowledge components written in modem object oriented programming languages. A meta model defines a model for representing facts, intelligence, and packaging facts and intelligence into readily usable knowledge components implemented in off the shelf object oriented programming languages and tools. In addition, the meta model defines knowledge algebra to assemble and cascade knowledge components into larger and more powerful knowledge components and knowledge oriented software applications. A kernel is provided that links and executes knowledge components and knowledge oriented applications. The kernel dynamically links logical definition of knowledge components and the knowledge application to real implementations.

Description

FIELD OF THE INVENTION

[0002] The invention relates to computers and more particularly to knowledge oriented programming on a computer.

BACKGROUND OF THE INVENTION

[0003] Object Oriented Programming Languages (OOPL) and Relational Database Management Systems (RDMS) are the two major technological components of most of the contemporary computer programs. An OOPL encodes the domain knowledge (the logic layer) and visualization (the presentation layer) of the application. A database persistently stores application data and provides a declarative query language to selectively retrieve application data when needed.

[0004] The existence of two distinct technologies (OOPL and RDMS) leads to an impedance mismatch that must be resolved in the interface layer between the logic layer and the database. Layered architectures try to minimize and contain the impact of two distinct technologies on the design, development, and maintenance of applications.

[0005] Multiple approaches were proposed to merge the two different paradigms of computing: object oriented and relational database technologies. Primary motivations were: the elimination of the impedance mismatch between the persistence and logic layers, persistent storage and query of complex objects, and a single computing framework

[0006] These attempts led to competing proposals and standards. The object oriented community responded with extensions to object oriented technologies while the relational database community proposed extensions to relational databases. Two major proposals are, therefore, object databases and object relational databases

[0007] Object databases extend the object oriented paradigm to incorporate the concept of relation. In contrast, object relational databases extend the relational data model by providing support for complex data types. In either case, the goal is to provide a single platform that provides persistence and ad hoc query of complex objects.

[0008] The logic layer typically consists of rules. It has been anticipated for decades that rules stored and managed in a rule engine or knowledgebase would revolutionize the software industry. Given the fact that relational data model is firmly founded on logic, one might expect that the (object) relational databases should include rules. Although some proposals require the rules as essential, there is not a consensus on whether they are an essential or required as part of next generation systems.

[0009] Expert systems explicitly support rules and a significant number of object oriented concepts. Although expert systems are well known, they are not widely adopted by the mainstream software designers and developers. Common characteristics of expert systems (shells) are: a declarative rule language, a declarative language support for object oriented concepts, a pattern matching algorithm (typically a variant of the RETE algorithm), and host language support, for example Java or C++.

[0010] Rule engines have several major drawbacks. First, rule engines contain concepts and syntax that are alien to object oriented programming languages and relational databases. Second, rule engines include a fixed pattern-matching algorithm, which may not perform or scale to complex problems. Third, rule engines need to be integrated into object oriented programming languages and relational databases. Fourth, rule engines lack standards for defining, packaging, sharing, and integrating knowledge from different sources. Finally, rule engines are not extensible or adaptable to the particular needs of an application, i.e., they are a fixed generic solution.

[0011] Despite the strong need for isolating the logic layer and contrary to the long anticipation, widespread adaptation of rule engines to object oriented software applications did not materialize.

[0012] Intelligent databases, i.e., active and deductive databases, are proposals to extend databases to include the rule and event support. Most commercial databases do not yet include explicit rule support that is capable of representing and executing rules in the database. These proposals do not address the impedance mismatch, which is likely to become even more severe if logic layer is moved to persistence layer. The closest database feature, databases triggers, does not meet the needs of business rules.

[0013] What is needed to solve these problems is a single computing environment that seamlessly integrates object oriented programming, rules, and relations of complex objects.

SUMMARY

[0014] The invention may provide a method, apparatus, and program product for designing, implementing, distributing, and deploying computer programs that consist of packaged knowledge components written in object oriented programming languages. A meta model defines a model for representing facts, intelligence, and packaging facts and intelligence into readily usable knowledge components implemented in off the shelf object oriented programming languages and tools. In addition, the meta model defines knowledge algebra to assemble and cascade knowledge components into larger and more powerful knowledge components and knowledge oriented software applications. The invention provides a kernel that links and executes knowledge components and knowledge oriented applications. The kernel dynamically links logical definition of knowledge components and the knowledge application to real implementations.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] FIG. 1 depicts a block diagram of a computer system, according to an embodiment of the invention.

[0016] FIG. 2 depicts a block diagram of a Relation Function, according to an embodiment of the invention.

[0017] FIG. 3 depicts a block diagram of how new knowledge is derived from existing knowledge, according to an embodiment of the invention.

[0018] FIG. 4 depicts a block diagram of how relation functions and relations form a closed algebra, according to an embodiment of the invention.

[0019] FIG. 5 depicts a block diagram of the relationship between the Event, Event Handler, and Relation Function, according to an embodiment of the invention.

[0020] FIG. 6 depicts a block diagram of a Recursive Relation Function, according to an embodiment of the invention.

[0021] FIG. 7 depicts a UML representation of a Meta Knowledge Model, according to an embodiment of the invention.

[0022] FIG. 8 depicts a UML representation of a Meta Logic Model, according to an embodiment of the invention.

[0023] FIG. 9 depicts a UML representation of a Knowledge Definition Model, according to an embodiment of the invention.

[0024] FIG. 10 depicts a UML representation of a Run-time Model, according to an embodiment of the invention.

[0025] FIG. 11 depicts a UML representation of a Catalog Model, according to an embodiment of the invention.

[0026] FIG. 12 depicts a UML representation of a SYS_Catalog, according to an embodiment of the invention.

[0027] FIG. 13 depicts a UML representation of SYS_App and SYS_AppKnowledge, according to an embodiment of the invention.

[0028] FIG. 14 depicts a UML representation of SYS_AppSessionKnowledge and SessionKnowledge, according to an embodiment of the invention.

[0029] FIG. 15 depicts a UML representation of SYS_AppRelation, according to an embodiment of the invention.

[0030] FIG. 16 depicts a UML representation of SYS_AppEvent, according to an embodiment of the invention.

[0031] FIG. 17 depicts a UML representation of SYS_AppEventHandler, according to an embodiment of the invention.

[0032] FIG. 18 depicts a UML representation of SYS_AppRelationEvent, according to an embodiment of the invention.

[0033] FIG. 19 depicts a UML representation of SYS_KeyDefinition, according to an embodiment of the invention.

[0034] FIG. 20 depicts a UML representation of SYS_ThingDefinition, according to an embodiment of the invention.

[0035] FIG. 21 depicts a UML representation of SYS_ReferenceDefinition, according to an embodiment of the invention.

[0036] FIG. 22 depicts a UML representation of SYS_RelationDefinition, according to an embodiment of the invention.

[0037] FIG. 23 depicts a UML representation of SYS_RelationFunctionDefinition, according to an embodiment of the invention.

[0038] FIG. 24 depicts a UML representation of SYS_FactDefinition, according to an embodiment of the invention.

[0039] FIG. 25 depicts a UML representation of SYS_SessionRelation, according to an embodiment of the invention.

[0040] FIG. 26 depicts a UML representation of SYS_SessionEvent, according to an embodiment of the invention.

[0041] FIG. 27 depicts a UML representation of SYS_SessionEventHandler, according to an embodiment of the invention.

[0042] FIG. 28 depicts a UML representation of SYS_SessionRelationEvent, according to an embodiment of the invention.

DETAILED DESCRIPTION

[0043] In the following detailed description of exemplary embodiments of the invention, reference is made to the accompanying drawings (where like numbers represent like elements), which form a part hereof, and in which is shown by way of illustration specific exemplary embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, but other embodiments may be utilized and logical, mechanical, electrical, and other changes may be made without departing from the scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims.

[0044] In the following description, numerous specific details are set forth to provide a thorough understanding of the invention. However, it is understood that the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the invention.

[0045] FIG. 1 depicts a block diagram of a system for implementing an embodiment of the invention. The system 100 may include an electronic device 110 and a network 120.

[0046] Electronic device 110 may include a processor 135, a storage device 140, a network adapter 145, an input device 150, and an output device 155, all communicatively coupled via bus 180. Processor 135 may represent a central processing unit of any type of architecture, such as a CISC (Complex Instruction Set Computing), RISC (Reduced Instruction Set Computing), VLIW (Very Long Instruction Word), or a hybrid architecture, although any appropriate processor may be used. The processor 135 executes instructions and includes that portion of the electronic device 110 that controls the operation of the entire electronic device. Although not depicted in FIG. 1, the processor 135 typically includes a control unit that organizes data and program storage in memory and transfers data and other information between the various parts of the electronic device 110. The processor 135 may receive input data from the input device 150 and the network adapter 145, read and store code and data in the storage device 140, and may present output data via the output device 155. The processor 135 also may transmit and receive packets of information across the network 120 using the network adapter 145.

[0047] The network 120 may be any suitable network capable of supporting communication to the electronic device 110. Although one network 120 is shown, in other embodiments any number of networks and/or combinations of networks may be present. In an embodiment, the network 120 may support wireless communications. In another embodiment, the network 120 may support hard-wired communications, such as a telephone line or cable. In an embodiment network, the network 120 may be the Internet and support IP (Internet Protocol). In other embodiments, the network 120 may be a local area network (LAN) or a wide area network (WAN). In still other embodiments, the network 120 may support any appropriate protocol or protocols.

[0048] Although the electronic device 110 is shown to contain only a single processor and a single bus, the present invention applies equally to electronic devices that may have multiple processors and to electronic devices that may have multiple buses with some or all performing different functions in different ways.

[0049] The storage device 140 represents one or more mechanisms for storing data. For example, the storage device 140 may include read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, and/or other machine-readable media. Although only one storage device 140 is shown, multiple storage devices and multiple types of storage devices may be present. Further, although the electronic device 110 is drawn to contain the storage device 140, it may be distributed across other electronic devices.

[0050] The storage device 140 may include a Meta Model 160, an Application 161, and a Run-time 162. The Run-time 162 may include instructions capable of being executed on the processor 135 to carry out the functions of the present invention. In another embodiment, some or all of the functions of the present invention may be carried out via hardware in lieu of a processor-based system. Of course, the storage device 140 may also contain additional software and data (not shown), which is not necessary to understanding the invention. The Run-time 162 runs applications, such as application 161. The Run-time 162, Meta Model 160, and Application 162 may be embedded into another program: an application server, a web server, or a standalone application. The Run-time 162 is also the interface to other applications. The Run-time 162 dynamically binds the Application Definition 174 to the Application Implementation 177.

[0051] The Meta Model 160 may include a Meta Knowledge Model 165, a Meta Logic Model 166, a Knowledge Definition Model 167, a Catalog Model 169, and a Run-time Model 171.

[0052] The Application 161 may include an Application Knowledge Model 172, an Application Logic Model 173, an Application Definition 174, Application Data 175, Application Logic 176, and an Application Implementation 177. The Application Knowledge model 172 complies with the Meta Knowledge Model 165. The Application Logic Model 173 complies with the Meta Logic Model 166. The Application Definition 174 complies with the Knowledge Definition Model 167. The Application Definition 174 is stored in the Catalog Model 169. The Application Data 175 is stored in Knowledge Model 172. Application Logic 176 is stored in Application Logic Model 173.

[0053] The Meta Model 160 is a formally-defined programming model and may provide knowledge oriented software design and construction; packaging of knowledge into knowledge components; generalized queries as knowledge components; assembling knowledge components into knowledge oriented applications; independence from a programming language and development tool; rules, events, constraints, relations, classes, and objects within a single programming environment; a computing model based on most common object oriented programming and database concepts; independence from any persistence mechanism; declarative application design and binding; object oriented representation of knowledge; packaged, ready to use, sharable knowledge components; a run-time that can integrate knowledge components into knowledge applications; a software design and development model that emphasizes the componentization of knowledge; and persistence formats compatible with widely accepted formats, such as relational databases and XML.

[0054] Informally, knowledge consists of what we know, how we infer, and how we react to external events. The Meta Model 160 is a formal method for modeling knowledge (Meta Knowledge Model 165), modeling inferencing (Meta Logic Model 166), dynamically binding a declaratively defined application to a computer executable process using the Knowledge Definition Model 167, modeling declarative applications and their bindings (Catalog Model 169), and providing a run-time environment via the Run-time Model 171.

[0055] Application 161 consists of an Application Knowledge Model 172, Application Logic Model 173, Application Definition 174, Application Data 175, Application Logic 176, and Application Implementation 177. Application Knowledge Model 172 complies with the Meta Knowledge Model 165. Application Data 174 is stored in data structures defined by the Application Knowledge Model 172. Meta Knowledge Model 165, Application Knowledge Model 172, and Application Data 175 are analogous to Relational Model, Database Schema, and Data of Relational Databases. Application Logic Model 173 stores the Application Logic 176. Application Logic Model 173 complies with the Meta Logic Model 166.

[0056] Run-time 162 may include a Kernel 163 and a Catalog 164. Catalog 164 is stored in data structures defined by the Catalog Model 169. The Kernel 163 manages the Meta Model 160, Application 161, and the Catalog 164. The Kernel 163 also provides the interface to the external clients and/or applications.

[0057] Meta Knowledge Model 165

[0058] FIG. 7 shows the Meta Knowledge Model 165 described using the Unified Modeling Language (UML) notation. The Meta Knowledge Model 165 has the building blocks of an application's knowledge model. Thing, Key, Fact, and Relation are the fundamental building blocks. They are analogous to the Attribute, Key, Tuple, and Relation of Relational Data Model. The Meta Model 160 defines building blocks as abstract types. The abstract types specify the Meta Knowledge Model unambiguously and independently of any host programming language.

[0059] The Thing is the base class of all objects in the data model, in other words, all the domain objects. An instance of a Thing is a named object that is the subject of the knowledge. All application objects have a type that is a sub type of the Thing.

[0060] The Key class is the base class of a unique identifier of an application object. A key is required to be unique within the scope of the object it refers to. When an object is created, it is stored by value in only one relation. All other relations refer to the same object by its key. The Meta Model 160 does not allow facts to refer to objects by pointers or object references. The Meta Model 160 requires that all sub types of Key implement usual comparison operators: Equality, Greater Than, and Less Than.

[0061] A fact is a statement that is assumed to be true. A fact consists of a predicate and the list of arguments for which the predicate is true. For example, in the statement “John is a biologist,” “biologist” is the predicate and “John” is the thing for which the predicate is true.

[0062] In the Meta Model 160, the Fact class is a generic structure type to organize and hold subjects of predicates. Formally, the Fact is a set of things.

[0063] A relation is the container for a set of facts and the predicate of the facts it contains. The name of the relation is the name of the predicate. The predicate restricts the types of facts that can be inserted into the relation. Facts can be inserted into, updated in, deleted from, or queried in a relation. All facts of a relation must be of the same type or they must have a common base type. All facts of a relation may have the same cardinality, i.e., facts contain same number of things. A Fact implementation may have a fixed cardinality, that is, the number of elements in the Thing set is fixed.

[0064] StringKey, DateKey, and IntegerKey are three common types of keys. Additional key types can be added if necessary. ThingList and ThingSet are commonly needed sub types of Thing. They often used to encode a fact between one object and a set or list of other objects. SimpleFact is the implementation of a fact type that has a cardinality of one. OneToOneFact is the implementation of a fact type that has a cardinality of two. In practice, higher cardinality facts are rarely needed. If required they can be created by extending the Fact class or OneToManyFact. MapRelation is a generic implementation of Relation. As the name suggest, MapRelation uses a hash map to store and index its facts.

[0065] The Meta Knowledge Model 165 has the expressive power to represent and index any type of data structure and relationship types encountered in relational database design and object oriented programming.

[0066] Meta Logic Model 166

[0067] The Meta Knowledge Model 165 is a protocol for organization, indexing, and retrieval of objects. The Meta Logic Model 166 is a protocal for deriving new relations from a set of base relations, and imposing rules and constraints on the relations. It specifies the building blocks of an application's logic: Event, Event Handler, and RelationFunction. FIG. 8 shows the Meta Logic Model described using the Unified Modeling Language (UML) notation.

[0068] The Meta Knowledge Model 160 requires that all knowledge is stored in relations. Similarly, Meta Logic Model 165 requires that all computed or inferred knowledge be returned as a relation. Relation Functions are special in that they take relations as input and return a relation. The Relation Function is a generalization of both a database query and function concept in programming languages.

[0069] RelationFunction is an abstract class. The application provides the implementation. Typically a relation function is a thin wrapper to an existing algorithm. The simplicity and the generality of the RelationFunction enable the end users and the application designers to reuse or integrate existing code. RelationFunctions forms a closed algebra. Closure property ensures that RelationFunctions can be cascaded to implement complex logic.

[0070] An Event is a change in a relation. The Run-time 162 monitors the changes to the relations to ensure that change is allowed and to take necessary actions. An event is associated with a relation. Typical changes are insertion, deletion, and update of facts. An event may apply to any fact or to a number of specific facts. Once an event is detected, an action may need to be taken. An event has an event handler that represents the action. An event and event handler pair represents a rule or a constraint: If <event> then <eventHandler>. The designer of Application 161 may specify the events. Typically, there is no need to override the Event and EventHandler classes. An event has one of the following scopes: Application, and Session. Application and Session will be discussed later in detail. When an event is application scope, it applies to all sessions of the application. When it is session scope, it applies to specific session in which it is declared. An event has one of the following types: Insert, Delete, Update, Add, and Drop. These are the allowed operations on relations. Since all knowledge is stored in relations, every event is one of these types. There are two levels of an event: Relation, and Fact. When an event has the Relation Level, it applies to any fact in the relation. When it is Fact Level, it only applies to specified facts.

[0071] An event handler is a specification of what action will be taken and where. An event handler has a relation function (what to execute) and a target relation (where to put the result).

[0072] When an event handler is invoked, its relation function is executed. The action of an event handler is an operation between two relations: the output of the relation function and the target relation. An event handler has the following action types: Clear, Drop, Replace, Insert, Delete, and Update. An action type determines the operation on the target relation.

[0073] The Relation Function, Event, and Event Handlers together provide the functionality of query, computation, rule, and constraint. The Meta Logic Model 166 is a model of the logical flow of a software application 161. Separation of the application logic is critical to on-demand assembly of applications from a set of data structures and algorithms.

[0074] Knowledge Definition Model 167

[0075] The Meta Model 160 may separate the logical structure of a software application from its implementations. The Knowledge Definition Model 167 is an object-oriented model to capture and store the logical design of an application. FIG. 9 shows the Knowledge Definition Model 167 described using the Unified Modeling Language (UML) notation. The Kernel 163 binds the logical design to a real implementation at run time. In the Meta Model 160, users design the application at a logical level and then assemble a set of implementing components at run time. Logical application definition and dynamic binding is key to realizing knowledge component technologies and markets. A precise mapping of the logical design to physical implementation is also critical to the development of visual design tools and automatic code generation. The conversion from logical to physical model is lossless. The separation of logical and physical design enables the domain experts do design the application without worrying about the implementation.

[0076] Most of the building blocks of the Application 161 has a matching component in the Knowledge Definition Model 167. The logical definition of an application is also used to enforce type safety.

[0077] Catalog Model 169 and Catalog 164

[0078] The Catalog 164 stores the applications, their logical design, and their user sessions and run-time data. The Catalog Model 169 specifies the structure and building blocks of Catalog 164.

[0079] SYS_Catalog is the root relation of Run-time 162. Storage Device 140 may have multiple instances of Run-time 162 running. Each instance has its own catalog. An instance of SYS_Catalog is created by the Run-time 162 automatically. SYS_App is the root relation of an application. SYS_App and the relations contained in it form the application catalog. End users with sufficient privileges can query and modify the application catalog directly. Knowledge definitions stored the Catalog 164 are used to instantiate objects, enforce type constraints, and referential integrity by the Runtime 162.

[0080] Kernel 163 creates an instance of an application catalog when it loads the application. The application catalog is destroyed when an application is unloaded.

[0081] SYS_AppSessionKnowledge is the root relation of session specific application knowledge. SYS_AppSessionKnowledge and the relations contained in it form the session catalog. Kernel 163 creates an instance of a session catalog when the session is created. The session catalog is destroyed when user closes the session or when the session expires.

[0082] The Kernel 163 manages the application catalog and the session catalog. The Catalog 164 may have multiple applications loaded. Each application may have multiple sessions. Knowledge can be shared between the applications and sessions.

[0083] Runtime 162

[0084] The Runtime 162 consists of Kernel 163, and the Catalog 164. FIG. 10 shows the Run-time described using the Unified Modeling Language (UML) notation. The Runtime 162 is the container for the applications, and the components that manages the applications. Responsibilities of the Kernel 163 include system initialization, loading and binding of the applications, providing client access to application relations and relation functions, linking the application to a real implementation, monitoring relations for events, executing the event handlers when events are detected, and managing multiple user sessions. The clients of System 100 may create an instance of the Kernel 163 as the first step. All system functionality is then accessible from the kernel object. A kernel object can be embedded to any container application, for example, web server, application server, or a desktop application. The Kernel 163 is independent of the application and the host environment. The Kernel 163 can accommodate multiple clients (users) for multiple applications. The Kernel 163 allocates a separate copy of the application for each concurrent client.

[0085] The Kernel's role is equivalent to the role of an operating system. The Kernel 163, like an operating system, runs the applications without knowing their context. It needs to know only a small number of things. The Kernel 163 manages an application using the information contained in the Meta Model 160. The operational job of the Kernel 163 is to respond to client requests, detect system events, call the event handlers, and take specified actions on the relations. Details of the application are not need to be known to the Kernel 163.

[0086] A session is where a client's work is stored. A session is created when a client sends the first request to the Kernel 163. It is destroyed when it is expired, or when the client explicitly terminates the session. The Kernel 163 can have multiple applications loaded and running. When a client requests an application to be loaded, the Kernel 163 reads the Application Definition 174 from a text file. The Application Definition 174 includes the logical definition of the application and its run-time bindings.

[0087] Application 161

[0088] Application 161 consist of the Application Knowledge Model 172, Application Logic Model 173, Application Data 175, Application Logic 176, Application Definition 174, and Application Implementation 177.

[0089] Application Knowledge Model 172 is the set of application domain classes that specify how the known facts are organized and indexed. There can be any number of classes. Each class must be a sub class of a class contained within the Meta Knowledge Model 165. Application Data 175 are the set objects that are instances of the classes defined within the Application Knowledge Model 172.

[0090] Application Logic Model 173 is the set of application domain Relation Functions. Each domain Relation Function must be a sub type of the base Relation Function specified by the Meta Logic Model 166. Application Logic 176 is the set objects that are instances of classes defined within the Application Logic Model 173 and the set of objects that are instances of Event and Event Handler classes defined by the Meta Logic Model 166.

[0091] Application Definition 174 is a textual or binary file that specifies all the domain classes, and domain objects and their constraints. Application Definition 174 includes both a logical specification and their bindings to an implementation. Application Implementation 177 is a set of compiled libraries that implements the classes and objects specified in the Application Definition 174.

[0092] Class

[0093] Class is the fundamental concept of Object Oriented Programming. Domain is the equivalent concept in Relational Databases. Data type, or Type, commonly used to mean Class or Domain. Type is a more general concept. We might have types that are not classes. We will use only Class, instead of type, to emphasize our intention to firmly base the Meta Model 160 on Object Oriented Programming.

[0094] A Class defines methods that collectively specify the external behavior of the objects that are instances of that Class. A class may also have public attributes.

[0095] Object

[0096] An object can be anything. An object may have one or more classes. Every object has at the least one class. We will use object to refer to an instance of a Class.

[0097] Inheritance

[0098] Class B inherits Class A, if Class B provides all of the external behavior of Class A. In other words, Class B is a subtype of Class A or Class A is super class of Class B.

[0099] Object Name

[0100] Object names start with lower case letters and classes start with upper case letters. For example, “relation” refers to an instance of “Relation” class. Object names are used when discussing properties of instances of a class. For example, “A relation must have a unique key” means that every instance of the Relation Class has a unique key.

[0101] Current Object Reference

[0102] The reference to the object itself is this. For example, in description of method getName( ), “Gets the name of this”, this refers to the object on which getName( ) is called.

[0103] Variables

[0104] The concept of variable is inherited from the host programming language. Variable names used in the text follow the programming element conventions. For example, in the description of method setName(String newName), “Sets the name of this to newName”, newName refers to a variable that points to a string.

[0105] Meta Knowledge Model 165

[0106] The classes Key, Relation, Fact, and Thing are the building blocks of a knowledge model. The Meta Knowledge Model 165 may specify them as abstract classes. All application specific components must be a subclass of one of these classes.

[0107] Key

[0108] The Key class is the base class of a unique identifier of an object. A key is required to be unique within the scope of the object it refers to. When an object is created, it is stored by value in only one relation. All other relations refer to the same object by its key.

[0109] A key identifies an object by name. Two objects are the same if they have the same key. Typically a key is a wrapper around a string or an integer. Three most common sub classes of Key are StringKey, DateKey and IntegerKey. They have methods to construct keys from strings, dates, and integers. They also have methods to get the string, date, and integer values of the keys.

[0110] Key Class is an abstract class.

[0111] public Key getKey( )

[0112] Returns the key of a key. The key of a key is itself. All key classes are sub classes of Key.

[0113] The StringKey Class is a sub class of Key.

[0114] public StringKey(String newValue)

[0115] Constructs a key out of a String.

[0116] public String getAsString( )

[0117] Returns the string value of the key. This is the same string that is used to construct the key.

[0118] public int compareTo(Object newKey)

[0119] Compares two keys. The input is another key of the same type: StringKey. This method delegates the comparison of two keys to the comparison of their string values.

[0120] public boolean equals(Object obj)

[0121] Compares two keys for equality. The input is another key of the same type: StringKey. Two keys are equal if they compare to be the same.

[0122] public int hashCode( )

[0123] Returns the hash code of the key. The hash code of the key is the hash code of the string value of the key.

[0124] IntegerKey Class is a sub class of Key.

[0125] public IntegerKey(int newValue)

[0126] Constructs a key out of an int value.

[0127] public int compareTo(Object newKey)

[0128] Compares two keys. The input is another key of the same type: IntegerKey. This method delegates the comparison of two keys to the comparison of their integer values.

[0129] public int getAsInt( )

[0130] Returns the integer value of the key. This is the same integer that is used to construct the key.

[0131] public boolean equals(Object obj)

[0132] Compares two keys for equality. The input is another key of the same type: IntegerKey. Two keys are equal if they compare to be the same.

[0133] public int hashCode( )

[0134] Returns the hash code of the key. The hash code of the key is the integer value of the key.

[0135] The DateKey Class is a sub class of Key.

[0136] public DateKey(Date newValue)

[0137] Constructs a key out of a Date value.

[0138] public int compareTo(Object newKey)

[0139] Compares two keys. The input is another key of the same type: DateKey. This method delegates the comparison of two keys to the comparison of their date values.

[0140] public Date getAsDate( )

[0141] Returns the date value of the key. This is the same date that is used to construct the key.

[0142] public boolean equals(Object obj)

[0143] Compares two keys for equality. The input is another key of the same type: DateKey. Two keys are equal if they compare to be the same.

[0144] public int hashCode( )

[0145] Returns the hash code of the key. The hash code of the key is hash code of the date.

[0146] Thing

[0147] Thing is the abstract base class of all objects in the Run-time 162. The Thing class has the methods that are common to all of the Run-time 162 classes.

[0148] Thing Class

[0149] public String getDefinition( );

[0150] Gets the name of the knowledge definition of this.

[0151] public void setDefinitionName(String newDefinitionName);

[0152] Sets the name of the knowledge definition of this.

[0153] public abstract Key getKey( );

[0154] Gets the key of this. The method getKey( ) ensures that all objects in the data model have a key that identifies the logical object.

[0155] The ThingList Class is the base class of domain things that represents an ordered list of things.

[0156] public ThingList( );

[0157] Construct an empty thing list.

[0158] public void add(int index, Thing thing);

[0159] Adds a thing at the specified position. The index must be zero or positive.

[0160] public boolean add(Thing thing);

[0161] Adds a thing to the end of the list.

[0162] public boolean addAll(ThingList newThings);

[0163] Adds all the thing of newThings to the end of this.

[0164] public boolean addAll(int startindex, ThingList things);

[0165] Adds all the thing of a thingList starting at the startIndex. If list contains elements beyond position i, they are overridden.

[0166] public Thing set(int index, Thing newThing);

[0167] Sets the thing at index to newThing.

[0168] public Thing get(int index);

[0169] Gets the thing at index.

[0170] public Thing remove(int index);

[0171] Removes the thing at index.

[0172] public void clear( );

[0173] Removes the all thing of this.

[0174] public boolean contains(Thing newThing);

[0175] Searches the list for an item whose key matches the key of the newThing. Returns true if a match is found. Return false otherwise.

[0176] public int size( );

[0177] Returns the number of things in this.

[0178] public void trimToSize( );

[0179] Trims the size of the list to the number of things in the list.

[0180] public void ensureCapacity(int newCapacity);

[0181] Sets the minimum capacity of this to newCapacity.

[0182] public boolean isEmpty( );

[0183] Returns whether this is empty.

[0184] public int indexOf(Thing thing);

[0185] Returns the index of the thing. If thing does not exist, it returns—1.

[0186] public Key getKey( );

[0187] Returns the key of this.

[0188] The ThingSet Class is the base class of domain things that represent a set of objects.

[0189] public ThingSet( );

[0190] Construct an empty thing set.

[0191] public int size( );

[0192] Returns the number of things in the set.

[0193] public boolean isEmpty( );

[0194] Returns whether the set is empty.

[0195] public boolean contains(Thing newThing);

[0196] Searches the set for an item whose key matches the key of the newThing. Returns true if a match is found. Return false otherwise.

[0197] public Thing[ ] toArray( );

[0198] Gets the things in the set as array of things.

[0199] public boolean add(Thing thing);

[0200] Adds a thing to this.

[0201] public boolean addAll(ThingSet thingSet);

[0202] Adds all the thing of a thingSet to this.

[0203] public boolean remove(Thing thing);

[0204] Removes the thing from this.

[0205] public boolean removeAll(ThingSet thingSet);

[0206] Removes all the things of thingSet from this.

[0207] public void clear( );

[0208] Removes all the things of this.

[0209] public Key getKey( );

[0210] Returns the key of this.

[0211] The Fact Class is the abstract base class of all objects that represent a fact.

[0212] public abstract int getSize( );

[0213] Returns the cardinality of the fact; the number of things in the facts.

[0214] public abstract boolean set(int i, Thing thing);

[0215] Sets the thing at the position i. Input thing is an object whose subtypes include Thing. If the requested position i is negative or greater than or equal to the number of things, no value is set.

[0216] public abstract Thing get(int i);

[0217] Returns the thing stored at the position i. Return value is an object whose subtypes include Thing. If the requested position i is negative or greater than or equal to the number of things, it returns null.

[0218] public abstract Thing get(Key key);

[0219] Returns the thing whose key is equal to key. If no matching key exists, it returns null. The return value is an object whose subtypes include Thing.

[0220] public abstract Thing[ ] get( );

[0221] Returns all the thing of the fact. The returned array of things can have only those objects whose subtypes include Thing.

[0222] public abstract boolean update(int i, Thing thing);

[0223] Replaces the thing at position i with the thing. If requested position i is greater than or equal to the number of things of the fact, or if i negative, it does not modify the fact. In other words, only existing things can be updated.

[0224] public abstract boolean update(Key key, Thing thing);

[0225] Replaces the thing whose key is equal to key. If no matching key exists, it does not update the fact.

[0226] public abstract boolean delete(int i);

[0227] Deletes the thing at position i. If requested position i is greater than or equal to the number of thing in the fact, or if i negative, it does not modify the fact. Only existing things can be deleted. After the successful deletion, the size of the thing list is still the same. The position i has a null value after deletion.

[0228] public abstract boolean delete(Key key);

[0229] Deletes the thing whose key is equal to key. If no matching key exists, it does not modify the fact. After the successful deletion, the size of the thing list is still the same. The position i has a null value after deletion. If multiple matches are found, all matched things are deleted.

[0230] public abstract boolean deleteAll( );

[0231] Delete all things of the fact.

[0232] public Key getKey( );

[0233] Return the key of the fact. getKey( ) is overridden in a sub type to return the desired key.

[0234] Simple Fact

[0235] The Simple Fact class is an implementation of the abstract Fact class. A simple fact has only one thing. The default key of the fact is the key of the thing. A relation with simple facts is equivalent to a hash table. The thing of the fact can be any sub type of Thing, including Key, and Relation.

[0236] One-to-One Fact

[0237] This class is an implementation of abstract Fact class. A One-to-One fact has two things. The default key of the fact is the key of the first thing. The things of the fact can be any sub type of Thing, including Key, and Relation.

[0238] One-to-Many Fact

[0239] A fact whose cardinality is greater than 2 is required to extend this class. The default key of the fact is the key of the first thing. The things of the fact can be any sub type of Thing, including Key, and Relation.

[0240] Relation

[0241] A Relation is the container for a set of facts and the predicate of the contained facts. The name of the relation is the name of the predicate. The predicate restricts the types of facts that can be inserted into the relation.

[0242] Relation Class

[0243] abstract public String getName( );

[0244] Gets the name of a relation. Name identifies the logical name of the relation object. The application designer assigns the logical name. Name is the default key for the relation. If name is not unique, getKey( ) method is overridden to provide a unique key. abstract public void setName(String newName);

[0245] Sets the name of a relation. Every relation has a name. The name is expected to be descriptive of the purpose of the relation.

[0246] abstract public boolean insert(Fact fact);

[0247] Inserts a fact to the relation. The key of the fact cannot be null. The type of the fact must match with Fact or with one of sub types of Fact. If key type does not match, it raises InvalidKeyException. If key exists, it fails. It raises DuplicateKeyException. If key is null, it raises NullKeyException.

[0248] abstract public boolean update(Fact newFact);

[0249] If there is a fact whose key matches with key of newFact, it replaces that fact with newFact. If no matching fact is found, relation is not updated. If key newFact is null, relation is not updated.

[0250] abstract public boolean delete(Fact newFact);

[0251] If there is a fact whose key matches with key of the newFact, it deletes that fact. If key of the newFact is null, relation is not updated.

[0252] abstract public boolean delete(Key newKey);

[0253] If there is a fact whose key matches with newKey, it deletes that fact. If newKey is null, relation is not updated.

[0254] abstract public boolean deleteAll( );

[0255] Deletes all the facts in this.

[0256] abstract public boolean insert(Relation r);

[0257] Inserts all the facts of the relation r into this. If r is null, it raises InvalidRelationException. Key and the Fact type of relation r must match the key and fact type of this. Otherwise InvalidRelationException is raised. This operation loops over the facts of r and inserts each one of them into this.

[0258] abstract public boolean update(Relation r);

[0259] Update all the facts of the relation r in this. If r is null, it raises InvalidRelationException. Key and the Fact type of relation r must match the key and fact type of this. Otherwise InvalidRelationException is raised. This operation loops over the facts of r and updates each one of them.

[0260] abstract public boolean delete(Relation r);

[0261] Deletes all the facts of the relation r from this. If r is null, it raises InvalidRelationException. Key and the fact type of relation r must match the key and fact type of this. Otherwise InvalidKeyException is raised. This operation loops over the keys of r and deletes each one of them from this.

[0262] abstract public int getSize( );

[0263] Returns the number of facts in this.

[0264] abstract public Fact get(Key newKey);

[0265] Returns the fact whose key matches newKey. If no matching record is found, it returns null.

[0266] abstract public Fact[ ] getAll( );

[0267] Returns all the facts of this as an array.

[0268] abstract public boolean contains(Key newKey);

[0269] Returns true if there is fact whose key matches newKey. If no matching record is found, it returns false.

[0270] abstract public Relation intersect(Relation r);

[0271] Returns the facts that exist in r and this. If r is null, it raises InvalidRelationException. Key and the Fact type of relation r must match the key and fact type of this. Otherwise InvalidRelationException is raised.

[0272] abstract public Set keys( );

[0273] Returns the set of keys of this.

[0274] abstract public Key getKey( );

[0275] Returns the key of this.

[0276] MapRelation Class

[0277] MapRelation is the default implementation of Relation. As the name suggests, MapRelation uses a HashMap to store and index facts.

[0278] Meta Logic Model 166

[0279] The System 100 may have two types of fact: base and derived

[0280] A base fact exists independently of other facts. We cannot derive them from other facts. They are the axioms of the System 100. Derived facts are consequences of base facts. We refer to the ability to derive facts from base facts as intelligence. In the System 100, intelligence is represented as a Relation Function, FIG. 3.

[0281] A client of the System 100 may request the execution of a relation function. Or the Run-time 162 may execute a set of relation functions to enforce rules and constraints. The ability of the Run-time 162 to enforce the rules and constraints is provided by Relation Function, Event, and Event Handler. The Meta Logic Model 166 specifies the Relation Function, Event, Event Handler, and their supporting classes.

[0282] Relation Function

[0283] Relation functions are special in that they take relations as input and return a relation. A relation function is a generalization of both a database query and function concept in programming languages. The System 100 stores relation functions in the Catalog 164. Relation Function is a sub type of Thing. Relation Function is an abstract class. The application provides the implementation.

[0284] FIG. 2 graphically depicts the Relation Function. A relation function may be recursive. FIG. 4 graphically depicts a recursive relation function. Relation functions form a closed algebra. Due to its closure property, relation functions can be cascaded to construct complex logic. FIG. 4 graphically depicts how relation functions can be cascaded. FIG. 5 depicts how events and relation functions cooperate to implement rules.

[0285] FIG. 6 depicts how events and recursive relation functions cooperate to implement cascaded rules and actions.

[0286] Relation Function Class

[0287] Relation Function is an abstract sub class of Thing.

[0288] public String getName( )

[0289] Gets the logical name of this. Logical name uniquely identifies a relation function. Logical names are assigned by the application. The name is the default key of a relation function.

[0290] public void setName(String newName)

[0291] Sets the logical name of this to newName.

[0292] public abstract Relation execute(Relation[ ] r)

[0293] Executes the relation function. Application designer specifies what execute does. Application developers implement execute method in a sub type of Relation Function. Input is an ordered list of relations. The Run-time 162 ensures the type safety at run time.

[0294] public Key getKey( )

[0295] Return the key of this. Default implementation return a StringKey constructed from the name of this.

[0296] Event

[0297] An event is change in a relation. The Run-time 162 may monitor the changes to the relations to ensure that change is allowed or to take an action.

[0298] An event is associated with a relation. Typical changes are insertion, deletion, and update of facts. An event may apply to any fact or a number of specific facts. Once an event is detected, an action may need to be taken. An event has an event handler that represents the action. An event and event handler pair represents a rule:

[0299] If<event>then <eventHandler>

[0300] The designer of Application 161 specify the events and their handlers. Typically, there is no need to override the Event.

[0301] An event may have scopes of Application or Session Application and Session will be discussed later in detail. When an event is application scope, it applies to all sessions of the application. When it is session scope, it applies to specific session in which it is declared.

[0302] An event has one of the following types: Insert, Delete, Update, Add, or Drop

[0303] These are the five types of operations on relations. Since all knowledge is stored in relations, every event is one of these types.

[0304] There may be two levels of an event: Relation and Fact.

[0305] When an event has the Relation Level, it applies to any fact in the relation. When it is Fact Level, it only applies to specified facts.

[0306] Event Class

[0307] Event is a sub class of Thing.

[0308] public Event( )

[0309] Constructs an event.

[0310] public String getName( )

[0311] Gets the name of this as a string. A name uniquely identifies an event within its scope. If scope is Session, name must be unique within the session. If scope is Application, name must be unique within the application.

[0312] public void setName(String newName)

[0313] Sets the name of this to newName.

[0314] public String getRelationName( );

[0315] Gets name of the relation to whom event is attached.

[0316] public void setRelationName(String newRelationName);

[0317] Sets the name of the relation to whom event is attached.

[0318] public Relation getKeys( )

[0319] Returns the keys of facts to which event are applicable. If the level of the event is Relation, returns null. When the level is Relation, event is applicable to all facts of the relation.

[0320] public int getPriority( )

[0321] Returns the priority of the event. The highest priority is 0. The priority decreases with increasing value. The Run-time 161 checks highest priority event first. Default value is zero. When a set of events has the same priority, their keys prioritize them. The smallest key value has the highest priority.

[0322] public void setPriority(int newPriority)

[0323] Sets the priority of this to newPriority.

[0324] public EventScope getScope( )

[0325] Returns the scope of this. Valid scopes are Session, and Application When the scope is Session event is monitored for the current session only. When the scope is Application event is monitored for all session of the application only.

[0326] public void setScope(EventScope newScope)

[0327] Sets the scope of this to newScope.

[0328] public EventLevel getLevel( )

[0329] Returns the level of this. Valid level are Relation and Fact. When the scope is Relation event is monitored for every fact of the target relation. Otherwise it is monitored for a specified set of facts.

[0330] public void setLevel(EventLevel newLevel)

[0331] Sets the level of this to newLevel.

[0332] public String getEventHandlerName( )

[0333] Gets the event handler name of this. When the event is detected, the event handler is executed.

[0334] public void setEventHandlerName(String newEventHandlerName)

[0335] Sets the event handler of this to newEventHandlerName.

[0336] public Key getKey( )

[0337] Returns the key of this.

[0338] Event Handler

[0339] An event handler is a specification of what action will be taken and where. An event handler may have a Relation Function (what) and a Target Relation (where).

[0340] When an event handler is invoked, relation function is executed. The action is an operation between the output of the relation function and the target relation.

[0341] An event handler may have the following action types: Clear, Add, Drop, Replace, Insert, Delete, or Update.

[0342] An action type determines the operation on the target relation.

[0343] Class ActionType

[0344] Action is a super class of EnumeratedType.

[0345] public static final int Clear=1;

[0346] Removes all facts from the target relation.

[0347] public static final int Add=2;

[0348] Adds the target relation to Catalog 164. Target relations within the scope of the event are added. For example, if the scope of the event is Session, it is added to the session of the triggered event. If scope is Application, target relation is added to all the sessions of the application.

[0349] public static final int Drop=3;

[0350] Drops the target relation from Catalog 164. Target relations within the scope of the event are dropped. For example, if the scope of the event is Session, it is dropped from the session of the triggered event. If scope is Application, target relation is dropped from all the sessions of the application.

[0351] public static final int Replace=4;

[0352] Replaces the target relation in a Catalog 164. Target relations within the scope of the event are replaced. For example, if the scope of the event is Session, it is replaced in the session of the triggered event. If scope is Application, target relation is replaced in all the sessions of the application.

[0353] public static final int Insert=5;

[0354] Inserts into the target relation the facts of the relation returned by the relation function. Target relation must be within the scope of the event.

[0355] public static final int Delete=6;

[0356] Deletes from the target relation the facts of the relation returned by the relation function. Target relation must within the scope of the event.

[0357] public static final int Update=7;

[0358] Updates in the target relation the facts of the relation returned by the relation function. Target relation must be within the scope of the event.

[0359] public ActionType(int newType)

[0360] Constructs an action type from its integer id newType.

[0361] public String getDescription( )

[0362] Gets the description of the action type.

[0363] public void setDescription(String newDescription)

[0364] Sets the description of the action type to newDescription.

[0365] EventHandler Class

[0366] EventHandler is a sub class of Thing.

[0367] public EventHandler( )

[0368] Constructs and EventHandler.

[0369] public String getName( )

[0370] Gets the name of this. Name is the key of this.

[0371] public void setName(String newName)

[0372] Sets the name of this to newName.

[0373] public ActionType getActionType( )

[0374] Gets the actionType of this.

[0375] public void setActionType(ActionType newActionType)

[0376] Sets the actionType of this to newActionType.

[0377] public String getRelationFunctionName( )

[0378] Gets the name of the relation function that is to be executed. The name is the logical name. The Run-time 162 may map the logical name to a physical implementation at run time.

[0379] public void setRelationFunctionName(String newRelationFunctionName)

[0380] Sets the name of the relation function that is to be executed to newRelationFunctionName.

[0381] public String getTargetRelationName( )

[0382] Gets the name of the relation that is to be acted upon. The name is the logical name. The Run-time 162 may map the logical name to a physical implementation at run time.

[0383] public void setTargetRelationName(String newTargetRelationName)

[0384] Sets the name of the relation that is to be acted upon to newTargetRelationName.

[0385] public Key getKey( )

[0386] Gets the key of this.

[0387] Run-Time Model 171 and Run-Time 162

[0388] Run-time Model 171 consists of Kernel, Application, and Session. FIG. 10 shows the Run-time Model described using the Unified Modeling Language (UML) notation. Run-time 162 consists of an instance of Kernel Class, a set of instances of Application Class, and a set of instances of Session Class.

[0389] Class Application

[0390] public String getVersion( );

[0391] Gets the version of this.

[0392] public void setVersion(String newVersion);

[0393] Sets the version of this to newVersion.

[0394] public String getName( );

[0395] Gets the name of this.

[0396] public void setName(String newName);

[0397] Sets the name of this to newName.

[0398] public void addRelationDefinition(RelationDefinition relationdefinition, String name);

[0399] Adds a relation definition to this.

[0400] public RelationDefinition getRelationDefinition(String name);

[0401] Gets a named relation definition.

[0402] public void dropRelationDefinition(String name);

[0403] Drops a relation definition.

[0404] public void addRelation(String relationName, String relationDefinitionName);

[0405] Adds a relation to this.

[0406] public Relation getRelation(String name);

[0407] Gets a relation.

[0408] public void dropRelation(String name);

[0409] Drops a relation.

[0410] public void addEvent(String relationName, String eventName, Event event);

[0411] Adds an event to this.

[0412] public void dropEvent(String relationName, String eventName);

[0413] Drops an event.

[0414] public Event getEvent(String relationName, String eventName);

[0415] Gets an event.

[0416] public void addEventHandler(String eventHandlerName, EventHandler event);

[0417] Adds an event handler to this.

[0418] public void dropEventHandler(String eventHandlerName);

[0419] Drops an event handler.

[0420] public Event getEventHandler(String eventHandlerName);

[0421] Gets an event handler.

[0422] public void addRelationFunctionDefinition( RelationFunctionDefinition relationFunctionDefinition, String name);

[0423] Adds a relation function definition to this.

[0424] public RelationFunctionDefinition getRelationFunctionDefinition(String name);

[0425] Gets a relation function definition.

[0426] public void dropRelationFunctionDefinition(String name);

[0427] Drops a relation function definition.

[0428] public void addRelationFunction(String relationName, String relationDefinitionName);

[0429] Adds a relation function to this.

[0430] public RelationFunction getRelationFunction(String relationFunctionName);

[0431] Gets a relation function.

[0432] public void dropRelationFunction(String name);

[0433] Drops a relation function.

[0434] public void addThingDefinition(String thingDefinitionName, ThingDefinition keyDefinition);

[0435] Adds a thing definition to this.

[0436] public void dropThingDefinition(String thingDefinitionName);

[0437] Drops a thing definition.

[0438] public Event getThingDefinition(String thingDefinitionName);

[0439] Gets a thing definition.

[0440] public void addKeyDefinition(String keyDefinitionName, KeyDefinition keyDefinition);

[0441] Adds a key definition to this.

[0442] public void dropKeyDefinition(String keyDefinitionName);

[0443] Drops a key definition.

[0444] public Thing getKeyDefinition(String keyDefinitionName);

[0445] Gets a key definition.

[0446] public void addFactDefinition(String factDefinitionName, FactDefinition factDefinition);

[0447] Adds a fact definition to this.

[0448] public void dropFactDefinition(String factDefinitionName);

[0449] Drops a fact definition.

[0450] public FactDefinition getFactDefinition(String factDefinitionName);

[0451] Gets a fact definition.

[0452] public void addReferenceDefinition(String referenceDefinitionName, ReferenceDefinition referenceDefinition)

[0453] Adds a reference definition.

[0454] public void dropReferenceDefinition(String referenceDefinitionName);

[0455] Drops a reference definition.

[0456] public ReferenceDefinition getReferenceDefinition(String referenceDefinitionName);

[0457] Gets a reference definition.

[0458] public void startTransaction( );

[0459] Starts a transaction.

[0460] public void commitTransaction( );

[0461] Commits a transaction.

[0462] public void rollbackTransaction( );

[0463] Rollbacks a transaction.

[0464] public Relation execute(String relationFunctionName);

[0465] Executes a relation function.

[0466] public Key getKey( );

[0467] Gets the key of this.

[0468] Class Session

[0469] public Application getApplication( );

[0470] Loads an application to this.

[0471] public Key getKey( )

[0472] Gets the key of this.

[0473] Class Kernel

[0474] public void addUser(String userName, String password);

[0475] Adds a user to this.

[0476] public void dropUser(String userName);

[0477] Drops a user.

[0478] public void grant(String touser, String appName);

[0479] Grants access privilege to a user for an application.

[0480] public Session connect(String userName, String password, String appName);

[0481] Opens a session to an application.

[0482] public void removeSession(Key key);

[0483] Closes a session.

[0484] public Key loadApplication(File applicationDefinition);

[0485] Loads an application to this.

[0486] public void unloadApplication(Key key);

[0487] Unloads an application.

[0488] public Key getKey( );

[0489] Gets the key of this.

[0490] The network adapter 145 facilitates communication between the electronic device 110 and the network 120. The network adapter 145 provides the electronic device 110 with a means of electronically communicating information with a remote electronic device, not shown. In addition, in another embodiment, the network adapter 145 may support distributed processing, which enables the electronic device 110 to share a task with other devices linked to the network 120. Although the network adapter 145 is shown as part of the electronic device 110, in another embodiment they may be packaged separately. Although only one network adapter 145 is shown, in other embodiments multiple network adapters of the same or of a variety of types may be present.

[0491] The input device 150 is that part of the electronic device 110 that accepts input from a user. In an embodiment, the input device 150 may be a keyboard, but in other embodiments, the input device 150 may be a pointing device, mouse, trackball, keypad, touchpad, touch screen, pointing stick, microphone, or any other appropriate input device. Although only one input device 150 is shown, in other embodiments any number of input devices of the same or of a variety of types may be present. In another embodiment, the input device 150 may not be present.

[0492] The output device 155 communicates information to the user of the electronic device 110. The output device 155 may be a cathode-ray tube (CRT) based video display well known in the art. But, in other embodiments the output device 155 may be replaced with a liquid crystal display (LCD) based or gas, plasma-based, flat-panel display. In still other embodiments, any appropriate display device may be used. In yet other embodiments, a speaker that produces audio output may be used. Although only one output device 155 is shown, in other embodiments, any number of output devices of different types or of the same type may be present. In other embodiments, the output device 155 might not be present.

[0493] The bus 180 may represent one or more busses (e.g., PCI, ISA (Industry Standard Architecture), X-Bus, EISA (Extended Industry Standard Architecture), or any other appropriate bus and/or bridge (also called a bus controller).

[0494] The electronic device 110 may be implemented using any suitable hardware and/or software, such as a personal computer or other electronic computing device. Portable computers, laptop or notebook computers, and mainframe computers are examples of other possible configurations of the electronic device 110. The hardware and software depicted in FIG. 1 may vary for specific applications and may include more or fewer elements than those depicted. For example, other peripheral devices such as audio adapters, or chip programming devices, such as EPROM (Erasable Programmable Read-Only Memory) programming devices may be used in addition to or in place of the hardware already depicted. Thus, an embodiment of the invention may apply to any hardware configuration that supports a Meta Model 160, Run-time 162, and Application 161.

[0495] As will be described in detail below, aspects of an embodiment pertain to specific apparatus and method elements implementable on electronic devices. In another embodiment, the invention may be implemented as a program product for use with an electronic device. The programs defining the functions of this embodiment may be delivered to an electronic device via a variety of signal-bearing media, which include, but are not limited to:

[0496] (1) information permanently stored on a non-rewriteable storage medium (e.g., read-only memory devices attached to or within an electronic device, such as a CD-ROM readable by a CD-ROM drive);

[0497] (2) alterable information stored on a rewriteable storage medium (e.g., a hard disk drive or diskette); or

[0498] (3) information conveyed to an electronic device by a communications medium, such as through a computer or telephone network accessed via network adapter 145, including wireless communications.

[0499] Such signal-bearing media, when carrying machine-readable instructions that direct the functions of the present invention, represent embodiments of the present invention.

[0500] FIG. 2 depicts a block diagram of a Relation Function, according to an embodiment of the invention. The Relation Function comprises an object-oriented representation of actions, queries, rules, constraints, or functions. The Relation Function receives a set, or array, of Relations as input and returns a Relation as output. The Relation Function can implement a query, an algorithm, a rule, a constraint, or a function.

[0501] FIG. 3 depicts a block diagram of how new knowledge is derived from existing knowledge, according to an embodiment of the invention. The relation function F represents an algorithm to calculate or derive new facts that is returned in relation R.

[0502] FIG. 4 depicts a block diagram of how Relation Functions and Relations form a closed algebra, according to an embodiment of the invention. A Relation Function can be substituted for a relation and vice versa.

[0503] FIG. 5 depicts a block diagram of the relationship between the Event, Event Handler, and Relation Function, according to an embodiment of the invention. A relation can have events. An event has an event handler. An event handler has a relation function, an action, and a target relation. The action is the operation between the output of the relation function and the target relation.

[0504] FIG. 6 depicts a block diagram of a recursive event, according to an embodiment of the invention. A recursive event modifies the relation that generated the event. Recursion ends when the calculated relation is empty.

[0505] FIG. 7 depicts a UML representation of the Meta Knowledge Model 165, according to an embodiment of the invention.

[0506] FIG. 8 depicts a UML representation of the Meta Logic Model 166, according to an embodiment of the invention.

[0507] FIG. 9 depicts a UML representation of the Knowledge Definition Model 167, according to an embodiment of the invention.

[0508] FIG. 10 depicts a UML representation of the Run-time Model 171, according to an embodiment of the invention.

[0509] FIG. 11 depicts a UML representation of the Catalog Model 169, according to an embodiment of the invention.

[0510] FIG. 12 depicts a LML representation of a SYS_Catalog, according to an embodiment of the invention. SYS_Catalog is the root relation that stores all other relations. An instance of SYS_Catalog is created by the kernel automatically.

[0511] FIG. 13 depicts a UML representation of SYS_App and SYS_AppKnowledge, according to an embodiment of the invention. SYS_App is a root relation of the Application Catalog.

[0512] FIG. 14 depicts a UML representation of SYS_AppSessionKnowledge and SessionKnowledge, according to an embodiment of the invention. SYS_AppSessionKnowledge is the root relation of session specific knowledge. SYS_AppSessionKnowledge and the relations contained in it form the Session Catalog. An instance of a session catalog is created for each session. Session catalog is destroyed when user closes the session or when the session expires.

[0513] FIG. 15 depicts a UML representation of SYS_AppRelation, according to an embodiment of the invention. SYS_AppRelation is a relation that stores application scope relations

[0514] FIG. 16 depicts a UML representation of SYS_AppEvent, according to an embodiment of the invention. SYS_AppEvent is a relation that stores application scope events.

[0515] FIG. 17 depicts a UML representation of SYS_AppEventHandler, according to an embodiment of the invention. SYS_AppEventHandler is a relation that stores application scope event handlers.

[0516] FIG. 18 depicts a UML representation of SYS_AppRelationEvent, according to an embodiment of the invention. SYS_AppRelationEvent is the relation of that stores the events of application scope relations.

[0517] FIG. 19 depicts a UML representation of SYS_KeyDefinition, according to an embodiment of the invention. SYS KeyDefinition is a relation that stores the definitions of application keys.

[0518] FIG. 20 depicts a UML representation of SYS_ThingDefinition, according to an embodiment of the invention. SYS_ThingDefinition is a relation that stores the definitions of application things.

[0519] FIG. 21 depicts a UML representation of SYS_ReferenceDefinition, according to an embodiment of the invention. SYS_ReferenceDefinition is a relation that stores the definitions of application references.

[0520] FIG. 22 depicts a UML representation of SYS_RelationDefinition, according to an embodiment of the invention. SYS_RelationDefinition is a relation that stores the definitions of application relations.

[0521] FIG. 23 depicts a UML representation of SYS_RelationFunctionDefinition, according to an embodiment of the invention. SYS_RelationFunctionDefinition is a relation that stores the definitions of application relation functions.

[0522] FIG. 24 depicts a UML representation of SYS_FactDefinition, according to an embodiment of the invention. SYS_FactDefinition is a relation that stores the definitions of application facts.

[0523] FIG. 25 depicts a UML representation of SYS_SessionRelation, according to an embodiment of the invention. SYS_SessionRelation is the root relation of all session scope relations.

[0524] FIG. 26 depicts a UML representation of SYS_SessionEvent, according to an embodiment of the invention. SYS_SessionEvent is the root relation of all session scope events.

[0525] FIG. 27 depicts a UML representation of SYS_SessionEventHandler, according to an embodiment of the invention. SYS_SessionEventHandler is the root relation of all session scope event handlers.

[0526] FIG. 28 depicts a UML representation of SYS_SessionRelationEvent, according to an embodiment of the invention. SYS_SessionRelationEvent is the relation of that stores the events of a session relation.

Claims

1. A Meta Model for building a knowledge-oriented software application using an object-oriented programming language, the Meta Model comprising: a Meta Knowledge Model comprising a specification of how the knowledge-oriented software application represents knowledge; a Meta Logic Model comprising a specification of how the knowledge-oriented software application derives new knowledge; a Knowledge Definition Model comprising a specification of how the knowledge-oriented software application is converted from a human-readable format to executable code; a Catalog Model comprising a specification of how the knowledge-oriented software application organizes the knowledge within an electronic device; and a Run-time Model comprising a specification of how the knowledge-oriented software application enables concurrent clients to manipulate the knowledge stored in the electronic device.

2. The Meta Model of claim 1, wherein the Meta Knowledge Model further comprises a Thing, a Key, a Fact, a Relation, and a Knowledge Definition.

3. The Meta Model of claim 2, wherein the Thing comprises an object-oriented representation of a named object.

4. The Meta Model of claim 2, wherein the Key comprises an object-oriented representation of a name of the Thing.

5. The Meta model of claim 2, wherein the Fact comprises an object-oriented representation of facts regarding a set of things.

6. The Meta Model of claim 2, wherein the Relation further comprises an object-oriented representation of a set of facts.

7. The Meta Model of claim 2, wherein the Knowledge Definition Model further comprises an object oriented representation of a function for converting elements of the Meta Model to an implementation.

8. The Meta Model of claim 1, wherein the Meta Logic Model further comprises an Event, an Event Handler, and a Relation Function.

9. The Meta Logic Model of claim 8, wherein the Event comprises an object-oriented representation of functions selected from a group consisting of: adding, editing, modifying, and dropping a Relation.

10. The Meta Model of claim 8, wherein the Event Handler comprises an object oriented representation of responses to the Event.

11. The Meta Model of claim 8, wherein the Relation Function comprises an object-oriented representation of actions.

12. The Meta Model of claim 8, wherein the Relation Function comprises an object-oriented representation of queries.

13. The Meta Model of claim 8, wherein the Relation Function comprises an object-oriented representation of functions.

14. The Meta Model of claim 8, wherein the Relation Function receives a set of Relations as input and ret urn s a Relation as output.

15. A signal-bearing medium bearing a Meta Model comprising: a Meta Logic Model comprising an Event, an Event handler, and a Relation Function; a Meta Knowledge Model comprising a Thing, a Key, a Fact, a Relation, and a Knowledge Definition; a Knowledge Definition Model comprising a model for binding the Thing and its subtypes to a computer program; a Catalog Model comprising a set of classes that are subclasses of the Relation, and wherein the Catalog Model indexes a set of knowledge definitions that are instances of subclasses of the Knowledge Definition Model; and a Run-time Model comprising a set of classes that are subclasses of the Thing, whrein the Run-time Model dynamically binds the knowledge definitions to a physical implementation.

16. The signal-bearing medium of claim 15, wherein the Knowledge Definition Model further comprises a model for binding the Key and its subtypes, the Relation and its subtypes, the Fact and its subtypes, the Event and its subtypes, the Event Handler and its subtypes, and the Relation Function and its subtypes to the computer program.

17. The signal-bearing medium of claim 15, wherein the Knowledge Definition Model further comprises a Knowledge Definition and its subtypes.

18. The signal-bearing medium of claim 16, where the Knowledge Definition subtypes comprise a Thing Definition, a Key Definition, a Fact Definition, a Relation Definition, a Reference Definition, and a Relation Function Definition.

19. The signal-bearing medium of claim 18, wherein the Thing Definition comprises a logical name for the Thing and a name of a programming language class that implements the Thing.

20. The signal-bearing medium of claim 18, wherein the Key Definition comprises a logical name for the Key and a name of a programming language class that implements the Key.

21. The signal-bearing medium of claim 18, wherein the Fact Definition comprises a logical name for the Fact and a name of a programming language class that implements the Fact.

22. The signal-bearing medium of claim 18, where the Relation Definition comprises a logical name for the Relation and a name of a programming language class that implements the Relation.

23. The signal-bearing medium of claim 18, where the Relation Function Definition comprises a logical name for the Relation Function and a name of a programming language class that implements the Relation Function.

24. The signal-bearing medium of claim 18, wherein the Catalog Model comprises a model for storing a declarative definition of an application and the application's run-time data.

25. The signal-bearing medium of claim 24, wherein the Catalog Model further comprising a set of classes that are subclasses of the Thing, Key, Relation, Fact, and Knowledge Definition.

26. The signal-bearing medium of claim 24, wherein the Run-time Model comprises a Session, a Kernel, and subtypes of an Application.

27. The signal-bearing medium of claim 24, wherein the Application comprises an object oriented definition of how the application can be accessed by a computer program that uses the services of the application.

28. The signal-bearing medium of claim 25, wherein the Session comprises an object oriented definition of how the application can be accessed by concurrent users.

29. The signal-bearing medium of claim 26, wherein the Kernel comprises an object-oriented definition of how multiple applications can be managed and accessed by multiple users.

30. An electronic device comprising: a processor; and a storage device comprising: a Meta Knowledge Model comprising a specification of how a knowledge-oriented software application represents knowledge, a Meta Logic Model comprising a specification of how the knowledge-oriented software application derives new knowledge, a Meta Knowledge Model comprising a Thing, a Key, a Fact, a Relation, and a Knowledge Definition, wherein the Thing comprises an abstract base Thing class with a method for retrieving a key of a Thing instance, wherein the key comprises a unique identifier, a Knowledge Definition Model comprising a specification of how the knowledge-oriented software application is converted from a human-readable format to executable code, a Catalog Model comprising a specification of how the knowledge-oriented software application organizes the knowledge within an electronic device, and a Run-time Model comprising instructions that execute on the processor.

31. The electronic device of claim 30, wherein the Thing comprises a static Thing Definition object that defines its physical implementation.

32. The electronic device of claim 31, wherein the Thing is extendible to create application-specific Thing classes and wherein the Thing class is a base class for all domain-specific object classes.

33. The electronic device of claim 30, wherein the Key comprises an abstract base type and a StringKey, a DateKey and a IntegerKey are sub types of the Key.

34. The electronic device of claim 33, wherein the StringKey creates the Key from a string and wherein the StringKey comprises a method to get a string value of a string key.

35. The electronic device of claim 33, wherein the IntegerKey creates the Key from an integer and wherein the IntegerKey comprises a method to get an integer value of an integer key.

36. The electronic device of claim 33, wherein the DateKey creates the Key from a date and wherein the DateKey comprises a method to get a date value of a date key, and wherein the Key is extendible to create other types of keys.

37. The electronic device of claim 30, where the Fact is a sub type of the Thing.

38. The electronic device of claim 30, wherein the Fact is as an abstract base type.

39. The electronic device of claim 30, wherein the Fact is a set of the Things, and wherein the Things can be gotten and updated by their ordinal numbers.

40. The electronic device of claim 30, wherein the Fact is a set of the Things, and wherein the Things can be gotten and updated by their names.

41. The electronic device of claim 30, wherein an implementation of the Fact has a fixed cardinality.

42. The electronic device of claim 30, wherein the Fact has a Type and methods to get and set the Fact Type, wherein the Fact Type can be Simple, OneToOne, and ManyToOne.

43. The electronic device of claim 39, wherein the Things of the Fact can be gotten and set as an array of the Things.

44. A signal-bearing medium comprising a Meta Model for building a knowledge-oriented software application using an object-oriented programming language, wherein the Meta Model comprises: a Meta Knowledge Model including: a Thing comprising a specification of how the knowledge-oriented software application is represented as objects, wherein the Thing is the super class of the objects; a Key comprising a specification of how knowledge-oriented software application things are named, where the thing names are instances of classes that are subclasses of the Key and the things are instances of subclasses of the Thing; a Fact comprising a specification of how knowledge oriented software application represent facts, where the facts are instances of classes that are subclasses of the Fact and the Fact is a subclass of the Thing, a Relation comprising a specification of how the knowledge-oriented software application represents sets of similar facts, where all relations are instances of classes that are subclasses of the Relation, and the Relation is a subclass of Thing, and a Knowledge Definition comprising a specification of how the knowledge-oriented software application represents the logical design of the application and how it relates the logical design to a physical implementation, wherein the Knowledge Definition is a subclass of the Thing.

45. The signal-bearing medium of claim 44, wherein the Relation is a super type of the Thing.

46. The signal-bearing medium of claim 44, wherein the Relation is as an abstract base type.

47. The signal-bearing medium of claim 44, wherein the Relation is a set of named Facts.

48. The signal-bearing medium of claim 44, wherein the Relation has a Relation Scope.

49. The signal-bearing medium of claim 44, wherein the Relation has methods to get and set the Relation Scope.

50. The signal-bearing medium of claim 48, wherein the Relation Scope comprises an Application and a Session.

51. The signal-bearing medium of claim 44, where each instance of the Relation comprises a name, and wherein the Relation has methods to get and set the name.

52. The signal-bearing medium of claim 44, wherein the Relation comprises methods to retrieve, insert, delete, and update facts of the Relation.

53. The signal-bearing medium of claim 44, wherein Relation has methods to find the union, intersections, and the difference of two relations.

54. The signal-bearing medium of claim 44, wherein the Relation comprises a method to determine whether a fact is contained within a relation.

55. The signal-bearing medium of claim 44, wherein the Relation comprises a method to get the number of facts in a relation.

56. The signal-bearing medium of claim 44, wherein the Relation comprises a method to return all the facts as an array.

57. The signal-bearing medium of claim 44, wherein the Knowledge Definition is a sub type of the Thing.

58. The signal-bearing medium of claim 44, wherein the Knowledge Definition is an abstract base type.

59. The signal-bearing medium of claim 44, wherein the Knowledge Definition has a name, and wherein the Knowledge Definition comprises a method to get and set the name.

60. The signal-bearing medium of claim 44, wherein the Knowledge Definition comprises a logical and physical representation of a Thing.

61. A signal-bearing medium comprising a Meta Model for computer programs implemented in an object-oriented programming language, the Meta Model comprising: a Meta Knowledge Model comprising a Thing, a Key, a Fact, a Relation, and a Knowledge Definition; and a Meta Logic Model comprising an Event, an Event Handler, and a Relation Function, wherein the Event is a sub type of the Thing.

62. The signal-bearing medium of claim 61, wherein the Event has a name, and wherein the Event has methods to get and set the name.

63. The signal-bearing medium of claim 61, wherein the Event has a Level and wherein the Event has methods to get and set the Event Level, and wherein the Event Level can be selected from a group consisting of: the Relation and the Fact.

64. The signal-bearing medium of claim 61, wherein the Event has a Priority, and wherein the Event has methods to get and set the Event Priority.

65. The signal-bearing medium of claim 61, wherein the Event has a Scope, and wherein the Event has methods to get and set the Event Scope, and wherein the Event Scope can be selected from a group consisting of: an Application or a Session.

66. The signal-bearing medium of claim 61, wherein the Event has a Type, wherein the Event has methods to get and set the Event Type, and wherein the Event Type can be selected from a group consisting of: On Insert, On Delete, On Update, On Add, and On Drop.

67. The signal-bearing medium of claim 61, wherein the Event has methods to get and set the Event Handler.

68. The signal-bearing medium of claim 61, wherein the Event Handler comprises a sub type of the Thing.

69. The signal-bearing medium of claim 61, wherein the Event Handler comprises: a name; and methods to get and set the name.

70. The signal-bearing medium of claim 61, wherein the Event Handler comprises: a relation function; and methods to get and set a name of the relation function.

71. The signal-bearing medium of claim 61, wherein the Event Handler comprises: a target relation; and methods to get and set a name of the target relation.

72. The signal-bearing medium of claim 61, wherein the Event Handler comprises: a n action type; and methods to get and set the action type, wherein the action type is selected from a group consisting of: Clear, Add, Drop, Replace, Insert, Delete, and Update.

73. The signal-bearing medium of claim 61, wherein the Relation Function is a super type of the Thing.

74. The signal-bearing medium of claim 61, wherein the Relation Function comprises: a name; and methods to get and set the name.

75. The signal-bearing medium of claim 61, wherein the Relation Function has an argument and the argument is an array of the Relations.

76. The signal-bearing medium of claim 61, wherein the Relation Function has a return value and the return value is a Relation.

77. The signal-bearing medium of claim 61, wherein the Relation Function defines a method to execute.

78. The signal-bearing medium of claim 61, wherein the Relation Function and the Relation form a closed algebra, wherein the Relation Function returns only a relation, and wherein the Relation Function can be used as an argument anywhere a Relation can be used as an argument.

79. The signal-bearing medium of claim 61, wherein the Relation Function is recursive, wherein an output of the Relation Function is an input of the Relation Function, and wherein the Relation Function terminates when an output Relation is empty.

80. A signal-bearing medium comprising: a Meta Model for computer programs implemented in an object-oriented programming language, the Meta Model comprising: a Meta Knowledge Model comprising a Thing, a Key, a Fact, a Relation, and a Knowledge Definition, and a Meta Logic Model comprising an Event, an Event Handler, and a Relation Function; and a Kernel, wherein the Kernel is a super type of the Thing.

81. The signal-bearing medium of claim 80, wherein the Kernel comprises a system Application that manages external applications.

82. The signal-bearing medium of claim 80, wherein the Kernel comprises a name and methods to get and set the name.

83. The signal-bearing medium of claim 80, wherein the Kernel comprises a root object of all objects.

84. The signal-bearing medium of claim 80, wherein the Kernel has a number of users and methods to add and drop users identified by their names and passwords.

85. The signal-bearing medium of claim 80, wherein the Kernel grants access to Applications and wherein the Kernel comprises methods to grant privileges to users.

86. The signal-bearing medium of claim 80, wherein the Kernel has multiple concurrent users, wherein each of the users has multiple sessions, and wherein the Kernel comprises methods to create, get, and drop named sessions.

87. The signal-bearing medium of claim 80, wherein the Kernel comprises methods to load and unload an Application.

88. The signal-bearing medium of claim 80, wherein the Kernel loads an application from an Application Definition File.

89. The signal-bearing medium of claim 80, wherein the signal-bearing medium further comprises an Application.

90. The signal-bearing medium of claim 89, wherein the Application is a sub type of the Thing.

91. The signal-bearing medium of claim 89, wherein the Application has a version and the Application has methods to get and set the version.

92. The signal-bearing medium of claim 89, wherein the Application has a name and the Application has methods to get and set the name.

93. The signal-bearing medium of claim 89, wherein the Application has a set of Relation Definition instances and the Application has methods to add, get, and drop the Relation Definition instances.

94. The signal-bearing medium of claim 89, wherein the Application has a set of Relation instances and the Application has methods to add, get, and drop the Relation instances.

95. The signal-bearing medium of claim 89, wherein the Application has a set of Relation Function Definition instances and the Application has methods to add, get, and drop the Relation Function Definition instances.

96. The signal-bearing medium of claim 89, wherein the Application has a set of Relation Function instances and the Application has methods to add, get, and drop the Relation Function instances.

97. The signal-bearing medium of claim 89, wherein the Application has a set of Event instances and the Application has methods to add, get, and drop the Event instances.

98. The signal-bearing medium of claim 89, wherein the Application has a set of Event Handler instances and the Application has methods to add, get, and drop the Event Handler instances.

99. The signal-bearing medium of claim 89, wherein the Application has a set of Thing Definition instances and the Application has methods to add, get, and drop the Thing Definition instances.

100. The signal-bearing medium of claim 80, wherein the Kernel enforces type safety.

101. The signal-bearing medium of claim 100, wherein when a relation, relation function, thing, key, and fact are created and referenced, the Kernel enforces the type specified in a corresponding knowledge definition.

102. The signal-bearing medium of claim 80, wherein the Kernel enforces referential integrity.

103. The signal-bearing medium of claim 102, where when a relation, relation function, thing, key, and fact are referenced by the key, the Kernel enforces that an object referenced by the key exists in the relation specified by the key's reference definition.

104. The signal-bearing medium of claim 89, wherein the Application manages a transaction, wherein a transaction comprises a change in a state of a relation.

105. The signal-bearing medium of claim 104, wherein the Application has a method to start the transaction.

106. The signal-bearing medium of claim 104, wherein the Application has a method to commit the transaction.

107. The signal-bearing medium of claim 104, wherein the Application has a method to rollback the transaction.

108. The signal-bearing medium of claim 104, wherein the Application has a method to execute the Relation Function and return a result as a relation.

109. The signal-bearing medium of claim 104, wherein the Application rollbacks an external transaction when the external transaction fails.

110. The signal-bearing medium of claim 109, wherein the Application rollbacks an external transaction when a transaction of an event generated by the external transaction fails.

111. The signal-bearing medium of claim 109, wherein the Application commits the external transaction and the transactions generated by the events as a result of the external transaction.

112. The signal-bearing medium of claim 89, wherein the Application is persistently and declaratively stored in an Application Definition File.

113. The signal-bearing medium of claim 112, wherein a Kernel binds the Application Definition to a physical implementation at run time.

114. The signal-bearing medium of claim 80, wherein a Session is a sub type of the Thing.

115. The signal-bearing medium of claim 114, wherein the Session has a name and the Session has methods to get and set the name.

116. The signal-bearing medium of claim 114, wherein the Session has methods to access any Kernel application.

117. The signal-bearing medium of claim 114, wherein the Session has a time out and wherein the Kernel removes timed-out sessions automatically.

118. The signal-bearing medium of claim 114, wherein the Session has a state.