Tuesday, December 07, 2004
Jini Community Meeting
Actually, I started at the Kickstart session on the Monday before. This was a high level view of Jini and Javaspaces. I suppose I should have read the description in a bit more detail, since the session was very high level and more of an introduction for those who'd never read up or used either technology. The best part was a (unfortunately) brief discussion on when to use Jini/spaces over the more established J2EE based products. The feeling was that compute farms and workflow are the sweet spots, classic client server or pub/sub or even queuing systems should go down the normal roads (eg web/web services).
Pub session (who me?)
Chatted to John ___ , about the continuous bleeding edge nature of Jini/spaces. For example, if Sun believe in the technology, why don't they use it? Where are the products? I get the feeling Jini is pretty much a toy system (in terms of usage rather than potential or capability) -- ie most people pick it up, turn it over then decide that the effort needed to fully understand it, due to lack of overall mindshare / knowledge / experience is too high, and that either a much simpler home grown approach is sufficient or that using J2EE apis instead is the best route.
jini.org
I've just taken another look at the jini.org website, and I have to say it's not very inviting. It doesn't provide (that I can see at first glance) a list of tutorials, list of docs, a list of samples etc. It has a number of links to lots of projects in various states of decay / liveliness. There seems to be x (10, 20+ ?) service container projects --- why so many? Can people not agree on features? I don't want to learn loads of different containers just to get some simple services running without writing my own container.
While I'm ranting, thought I'd complain about the use of project names for all the support services -- reggie (ok I can guess this is something to do with registration), outrigger (err, does what?), mahalo (hmm, not much to give it away), etc, etc. This just raises the barrier to entry since you have to remember the different names for each service. I don't understand why something like registryd, lookupd, javaspaced, transactiond couldn't be used -- at least I'd have a chance of guessing what each one does.
I seem to remember an old Jini distribution by JPower (i think) - this was basically a jboss instance which launch all the services you needed, preconfigured to talk to each other - all you needed was to start a client or service vm. tada. thankyou. goodnight. This is what we need. Talking to Dan Creswell he says his blitz project provides a much nicer experience -- this should be referenced on the jini.org home page instead of the non-starter kit (grr, reg to download...).
Jim Waldo
Arrived a bit late to this one, but Jim was espousing on topic of keeping object models simple and pure, distinct from non-object identity responsibilities like QoS etc. In particular versioning / type evolution is an area that is often fudged creating more problems down the road than solving it upfront. Unfortunately, as Jim stated, no real solutions, best practices or real suggestions for approaches were put forward -- pretty disappointing.
Dave Sag
Dave explains exactly why you shouldn't trust external firms to design systems when the motivation for the supplier is cv-agmentation. He described a bunch of projects that failed to impress, I have to say the lack of positive outcome (or insightful conclusions), didn't encourage me to ever hire his current firm. The self deprecating humour was a bit over done given the lack of depth. Again a bit disappointing.
Mood Ring
Could have been good, but the demo barely worked (I couldn't get on, but that's probs my ancient 98 laptop being daft). Overall, :o/ .
Tom White
An overview on building a (trivial) compute farm using Jini/spaces. Err, isn't this just the Artima intro slides? The system looked very prototypical - no management, worker reloads all classes for each unit of work(!). Not a great presentation, and not much depth, are you starting to see a trend here?
I'll finish this posting here cos a can't be bothered to write up the lightning session... I'll let you draw your own conclusion.
Actually, I started at the Kickstart session on the Monday before. This was a high level view of Jini and Javaspaces. I suppose I should have read the description in a bit more detail, since the session was very high level and more of an introduction for those who'd never read up or used either technology. The best part was a (unfortunately) brief discussion on when to use Jini/spaces over the more established J2EE based products. The feeling was that compute farms and workflow are the sweet spots, classic client server or pub/sub or even queuing systems should go down the normal roads (eg web/web services).
Pub session (who me?)
Chatted to John ___ , about the continuous bleeding edge nature of Jini/spaces. For example, if Sun believe in the technology, why don't they use it? Where are the products? I get the feeling Jini is pretty much a toy system (in terms of usage rather than potential or capability) -- ie most people pick it up, turn it over then decide that the effort needed to fully understand it, due to lack of overall mindshare / knowledge / experience is too high, and that either a much simpler home grown approach is sufficient or that using J2EE apis instead is the best route.
jini.org
I've just taken another look at the jini.org website, and I have to say it's not very inviting. It doesn't provide (that I can see at first glance) a list of tutorials, list of docs, a list of samples etc. It has a number of links to lots of projects in various states of decay / liveliness. There seems to be x (10, 20+ ?) service container projects --- why so many? Can people not agree on features? I don't want to learn loads of different containers just to get some simple services running without writing my own container.
While I'm ranting, thought I'd complain about the use of project names for all the support services -- reggie (ok I can guess this is something to do with registration), outrigger (err, does what?), mahalo (hmm, not much to give it away), etc, etc. This just raises the barrier to entry since you have to remember the different names for each service. I don't understand why something like registryd, lookupd, javaspaced, transactiond couldn't be used -- at least I'd have a chance of guessing what each one does.
I seem to remember an old Jini distribution by JPower (i think) - this was basically a jboss instance which launch all the services you needed, preconfigured to talk to each other - all you needed was to start a client or service vm. tada. thankyou. goodnight. This is what we need. Talking to Dan Creswell he says his blitz project provides a much nicer experience -- this should be referenced on the jini.org home page instead of the non-starter kit (grr, reg to download...).
Jim Waldo
Arrived a bit late to this one, but Jim was espousing on topic of keeping object models simple and pure, distinct from non-object identity responsibilities like QoS etc. In particular versioning / type evolution is an area that is often fudged creating more problems down the road than solving it upfront. Unfortunately, as Jim stated, no real solutions, best practices or real suggestions for approaches were put forward -- pretty disappointing.
Dave Sag
Dave explains exactly why you shouldn't trust external firms to design systems when the motivation for the supplier is cv-agmentation. He described a bunch of projects that failed to impress, I have to say the lack of positive outcome (or insightful conclusions), didn't encourage me to ever hire his current firm. The self deprecating humour was a bit over done given the lack of depth. Again a bit disappointing.
Mood Ring
Could have been good, but the demo barely worked (I couldn't get on, but that's probs my ancient 98 laptop being daft). Overall, :o/ .
Tom White
An overview on building a (trivial) compute farm using Jini/spaces. Err, isn't this just the Artima intro slides? The system looked very prototypical - no management, worker reloads all classes for each unit of work(!). Not a great presentation, and not much depth, are you starting to see a trend here?
I'll finish this posting here cos a can't be bothered to write up the lightning session... I'll let you draw your own conclusion.
