Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
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 | + | 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.