%---------------------------------------------------------------------

%
%	title page with logo
%

\begin{slide}{}
\setcounter{slide}{1}

\Mytitle{Global Event Model Ideas\\Adam Rifkin --- October 27, 1997}

\begin{itemize}

\item Two Examples.
\begin{itemize}
\item Room/Floor/Building Security.
\item An ``Active Document'' for a Budget.
\end{itemize}

\item Local Event Models.
\begin{itemize}
\item JavaBeans.
\item Compare with Infospheres, CORBA, Multicast.
\end{itemize}

\item Global Event Model.
\begin{itemize}
\item Compositional Structure.
\item Specification Notation.
\item Predicates.
\item Soft Real Time.
\item Fault Tolerance.
\item Exceptions.
\end{itemize}

\end{itemize}

\vspace*{\fill}		% prevent (?) vertical centering
\end{slide}

%---------------------------------------------------------------------

\begin{slide}{}

\Mytitle{Example: Room/Floor/Building Security}

\begin{itemize}

\item Predicates for rooms.

\item Predicates for floors composed by the predicates for the rooms.

\item Predicates for the building composed by the predicates for the floors.

\end{itemize}

\vspace*{\fill}		% prevent (?) vertical centering
\end{slide}

%---------------------------------------------------------------------

\begin{slide}{}

\Mytitle{Example: An ``Active Document'' for a Budget}

\begin{itemize}

\item A document where different people have different views based on
relative importance to the document.

\item Each view allows different manipulations of the document.

\end{itemize}

\vspace*{\fill}		% prevent (?) vertical centering
\end{slide}

%---------------------------------------------------------------------

\begin{slide}{}

\Mytitle{Components}

\begin{itemize}

\item Components of Components.
\begin{itemize}
\item Properties, which are broadcastable variables.
\item Events, which are messages that announce property changes.
\item Like objects, attributes and methods for doing stuff.
\end{itemize}

\item JavaBeans is a component model implemented in Java.
JavaBeans represents the culmination of years of event work, from 
operating systems and GUIs to CORBA and OpenDoc.  And yet, even now
events are distributed only locally within a single beanbox on a single
machine --- in other words, they are not distributed at all.

\item Operational model: Components consist of types, variables,
properties, event targets, and event sources.  Communication happens
through events. Delete, add, listeners, methods, beans.

\end{itemize}

\vspace*{\fill}		% prevent (?) vertical centering
\end{slide}

%---------------------------------------------------------------------

\begin{slide}{}

\Mytitle{Properties}

\begin{itemize}

\item A {\em property\/} is an attribute name (and corresponding value)
that represents a single piece of data that affects its component's
appearance or behavior.

\item When the value of a {\em bound property\/} changes, the component
owning the property sends out a notification message to all of the
components that have expressed interest in the property.  This is called
a {\em change notification service}.

\item A {\em constrained property\/} is similar to a bound property,
except that other components can veto a change to that property value.

\item Conceptually, an event is any meaningful occurrence.  For example,
{\tt PropertyChangeevent} occurs whenever a property value changes (as
in, a mouse moves).

\item A {\em property editor\/} allows developers to change the value of
a component property through a nice visual interface.

\item A {\em property sheet\/} visually displays all of a component's
properties, each of which is supported by a corresponding property
editor.

\end{itemize}

\vspace*{\fill}		% prevent (?) vertical centering
\end{slide}

%---------------------------------------------------------------------

\begin{slide}{}

\Mytitle{Events}

\begin{itemize}

\item {\em Events\/} are the mechanism by which a component informs other
components that something interesting has happened.  Think of them as
active messages.

\item For example, a button is pressed at a source, and channeled
through an event listener, to automatically trigger a method in an event
observer.

\item An {\em event\/} is immutable and does not usually change as it
propogates from an event source through an event listener (also called
an event notifier) to one or more event observers (also called event
targets).

\item A {\em framework\/} (such as JavaStudio) can associate the events
that a component fides with methods in other components.

\item {\em Introspection\/} is the process of discovering a component's
properties, methods, and events at runtime.

\item {\em Persistence\/} is the saving of internal state.
\end{itemize}

\vspace*{\fill}		% prevent (?) vertical centering

