Here is my latest vision of the client server communication.
I am not concerned with finding the servers at the moment, just with making a complete transaction.
1: It all starts with a security handshake initiated by the client. Here the client establishes it's identity with the server and an encryption Key is established.
2: Once this phase is complete the client makes a request for data in the form of an RMI call. This RMI call returns an arbitrary data structure containing what ever data is needed as well as the UML of the class containing the code to run on that data.
3: The class is then retrieved with the Java class loader. some predetermined member function of the class is then executed with the data as an argument.
4: When the function has completed its execution the client makes another RMI call to the server returning the data.
I like this line of communication because the client is always initiating the transfer of information. I hope this will nullify issues with proxys and fire walls.
However, This use of RMI seems a little bodgey to me. Perhaps it would be better to handle it in a different way.
For instance with just one RMI call made by the server to the client. I think thuis approach is out of the question since it might require a new thread for each client.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Instead of RMI the entire thing (data and code) why not set it up like this instead:
1. User assigns his client to a project. As part of project setup the server sends the clients a Java Bean built off an abstract class we define (landonApp, say). This bean can be built with serializable or some other persistance engine.
2. The bean requests a data packet in the form of an input object defined by the project builder. It then crunches away until halted.
3. Whenever the client runs it instantiates this bean, which will restore state, and runs with it. When the bean is done it packages the results and sends them off in a data packet.
4. The use can set a "switch to project X after this packet" flag when he wants to switch.
The class transfers could then be methods on the client that return objects of some root class we design. Instead of RMI we could use simple transfer protocols to get the pieces in the same manner as applets. This also has the advantage of letting us take advantage of some java security features.
While this would buy us into writing a bean builder instead of a UML editor it makes better use of the Java langauge's built it tools while maintaining the client driven interface you prefer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is my latest vision of the client server communication.
I am not concerned with finding the servers at the moment, just with making a complete transaction.
1: It all starts with a security handshake initiated by the client. Here the client establishes it's identity with the server and an encryption Key is established.
2: Once this phase is complete the client makes a request for data in the form of an RMI call. This RMI call returns an arbitrary data structure containing what ever data is needed as well as the UML of the class containing the code to run on that data.
3: The class is then retrieved with the Java class loader. some predetermined member function of the class is then executed with the data as an argument.
4: When the function has completed its execution the client makes another RMI call to the server returning the data.
I like this line of communication because the client is always initiating the transfer of information. I hope this will nullify issues with proxys and fire walls.
However, This use of RMI seems a little bodgey to me. Perhaps it would be better to handle it in a different way.
For instance with just one RMI call made by the server to the client. I think thuis approach is out of the question since it might require a new thread for each client.
Instead of RMI the entire thing (data and code) why not set it up like this instead:
1. User assigns his client to a project. As part of project setup the server sends the clients a Java Bean built off an abstract class we define (landonApp, say). This bean can be built with serializable or some other persistance engine.
2. The bean requests a data packet in the form of an input object defined by the project builder. It then crunches away until halted.
3. Whenever the client runs it instantiates this bean, which will restore state, and runs with it. When the bean is done it packages the results and sends them off in a data packet.
4. The use can set a "switch to project X after this packet" flag when he wants to switch.
The class transfers could then be methods on the client that return objects of some root class we design. Instead of RMI we could use simple transfer protocols to get the pieces in the same manner as applets. This also has the advantage of letting us take advantage of some java security features.
While this would buy us into writing a bean builder instead of a UML editor it makes better use of the Java langauge's built it tools while maintaining the client driven interface you prefer.