Application Server

STRATEGIES FOR DEPLOYING JAVA APPLICATIONS IN YOUR

ENTERPRISE
Stephen P. Karniotis, Compuware Corporation

PRESENTATION ABSTRACT
Business owners believe that developing and deploying J2EE/Java applications is as
simple as using a development tool to write the application code and port that code for
both internal and external usage.
Many steps are considered when developing and deploying Java applications to the
enterprise. These include architectural surveys to better understand the scope of the
project, deployment strategies and platforms, service level agreements, quality assurance
testing, and production management. Too often one or more of these steps is ignored,
leading to failure for most projects.
This presentation discusses the pitfalls of deploying poorly developed, tested and
managed applications and then demonstrates how to mitigate the problems by focusing
on proper deployment strategies. Usage of both Oracle and Compuware technology are
discussed as part of the overall solution to improve value to the customer.
By attending this presentation, each attendee should understand how the
deployment pitfalls affect them and how Compuware can mitigate these pitfalls with
technology, helping to ensure that future deployments of Java applications are more
successful.

INTRODUCTION
Developing J2EE applications is generally the easiest portion of the application
deployment project. The technology for developing the application has already been
chosen. The platforms to be supported/deployed upon have been chosen. The target
audience has already been informed and they have also provided input into the
application design process. Resources for supporting the application deployment process
have been acquired, tested, and installed prior to the final installation. Test plans
designed to validate application functionality have been created and validated by users.
Management has agreed to the application deployment terms and service levels prior to
deployment. Or has everything been assumed it will happen?
Too many application deployments fail because one or more components of the
process is incomplete, bypassed, forgotten or ignored. Stating examples in this white
paper is unnecessary, as everyone can think of specific cases within their organization
where application rollouts failed for one reason or another.
J2EE applications increase the complexity of deployments by attempting to
integrate multiple, disparate technologies, incomplete standards, and third-party solutions
into one solution. The good news is that everything discussed in this paper, and the
associated PowerPoint presentation, applies not only to J2EE but also for EVERY
application deployment. So, read carefully, take notes and be prepared to field questions
from management when failures occur.

Paper 36726
Page 1 of 11
 Application Server

TRADITIONAL APPLICATION DEVELOPMENT PITFALLS

Nearly every application developed and deployed today has suffered from one of
the pitfalls mentioned in this paper. Unfortunately, the infancy of Java & J2EE application
development within the enterprise has ignited many of the same problems associated
with the poor coding and deployment strategies experienced with both mainframe and
client/server development.

POOR OVERALL DESIGN

The image of the tree swing design comes to mind quite clearly here. If everyone
that attempted to design the swing read the original requirements, the swing would look
like any other tree swing. Unfortunately, everyone added his or her requirements to the
final product design. The net result was a tree swing that had a tree going through the
center of the swing, rendering the swing useless.
Poor application design is not the most visible pitfall, however, it has a profound
impact on the application deployment process. Not thoroughly thinking through what the
actual requirements should be, using unproven technology, or adding options to the final
product because of technological requirements are examples where deployment projects
fail. Java applications are not ambivalent towards these problems. Remember that Java is
an Integrated Development Platform, encompassing multiple technologies into a single
solution. If components of the application are either improperly designed or architected,
the application suffers, customers may discontinue using the application and potential
business revenue may be lost.
An example of poor design would be assuming that specific technologies should be
used to create and/or generate the code for the application. Instead, Java application
designers should concentrate on ensuring that business rules/processes are closely
adhered to, satisfied, and validated. Once the technology strategy is chosen, the
development staff can begin the rigorous task of developing and deploying the
application. More on delaying the technology choice until development begins later in
this paper.

POOR COMPONENT DESIGN

Assuming that the infrastructure of the application has been designed
appropriately, poor component design can aid to the destruction of a Java application
deployment. Poorly crafted JSPs, inappropriate use of Beans, inefficient invocations of
other application components are just examples of components that were not crafted
properly. Because of ineffective testing, problems are generally found too late in the
development process and are repaired only when someone complains.
Inappropriate use of system resources is another example of poor component
design. If a portion of a Java application consumes too much memory or CPU, the issue
remains dormant until it’s too late. Java Server Pages that invoke Beans for data retrieval
from a database should be considered as a significant performance issue by the
development team and should be rectified before deploying the application into the
production environment. What about looping within code to retrieve data out of a
financial database and, at the same time, the code for repainting the presentation of the

