river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: [Was: OSGi and Jini] Now -> Next Steps
Date Mon, 13 Jul 2009 10:25:36 GMT
Hi Elijah,

Look into JERI (part of River/Jini) before going down the RMI path, big 
improvements in security and not requiring pre compiled RMI stubs.  JERI 
reuses some parts of RMI.  JERI was intended as a replacement for RMI, 
however that's another story.

There are significant advances made with regards to security since Jini 
1.2.1, a significant achievement considering the problems overcome.

The artice on JavaWorld: "Jini Starter Kit 2.0 tightens Jini's security 
framework" gives a good overview.



Elijah Menifee wrote:
> I myself have started to play with NIO for prototyping a replacement server
> system for my company's software.  While doing research on how to obtain
> SSL/TLS connections on top of the NIO framework I came across Project
> Grizzly <https://grizzly.dev.java.net/> which is a sub component of the new
> GlassFish server, as such it is dual licensed under CDDLv1 and GPLv2
> (ClassPath exception for some parts listed at bottom of GlassFish
> license<https://glassfish.dev.java.net/public/CDDL+GPL.html>
> ).
> IANAL so I do not know if it is license compatible or not. If it is it may
> provide a good frame work for a low level threaded NIO server to implement
> Jini protocols on top of.  My understanding is that there has been work done
> to get its transport layer to work for the Glassfish ORB.  This includes
> IIOP, not sure if it also includes RMI-IIOP, or how hard it would be to get
> the RMI-IIOP on top of their IIOP transport layer. ( I found this info
> at Grizzly
> Terminology Blog<http://blogs.sun.com/harshag/entry/grizzly_1_7_0_terminology>).
>  I am currently evaulating it as a base server to implement my
> company's
> protocols on top of.  Also it has been a while since I worked with Jini
> technology (1.2.1), I assume it still uses RMI, and do not know if it was
> ever changed to support RMI-IIOP....But from what I have read it should be
> possible to implement custom protocols on top of Grizzly transport layer.
> Although it has been fun learning the NIO framework, and building a basic
> threaded high-performance server has been a learning experience I am still
> only prototyping the next revision of our software. If I can get Grizzly to
> work with its SSL layer and worker thread management running our async
> protocol and business logic I plan to pitch it to the other owners as the
> technology to use for the next major rewrite. I believe it would be a better
> solution than us maintaining our own low-level threaded NIO server, thus we
> only would have to maintain our protocol, business-logic, and presentation
> layers...
> P.S. According to the FSF GPLv3 is license compatible with the v2 Apache
> License, so if the Kerberos stuff can be upgraded to GPLv3 ( sometimes the
> license on software states or a later version..., or if they choose to
> relicense it under GPLv3) it should be compatable.
> On Fri, Jul 3, 2009 at 11:41 PM, Peter Firmstone <jini@zeus.net.au> wrote:
> ...
>> After that I'd like to play around with NIO and DEFLATE compression for
>> serialization and http classserver performance improvements.
>> I recently stumbled across a complete Java implementation of Kerberos
>> Server and client software, I'm thinking there may be benefits for River
>> running with a default authorisation setup, however it's GPL2, so I'd have
>> to ask if it can be relicensed first.
>> Cheers,

View raw message