WebEngine Server
The WebEngine Server is a networked computer system that provides higher-level operating system
services for managing objects in a real-world environment. Objects are cast into a common
framework referred to as ‘Devices’. This framework provides the environment in which Devices
can interact. Device interaction is controlled by the execution of a rule-based computing element,
which permits device states to be compared, combined and controlled.
The WebEngine Server is designed to operate on networks of computers and is a combination of a
client/server as well as peer-peer system that can be run all in a single machine, or across a
network. Network operation can include local area Ethernet, or Internet.
The WebEngine system can be applied to a broad base of applications that require the control and
coordination of persistent Devices. Devices include a wide variety of categories such as
communication devices (faxes, telephones, pagers, email), environmental devices (security systems,
lighting, heating), computer-related devices, Internet sites, and more, within a home, a small
business, a factory, or combinations of these connected across the Internet.
WebEngine Server - a Networked Control System for Devices
The WebEngine Server utilizes advanced concepts in object design and networking to provide a
comprehensive, network based environment for the coordination and control of Device objects.
Let’s examine some of the characteristics of this system and how they compare with conventional
approaches.
The WebEngine Server is a networked computer system that provides higher-level operating system
services for managing objects in a real-world environment. Objects are cast into a common
framework referred to as ‘Devices’. This framework provides the environment in which Devices
can interact. Device interaction is controlled by the execution of a rule-based computing element,
which permits device states to be compared, combined and controlled.
The WebEngine Server is designed to operate on networks of computers and is a combination of a
client/server as well as peer-peer system that can be run all in a single machine, or across a
network. Network operation can include local area Ethernet, or Internet.
The WebEngine system can be applied to a broad base of applications that require the control and
coordination of persistent Devices. Devices include a wide variety of categories such as
communication devices (faxes, telephones, pagers, email), environmental devices (security systems,
lighting, heating), computer-related devices, Internet sites, and more, within a home, a small
business, a factory, or combinations of these connected across the Internet.
WebEngine Server - a Networked Control System for Devices
The WebEngine Server utilizes advanced concepts in object design and networking to provide a
comprehensive, network based environment for the coordination and control of Device objects.
Let’s examine some of the characteristics of this system and how they compare with conventional
approaches.
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
Observe many sites
across the country, a
city or campus using
the power of Savoy.
across the country, a
city or campus using
the power of Savoy.
Ubiquitous Rule Processing
It is generally assumed that all devices endowed with computers will somehow be able to
communicate with each other – the industry has a sufficient number of proposed ways to
do this [CEBUS, home network LANS, JINI, etc. ]. Beyond how they will communicate,
however, is the question of what they will communicate. That is, what is the logic, or set of
algorithms, that determine overall behavior of a complex system of devices?
In some cases, a device may require specific services of another device. For example, an
HVAC (Heating, Ventilation, and Air Conditioning) unit requires the specific services of a
thermostat, a requirement designed into these particular devices. But suppose we wish to
extend the ‘design’ of a device to provide an unforeseen interaction, like having your
thermostat interact with a security system (reducing the temperature while away)? For this
purpose, we need a way to extend the logic of a device.
In object-oriented computer languages (e.g., C++, Java), extending the design of an
object is done by deriving another object from it and then adding methods to implement
the extensions. However, if we added the extension as object methods, both participating
devices would have to be ‘designed’ or the interaction; e.g., the security system would
have to ‘know’ about thermostats. We have a tricter requirement: any device should be
able to dynamically connect to any other device without ny knowledge of their partners. To
achieve this, we must impose some strict conformity to the xtended methods.
The advantage of a common rule structure across all of these implementations is (1) they
can all compatibly interact with each other, (2) it is independent of the communication
technique and can arguably utilize any communication facility available (particularly any
standard that emerges), (3) does not require a common operating system nor
implementation language to run in the processors, and (4) encodes the actual
functionality of the interactions so that the design of devices themselves can remain
generic.
Domains and Type Managers
The network server is designed to manage a large and extensible set of Device types.
The set of Device types having common physical characteristics are grouped into what is
called a domain. Since many Devices represent real-world objects that can be controlled
by the computer, the domain is typically the space of device types that a particular
hardware interface can control.
The Server performs computation at two distinct levels: (1) within a domain, and (2) across
one or more domains. Computation within a domain is usually limited to dealing with the
I/O peculiarities of the interface and is encapsulated and hidden within a software
component called a Type Manager—so named because it manages the set of device
types defined within the domain. Computation across domains is performed by an entity
called the Rule Processor.
The Rule Processor within the Server performs Boolean logic across domains in
accordance with rules created by users. This is a simple, but powerful concept. For
example, suppose one domain is the Internet WWW wherein a device type called ‘weather
report’ periodically browses a known Internet site that contains weather forecasts.
Suppose a second domain is an I/O system used to control water valves on a lawn
sprinkler system. Then, with point-and-click simplicity, a user could modulate the
scheduling of the lawn sprinklers in accordance with rain forecasts.
Network Configurations
While most environments will likely run in a single machine, the WebEngine is designed to
cooperate with other WebEngines connected over networks. The WebEngines cooperate
in such a way as to behave as a single entity, allowing for remote facilities to be managed
collectively. Specifically, all WebEngines exchange cause and effect information allowing
causes in one facility to have effects in another .
It is generally assumed that all devices endowed with computers will somehow be able to
communicate with each other – the industry has a sufficient number of proposed ways to
do this [CEBUS, home network LANS, JINI, etc. ]. Beyond how they will communicate,
however, is the question of what they will communicate. That is, what is the logic, or set of
algorithms, that determine overall behavior of a complex system of devices?
In some cases, a device may require specific services of another device. For example, an
HVAC (Heating, Ventilation, and Air Conditioning) unit requires the specific services of a
thermostat, a requirement designed into these particular devices. But suppose we wish to
extend the ‘design’ of a device to provide an unforeseen interaction, like having your
thermostat interact with a security system (reducing the temperature while away)? For this
purpose, we need a way to extend the logic of a device.
In object-oriented computer languages (e.g., C++, Java), extending the design of an
object is done by deriving another object from it and then adding methods to implement
the extensions. However, if we added the extension as object methods, both participating
devices would have to be ‘designed’ or the interaction; e.g., the security system would
have to ‘know’ about thermostats. We have a tricter requirement: any device should be
able to dynamically connect to any other device without ny knowledge of their partners. To
achieve this, we must impose some strict conformity to the xtended methods.
The advantage of a common rule structure across all of these implementations is (1) they
can all compatibly interact with each other, (2) it is independent of the communication
technique and can arguably utilize any communication facility available (particularly any
standard that emerges), (3) does not require a common operating system nor
implementation language to run in the processors, and (4) encodes the actual
functionality of the interactions so that the design of devices themselves can remain
generic.
Domains and Type Managers
The network server is designed to manage a large and extensible set of Device types.
The set of Device types having common physical characteristics are grouped into what is
called a domain. Since many Devices represent real-world objects that can be controlled
by the computer, the domain is typically the space of device types that a particular
hardware interface can control.
The Server performs computation at two distinct levels: (1) within a domain, and (2) across
one or more domains. Computation within a domain is usually limited to dealing with the
I/O peculiarities of the interface and is encapsulated and hidden within a software
component called a Type Manager—so named because it manages the set of device
types defined within the domain. Computation across domains is performed by an entity
called the Rule Processor.
The Rule Processor within the Server performs Boolean logic across domains in
accordance with rules created by users. This is a simple, but powerful concept. For
example, suppose one domain is the Internet WWW wherein a device type called ‘weather
report’ periodically browses a known Internet site that contains weather forecasts.
Suppose a second domain is an I/O system used to control water valves on a lawn
sprinkler system. Then, with point-and-click simplicity, a user could modulate the
scheduling of the lawn sprinklers in accordance with rain forecasts.
Network Configurations
While most environments will likely run in a single machine, the WebEngine is designed to
cooperate with other WebEngines connected over networks. The WebEngines cooperate
in such a way as to behave as a single entity, allowing for remote facilities to be managed
collectively. Specifically, all WebEngines exchange cause and effect information allowing
causes in one facility to have effects in another .