Weblogic - DEVELOPMENT ENVIRONMENT VS. PRODUCTION ENVIRONMENT

Development of an application and carrying it to production are two distinctly difficult activities. When the system is under development, typically various groups/teams are working on each piece of the system in an independent, rather disconnected manner. The teams do coordinate if some piece is complete and is deemed usable by other teams, but the development process is often not a well-integrated and connected process. Ideally, a well-constructed system emphasizes integration and tight coupling between various components of the system; but the reality is that it is difficult to attain this in a development environment.

In the traditional project development environment, a wide variety of tools exist for different activities during the project’s life cycle. Mostly, these tools do not coexist on the same platform, thereby disconnecting various project activities.

In the typical development and production process, some teams design front ends; others build front-end logic; others work at various business layers (middle-tier); some teams are responsible for database administration; and some are responsible for database development, business analysis, and so on. Such an environment can prove difficult for keeping teams working in a truly integrated manner.

When developing in Java, you should always make sure that you’re working in a controlled development environment. To avoid Java class conflicts and other problems that can be difficult to diagnose, you need to be aware of all of the environment settings that are in use during development. A common set of tools must be used by all the teams participating in development for source code control and versioning, test frameworks, source code editors, and coding conventions and guidelines.

Having a deployment environment preconfigured in development to match the production environment helps ensure high-quality deployments and helps to streamline the application life cycle. You should develop your application by utilizing the J2EE model for application deployment. J2EE applications provide a consistent, portable, and easily maintainable way to deploy your applications.

WebLogic Server has a provision for auto-deployment, which is viable for quickly deploying the application on the administration server. We recommend that you use this method of deployment only in a single-server development environment. It is not advisable in a production environment or while deploying components on managed servers.

CAUTION You must ensure that auto-deployment is turned off in the production environment. Another mechanism of deploying the applications is known as hot-deployment, or dynamic deployment. In this case, whenever the application undergoes change, it is automatically deployed in the sense that changes are immediately impacted. In addition, this setting is, by default, enabled.

CAUTION Dynamic deployment should not be used in a production environment. Instead, a manual or static deployment of applications should occur.

In the development environment, dynamic deployment or auto-deployment can be afforded because it is just internal—that is, it’s internal to the teams concerned. However, when in the production environment, great care must be taken to not initiate any steps that can lead to unexpected behavior and user experiences and that can harm organizations’ reputations.

Typically, Web applications undergo constant changes, and users don’t want to see these changes every time the contents are added, subtracted, or manipulated on the Web site. Even the functionality of the Web applications can change, which at times involves new business rules. This doesn’t mean that the only point at which we can and should deploy applications is when the server boots, however. At times, bug fixes need to be dropped without bringing down the server and without affecting the availability and functionality of the Web site. In such a case, we must perform dynamic deployment. Hence, specific features that we need to apply to specific content are crucial.

One more issue crucial in a production environment is the discovery of managed servers. WebLogic Server has an administration server and a managed server. An administration server manages the managed servers. Therefore, you must deploy your applications in the production environment on the managed servers and not use an administration server for that purpose. You can restart the administration server without affecting the clients connected to managed servers, even when the managed servers are running.

If you restart the WebLogic administration server while the managed servers are still running, the administration server will detect the presence of the running managed servers if instructed to do so. To instruct the administration server to look for running managed servers, enter the following argument on the command line when starting the administration server:


The default value of this attribute is true. Why is it, then, that we have to set it to true? To ensure that either this parameter is not set or at least not set to false. The configuration directory for the domain contains the file running-managed-servers.xml, which is a list of the managed servers that the administration server knows about. When the administration server is instructed to perform discovery upon startup, it uses this list to check for the presence of running managed servers.

From a hardware perspective, the way we configure our development servers is a lot different from the way we configure our production servers. Development servers are never under stress and don’t need to be scaleable in terms of supporting a large number of users, whereas the production servers do function under stress and must be scaleable.

---