EQUIP2 API Alternatives

Introduction

The current/initial EQUIP2 API uses a Data Access Object style, in which POJOs or JavaBeans (with framework support through helper classes or reflection) are used a data values. This encourages an OO style, and allows large parts of the application logic to be independent of EQUIP2, solely making use of these common data object classes. The current/initial session API is based on the Hibernate API, which further supports non-EQUIP2 application logic by automatically/transparently detecting changes made by the application to values obtained from the data space during that session and committing these as updates at the end of that session.

While useful for support non-EQUIP2-specific application logic, this approach has some potential issues:

• data object classes must be defined;
• these must be supported by the framework;
• there is overhead, e.g. in framework support, marshalling, change detection;
• the API is more complicated to implement and the required minimal facilities are larger
• this is an issue both for resource-limited devices (resources required), and for porting (effort required).

Consequently, it may be worth defining other API options which use different idioms, but remain compatible, e.g. may be used on the same dataspaces, or even mixed within the same application.

Initial thoughts:

• different data representations
• opaque byte arrays
• tuples (1D arrays) or named-keyed maps of opaque byte arrays (cf. JavaSpaces)
• non-opaque byte arrays, e.g. hessian encoded values
• common carrier types, e.g. Hashtable and Vector, mapping to a common information/data model
• non-change-tracking session option
• requires explicit generation of session changes - add, modify, remove

• supporting core operations:
• get (identity)
  
• match (structured values)
  
• add
• update (identify/match and mutate)
  
• remove (identify/match and remove)
• interoperability
• e.g. variant network protocols? or changes to existing network protocols?
• e.g. variant dataspace implementations? requirements for data representation conversions within dataspace implementations? shift of dataspace implementations to alternative common data representations from current object-based view?