Hi Scott,
Thanks for the links. I plan to look at doing some sort of compatiblity
layer for OSGi Remote Services, if anyone wants to help out, I'll gladly
accept any assistance, I'm not quite at that stage yet though, first
step is to just get the code to play nicely in an OSGi framework, I'm
almost there. :)
My current plan is to use proxy bundles to determine wiring /
dependencies and use public Maven repositories to satisfy them. So
different companies, entities or people can discover and use each others
services in a global network, that is dependencies must be publicly
available. The proxy can be a private implementation.
Thanks,
Peter.
On 24/01/2018 11:28 AM, Scott Lewis via osgi-dev wrote:
Hi Peter,
Full disclosure: I'm the ECF project lead.
I would suggest taking a look at OSGi Remote Services and Remote
Service Admin [1]. These are two specifications for exporting and
importing OSGi services across processes.
The specifications are agnostic wrt both discovery and
distribution+transport, meaning that it should be possible to use Jini
and/or your code to implement discovery or distribution using your own
serialization, wire protocol, and transport (e.g. RMI).
ECF's implementation of these specs provides open APIs for new
discovery and/or distribution subsystems, and this is how we currently
support a range of open distribution providers [2] and discovery
providers [3]. There are examples and tutorials for creating one's
own distribution provider [5].
I'm not aware of the other RS/RSA impls abilities to implement and use
new/other discovery or distribution providers without implementing the
entire specs. Here [5] is a wikimedia page listing all the RS/RSA impls.
ECF's RS/RSA bundles are made available via maven central [6].
Scott
[1] Chap 100 (RS) and Chap 122 (RSA) in Compendium:
https://www.osgi.org/developer/specifications/
[2] https://wiki.eclipse.org/Distribution_Providers
[3] https://wiki.eclipse.org/Discovery_Providers
[4] https://wiki.eclipse.org/Eclipse_Communication_Framework_Project
[5]
https://en.wikipedia.org/wiki/OSGi_Specification_Implementations#Implementations
[6] https://search.maven.org/#search%7Cga%7C1%7Corg.eclipse.ecf
On 1/23/2018 4:02 PM, Peter via osgi-dev wrote:
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
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
