Chris Greenhalgh, 2007-06-12
For more documentation see index.html
EQUIP2 is a completely new version of EQUIP which focusses on (what
consider to be) the key essence of EQUIP: providing an integrated
state/event model for developing loosely coupled (usually distributed)
At the heart of EQUIP2 is the notion of a dataspace, which is a
logical container for data. It can be thought of as a database or
tuplespace. However it holds programming language objects rather than
tables and rows (relational database) or tuples (tuplespace). It also
integrates a flexible change notification system which is comparable to
a publish-subscribe event/data distrbution system.
2. The master plan
"It's not a technology, it's a way of life" :-)
The idea is that the application(s) on each device (e.g. phone, pda,
server) are constructed around one or more dataspaces on that device.
At least one of those dataspaces will be persistent (for
configuration), but in some cases most or all of the dataspaces may be
The dataspace(s) can be thought of as a partially standardised model in
the sense of the Model-View-Controller
pattern. Like other data- and tuple-spaces they also allow
relatively loosely coupled coordination between the different elements
of the application, in particular:
- input/output activities, including GUIs and sensor/actuator IO
are routed to/from the dataspace(s).
- "business" or application logic is triggered by changes in the
dataspace(s) (and timers), and manipulates the dataspaces to reflect
changes in state and to (implicitly) trigger other activities such as
- communication with other devices, to support coordination, RPCs,
replication, etc. layered on the basic local dataspace facility.
- configuration, management and analysis, through a (yet to be
defined) standard (typically remote) means of access to all of the
dataspaces on a device (which may only be performed in constrained
situations, e.g. with the device to hand).
Potential benefits of this approach include:
- Applications can be specialised for
particular devices and deployments by tailoring (e.g.) the
communications elements without requiring changes to the
application logic, IO, etc.
- Communication can also be managed on a
device-wide basis across all device dataspaces, e.g. providing uniform
adaptation to varying network availability and other communication
- The approach makes it relatively easy and natural to develop
application which are robust in the face of network failures and
- Configuration, management and analysis tools can be developed to
run across a range of applications, systems and devices.
- The dataspace interface can provide a common point for logging
and instrumenting applications and systems.
It should be relatively straight-forward to have a persistent
dataspace implementation based on the Hibernate Object/Relational
dataspace system; this would allow integration with other applications
and interface that are based on a common relational database (e.g.
simple PHP site, other data logging application(s)).
The session API is intended to support transactions (in the future)
and to reflect a "reactive" style of programming which should fit well
with enterprise and web-style server applications.
Keeping EQUIP2 relatively focussed, it will hopefully be easier to
port to and support in other languages.
It is also intended to have wire-protocol specifications/standard in
some places (e.g. remote access to dataspaces for management and
configuration, and for server-side integration) to allow cross-language
3. Comparison with EQUIP
I'll leave the details for another day, but:
WARNING: Out of the box EQUIP2 currently has simpler
distribution that EQUIP version 1 (aka EQUIP4J); if EQUIP 1's
distribution/replication model is just right to you then you may want
to start (or stay) there (unless you also need J2ME and/or C++ support).
- No IDL and no requirement for dataspace objects to extend equip.runtime.ValueBase and
implement matching and marshalling directly.
- No single specific distribution/replication model - this is
currently left entirely to application to decide/work with.
- Runs on J2ME.
- Events made asynchronous, rather than called synchronously with
each handled event.
- Hibernate-style managed object API rather than (almost) explicit
- Single-thread session structure with potential to support
- No active objects with custom methods, code/module loading, etc.
- (Currently at least) no custom matching facility.
- document created, from material previously in