\end{slide}

%---------------------------------------------------------------------

\begin{slide}{}

\Mytitle{Event Sources}

\begin{itemize}

\item An {\em event source\/} triggers an event state object when its
internal state changes, usually as a result of some external stimulus.

\item An event source delivers an event to a list of listeners
sequentially using its own thread.  It has methods such as {\tt
addListener} and {\tt removeListener}.

\item An event source must catch and handle all of the exceptions raised
when it calls listeners.

\item JavaBeans permits event sources to define their own delivery-order
semantics to event listeners.

\end{itemize}

\vspace*{\fill}		% prevent (?) vertical centering
\end{slide}

%---------------------------------------------------------------------

\begin{slide}{}

\Mytitle{Event Listeners}

\begin{itemize}

\item An {\em event listener\/} is a callback object that serves as a
bridge between an event source and a consumer of events.  A listener may
encapsulate a number of semantically related methods.

\item An event listener allows the application-specific code to be
localized in one or more {\em event observers}.

\item Potential uses of event listeners:
\begin{enumerate}
\item Implement event queues for observers.
\item Filter events before they reach observers.
\item Demultiplex multiple event sources into a single notifier.
\end{enumerate}

\item JavaBeans cleanly separates GUI code from the event handling code,
which resides in the event observer.

\end{itemize}

\vspace*{\fill}		% prevent (?) vertical centering
\end{slide}

%---------------------------------------------------------------------

\begin{slide}{}

\Mytitle{Event Observers}

\begin{itemize}

\item An event observer contains application-specific event handling
methods that respond to events triggered in an event source.

\item The {\em multicast event registration\/} allows any number of
event listeners to be associated with an event source under the same
event types.

\item {\em Event delivery\/} is the process of flowing a triggered event
from an event source to an event observer through an event listener.

\item An {\em event-driven system\/} runs in a multithreaded environment
and has an asynchronous nature.  Such environments are subject to races
and deadlocks.  To reduce risks, we synchronize the registration methods
and call event listeners from within unsynchronized code.

\end{itemize}

\vspace*{\fill}		% prevent (?) vertical centering
\end{slide}

%---------------------------------------------------------------------

\begin{slide}{}

\Mytitle{Publish and Subscribe}

\begin{itemize}

\item Sources publish events.  Listeners subscribe.

\item A source component needs:
\begin{itemize}
\item A method call to fire off an event notification upon occurrence.
\item Declarations for {\tt add---EventListener} and {\tt
remove---EventListener} that other components call to get on and off
event notification lists.
\end{itemize}

\item A listener component needs:
\begin{itemize}
\item To call the source component's {\tt add---EventListener} to
register interest in listening (or call {\tt remove---EventListener}
when it loses interest).
\item A method to perform some action after receiving the event from the
source component.
\end{itemize}

\item Creating new events:
\begin{itemize}
\item New event support class (e.g., {\tt PropertyChangeSupport}).
\item New type of event objects (e.g., {\tt PropertyChangeEvent}).
\item New type of event listener (e.g., {\tt PropertyChangeListener}).
\item Pair of register/cancel methods (e.g., {\tt addPropertyChangeListener}
and {\tt removePropertyChangeListener}).
\end{itemize}

\end{itemize}

\vspace*{\fill}		% prevent (?) vertical centering
\end{slide}

%---------------------------------------------------------------------

\begin{slide}{}

\Mytitle{Comparison with Infospheres and Multicast}

\begin{itemize}

\item Infospheres 1.
\begin{itemize}
\item Outbox can bind to any inbox.
\item Subscribers must beg listener to add or remove,
but the publisher has all of the control.
\item However, subscriber can move so the publisher
never really knows where subscriber is.
\end{itemize}

\item Multicast.
\begin{itemize}
\item Subscribers listen on a multicast address.
\item Publisher posts to multicast address without having
list of listeners.
\item Separate registry program handles add and remove.
\end{itemize}

\item Other comparisons?  CORBA events?

\end{itemize}

\vspace*{\fill}		% prevent (?) vertical centering
\end{slide}

%---------------------------------------------------------------------

\begin{slide}{}

\Mytitle{From a Local Event Model to a Globel Event Model}

