-
Notifications
You must be signed in to change notification settings - Fork 4
OSGi and JGDMS
All JGDMS Modules are also OSGi Bundles. There are no split packages or circular dependency relationships in JGDMS. Service Provider Interfaces in META-INF are also registered as OSGi services. net.jini.config.ConfigurationServiceFactory has been added, users can provide this as an OSGi service to dependency inject Configuration instances into Jini Services, Smart Proxy's or client applications. net.jini.config.ConfigurationProvider::getInstance will retrieve the OSGi service from the OSGi service registry, so Configuration should be retrieved using the provider, rather than directly from the OSGi service registry.
AtomicILFactory is designed with security and input validation in mind, as well as support for OSGi. AtomicILFactory has constructors that accept a Class parameter, which can be specified in your configuration files, the ClassLoader of this class will be used for deserialization.
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 by the distribution provider, 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 distribution provider must be implemented by the user to utilise the interfaces in ServiceDiscoveryManager to register discovered Jini services with the OSGi registry.
Using bundles to separate the components of a Jini service into API, Proxy and Service implementation bundles is very important for OSGi support, where the proxy bundle is used at each endpoint. This is enabled by using an AtomicILFactory and passing a class from or ClassLoader of your proxy Bundle. The codebase annotation for the service must also be a URI string that references the location of or method of provisioning the proxy bundle. AtomicILFactory ensures the correct bundles ClassLoaders are visible at client and server endpoints. Your service will have a unique identity in the client, so even if two different service utilise the same bundle URL, they will have independent bundle and ClassLoader visibility in the client. The client will interact with the proxy only through the API bundle.
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
| Distribution | Imports packages | Service | K
| Provider |<--------------------| API Bundle | |
| Discovers & | from API |______________| |
| Registers service | | |
|____________________| | |
Imports |
API |
Packages |
| |
| |
______|_______ |
| | |
| Proxy Bundle |---EP
|______________|
============================================================
Exporting a Jini Service is not represented above.
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 their dependencies). 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.
At this time, rather than provide an implementation of an OSGi Distribution Provider it has been left for community input and development.
Unlike Java RMI, JGDMS accepts ClassLoader arguments for it's endpoints, allowing it to avoid the problems experienced during Deserialization with RMI. In addition JGDMS provides much improved security and is extensible to other protocols and has endpoint implementations for https, TLS and Kerberos among others.