I work with and have spoken with a number of people who say things like, "I LOVE the concept of JavaSpaces - I just don't want to bring all of Jini with it".
What they are really saying is they love JavaSpaces - TupleSpaces really, they just can't stomach the mobile code bit. These are not stupid people. Honestly, this includes me a lot of the time.
Most of these people lived through J2EE and wouldn't bet their job on auto-deployment of a .war file or .ear file work - why should we think something more complex (downloading the code) will not result in panic? I remember talking to BEA about their auto-deployment - some engineer said they had something like a 120 page spec on this functionality alone (and it still didn't work).
I could just send Dan Creswell an email, but I've heard this comment so often that I figured I would put it out here for all to see. I'm sure this topic has been discussed before - thing is it still is being discussed.
Dan, others, are we neophyte's just wimps for fearing mobile code?
How hard would it be to de-Jini JavaSpaces?
Is this completely out of the question, stupid, etc.?
For JavaSpaces to see a lot of mainstream usage 1 of 2 things needs to happen IMHO:
- Educate the neophytes on the power of mobile code. Help them not fear it. Help them to convince their infrastructure and security groups that it is viable
- Create a JavaSpaces sans Jini (really sans mobile code) version
8 comments:
When I looked a few years ago, there were at least two other implementations of tuple spaces than JavaSpaces. I don't know if JavaSpaces killed them off or if they're both still out there.
From my experience in using tuple spaces for distributed processing, it's at least as hard to understand as event-driven.
Hi Mike,
I'll frame my answer with a question:
If one spent their life messing around with J2EE solutions, and never touched the Jini solution how would they know with any certainty it's more complex?
I've said this before, there are way too many people out there making judgements about this or that "new" technology based on what they know of other completely un-related "old" technologies.
What happens when you install that J2EE .jar?
* The JVM dynamically loads classes from it on the fly
* The difference is your .jar comes from disk rather than via http, ftp or some other protocol
But codebase breaks when the network breaks right?
* Virtual IP addresses, load balanced web-servers or a custom protocol smart enough to failover amongst a collection of web servers can solve that problem. So we have ready solutions available and we could write something pure software if people want it
Jini's code-downloading is different because we have a defined model for how classpaths etc are laid out.
* We've done it different - it's not like applet or RMI code-downloading
* The client classpath contains (typically at most) jsk-lib.jar, jsk-platform.jar and sun-util.jar plus whatever other .jars a client might need (e.g. commons-collections) and the code for the interfaces of the services it wishes to use
* All the remaining service code a client needs is downloaded at runtime. No need to pre-install RMI stubs for example - we've had dynamic RMI proxies in Jini since JDK 1.4 not too mention Jini RMI (JERI) can run across http, https etc and has plugin support for protocols
* That service code the client needs on it's classpath is the same as that which you'd use for compilation in your IDE by the way
Need to update a service?
* Simple, start up a new version of the service, stop the old one
* Clients (because they adopt the Jini programming model) see the old service die and perform a lookup to discover the new one at which point they download the new service's code and we're off again. We encourage programmers to handle all the issues around versioning up front - not nice right? But not as not nice as trying to manage your versioning when you didn't think about it up front
* Of course, if you'd rather do it J2EE style you can restart all your clients having figured out what their new classpath's need to look like etc and go through all the classpath hell you're used to
* Note I can validate my service is properly configured simply by pointing a service browser at it - if the service is broken in some way, I'll get warning messages. And I can do all this in a private lookup service (running on my own machine for example) before moving the service to the public lookup services (which can also be done through the browser)
On security:
* Jini has a security model for downloadable code
* jars can be made tamper proof
* There's support for authentication, authorization, integrity and confidentiality on a service by service basis with varying (and customizable) levels of armour - straight username/password all the way to Kerberos and so on
* And all of this can be done via configuration
I'll finish with two things:
Jini, IMHO makes things simpler - you manage _all_ issues, like security and code packages on a service by service basis, you don't manage at container or bean level - you manage at service interface level - a simple, clean, intuitive boundary. And _that_ is the real benefit of code downloading which is frankly just an enabler.
Jini code downloading is _not_ RMI code downloading - don't try and use java.rmi.server.codebase - use the starter package in com.sun.jini.start and do it right. And ask for help _before_ you try and do it alone - get your ass onto Jini-Users and ask those dumb "help me" questions so's we can improve installers, write appropriate documentation etc.
Dan Creswell
http://www.dancres.org/
One more thing I'd like to mention is that many complain with something like "Jini doesn't work in my existing container".
And that is indeed true but it's because your existing container enforces static, fixed classpath style constructs whilst Jini does completely the opposite.
It can hardly be a surprise that these two don't work well together! Is that Jini's fault for being different or the container's for being inflexible?
Okay, so all that said let's ignore the politics - we're making progress, I'm hearing good things about GlassFish and the Jini community is attempting to build container type models that work well with Jini. We're also looking at integration with OSGi.
Dan.
Thanks Dan,
As usual you have great points.
Patrick Logan has some more specific questions that we will ask on the user list.
My point was more general - this is the type of response you get from lots of smart people (honest they are!). Yes these smart people have to be willing to learn something new (including me).
You are right Jini and J2EE are different. This is good.
But in order for Jini to see a real uptick in mainstream usage somehow these J2EE folks need to be educated in a way that will make them not just walk away from the technology because of things like mobile code.
I have found heaps of articles going all the way back to 1999 that talk about various bits of the technology, but it can be hard to find clear information that "hits me where I live". This type of information will be great to capture in a wiki etc. or some FAQ for people in need of J2EE de-programming. Obvious places would be http://www.jini.org/wiki/Category:FAQs or http://incubator.apache.org/projects/river.html
I went ahead and added a page to the jini.org wiki on this topic here: http://www.jini.org/wiki/How_does_mobile_code_work%3F
Mike
Okay, so now I'm very interested.....
"I have found heaps of articles going all the way back to 1999 that talk about various bits of the technology, but it can be hard to find clear information that hits me where I live"
Can you explain "hitting you where you live"? What is that?
And could you explain more about why people reject mobile code? Because this.....
"But in order for Jini to see a real uptick in mainstream usage somehow these J2EE folks need to be educated in a way that will make them not just walk away from the technology because of things like mobile code."
....doesn't speak to me of education. It has all the overtones of bad engineering plain and simple. It suggests to me that people are too ready to knee-jerk and assume rather than think. Education doesn't fix that.
So I figure I'm missing some crucial (general) point.....
Dan.
I kept looking at my last post and couldn't figure out why I didn't like it. I think it's cos I can't convince myself the questions I've asked are getting directly to the core of the issue.
Perhaps a better question is:
Why do people perceive mobile code to be any more complex/less manageable than the current classpath and J2EE deployment hell?
Is it sufficient to explain how mobile code works or do we need to cover the whole piece - like here's mobile code, here's how we secure it, here's how we make it reliable?
If it's the latter, that's a substantial topic, what's the best way to break this down into small easily consumed chunks?
Dan.
> Jini's code-downloading is different because we have a defined model for how classpaths etc are laid out.
Where do I find this type of info - I feel like I'm missing some key bits of documentation?
> Need to update a service?
> * Simple, start up a new version of the service, stop the old one
How do deployments typically work? How do you make sure that in process transactions don't fail etc.?
> We encourage programmers to handle all the issues around versioning up front - not nice right? But not as not nice as trying to manage your versioning when you didn't think about it up front
Where do I find more information on this?
> Of course, if you'd rather do it J2EE style you can restart all your clients having figured out what their new classpath's need to look like etc and go through all the classpath hell you're used to
I like pain and I like JavaSpaces - it might come to this. How do I do this?
> One more thing I'd like to mention is that many complain with something like "Jini doesn't work in my existing container".
But I need at least a web container and perhaps JMS. How do I get these to work together - how for instance do I make Blitz work with JBoss? I assume I can do write, read, take? How does mobile code work here?
OSGi would be great.
The "hitting me where I live" bit was a fairly lame way of saying I haven't found anything yet that clearly explains mobile code. I read bits and get it a little more, but I hear warning bells going off in my head about ClassLoader issues etc. I think that if we can get that wiki page filled in I will finally get it. I certainly can do more of my own homework.
> ...doesn't speak to me of education. It has all the overtones of bad engineering plain and simple.
I really think it is education. Anyone coming from J2EE IMHO will react this way. Like I said several people have made the comment about mobile code. I'm convinced it comes from ClassLoaders. I think my example of app servers not being able to get auto-deployment right is exactly the analogy people use in their head to say no thanks. J2EE beat people into submission. J2EE made people pick the simplest approach. J2EE made people fear complexity. There are certainly those that won't listen, but right now I don't think the proper resources are readily available that will concisely explain the Jini mobile code philosophy. I'm not certain that I just haven't stumbled across it yet. Due to the web site move a while back (I think?) it can be hard to find things.
> Is it sufficient to explain how mobile code works or do we need to cover the whole piece - like here's mobile code, here's how we secure it, here's how we make it reliable? If it's the latter, that's a substantial topic, what's the best way to break this down into small easily consumed chunks?
Unfortunately I think it is all this + whatever else I put on the wiki page. And probably even more. I think that starting with the basics in how it works and how it is different / how it isn't the same thing as auto-deployment of a .war file for example is a great place to start. If we can get past that then I assume the rest is detail. Right now I am battling the fear that this is even achievable in a large corporate environment. I'm scared of botched transactions etc. I assume I just don't get it.
Thanks for listening.
Mike-
I suggest if you want to look more at the Jini side, then you can do a lot worse than look at some of the Jini projects on java.net http://jini.dev.java.net
As someone new to the technology, perhaps have a look at glyph (https://glyph.dev.java.net) and give me some feedback, if you'd be so kind.
Thanks
--Calum
Post a Comment