Yeast: A General Purpose EventAction System

1
Yeast A General Purpose Event-Action System

• by
• Balachander Krishnamurthy and David S. Rosenblum
• Presentation by Brian Castiaux
• CIS 6610 3/3/99

2
How does Yeast apply to Software Architecture?

• The architecture of the Yeast application is an
  example of an Event-Basted Implicit Invocation
  architecture.
• This paper goes into detail about the
  organization and construction of the Yeast
  application.
• This application is a prime example of the
  event-based architecture where all of the
  components interact based on events provided both
  by the environment and the components themselves.

3
An Event Action System

• An event-action system is a software system where
  events occurring in the environment of the system
  trigger actions in response to the events.
• Triggered actions may generate other events,
  which trigger other actions, and so on.
• Most existing event-action systems are
  special-purpose systems that support a particular
  domain.
• Examples include
• Tool integration systems, such as HP Softbench.
• Active databases such as ODE and AP5.
• Rule based development environments such as
  Marvel.
• Software process monitoring system such as
  Amadeus.

4
What does General Purpose mean?

• The system must be open, it has knowledge about
  the external events.
• There should be no restrictions on actions
  performed to the occurrence of user-specified
  event patterns.
• The specification language for the system must be
  simple, yet powerful.
• The system must handle both temporal and
  non-temporal events.
• The system must be extensible in the sense that
  users can define new kinds of events to the
  system.
• The system must be reliable, with a state that
  persists across machine crashes.
• Users of the system must be able to interactively
  query the status of specifications they have
  registered with the system.
• User interactions with the system must be
  authenticated to ensure the security of the
  system and the privacy of user interactions.

5
Yeast (Yet another Event-Action Specification
Tool)

• This paper discusses the details of the system
  called Yeast. This system attempts to satisfy
  these general purpose requirements.
• Yeast is general purpose platform for
  constructing distributed event-action
  applications.
• This system is implemented with a high level
  event-application specification language.
• This system is similar to the domain specific
  examples that were discussed, but this system
  also implements the ability to have user-defined
  events as well as user-defined objects.

6
Architecture of the Yeast System
Client commands
User Process
Server Process
Command Interpreter
Specification action
Information
Action Output
diagnostics
Specification Database
User Mailbox
Announced Event Table
Object Definition Database
Polled Event Queue
7
Yeast Architecture Breakdown

• User Process - Process requesting Yeast services
  and providing user-defined events and objects.
• Server Process - Manages Specifications from the
  user process.
• Command Interpreter - Executes the actions
  defined in the specifications. This execution of
  action is controlled by the server.
• Specification Database - Stores specification
  data as defined by users.
• Object Definition Database - Stores object
  information.
• Polled Event Queue - Stores predefined event
  specification in the order that the server is
  looking (polling) for them.
• Announced Event Table - Stores user-defined
  events, this table is searched for every
  user-defined event that the server processes.
• User Mailbox - Email system to report output and
  diagnostics to the user.

8
Yeast - Server Command Interpreter

• The central entity accepting commands from a
  number of (possibly remote) users, its primary
  function is to match and manages specifications
  on behalf of the users.
• Interfaces with the Client Process through a
  command interpreter. (such as a UNIX shell)
• Interaction with the user and server are
  synchronous and interactive.
• The Command Interpreter handles the execution of
  the commands, and it sends any output that is not
  directed to files or other commands to an
  electronic mailbox for the user.
• In addition to the Command Interpreter the Server
  also sends information to the mail box, this
  information includes problems, performance and
  other diagnostic data.

9
Yeast - Specifications

• Are comprised of an event pattern and an action.
• Each pattern is a made up of primitive event
  descriptors.
• The Action of a specification is any valid
  sequence of commands, including Yeast client
  commands. These commands are run on the Command
  Interpreter as soon as the event pattern has been
  matched.
• Primitive Events are low level monitor controls,
  the can match an event either transiently or
  permanently.
• Transiently - an event descriptor could match
  when the load on a particular processor reaches a
  specific level. Only matches while at that
  level.
• Permanently - specify and event descriptor to
  match based on a specific time, any time after
  the specified time is still a match.

10
Types of Primitive Events.

• Time Events Object Events
• time event involve clock times, dates, etc.
• object events involve non-temporal objects.
• Predefined User-Defined Events
• Predefined events are automatically detected by
  the server.
• Predefined events are defined over objects that
  the server can poll, they are both time events
  and object events.
• User Defined events must be announced the server
  by the user or by some application.
• The server has no information about the semantics
  of User-Defined events and cannot detect these
  events automatically. All User-Defined events
  involve user-defined attributes of user-defined
  or predefined objects, thus all of these events
  are object events

11
The Yeast Specification Language

• The specification language has the following
  syntax event_pattern do action
• Event_pattern can contains primitive event
  descriptors formed using the connectors then,
  and, or.
• Types of event descriptors
• Time Event Descriptors - Time events can match
  the passage of relative time, or of the
  occurrence of an absolute time.
• Object Event Descriptors - These events test an
  attribute of the defined object, the can test for
  any change or for a specific value.
• Compound Event Descriptors - Are simply a
  combination of base event descriptors, and they
  can even combine time and object events.

12
Time Event Descriptors

• Relative time.
• Specified by keywords in and within.
• in 2 hours 10 minutes
• within 6 days 10 hours
• Absolute time
• Specified by keywords at and by.
• at 8am
• by 8am Saturday
• Absolute time events can have modifiers.
• daily, today, tomorrow, weekly, monthly, yearly
• by 10pm today.
• at 8am daily
• at 8am 31 monthly