\begin{itemize}
\item Specification Notation.
\item Predicates.
\item Soft Real Time.
\item Fault Tolerance.
\item Exceptions.
\item Compositional Structure.
\end{itemize}

\vspace*{\fill}		% prevent (?) vertical centering
\end{slide}

%---------------------------------------------------------------------

\begin{slide}{}

\Mytitle{Compositional Structure}

\begin{itemize}

\item {\em Problem}: how to deal with multiple notifiers?  Study
compositional structure of event model. Notifiers that can call other
notifiers.  In the middle could have several intermediate stages.  If
you think about this as one big system, what can you prove?

\item Need to investigate design choice of how to structure
applications.  Perhaps a hierarchical structure (buildings, floors, and
rooms).  Perhaps a more flat structure (buyers, sellers, markets, companies).

\end{itemize}

\vspace*{\fill}		% prevent (?) vertical centering
\end{slide}

%---------------------------------------------------------------------

\begin{slide}{}

\Mytitle{Specification Notation}

\begin{itemize}

\item {\em Problem}: how to specify components, events, and event flow?

\item Timed temporal logic. State transition diagrams.

\end{itemize}

\vspace*{\fill}		% prevent (?) vertical centering
\end{slide}

%---------------------------------------------------------------------

\begin{slide}{}

\Mytitle{Predicates}

\begin{itemize}

\item {\em Problem}: what to put in event listeners to make them easier
to program and reason about?  Dealing with predicates on the attribute-value
pairs bundled with events.  Especially predicates that have time in
them.  How to deal with in a compositional way?

\item A predicate comprises ands and nots on attribute/value pairs in
event headers.  A predicate may include an access control list.  A
predicate may include soft real time.

\item Use of XML message headers.  Attribute-value pairs allow arbitrary
predicates in event notifiers.  Personalization of response to events in
a customizable GUI.  Customization is key. 

\end{itemize}

\vspace*{\fill}		% prevent (?) vertical centering
\end{slide}

%---------------------------------------------------------------------

\begin{slide}{}

\Mytitle{Soft Real Time}

\begin{itemize}

\item {\em Problem}: how to deal with time in predicates?

\item Using a clock not guaranteed to be accurate.  For example, wait 5
minutes, then monitor again.  Keep local control of constraints.

\item From my understanding, Paul only has leads-to in his certificates,
so adding time to them seems arbitrary because you don't know when
leads-to actually happens.  This is where soft real time could be useful.

\item For example, give a timed certificate to the runtime checker.  The
checker can then itself throw events.  This is a good use of a safety
property, with no need to modify progress conditions.

\end{itemize}

\vspace*{\fill}		% prevent (?) vertical centering
\end{slide}

%---------------------------------------------------------------------

\begin{slide}{}

\Mytitle{Fault Tolerance}

\begin{itemize}

\item {\em Problem}: a global event model must have facilities for
handling faults and excessive communication delays.  How to do this?

\item Example: fire alarm goes off, no response in 5 minutes.  Response:
diagnose the line as dead and try something else.  In beans, the
applications are usually GUIs that are not safety-critical or
mission-critical, so faults and excessive delays are all right.

\item Feedback cycles are necessary.  For example, what we're
programming the thermostat?  Now, what if there is a fire?
Feedback cycles detect different types of heat and do diagnostics to
determine whether turning on the air conditioning makes sense.

\end{itemize}

\vspace*{\fill}		% prevent (?) vertical centering
\end{slide}

%---------------------------------------------------------------------

\begin{slide}{}

\Mytitle{Exceptional Behavior}

\begin{itemize}

\item {\em Problem}: A global event model must have facilities for
handling exceptions such as late responses or nonresponsive
communication channels.  How to do this?

\item Component behavior.  If a component is not behaving correctly,
raise an exception.  For example, if it violates one of Paul's
certificates, all bets are off.  Can do as event exception behaviors as
runtime checks, intuition says.

\end{itemize}

\vspace*{\fill}		% prevent (?) vertical centering
\end{slide}

%---------------------------------------------------------------------

% \begin{slide}{}

% \Mytitle{ }

% \vspace*{\fill}		% prevent (?) vertical centering
% \end{slide}

%---------------------------------------------------------------------