+1, and any of this that can make it into River (and not have to be
Seven specific) sure sounds good to me.
Dan
Gregg Wonderly wrote:
Sam Chance wrote:
Gregg,
Please forgive me for what I'm about to say. While all this is surely an
engineering marvel - and perhaps necessary, it has no impact or wow
factor
to motivate 'outsiders' to download, install and use it.
Here's my thoughts around this Sam.
o New lookup service:
Removes the lost codebase problem as an issue because you can pass
around the service object in marshalled form. It provides a bases
for concepts of marshalled data transmission and use in your service
so that you can separate the "container for transport" from the data.
In doing that, you provide the opportunity for random marshalling
technologies to be used, such as SOAP and other packaging.
o Jini Desktop environment:
Provides the basis for just install and use services. In concert with
getting Seven out the door, there is the opportunity to provide a
simple
service deployment and use mechanism that would encourage the creation
of Jini services. Today, the out of the box experience is raw and full
of details that are not "creating the service". I created the stuff
in my startnow.dev.java.net project as the mechanism that I use for
creating services now. I just do
public class MyService extends PersistentJiniService {
public static void main( String args[] ) {
new MyService( args, null );
}
public MyService( String args[] ) {
super( args );
...get other config params and do setup...
startService();
}
}
and I have a Jini service up and running. We need an experience like
this where all the config details and all the appropriate defaults just
happen for the user. The Seven mechanisms are similar, but the API is
richer for plugability and there is the whole deployment mechanism.
Password access:
We see occasional traffic on the list about "how do I keep joe from
using my service if it is visible on the internet?" To me, these hover
around the basic issue of how easy it is to do password based
authentication using a web interface.
I'm all for having some web interface capabilities. For me though, that
would be a serviceUI exercise. We would define the appropriate
UIDescriptor that would provide all of the details for getting a
"servlet" interface to a service. Someone would then just write a
service discovery bit for throwing into apache and it would then
automatically discover and make available a web service UI to the "world".
Proxied Authorization:
Using the Java security system is a royal pain because of the issues
with how Subject and threads of execution create context that is not
always active. So, if you instead use an instance of the service
interface as a proxy to the real service, and bury in that proxy,
all the authorization implementation, then an existing service can
have authorization pasted on top of it without the sprinkling of
java security permission checks which pretty much lock you into one
mode of authorization. I think this would be a big help to a lot of
issues revolving around overall security of network services.
I don't expect to influence the community to make a sharp rudder
change, but
one is sorely needed to bring River from real obscurity to something of
relevance.
I think we have to focus on the user experience and wrap a lot of the
mechanics into simple wrappers that don't remove access to the details,
but just provide reasonable defaults.
Gregg Wonderly
