Chapter 19 Dynamic Class Load deployment a distributed program is more difficult. The corresponding partial program must be installed on each machine that runs some programs. For a local network, just some time is not too difficult. But if you want to deploy a wide range, you often need to change the environment, the deployment process will become very difficult. Dynamic mount technology built in RMI, wants to try to make this deployment simple. In this book, we talked about the most basic knowledge of establishing a robustly scalable distributed program. We tell the principle of design interfaces; spend a lot of time to discuss threads; test a distributed application; even discuss how to optimize distributed garbage collection. The deployment (secondary deployment) will now perform deep excavation. 19.1, deployment is a difficult assumption that we will deploy the latest version of the banking program. We need to do the following: l Configure the server L to add the class path of the stub class (and other related classes, like a socket factory and value object) to the ClassPath of the name server, which may instantiate in the name server. l If this is not the first deployment (relative to the first deployment), you need to restart the name service and re-register all objects to remove objects already in the name service JVM. l Install and configure programs at each client. This includes the machine that is not currently not in use (e.g., there is currently no load or machine to repair) so that it will be installed later. Compare a small application deployment process: l Configure the server l Write a web page that contains the Applet tag, deploying a web program without modifying the client without modifying the name service. Instead, when the browser downloads the web page containing the Applet tag, it also downloads the required Java class file to run the applet. This way of deployment not only saves time and will not be wrong. Tip: For past, except for the first time and energy required for the first time, you also need to consider unavoidable deployment errors. ------------ How long does you need to deploy it again? -------------- Sometimes, when I mention how the deployment is painful, some people will say: "Indeed. But you need to redeploy multiple times? One year once?" This is a good problem. Some procedures do not need to be deployed frequently. However, this problem is a bit around. Some reason why the program is not deployed is because it is too difficult to operate too much when deploying too much. If the deployment becomes simple, the program will change and deploy more frequently. Web program is a good example. Deploy a web program, you only need to reconfigure it on the server. The web program is often deployed. ------------------------------------------------ Every time you need to modify or re-deploy the program, this problem will become more and more prominent. Of course, small applications have many restrictions. Because every time you run, you need to be downloaded as much as possible; because the browser may use the old JVM, developers cannot use the latest Java feature, like the Swing GUI development package. Moreover, because the browser has strict security requirements, the small application opens the socket connection or open the file. Tip: This is the "Even browser has been implemented" defects even if the browser has been implemented. This defect now exists and always exists, regardless of how the browser is improved. In addition to this defect, the JVM provided by the browser may be extremely slow, full of bugs. The good news is that RMI has an interesting and useful technology called dynamic mount, which attempts to take these two ways.
