----- Original Message ---- > From: Gregg Wonderly <[email protected]> > To: [email protected] > Sent: Thursday, December 11, 2008 6:33:42 PM > Subject: Re: Split JavaSpaces and JINI > > Wade Chandler wrote: > > ----- Original Message ---- > > > >> From: Gregg Wonderly > >> To: [email protected] > >> Sent: Thursday, December 11, 2008 11:36:55 AM > >> Subject: Re: Split JavaSpaces and JINI > >> > >> Wade Chandler wrote: > >>> Does anyone else have a site they are able to write articles? > >> We can put anything we want on jini.dev.java.net, and jini.org. > >> > >> What target audience are you thinking of? > >> > > > > Well, from my perspective it would be different targets. Web service > > discovery, database server discovery, login servers, ldap, etc through > > Jini to make enterprise desktop applications discover resources in the > > intranet etc. Different ways to work with NetBeans and use Jini. All > > kinds of things really. I'm thinking that is part of Jinis problem. > > Well one issue with netbeans is the fact that it doesn't have a real > SecurityManager implementation. It's not pluggable either. That means that > if > I put together a Jini module for netbeans, and it has discovery and code > download in it, I am opening the users to viral services. That door has to > be > closed. I brought it up more than a year ago. I haven't had any chance to > work > on this issue with the dev team, other than some discussion that melted away. >
Hmm. I'm missing your point here. Tooling can be designed to do what ever. From the view of NetBeans that can be anything. It is an IDE, so the developer/user would know what they are working with if just using NB as is with Ant and some fancier Jini services and tools, and of course if there is specific tooling for NB that can do whatever. From the view point of using Jini in a NetBeans module in say an RCP application I don't see the issue there either. Known services would be used, and however that needs to be handled would be added by what ever is adding it...the modules. We should be able to add whatever we need to Jini and/or the tooling to work that out. NB itself I don't see needs to support a specific security manager implementation for that. Too, I don't know what you mean by "it is not pluggable either". What isn't pluggable? Without further insight all I can say is that the module system itself is, but if you mean a security mechanism to load modules etc then know. The module system is what it is. Jini extensions to that would come from Jini modules etc. Of course, if we find we need some things added to the base NB module loader we can do some of those things and submit them as patches etc. We can also use PlatformX: http://platformx.netbeans.org to work on some module system extensions which are compatible with the current one if we need. > For Java mobile code, the SecurityManager is the key issue! We have to > figure > out how to simplify this to a non-threat, up front, or it will be a constant > point of frustration. Running all the services in one JVM with the users > code, > and no network access is one way to create an IDE development environment. > But > that supposes that the user will never want to test their service/client with > something elsewhere on the network. > Yes, I guess if we are talking about transparently used services. Services themselves can easily build in their own security mechanism and validation. Security managers of some kind can be built. Known services can also only be used (these from known systems that the user/developer knows are running). If I have a service running on X, Y, and Z and I know that I do, then there is nothing different about using it than loading an Applet from X, Y, or Z in the web browser or launching JNLP code or using RMI. Otherwise we need to be able to tell that service X is what and from who it says it is. > When they go from no-network to on-the-network, how will we make sure we > don't > open them to all sorts of problems? There would need to be some kind of > wizard > that said "here's the lookup groups that are active, which to you want to > use". > > Then, it might provide some ability to select a service by type etc. > Sure, any development environment would have to do that...provide service selection. Otherwise there may be untold numbers of services in a very large network or system even without worry of security and that would overwhelm the environment. Too, the services users would want to use would be known types of services I would imagine except for a dynamic system where any number of client modules could be running any number of possibly unknown services...obviously a power Jini provides, but those services would at a minimum need to match a common interface to be meaningful in any given context. Any code in between can be high jacked without having a mechanism to know where it is from such as signatures/signed code etc or service specific authentication and validation through certificates or some other means. > But, for all of this to really work safely, we have to have a > "no-live-object" > lookup...As I described in my previous email a few weeks ago... > Yes, and this is something we need. I'll need to check out your other email. Is this mailing list in a mark mail archive some where like the Tomcat lists? Wade ================== Wade Chandler, CCE Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team Member, and NetBeans Board Member http://www.certified-computer-examiner.com http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam http://www.netbeans.org
