The candidate confirms that the work submitted is their own and the appropriate credit has been
given where reference has been made to the work of others
I understand that failure to attribute material which is obtained from another source may be
considered as plagiarism.
Signed: …………………………………………………………………………………………………..
Replacing TUXEDO Karl Swire
B.Sc. (Hons.) Computing 2001/2002
II
Summary The Midshires Insurance Company (Hereafter referred to as The Company) is a large financial
institution with a head office in The Midlands and over 150 branches throughout the UK. The annual
turnover is over £500 million and the company holds assets totalling over £11 billion.
On migration from the existing Bull mainframe system some 3 years ago Hewlett Packard (HP) and
Olivetti UK were invited in as consultants to create a new system. The system specification was
produced after a long consultation period and briefly comprised the following system:
An Oracle 7 database running on HP Unix Servers, BEA TUXEDO middleware application also
running on HP Unix and a Visual Basic front end for all branches running a GUI for staff and sitting
on top of an Olivetti proprietary C++ wrapper application called AB2.
The information used about The Company in this document was obtained from an actual organisation.
All figures and values that have been obtained from the organisation are accurate from the
information given. As the organisation is in a sensitive area of the market it was felt that the data
should appear to have originated from a fictitious organisation. However, this does not detract from
the fact that The Company is based on a real business and the way it is operated and the systems
described in this document are an accurate reflection of the way they conduct their day to day
business.
The project aims to show that a replacement for the TUXEDO middleware application could be
incorporated in a new system that would greatly enhance the existing functionality by providing a
much more clearly designed, scalable and economical solution.
The objectives for the project are to clearly define a new system, if such a system exists and to show
how it could be delivered and installed into the company with a minimal level of disruption to all
members of staff. Initially the project will focus on the existing system and why it is believed that it is
unsuitable in the modern technological climate. Research into alternatives will be introduced and the
suitability of these alternatives will be evaluated. The solution to the problem will then be outlined
and the implementation of this will be covered in detail. An evaluation of the outlined solution and its
potential for implementation will be discussed along with any further enhancements that could be
made to the proposed solution to create a more holistic solution to the problem.
Where currency conversions have been performed within this document the rates used have been as
follows:
• 1 United States Dollar ($) = 0.69 British Pounds (£)
III
Contents
The problem outlined.................................................................................................................... 1
How the existing system works .................................................................................................. 1
About TUXEDO....................................................................................................................... 2
What exactly does TUXEDO do within The Company? ............................................................... 3
The current network architecture ................................................................................................ 4
The problem defined.................................................................................................................. 6
Problem Summary..................................................................................................................... 8
An Alternative System................................................................................................................ 10
How to Evaluate an Alternative ................................................................................................ 10
System Comparisons ............................................................................................................... 14
The Business Case...................................................................................................................... 15
What the Existing System Costs ............................................................................................... 15
Will the New System Save Any Money?................................................................................... 16
The Benefits of The New System............................................................................................. 19
The Technical: How Will it Be Done?.......................................................................................... 21
The World of Microsoft COM and COM+................................................................................ 21
Deployment ............................................................................................................................... 28
System Installation and Testing ................................................................................................ 28
Deploying the System.............................................................................................................. 28
Socio-Political Consideration ...................................................................................................... 29
Developers ‘camps’................................................................................................................. 29
Other Alternative Technologies ................................................................................................... 31
Overview................................................................................................................................ 31
The existing competition.......................................................................................................... 32
The World of JAVA................................................................................................................ 33
Other alternatives .................................................................................................................... 36
Evaluations ................................................................................................................................ 37
Will It Work? .......................................................................................................................... 37
Will It Be Adopted?................................................................................................................. 38
Further Enhancements................................................................................................................. 40
IV
The Head Office Data Access System....................................................................................... 40
Other Possible Improvements................................................................................................... 40
Glossary..................................................................................................................................... 42
References ................................................................................................................................. 43
V
Figure 1: Transaction Processing System Model............................................................................3
Figure 2: Current Network Architecture ........................................................................................5
Figure 3: Benchmark Results for Non-Clustered Systems ..............................................................13
Figure 4: Benchmark Results for Clustered Systems......................................................................13
Figure 5: Current System Costs...................................................................................................16
Figure 6: Potential Savings.........................................................................................................19
Figure 7: How MIDL.EXE Works................................................................................................23
Figure 8: COM v COM+ Functionality........................................................................................24
Figure 9: Internet Usage.............................................................................................................31
Figure 10: The CORBA Model....................................................................................................34
1
The problem outlined
How the existing system works The Company is a large financial organisation and conducts its business through a network of
branches that cover a large proportion of the UK. It has a traditional customer facing counter style
approach to business and over 80% of business is through this method. The Company has recently
been developing an internet presence to increase business and also has a telephone call centre
operation from its Head Office to enable customers to conduct certain transactions at their own
convenience.
As with most major financial institutions The Company was an early entrant into the business
computerisation market. Originally the system revolved around a Bull mainframe computer with
transactions being processed on a nightly basis after close of business. This evolved to an extent that
certain transactions could be processed ‘live’ during office hours. Obviously this introduced a new
level of problem with the potential for missed or aborted transactions causing huge problems. Bull
had developed a solution to this called TDS it acted as a transaction management and monitoring
application and was integrated into the mainframe operating system. This was an improvement and
extension of OLBS (On Line Banking System) that Honeywell-Bull developed in the late 1960’s
which is seen as one of, if not the first transactional system. Some of the functionality was to allow
distributed transactions to be processed online, specifically for banking customers and to be able to
retain database integrity [28].
Most of the information available to counter staff at this time was displayed on small terminals that
accessed the database using COBOL applications, some of which began to be written ‘in-house’.
In 1997 inline with most other financial providers The Company decided that the existing system was
not suitable and they called in one of the leading consultants at the time to the financial sector:
Olivetti UK. At this time they also used Hewlett Packard as hardware suppliers and they were also
invited in to consult. As software providers to the financial sector Olivetti UK had developed an
application based on C++ called AB2 – Application to Business Banking. This was to be used as the
basis for ‘wrapping’ transactions at the branch end and connecting to the newly specified Oracle 7
database running on Hewlett Packard supplied UNIX servers. The front-end system was written in
Visual Basic ® at the branch end and all data passing between branch and Head Office was wrapped
by the AB2 application in to small ‘messages’. The system needed some middleware to allow
communication between the two disjunct components. As the middleware had to be message oriented,
2
as opposed to RPC-based or Object Request Broker (ORB)[19] TUXEDO was recommended which
at the time was a prominent market leader in this area.
All company Tuxedo services are of the request/response type; i.e. the client application sends a
service request to the server and waits until it gets a response (or a timeout condition). This is very
much down to the fact that the implementation of Tuxedo was designed to replace (and mimic) the TP
Monitor that existed on the Bull mainframe before the migration to Unix. At that time a decision was
made not to change the branch application during a period of major upheaval and therefore Tuxedo
needed to act in a very similar way to TDS to ease migration.
About TUXEDO TUXEDO provided similar functionality to the Bull TDS monitor and was widely used and acclaimed
as a solution to Online Transaction Processing (OLTP) problems [1,7,12] and was fully compliant
with the XA specification [29] for distributed transaction processing. “The XA Specification was
developed by the X/Open Company Ltd, an independent world-wide organisation supported by many
of the largest information systems suppliers and software companies” [15], Page 734. The API
specified by this standard contains the key tx interface which provides for the basic tx_begin(),
tx_commit() and tx_rollback functions which are key to any transaction processing system.
TUXEDO is such an application and was developed originally by AT & T in the 1970’s. It grew to
become the most widely implemented transaction management application used in 3-tier architecture
in the world. Based on TUX (Transactions for Unix) and eventually renamed in 1984 as TUXEDO
(TUX for Extended Distributed Operations) and the first commercial release (4.0) was implemented
in 1989. The system was acquired by Novell in 1993 and was sold to BEA Systems (The current
owners in 1996)
Middleware.net describes TUXEDO as at least three things:
• “It's middleware: it relays requests and responses between client and server processes (with
or without transactions).
• it's a Transaction Processing (TP) monitor: it begins, terminates, and monitors transactions
on behalf of client and server processes.
• it's a Distributed TP monitor (DTP): it allows the transaction participants to be located on
different machines or associated with different databases” [16]
3
What exactly does TUXEDO do within The Company? TUXEDO purely acts as a transaction management and monitoring system and is integral part of the
complete transaction processing system at The Company. . As TUXEDO is MOM (Message Oriented
Middleware) it performs as the middle layer within the 3-tier hierarchy employed by The Company
and manages transaction based on messaging between client and server, in this case branch client and
Head Office Oracle DBMS. One of the roles of TUXEDO is to ensure that the database keeps its
ACID (Atomicity, Consistency, Isolation and Durability) properties.
TUXEDO is primarily employed as a TP Monitor within The Company, Lewis, Bernstein and Kifer
give this definition:
“The TP Monitor provides some services similar to those provided by an operating system. The
operating system creates the abstraction of concurrently executing processes that can communicate
with one another, and provides theses processes with shared access to the physical resources of the
computer system. The TP monitor builds on this abstraction to create the abstraction of transactions
that execute concurrently in a heterogeneous distributed environment” [15] page 734.
In terms of a reference model for a transaction processing system the structure is similar to Figure 1.
Figure 1: Transaction Processing System Model
Application Layer
TP Monitor
Operating System
Hardware
In this model the transactional API sits on top of the TP Monitor layer where it is accessed by
developers.
Within The Company this ensures that transactions commit, abort or are rolled back. The application
will repeatedly try to commit erroneous transactions until success is achieved. If this is impossible due
to a fault somewhere within the calling application an error log is generated and passed to the owner
4
of the application causing the fault. TUXEDO client runs on every branch server and the server
element runs on dedicated servers at Head Office (see Figure 2). TUXEDO is licensed on a named
user basis for the developer license (5) and a connection license for each individual client-server
connection (300).
The current network architecture After the migration to the new system The Company had to ensure that the networking environment
was able to cope with the new increased workload that was going to fall upon the network. Obviously,
with transactions now being processed primarily in real time there would have to be serious
consideration to ensure that no network failures occurred or to ensure safeguards in case of such a
failure. With the advance of networking technology it was reasonably easy to put into place a very
reliable high-speed network between the branches and Head Office. Figure 2 highlights the existing
network architecture of The Company.
As is to be expected The Company Head Office and branches run a standard Ethernet LAN, most of
which now runs at 100-BaseTX (100Mb/s). Each branch has a local server running Windows NT®
and also the TUXEDO client. The branches and Head Office are connected via an SMDS WAN
(Wide Area Network) SMDS (Switched Multimegabit Data Service). CISCO Systems define SMDS
as a high-speed packet-switched datagram based WAN networking technology used for high-speed
communication over public data networks (PDN’s). It can use fibre or copper based cabling and can
support speeds of up to 44 Mb/s dependant on the transmission facilities [5]. In addition to the
facilities provided by the WAN each branch has an ISDN connection with Head Office. Should a
WAN failure be detected this line will automatically be used as the prime method of communication
between the branch and the Head Office systems.
At Head Office TUXEDO Servers communicate to the corporate Oracle database (approx. 200Gb) via
a dedicated 100Mb network connection using Oracle SQL*Net. This is the Oracle ® proprietary
networking system for use on server-server basis or from client tool-server, as in this instance. It can
work across multiple network protocols and operating systems and is briefly described in [22].
5
Figure 2: Current Network Architecture
Channelised E1 (64k to branches)
Channelised E1 (64k to branches)
Channelised E1 (64k to branches)
100 Mb
Head Office LAN
Channelised E1 (64k to branches)
100 Mb LAN
SMDS
Node
Router
Node
Node
Branch PC Branch PC Branch PC
Branch Server running BEA Tuxedo /WS 6.3
Fibre Channel
HP Storage Array
HP Unix running Oracle 7.3.4
HP Unix running Tuxedo Server 6.5
100Mb network supporting
SQL*Net traffic
Node
6
The problem defined Given that The Company is such a large institution and has to service the needs of many thousands of
customers the existing system is undesirable to say the least. The existing application structure within
the system is a very unpleasant ‘workaround’ for many problems or requirements that have developed
in the past. The underlying factor behind this is the use of the mixture of UNIX and Windows®
platforms to create a solution. This has required the use of TUXEDO as a middleware application just
to allow this co-habitation to continue. There are now many other technologies available that would
either replace or completely remove the need for this piece of software and allow for a much more
manageable system that would require less cross-platform knowledge to maintain. It is proposed that
the advances made in technology in the last 3-5 years may have completely negated the need for an
independent, third party middleware application altogether. Or, if this is not the case, there may be a
much more viable alternative to the current TUXEDO application that will serve The Company just as
well and may produce longer-term benefits.
The company has 4 people classified as TUXEDO administrators. As well as this the company has
over 30 members of staff who create the messages that TUXEDO uses to format the data that is
requested by the branch from the database and unformatted by the AB2 application underlying the
branch Visual Basic ® application. These modules are written in COBOL and access stored
procedures on the database. Many of these members of staff work full-time on debugging COBOL
modules, which have generated errors. As a proportion of this work also involves testing these
routines against a dummy Oracle database to ensure that it is not the database side of the system that
is at fault it would be conservative to assume that the TUXEDO aspect of the work accounts for 15
full-time members of staff working constantly on the maintenance and development of existing and
occasionally, new routines.
The Company also accesses the corporate database at Head Office and all the users there (some 600)
access the data in a different manner to the branch staff. Applications are written using the Oracle
Forms © tool (referred to as Forms hereafter) and the staff at Head Office use these applications to
retrieve the same or very similar data to branch staff. As both the Forms applications and the Visual
Basic ® applications use different stored procedures on the database this is seen as a large area where
there is good scope for improvement of the current system. Most of the developers who create the
COBOL applications for TUXEDO are also licensed users of the Forms tool. Further to this there are
7
a large number of other developers (around 30) within the Information Systems department whose
sole responsibility is to develop front-ends using Forms to allow data access for all the members of
staff at Head Office. As this will play a large part in the overall cost of the current system this area is
seen as a major area of investigation within the project. If a change in DBMS is thought to be needed
as part of the solution then obviously this will impact any other applications that are currently
supplied by the DBMS vendor (Oracle). There is potential for this to make a large saving in the
current system cost structure if such applications prove to be unnecessary or over engineered as they
are supplied on a named user basis only.
The day to day operation of the database system and its integrity is obviously of critical importance to
The Company and there are a large number of DBAs (Database Administrators) and other ancillary
staff employed to ensure that the DBMS is running at optimal levels of performance and security.
Given the critical nature of the data stored on the system The Company operates a very strict and
comprehensive system of security and their backup methods are exceptionally well planned and
implemented. The precise nature of the methods employed in this area are seen as beyond the scope of
this document. Should a solution be outlined that required a change in DBMS this staffing level would
almost certainly have to be maintained given that any replacement would also require the same high
levels of support and maintenance.
The existing network architecture takes advantage of many current technological advances and in that
respect is not in seen as being part of the problem. As the network is of a generic type that has been
adopted by a large percentage of simila r companies throughout the world it is doubtful that there
would be any benefit to be obtained by changing the existing architecture or operating methods. With
the rapid advances of such technologies as ATM (Asynchronous Transfer Mode) and huge advances
in wireless networking technologies this may be subject to change in the near future.
The remainder of the members of staff within the Information Systems department are employed in a
large range of duties including computer security, network support, systems support, change
administration, corporate statistics and a helpdesk for branch support. Interestingly, the branch Visual
Basic ® part of the system has only 8 members of staff employed in the maintenance, update and
development of the whole branch system, which is used by approximately 1000 users. Of these only 6
are developers and 2 are employed in the testing of any new or modified areas of the Visual Basic ®
application. This poses many interesting questions as to the viability of the ‘back-end’ of the system
as the branch system accounts for something in the region of 750 000 lines of code!
As well as supporting the business itself, the board has decided that the overall system is suitable for
sale or leases in whole, or in part to other similar financial institutions. This B2B (Business to
8
Business) plan could be a large provider of extra revenue to The Company. Already approaches have
been made to several other companies and there have been several interested parties invited to Head
Office to view the operation of the system and its abilities. If a ‘better’ system than the current one is
found to exist this may have serious impact on this scheme which will have to be taken into account
when discussing implementation of a replacement system.
Given the sensitivity of corporate spending, all prices used in the project relate to the standard pricing
structures available from manufacturers at list price. It is assumed that as long as list prices only are
used to assess a system’s cost then they represent a benchmark figure for the total cost of a system.
Any preferential pricing that The Company may negotiate with a supplier cannot be assessed for the
purpose of this project.
BEA Systems Inc.[3] were contacted for a pricing structure for TUXEDO but failed to respond. The
pricing information gained for the TUXEDO licenses has been gathered from several sources of
information to ensure a reasonable accurate figure. The most significant resources being The
Transaction Processing Council [28] from their benchmarking figures. Other relevant information on
TUXEDO pricing was also found at middleware.net [16]
Oracle Corporation was contacted for the current pricing structure and was most helpful in their
direction towards their online retail site [23] and indicated in their correspondence which products
would be in use at The Company. They also supplied information on the type of licensing which most
large enterprises would employ given the nature of the business outlined.
The main thrust of this project is to investigate a system or technology that could replace the
TUXEDO application and what this would involve. Further too this, as part of additional requirements
some further system changes may be outlined that are beyond the main project aims. This will involve
investigating other areas of the system that may be not be the optimal solution within the current
environment. These areas will be discussed later but will include reference to the current Head Office
data access approach, possible changes to the branch system and also a view of the newly
implemented customer focussed Internet site.
Problem Summary There are many potential areas for this system to be improved. TUXEDO is seen as the main area of
improvement but the fact that there is so much reliability on Oracle products and systems indicates
that this area may potentially provide huge cost savings. It is interesting to note that during the
9
research of this subject any research materials found pertaining to the functionality and use of TP
monitors and other similar systems has been very dated, with very few references to this particular
application within the last 5 years or so. This would indicate that the existing premise is correct i.e.
somewhere out there, there is a better way of doing this than is being done at present.
10
An Alternative System
How to Evaluate an Alternative During the investigation into this project the fundamental problem of evaluation came to light. How
can a system be judged? The financial aspect is an easy one to produce and will be delivered within
the remainder of the document. The figures of transaction volumes are known for The Company, but
how can we compare these to a system that does not exist?
The answer to this question was discovered during research. There is an independent body that is
comprised of many members of the IT community. These include the following but this is not an
exhaustive list:
• Microsoft
• BEA Systems
• Compaq
• Fujitsu Siemens
• Unisys
• Toshiba
• Sun Microsystems
• NEC
• Hewlett Packard
• Oracle
The purpose of this body, the Transaction Processing Performance Council (TPC) is:
“Mission The TPC is a non-profit corporation founded to define transaction processing and database
benchmarks and to disseminate objective, verifiable TPC performance data to the industry.” [28]
Obviously with this in mind and given the members of such an organisation then the systems they use
must be widely accepted by all contributing members and therefore not open to doubt. The TPC’s first
benchmark TPC-A was approved in 1989 and is described in great detail in [14]. Briefly it is based on
a banking system that performs many update-intensive transactions throughout the course of business.
11
“ ….workload is patterned after a simplified banking application. In this model, the bank contains one
or more branches. Each branch has 10 tellers and 100 000 customer accounts. A transaction occurs
when a teller enters a deposit or a withdrawal for a customer at some branch against an account.
Each teller enters transactions at an average rate of one every 10 seconds “ [14] page 489.
The benchmark has the following implementation constraints:
“
• The Transaction Processing system must support atomicity, consistency, isolation and durability
(ACID) properties during the test
• The tested system must preserve the effects of committed transactions and ensure database
consistency after recovering from any single failure of one of the following types
1. Failure of a single durable medium that contains database or recovery log data
2. Crash and reboot of the system
3. Loss of all or part of memory
• Eighty-five percent of the accounts processed by a teller must belong to the local branch(the one
to which the teller belongs. Fifteen percent of the accounts processed by a teller must be owned
by another branch (to be chosen uniformly from all of the other accounts)” [14] pages 489 – 490.
The TPC has enhanced this original benchmark with TPC-W for Internet based transaction
processing, TPC-H for a decision support system using ad-hoc queries against a database system and
TPC-R, similar to TCP-H but with advance knowledge of the queries. None of these benchmarks is
seen as relevant in the scope of this project.
The TPC-A benchmark has now been superseded by the TPC-C benchmark the summary of which
outlines the basic system and performance metrics:
“Approved in July of 1992, TPC Benchmark C is an on-line transaction processing (OLTP)
benchmark. TPC-C is more complex than previous OLTP benchmarks such as TPC-A because of its
multiple transaction types, more complex database and overall execution structure. TPC-C involves a
mix of five concurrent transactions of different types and complexity either executed on-line or queued
for deferred execution. The database is comprised of nine types of tables with a wide range of record
and population sizes. TPC-C is measured in transactions per minute (tpmC).
TPC-C simulates a complete computing environment where a population of users executes
transactions against a database. The benchmark is centred around the principal activities
(transactions) of an order-entry environment. These transactions include entering and delivering
12
orders, recording payments, checking the status of orders, and monitoring the level of stock at the
warehouses. While the benchmark portrays the activity of a wholesale supplier, TPC-C is not limited
to the activity of any particular business segment, but, rather represents any industry that must
manage, sell, or distribute a product or service.” [28]
The complete benchmark specification can be downloaded from [28].
The other metric of the TPC-C is the price/tpmC – this is based on the supplied cost of the system and
the cost of maintenance and support for the system for a period of 3 years per tpmC.
This benchmark perfectly suits the system in use by The Company at present and is therefore a key
element in the evaluation of any system to replace TUXEDO.
Hardware manufacturers from the list of TPC members submit system configurations and full details
of all hardware and software implemented on the system, theses systems are then tested and the
results are audited by independent auditors and the TPC then posts the results of these tests on their
web-site. Using TPC-C these are ranked in order of price, price/performance etc.
For the latest figures showing system evaluations from [28] using price/performance and a non-
clustered database configuration see figure 3. For clustered databases see figure 4.
For the current exhaustive list of SUTs (Systems Under Test) and the results please refer to Appendix
B.
13
Company System tpmC $/tpmC
Total Sys. Cost
Database Software Operating System TP Monitor # Server CPU's
Date Submitted Availability Date
Dell PowerEdge 2500/1.26/1P 11537.02 3.68 42451 Microsoft SQL Server 2000 Standard Edt.
Microsoft Windows 2000 Server Microsoft COM+ 1 03/12/2002 03/12/2002
Compaq ProLiant ML370 T02/1.26-2P
17078.88 3.99 67996 Microsoft SQL Server 2000 Standard Edt.
Microsoft Windows 2000 Server Microsoft COM+ 2 2/13/2002 3/30/2002
Dell PowerEdge 2500/1.13/1P 11314.11 4.38 49484 Microsoft SQL Server 2000 Standard Edt.
Microsoft Windows 2000 Server Microsoft COM+ 1 12/14/2001 12/14/2001
IBM IBM e(logo) xSeries 360 c/s 23027.66 4.41 101450 Microsoft SQL Server 2000 Standard Edt.
Microsoft Windows 2000 Server Microsoft COM+ 2 03/11/2002 09/10/2002
IBM IBM e(logo) xSeries 250 c/s 15533.72 4.67 72487 Microsoft SQL Server 2000 Standard Edt.
Microsoft Windows 2000 Server Microsoft COM+ 2 11/05/2001 11/05/2001
Dell PowerEdge 2500/1.13/1P 11320.02 4.7 53203 Microsoft SQL Server 2000 Standard Edt.
Microsoft Windows 2000 Server Microsoft COM+ 1 10/31/2001 10/31/2001
IBM IBM eServer xSeries 220 c/s
9112.91 4.76 43370 Microsoft SQL Server 2000 Standard Edt.
Microsoft Windows 2000 Server Microsoft COM+ 1 10/16/2001 10/16/2001
Compaq ProLiant ML530-X1000-1P 9347.24 4.77 44582 Microsoft SQL Server 2000 Microsoft Windows 2000 Server Microsoft COM+ 1 9/25/2001 9/25/2001 IBM IBM e(logo) xSeries 350 c/s 20422.01 5.39 110015 Microsoft SQL 2000 Microsoft Windows 2000 Server Microsoft COM+ 3 10/01/2001 10/01/2001 Compaq ProLiant ML570-700 3P 20207.2 5.64 113798 Microsoft SQL 2000 Microsoft Windows 2000 Server Microsoft COM+ 3 7/27/2001 9/26/2000
Figure 3: Benchmark Results for Non-Clustered Systems
Figure 4: Benchmark Results for Clustered Systems
Company System TpmC
$/tpmC Total Sys. Cost
Database Software Operating System TP Monitor # Server CPU's
Date Submitted Availability Date
Compaq ProLiant DL760-900-128P 410769.88 13.02 5344576 Microsoft SQL Server 2000 Enterprise Edition
Microsoft Windows 2000 Advanced Server
Microsoft COM+ 136 9/19/2001 10/15/2001
Compaq ProLiant DL760-900-192P 567882.56 14.04 7972452 Microsoft SQL Server 2000 Enterprise Edition
Microsoft Windows 2000 Advanced Server
Microsoft COM+ 204 9/19/2001 10/15/2001
Compaq ProLiant DL760-900-256P 709220.08 14.96 10603803 Microsoft SQL Server 2000 Enterprise Edition
Microsoft Windows 2000 Advanced Server
Microsoft COM+ 272 9/19/2001 10/15/2001
IBM IBM eServer xSeries 370 136766.67 16.93 2315801 Microsoft SQL Server 2000
Microsoft Windows 2000 Datacenter Server
Microsoft COM+ 36 4/24/2001 9/20/2001
IBM IBM e(logo) xSeries 370 c/s 121319.23 18.97 2301858 Microsoft SQL Server 2000
Microsoft Windows 2000 Datacenter Server
Microsoft COM+ 32 04/10/2001 5/31/2001
IBM IBM e(logo) xSeries 370 c/s 440879.95 19.35 8530671 IBM DB2 UDB 7.1 Microsoft Windows 2000 Advanced Server
Microsoft COM+ 128 04/11/2001 12/07/2000
IBM IBM e(logo) xSeries 370 c/s 363129.75 21.8 7915144 Microsoft SQL Server 2000
Microsoft Windows 2000 Datacenter Server
Microsoft COM+ 136 04/10/2001 5/31/2001
IBM IBM e(logo) xSeries 370 c/s 688220.9 22.58 15543346 Microsoft SQL Server 2000
Microsoft Windows 2000 Datacenter Server
Microsoft COM+ 280 04/10/2001 5/31/2001
14
System Comparisons
As can be seen from the current resultset there is absolutely no room for doubt about the conclusion.
Systems using Microsoft COM+ as a TP Monitor and using SQL Server as a DBMS are unbeatable in
price/performance metrics using clustered and non-clustered databases.
The figures from The Company show average throughput is in the region of 4-6 service activations
per second (240 –260 per min.). Peak transaction throughput is in the range of 30-40 (1800 – 3200 per
min.). All of the systems in the results far outweigh these figures with varying scales between factors
of 3 up to a factor of over 200.
Assuming that The Company would wish to specify a system that could easily cope with the business
demands of the moment and also allow for an increase in system usage in the future a system.
Any of the 20 systems shown in figures 3 and 4 would fit this profile. If The Company expects to
increases transaction volume by a large degree with the proposed Internet traffic then one of the larger
clustered systems may need to be considered. As the hardware configuration is to a certain extent
outside the domain of this project any of these systems may be chosen. The IBM e-server xSeries 370
produces figures that in excess of 40 times the throughput of the current system with a total system
cost of $2,315,801 and a tpmC price performance figure of $16.93/ tmpC. So the project will focus on
this system as the competition. As outlined earlier this cost metric is the complete cost of the system
over a 3 year period including all software and support it is not just the cost of the hardware.
The figures used below for this system can be found in the executive summary (Appendix C).
This system supports 112000 users which is approximately 70 times the current number of users (not
accounting for Internet usage). If this system were to be specified as a replacement for the existing
one then adjustments would have to be made to the overall price as the fact that there are over 100
‘client’ servers within the branch network. This would necessitate extra server hardware and software.
However, the specification of this system is from the ground up and includes all network hardware
and storage hardware, this of course may not be all necessary. It is proposed that the hardware issues
are ignored to a certain extent as this is not the core domain of this project and instead the focus will
be on the potential business advantages of the software and human sides of this as a proposed
solution.
15
The Business Case
What the Existing System Costs
As stated, the cost of hardware is largely outside the domain of this project. Its only relevance is that
the proposed software systems can utilise the hardware platform that they run on. We know this is
true for the existing system and we know from the results in figures 3 and 4 that the proposed system
also does this.
Using the figures gained from The Company and from the suppliers of the software an estimate can be
built up of the current running costs including support and maintenance. Coupled with this it is also
known to a slightly lesser degree of accuracy what the human element of this system costs The
Company.
The maintenance and support of all Oracle products cost The Company in excess of £200,000 per
annum. This covers support of the database product as well as support for the IDS (Internet
Development Suite) that contains the Oracle Forms application used at Head Office. This breaks
down into approximately £500 per annum per named user for IDS (Approximately 40) and the
balance in support for the databases themselves, which is of the 24 hour 7 days a week 4-hour
response type. As an addition to this, the company has recently recruited many more members of staff
that are developing on the Oracle platform. The named user license for IDS costs £3524 to purchase
and it is estimated that given current growth and the expanding B2B plan this will require at least
another 20 developers over the next 2 years. (Figures from [23])
TUXEDO support costs the company over £30 000 per annum. This covers the developer licenses for
TUXEDO developers (5) and the connection licenses for the TUXEDO connections to Head Office
and the branch servers (Approximately 300). This cost is based upon the maintenance price for the all
TUXEDO software which is 15% of license cost per annum per license. The TUXEDO developer
license currently cost £3500 and the connection license £600 per connection. (Figures from [16, 28])
The most difficult part of this costing equation is the human element. As was stated in the problem
definition for the purposes of this project we will assume that 15 people work full-time on the
maintenance of TUXEDO routines as well as the known 4 full-time TUXEDO administrators within
The Company.
16
According to [6] experienced TUXEDO developer jobs are within the range of £30 - £50 000 per
annum as at April 2002 and according to [8] the average starting salary in IT is around £19000. If we
take the average of the lower bounds this can be used as an estimate as to how much the human
element of TUXEDO costs The Company. The figure generated comes to just over £460,000 per
annum. Obviously this is a significant sum.
In summary the following costs are applicable for the current system:
Figure 5: Current System Costs
Oracle Software
Support (per annum)
Tuxedo Software
Support (per annum)
Human element for
Tuxedo (per annum) Annual Total
£200,000 £30,000 £460,000 £695,000.00
Will the New System Save Any Money? To replace the current system with the proposed alternative will obviously require large capital
expenditure for a new system, over £1.5 Million. Coupled to this there will be the other costs of
implementation and retraining for many members of staff that may run into many millions of pounds.
However, the fundamental premise of this project was to show that there is no need for TUXEDO or
any of the associated costs it has. Figures 3 and 4 show that this is indeed the case and the Microsoft
COM+ model can be used to replace all the functionality of TUXEDO. If this is allied with a
complete change in DBMS and all applications are placed on one platform it will significantly reduce
the skillsbase required within The Company and enable a consolidation of all systems.
Although Oracle is a different DBMS to SQL Server they are both based upon the relational model.
As this is the case the difference between the operation, maintenance and data access models for the
two distinct systems will be largely cosmetic. There is obviously a difference between Oracle SQL
and Microsoft’s T-SQL but again this is largely seen to be irrelevant. The key area where the learning
curve will be steep will be in the domain of the DBAs and the knowledge that they will have to
acquire to implement the same structure on the new DBMS and other areas such as database tuning
and security issues. However, this will be no different from the very similar process undergone by the
company in 1997 when the migration from the Bull mainframe system was undertaken
17
The current system requires that users at Head Office access data from the database using applications
written in Forms. Similar functionality exists at branch level using Visual Basic and is highly
efficient. If these branch applications were ported to the Head Office users then there would be no
need for the development of Forms to access data. This would save over £20 000 per annum initially
and in the longer term possibly significantly more as there would be no need to buy additional
licenses from Oracle.
As the company operates 10 distinct databases to allow for testing, backup and security the
maintenance costs from Oracle are extremely high – over £180,000 per annum. The Microsoft cost for
support of the SQL Server platform is listed at $2095 (£1445) per annum [28], therefore only about
£15000 per annum for 10 distinct SQL Server licenses
TUXEDO licenses are supported for every connection costing The Company around £25000 per
annum with the developer license support costing around £5000. COM+ is available from Microsoft
as part of the operating system and is therefore gratis. All branch servers currently run Windows NT4
and are supported in-house. The new system would require that branch servers be updated to
Windows 2000 Server which includes COM+. This may seem like another major expense. However,
in recent press articles [27] Microsoft have stated that they will no longer be offering support to NT4
users after 2005 (in this instance support means the release of Service Packs and patches). This means
that The Company would have had to budget for the upgrade to Windows 2000 from NT within the
next 3 years anyway.
There is only a small team within the IT department that develops in Visual Basic. However these
developers are responsible for the whole system at the branch end and it is a very large application.
This team is already familiar with the ideas of COM as they develop components all the time
throughout their working day. At the time of writing this report the Olivetti legacy AB2 is already in
the process of being replaced by COM objects and on top of this the existing branch system
functionality already uses many COM and DCOM objects. As many of these components have been
developed to marshal and handle the data received from the TUXEDO messages it is doubtful that a
migration to a system that is purely Microsoft based will cause any problems for this key area of the
system.
The Company has already given some of the existing TUXEDO COBOL developers Visual Basic
training but they have had little opportunity to utilise these skills. This accounts for approximately 12
of the existing developers. If the existing team were expanded by utilising these developers and all
members were given the necessary training into developing MTS components and implementing them
18
on the branch servers and on the proposed new Head Office database servers this would ensure that a
smooth migration could occur.
As all Head Office users access the database in a transparent manner using the Forms applications
developed in-house it is understood that there would need to be a period of readjustment if the
functionality of the branch front-end was ported to Head Office. However, this would not be a major
impedance to the staff as the branch system is very easy to use and was developed with user
simplicity in mind.
If this path were followed then the current Forms developers would not be required, as the team
developing and maintaining the front-end for what is currently two-thirds of company users would
expand this to cover the whole company. As none of the Forms developers do this part of their day to
day work full-time an estimate will have to be made as to how much this change would save The
Company in man-hours.
As The Company is currently recruiting heavily for the proposed B2B plan it is unlikely that any
members of staff would need to be made redundant if a system change were implemented. However,
the reduction in labour costs will have to be quantified and taken into account as no predictions of the
future staff requirements of The Company can be made.
Even if the developers who use the Forms application only do so for 2 hours per day this still accounts
for 2 man-years of labour. Working on the same formula as for the TUXEDO developers this
accounts for a saving of £50 000 per annum in labour costs. The remainder of the work done by these
employees involves developing stored procedures for the database and resolving problems that have
been identified by Head Office users. Obviously the database side of this work will remain but it is
foreseen that the issues of running 2 separate data access systems will enable labour reductions in the
future. For the purpose of this report though these potential savings cannot be allowed for.
If implementing the new system this restructuring enables a huge saving in labour costs.
Conservatively this accounts for 9 full-time member of staff. The four full-time TUXEDO
administrators and 3 other full-time members of staff from the original 15 highlighted as working on
TUXEDO issues full-time. As has been stated, the remaining 12 members of this group have had
some Visual Basic training and would be deployed in the proposed larger team that develops and
maintains the branch system. The remaining 2 members of staff reflect the amount of development
time used in the Forms application for the Head Office users applications as stated above.
19
The final breakdown of the potential savings in annual costs is shown in figure 6.
Figure 6: Potential Savings
Saving in DBMS
Support per annum (1)
Saving in TUXEDO
Support per annum
Labour Cost Saving
Other Oracle Support Saving
Total Saving Per annum
£180,000 £30,000 £220,500 £20,000 £450,500.00
(1) The TPC system specification includes within the cost all support and maintenance for the system
for the first 3 years. This would increase after 3 years to the standard Microsoft support price as stated
earlier.
As can be seen the savings of adopting this approach are significant. It should also be noted that rather
than completely removing the total number of members of staff maintaining TUXEDO a large
proportion of these can be re-deployed within the Visual Basic environment to enhance their skills
and help support the increased workload of that sector of the department.
This shows there is a strong advantage in moving towards this system as opposed to the current one. It
is believed that after the initial period of adjustment this option would allow the future development
of The Company’s information infrastructure to be much easier through the use of a single platform
approach with modular development an integral part of this infrastructure.
The Benefits of The New System The proposed system is far superior to the existing system in many respects. The cost factor is a great
incentive and over a period of 5 years should see the return of investment of the capital outlay.
This is in itself is an excellent justification for changing the system. However, there are other more
intangible benefits that are accessible given the proposed change. As the new system is based on the
component model any further development The Company may wish to get involved in can utilise the
strengths of this model. The whole Microsoft ethos driving COM and other technologies is the ability
to use component objects to allow any system to be infinitely scalable and easy to maintain. This give
The Company tremendous power when exploring potential avenues of growth. Closely allied with the
development of component systems SQL Server is designed to be accessed by Active Server Pages,
the Microsoft scripting based technology that allows for data access from browser-based systems.
This is an enormously powerful technology and the implementation of the Microsoft based system
20
now will ensure that any further exploration into web-based expansion can be easily supported by the
functionality of the new system. Allied to this, the specification of the new system will support over
100 000 concurrent users which means that it highly capable of supporting any high-level forays into
the world of Internet commerce.
21
The Technical: How Will it Be Done?
The World of Microsoft COM and COM+
According to the BBC “Windows may be on more than 90% of the world's Personal Computers” [2].
This is reflected within The Company and should be a useful aid to implementation of the new
system.
At The Company of over 1600 computers 97% currently use the Windows platform. This includes all
branch servers which run Microsoft Windows NT4®. As all support for these systems is currently
dealt with in-house this ensures a high level of knowledge about this platform already within The
Company.
The Microsoft technology to be implemented upon revolves around the implementation of COM
(Component Object Modelling) and other technologies that have evolved alongside this. The raison
d’être of COM is to produce an object system that supports binary reuse, versioning, location
transparency and language independence.
According to Charlie Kindel in [4], Page xiv, COM was developed after Bill Gates made a speech at
Comdex in 1990. At this conference Bill Gates gave one of his visions of the future as IAYF
(Information At Your Fingertips) and a small team was created at Microsoft to deliver this. The first
release of COM shipped as part of a release of OLE (Object Linking and Embedding) 2.0 in May
1993. This was the first vehicle to use COM.
Briefly OLE allows developers to define objects of many different types of Microsoft application and
manipulate them from inside other programs. This is most noticeably used in VBA (Visual Basic for
Application). Using this system a developer can access the functionality of another application e.g. the
numerical analysis and handling tools of Microsoft Excel can be used from within a Microsoft Word
document. Up until the subsequent development of DAO (Data Access Objects) and then ADO
(ActiveX Data Objects) it’s primary use was to access data in Microsoft Access databases and use
other products such as Excel and Word to format and display this data.
In the days before object oriented application development the norm was to develop programs using
‘hand-crafted’ or third party libraries that could be included in an application. The problem with this
Was that if n applications were running on a machine and they all used one specific library then that
library would have to be loaded in to memory n times thus using n units of memory. Obviously this is
22
a huge waste of resources. The Microsoft answer initially was to develop the DLL (Dynamic Link
Library) which only needed to be loaded once and could be accessed by many applications
simultaneously. This was a major advance. However, if these DLL’s had been compiled on different
compilers then the naming conventions would be different:
“To allow operator and function overloading, C++ compilers typically mangle the symbolic name of
each entry point to allow many uses of the same name (either with different argument types or in
different scopes) without breaking existing C-based linkers. This technique is often referred to as
name mangling.” [4] page 6.
This means that accessing a DLL from within an environment in which it hadn’t been developed
would not work. There are several workarounds for this problem but none of them are ideal. The other
issue with the DLL is versioning. If a new DLL is shipped to a client and it provides enhanced
functionality it is a simple task to install it on the system and all components accessing it will have the
new functionality available to them. However, if the interface has changed and some specific
applications access methods from the previous version of the DLL then they will not function, as the
new DLL will have overwritten the old version. Microsoft gets around this problem by incorporating
the version numbers within the DLL filename. This works, but the DLL directory soon becomes full
of old or largely unused DLLs.
To overcome these problems and to get to the ‘nuts and bolts’ of COM the implementation of the
code should be separated from the interface to the methods. Using the vptr (virtual pointer) and the
vtabl (virtual function table) used by almost all compilers the interface can be separated from the
implementation. Thus any compiler used can look at a class object and know how its virtual functions
are to be invoked. When creating new objects all member function that are to be used by another
object are declared as virtual, this informs the compiler that no implementation of this method is
required by the interface class only the ability to call these methods, not their implementations [4]
page 16.
This basic construction of abstraction of interface and implementation allows the developer to extend
existing interfaces as well as the ability to access different interfaces from one object. This is
essentially the Component Object Model.
To define a COM interface an IDL (Interface Definition Language) is used and the COM IDL is based
on the Open Software Foundation Distributed Computing Environment Remote Procedure Call [21].
This allows RPCs to be language neutral. The COM IDL also adds extra extensions that support the
Object-Oriented nature of COM. The Windows Operating System contains a compiler called
23
MIDL.EXE that creates the C++ compatible header files that contain abstract class definitions
corresponding to the interfaces defined in the IDL file. Box in [4] neatly shows how the base IDL file
is compiled to produce all the necessary structures to create the object interfaces:
Figure 7: How MIDL.EXE Works
This creates all the necessary files to allow the object to be able to be used by any calling process
once the implementation code has been written. The GUID (Globally Unique Identifier) is based on
the UUID (Universally Unique Identifier) defined in DCE RPC and are 128-bit numbers that are
guaranteed to be unique and are used throughout COM to name interfaces and implementations.
Using the UUIDGEN.EXE program on a Windows computer will give an example of one of theses
numbers e.g. 27f49ab2-ad63-4b01-a04b-c7abc1f0ad74.
When these names are applied to implementations they are referred to as Class Ids or CLSIDs and a
short visit to the registry of a Windows computer will reveal many thousands of these on the system.
Every COM object must implement the root interface Iunknown, this allows for reference counting
and QueryInterface services. This reference counting is then used by the object client to control
the lifetime of the object. The QueryInterface is used to access the actual methods of the object.
Once this is done this is the basis for developing any object that may be needed for any functionality
and since it’s inception it has seen a rapid growth in use by both Microsoft and many third party
vendors. The simplicity of component generation has led it to be widely adopted by developers in
many communities.
DOG.IDL Abstract Type Definition
MIDL.EXE
DLLDATA.C Interface Marshaller
Inprocess Server Code
DOG_P.C Interface Marshaller
definitions
DOG.TLB Tokenised IDL for
Visual Basic, Java etc.
DOG_U.C GUID Definitions
DOG.H C/C++ Type Definitions
24
In terms of accessibility COM has evolved since 1993. In 1995 Transparent COM for Visual Basic
4.0 was introduced allowing non-C++ developers to use COM objects. In 1996 DCOM (Distributed
COM) was introduced to allow the remote access of COM objects thus enabling COM to be used in a
distributed environment. Built in to DCOM were many security features to ensure that this technology
was as stable and secure as possible. At the same time Microsoft also introduced MTS (Microsoft
Transaction Server) to act as the Microsoft TP Monitor and enter the fray as a middleware enabler. In
1997 the functionality of COM was introduced to the JAVA community and then in 1998 COM+ was
introduced which provided new functionality and availability to a wide variety of programming
languages.
COM+ significantly reduces the amount of work that a developer has to do. With COM a lot of time
is spent defining IDLs, implementing automation support for access by scripting languages and
implementing the root interface Iunknown. Much of this work is very similar for each object
implementation and COM+ provides a default implementation for many of these tasks. The COM+
runtime also provides metadata describing the interfaces, this enables the automatic generation of
stubs and greatly helps with the development and installation of components.
Figure 8 from [13] shows the new functionality of COM+
Figure 8: COM v COM+ Functionality
With COM With COM +
Class Factory Class Factory
DLL Register DLL Register
Reference Counting Reference Counting
Query Interface Query Interface
IDispatch IDispatch
Connection Points Connection Points
Type Info Metadata
Methods Methods
The text in Italics denotes code that has to be written. As can be seen with the new default
implementations with COM+ there is much less work for the developer to do when using standard
object types.
25
“Developers merely implement classes to handle the application logic and provide information
describing class characteristics –the COM+ runtime does the rest….” [13]
The existing functionality of COM can still be used if the implementation the runtime provides is not
what the developer is looking for, this ensures maximum flexibility for all COM developers.
One of the key developments within the COM+ specification is the packaging of MTS with COM+.
One restriction with the COM architecture was that there was no standard way of adding external
services. Now with COM+ having external services such as MTS as part of the implementation it is
much easier to develop scalable applications that can run over a distributed network.
MTS is a TP monitor for Windows that is based upon DCOM. It is based upon four services: the MTS
Executive, Resource Managers, MTS Explorer and Microsoft Distributed Transaction Co-ordinator
(MSDTC).
The MTS executive is just the provider of system services to MTS components. Resource managers
do exactly as you would expect they manage system resources like databases. In conjunction with
MSDTC physical database operations are managed. MTS explorer is the GUI that allows services to
be monitored and managed by the user.
“When a transaction needs to be committed, MSDTC carries out a 2-phase commit with enlisted
resource managers to an atomic transaction………..
………….a client sends a request to a server. If the server receives the request it creates a
corresponding MTS component, its context object and transaction context if necessary…” [30] page
358.
The context object holds information about the transaction context, the transaction context is the link
between a transaction and those components instantiating the transactional method. All components
involved in the transaction share the transaction context during the lifetime of that transaction.
This method of transaction management is very similar to the way that TUXEDO manages
transactions within The Company. Using these component-based systems is the way towards the
development of a replacement system at The Company that does not involve a stand-alone
middleware application.
The main tasks for implementing the new system for The Company then involve the ability to develop
MTS. As has been said, there is already a large amount of COM object development done within the
26
existing framework so the only real unknown area is the MTS model. Functionally this is quite
straightforward and will not involve much training for the existing Visual Basic developers as the
functionality of the MTS transaction process is XA compliant and therefore acts in a very similar
manner to TUXEDO. The great benefit of the MTS model is the reuse aspect of it.
To implement a COM object that will be managed by MTS there is a slight change in syntax to that
which the developers will be used to. This is actually quite a small change and once the MTS service
is installed and configured the changes to existing code should be minimal.
The following Visual Basic code snippet demonstrates this:
Public Function GetAccBal(ByVal AccBal As long) As ADODB.Recordset Dim rs As ADODB.Recordset Dim strSQL As String On Error GoTo ErrHandler
strSQL = "SELECT t.acc as AccNo,t.Surname,a.AccBal FROM Accounts AS t JOIN AccBal AS a ON t.AccNum=a.AccNum"
Set rs = MTS.CreateInstance("ADODB.Recordset") rs.Open strSQL, ConnectionString Set GetAccBal = rs Exit Function ErrHandler:
Err.Raise Err.Number, Err.Source, Err.Description End Function
Rather than the usual new or CreateObject instantiation of a recordset object, which are commonly in
use within the system at The Company the MTS.CreateInstance is invoked which ensures that MTS
will manage this object throughout it’s lifetime and handle any scheduling/queuing issues that relate
to it.
Because transactions tend to be short in duration but high in frequency the implication for COM
objects is that it requires creating and deleting a large number of object instances. However, instead of
creating and deleting objects MTS recycles them. This greatly improves performance. The developer
creates the component to ‘renew’ its state MTS then creates the object once and tells the object to
recycle itself. The client sees the MTS component as a regular COM component and interacts with it
based on the requests/responses made. As the MTS component has a transactional state this can then
be used to access the database to request/send information. As most of the client side systems are
already implementing COM objects it will be reasonably straightforward to modify the existing DLLs
27
that format and unformat TUXEDO messages and make them MTS COM objects thus ensuring the
transactional nature will be a core component.
In addition to this, there are already systems in place at The Company that use ActiveX Data Objects
to access the current database system directly without using TUXEDO. These are not seen as mission
critical systems but their use has grown over the last 2 years. These systems are a perfect example of a
point of first contact to introduce the transactional nature of MTS into their operation thus enabling
total familiarisation with the MTS model on systems that have been developed completely ‘in-house’.
28
Deployment
System Installation and Testing The purchase price of the new system includes the delivery and installation of the system on the
amount of servers and clients specified in the specification in Appendix C.
Obviously the system can not be installed and go live immediately in such a sensitive environment so
the proposal is to use a system of smooth integration of the replacement system before completely
phasing out the existing system. In the initial period of installation the existing system will run as
normal. Once installed and tested by the suppliers the database staff will need to replicate the existing
databases on to the new SQL Server platform. Whilst this is in progress the existing stored procedures
from the Oracle database will have to be modified, if necessary, to ensure that they are syntactically
correct for the SQL Server platform.
Once this is completed the COM and MTS components can be implemented from the ‘front-end’ of
the system and then the system should work as a mirror to the existing one. It is expected that this
period of transition will take approximately 6 months.
The Company already has a rigorous testing procedure and at Head Office there are 3 test branches
running exactly the same software and architecture as a live branch. At least one of these should be
used full-time during the transition period to ensure correct installation and development of the new
system as if in a real-time environment. The system testing staff within the company will run all
standard tests and a full suite of regression tests against the new system to ensure the operation is as
expected. This is expected to begin once the system is functional and is likely to be concluded after
about 9 months.
Deploying the System Once the testing of the new system is completed in the test environment the new system will be
implemented following standard company practices. There are 6 branches close to the Head Office of
The Company that are already used as pilot branches when a new software release is to be ‘rolled-
out’. It is envisaged that these branches will have the new server software installed at the branch and
connected to the new database at Head Office as well as the existing TUXEDO software. Specia l
modifications will be made to the front-end software at these branches to allow the new system to run
29
in tandem with the existing system. This will require that when a transaction is done at the branch end
the software will function as normal using the TUXEDO system. In addition to this the same
transaction will be passed to the new system using MTS components. This will enable the live
database to be up to date but will also ensure smooth operation of all functionality within the new
system.
If this functions as expected for a given period of time, say 6 months, then it can be assumed that the
new system is functioning correctly and can be deployed in a similar manner in all branches. Once all
branches have the new system in place then the need to mirror all transactions to the Oracle database
will be unnecessary and the legacy system can then be completely removed.
During this time of running two systems the branch front-end functionality should have been ported to
the Head Office environment and the transition made there to access the SQL Server database rather
than the Oracle one. Given this time scale it is likely that the new system will have completely
replaced the old one within a period of 18 months. This transition period should have had no effect on
the perception of the system from the branch client end. However, there will have been a period of
change for the Head Office users.
Socio-Political Consideration
Developers ‘camps’ There will need to be a major sea change within the perception of certain groups of people from
within The Company. At present the Visual Basic system is maintained and developed by only 6
members of staff with over 40 working on the TUXEDO/Oracle system. The current view of many of
these TUXEDO/Oracle developers (and to some extent the management) is that the Visual Basic
application is basically just a conglomeration of forms or screens that have basically just been
‘painted’ by the Visual Basic developers. Nothing could be further from the truth, as said earlier the
Visual Basic application accounts for over 750 000 lines of code and performs many vital transaction,
backup and validation tasks other than just displaying data.
Unfortunately this view has led to many people believing that Visual Basic and is nothing more than a
screen-development tool and that it is not ‘real’ programming. Obviously this attitude will have to
undergo a fundamental change in the eyes of all staff as The Company will be completely reliant on
developers using Microsoft based products throughout the entire system. It will be necessary for all
30
staff within the IT department to be familiarised with the COM object model and how it basically
works. This will enable any staff that are to be retrained to have a better grasp of how the system
functions and give an overview of the elegance and simplicity of component based systems and show
how they can be extended with little work.
If this information can be put across to the whole department and it is understood then this will
engender a much more amicable and productive working environment. The main issue here is one of
history. It was the case up until 3-4 years ago that Visual Basic was a toy and not a tool. Many of the
developers in the department were mainframe COBOL programmers and have had no exposure to the
recent advances within the Microsoft development environment as a whole. Therefore they probably
have no perception of how much Visual Basic and the COM model have advanced and improved the
way that applications can be developed and the scalability and robustness of such applications. The
existing branch system itself is proof of this, it works extremely well and very rarely can it be made to
‘fall-over’.
31
Other Alternative Technologies
Overview Since TUXEDO was introduced to the world in 1989 the rate of technological advance within the
computer industry as a whole has been phenomenal. In addition to this, the rate of change in the way
systems have evolved has been exponential. In 1989 distributed computing was in its infancy and the
Internet was only known to a small percentage of the population. Figure 9 shows Internet growth from
August 1981 to January 2002. Data courtesy of The Internet Software Consortium [11]
Figure 9: Internet Usage
Since that time programming practices have changed completely and the concept of Object Oriented
programming and design has taken over the computer industry. Closely allied to these developments
has been the ‘holy grail’ of many programmers – reuse, this has been hastened by the many
component modelling techniques that have developed over the last 10 years. I will highlight examples
of other technologies that have emerged over the last few years and discuss their effectiveness in the
domain of this project. A short history of competing technologies will also be discussed to allow for a
broad overview of where things have led.
Internet Hosts
147,
344,
723
109,
574,
429
43,2
30,0
0029
,670
,000
16,1
46,0
00
4,85
2,00
0
2,21
7,00
0
727,
000
80,0
00
21
3
0
20000000
40000000
60000000
80000000
100000000
120000000
140000000
160000000
Aug
-81
Aug
-83
Aug
-85
Aug
-87
Aug
-89
Aug
-91
Aug
-93
Aug
-95
Aug
-97
Aug
-99
Aug
-01
Date
No
. Of H
ost
s
Internet Hosts
January 2002
January 1989
32
The existing competition At about the time TUXEDO was being deployed in various DTP (Distributed Transaction Processing)
systems throughout the world it had two main rivals, developed at about the same time but by rival
companies: Encina ® by Transarc Corporation and TOP END by NCR. Both competitors were aimed
at exactly the same market at TUXEDO and all three companies presented papers at Compcon ’92 to
showcase their products [1,24,25]. Interestingly all 3 claimed to be full compliant with the recently
announce X/Open DTP model [29]. All the systems offer a TP-monitor as well as transaction
processing functionality. TUXEDO and Encina however were only available on the UNIX platform.
The interesting point here is that of all 3 systems in 1992, TUXEDO and Encina still survive yet TOP
END does not. The main noticeable difference between the products at the time is that Encina uses the
Open Software Foundation’s DCE (Distributed Computing Environment) as it’s basic transaction
service. This is ultimately RPC (Remote Procedure Call) and therefore quite low-level. TOP END and
TUXEDO use message based transaction services, which allow the programmer to use more high-
level API’s when creating applications.
As stated earlier, TOP END is no more, unsurprisingly BEA Systems bought it from NCR in 1998
and it was merged with TUXEDO shortly thereafter.
Encina as a product is still available. Transarc became IBM Pittsburgh Labs. It would appear that the
development of Encina has continued alongside IBM’s other products. However, if the link to
products and transaction systems is followed from the IBM product web-site [10], there is no mention
of Encina being available.
The issue with any of the software systems that function in the same way as TUXEDO though is that
they have a high implementation and maintenance cost – this will be inline with the costing of
TUXEDO and will not represent any great increase in functionality or scalability and would not
benefit The Company financially. It is believed that there are other technologies available that would
do just this.
33
The World of JAVA
JAVA as a language only existed in the mind’s eye of the developers at Sun Microsystems when
TUXEDO was first deployed in the marketplace. The whole ethos behind JAVA is the “Write Once
Run Anywhere” maxim. Multi-platform support is what is needed in most businesses of today,
especially with the burgeoning of the Internet. In its initial stages of development this just didn’t
work. Code had to be re-written for different platforms and was inherently slower than C/C++
because JAVA has another layer of abstraction from the operating system, the JAVA Virtual
Machine. This in my opinion makes it more of an interpreted language than a compiled one and
therefore takes longer to ‘get the job done’. However, since JAVA is based on Object Oriented
methods it is far easier to write ‘componentised’ software and Sun have taken the lead in this area up
until recently. The other factor that now weighs heavily in favour of JAVA is that speed is now not an
issue to most commercial and personal users. The so-called Moore’s Law [18] states that the speed of
the processors will double every 18 months. Given that this was stated in 1965 and still holds true
today we can assume that the speed issue will only weigh heavily on the minds of users of high
intensity graphics and CAD/CAM packages.
Sun announced the new specification for its Enterprise JavaBeans™ (EJB) architecture in August
2001. In the introduction this was described as: “The Enterprise JavaBeans™ architecture is a
component architecture for the development and deployment of component-based business
application. Applications written using the Enterprise JavaBeans™ architecture are scalable,
transactional and multi-user secure. These applications may be written once, then deployed on any
server platform that supports the Enterprise JavaBeans™ specification” [26]
The fact that EJB applications will be transactional highlights the potentiality of this technology as a
possible replacement or extension for the existing system.
The EJB specification is part of the new Sun approach to business computing and is encapsulated
within J2EE (JAVA 2, Enterprise Edition) which Sun proposes as its all encompassing JAVA based
business solutions suite. This contains amongst other things, EJB, JTS (Java Transaction Server), JMS
(JAVA Message Service), JTA (JAVA Transaction API) and the new version of JDBC (JAVA
Database Connectivity API). This specification has been developed by Sun alongside many industry
partners in the IT world, including operating system, DBMS and middleware providers and sets a
standard for them all to adhere to.
34
Sun state that the new J2EE specification has been developed with openness in mind and that is why
so many industry partners have been invited to contribute. The idea of a transparent, open architecture
for all users is an excellent one and can not be discounted. Because this is the case it should
theoretically be possible for any vendor adhering to the standard to create an application that will run
on any other system that another supplier who adheres to the specification produces.
In many respects Sun have gone about this in the right way and have ensured that other architectures
will be accessible most notably CORBA and even Microsoft COM.
CORBA (Common Object Request Broker Architecture) is a standard for distributed computing that
has been developed by The Object Management Group (OMG) [20]. It enables client-server
communication based on objects. It many respects the CORBA standard is similar to existing methods
of communication like RPC in the fact that each server specifies interfaces to the objects it has using
an IDL (Interface Definition Language) which enables the client to access these objects. The
difference between CORBA and RPC is that within CORBA there is the Object Request Broker
(ORB). This is located between the client and any servers that it may access (Figure 10).
Figure 10: The CORBA Model
When a client calls a method based on the IDL it is the ORB that decodes this and locates the server
on which the object resides and then translates the way the method is called by the client into the way
the server expects the method to be called. Because ORB’s can be vendor specific the OMG has
created GIOP (General Inter-ORB Protocol) which allows ORB’s from one domain to map to objects
under another ORB’s domain. As these communications have to be delivered using real world
Client Server
IDL Skeleton IDL Stub
Object Request Broker
Request
35
networks the OMG has specified the IIOP (Internet Inter-ORB Protocol) to translate GIOP messages
into TCP/IP packets to be delivered over the Internet and other networks.
The description of the CORBA model has been quite detailed because it “…is rapidly becoming a
ubiquitous standard for distributed computing” [15], Page 528. As such Sun see it is an ideal
technology to integrate with the J2EE platform to allow for the most comprehensive compatibility
between new and legacy application. Because of this within the J2EE specification Sun have extended
their own version of RPC called RMI (Remote Method Invocation) to interface with the CORBA
IIOP. This RMI-IIOP standard is the basis for communication between EJB and other JAVA objects
and existing CORBA objects.
The JMS is the message-based area of J2EE that Sun has developed alongside middleware providers.
This ensure that all J2EE applications can access the functionality of existing transactional API’s,
these include TUXEDO and other BEA products as well as IBM’s MQ Series of products and various
other middleware products. To ensure compatibility with J2EE these API’s will be implemented by
the specific vendors of the systems. The vendors will implement JTS within their products to ensure
that the developers of client-side systems will not have to design and develop the whole business logic
of a transaction management system form the ground up and will have access to this functionality
from a higher level. Sun has also developed its own implementation of JTS called JTA which can be
implemented in environments where there is no existing middleware provider to create a complete
bottom-up suite of tools for any business environment.
Other important areas of the J2EE environment are JDBC which is the standard JAVA API for
accessing relational data and functions in exactly the same manner as the Microsoft version, ODBC
and the JAVA IDL which is the standard API for calling CORBA services.
The development of J2EE has largely been driven by the expansion of distributed computing into the
Internet where JAVA already is highly used. Because the JAVA paradigm evolves around the use of
components this has ensured that applications developed using these technologies will be highly
scalable and easy to reuse. Further factors that support the use of JAVA are the J2EE acceptance and
integration with other new technologies that have seen huge amounts of interest and deployment.
These include the ability to access data from server-side DBMSs using JSP (Java Server Pages) and
XML (eXtensible Mark-up Language) from a client browser – this area is the largest growth area of
the Internet over the last few years but does not figure highly in the domain of this project.
It should be noted that as man third party application vendors have been involved in the J2EE
specification there are many companies who have incorporated many of the features within their
36
software to ensure compliance. However, this still implies that these products will have to be
purchased and this consideration has to be accounted for. Obviously with the specification being open
The Company could embark on the route of utilising the JTA and developing their own custom built
transaction manager using EJB components at both server and client ends of the system.
Given that the J2EE specification has been developed with companies such as BEA Systems and
Oracle it is highly unlikely that it would be worth considering changing the current DBMS from
Oracle to another provider and all the major upheaval and capital outlay in terms of purchasing and
training that that would imply.
Other alternatives
The middleware market seems to be dominated by BEA Systems with TUXEDO and their enterprise
Internet middleware product, BEA WebLogic. As mentioned earlier IBM still produce Encina but
their main marketing thrust within their web-site if for their MQ Series of servers and related
middleware applications. It is seen as highly unlikely that any of theses alternate systems would
provide any benefit over the existing one given that the products all function in a similar manner and
still involve the need for a third party application rather than something that is either native or easily
implemented with the current architecture.
37
Evaluations
Will It Work? In terms of a solution to the problem outlined there is no doubt that the proposed system could be
implemented within The Company using the time scales outlined in the deployment section. There is
already a high level of skill and knowledge within The Company that could be used to ensure that this
system was implemented and functioning and would replace the existing system. The fact that there is
a core base of developers who are already highly skilled in component object modelling would mean
that the proposed system could be tailored to fit in with the current business requirements of The
Company.
There can be no doubt that the architectures described within this report are highly scalable and very
efficient. The figures for performance results from the TPC prove this fact beyond any doubt. The
system described is in many respects in the middle ground of the plethora of large-scale enterprise
systems available to a large company. However, the system described is easily able to cope with the
current demands of The Company and would certainly be suitable for an organisation processing
many times the transaction volume of The Company at present.
The fact that this system requires a complete replacement of the whole data access architecture of The
Company means that this would certainly be quite a ‘painful’ operation but it is believed that
scalability and modularity of the new system would reap great benefits in the long term. As stated
earlier the change in DBMS vendor would create many problems for The Company but this can be in
many respects no different to the transition undertaken when the migration took place from the
mainframe system to the current one.
The change in skills requirements for many of the existing developers would also cause many
problems but with many of these developers performing composite roles it would certainly clarify the
skill-set required for many of them after implementation. Existing Oracle developers could maintain
database related code, stored procedures and functions and the data access side of the system. The
existing COBOL developers who maintain TUXEDO routines could extend and improve upon there
Visual Basic and C++ skills to ensure that the system was operated at full optimality and new
developments could improve or extend existing functionality.
38
These skills that would be required are very marketable in the current IT marketplace and indeed
contain many current ‘buzzwords’. From a professional perspective this should then enhance the
employability prospects of any developer who has worked on such a system. In that respect the need
for change must certainly be an advantage to all current employees who wish to broaden their
experience using such an up to the minute system. It is understood that although widely proclaimed to
be ‘dead’ COBOL is still used extensively in legacy systems but with more and more companies
requiring enterprise level distributed systems the skills learnt by working on the proposed new system
would greatly enhance anyone’s CV. This must be seen as a positive ‘selling’ point to developers
worrying about changes in role.
Will It Be Adopted?
As mentioned in the socio-political section of this report, there are definitely two distinct camps
within The Company. It is hoped that the adoption of a new system would remove this completely
with the new experiences developers would have. However, the issues contained in this report would
cause many problems to many members of staff and management. There are several key areas where
these would weigh widely against the implementation of the system defined in this report.
Since the existing system was first specified The Company has had a very close working relationship
with Hewlett Packard. This covers all areas of IT from hardware to consultancy. Recently it was
Hewlett Packard that specified and planned the new e-commerce site for The Company. This
relationship has proved very reliable and would not be questionable. The reason that this may be a
problem is the fact that Hewlett Packard recommended this system in the first place and it may be
extremely difficult to persuade the management that the proposal is better. This is also coupled with
the bizarre attitude that seems to permeate the commercial IT industry that if something costs a lot to
research and implement then it must be better than something that is either free or significantly
cheaper!
The other major stumbling block that has been identified is the relationship that The Company has
with Oracle. Obviously this is highly lucrative for Oracle and would indeed be a major upset to them
to lose such a high profile customer. However, as has been said, the proposed system would not only
be cheaper than the current one but would also be infinitely more flexible. Granted, it is possible to
implement the MTS and COM+ aspects of this system and still retain the Oracle DBMS but it is felt
that this would not be a clear solution to the problem and would still maintain many of the inherent
issues within the current system.
39
Cost aside this would still require a double-ended approach to data access with Head Office users and
branch users continuing to run different systems, at least in the short term. This would mean that the
greatest benefits of the component aspect of the new system could not be implemented immediately
which would impact on the scalability of the system.
40
Further Enhancements
The Head Office Data Access System One enhancement beyond the scope of the project that has already been included is the ‘porting’ of
the branch system to Head Office users. This would have to be included initially to benefit from the
cost reducing option of ceasing to use the Oracle Internet Development Suite of applications. This
would ensure that there would be no further cost burden on the part of The Company from Oracle.
This is seen as a benefit to all users ensuring that data access is uniform across the whole company.
As this would unify all access to data it would make the maintenance and update of this system much
easier to test and roll out over the entire company and would significantly reduce the development
overhead compared to the existing system.
Other Possible Improvements The Company is heading toward a much broader delivery base than just the branch network with the
move into the Internet and the expansion of ‘call-centre’ based business. This expansion would be
significantly helped if there was a single method of data access both internally and externally. It is
believed that an ideal solution to this would be to begin the development of a browser based system to
be deployed on The Internet and The Company Intranet.
It is envisaged that this system would use current data access technologies such as ActiveX Data
Objects and Active Server Pages to allow staff to access all data presently viewed using Visual Basic
forms. The potential for such a system is huge and many extremely large organisations do this very
effectively at the present time.
For external use a system could be developed along the lines of many successful ‘e-tailing’ companies
such as Amazon.com and Jungle.com. Security is a key issue here but recent advances have made this
much less of a problem than was the case. If this was coupled with a browser based system for the
corporate Intranet then the system as a whole would be extremely flexible and infinitely scalable.
Introducing the use of technologies such as XML would ensure that both corporate and external users
could access large amounts of data swiftly and efficiently.
It is believed that this method of data access would also help with The Company’s business to
business venture. It would allow a uniform approach to viewing and retrieving information and would
41
surely appeal to potential purchasers of the system much more than the current rather outdated
approach.
Further to this Microsoft have advanced their development environment significantly within the last
year and claim that the new .NET technologies are completely platform and language transparent and
would be an ideal new technology for The Company to learn to use if this is indeed the case.
42
Glossary
ADO ActiveX Data Objects
ATM Asynchronous Transfer Mode
COM (and COM+) Component Object Model
CORBA Common Object Request Broker Architecture
DAO Data Access Objects
DBA Database Administrator
DBMS Database Management System
DCE Distributed Computing Environment
DCOM Distributed Component Object Model
EJB Enterprise Java Beans
GIOP General Inter-Orb Protocol
IIOP Internet Inter-Orb Protocol
J2EE Java 2 Enterprise Edition
JDBC Java Database Connectivity
JMS Java Message Service
JSP Java Server Pages
JTA Java Transaction API
JTS Java Transaction Server
MOM Message Oriented Middleware
OLTP Online Transaction Processing
OMG Object Management Group
RMI Remote Method Invocation
RMI-IIOP Remote Method Invocation Internet Inter-Orb Protocol
RPC Remote Procedure Call
TPC The Transaction Processing and Performance Council
XML eXtensible Markup Language
43
References [1] Andrade, J.M., Carges, M.T., MacBlane, M.R; Open online transaction processing with the
TUXEDO system. Compcon, Spring '92. Thirty-Seventh IEEE Computer Society International
Conference, Digest of Papers. , 1992 Page(s): 366 -371
[2] BBC News. http://news.bbc.co.uk/hi/english/sci/tech/newsid_279000/279926.stm, April 2002
[3] BEA Systems Inc., http://www.beasys.com, November 2001
[4] Box, D. Essential COM, Addison-Wesley, 1998
[5] CISCO Systems, http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/smds.htm, March
2002
[6] Computer Weekly, http://www.computerweekly.co.uk, April 2002
[7] Felt, E.P., Distributed transaction processing in the TUXEDO system, Parallel and Distributed
Information Systems, 1993., Proceedings of the Second International Conference on , 1993
Page(s): 266 -267
[8] Hickson, J., First Steps to an IT Career, BCS Computer Bulletin Young Professionals
http://www.bcs.org.uk/publicat/ebull/jan2000/article3.htm, April 2002
[9] History of OLBS, perso.club-internet.fr/febcm/english/ge400.htm, December 2001
[10] IBM Product List. http://www-3.ibm.com/software/ts/, March 2002
[11] Internet Software Consortium, http://www.isc.org/, March 2002
[12] Kauffmann, H and Schek, H.J., Extending TP-Monitors for Intra-Transaction Parallelism,
Parallel and Distributed Information Systems, 1996., Fourth International Conference on , 1996.
Page(s): 250 –261
[13] Kirtland, M. Object-Oriented Software Development Made Simple with COM+ Runtime
Services, Microsoft Systems Journal, November 1997
[14] Kohler, W.H.; Hsu, Y.-P. A benchmark for the performance evaluation of centralized and
distributed transaction processing systems Distributed Computing Systems, 1990. Proceedings.,
Second IEEE Workshop on Future Trends of , 1990 Page(s): 488 –493
[15] Lewis, P.M., Bernstein, A., Kifer, M., Databases and Transaction Processing: An Application
Oriented Approach, Addison-Wesley, 2002.
[16] Middleware.net, http://www.middleware.net/tuxedo, November 2001
[17] Mohan, C., Transaction Processing and Distributed Computing in the Internet Age
Tutorial Notes, 6th International Conference on Extending Database Technology (EDBT),
Valencia, Spain, 1998.
[18] Moore, G. Cramming more components onto integrated circuits, Electronics, Vol.38, No. 8,
April 19, 1965
44
[19] Network Computing, http://www.networkcomputing.com/netdesign/cdmwtypo.htm, January
2002
[20] The Object Management Group. http://www.omg.org, November 2001
[21] The Open Group (Formerly The Open Software Foundation) http://www.opengroup.org , April
2002
[22] Oracle FAQ’s, http://www.orafaq.com/faqnet.htm#WHAT, February 2002
[23] Oracle Corporation Store, http://www.oraclestore.oracle.com, November 2001
[24] Sherman, M., Distributed Transaction Processing with Encina, Compcon, Spring '92. Thirty-
Seventh IEEE Computer Society International Conference, Digest of Papers., 1992 Page(s):268 –
269
[25] Smerik, R., An Overview of TOP END, Compcon, Spring '92. Thirty-Seventh IEEE Computer
Society International Conference, Digest of Papers. , 1992 Page(s): 372 - 377
[26] Sun Microsystems. http://java.sun.com/products/ejb/docs.html, December 2001
[27] Swoyer, S., Microsoft Details Plan for Ending NT Party, Windows Enterprise News.
http://www.entmag.com/news/article.asp?EditorialsID=5119, March 2002
[28] Transaction Processing Council, http://www.tpc.org, March 2002
[29] X/Open Ltd., Reading, England, Distributed Transaction Processing: The XA Specification, 1991
[30] Yoon, I., Kim, H., Youn, C., Bae, D., Reliable Transaction Design using MTS, Computer
Software and Applications Conference, 2000. COMPSAC 2000. The 24th Annual International,
2000 Page(s): 357 -362
45
Appendix A
Project Management
Original and Revised Timetables and Reasons
The original timetable was submitted with the mid-project report. After a good start to research the
main problem encountered was the unwillingness from BEA Systems to pass on any data about the
pricing of TUXEDO. This problem was revisited several times to try and find the best sources of
information on TUXEDO licensing.
01/1
0/20
01
08/1
0/20
01
15/1
0/20
01
22/1
0/20
01
29/1
0/20
01
05/1
1/20
01
12/1
1/20
01
19/1
1/20
01
26/1
1/20
01
03/1
2/20
01
10/1
2/20
01
17/1
2/20
01
24/1
2/20
01
31/1
2/20
01
07/0
1/20
02
14/0
1/20
02
21/0
1/20
02
28/0
1/20
02
04/0
2/20
02
11/0
2/20
02
18/0
2/20
02
25/0
2/20
02
04/0
3/20
02
11/0
3/20
02
18/0
3/20
02
25/0
3/20
02
01/0
4/20
02
08/0
4/20
02
15/0
4/20
02
22/0
4/20
02
Problem DefinitionCompany InformationOracle and Tuxedo PricingResearch Mid-Project ReportIdentify AlternativesSpecify AlternativesBusiness CaseReport
01/1
0/20
01
08/1
0/20
01
15/1
0/20
01
22/1
0/20
01
29/1
0/20
01
05/1
1/20
01
12/1
1/20
01
19/1
1/20
01
26/1
1/20
01
03/1
2/20
01
10/1
2/20
01
17/1
2/20
01
24/1
2/20
01
31/1
2/20
01
07/0
1/20
02
14/0
1/20
02
21/0
1/20
02
28/0
1/20
02
04/0
2/20
02
11/0
2/20
02
18/0
2/20
02
25/0
2/20
02
04/0
3/20
02
11/0
3/20
02
18/0
3/20
02
25/0
3/20
02
01/0
4/20
02
08/0
4/20
02
15/0
4/20
02
22/0
4/20
02
Problem DefinitionCompany InformationOracle and Tuxedo PricingResearchMid-Project ReportIdentify AlternativesSpecify AlternativesBusiness CaseReport
Easter BreakChristmas and Exam Period
Easter BreakChristmas and Exam PeriodOriginal Timetable
Revised Timetable
46
The main difference from the original plan was the fact that there was a period of 3 –4 weeks over
Christmas when no significant work was carried out. This was partly due to the festive period but
more importantly the issues of revision for the January exams had to be addressed and were deemed
to be more important than the project as progress to date was satisfactory.
The length of time allocated to specify an alternative system was in the end far too long as the vast
majority of that work had been carried out by the TPC. Their criteria and choice of available system to
accomplish the task were far superior to any that the author could have investigated in the time
allowed. If the organisation had not existed this project would have had to rely heavily on
assumptions, which would have made the conclusions much less solid.
Other than this everything else has gone according to schedule except for a small piece of information
from The Company that was required for the business case that was requested over the Easter break.
Thankfully the response was swift.
Problems
The only real problem, which has been most frustrating, has been the inability to get absolutely
accurate prices from BEA Systems. The prices used within the document have been cross-checked
from several sources and appear to be reasonably accurate. However, in comparison to Oracle the
same level of accuracy cannot be guaranteed.
Another area of difficulty was in the fact that there was very little in terms of relevance in research
papers that were less than 2 years old. This may be indicative of the advancement of middleware
systems or the fact that other solutions are being used more and more at the present time.
Reflections This has been an interesting and satisfying project for me to carry out. As I worked at The Company
for over 15 months on my year out I have an in-depth working knowledge of their operation. It always
puzzled me while I was there as to why this very large organisation was operating a system of such
horrendous complexity when there were many other potential ways of working that I believe to be
much more efficient. I believe this has been proved within the body of this report and I would hope
that someone at The Company will read the findings of this report and consider the fact that there is
47
possibly a better solution for The Company that in the long run would save much time, effort and
money.
I would like to say also that my supervisors enthusiasm for this project has made it far less of a chore
than I ever imagined it would be and his help and advice has made it significantly more enjoyable
than it would have been without that support.
48
TPC-C BENCHM
ARK RESULT
S
These results are valid as of
date 11/16/2001 9:07:45 AM
TPC-C
Results - Revision
5.X
Company System Spec.
Revision tpmC $/tpmC
Sys. Cost
IBM IBM e(logo) xSeries 250 c/s 5 15533.72 4.67 72487
Dell PowerEdge 2500/1.13/1P 5 11320.02 4.7 53203
IBM IBM eServer xSeries 220 c/s 5 9112.91 4.76 43370
49
Compaq ProLiant ML530-X1000-1P 5 9347.24 4.77 44582
IBM IBM e(logo) xSeries 350 c/s 5 20422.01 5.39 110015
Compaq ProLiant ML570-700 3P 5 20207.2 5.64 113798
Compaq ProLiant ML570 6/900-4P 5 37100.52 6.36 235777
Dell PowerEdge 6400 5 20331.91 6.46 131275
Dell PowerEdge 6450 5 20320.7 6.62 134392
50
Dell PowerEdge 6450 5 30231.37 6.98 210862
Dell PowerEdge 6400 Client/Server w/4 PE1300 Front End 5 30231.37 7 211426
Dell PowerEdge 6450-3P 5 24925.43 7.32 182230
Dell PowerEdge 6400 5 24925.43 7.33 182457
IBM IBM e(logo) server xSerier 250 c/s 5 32377.17 7.58 245460
Compaq ProLiant DL580 6/900 5 39158.09 7.95 310945
51
IBM IBM e(logo) xSeries 350 c/s 5 34264.9 8.06 276075
Dell PowerEdge 8450/900 DC 5 69901.74 8.46 591071
Dell PowerEdge 8450 5 57014.93 8.7 495610
HP HP Netserver LH 6000 Client/Server 5 37596.34 8.87 333572
Fujitsu Siemens Primergy F200 5 22007.12 8.94 196805
Compaq ProLiant ML530-x1000-2P 5 17335.75 9.8 169758
HP HP NetServer LXr 8500 5 43046.55 10.11 435038
52
Fujitsu Siemens PRIMERGY H400 C/S with 3 PRIMERGY B210 5 37383.57 12.8 478649
NEC Express5800/180Rb-7 5 52671.3 12.96 682724
Compaq ProLiant DL760-900-128P 5 410769.8 13.02 5344576
Compaq ProLiant DL760-900-192P 5 567882.5 14.04 7972452
Dell PowerEdge 4400 5 16262.9 14.36 233532
Compaq ProLiant DL760-900-256P 5 709220.0 14.96 1060380
53
HP hp server rp8400 5 140239.9 16.31 2287403
HP HP 9000 Model L2000 Enterprise Server 5 22422.5 16.43 368367
Compaq Compaq AlphaServer ES40.Model 6/833 5 37274 16.83 627144
IBM IBM eServer xSeries 370 5 136766.6 16.93 2315801
HP HP 9000 Model L3000 Enterprise Server 5 34288.77 17.97 616165
IBM IBM e(logo) xSeries 370 c/s 5 121319.2 18.97 2301858
54
IBM IBM eServer xSeries 370 c/s 5 440879.9 19.35 8530671
HP HP 9000 N4000 Enterprise Server 5 60366.82 20.87 1259762
Unisys Unisys e-@ction Enterprise Server ES7000 5 165218.7 21.33 3524109
IBM IBM e(logo) xSeries 370 c/s 5 363129.7 21.8 7915144
IBM IBM e(logo) xSeries 370 c/s 5 688220.9 22.58 1554334
Unisys Unisys e-@ction Enterprise Server ES7000 5 141138.4 23.84 3363483
55
IBM IBM e(logo) xSeries 370 c/s 5 440879.9 25.03 1103302
IBM IBM eServer pSeries 660 Model 6M1 5 105025.0 25.33 2660058
Bull Bull Escala PL800R 5 105025.0 25.41 2668861
Sun Sun Enterprise 4500 5 67102.53 25.85 1734522
IBM IBM eServer pSeries 660 5 57346.93 28.47 1632624
Bull Bull Escala PL600R C/S 5 57346.93 28.57 1638835
Fujitsu PRIMEPOWER 2000 c/s w 66 Front-Ends 5 455818.2 28.58 1202552
56
IBM IBM eServer pSeries 680 Model 7017-S85 5 220807.2 34.18 7546837
Bull Bull Escala EPC2450 c/s 5 220807.2 34.67 7657157
Bull Bull Escala Epc 810 c/s 5 66750.27 37.57 2508189
IBM IBM RS/6000 Enterprise Server M80 c/s 5 66750.27 37.8 2523482
HP HP 9000 Superdome Enterprise Server 5 197024.1 43.25 8522104
Fujitsu/ICL PRIMEPOWER 2000 c/s w /32 Front Ends 5 222772.3 43.42 9671742
57
IBM IBM eServer iSeries 400 Model 840-2420 5 152346.2 44.52 6782752
Compaq Compaq AlphaServer GS320 5 230533 44.62 1028602
IBM IBM eServer iSeries 400 Model 840-2420-001 5 163775.8 51.58 8448137
Compaq Compaq AlphaServer GS320 Model 6/731 5 155179.2 52.88 8205964
WITHDR
AWN RESULT
S
TPC-C
Withdrawn Results
Company System Spec.
Revision tpmC $/tpmC
Sys. Cost
58
Compaq Compaq AlphaServer GS160 Model 6/731 5 71863.02 52.42 3766731
Each of 8 xSeries 220 Clients:933MHz Pentium IIIw/256KB L2 Cache128MBUltra160 SCSI Onboard
9.1GB (10000 rpm)
One DTC Server:700MHz/2MB Pentium III Xeon128MB ECC SDRAMServeRAID-4H Ultra160 SCSIAdapter9.1GB (10000 rpm) Giganet cLAN-1000 HostAdapter
Qty 2 4 1 1
4 4 1 6 1
Each of 4 Database Servers 900MHz Pentium III Xeonw/2MB L2 Cache1GB ECC SDRAM Mylex eXtremeRAID 2000ServeRAID-4H Ultra160SCSI Adapter9.1GB (15000 rpm)18.2GB (15000 rpm)9.1GB (10000 rpm)
6.952TB (6.91TB online)
3502-R14 DLT Tape LibraryGiganet cLAN-1000 HostAdapterGiganet cLAN-5000 Switch
Qty 8 32 6 1 140 40 2
1 1 1
1
System Component Processors Cache Memory Disk Controllers
Disk Drives
Total StorageOther Tape Drive Interconnect
1,000 Users per Segment
Giganet cLAN-5000Switch
8-PortSwitch
Clients 1-8xSeries 220
8-PortSwitch
Nodes 1-4
xSeries 37013 x EXP300
40 x 18.2GB drives140 x 9.1GB drives
DTCServerxSeries 350
112,000Microsoft COM+
Microsoft Visual C++6.0
MicrosoftWindows(R) 2000
Datacenter Server
Microsoft(R)
SQL Server2000
Database Servers = 32 Pentium III Xeon 900MHz/2MBDTC Server = 4 Pentium III Xeon 700MHz/2MB
Numberof UsersOther SoftwareOperating System
DatabaseManagerProcessors
Sept. 20, 2001$16.93 / tpmC136,766.67 tpmC$2,315,801
Availability DatePrice/PerformanceTPC-C ThroughputTotal System Cost
Report Date: April 24, 2001Original: April 20, 2001
TPC-C Rev. 5.0Upgrade from Rev. 3.5
IBM � xSeries 370with
Microsoft SQL Server 2000
Prices used in TPC benchmarks reflect the actual prices a customer would pay for a one-time purchase of the stated components. Individually negotiateddiscounts are not permitted. Special prices based on assumptions about past or future purchases are not permitted. All discounts reflect standard pricingpolicies for the listed components. For complete details, see the pricing sections of the TPC benchmark specification. If you find that stated prices are notavailable according to these terms, please inform the TPC at [email protected]. Thank you.
$ / tpmC: $16.93
tpmC Rating: 136,766.67
Three-Year Cost of Ownership: $2,315,801Notes: * The standard 3-year warranty on IBM hardware has been upgraded to 7x24, 4-hour response.** Five-year warranty. *** 10% or minimum 2 spares are added in place of on-site service (productshave a 5-year return-to-vendor warranty)
Pricing: 1 - IBM; 2 - Microsoft; 3 - Giganet; 4 - Mylex; 5 - Software House International
Audited by Brad Askins of InfoSizing, Inc.
$102,419$2,213,382 Grand Total
$0(211,764) DiscountLarge volume discount; prices will vary if purchased individually.$102,419$2,425,146Total
$0$100Subtotal01004255NX-DSS88-Port 10/100 Nway Fast Ethernet Switch (+2)
User Connectivity$0$6,453Subtotal
incl. above54915492Microsoft048-00317Microsoft Visual C++ Professional 6.0
incl. above5,90487382MicrosoftC11-00821Microsoft Windows 2000 Server with COM+
Client Software$6,704$33,856Subtotal
7201,38481731IBM6331N2NE54 15” (13.8” Viewable) Color Monitor*
03,504162191Intel8472Intel Pro/100+ Dual-Port Ethernet Adapter**
02,39282991IBM37L72049.1GB 10K Ultra160 SCSI Drive
05,840163651IBM33L3144256MB ECC SDRAM RDIMM
07,99289991IBM10K3819933MHz/256KB Pentium III Upgrade
5,98412,74481,5931IBM8645-41XxSeries 220 / 933MHz/256KB Pentium III*
Client Hardware$25,140$974,511Subtotal$25,140122,0952Microsoft3-Year Maintenance for Software
incl. below2,39912,3992MicrosoftC10-00475Microsoft Windows 2000 Advanced Server
0539,3123216,5412Microsoft11K7641Microsoft SQL Server 2000
0$442,800 1IBM22P4745Datacenter OS Preload Kit/Ship Group/Warr.
Server Software$70,575$1,410,226Subtotal
0126,2401607891IBM19K065618.2GB 15K Ultra160 SCSI Drive
0336,5605606011IBM19K06559.1GB 15K Ultra160 SCSI Drive
10,400165,308523,1791IBM35311RUNetfinity EXP300 Rack Storage Enclosure* Storage Hardware
incl. above94571353GiganetcLAN-A1011Giganet cLAN-A1011 10M Cable (incl. 10%)
incl. above18,75036,2503GiganetcLAN-5000Giganet cLAN-5000 8-Port Switch (incl. 10%)
45,0005,56577953GiganetcLAN-1000Giganet cLAN-1000 Host Adapter (incl. 10%)
021,1801IBMHardware installation and prep fees
019511951IBM94G6669Side Panel Kit
1,80010,35061,7251IBM9306900Netfinity Rack*
013,19643,2991IBM37L6861IBM Smart-UPS Model 5000RMB
1,45013,779113,7791IBM3502R143502-R14 DLT Tape Autoloader*
45086551731IBM6331N2NE54 15” (13.8” Viewable) Color Monitor*
03964991IBM06P360110/100 Ethernet Server Adapter with IPSec
010,9201041051IBM03K9311Ultra2 SCSI 4m Cable
050,544271,8724MylexE2000-4-32NBMylex eXtremeRAID 2000 Adapter (incl. 10%)
012,19552,4391IBM37L6889ServeRAID-4H Ultra160 SCSI Adapter
04,186142991IBM37L72049.1GB 10K Ultra160 SCSI Drive
010,87533,6251IBM00N7944700MHz/2MB L2 Cache Processor Upgrade
1,4957,16517,1651IBM8682-5RYxSeries 350 700MHz/2MB Pentium III Xeon*
0332,2881282,5961IBM33L30561GB SDRAM RDIMM Memory Kit
04,99641,2491IBM10K23358500 >4X Accelerator Filter
02,50046251IBM28L44548500R Memory Expansion Card
0184,772286,5991IBM19K4637900MHz/2MB L2 Cache Processor Upgrade
$9,980$76,4564$19,1141IBM8681-3RXxSeries 370 900MHz/2MB Pentium III Xeon*
Server Hardware
PricingBrand
3-Yr. Maint.*Ext. PriceQtyUnit PriceThird-PartyOrder NumberDescription
Report Date: April 24, 2001Original: April 20, 2001
TPC-C Rev. 5.0 Upgrade from Rev. 3.5
� xSeries 370 c/s with
Microsoft SQL Server 2000
30 minutesCheckpoint interval
1Number of checkpoints in measurement interval
37 minutes 52 secondsRamp-down time
9,527,120Number of transactions (all types) completed in measurement interval
30 minutesMeasurement interval
35 minutes 38 seconds Ramp-up time
Test Duration
2.06 / 100.502.01 10.062.00 / 0.00Order Status
2.05 / 50.502.01 / 5.072.00 / 0.00Stock Level
2.05 / 50.512.01 / 5.062.00 / 0.00Delivery
3.07 / 120.513.01 / 12.063.00 / 0.00Payment
18.06 / 120.5318.01 / 12.0518.00 / 0.00 New-Order
MaximumAverageMinimumKeying/Think Times(in seconds)
0.10.1Stock-Level
0.10.1Delivery
0.10.1Order-Status
0.10.1Payment
0.10.1New-Order
Menu Response TimeEmulation Delay (inseconds)
4.05370,721Order Status
4.05371,032Stock Level
4.05370,994Delivery
43.033,940,308Payment
44.814,103,000New-Order
PercentTotal OccurrencesTransaction Mix (in percent of total transactions)
3.470.370.86Menu
0.780.200.27Delivery (Deferred)
3.300.410.90Order Status
2.440.480.98Stock-Level
1.870.360.85Delivery (Interactive)
20.010.681.22Payment
19.160.631.12New-Order
MaximumAverage90%Response Times(in seconds)
136,766.67 tpmC.12 %
MQTh, Computed Maximum Qualified Throughput: % throughput difference, reported and reproducibility runs:
Numerical Quantities Summary