I've mentioned the work OSGi ifying Jini / River previously, and had
some very useful tips and ideas from this list, so I thought I'd discuss
my current progress in the hopes of receiving some more good ideas.
I'm looking for thoughts on using public Maven repositories (eg Maven
Central) and OBR as well as suitable URL formats for proxy bundles.
https://github.com/pfirmstone/JGDMS
Basically for anyone who hasn't heard of Jini, it's a distributed
services platform, with dynamic discovery of service registrars, for
clients to consume and register services. Jini has it's own
implementation of RMI, called JERI (Jini Extensible Remote Invocation)
and supports communication over a number of protocols (TLS, Kerberos,
https, among others) the implementation I've been working also has a
reimplementation of ObjectInputStream and ObjectOutputStream, that's
java serialization protocol compliant, but hardened against gadget
attacks and denial of service, using atomic input validation (it's not a
look ahead stream that white lists of black lists). More information
can be found here:
https://github.com/pfirmstone/JGDMS/wiki
and here:
https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/io/AtomicMarshalInputStream.java
So what advise should I heed?
1. I want all services and clients to be able to utilise Maven
Central, or other publicly provided repositories for dependencies,
and be utilised as an OBR.
2. Proxy implementation bundles shouldn't need to be published to a
repository and can be provided by a url, but all their
dependencies should be resolvable from a public repository.
This is the service interface I've concocted for retrieving proxy
bundles (a service registered in OSGi's service registry, utilised by
AtomicMarshalInputStream):
public interface SmartProxyClassLoadingSpi {
public Object resolve(
CodebaseAccessor bootstrapProxy,
MarshalledInstance smartProxy,
Collection context) throws IOException;
}
In the resolve method above, the bootstrapProxy is an instance of
java.lang.reflect.Proxy (bootstrap proxy), it's InvocationHandler
contains a JERI endpoint, that communicates remotely with the service
who's smart proxy is contained in serialized form in
MarshalledInstance. CodebaseAccessor allows service implementation to
download and verify a bundle, the getClassAnnotation method returns the
bundle url, where a bundle can be located and the other methods allow
the codebase signers to be retrieved. Once a bundle has been started,
it's ClassLoader is passed as a parameter to MarshalledInstance, and the
smart proxy is deserialized using the proxy bundle's ClassLoader. The
bootstrap proxy's InvocationHandler also represents the service's
identity, and this can be used as a key to cache the started bundle's
location.
It should be noted that the smart proxy may be not have originated from
the same location as the bootstrap proxy, the smart proxy may have been
reserialized from a third party. For the curious the context contains
MethodConstraints, which allow all sorts of security constraints, such
as the endpoint's connection encryption strength, the principals the
service must authenticate as etc. The bootstrapProxy also implements
RemoteMethodControl, which allows the constraints to be applied. Once
the smart proxy has been deserialized, method constraints are also
applied to it, before it's returned, as well any permissions it requires
dynamically granted, such as permssion to contact it's originating host.
public interface CodebaseAccessor extends Remote {
public String getClassAnnotation() throws IOException;
public String getCertFactoryType() throws IOException;
public String getCertPathEncoding() throws IOException;
public byte [] getEncodedCerts() throws IOException;
}
Jini Services structured for use with OSGi
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.
| 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.
|
Thanks,
Peter.
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