Paper 36726
Page 2 of 11
 Application Server

data is executed each time, or is never executed? In one extreme, resources were utilized
to retrieve and process the same data over and over again, or the code to present the
data to the user is never executed by the application.
Coding inefficiencies at the component level have a dramatic affect on application
performance as resources are exhausted by the application whereas they could have been
used by other applications. A secondary goal should be to ensure that each component of
an application properly utilizes resources it consumes, and does not disturb the
consumption of resources by ancillary applications.

STANDARDS? WE DON’T HAVE ANY STANDARDS

Here is a question to help explain this pitfall. How many different ways can 1 and 1
be summed to equal 2? The answer seems quite obvious, yet there always seems to be
more than one answer. The issue is that different methods of performing the same task
are available and no two solutions, or methods to arrive at the same solution, are equal.
In the Java space, not following development and deployment standards can be
disastrous. With the number of individual components that must be integrated together
to achieve a working application increasing, relying only on creativity and “trial and error”
versus tried and true practices may eventually lead to a poorly designed, implemented
and deployed application. If organizational standards are not available that
describe/recommend how to implement specific J2EE components, then relying on
industry standards must be an alternative.

STANDARDS EXIST – NO ONE USES THEM

“Rules are made to be broken”. Such a statement seems to apply more and more
for application deployment. Management creates standards to ensure a common look and
feel for all applications deployed within the enterprise and some developers view this as a
violation of their creativity. They rebel by inflicting unapproved technologies or
unapproved implementation methodologies on the enterprise and tragedy begins.
Applications begin to fail or ineffectively communicate with each other; integration
becomes a test in stress management versus a seamless process. Or even worse –
applications begin to conflict with each other on the deployed platform. The result is a
customer’s inability to process transactions properly and within their expectations,
causing potential revenue losses and management wondering how and why this occurred.
If both industry groups and enterprises create standards, there must be a reason
for their existence. Enterprises seek consistency within application deployments, as it
enables them to reuse resources or to embed new technology within existing resources at
a significantly lower cost. Management and developers must be cognizant of these
requirements as new applications are developed and deployed, as non-compliance will
force delays or even cancellation of projects critical to the company.

POOR TESTING STRATEGIES – WHY TEST?

If this question is asked by anyone within the deployment organization, they have
never experienced an application deployment that absolutely failed. Fortunately, no such
person exists within IT so everyone assumes that testing is a positive process. All too
often, application deployment testing involves creating a lab environment where hardware

Paper 36726
Page 3 of 11
 Application Server

is cleansed from applications and the new deployment process is tested. Well, of course
this will work, as preexisting software that may cause conflicts or installation issues does
not exist. However, this is how many organizations test the deployment of technology.
Application deployments must include a variety of testing strategies long before the
application is migrated into the production environment. Only after exhaustive testing
should customers have the ability to use the new application to support the enterprise.
Unfortunately for Java applications, testing is not as simple as it was for
client/server applications. In many cases, application deployment testing involves
technology not within the walls of the data center; external links to web sites, data
verification organizations (i.e.: Paypall, etc.), and other internal/external applications exist
to support the business requirements of the enterprise. With additional layers of
technology imposed upon network-centric applications, the type of testing involved
becomes complicated, as any failure in these components affects both performance and
functionality. Thus, to ensure that applications perform according to the original design
requirements, full functionality testing, load/stress testing, and deployment testing must
occur before the final deployment into the production environment.

PRODUCTION IMPLEMENTATION PITFALLS

What else can go wrong? Up to this point the design requirements were complete,
developers created a solid application, and functional testing/validation activities did
locate some issues that were immediately rectified prior to signoff. So, the application
should be ready for deployment, correct? Well, in reality some additional pitfalls can
occur if management is not careful. Following are some issues that seem to crop up time
and time again.
THIS APPLICATION WILL WORK ON THE NETWORK – RIGHT?
Java applications, by virtue of their inherent nature, are network-centric; they rely
heavily on network resources to communicate, both internally and externally to the
enterprise, for successful execution and data management. In many cases, organizational
infrastructures have sufficient capacity to accommodate additional load, and certainly can
withstand bursts of load from applications demanding significant levels of resources.
However, if each application attempted to test the “outer limits” of the infrastructure,
eventually something must break.
Most application deployment teams “assume” that the network infrastructure
contains sufficient bandwidth to accommodate their application, and are caught off guard
when users complain of slow response time. Application performance problems within the
Java environment only complicate the problems by pointing at the network, instead of the
application, for performance problems. Requests to application servers and database
servers throughout the enterprise, as well as requests to external resources, must be
examined for ways to improve performance for large-scale, enterprise ready applications.

