- how I package the native libraries/compilers
- how can I deliver native libraries/compilers according to customer environment
- how I install them afterwards (in some cases an install step is requiered
- how should I protect the download (if somebody intercepts the jnlp file, what's happening next?)
The project I am currently working is quiet big - the packaged distro has aprox 25Mb (Java + native custom compilers). During the spring (till late summer) we had to deliver almost weekly to our customers (they are testing a lot and we had a long period of feature requests/analysis). The prefered way to make this deliveries was an FTP archive. As you may expect the build/distribution is automated using Ant builds.
But, we got some complains about the size of the download and about the bad connection (damn, this is something we cannot improve [sad/]).
Right now I am thinking that a distribution based on Java Web Start will boost the update process (I expect another tough period). Even if the documentation for Java Web Start seems good enough I have some points on which I am not sure:
2 comments:
(a) how I package the native libraries/compilers?
Not sure about the 'compilers', but in the JNLP you list all the libraries that you use inside the JNLP. I would also put the list in the manifest.mf of the master jar so you could execute it as a normal java app.
(b) how can I deliver native libraries/compilers according to customer environment.
Not sure what your environment is or if there is required any specialised configuration, but if its 25 meg, in addition to making it available over the web, I'd put it on a CD.
(c) how I install them afterwards (in some cases an install step is requiered
Java 5 has "Install from CD" options for WebStart.
(d) how should I protect the download (if somebody intercepts the jnlp file, what's happening next?)
If its on CD you deliver the correct jnlp to the client. It will the pull down libraries that have changed from the web. Someone could obviously swap the CD. If you employ a web only deployment strategy and its _critical_ (bank application, etc).
I'd investigate the impact of SSL ONLY. Not looked at this level of trust so I'd be intrested in your findings. I would expect the same issues would exist in as any normal application that requires integrity.
Without 'trusted computing' it would be difficult for the server to trust that the client app has not been modified, nor for the client to validate that it is using a client that has not been modified. While the client could use signed jars, this would require investigation by the user to check that he's got the right version. If the client were to do this checking, it could be modified to 'ignore' this validity check. Bleh, drifting.
Webstart is nice.
Here's an example of os-dependent library loading, it's helped me out a few times:
Post a Comment