river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: Future of Jini/River
Date Sat, 15 Nov 2008 07:36:46 GMT
----- Original Message ----

> From: Sam Chance <sgchance@gmail.com>
> To: river-dev@incubator.apache.org
> Sent: Friday, November 14, 2008 8:52:30 PM
> Subject: Re: Future of Jini/River
> 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.

Seems with significatn differences in memory requirements, OS targets, and as far as I can
tell application targets/markets. Always more to read though.

> 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! :-)
> 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. :)

UDDI has it's place. Just like JMDNS below. These are all targeting different problems necessarily.
I have seen you use irrelevant for describing Jini a couple times. My view is it is very relevant
in its current form just maybe not as popular or well known, which may be your meaning, but
it isn't a model one would use in every application nor is it related to web services necessarily,
nor is it really understood by many. I would argue the same thing about Java EE and EJB. Not
understanding something doesn't mean the issue it solves isn't relevant nor is it wrong at
the base layer in the overall approach to solving the problem, but don't let that confuse
the issue that things can always be made simpler such as deployment or installation and embedding

Realizing no one needs a course on WS, XML web services are all about interoperability and
single point RPC and data transfer; at least this is their initial design, and this is why
we now see REST and different remoting protocols for things to try to make these things more
performant as they were not designed to be used the way they are actually being used today
as full blown application support, and is why RMI and other things still have their place
versus XML web services. I feel most of these technologies have been a little misused for
the sake of heterogenious front ends at the expense of performance, or in the case of RMI
at times, used for data transfer at the expense of heterogenious data access calls; at least
this is the only way I can explain the constant shift in patterns as it relates to them JAX-RPC,
JAX-WS, *-RS, what's next :-). Jini as I see it is about performance driven distributed discoverable
services which provides not only
 services, in the sense different from web services, but distributed and concurrent memory
through JavaSpaces. A totally differnet technology though solving some of the same issues.

Now, if there is a market for such support under the hood, to operate over SOAP and web services,
but not as the default or main reason for Jini's being, then I don't think that is a bad thing
necesarily. The transport layer is already pluggable, but to me really, the only thing that
solves, as services are not defined in something like WSDL but instead interfaces etc, and
that seems that would just be a whole lot of work to not necessarily solve the real issues
with Jini at the moment which seem more related to learning curves and not the technology
itself except for those things listed as needing to be addressed. Folks are using Rio and
like and they seem to find most useful the general concepts of Jini because they solve unique
problems really. As it relates to web services or any other kind of service, and as it relates
to Java per the nature of Jini, I think Jini could be used to locate or integrate about anything.

> 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!

Again I argue solving different problems here. Jini isn't WS nor REST, and the discovery mechanisms
in Jini, through interfaces and remote downloadable code, are more descriptive and powerful
than what DNS Srv and multicast DNS (JMDNS) is trying to solve. JMDNS tells you where a given
service is by protocol and what port where as Jini gives you the services and they can use
what ever kinds of proxies and interfaces they have been programmed to use and then system
administrators need to follow whatever documentation is available for those services such
as open ports XYZ on firewalls and routers etc. 

Take my Dell 1720dn printers. The driver is installed by a disk, and is running in the OS
as an OS level service as a printer driver. It then communicates on the ports the service
in the printer is configured. I have to configure my network or them to deal with the situation
depending on my needs. Jini works on this level except the device or remote services remotely
install their own code through the service versus a driver disk. This can be in a desktop
or server computer or on some other small type device which can implement the Jini protocols
and class interfaces etc. This is a little different than DNS level services or service by
name or protocol. Suttle from a birds eye view, but very different at the implementation and
problem/domain level.

> Why couldn't Jini explicitly address the service discovery challenges
> currently prominent in mainstream SOA?  Why can't I log into my machine and
> 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.

Pretty much Jini solves this although not through a UI of some sort, but instead for other
applications through API. Now, the security stuff I'm not all sure about yet, but you can
do that for sure. It would be very easy to filter per roles and security as long as the services
you have coded are using some kind of interface and you can ask them if you have rights to
use them etc based on some credential. I don't really know what is and isn't supported at
the Jini level as it relates to security other than building it in yourself, but this is one
of the things which has been talked about addressing in the thread where a list of wants and
needs was listed.

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

