-
Notifications
You must be signed in to change notification settings - Fork 5
OSGi and JGDMS
All JGDMS Modules are also OSGi Bundles. There are no split packages or circular dependency relationships in JGDMS.
JGDMS implements Jini Lookup and Discovery, with support for IPv6 Multicast in addition to IPv4. OSGi utilises it's own service registrar to lookup services. OSGi users should utilise net.jini.lookup.ServiceDiscoveryManager to discover Jini services, authenticate, and resolve their proxy bundles dependencies, prior to deserializing the proxy's state into the proxy's bundle ClassLoader. After this potentially lengthy process is complete, the service's proxy should then be registered with the OSGi service registrar, where it can be utilised by listening clients.
In an OSGi environment, net.jini.jeri.Endpoint (EP) and net.jini.jeri.ServerEndpoint (SEP) must have a reference to the proxy bundle's ClassLoader in both the client and servers jvm's, the same version of the proxy bundle must be used in each jvm. All serialized classes will be resolved by the proxy bundles at each endpoint. This limits the classes that can be serialized to those visible to the proxy bundles at each endpoint, this structure ensures that serialization works as expected, and is managed by OSGi versioning, it also has security advantages. The management agent must be implemented by the user to register discovered Jini services with the OSGi registry.
SERVER JVM
============================================================
______________
| |
| Service |
| API Bundle |
|______________|
|
|
Imports
API
Packages
|
|
____________________ ______|_______
| | Imports packages | |
| Service Bundle |<--------------------| Proxy Bundle |--SEP
| Implements | from proxy |______________| |
| Proxy API | |
|____________________| |
|
============================================================ |
|
|
|
C
O
CLIENT JVM M
============================================================ |
L
______________ I
____________________ | | N
| | Imports packages | Service | K
| Management Agent |<--------------------| API Bundle | |
| Discovers & | from API |______________| |
| Registers service | | |
|____________________| | |
Imports |
API |
Packages |
| |
| |
______|_______ |
| | |
| Proxy Bundle |---EP
|______________|
============================================================
There are two kinds of proxy's in JGDMS, smart proxy's (that have a dedicated proxy bundle containing proxy class files) and dynamically generated proxy's (that only utilise published Service API classes and any imported packages by Service API). Dynamic proxy endpoints must have a reference to the Service API bundle in each JVM.
Additionally Jini Services often have methods that expect a callback exported object that can invoke method calls from the remote end (to send an event to a remote event listener for example), best practise is to utilise only dynamic proxy's for call back's in an OSGi environment. While it is possible to utilise a smart proxy as a callback, by providing a codebase that contains all necessary classes, which will have the Service API as the parent ClassLoader at the remote end, it is generally inadvisable because there will be no version control for smart proxy code in this instance.