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
well.
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
things.
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
