Skip to main content
Jump to: navigation, search

Difference between revisions of "EIG:Introduction to the Shared Object API"

 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
The Shared Object API is used to expose methods on a local object over a network to a number of remote VMs and to message those remote VMs, typically with updates to the local object.
+
The Shared Object API is used to allow objects to message groups of other objects of the same type  on a network, typically with updates to state. Thus the model is particularly appropriate where a peer-to-peer messaging or state distribution is called for.
 +
 
 +
For example, the task of transparently extending OSGI's EventAdmin messaging framework, which is limited to messaging between OSGI bundles within the VM on which the OSGI Framework is running, to handle events received from bundles within OSGI frameworks running on remote VMs, is fundamentally a peer-to-peer messaging problem, for which Shared Object API may be suitable. And it is no surprise to find that ECF's implementation of this functionality is built on the Shared Object API framework.
 +
 
 +
By contrast, if the problem involves messaging or state distribution from a master object to a number of slave objects, in a client server model, you might consider using OSGI Remote Services for this purpose. If there is likely to be complexity introduced by conflicting state updates, then the Data Share API may be a better fit.

Latest revision as of 10:20, 8 December 2010

The Shared Object API is used to allow objects to message groups of other objects of the same type on a network, typically with updates to state. Thus the model is particularly appropriate where a peer-to-peer messaging or state distribution is called for.

For example, the task of transparently extending OSGI's EventAdmin messaging framework, which is limited to messaging between OSGI bundles within the VM on which the OSGI Framework is running, to handle events received from bundles within OSGI frameworks running on remote VMs, is fundamentally a peer-to-peer messaging problem, for which Shared Object API may be suitable. And it is no surprise to find that ECF's implementation of this functionality is built on the Shared Object API framework.

By contrast, if the problem involves messaging or state distribution from a master object to a number of slave objects, in a client server model, you might consider using OSGI Remote Services for this purpose. If there is likely to be complexity introduced by conflicting state updates, then the Data Share API may be a better fit.

Back to the top