Ubik(ID:6313/ubi001)Generalised ACTORS systemPossibly for the Updike Character, or for Ubique (everywhere) Generlaisation of the actors model to support distributed knowledge objects References: Configurator Ubik is a system for developing business applications on a computer. Ubik provides a language for representing business concepts and actions, an environment for executing business applications, and facilities for maintenance of business applications software. The goal of Ubik is to raise the level of programming such that a non-programmer can directly define his applications on the computer, or a programmer can economically create applications which are currently not cost effective. To accomplish this goal. Ubik provides a language for representing business organizations and applications, and various software subsystems, which provide useful programming and reasoning facilities. A business organization is inherently concurrent and distributed. Ubik reflects this concurrency by being built using the Actor Mode| of concurrent, distributed processing. The Actor Model is built around a primitive object called an Actor. Each actor can execute in parallel with other actors. The actors communicate by sending and receiving messages asynchronously. The Message Passing Semantics Group at MIT has developed a series of languages based on the Actor Model. Pratt is the primitive actor language which closely reflects the message-passing semantics of the actor object. Acore is the core actor language which provides a higher ievel programming environment. Acore is a parallel programming language which unifies, in one language, the semantics of functional and object languages. Pratt and Acore are languages designed by Carl Manning. Ubik is an actor language based on unification, which supports both messagepassing and distributed knowledge-bases. Ubik consists of a basic computational object called the Ubik Configurator. It is built out of a more basic object called the primitive configurator, which in turn is build out of a collection of Actors. A primitive configurator consists of an actor with a script which evaluates the c0nfigurator language. This language provides a syntax for specifying configurators, a configurator creation facility, a unifier for matching configurators to patterns, and a basic sending and receiving facility which supports the transmitting of configurators as messages. The configurator creation facility provides a primitive inheritance facility. Using this facility, the full Ubik configurator is composed of the following primitive eonfigurators: 1. Handier - Provides the support for the reception of messages by a configurator. A handler contains a collection of patterns and actions. The patterns unify with the incoming messages. An action assocmted with a pattern carries out the organization's action. The handler can match the collection of patterns sequentially or in parallel. A serialized configurator will lock itself when taking action. 2. Batch - Provides support for the cyclic processing which occurs within business organizations. A handler can have AND expressions of patterns. An AND expression has multiple patterns which can match incoming messages. A partially matched AND expression is one m which some but nor all of its patterns are matched. The messages which make up the partially matched AND expression are queued in the batch until the AND expression is completely matched. 3. Model - Provides for the modeling of the structure and action of organizauons. A model consists of a lattice of configurators. Ubik supports multiple, distributed models. 4. Daemon - Provides for the monitoring, control, and change of organizational activity. An active configurator is one in which the handler attributes specify the events for which they are sent messages. An active configurator is supported bv embedding, within a model or another configurator, daemons which specify the message sending condition. Section 2 on handler taxonomies describes the active configurators in more detail. 5. Prototype - Provides for the creation of new configurators by using other configurators as prototypes. As an organization's structure and action changes over time. old prototypes representing the organization become inappropriate. Ubik wiil create new prototypes which better reflect the current state of the organization. A prototype can be used as a template in creating a new configurator. It can also be used to maintain multiple inheritance by delegating messages in parallel to the prototypes which make up the class structure of a configurator. 6. Sponsor - Provides focus for the actions of an organization. Actor systems generate much more potential parallelism then can be realized at any one time. Sponsors determine which configurators have priority. Extract: Handler taxonomy Handler taxonomy Active configurators are configurators whose handlers specify that they are to be sent messages when certain events occur. The specification is with tile use of handler attributes: use, installation, and operation. The use. installation, and operation attributes, along with their subattributes, define a taxonomy of behavior of the configurator in relation to its incoming message. The use attribute specifies how the message is to be sent to the handler. The use attributes are: receive, monitor, and censor. Receive specifies that the handler will receive a message. This is a handler's default behavior. Monitor specifies that if a specified event occurs within a model, this handler is to be sent a message. Censor is like monitor, except that an event can be prevented from being completed. The installation attribute specifies whether the history of an event's occurrence is considered when the monitor or censor is installed in a model. The commutative attribute specifies that a message will be sent if the event being monitored occurred before installation as well as after installation. The non-commutative attribute will be sent messages only for events which occur after installation. The notion of commutative comes from the scientific community metaphor [5], Commutativity deals with the problem of events and queries being distributed, such that in any one model an event can occur before a query arrives from a distributed model, or the query can arrive before the event takes place. Commutativity will produce equivalent results in either case. The operation attribute specifies which operations the handler is monitoring or censoring within a model. The operations are: insert, update, delete, query, and evaluate. In the Ubik language the operations are specified as @I, @D, @U, @Q, and @X respectively. Modern knowledge-base systems as Kee and GoldWorks use multiple types of high level objects to perform only some of the subfunctions which Ubik performs. By taking a unified approach to supporting the mechanisms of application development, Ubik simplifies the use of the mechanisms, and supports the use of combinations of the mechanisms. This is illustrated in Figure 2. A rule in a knowledge-base system is represented as a commutative monitor with operations insert, delete, or update in Ubik. The specification of variants of rules are natural within Ubik. For example a rule which operates only for insert operations is a commutative monitor with operation insert. When-modified. and when-referenced are the type of daemons typicaiiy supported in expert systems. When-recmved is a daemon unique to Ubik. It triggers when a configurator being monitored receives a message. It is similar to a phone tap or a very general function trace. in SIGPLAN Notices 24(04) April 1989 incoroporating Proceedings of the 1988 ACM SIGPLAN workshop on Object-based concurrent programming, San Diego view details in Lamersdorf, W. (ed) Office Knowledge: Representation, Management. and Utilization. North-Holland, 1988 view details in Lamersdorf, W. (ed) Office Knowledge: Representation, Management. and Utilization. North-Holland, 1988 view details in Concurrency: Practice and Experience 2000 v12 view details |