FYI. JERI != Java RMI.
There's no reason these layers couldn't be provided as OSGi services and
selected from the service registry either.
Cheers,
Peter.
Protocol Stack
The Jini ERI architecture has a protocol stack with three layers as
shown in the following table, with interfaces representing the
abstractions of each layer on the client side and the server side as shown:
Layer Client-side abstractions Server-side abstractions
Invocation layer |InvocationHandler|
<http://docs.oracle.com/javase/6/docs/api/java/lang/reflect/InvocationHandler.html?is-external=true>
|InvocationDispatcher|
Object identification layer |ObjectEndpoint| |RequestDispatcher|
Transport layer |Endpoint|, |OutboundRequestIterator|,
|OutboundRequest| |ServerCapabilities|, |ServerEndpoint|, |InboundRequest|
The client-side and server-side implementations of each layer are chosen
for a particular remote object as part of exporting the remote object.
The design is intended to allow plugging in different implementations of
one layer without affecting the implementations of the other layers.
The client side abstractions correspond to the structure of the
client-side proxy for a remote object exported with Jini ERI, with the
invocation layer implementation containing the object identification
layer implementation and that, in turn, containing the transport layer
implementation.
Which invocation constraints are supported for remote invocations to a
particular remote object exported with Jini ERI is partially dependent
on the particular implementations of these layers used for the remote
object (most especially the transport layer implementation).
On 4/02/2017 3:51 PM, Peter wrote:
Thanks Nic,
JERI shouldn't be considered as being limited to or dependant on Java
Serialization, it's only a transport layer, anything that can write to
an OutputStream and read from an InputStream will do.
The JSON document could be compressed and sent as bytes, or UTF
strings sent as bytes.
See the interfaces InboundRequest and OutboundRequest.
Cheers,
Peter.
On 4/02/2017 3:35 PM, Niclas Hedhman wrote:
FYI in case you didn't know; Jackson ObjectMapper takes a POJO structure
and creates a (for instance) JSON document, or the other way around.
It is
not meant for "any object to binary and back".
My point was, Java Serialization (and by extension JERI) has a scope
that
is possibly wrongly defined in the first place. More constraints back
then
might have been a good thing...
On Sat, Feb 4, 2017 at 12:36 PM, Peter<j...@zeus.net.au> wrote:
On 4/02/2017 12:43 PM, Niclas Hedhman wrote:
On Fri, Feb 3, 2017 at 12:23 PM, Peter<j...@zeus.net.au> wrote:
No serialization or Remote method invocation framework currently
supports
OSGi very well, one that works well and can provide security might
gain a
lot of new interest from that user base.
What do you mean by this? Jackson's ObjectMapper doesn't have
problems on
OSGi. You are formulating the problem wrongly, and if formulated
correctly,
perhaps one realizes why Java Serialization fell out of fashion rather
quickly 10-12 years ago, when people realized that code mobility
(as done
in Java serialization/RMI) caused a lot of problems.
Hmm, I didn't know that, sounds like an option for JERI.
IMHO, RMI/Serialization's design is flawed. Mixing too many concerns
in the
same abstraction; sandboxing w/ integration , code mobility, class
resolution, versioning and deserialization, with very little hooks to
cusomize any or all of these aspects. And these aspects should not
have
been wrapped into one monolith.
Further, I think the only "sane" approach in a OSGi environment is to
create a new bundle for the Remote environment, all codebases not
part of
the API goes into that bundle and that the API is required to be
present
in
the OSGi environment a priori. I.e. treat the Remote objects in
OSGi as it
is treated in plain Java; one classloader, one chunk, sort out its own
serialization woes. Likewise for the server; treat it as ordinary RMI,
without any mumbo-jambo OSGi stuff to be figured out at a
non-OSGi-running
JVM. An important difference is that in OSGi, the BundleClassLoader
is not
(required to be) a URLClassLoader, so the Java serialization's auto
annotation of globally reachable URLs won't work, and one need to
rely on
java.rmi.server.codebase property, but a bundle could watch for loaded
bundles and build that up for URLs that can be resolved globally.
Cheers
