-
Notifications
You must be signed in to change notification settings - Fork 1
Runtimes
A JEFRi runtime is the underlying programming component which handles all aspects of JEFRi for an application. Runtimes act as a data cache, managing references to Entities within an application. This includes responsibilities for interning entities, managing entity relationships, and attaching attribute information to Entities.
Runtimes can expose themselves publicly as a REST service. These services provide two URIs, http://example.com/jefri/*get*
for handling get
transactions and post
for handling persist requests. Transactions are POSTed to these URIs, and the runtime will return the appropriate result.
Persistence Stores allow JEFRi applications to save their data in some fashion. Persistence Stores use transactions as a specification for data to either store or retrieve data. Implementations of persistence stores are flexible on how they handle this. Some implementations might translate transactions into SQL queries, using an underlying RDBMS configured with a JEFRi context. Other implementations can send transactions to remote public JEFRi runtimes, acting as a proxy between runtimes. Applications could use these stores to create a traditional client / server model, or build a flexible peer-to-peer model for data communication.
Persistence stores must provide a single function execute
which takes a transaction and returns an object encapsulating a callback on an asynchronous operation. While a persistence store that operates locally could return immediately, to ensure consistency across runtime implementations the store must return a callback handler.
Executing get
transactions must handle the myriad of filter and join operations available in the transaction specifications. See the section on transaction specifications for the exact semantics of get requests. Executing persist
transactions must function atomically. It is the responsibility of the remote runtime to ensure that transactions happen atomically. In general, it is the persistence store's responsibility to meet the semantics specified in the section on Transactions.