FIX IT NOW – IT WILL NOT IMPACT ANYONE

This is one of the most common pitfalls experienced by organizations. An
application user experiences a problem with a order entry application and contacts their
help desk for assistance. It is determined that several users are experiencing the same
problem and the development team is contacted to examine the problem and provide

Paper 36726
Page 4 of 11
 Application Server

some feedback to the application user community. The development team locates the
problem and provides a fix for the user community. However, instead of validating the
patch, the team issues the patch from the development environment, without adequate
testing, and places the patch directly into production. Application users are excited to
hear that the problem they identified to the help desk has been repaired; they proceed to
re-enter their data when the application freezes up. How could this be? This should have
been repaired. What happened?
Or how about application patches that are applied to the production environment
without any documentation as part of the follow up? When the server is reloaded, all of
the “one-time” patch repairs are lost and no one has any idea where the patches are or
what they repaired.
Last-minute patches or quick production fixes were somewhat manageable in the
client/server application age. With Java applications, the impact could be much greater,
as application changes could impact web services that are invoked from outside the
organization. Production changes must be thoroughly tested and validated prior to a
complete rollout and sufficient follow up must be performed to ensure that the integrity of
the application is not lost should other changes occur.

WHY DID THE LIGHTS GO OUT?

Technology is used for a wide variety of applications. From keeping an
automobile’s fuel flow moving smoothly and mixing properly to simulating a surgeon’s
hand during complicated remote heart surgery, technology either assists or controls
activities once performed manually. Unfortunately, technology is bound by a very
significant fault – that of human error. Remember, a computer is only as good as the
person who programmed it.
Changes to technology that may cause production outages can have a significant
impact on an enterprise’s bottom line as well as its perception in the market. Stories such
as viruses dismantling many of the Internet’s backbone sponsors brought email, web
surfing, and online ordering to a screeching halt. Security patches to software prevented
orders from being placed within many companies. The list is endless.
Java applications impact organizations more so then did their client/server brothers,
as external resources are often part of the application deployment. Minor changes that
cause “unwanted” downtime impact how organizations can respond to demands in the
future. It is for this reason that anything that “may” impact the external perception of an
organization via technology must be carefully scrutinized before implemented.

IMPROVING THE APPLICATION DEPLOYMENT PROCESS

Now that the traditional pitfalls have been discussed at length, how can some of
these be mitigated such that the frequency of occurrence is minimized in the future? Part
of the overall solution involves technology, yet refinements to existing processes are
necessary to ensure that technology is used effectively and correctly. Technology cannot
replace people and process – It can only assist, improve and automate.
Both Oracle and Compuware offer technology solutions to assist developers and
administrators create, test and deploy Java centric applications successfully and with
minimal failures. The technology used for each phase of the application deployment
process depends on how the organization would like to be positioned within the market.

Paper 36726
Page 5 of 11
 Application Server

Complementary technology is available for many of the tasks discussed below, however,
to simplify the selection process, a chart is provided. The theme of this chart is
“Build/Test/Manage” and showcases both Oracle and Compuware technology available for
creating a complete solution.

Oracle Compuware
Technology Technology
Building Java Constructing Java JDeveloper/Oracle OptimalJ/OptimalView/Unif
Applications Applications Portal ace
Debugging Java DevPartnerDB,
Applications DevPartnerJava
Testing Java Testing and TestPartner, QACenter,
Applications Validating Java Vantage
Applications
Load Testing Java QACenter
Applications
Managing Java Deploying Java Oracle9i Application
Application Applications Server
Deployments Managing Java Oracle Enterprise Vantage
Applications Manager

IMPROVING ACTIVITIES AT DEVELOPMENT TIME

