There is a lot of code in the base implementation of the endpoints. It’s quite deep to “replace”. But, it is replaceable. I’ve sometimes started to create various types of protocols instead of Marshalled data. But, practically, I’ve not decided to do that. There are other technologies like RabbitMQ or other various queue based technologies that are better for “data” streaming. The explicit nature of RPC and of the layers here make them complex to replace. There are many things wired into multiple dependencies.
Why specific things do you want your AnnotatedStream to provide? Gregg > On Feb 4, 2017, at 1:43 AM, Michał Kłeczek (XPro Sp. z o. o.) > <michal.klec...@xpro.biz> wrote: > > 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 >>>>>> >>>>> >>>> >>> >>> >> >
