river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <...@dcrdev.demon.co.uk>
Subject Re: Future of Jini/River
Date Sat, 15 Nov 2008 10:12:31 GMT
Hi Sam,

Sam Chance wrote:
> All,
> Many of you may be familiar with companies like GlobalInfoTek and Paremus.
> GlobalInfoTek has implemented a capability called "Intelligent Services
> Layer" (ISL) and a composition layer on top of it called CHAIN.  You can go
> to their website to learn more.
> Paremus has built a distributed services framework that manages OSGi bundles
> (components) and assembles them into systems using a Service Component
> Architecture (SCA) based model.
> Both of these feature the various autonomic properties provided by
> Jini...and more. They're awesome and we never have to talk about Jini.

Do you ever talk about River?

> Then we have "SOA".  I suppose we've bemoaned the fact that XML Web Services
> don't = SOA and vice verse.  However, SOAP/WSDL and REST/WADL remain all the
> rage.  I always argue we have JBOWS and not SOA.  (Just a Bunch of Web
> Services). But I doubt anyone cares! :-)

They're all the rage for various reasons - which might include:

(1)  SOAP/WSDL is basically CORBA or a subset of RMI - it's a simple
leap for most and allows them to not worry about failure as they have
always done before.  New technology same old philosophical approach to

(2)  REST arguably didn't really take off until it got first class
support (of a sort) in Ruby on Rails.  Around the same time many
websites had some sort of API available over http and all claimed they
were RESTful which got everybody's interest although in many cases these
APIs weren't even remotely inline with the basics of REST.  Even now
exactly what complete REST might be is something of an exercise left to
the reader to discover.  There are lots of dark corners design-wise and
most http libraries make it somewhat difficult to do well.

> Still, the static nature of mainstream SOA presents *yet another*
> opportunity for Jini/River to emerge as relevant.  For example, service
> discovery is some pathetic attempt to register service descriptions in a
> UDDI.  Nobody uses or likes UDDI.  Well, I'm sure someone does. :)
> As another example, I recently attended a "No Fluff, Just Stuff" conference
> wherein the speaker was talking about REST and Resource Oriented
> Architecture.  In his talk, he showed an example of (location independent)
> service discovery.  His discovery mechanism?  JMDNS (jmdns.sourceforge.net).
> I asked him if he heard of Jini and, if so, what he thought of it.  His
> answer: Yes. It's too complicated and overkill.  He's a smart, well informed
> technology leader and HE doesn't appreciate Jini!

Ah but he does appreciate Jini - that's why he's using JMDNS.  JMDNS is
one small chunk of the Jini philosophy.  It's a dynamic discovery mechanism.

To sell to this guy means getting him to take another step - it might be
code-downloading (if we make it work nice) or security or.......

Jini of course does what JMDNS does but requires at least potentially a
few more steps beyond what you'd do for a JMDNS app like building up
download .jars and the like.  None of the documentation I've seen tells
a developer "how to build a JMDNS-like app with Jini".....

> Why couldn't Jini explicitly address the service discovery challenges
> currently prominent in mainstream SOA?  Why can't I log into my machine and

What is mainstream SOA?  There are seemingly 90000 meanings and
definitions as supplied by the endless list of "SOA-compliant" vendors.

Much of the "service discovery" I've seen in this arena is in the style
of CORBA or similar staticness.  It's not nearly as "compatible" as
JMDNS and thus a harder step to take.

> see available services pushed to me - perhaps filtered by security, roles,
> interests, etc?  I don't care where they are; I just want to use them.

You can but it wouldn't fit with how most SOA people think it should work.

> Why can't we do discovery over the Internet? At least an Enterprise
> Intranet?

Intranet != Internet.

On an intranet you have a cat in hells chance of mulicast working though
most network admins won't enable it out of some fear or another.

However discovery can be done on the internet already with appropriate
open ports and peering of lookup services.  However:

(1)  Your firewall/network admins have to be prepared to co-operate and
potentially open up more than port 80.

(2)  You need to put the appropriate configuration magic into your
lookup services and services.

But what you don't get out of this is the more flexible
lower-configuration discovery that comes from multicast.

> I would (almost) bet money that various Jini/River-based projects (currently
> floundering in obscurity) address or begin to address these challenges /
> needs?
> I think we ought to confront the reality that technology does not
> necessarily rise to large-scale adoption based on merits, but ease of
> understanding and ease of use and marketing. In fact, I've heard folks
> nicely describe the process as "Awareness, Appreciation, then Preference."
> River lacks the first two, and thus never makes it to the third.  The
> "River" community arguably is "balkanized".  Each time this issue comes up,
> a group of VERY smart technologists/engineers talks about things like
> "serialization, marshaling, interfaces, namespaces..." and all manner of
> deep, into the weeds, technical jargon.  But there is no coordinated effort
> to simplify, educate and evangelize. No vision will lead to its eventual
> death.
> I constantly bring up Jini, and the aforementioned companies, in my circles,
> and I get the same results: Ignorance and apathy.
> If we can't rally around a couple of relevant uses and we if we can't
> simplify it and if we can't (then) spread the gospel, then we'll not create
> Awareness that leads to Appreciation and ultimately Preference.
> There is simply no way I can successfully evangelize Jini by telling people
> it is a "...dynamic, distributed SOA framework..."  The recipient perceives
> that as a gnat on a horse's ass.  They're going to ride the horse and not
> even realize there's a gnat on it!
> Since I learned about Jini in 2001, I've been a big fan.  I see incredible
> uses that scale from services within a machine up to planes, trains, and
> automobiles... worldwide! :-)
> Sorry for the rant...
> Sam
> On Tue, Nov 11, 2008 at 9:22 AM, Gregg Wonderly <gregg@wonderly.org> 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

View raw message