DEVELOP SMALL – TEST OFTEN
Creating the entire application before any testing occurs is probably not a
suggested methodology for success. All too often, portions of code are missing or
incorrect and finding the problem is too difficult, leading to a complete re-write of that
portion of the application.
Java development lends itself to component-based development and testing. The
tendency for Java applications is to link both internal and external systems to provide a
comprehensive solution for the user. Order-entry systems that integrate with inventory or
credit processing systems must contain links to external systems. The amount of work to
integrate systems such as these could be quite time consuming and, without adequate
attention, may cause irreparable harm if incomplete. Two distinct approaches exist for
achieving the same goal: an application ready for production deployment.
Using Oracle’s JDeveloper9i, application developers and utilize Oracle’s workflow
technology to visually document the various integration points within the application, add
various customizations as required by the application community, and then generate the
code for the Oracle9i Application Server. The integration between Oracle9iAS and
JDeveloper9i allows the tools to share workflow management engines and provide for a
complete application deployment. JDeveloper9i allows an application developer to create
application “stubs” to contain skeleton Java code. This code exists to allow developers to
test specific features of their application without completing all of the code for each
module. Once the stub is tested to the satisfaction of the development team, the true

Paper 36726
Page 6 of 11
 Application Server

integration code can be added to the application for a complete deployment test. This
process can be followed throughout the development process until a working application
is ready for deployment.
The above scenario generates some extra benefits. First, it accommodates a
component-based development model giving developers the ability to create and test
portions of code before the entire product must be tested. Second, because of the
additional testing, this process also helps generate the various testing scenarios required
for final application testing and deployment. Third, this procedure allows key application
components to be distributed amongst multiple development teams for development,
testing and final integration.
An alternate approach would be to model the application business requirements
before any code is created, and then generate code as modeling is completed. For
example, Compuware’s OptimalJ with its industry standard Model Driven
Architecture/Pattern Based approach towards application development, the business
requirements are modeled before any code is created or generated. Any corrections for
integration and processing are caught well in advance of code generation. Changes to the
visual model or the generated application are coordinated to ensure consistency,
completeness, and reliability. Once complete, the appropriate deployment process begins
with the generation of the code for the specific platform being used. This includes
Oracle’s 9i Application Server. The application is now ready for the remainder of the
development and deployment processing.

WHY RE-INVENT THE WHEEL?

It’s accurate to articulate that developers enjoy creating the entire application that
they are responsible for. From beginning to end, developers want the responsibility of
using their creativity to satisfy application users. However, reinventing the wheel is not
only counter productive, it increases the amount of time required and cost associated for
application testing and management. Java developers are not unique in this situation,
however, it seems that most would prefer to create all components of the application
versus relying on other code to integrate with. However, as Java applications are created
to implement web services, integration is paramount for successful deployments.
Implementing Java applications with OptimalJ’s transformation and platform
independent patters is well suited for application integration projects. Transformation
Patters allow architects and developers to draft the architecture of the application based
on a strict methodology of developing the overall business requirements before any code
is created. The transformation patters can include “best practices” for key application
components; these transformation patters are initially included via a Class Diagram with
code included via Platform Specific Patterns (PSP) at final code generation/deployment.
Thus, for processes that may be common throughout the enterprise, each developer
implements the process exactly as required by the enterprise, thereby reducing the
amount of code maintenance required by the deployment team.

ENSURING QUALITY – IS THERE ANY OTHER OPTION?

Applications are designed to perform a specific function and perform that function
repetitively over time. Ensuring that the same output is received every time does not
seem like rocket science, however, it seems to be taken for granted. Everyone assumes

Paper 36726
Page 7 of 11
 Application Server

that the code works, and the checks and balances are infrequently performed to ensure
that functionality is correct.
For application deployments to be successful, sufficient testing strategies are
necessary to validate all functionality within the application before users complain about
functional performance. Java applications are no exception for functional testing. In fact,
functional testing is a critical success factor for every Java application; with integration a
key component of every Java application, validating each integration component prior to
rollout only helps to complete a successful application deployment.
Multiple levels of testing are necessary and will be discussed below. They are: (1)
component testing, (2) unit testing, (3) string testing, (4) full functional testing, and (5)
load/performance testing. Technologies embedded within JDeveloper9i and OptimalJ, as
well as complementary technology can assist in these processes.

COMPONENT TESTING
A Java developer, besides validating that application code works properly, must also
examine how efficient the application is, especially as it relates to system resource
utilization (CPU, memory, etc.). Although a process is functionally correct, it may
unnecessarily exhaust system resources causing other applications to fail. Java
applications, like any other application within the enterprise, must maintain a responsible
usage of the resources it consumes.
For users of either Oracle’s JDeveloper9i or Compuware’s OptimalJ development
technologies, Compuware’s DevPartner Java Edition (DPJ) product focuses on assisting
Java developers maintain a responsible environment. DPJ provides Java developers a
window into their application and all of the components it consumes, including all system
resources, external connections, network resources, etc. DPJ’s Code Coverage feature will
allow Java developers to review what code is executing to determine if threads of code are
within a particular execution stack or are absent. This feature helps Java developers
locate and isolate functional performance issues with both invalid code execution, missing
code execution or poorly performing code. The performance profiling feature allows Java
developers to look within the bowels of the application for hidden performance problems.
CPU, memory, I/O, and network consumption rates and statistics are available to assist
the developer determine where performance bottlenecks exist and how to correct them.
DPJ accomplishes these tasks by integrating with Oracle’s 9i Application Server to
generate performance data, review statistical measures for performance bottlenecks, and
to recommend corrective actions to the development team.

