I know that.
And while it is better than Java RMI for several reasons (extensibility
being one of them) - it is still not perfect:
1) It is inherently blocking
2) Does not support data streaming (in general you need a separate comm
channel for this)
3) invocation layer depends on particular object serialization
implementation - Marshall input/output streams (this is my favorite - to
plug in my new AnnotatedStream implementations I must basically rewrite
the invocation layer)
Thanks,
Michal
Peter wrote:
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
