Saturday, December 11, 2004
Jini meeting, part 2.
Brian Murphy
Brian presented on how advancement in any area requires people to break away from the established norms and do things differently. In the end it was a pretty good talk, a relief at last. It certainly explains why Jini is interesting to a lot of people and also why the academic bias in a lot of projects is there -- it's almost the anti-thesis of what corporate IT is all about.
Simplicity
In my day job (technical architect for a bank) I'm always interested in novel design solutions from projet teams. However, the general path I try to guide them on is the one of simplicity. I'm afraid Jini just doesn't satisfy this yet. While the concepts are remarkably simple, the current implementations, infrastructure and other complexities, as far as I can see, fail the KISS tests.
The other problem with Jini is the lack of body of knowledge, both documented on jini.org and in the form of examples. To illustrate, take the one example supplied with the starter kit. OK, so it's quite clever to have 4 classes or so illustrate many combinations of startup configs (network protocols, authentication/activation schemes per service type etc), but that's not really a great way to introduce a newbie.
On installing the starter kit, where'd you expect to find the examples?
The Sun guys seemed genuinely keen to find out why jini isn't taking on. Which is nice, but I have to say there are some pretty obvious problems. I'll list a few. I know a bunch of good stuff is coming in 2.1 but wanted to empty my head ...
Right, back to the conference.
RFID
An OK session about the use of jini in a customer solution. Like most sessions, I didn't really get into this one. The technical details about the project seemed a bit sparse.
Gary Kendall
Gary's written a mini-calculation grid using Jini. Excel calls a web service which distributes slices of calculations amongst a number of user PCs. This is probably the sweet-spot for simple Jini apps, I think.
F1 Telemetry
Probably the best session of the meeting, imho. Interesting subject, good level of detail of what they did, problems solved, plans for new stuff. Just the structure of this was better than everything else. The single biggest thing, though was the discussion of issues and solutions, also it was a REAL project, not just a university project (not to diss students, but most projects are not worthy of a commercial technology presentation, most are also disturbingly naive).
Mike Warres
Another good session (actually enjoyed this afternoon compared to the paucity of previous sessions). I was getting worried at the start when Mike was suggesting the opaque:
Community Lessons
A pretty good session about how to break and then fix a Javaspace impl by throwing fairly ambitious (aka silly) problems at it; a whole video stream; each frame of a stream; each pixel?!
Conclusion
Well the Meeting has certainly re-kindled my interest in the Jini world, though after the first day, I was starting to think it was not it good shape. I obviously have a few opinions on what they need to do to increase adoption / mature the offering. I've a couple of other thoughts on Jini ideas, but will use a separate posting, since this one is already too big.
Brian Murphy
Brian presented on how advancement in any area requires people to break away from the established norms and do things differently. In the end it was a pretty good talk, a relief at last. It certainly explains why Jini is interesting to a lot of people and also why the academic bias in a lot of projects is there -- it's almost the anti-thesis of what corporate IT is all about.
Simplicity
In my day job (technical architect for a bank) I'm always interested in novel design solutions from projet teams. However, the general path I try to guide them on is the one of simplicity. I'm afraid Jini just doesn't satisfy this yet. While the concepts are remarkably simple, the current implementations, infrastructure and other complexities, as far as I can see, fail the KISS tests.
The other problem with Jini is the lack of body of knowledge, both documented on jini.org and in the form of examples. To illustrate, take the one example supplied with the starter kit. OK, so it's quite clever to have 4 classes or so illustrate many combinations of startup configs (network protocols, authentication/activation schemes per service type etc), but that's not really a great way to introduce a newbie.
On installing the starter kit, where'd you expect to find the examples?
./examples?Err, no.
./demo? (as per the jdk)
./docs?
./samples?
./source/vob/jive/src/com/sun/jini/example/hello/Right. Though, I have to say, it's almost refreshing to see a Jini/Javaspace example to actually use a package name -- most seem to live in the default namespace. This is presumably done to make compiling from the command line easier. However, Makefiles, yes, Makefiles are used to compile Jini in the starter kit. Not Ant. Not Maven. Makefiles. One of the great strengths of the makefiles is that they run really nicely on any platforn just like the Java code. Err, sorry, no. Unix only please. Not even under cygwin (until after some liberal sprinkling of vi/ex commands and the odd hack).
The Sun guys seemed genuinely keen to find out why jini isn't taking on. Which is nice, but I have to say there are some pretty obvious problems. I'll list a few. I know a bunch of good stuff is coming in 2.1 but wanted to empty my head ...
- Licence -- BSD/Apache please, otherwise make it a product. I don't want to spend time on something that I can't do what I want with unless there's a low barrier to entry.
- Productise Jini. Define a spec, not an implementation. Allow decent competition against the standardised interfaces.
- Evolve. Jini has been around for years. Not much has changed. OK 2.0 gave us Jeri etc, but one of the big changes coming is iterators for a Javaspace. Woo. Can I pass a predicate instance to the space to match entries? Err, no. Not yet. Why not?
- Dogfood -- where are the Sun products? Is Jini baked into the app server? The directory server? Solaris? Jini seems to be almost the perfect way, ostensibly, to build a J2EE app server -- dynamic instance regstration, code deployment, persistent messaging / sessions etc) -- if not, why not?
- Accounting. This is one of the last barriers to trusting code -- I may be able to stop it hitting the filesystem, can I sensibly stop it doing while(true) {} ? If I'm going to host code, I need to be able to stop it without killing the whole process.
- Join thy brethern. Java is huge. J2EE is huge. Get on that bandwagon.
- Is there a standard, supported JCA adapter to call an EJB? No. Yes, there are some thread issues etc to think about, but it can't be that hard, especially since you can push much of it back into the client -- it's then just like any other remote call.
- Standard JNDI / regie bridge / helpers. Why is reggie not just a DirContext? Waldo was saying to me that he didn't think reggie was a good option for enterprise wide service lookup -- a model is needed.
- Unify the transaction models. OK, so you can generally live without XA/2PC but it makes a lot of projects simpler. I bet outrigger (Javaspace impl) probably doesn't do full recovery - including rolling forward. JTA/XA has momentum -- can I get an Oracle JDBC driver that uses Jini 2PC? I know I can plumb it myself probably, but that's an engineering task -- that's what I want to buy from Sun. Charge me, really. Better yet, make adapters for all sane components (Sybase,Oracle,JMS,Javaspace impls).
- Provide a way to go JMS <--> javaspace.
- Fix the web site. Where're the docs? It's not clear that Rio is a major project, almost part of the starter kit, it seems. Why are there 10+ container projects? The must be some serious synergy. The new container spec -- is this distinct from Rio? how? Get away from the template site from CollabNet -- why not more like java.sun.com? Much nicer / easier to use.
- Make the experience great.
I love the stuff codehaus has on some projects: the 1 minute, 5 minute, 10 minute guides to the project (linked as well).
- Get people excited as quickly as possible.
- Then make the download / install / helloWorld a no brainer. All I want is a build.xml, or a shell script -- don't make me compile before running (or make it seemless).
- First example should be a sanity check, minimal stuff. Are the services running? If not why not start them, or tell the user, not a stack trace / barf.
- Separate examples to show different things. Don't provide multiple classes (hidden as inner classes too) to make things look hyper flexible. There's loads of code in those classes.
- Supply helpers -- most examples I see supply helper classes. Why aren't these standardised, a la Jakarta commons-jini, say?
- Get rid of makefiles.
- Show stuff you can't do easily without Jini.
- Get people excited as quickly as possible.
- Find a bridge with WebStart -- where's the overlap between this and Jini ServiceUI? Is it just caching? Or versioning of jars too? Can I launch a non-applet from a browser (perhaps via an applet bridge).
- Just to make it 10 -- Isolation API, how does that work with Jini? Should proxies be different isolates?
Doh! More have popped into my head...
- Resolve the non-Java issue. JNI is evil, don't rely on it (or fix it - zero C code). You HAVE to play nice with .NET and others. Surrogate is OK for a subset, but why can't I use discovery and lookup directly from C#? They're based on wire protocols, so should be do-able. Can the implementation requirements of the proxy (ie JVM/CLR) not just be part of the entry's properties? If a CLR gets a Java proxy -- it should be able to bridge across the process.
- Talk about more than HelloWorld. There seems to be a dearth of intermediate to advence documentation (it's probably only found in email chains). For example, what are the design strategies -- should you pass complex objects, with behaviour, into a proxy? Or should the API's be fairly data centric? That's certainly the impression I've gotten from previous RMI projects. If behaviourly complex objects are passed around, then you REALLY need to make sure they only know about a fixed API. The whole separation of concerns is very important, otherwise you'll end up with a ball of mud -- re-write time!
- Err, Web Services -- define a sane JAX-RPC bridge, both client and server side. If you want to push to boat, you could define a protocol negotiation based on SOAP headers that allow you to drop to Jini as a pure Java optimisation. Since this can actually be a per-service protocol, massive gains are possible in performance, all without reducing the compatibility with other clients.
I posted the next two on a JINI-USERS posting, but it seems to have died on the moderators cutting room floor.
- IoC. The rest of the Java world, including EJB3 are looking to IoC containers to do much of the donkey work of wiring apps together -- this is ideal for Jini. Sorry, can I say that again - Jini plugins for Spring/HiveMind/Pico will increase adoption. In the current trend, everybody is using interfaces and wiring objects with config -- a perfect fit for the nastiness of exporters/SDMs/preparers etc.
- AOP. The other big trend. Dynamic class loading -- time to instrument those classloaders with aspects. Work with the Aspect* teams to get hooks. This will increase exposure and get Jini into the hands of lots of other early adopter communities -- aspects will also help debug/build these things.
- Wiki. Trawl the mailing lists and build a wiki FAW with the info -- all the answers are here, get them into the users' hands.
- Roadmap -- what is it? I hear there's a 2.1, how about 2.2? 3.0?
Right, back to the conference.
RFID
An OK session about the use of jini in a customer solution. Like most sessions, I didn't really get into this one. The technical details about the project seemed a bit sparse.
Gary Kendall
Gary's written a mini-calculation grid using Jini. Excel calls a web service which distributes slices of calculations amongst a number of user PCs. This is probably the sweet-spot for simple Jini apps, I think.
F1 Telemetry
Probably the best session of the meeting, imho. Interesting subject, good level of detail of what they did, problems solved, plans for new stuff. Just the structure of this was better than everything else. The single biggest thing, though was the discussion of issues and solutions, also it was a REAL project, not just a university project (not to diss students, but most projects are not worthy of a commercial technology presentation, most are also disturbingly naive).
Mike Warres
Another good session (actually enjoyed this afternoon compared to the paucity of previous sessions). I was getting worried at the start when Mike was suggesting the opaque:
md:314159627while it would work, can you imagine debugging this? You definitely need the filename, if only for sanity. Good depth, a project to watch.
Community Lessons
A pretty good session about how to break and then fix a Javaspace impl by throwing fairly ambitious (aka silly) problems at it; a whole video stream; each frame of a stream; each pixel?!
Conclusion
Well the Meeting has certainly re-kindled my interest in the Jini world, though after the first day, I was starting to think it was not it good shape. I obviously have a few opinions on what they need to do to increase adoption / mature the offering. I've a couple of other thoughts on Jini ideas, but will use a separate posting, since this one is already too big.
