Using Tomcat with CA Clarity PPM

(1)

Using Tomcat with CA

Clarity PPM

(2)

TOMCAT

Apache Tomcat is the black-box solution that comes bundled with CA Clarity PPM. The following topics will outline the benefits our customers receive by deploying CA Clarity PPM with our embedded Tomcat solution.

OEM & LIGHTWEIGHT

CA Technologies has bundled versions of Tomcat with Clarity since November 2006. While the latest Tomcat version is not necessarily bundled with Clarity, customers are encouraged to download the latest Tomcat version that coincides with their Clarity implementation (refer to the Product Architecture Stack or Release Notes to identify the supported Tomcat version). Best practices are also published within the CA Clarity Global User Community Site in securing Apache Tomcat with CA Clarity PPM and SAP Business Objects (search on CA Clarity PPM Application Tier Patching Procedure). SAP follows that same development practice of embedding Apache Tomcat with SAP Business Objects.

Apache Tomcat is an open source software implementation of the Java Servlet and JavaServer Pages technologies. The Java Servlet and JavaServer Pages specifications are developed under the Java Community Process. Apache Tomcat powers numerous large-scale, mission-critical web applications across a diverse range of industries and organizations. Some of these users and their stories are listed on the PoweredBy wiki page.

For IBM WebSphere and Oracle WebLogic, our customers are responsible for obtaining the appropriate license. These two generic application servers have a number of features, but Clarity in effect uses less than 5% of the overall package.

Tomcat proves to be the industry “de facto” standard application server that is extremely lightweight, highly scalable and follows industry standards. At roughly 8MB in size, Tomcat proves to be an

enterprise class solution in a very small package. The remarkable aspect of the solution is really around the installation process; it can simply be extracted and is immediately ready for deployment.

CONFIGURATION THROUGH CSA

All Tomcat configurations are accomplished through the Clarity System Administration (CSA) URL. The System Administration function is needed for remotely controlling, changing and monitoring the

(3)

services in the cluster. All configurations of the web, application, reporting and database tiers are done through the Clarity administrative web interface requiring minimal training to manage. When using Tomcat, the application is deployed as a “managed service” – this makes the application deployment tightly integrated with the rest of Clarity.

As a result, the Tomcat solution does not require any specific Tomcat administrative skill sets to deploy the application – CA Technologies has simplified the deployment of Tomcat so that even the most basic of users can deploy Clarity.

Primary activities of the Clarity System Administration Server include:

– _{Installing and configuring the system.}

– Adding and controlling Application (app) and Background (bg) services on remote servers.

– Configuring and reading log files from remote servers.

MANAGEMENT

With Tomcat as the black-box solution, many of the configurations are already optimized. Database pooling, for example, is already optimized for the Clarity usage model. Other configuration settings like background services, search services, system security, etc. are easily accessible and can be adjusted based on best practices. CA Clarity PPM has incorporated a JVM wrapper as part of our managed service to ensure scalability, stability and reliability.

Tomcat has additional features of clustering and high availability. Clustering is used for Load balancing that can be achieved through many techniques. Clustering support currently requires the JDK version 1.5 or later. High Availability is obtained by dispatching live traffic requests to a temporary server on a different port while the main server is upgraded on the main port. It is very useful in handling user requests on high-traffic web applications.

Under Tomcat, Clarity can scale vertically (multiple JVM processes) and horizontally (on additional servers) for redundancy and performance.

The following is a summary of consumed resources that are managed under the Tomcat black-box embedded solution:

WEB TRAFFIC

(4)

 Sticky-Sessions are required for Partial, and highly recommended for Full

CACHING

 Caches are read-only and only populated from database

 Multicast messages are sent to invalidate stale entries

 Transactional data is not cached

THREADS

 Threads are always pooled or long-running singletons

 Guarded usage of ThreadLocal for session management, transaction management &

logging

DATABASE CONNECTIONS

 Always pooled, never kept

 Third-party library Proxool used with Tomcat and background (bg) services

 CA JDBC Drivers only (From DataDirect)

NETWORK

 Unicast to database, report server, mail server, etc

 Multicast from Clarity server-to-server using third party library JGroups

(www.jgroups.org) MEMORY

 Heap space

o Stylesheet and Metadata caches o Session data

o Transient data per thread

o Varies greatly depending on usage and number of active users

 Permanent space

o Class definitions and constants o Internal JVM compiled code o Varies little with usage

 Stack space

o Any data local to methods in the call stack o Varies little with usage

(5)

DIAGNOSTICS

Under the embedded Tomcat solution, Clarity has a greater number of out-of-the box

diagnostics/logging capabilities. Various configurations can easily be adjusted through the Clarity System Administration URL.

Within the embedded Tomcat interface, customers can configure the Clarity logs to add more detail or to update or remove entries. Customers can update the log file configuration to have changes take effect immediately. Otherwise, it may require restarting the Clarity Application (app) and Clarity Background (bg) services before they take effect.

There are several different logs to choose from:

– _{The primary logs are the ca logs, named after each active Clarity service on the selected server.}

For example, if running an app and bg service on the selected server, two log files display: app-ca.log and bg-app-ca.log. These log files contain log messages from the app service and bg service respectively. If a second app service is running on this server with id app1, an additional log file, app1-ca.log, displays.

– _{The admin log is another important log on the CA Clarity application server. This log contains a}

record of system administrator tasks such as installation, upgrade, database deployment, and file distribution.

– The system logs contain the console output from any app or bg services running on the selected server. The console output contains any messages outside of Clarity, for example logged by the VM itself or the application server (Tomcat). Example system logs are app-system.log and bg-system.log.