replacing tuxedo

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], 34. 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)



100 Mb

Head Office LAN


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.




IBM IBM e(logo) xSeries 360 c/s 23027.66 4.41 101450 Microsoft SQL Server 2000 Standard Edt.


IBM IBM e(logo) xSeries 250 c/s 15533.72 4.67 72487 Microsoft SQL Server 2000 Standard Edt.




IBM IBM eServer xSeries 220 c/s

9112.91 4.76 43370 Microsoft SQL Server 2000 Standard Edt.


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



Microsoft COM+ 204 9/19/2001 10/15/2001



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



Microsoft COM+ 136 04/10/2001 5/31/2001



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


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


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


Dell PowerEdge 4400 5 16262.9 14.36 233532


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


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



Unisys Unisys e-@ction Enterprise Server ES7000 5 141138.4 23.84 3363483

55


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

replacing tuxedo

Documents