STRING & SYSTEM TESTING

String testing is often neglected but is widely recognized as a process for locating
significant functional and performance-related problems within applications. String
testing involves taking various levels of transaction requirements and testing the
application to determine how well the application performed relative to expectations. An
expectation level of 100% is reasonable and applications should be able to achieve this
only if they have been coded properly. String testing can be used to isolate performance
problems associated with specific transactions. The limiting factors are what technology
is available to assist with these procedures, what critical transactions must be analyzed
and how much time is available to perform these tasks?

Paper 36726
Page 8 of 11
 Application Server

System testing is more rigorous and involves testing and validating nearly all of the
functionality of the application before it is deployed to the masses. System testing
involves the development of concrete test plans to help validate application functionality,
locate missing functionality as compared to the requirements, and to locate unnecessary
functionality that was added but not required. System testing focuses on overall
functionality as well as movement within the application to ensure that functionality is
equal throughout the application.
Java/J2EE applications are not exempt to the requirements of complete string and
system testing. In fact, Java/J2EE applications must withstand a microscopic test of
successfulness, as these applications typically rely on external resources for portions of
their functionality. For example, string testing help isolate problems with credit card
verification transactions that periodically fail or with order-entry transactions that report
invalid information from the inventory system. System testing would help diagnose
problems with discrete transactions requiring varying functionality throughout the
application. System testing, for example, would help determine if transactions conflict
with each other. System testing would also help validate the “look and feel” requirements
throughout the application.
Oracle JDeveloper9i can satisfy a subset of the string and system requirements for
most Java applications; however, it is not strategically positioned as a quality assurance
product. For that Oracle relies on partner companies to deliver functionality to satisfy the
requirements of customers. Compuware’s TestPartner is specifically designed to provide
quality assurance services for web applications using either Microsoft or Java-centric
technology. By integrating with quality assurance software like Compuware’s QACenter,
Test Partner is able to create repeatable test scripts that will test functionality, ensuring
that Java Applications achieve the desired outputs. To provide quality assurance test with
performance metrics Compuware’s Vantage is able to generate performance metrics for
all tiers of Java applications, including client, application server and the back-end
database. These metrics can be used to determine if response times from the application
are acceptable and within service level agreement guidelines.
For testing that must determine why specific Java code is performing outside
required guidelines, Oracle developers have another venue for diagnosing the problem.
Compuware’s Vantage technology can break up a network transmission into the individual
components (i.e.: SQL, HTML, HTTP, etc.) and locate the performance problem
automatically, thereby eliminating any so-called “finger pointing” between application
deployment teams members. For example, Vantage can be used to examine 100% of the
network traffic and can open specific packets to review their payloads, diagnose
performance problems and provide developers with potential resolutions.
These techniques assist application deployment teams by helping to diagnose
performance problems located during quality assurance and stress testing phases. For
Oracle developers, this technology helps to improve the code deployed to Oracle9iAS,
both in code quality and code performance. By finding the problems before the mass user
community does, developers help to improve the time required to deploy enterprise-scale
applications.

LOAD TESTING
Load testing is considered a critical step before final enterprise-wide deployment,
yet it is a step that many consider unnecessary. Statements such as “This application

Paper 36726
Page 9 of 11
 Application Server

