river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: Extras (Was: PGP)
Date Thu, 14 Oct 2010 15:10:41 GMT
On 10/14/2010 6:47 AM, Tom Hobbs wrote:
> Having said that, what I'd like to do with these Extras is to allow an
> AD to download River and have a Jar and/or cookbook which they can
> easily read to get them going.  As it stands, justing writing a "Hello
> World" service is not documented on the River site or made easy - and
> it should be.  I don't want to take anything away from all the
> fabulous external projects built on top of River/Jini, but as a AD
> myself, I don't want to have to download River and then be told that I
> need to make another decision about which external project I need to
> download next in order to write effective River services.  Then I need
> to learn how to knit the two together.

What I think we need to deal with, is trying to map out this Kniting process as 
it would exist today given that we have in the community projects and river.

There are the low level service and client construction steps that just use JERI 
raw.  There is com.sun.jini.start that lets multiple services run 
"independently" in the same VM. This is the River container.  Then we have other 
value added containers such as Rio and Seven as standalone environments, and 
still others that integrate Jini into web service environments and other such 
environments.  There are outliers, like my http://startnow.dev.java.net project 
that just provides a giant class that you can subclass, which has all of the 
"River stuff" (config, jeri etc) visible in it, so that people can just create a 
service with

public class MyService extends PersistentJiniService { }

and call startService("Service Name", "archive.ser") to advertise it.  The 
things that you need done are done for you.  If you want to see how they are 
done, "Use the source Luke".

What I feel is really needed, is an interface that all of the "containers" can 
support to allow service injection.  There needs to be a River SPI that which 
allows service authors to create standalone services using simple mechanisms 
like those in com.sun.jini.start, but also allows the same service to be 
deployed into environments such as Seven, Rio and the web service containers as 

It doesn't need to be all powerful, but something basic needs to exist in River 
as the "way" which allows these other environments to use those services, even 
if it is with some restricted behaviors/features.

Then, there will not be "pain and agony" to switch containers.

The JavaEE world has such mechanisms and people can switch things around there, 
because those "services" are the same kind of services doing the same kinds of 

Jini is not so "confined" in use, and so we need to step back and think about 
whether what matters is the four things that com.sun.jini.start needs, policy, 
classpath, codebase and args (ConfigurationFile conveyance path), or is it a 
different thing.

The service is the serivce.  Those 4 things are deployment considerations and 
the things that the "container requires".

Other containers provide automated or more GUI based deployment controls which 
don't need the same deployment "mechanisms".

 From my perspective, Policy, classpath and codebase are external deployment. 
Configuration and command line arguments are runtime deployment information 
which can control how the service behaves directly.

So, I'd like to suggest that there is a runtime deployment control mechanism 
needed which just deals with "what is the service object", "what is the 
configuration" and "what are the arguments".  Additionally, the service needs to 
have lifecycle management available so that it can know when it is being 
unloaded, and perhaps when Policy and Principal information changes so that it 
can drop references to cached values dealing with such issues.

If a single Jini service class is "Ran" via 'public static void main()' it 
should be able to find a deployment factory instance from "River", and start 
itself up.

If a collection of services need to be run in the same JVM, the same service 
should be able to be dropped into com.sun.jini.start mechanisms and work.

The same service can then be deployed into other containers if those containers 
support the River standard mechanisms by looking at deployed service classes for 
an interface/abstract class and then calling methods appropriately.

Any suggestions on what kind of API we need?  I have some thoughts, but perhaps 
others have already done this themselves?

Gregg Wonderly

View raw message