Sunday, November 06, 2005
JINI still trying to escape the bottle.
Dan posts on JINI wish lists and SOAP comparisons. Well, I've posted before about JINI here, so I've asked for a few things.
With my current interest in compute grids, there are a few things I'd ask for:
With my current interest in compute grids, there are a few things I'd ask for:
- Sort out the class caching -- whether it's the JAR cache or the class loader, I want to be able to flush the classes used in compute nodes. No, I don't want to implement it myself, I want a standard mechanism (or a mature OS implementation). It could be automatic somehow (say, classid based), but a metadata driven option would be better (eg this job depends on lib version 2.3c).
- Play nice with other platforms -- discovery is essentially a wire protocol, so where are the python, .NET, Ruby implementations? Build a JINI framework in the other langs, and provide some form of interop. On service discovery, declare the proxy's host requirement for the proxy -- this can include the implementation platform.
- Demonstrate real systems using this. A single travel agent and an rfid system aren't enough. The core community needs to prove better, cheaper, lower risk systems before other people will jump in.
- Again, keep lowering the barriers to entry, working examples (and simple ones), simplified config, example configs for typical projects. Books are useful -- you don't need a big publisher however, a small one will do, or a self-publish book.
- Integrate with Spring, Globus, DataSynapse etc etc, integration is key. Make it easy to add it to an existing project, this lowers the adoption risk.
Comments:
<< Home
Hi Ken,
Some quick feedback...
On JAR caching: You can only flush a class if it's no longer used and that's actually something the JVM can do anyways. It doesn't flush .jars of course and some of that is a core library issue (not specifically a JINI problem). For classes that are in use, we actually have to get the client to suspend all it's threads for some period of time whilst we do the work. i.e. it's a co-operative exercise. You may get more mileage from some of JDK 5.0's features for profilers/debuggers but I'm not yet convinced that would satisfy your requirement.
Discovery is indeed a wire protocol but the upper layers require that we download a proxy to the client JVM which most other languages don't support so readily. I'd be more tempted to go via the gateway route which can interface between other languages and Java. IMHO, it's probably not good practice to expose the implementation of detail of a service in the form of host requirements - the whole point of a decent SOA is to conceal this sort of thing hence my thinking on gateways.
On usage: Well, there are plenty of other real systems (and I've consulted on a number of those) other than the well known two you list but most still insist on silence. We're working on that one - probably some kind of "powered by JINI" statement or whatever.
On the book: Yes, self-publish may be an option - it's a cost vs return issue for most of us would be authors - I can't give up my day job to write it :(
On integration: The Spring thing is being worked on - http://www.jini.org/meetings/ninth/Spring.pdf though that's only one approach. I'd like to hear more on this from you - specifically what you think the advantages are here.
Post a Comment
Some quick feedback...
On JAR caching: You can only flush a class if it's no longer used and that's actually something the JVM can do anyways. It doesn't flush .jars of course and some of that is a core library issue (not specifically a JINI problem). For classes that are in use, we actually have to get the client to suspend all it's threads for some period of time whilst we do the work. i.e. it's a co-operative exercise. You may get more mileage from some of JDK 5.0's features for profilers/debuggers but I'm not yet convinced that would satisfy your requirement.
Discovery is indeed a wire protocol but the upper layers require that we download a proxy to the client JVM which most other languages don't support so readily. I'd be more tempted to go via the gateway route which can interface between other languages and Java. IMHO, it's probably not good practice to expose the implementation of detail of a service in the form of host requirements - the whole point of a decent SOA is to conceal this sort of thing hence my thinking on gateways.
On usage: Well, there are plenty of other real systems (and I've consulted on a number of those) other than the well known two you list but most still insist on silence. We're working on that one - probably some kind of "powered by JINI" statement or whatever.
On the book: Yes, self-publish may be an option - it's a cost vs return issue for most of us would be authors - I can't give up my day job to write it :(
On integration: The Spring thing is being worked on - http://www.jini.org/meetings/ninth/Spring.pdf though that's only one approach. I'd like to hear more on this from you - specifically what you think the advantages are here.
# posted by 
: 10:34 am
: 10:34 am << Home