won’t fail” or “It will support thousands of concurrent users” are quite typical for ignoring
a stress test or load test phase. However, after only 50 concurrent users were successful
in accessing the application, thoughts return to steps that were ignored before final
deployment.
The goal of a complete, and thorough, load test is to provide proof that the
application will continue to operate and achieve required service level agreements as the
number of users increases and demands on the application increase. Quality assurance
testing should have been performed already so the goal is not to validate application
functionality. Should load testing locate performance-related issues that affect application
logic, the development teams can correct these issues prior to test signoff.
Load testing of Java applications is critical, as the load test is not only designed to
locate problems in the application, but also performance issues with the deployment
technology such as both the application server and the web server. Most Java application
deployments also include vanilla or “out of the box” deployments of both application
server and web server versus utilizing many of the performance-related features within
the products. Load testing helps evaluate the use of web caching, dynamic links and
much more for all tiers of the Java application. Load testing should also be a repeatable
process, without alteration, and should represent realistic transactions normally
performed by users. Fake or “creative” load test scripts only serve to validate the speed
with unrealistic processing. Ensuring that users are satisfied with performance results
should be the final acid test; if users are unable to replicate the work, they will never be
satisfied with the effort.
Compuware’s QACenter Performance Edition is uniquely adapted for load testing
Java Applications in preparation for final enterprise deployment. The QALoad components
is designed to help testers create and generate load test scripts that are repeatable and
will stress test all tiers of the application, not just the code itself. QACenter will generate
a plethora of performance statistics showing response times, latency times, I/O times, etc.
Additionally, QACenter is integrated with Vantage to monitor the overall deployment
environment to provide statistical information on how the new application testing has
affected all remaining applications in the environment. Additionally, Oracle Enterprise
Manager can manage and monitor all activities on the Oracle9i Application Server to help
determine if features should be activated/deactivated to improve overall performance.
Using a solid testing strategy, like the one mentioned here, will help ensure that service
level agreements can be maintained or exceeded and application failure will be
minimized.

PRODUCTION DEPLOYMENT
Product Deployment activities revolve around instituting the application throughout
the enterprise, managing the environment to ensure that the process goes smoothly,
monitoring enterprise resources for performance spikes and finally addressing last-minute
issues and ways to resolve them. Final coding, quality assurance testing, and load testing
should have already been performed. If not, it is guaranteed that the deployment will be
unsuccessful because the steps for deployment would be mixed in other activities.
Oracle Enterprise Manager is well qualified to manage and monitor activities and
traffic through the Oracle9i Application Server and the Oracle database. The tool include
metrics for determining if web-caching should be utilized, level of garbage collection
performed, I./O throughput, etc. Watching for unpopular wait events, locking, and

Paper 36726
Page 10 of 11
 Application Server

bottlenecks plus assisting in the backup and recovery processing for all tiers of the
application are some sample activities that OEM is well qualified for. Additionally OEM’s
Change Management module can be used to track and monitor application changes stored
within the database, such as Triggers, Procedures, etc. For external code changes, it is
recommended that versioning tools be utilized.
Compuware’s Vantage can be used for many of the same activities plus it provides
insight into the activities engaged throughout the enterprise infrastructure. This is
important for researching and mitigating performance problems that may or may not be
due to newly deployed Oracle-based applications. For massively distributed applications,
Vantage can watch and expose unwanted network traffic to improve overall application
performance. It is a primary goal of Vantage to view performance from an end user or
application perspective versus from the infrastructure up. Vantage can provide insight
into how applications are performing, help locate performance bottlenecks, from a user’s
perspective, and assist the support team by providing potential solutions to the
performance issue. Application response issues are what drive help desk tickets and
increase a customer’s level of impatience; eliminating or reducing these type of issues
can significantly reduce the headaches experience during application deployments.

SUMMING IT UP
Enterprise-wide application deployment involves more than just porting the
application from the development environment and into production. Too often application
changes are made in production, immediately deployed, and immediately fail. Proper
application deployment strategies involve a host of activities beginning with rigorous
development goals, quality assurance testing, stress testing and manageability. Java
application is far more complex than most view it to be; multiple deployment
environments, varying technologies, integration issues, and user demands make the
deployment complex in structure but simple in implementation if basic steps are
executed.
Using common sense for creating the Java application, thorough debugging and
testing by both application developers and quality assurance analysts, rigorous stress/load
testing to validate service level agreements and finally proactive monitoring will help
ensure that application deployments throughout the enterprise will be more successful
than without these critical steps. Utilization of technology by both Oracle and Compuware
for development, debugging, testing and finally management will help increase the level
of success and acceptance by removing variability discovered at the last minute. Instead,
variants will be discovered earlier in the development/deployment process and corrected
before users are affected.

CONTACT INFORMATION
Stephen Karniotis is the Technical Alliance Manager and Product Manager for
Compuware’s Oracle-related technology offerings. He can be reached at
Stephen.Karniotis@Compuware.com.

Paper 36726
Page 11 of 11