![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() | ![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Composer Enterprise Server User
CHAPTER 2
This chapter introduces some basic runtime issues you will need to know about if you intend to deploy projects to Composer Enterprise Server and administer them at runtime. Those issues include:
Cache management and other administrative issues are discussed in the next chapter.
NOTE: This chapter assumes that you are familiar with EAR, JAR, and WAR packaging concepts, as well as other J2EE deployment idioms. You should also be familiar with runtime and deployment concepts applicable to the particular app server you will be targeting (Novell exteNd, IBM WebSphere, BEA WebLogic, Apache Tomcat).
Composer follows a standard J2EE deployment model, using the EAR (Enterprise ARchive) file type as the deployment object.
The deployment EAR wrappers all of the project-level resources and components you've chosen to deploy. The EAR is scoped to a single project (.spf) file. The EAR encapsulates all services that exist in your project, and the resources they use.
You can create your deployment EAR either with Composer (design time) or Director. If you are using Composer Enterprise Edition (or the Enterprise Edition exteNd suite), you can use Composer's design-time deployment wizard to deploy projects straight to the app server (or to a staging area of your choosing). In this scenario, Composer does all the packaging for you, automatically, and puts the resulting EAR on the app server. The EAR is immediately "live," with no need to restart the server.
The other way of creating deployment archives is to use Director's native J2EE packaging facilities.
NOTE: Director-native deployment is covered in the Director documentation. Likewise, Composer Enterprise Edition deployment procedures are covered in the Composer User's Guide. See the appropriate guide for more information. The following discussion centers on low-level descriptions of deployment artifacts.
A Composer deployment EAR contains the following types of objects:
The following diagram summarizes the containment hierarchy of a deployment EAR.
(For a more detailed description of the contents of these objects, see the appendix.)
Many J2EE application servers use ordinary disk storage as the "backing store" for app-server content. By contrast, the Novell exteNd Application Server (up through and including version 5.1) uses a database.
NOTE: For a list of supported databases and drivers, see the Novell exteNd Application Server release notes and documentation.
The app server stores its own internal classes and runtime artifacts in a default database called SilverMaster (or SilverMaster50; the name always contains the version number in the final two characters). You can deploy your own projects (your Composer and Director EAR and WAR files) directly to SilverMaster, if you wish. But for better encapsulation and easier management, you may want to create individual databases for each project. The deployment process, in this case, involves the following steps:
Create a database and make it available to the app server (using the client-side smc.exe (Server Management Console) application that comes with Novell exteNd app server)
Specify that database's name in the Server Profile corresponding to the deployment you wish to perform (in Director or Composer, use Tools > Profiles . . . to access the dialog where you can create or edit Server Profiles; and specify the target database there)
The deployment database for your project need only be created and installed once. You can then deploy and redeploy your project into that database as many times as needed.
NOTE: A visual UI for managing databases and drivers installed on the app server is available in the smc.exe (Server Management Console) app that ships with the app server. Consult the Novell exteNd Application Server documentation for details.
Deployment of Composer services is usually initiated from within a Composer or Director design-time environment. Director offers a variety of wizards and tools for creating and packaging deployment artifacts, including those needed to deploy Composer services. (See the Director documentation for details.) Composer Enterprise Edition has its own wizards and tools to enable direct deployment from the Composer design-time environment. (See the separate Composer User's Guide for details.) Composer can do a live deploy straight to a target app server, or a "packaging only" deploy to a staging area on disk.
Composer supports a push model as well as a pull model for deployment. The push model is the case described above, where you initiate deployment from the design side. In the pull model, deployment is initiated from a browser console on the server. (See the next chapter.)
You can deploy a project to the app server while the app server is running, even if an earlier version of your project already exists on the server. (The old deployment EAR is simply overwritten.) There is no need to undeploy an existing EAR before deploying a new one. However, you should clear the cache (see "Clearing the Cache" in the next chapter) before running the newly deployed project, because it's always possible that old objects from the previous deployment are still in memory.
Various app-server vendors offer various tools for managing deployed web applications. With the Novell exteNd Application Server, you can use the following procedure to undeploy an already deployed object (which is to say, remove it from its host database, without removing the database itself). To undeploy a deployed Composer project:
With the app server running, launch the Server Management Console (smc.exe) application.
In the toolbar at the top of the main window, click the Deployment button (as shown below).
In the main window under Deployed Objects, locate the database that contains the deployed project you wish to undeploy. (All databases will be listed in tree view.) Toggle the plus sign next to the database "parent node" to expose its children. The child (or leaf) nodes of the tree represent deployed archives.
Single-click (select) the deployed archive you wish to remove. (See illustration below.)
CAUTION: If your deployment database is SilverMaster, be careful not to select the Director EAR nor the exteNd Composer EAR. These EARs contain runtime executables for Director and Composer.
Click the Undeploy button in the lower right corner of the window. The EAR or WAR in question will disappear from tree view and will no longer exist on the app server.
NOTE: You cannot undeploy individual Composer services one at a time. The entire project EAR will be undeployed as a unit.
For information on how to undeploy EAR and WAR files from other app servers, consult the appropriate vendor's product documentation.
Should the need arise to update the license string associated with Composer Enterprise Server, you can use the UpdateLicense.bat file (located in your exteNdComposer\bin directory) to accomplish this. From the command line, run:
updateLicense product newLicense [Composer/Server]
where product is the name of the particular product (whose license you would like to update, newLicense is the license string, and the final argument (one of Composer or Server) specifies whether to update the design-time or runtime version of the product in question.
You can see a list of installed products by running:
updateLicense -L
Copyright © 2003 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...