Introduction
Implementing EventWeb on MediaBroker will allow us flexibility in data
typing and data transport. MediaBroker will glue together the components
of EventWeb cleanly while hiding the complex transport code "under the covers."
MediaBroker will also allow data streams to transparently be shared
between Media Producers and Event Detectors, Stream Writers, and Live
EventWeb Browsers. In Figure 1, a mid-level architecture
diagram is presented. While the complex EventWeb querying interactions
are represented as only 4pt lines, all MediaBroker interactions
are presented in more detail.
Figure 1:
System Interaction of EventWeb Implemented on MediaBroker
|
|
A Media Producer is a data input wrapped in MediaBroker code. The data
stream from a Media Producer will be shared with an Event Detector,
necessary stream writers who are archiving the Media Producer's stream
and any EventWeb Browsers who are interested in the live media stream.
Each Media Producer will be specifically written for each producer type.
The Media Producer will have the option of providing a fixed type of
media or a complete type lattice of data types easing the burden of the
network and the MediaBroker when the producer's stream if of no
importantce.
The Media Producer will be named at run-time and that name will be
registered with the MediaBroker's nameserver as well as with the Event
Database. The Media Producer may specifically write to the Event
Database as shown in Figure 1 or may rely on another
facility to regularly sync information between the MediaBroker's
nameserver and the Event Database.
An Event Detector will listen to one or more Media Producers and judge
when a stream has become interesting. When a stream is deemed
interesting, the Event Detector will instantiate a Stream Writer to
archive the interesting stream(s). Once the Event Detector instantiates
the Stream Writer, it will register that Stream Writer with the Event
Database. This record in the Event Database will show that the stream is
currently live in the MediaBroker. When the stream is no longer
of importance, the Event Detector will terminate the internal Stream Writer
and update the Event Database to show that the stream is a static entity
in the Media Database.
The Event Detectors have the option of writing a media source stream
describing their current state. This stream can then be monitorred by
the Continuous Query Server.
The Event Detectors will be named and charged with streams at run time.
Once an Event Detector decides that a media stream is worth recording, it
instantiates an Stream Writer to write the stream to the Media Database.
The Event Detector specifies both the stream to record as well as the location
and name of where to write it. The Event Detector writes the data type
information, the stream name and the stream itself into the Media
Database.
The Stream Writer terminates when requested to do so.
Stream Readers are instantiated by the MediaBroker Plugin to service
requests from the EventWeb Browser. The Stream Reader is instantiated
with a name and a database entity to read. The Stream Reader then
queries the database for the media stream and the data type associated
with it. The Stream Reader then listens for VCR commands from the
MediaBroker Plugin to play, pause, rewind,
fast forward and stop the media stream.
The Stream Reader terminates when requested to do so.
The MediaBroker Plugin services HTTP replies of type: MediaBroker
Stream. When a browser recieves a source of type MediaBroker Stream, the
plugin reads for the stream name as well as the MediaBroker engine name
and port numbers. The stream name will either be a live stream
in the MediaBroker that the plugin will subscribe to or a database
entity. If the stream name is a database entity, the plugin will need to
call to instantiate a Stream Reader for that database entity and then
subscribe to the instantiated reader.
The plugin will have the ability to negotiate the appropriate data type
for data it will display. The specified size of the plugin will also
dictate how audio and visual media will be displayed.
Plugins are required to terminate any Stream Readers that they
instantiate when the reader is no longer necessary.
The EventWeb Browser is a standard HTTP-speaking HTML-rendering web
browser. The browser interacts with the Request Server and the
Continuous Query Server through web forms and displays media streams
using the MediaBroker Plugin when necessary.
The Request Server will query the Event Database based on its
interactions with the EventWeb Browser. These interactions are entirely
within the EventWeb and are only tangentially related in that the Event
Database holds records relating stream meta data to how the MediaBroker
Plugin can request these streams from the EventWeb/MediaBroker
architecture.
Like the Request Server, the Continuous Query Server recieves requests
from the EventWeb Browser and replies to these request as necessary.
This interaction follows the Request Server interaction model and is
completely out of the scope of this document.
The Continuous Query Server has the ability to subscribe to both Event
Detector streams, as shown in Figure 1, or directly to
Media Producer Streams. When the data in a stream meets criteria in a
active continuous query, the Continuous Query Server can notify the
EventWeb Browser or it could instantiate a Stream Writer to archive the
important data. In this way, the Continuous Query Server could take the
place of the Event Detectors or relegate the Event Detecors to simple
data aggregation functionality.
This document was generated using the
LaTeX2HTML translator Version 2002 (1.62)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -split 0 eweb
The translation was initiated by Martin Bruce Modahl on 2003-09-25
Martin Bruce Modahl
2003-09-25
![\includegraphics[width=5in]{eweb-mb.eps}](img1.png)