river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject Re: [Was: OSGi and Jini] Now -> Next Steps
Date Tue, 14 Jul 2009 19:43:53 GMT
Yes, simply, JERI provides the abilities to plug into the whole stack through 
concepts known as:

Endpoint - client and server interface to data transport over a media (network etc).

InvocationLayerFactory - Implements how Java invocation, data and results are
     represented through the endpoint provided transport layer.

Constraints - specify controls for things such as security, QOS etc.

Exporter - Wraps the above three things together into something that hands you
     back the thing that needs to go across the wire for someone to use remotely.

In a JavaSE-vs-JavaSE client-server relationship, all of these things "just 
work".  In a more restricted or non Java environment, these things provide the 
layers of abstraction where you can separate Java from another language, or 
otherwise circumvent something that needs to be done differently.

It really is quite powerful.  I had an example coded up at one point, where a 
server exported a proxy object that used the MODBUS prototol to write data to a 
remote device as a the "method invocation actions" and the reply from the write, 
or reads of other data values were the results returned from the invocation.

You have to be able to think in the "abstract" for these things to look like 
"layers" and "pluggable" action points.  But there is a lot of things possible.

The http://pastion.dev.java.net project has some example code that was used to 
look into "password" based authentication.  Today, I use variations on this in 
my applications so that my customers can just configure users of the "system" to 
allow people to use applications.  Group based or User based authoriations can 
then be used to control access to features of a service.

Gregg Wonderly

Peter Firmstone wrote:
> 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.
> 
> Cheers,
> 
> Peter.
> 
> 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,
>>>
>>>
>>>     
>>
>>   
> 
> 


Mime
View raw message