13
Object Event Descriptors

• Object event descriptors specify a relational
  test on an attribute of an object. With the
  syntax obj_class obj_name obj_attr
  relational_test
• obj_class and obj_attr must be predefined or else
  the must be defined to Yeast using the defobj and
  defattr commands.
• The relational_test has the special values
  changed and unchanged
• file foo mtime changed
• defobj obj_class. This is a client command that
  informs the server of a user-defined object of
  class obj_class.
• defobj tool
• defattr obj_class obj_attr obj_type. Is the
  client command that informs the server of a new
  attribute obj_attr defined for the class
  obj_class and the attribute is of the type
  obj_type.
• defattr tool debugged boolean.

14
Object Classes and Attributes
15
Object Classes and Attributes (cont)
16
Compound Event Descriptors

• Descriptors joined with then, and, or. These
  are listed in the order of decreasing priority.
  Parentheses can also be used to enforce any
  desired groupings.
• Compound events can join both time and object
  events.
• File foo mtime changed then in 10 min do echo
  hello
• in 10 min and host research load gt 5.0

17
Actions

• Any valid sequence of commands that can be
  executed by the computers command interpreter.
• The syntax and semantic of actions are dependant
  upon the command interpreter.

18
Client Commands

• Addspec defines a specification to the server.
  Syntax addspec repeat
  group_name Yeast_spec
• repeat is the optional setting that will
  automatically reissue this specification after it
  has been run.
• group_name is a way of logically-relating
  specifications.
• Yeast_spec is the specification already
  discussed.
• announce informs the server of user-defined
  events. Syntax announce obj_class obj_name
  obj_attr attr_value
• example
• defattr file debugged boolean
• addspec file project.c debugged true do notify
  project.c debugged
• announce file project.c debugged true

19
Client Commands (cont)

• lsspec - shows the internal number Yeast has
  assigned to each specification.
• rmspec - removes a specification
• suspspec - suspends matching specifications
• fgspec - resumes matching specifications
• modgrp add and remove specifications from groups.
• lsobj - list all of the predefined and
  userdefined object classes.
• lsattr - list all of the attributes of an object
  class.
• rmobj - remove a user-defined class.
• rmattr - remove a user-defined attribute.
• Authobj and authattr gives the ability to give
  another user the rights to add objects and
  attributes. These commands have allow four levels
  of access read access, announce access, write
  access and owner access.

20
Example of a Yeast Application

• The authors developed a series of Yeast
  specifications to help automate portions of a
  software distribution process at ATT Bell Labs.
• Advsoft is responsible for gathering and
  distributing official versions of tools.
• Owners of tools submit there new versions in a
  set cycle, and this process handles the book
  keeping tasks of notifying all that are involved
  and recording the status of this new version.
• In the following figure, the Bold text signifies
  Yeast specifications that help automate this
  process.

21
Advsoft distribution process
Announcement of Failure
Fixes to tools libx depends on
Fix libx (libxs owner)
Distribute Approved System (advsoft)
Rebuild libx (advsoft)
Initiate Cycle
Fixed libs
Announcement of Rejection
Announcement of Success
Announcement of New Cycle
New libx
Approved libs
Prepare Enhansed T (Ts Ownwe)
Notify Owners Dependant on Libx
Test (Dep owners) (Yeast)
Approve T
Approve libx (advsoft)
Prepare Enhansed libx (libxs Ownwe)
Notification Mail to dependant owners
Approve T (advsoft)
Announcement of Acceptance
22
Yeast Specifications from Advsoft.

• Define the objects needed in advsoft
• defobj tool
• defattr tool accepted boolean
• defattr tool rebuilt boolean
• example of the rebuild spec.
• addspec repeat advsoft libx file
  /home/libx/BUILT mtime changed do announce tool
  libx rebuilt true
• addspec repeat advsoft libx file
  /home/libx/ERROR mtime changed do announce tool
  libx rebuilt false
• addspec repeat advsoft libx tool libx rebuilt
  true do Mail -s libx rebutil U1 U2

• Response to the libx rebuilt mail.
• Announce onwer Ui accepts libx
• Announce onwer Ui rejects libx
• these announcements partially automate the test
  process
• lastly is the automation of all acceptance.
• addspec repeat advsoft libx owner U1 accepts
  libx and owner U2 accepts libx and do Mail
  -s libx accepted advsoft Ulibx announce tool
  libx accepted true

23
Conclusion - Strengths
The authors Listed there opinion on how well the
met the general purpose requirements that they
set out in the beginning of the paper.

• Yeast provides a rich specification language that
  supports specification and matching of patterns
  of both temporal and non-temporal events.
• Yeasts support for class and attribute
  definition and event announcement allows the
  users to extend the event-matching capabilities
  of Yeast.
• This implementation of Yeast attains reliability
  and fault tolerance at the software level. (Much
  of this is implemented in the Specification
  Database and Object Database).
• Yeast supports a rich collection of client
  commands that allow users to interactively query
  and manage the status of there specifications.

24
Conclusions - Weaknesses

• The current dependence of Yeast on the UNIX
  KornShell.
• Another weakness is the level of support for
  user-defined events. Yeast has no support for
  forcing the semantics of user-defined events.
• A planned enhancement is to include persistence
  of announcements, static analysis of
  specifications and the addition of variables to
  the specification language.
• A graphical interface has been added to Yeast in
  response to many user requests.