Integration Manager Enterprise Server User

CHAPTER 2

Integration Manager Enterprise Server Overview

This chapter introduces some basic runtime issues you will need to know about if you intend to deploy projects to Integration Manager 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 (JBoss, Novell exteNd, IBM WebSphere, BEA WebLogic, Apache Tomcat).

 
Top of page

Deployment Archive Contents

Integration Manager 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 use Integration Manager's design-time deployment wizard to deploy projects straight to the application server, or to a staging area of your choosing. Integration Manager 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. Integration Manager deployment procedures are covered in the Integration Manager User's Guide. See the appropriate guide for more information. The following discussion centers on low-level descriptions of deployment artifacts.

An Integration Manager deployment EAR contains the following types of objects:

Object

Use

Notes:

Project JAR File

Contains the services, components and resources of the project, in XML form.

The Components and other xObjects that comprise your services are stored in metadata form (not Java class files). Integration Manager Enterprise Server uses these files to create your runtime objects on the app server.

NOTE:   This file is always generated, and is always packaged into the deployment EAR.

EJB Service Trigger class files

Allows services to be invoked through EJBs (potentially front-ended by JSPs), which in turn means Container services (for transaction control, etc.) are available..

EJB triggers are required for standalone use of Integration Manager services as part of local business applications..

WAR file

Contains manifest.mf file (listing the JAR resources for this deployment) and web.xml (see below).

Required if Servlets or EJBs are created. Produced by Integration Manager automatically.

web.xml file

Describes information necessary to install Service Trigger Java classes into the application server. The URI associated with the Servlet based Service Triggers and JNDI name for EJBs are described in these.

Created automatically and stored in a WAR file within the deployment EAR.

SilverCmd batch file called ImportObjects.bat

Contains SilverCmd utility calls to install the deployment objects into the Novell exteNd application server.

Created automatically, and invoked automatically, if you choose the "Yes" radio button on the final screen of the Integration Manager deployment wizard. This artifact is created only for the Novell exteNd Application Server.

xc_deployment_info.xml

Contains the deployment profile from the last time the Deployment Wizard was executed.

Created automatically. Allows Integration Manager to restore the previous deployment information the next time a deployment is performed.

The following diagram summarizes the containment hierarchy of a deployment EAR.

EARContents

(For a more detailed description of the contents of these objects, see the appendix.)

 
Top of section

Novell exteNd Application Server Database Requirement

Many J2EE application servers use ordinary disk storage as the "backing store" for application 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 application 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 Integration Manager 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:

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.

 
Top of page

Push-Model versus Pull-Model Deployment

Deployment of Integration Manager services is usually initiated from within a Integration Manager design-time environment. Integration Manager has its own wizards and tools to enable direct deployment from the Integration Manager design-time environment. (See the separate Integration Manager User's Guide for details.) Integration Manager can do a live deploy straight to a target application server, or a "packaging only" deploy to a staging area on disk.

Integration Manager 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.)

 
Top of page

Hot Deployment

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.

 
Top of page

Removing (Undeploying) Existing Applications

Various application 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 Integration Manager project:

  1. With the app server running, launch the Server Management Console (smc.exe) application.

  2. In the toolbar at the top of the main window, click the Deployment button (as shown below).

    2smc1

  3. 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.

  4. 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 Integration Manager EAR. This EAR contains runtime executables for Integration Manager.

    2smc2

  5. 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 Integration Manager 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.

 
Top of page

Updating Your License

You can update licenses manually by means of one of the administration consoles (the License Manager page). Consult the discussion of the License Manager in the chapter on administration.



Copyright © 2004 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved.  more ...