If your desktop environment is NT/2000/Linux, you can set the file permission to readonly.
B.T.W. What kind of application is this, in that you deploy the EJB's in the client? This is a really 'fat' client.
> B.T.W. What kind of application is this, in that you
> deploy the EJB's in the client? This is a really
> 'fat' client.
Our situation is that we are building an application that we wish to deploy in several different configurations: as a traditional distributed n-tier application, as a desktop only application, and as as desktop application that is accessed by multiple users (i.e., same as a traditional n-tier application, but the middle and data tiers are housed on a desktop box, which also happens to have a client accessing the application).
I've been struggling with the question of whether J2EE is the right technology to use for this project. It seems to me that J2EE is fundamentally intended to be deployed on servers. Some specific concerns, besides those I already raised in this posting, are: Perhaps JBoss would require more processing power than could be provided by the typical desktop configuration. Also, perhaps there are peculiarities and idiosyncrasies in deploying a complex J2EE application that would make it hard to create a smooth experience for end-users configuring and installing a shrink-wrapped application on a desktop.
Indeed, I cannot find any precedent for building a shrink-wrapped desktop application (with a turn-key installation process) with J2EE.
I'm afraid to say that our alternative may be .NET.
Any suggestions you have would be greatly appreciated.
As far as I know there is no way to securing any application deployed on a file system that the user has write access to. The user can not only modify the EJB permissions but also the code. This is true given any technology. (You could imagine signed ears and the core JBoss secured though, but then you can as well secure the deploy directory as well). The securing must be in the next lower layer in your application. I think that what you really want is to install and deploy JBoss as a different user than the user working at the desktop. Easy with Unix. Windows I don't know (thats why we only run Unix servers).
If you look in the real world, there are many horrifying examples distributed systems with the access checks only in the client. These are by default hackable by the user of the client.
You can deploy the applications from across the network. So when you distribute all those JBoss instances to client hosts, put your applications into a central server which you can secure from writes rather than deploying them from a local file system. Modify the jboss-service.xml to add the additional deploy URL.
As for smooth configuration experience on client machines, netboot is also an excellent option (which downloads a preconfigured instance from the network to the user's machine).
CPU processing power: I run and often develop JBoss on my 800Mhz laptop. If the desktop machines have that much power it is enough.