There isn't anything keeping Jini from working on a broader network now that I know of. Routers
need to be configured to forward multicast packets. Over the internet can be an issue because
of packet delivery etc. Many ISPs won't support multicast. This is where Unicast comes in

> I would (almost) bet money that various Jini/River-based projects (currently
> floundering in obscurity) address or begin to address these challenges /
> needs?

Sure. This happens with anything solving harder problems. This is the exact same thing with
Spring, Hibernate, and others as it relates to JEE, and look at the ideas which have been
moving into JEE over the passed two iterations (one in the works 6). That makes the core standards
and ideas better. There has to be some central ideas for other things to build atop. Had there
not been JavaBeans would Spring look the same today? I doubt it. What about JEE? What if JEE
didn't exist? Then would Spring exist? If so, then where would the standards related to clustering
and session replication have come, what about those central ideas? This is the nature of the
business yet folks tend to forget it and not see it, and is why JEE tends to get a bad rap
too, and folks forget all the problems JEE solves such as clustering, session replication,
distributed and remote services and data, transactions, and scheduling.

> 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."

Here I point to my last paragraph how things build on top of other things. At the heart of
Jini is a pretty unique problem solving solution; similar here and there to other things yet
not the same. That core value is there. Now, making that core value easier to use and more
approachable/adoptable shouldn't limit what it can do, but should merely allow a set of abstractions
which make it easier yet do not get in the way when one needs to get low level with the technology.
I have used different APIs in different technologies and environments which could have been
much better if there hadn't been too much hand holding without exposing the hairy details
if needed, and those things are fine when the problem you solve is simple, but when it gets
complex it is better to have the details in the open so that one can become an expert and
get the most from the system.

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

I don't want to beat a dead horse, but I feel it would be useless to simplify or as has been
said to dumb down the technology. It has to be kept in mind that the capabilities do not need
to be simplified except where it might improve them, but some abstractions and fluff needs
to be added to simplify the technology. No fluff is great when a problem is as easy as REST
or a single connection to a single point or asking something where something is in a very
generic sense, but Jini solves more technical and difficult problems. I'm all for simplification
where it needs to be done, but not at the expense of functionality, and I think you can get
both with abstractions, build systems, installers, tooling etc, for making things more approachable
for beginners and intermediate use, but those at the top of the food chain are not going to
find use in the technology if overall things are simplified and dumb downed. In that regard
I don't think it is possible, and
 folks need to realize the differences in the problems being solved by the different technologies
being talked about and not just the differences in the technologies.

I agree some uses need to be detailed and some applicability needs to be demonstrated for
folks to see. I too agree that it needs to be more approachable, but I think that is best
handled through abstractions and tooling leaving the capabilities intact. Too, the web site
and advertising the technology is important.

> 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!

Yes, and this is where examples can help. Examples from different walks of life. Jini can
be used for simple things such as:

*) Service to lookup databases, servers, and ports for data access in a relaxed client server
model applications.
*) Service to locate web services of a given type within a network.
*) Service to lookup and load code which embeds libraries to access the server layer of strict
client server model applications.

and for more complicated things:
*) Service to lookup and operate on premises cameras.
*) Service to lookup and monitor different security systems and devices on premises.
*) Service to lookup and manage different on board sensors on a car or other transportation
*) Service to lookup and access RFID readers.

and of course both lists can go on and on. I believe some good and simple examples can be
created for the application level support. Some of the others can be done as well but depending
on those examples where hardware is involved more expense can be involved, so those have to
be studied more closely to see who wants to do them or what can be done cheaply and show off
what can be done.

> 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! :-)

Yes! I guess I get a little confused as you bring up Web Services and REST. Do you mean support
those things in tandem or what exactly? Do you mean more example uses of Jini using these
technologies? Do you mean to change Jini to use these technologies instead of the way services
and logic are downloaded now?


View raw message