EQUIP2 Overview

Chris Greenhalgh, 2007-06-12

Contents:

• Introduction
• The master plan
• Comparison with EQUIP v.1
• Changes

1. Introduction

EQUIP2 is a completely new version of EQUIP which focusses on (what I consider to be) the key essence of EQUIP: providing an integrated state/event model for developing loosely coupled (usually distributed) applications.

2. The master plan

"It's not a technology, it's a way of life" :-)

• 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.
• 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 channels.
  
• The approach makes it relatively easy and natural to develop application which are robust in the face of network failures and variability.
• 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 integration/interoperation.

3. Comparison with EQUIP v.1

I'll leave the details for another day, but:

• 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 event API.
• Single-thread session structure with potential to support transactions.
• No active objects with custom methods, code/module loading, etc.
• (Currently at least) no custom matching facility.

4. Changes

• document created, from material previously in EQUIP2_Introduction.html

• added equip1 warning