----- Original Message ---- > From: Dan Creswell <d...@dcrdev.demon.co.uk> > To: river-dev@incubator.apache.org > Sent: Saturday, December 20, 2008 5:51:41 AM > Subject: Re: Split JavaSpaces and JINI > > Niclas Hedhman wrote: > > On Fri, Dec 12, 2008 at 12:30 AM, Gregg Wonderly wrote: > > > >> Perhaps Niclas you can enumerate all the reasons why JavaSpace shouldn't > >> have transactions or leases? > >> > >> I'm dead serious about trying to understand what you are saying. > > > > Ok, let's try this again; > > > > > > I want the 'package' that is offered to "me" to have local-JVM > > implementations that are plug-replaceable with distributed ones. I > > don't want to "yank" out Transactions and Leases, I want to be able to > > use them easily locally without network traffic. > > > > Okay, so you don't mind writing code that handles networking conditions > even though they aren't present in a "local" configuration? > > If that's the case, I don't think you need to write local-JVM > implementations, I think this is back to base-line configurations, > hiding a bunch of stuff, writing some auto-detection/setup code and > merging in some bits that Bob S wrote a while back to do in-JVM > communication whilst looking like JERI endpoints. >
Indeed. To me that would make the most sense if you mean to use the same classes to access a service whether it in-jvm or not (through lookup). Behind the scenes either something remote is connected to or something in memory. Other things support this kind of behavior including EE servers where the JNDI is run in the same JVM. Essentially you perform a lookup of a service and it either comes from a remote location or in-jvm. > > I want an introduction path into this world going through that > > 'local-JVM' variant first, and slowly introducing the more complex > > aspects of Jini to me. I don't want to know that I have 3-4 transport > > protocols, some with endless options, and I don't want to know the > > details of setting up security (just assume I am the ignorant b'stard > > that I am and give me AllPermissions until I sober up). I don't want > > to see configuration files in a "Java-like" language, either give me a > > straight shooting API, properties files or worst-case a Spring app > > context... > > > > I want to deploy my first Jini services and clients in a WAR on > > Tomcat, without having to ask my NetAdmin to alter any setup and know > > that it works out of the box everywhere. > > > > This implies a drift from local to remote - now unfortunately you have > incompatible classloader models to face, network config to do etc. All > those things that are core to Jini that other enterprise setups don't do > because of their environmental assumptions (limited support for > multiple versions, nothing breaks etc). > > So the out of the box stuff I think we can certainly sort, this one I'm > less sure of. Though things like Bantam get you somewhere near. May be missing your total point here, but if the same interfaces are used from client code, yet through some simple configuration in-jvm services can be configured to be immediately accessible through in-jvm lookup it seems that would be doable. That is of course assuming this hits Nicks nail on the head. If talking about services deployed in a WAR file which are intended to be used right off by something on another system, over the network, then the things a system or network admin will have to worry about are multi-cast and the ability to bind ports onto the attached system, so there are always things to worry about in that case for sure. Too, what happens if you deploy multiple WARs? How is the Jini TCP/IP endpoint setup on the system? In that case there needs to be two options, either those things automatically federate and join the service server, can happen now, or they are each individually allowed to automatically configure their own server on dynamic ports depending on the configuration. Possibly stuff in Jini to do this now, and if not probably in some of the extensions which could be gleaned for core ideas. Technically, if there isn't something which I haven't read about existing today, the Jini protocols could be extended to allow service lookup from direct connections to web applications over HTTP. I'm not just talking about remote code download and smart proxies etc JERI, but the lookup mechanism itself. So, if an end client is setup to point to a specific resource on the internet for service lookup that resource could be an HTTP(S) endpoint. This would be without the unicast connection. Not that it is something one would want to use for everything that Jini can do, but that would make it more flexible. > > > I want services to be under the control of Java code that I write. I > > don't want to ever hear about RMID and Activation ever again. I don't > > want to encounter classloading problems when services are in the same > > JVM, even if they depend on different versions of Jini "Core". > > > > You won't get that wish with the classloader models of many existing > containers. Sorry for labouring the point. > If Jini has its own classloader, and services are installed into it much like OSGi or the NetBeans Module system then that seems doable. Fabrizio Giudici is doing similar things in the web applications with the NetBeans RCP and Wicket albeit not with Jini. A base module system can be setup to load different versions of modules, so you can have Jini 1.x and Jini 2.x and then your services could be deployed in that system and each of them can depend on this or that Jini core. Now, that assumes Jini 1.x, 2.x, x.x are installed in a single web application which modules are installed some how. There can be a couple models here though. In another less clear model, you could have a core system register and unregister classloaders and different services with a core static API held in a common set of libraries on a server in some shared folders, almost all containers I have used have some shared space, and in this type of a setup a single web application could house the versions of Jini in the system and the essential module system, which has things added to it by things installed onto a server or in some other container through an API or some other service registry annotations. Of course you are going to be more locked into a single version of this common API at that point, but if the real guts and system are injected into by another EE application or module of some sort it is a workable solution to go in under the hood of different classloader systems to inject a common loader which can then be extended which also has the ability to access everything else within the system classpath below it; now it isn't without other issues of course. Essentially this static system would be an extra tie in to the module systems ability to add and remove modules on the fly; OSGi and NetBeans both support this. So, modules could come from WARs, EARs, EJB-JARs, Spring artifacts, etc into this common system as long as those things house modules matching the system or some kind of a classloader extension mechanism used. Just a rough thought right now, but it seems doable in my mind, and if the common API is nothing more than a proxy for some system which injects itself it could technically support multiple module systems some how linked together. Those other pieces would have to be able to unregister themselves to prevent memory leaks in the case they are undeployed or turned off etc through container management interfaces. Too, what happens if the main classloader or module system application becomes unloaded or disabled/turned off, and yet the others are up. I suppose in that case, as the main system is the actual Jini system it doesn't matter as much as long as the classloader and resource links can later be re-established; that would take classloader proxying of some kind which can later have resources added back to it. Either way, that would not be without some troubles of its own which all may not be able to be taken out successfully which probably means the first model where everything is held in a single web or EE application would have the best success. Wade
