Can JWS do this...? Architecture question
Hi,
I'm designing the architecture for a school board that is moving a COBOL system to a Java App Server system. Within the system there are approx 180 'Modules' - each module being a set of screens that allow a user to accomplish a task. For example, the Teacher Grading module allows a teacher to access their student records and maintain the student's grades.
I'm looking to use JWS for deployment of the front end but am unsure if JWS will support the framework I want to put in place.
From a UI perspective, as there are so many modules in the system I want to design the architecture in a way that allows each module to plug in to the existing framework.
The front end would consist of a container application that would house each module in a sort of tabbed view. As each module is added to the system so the user would see a new tab in the UI that housed the new module (depending on whether the users had permissions to access the module).
So the front end container would display the modules that the user can access, adding new ones as they are defined.
Question:
Is the server's JNLP file for the application static? If it was ammended to include new jars would this cause problems on the Client side post initial installation, or would it take it in it's stride and just upload the new jars as required?
What I want to do:
I was hoping that I could just ammend the JNLP file on the server to include the new Module (jar file), the Container app could then just get a list of class names from the App server that were applicable to the User. The Container app could then instantiate the class objects and the JWS would automatically upload jars any that were missing (using lazy loading), and subsequently add the new Module( jar) to it's list of versioned jars to update when required.
Question:
Is this possible to do using JWS?
Another possiblity:
1) Main application Container gets installed using JWS
2) User starts app and signs on
3) Container talks to App Server and determines which Modules the User has permissions to use
4) Container downloads missing or new Modules - jar files (maybe using javax.jnlp.DownloadService?)
5) Want JWS to subsequently evaluate downloaded Modules (and main app) for any updates - though this would happen at step 2.
Question:
Would an individual Module's jar file/s need to be referenced in the JNLP file to download it using javax.jnlp.DownloadService? I am thinking it would.
Things to note - it is not possible to define the app with all 180 Modules embedded as it may take years to recode all 180 COBOL Modules in Java. and the system it being implemented iteratively. Also few, if any users will have access to all 180 Modules. Users are part of Groups (Teachers, Superintendants, Subtitutes etc) and each Group only has access to a certain set of screens (Modules).
Any advice would be appreciated, as I would like to be aware of any potential problems before I define the architecture.
cheers
Ray
[3113 byte] By [
ray101a] at [2007-10-2 15:45:45]
WebStart is a delivery mechanism, pure and -relatively- simple. Most of the functionality you describe will have to be custom-made. Both approaches you are currently thinking about should work.
I think the second (5-step) approach is the most promising. I think you could benefit greatly from using a Rich Desktop Platform, such as Eclipse or Netbeans, as your application container. This will provide you with a lot of infrastructure for free.
As an alterative solution, have you considered making the system entirely web-based? That way you wouldn't have to deploy anything on the client and you have much greater control over updates and who can access certain modules.
You are completely free to dynamically generate the JNLP file if you wish via a regular Java servlet. In fact Sun has available a simple servlet called JnlpDownloadServlet which you'll find in the jnlp-servlet.jar file in your jdk installation. So you could create the servlet and pass arguments to it giving the user id and it could generate it with the modules that this user has access to. You would then probably also generate arguments passed to the main() function which would tell your app what classes (modules) to load into your app.
The disadvantage of this approach is that your server has to keep track of what modules this user can use, and he would probably have to use the web site and another servlet to configure it. (Assuming the user has any control over what modules he can access).
However there may be a better way for you to proceed. If you create a static JNLP file that contains ALL the modules but with the download="lazy" option, then all modules will be in the JNLP but not downloaded unless necessary.
Then you can download the bits explicitly you want to use. (The DownloadService class) will tell you how to do this.... http://java.sun.com/products/javawebstart/docs/javadoc/index.html
You will need to have all the modules listed in the JNLP file. Whenever a user starts up the app it will refresh their copy of the JNLP file. Pass the list of available modules to the main() function within the JNLP file so that the app knows they are there.
If necessary have some arguments that indicate permissions on the modules within the JNLP file that are passed to main(). (e.g. --module=mymod1.jar,perm=teachers,students )
You may want to create a ClassLoader that accesses that jar file directly (passing in the URL)... (once it is downloaded via DownloadService) and loading information directly from each jar. e.g. have an info.properties file in the "root directory" of every jar file that explains what the entry point or points are for this module. That avoids having to pass even more info in the JNLP file (e.g. --entryPoint=com.foo.MyModule1). or else having some guessable naming scheme for classes. That is a good thing at least for entry points so that the module is completely self-contained describing its own entry points. That is an approach I've used before. But you wouldn't use it for permissions, because then you would have to download it before you could tell if you need it.
Now the application itself can manage its own modules and resources using whatever criteria you desire. (You could even give the user some control). If all your modules have a standard interface for launching them, you can dynamically load those classes on demand. Use DownloadService to download the jar for that module, and then use Class.forName() to access the entry point for the module. Use the java.util.prefs.Preferences class if you need to keep track of anything on the client side about modules.
If it were me, I'd have the code be able to work without webstart as well which is easier for local debugging. That shouldn't be a problem.
Hi guys - thanks for your replies.
Unfortunately the forum is refusing to log me in (and refuses to take my answer to the security question) - all very very annoying.
So I had to create a new login
I appreciate your answers and they have really helped. I have started another thread
"Can JWS do this...? Architecture question revisited'
if you can visit this thread and just post a simple message (e.g. Hi) I can allocate the both of you some duke dollars...
sorry about this.
cheers
Ray
