Monday, November 14, 2005
Jini feedback
I got a comment, I think from Dan, on my last Jini post.
JAR caching:
Discovery & other languages:
Publicly known Jini impls:
JAR caching:
It doesn't flush .jars of course and some of that is a core library issue (not specifically a JINI problem).Afaik, using a different jar: url handler should be able to skip the default one and it's handling/caching. If, the core library (/Sun) can't be persuaded, then it's time for a Jini/OSS one to replace it. If a new handler can't be used to fix this, then Sun need to look hard at Jini support and fix this -- applet containers can do this today...
Discovery & other languages:
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 requirementsHmm, but for a given service, you don't want to have to create a gateway per service interface etc. I don't see why this can't be a standard field on an Entry -- open to interpretation by the node / filtered at the registry. The key thing is plug and play for other platforms -- there's no need for ANY java in the system if you remove the gateway.
Publicly known Jini impls:
"powered by JINI"+1.
Comments:
<< Home
Hmm, but for a given service, you don't want to have to create a gateway per service interface etc. I don't see why this can't be a standard field on an Entry -- open to interpretation by the node / filtered at the registry. The key thing is plug and play for other platforms -- there's no need for ANY java in the system if you remove the gateway.
The power of Jini is mobile objects. Everything else is science related to transactions, leasing and security. Using JERI to bridge between two different platforms will best be done with a gateway service that can download the service proxy, run whatever code that is in that proxy, under java, and then mascarade the interface in a form that the other platform needs.
If you try and make the point of interface be the service registration, then you are presupposing that you'll know every possible use of the service. The great thing about Jini is that you can use service lookup to find things that didn't exist a moment ago. This allows the gateway to adapt and manage the interface to the world, and to keep the service clean an unburdened by the other users.
This is not a simple problem. Plain and simple though, mobile objects is the power of a pure Java solution. There might be some simple solutions for certain classes of problems. The lack of massively visible solutions, says to me, that people might be trying to deal with the problem themselves. Because it requires a particular level of customization there isn't much that seems reusable.
An interesting thing for me is that the people who are behind Jini, are people who have had years of experience with the "everythings a string" technologies around awk, sh, perl, cut, paste etc. They don't want to do that any more it seems. The people behind XML, are microsoft, who developed all kinds of proprietary binary protocols. They don't seem to want to do that any more.
Maybe we'll find something in between that lets you get the data, and ignore the code if you don't want to, or can not use it...
Gregg
The power of Jini is mobile objects. Everything else is science related to transactions, leasing and security. Using JERI to bridge between two different platforms will best be done with a gateway service that can download the service proxy, run whatever code that is in that proxy, under java, and then mascarade the interface in a form that the other platform needs.
If you try and make the point of interface be the service registration, then you are presupposing that you'll know every possible use of the service. The great thing about Jini is that you can use service lookup to find things that didn't exist a moment ago. This allows the gateway to adapt and manage the interface to the world, and to keep the service clean an unburdened by the other users.
This is not a simple problem. Plain and simple though, mobile objects is the power of a pure Java solution. There might be some simple solutions for certain classes of problems. The lack of massively visible solutions, says to me, that people might be trying to deal with the problem themselves. Because it requires a particular level of customization there isn't much that seems reusable.
An interesting thing for me is that the people who are behind Jini, are people who have had years of experience with the "everythings a string" technologies around awk, sh, perl, cut, paste etc. They don't want to do that any more it seems. The people behind XML, are microsoft, who developed all kinds of proprietary binary protocols. They don't seem to want to do that any more.
Maybe we'll find something in between that lets you get the data, and ignore the code if you don't want to, or can not use it...
Gregg
# posted by 
: 7:17 pm
: 7:17 pm
Hi Ken,
Yes it was me - sorry I didn't id myself I realized just after I hit publish of course! Duh.
Yeah, the URL handler can help but it's more complicated than that:
http://archives.java.sun.com/cgi-bin/wa?A2=ind0201&L=jini-users&D=0&I=-3&P=31033
Also, do you think specifying an additional handler on the command-line or whatever is acceptable?
On the gateway - I meant a single gateway handling the bridging for a number of service interfaces think of something that looks like JINI lookup service on one face and something else on the other (say a UDDI registry or whatever). That's one solution not _the_ solution of course just an indication of my thinking.
Post a Comment
Yes it was me - sorry I didn't id myself I realized just after I hit publish of course! Duh.
Yeah, the URL handler can help but it's more complicated than that:
http://archives.java.sun.com/cgi-bin/wa?A2=ind0201&L=jini-users&D=0&I=-3&P=31033
Also, do you think specifying an additional handler on the command-line or whatever is acceptable?
On the gateway - I meant a single gateway handling the bridging for a number of service interfaces think of something that looks like JINI lookup service on one face and something else on the other (say a UDDI registry or whatever). That's one solution not _the_ solution of course just an indication of my thinking.
# posted by : 9:44 pm
: 9:44 pm << Home
