Cover image for IT architectures and middleware : strategies for building large, integrated systems
IT architectures and middleware : strategies for building large, integrated systems
Britton, Chris.
Personal Author:
Publication Information:
Boston, MA : Addison-Wesley, 2001.
Physical Description:
xxvii, 296 pages : illustrations ; 24 cm
Format :


Call Number
Material Type
Home Location
Central Library QA76.9.A73 B77 2001 Adult Non-Fiction Central Closed Stacks

On Order



This title will be released on 12/1/2000. You may join our all-subject mailing list to receive official notification of its publication.

Author Notes

Chris Britton is an independent consultant, specializing in IT architecture. He has worked in IT for the last twenty-seven years doing a variety of jobs--programming, technical support, system software design, program management, technical consultancy, and even marketing. More recently he has been spending his time developing an IT modeling tool.



All large organizations have complex, heterogeneous IT systems. All of them need to integrate their applications to support faster, more accurate business processes and to provide meaningful, consistent management information. All organizations are struggling to achieve this. One reason for this struggle is that they are caught in the crossfire of an IT vendor war. In one corner is Microsoft. The strength of Microsoft is that they have a consistent technical strategy based on COM+ and Windows 2000. In the other corner, ranged against Microsoft, is a group that includes IBM, SUN, Oracle, and BEA. This group is focusing their resources around Enterprise Java Beans and CORBA. This is a battle over who will rule over middleware technology; a battle over how to implement distributed systems. Given the importance of the subject matter, it is a battle for the hearts and souls of IT for the next decade. Why? Because all large organizations have complex, heterogeneous IT systems that need to be brought together. But vendor wars are only part of the problem. Scratch the surface of a large IT department and you will see many camps--in particular, workstation/departmental server "decentralizers" in one camp, and mainframe "centralizers" in another. Look from another angle and you will see two kinds of people, "techies" and "modelers." A techy will start a project by deciding what platform and software to use and will eventually get around to the boring bit, which is writing application code. A modeler will design the application with a modeling tool, generate a few programs and a database, and eventually will confront the (to him or her) trivial question of what platform it will run on. Modeling to a techy seems abstract and disconnected from reality. Technical issues to a modeler are tedious, and surely, soon we will be able to generate the application from the model at the press of a button, won't we? One of the keys to developing large distributed systems is to bring these people together. Computer professionals are in general comfortable with developing applications on a single platform to a well-defined set of requirements. The reason is that the technology is well understood; the modelers know that what they design can be implemented and the techies know they can make it work. Large distributed systems are not like that. A system designed without consideration for the distributed implementation will flat out not work. Even worse, you will only discover that it doesn't work when you start scaling it up to production capacity. To add to our woes, we are now considering integrating multiple systems, each of which was a challenge to develop in the first place, and each of which is changing at a different speed, driven ever faster by the business. The notion of a "well-defined set of requirements" is not realistic; requirements will always be changing. It is my contention that modelers need to know something about technology, and techies need to know something about modeling. Also, vendors, commentators, consultants, academics, and marketers need to know that their "solutions" lack either a modeling or a technical dimension. This book is about IT architecture. IT architecture provides a framework for discussing implementation design, and it is in these discussions where techies and modelers should meet. Anyone with IT architect as part of their roles and responsibilities should know everything in this book. (Note I said "know" not "agree with.") They might like to read this book to see whether my approach to IT architecture is the same as theirs. While IT architects are an important audience for this book, I have tried to write a book for IT management professionals as well. To be honest, I have assumed that the IT management professionals in my readership come from an IT background and not a business background; therefore, this book is not an introduction to IT. So why do IT management professionals need a book about IT architecture? Because it is here that so many of their concerns come together--application flexibility, information quality, resiliency, scalability and so on. One of my goals is to give IT management professionals the knowledge needed to challenge IT architects. This book attempts to give an overview of the whole subject of building and running large distributed systems. It is a deliberate attempt to step above the detail and the infighting to examine what is important, what isn't important, and what we need to do differently now from ten years ago. My contention is that the difference between then and now is much more than simply that there are some new tools to play with. Building integrated systems is substantially different from building standalone applications, and it impacts everything we do in IT. A major theme of this book is "enterprise computing." In the list of terms abused by the industry, "enterprise computing" has to be somewhere near the top. This book takes the view that enterprise computing is about being able to build systems that support the whole enterprise, which in large organizations means many thousands of users. It is obvious that systems supporting thousands of users must have resiliency, scalability, security, and manageability as major concerns. The enterprise computing mentality is about not being prepared to compromise on these objectives. An old mainframe application written in Cobol that gives you resiliency, scalability, security, and manageability is far superior to any implementation that does not. This is not to say that you cannot build enterprise capable applications with modern tools like COM+ and Enterprise Java Beans. But to succeed we must understand the principles of building large, resilient systems. The principles that served us well for mainframe applications do not all apply for distributed systems and vice versa. So much has changed recently, especially in connection with the Internet, that I feel it is time the principles were reassessed and restated. Unfortunately I have already discovered that many people see a discussion of principles as too abstract, and many people in IT, to my surprise, hate any sniff of an abstract concept. In a sense this is a value judgment; my important principle is your unimportant abstract concept. I have tried to avoid too dry a presentation style by giving many examples. In the earlier chapters the examples are very short--snippets of examples if you will. In later chapters, when I discuss modeling, the examples become more substantial. Many organizations today are trying to avoid all these issues by buying third-party application packages. This is partially successful. When you buy a package, you buy an IT architecture, albeit only in the context of the package functionality. If you buy many packages, it is likely that you must lash them together somehow and for this you need an IT architect. If the packages are from different vendors, integration is a challenge. In this book, I give you the principles that should help in this task, but I have chosen not to address the challenge directly. The problem is there are so many packages, and I don't know them well enough to give a good account on package integration. The subject needs a book by itself. This book is not for everyone. If you have no ambitions beyond programming, you will find this book short on product detail. It does not tell you anything about installation, there are no proper coding examples, there is no survey of products, and little in the way of product comparisons. This book will probably offend many IT vendors by mentioning their products either not at all or only in passing. I have no apology for any of these omissions. There are many books on coding, and product details change so fast the best place for comparisons is on the Internet. This book does not teach modeling. There are many books for that as well. But I hope application designers will read this book because the discussion on the principles for building enterprise systems is vital for them also. Finally, this book is not an academic book. There is little mathematics except for back-of-the-envelope style calculations to illustrate a few points. The aim is for a practical, wide-ranging discussion for IT professionals to help them understand what is going on so they can pick out the real issues from the imaginary issues and start building complex distributed systems with confidence. An outline of the book is covered in the next section--How to read this book. How to read this book You can read this book straight through or as a work of reference. The purpose of this section is to explain the structure of the book, particularly for those who want to use the book for reference. If you are intending to use it for reference, and don't intend to read it through first, I encourage you to read at least chapters 1, 6, 10, 11, and 15. This book is about four topics: Middleware technology alternatives Distributed systems implementation design Guidelines on the practice of IT architecture The common thread that holds these topics together is a focus on IT architecture and implementation design. The structure of the book in greater detail is as follows. Introduction Chapter 1: The Nature of the Problem. This chapter is an introduction to the rest of the book. It takes an example and points out the main concerns of IT architecture. Middleware technology alternatives Chapter 2: A Short History of Middleware Technology--From the Stone Age to Message Queuing. This and the following two chapters are a historical survey of middleware technology. The topics are Remote procedures calls. Remote database access (ODBC, etc.). Distributed transaction processing. Message queuing. Comparison of message queuing with distributed transaction processing. Chapter 3: A Short History of Middleware Technology--Object Middleware. The topics are A short introduction to object-oriented concepts. DCOM. CORBA. Using object interfaces over middleware. Chapter 4: A Short History of Middleware Technology--Components and the Web. The topics are The difference, from an application implementation design angle, between Webbrowsers and workstations. COM+. Enterprise Java Beans. The issue of session state. IT architecture guidelines / middleware Chapter 5: Middleware Classification and Middleware Architectures. The topics are A technological classification of middleware. This section tries to answer the questions--is there additional middleware that has been overlooked, and how does middleware fit with other software? Vendor architectures like Microsoft DNA and Sun's J2EE. Chapter 6: What Is Middleware For? The topics are A description of the functional requirements of middleware technology. An introduction to a high-level generic architecture (this is further broken down into components in chapter 10). Distributed systems technology principles Chapter 7: Resiliency. This chapter explains the principles of resiliency in distributed systems. Chapter 8: Performance and Scalability. This chapter explains the principles of performance and scalability in distributed systems. Chapter 9: Security and Systems Management. This chapter explains the principles of security and systems management in distributed systems. IT architecture guidelines / distributed systems implementation design Chapter 10: Implementation Design and Components. The topics are An explanation of the design context for IT architecture. A look at implementation design in more detail, in particular how to break the application into components. Distributed systems implementation design Chapter 11: Implementing Business Processes. The topics are A description of business processes. The relationship between business processes and data. The relationship between business processes and IT systems. Chapter 12: Information Access and Information Accuracy. The topics are Information access requirements. Shared data or controlled duplication in new applications. How to change existing applications to achieve data consistency. Chapter 13: Change--Integration. This and the next chapter are about changing existing systems. The topics are Creating a new presentation layer for existing applications. Integration of transaction servers. Chapter 14: Change--Flexibility. The topics are Understanding and changing large, monolithic applications. Reducing reliance on batch. Chapter 15: Building an IT architecture. This chapter summarizes the contents of the book and discusses how projects change when an IT architecture approach is followed. IT architecture guidelines / conclusion Throughout the book you will see text put into boxes with a heading in bold. You will also see references like this (see IT Architecture box). This reference indicates that the box on this subject has more information about the topic just being discussed. The text in the box contains a subject that is either more technical than the body of the text or that is on an esoteric subject I could not resist writing about. 0201709074P04062001 Excerpted from IT Architectures and Middleware: Strategies for Building Large, Integrated Systems by Chris Britton All rights reserved by the original copyright owners. Excerpts are provided for display purposes only and may not be reproduced, reprinted or distributed without the written permission of the publisher.

Table of Contents

List of Figuresp. xv
List of Boxesp. xix
Prefacep. xxi
Acknowledgmentsp. xxvii
Chapter 1 The Nature of the Problemp. 1
1.1 Example: Moving to e-businessp. 1
1.2 What is IT architecture?p. 5
1.3 Why is it different from what we did before?p. 7
1.4 The IT architecture approachp. 9
1.5 Alternativesp. 11
1.5.1 Why not surround?p. 11
1.5.2 Packagesp. 13
1.6 How do we get there?p. 13
1.6.1 Rewritep. 13
1.6.2 Evolutionp. 15
1.6.3 Bringing the techies and modelers togetherp. 17
1.7 Conclusionsp. 18
Chapter 2 A Short History of Middleware Technology--From the Stone Age to Message Queuingp. 19
2.1 Early daysp. 19
2.2 Preliminariesp. 23
2.3 Remote procedure calls (RPC)p. 25
2.4 Remote database accessp. 27
2.5 Distributed transaction processingp. 30
2.6 Message queuingp. 34
2.7 Message queuing vs. distributed transaction processingp. 36
2.8 What happened to all this technology?p. 39
Chapter 3 A Short History of Middleware Technology--Object Middlewarep. 41
3.1 Object-oriented conceptsp. 42
3.2 Object middleware conceptsp. 49
3.3 Object middleware technologies--DCOM and CORBAp. 52
3.4 Using object interfacesp. 56
3.5 Conclusionsp. 58
Chapter 4 A Short History of Middleware Technology--Components and the Webp. 61
4.1 Internet applicationsp. 62
4.2 Transactional component middlewarep. 66
4.2.1 COM+p. 69
4.2.2 EJBp. 70
4.3 The issues of statep. 71
4.4 Conclusionsp. 73
Chapter 5 Middleware Classification and Middleware Architecturesp. 75
5.1 Middleware elementsp. 75
5.1.1 Networking and interoperabilityp. 76
5.1.2 The programmatic interfacep. 77
5.1.3 Server controlp. 77
5.1.4 System administration infrastructurep. 78
5.2 A technical classification of middleware?p. 78
5.2.1 What is communicating?p. 78
5.2.2 How they communicatep. 80
5.2.3 What is the interface?p. 83
5.2.4 Classifying middleware from technological principlesp. 84
5.3 Vendor architecturesp. 84
5.3.1 Positioningp. 87
5.3.2 Strawman for user target architecturep. 88
5.3.3 Marketingp. 88
5.4 Implicit architecturesp. 89
5.5 Conclusionsp. 90
Chapter 6 What Is Middleware For?p. 91
6.1 Support for business processesp. 92
6.1.1 Transactional, real-timep. 94
6.1.2 Transactional, deferrablep. 95
6.2 Information retrievalp. 96
6.3 Collaborationp. 97
6.4 The presentation layerp. 98
6.5 The transaction server layerp. 100
6.6 The data layerp. 101
6.7 A generic functional architecturep. 103
6.8 Mediatorsp. 105
6.9 Conclusionsp. 106
Chapter 7 Resiliencyp. 107
7.1 Using backup serversp. 108
7.1.1 Detecting failurep. 108
7.1.2 Clean-up work in progressp. 110
7.1.3 Activating the applicationp. 110
7.1.4 Reprocessing "lost" messagesp. 113
7.2 Dual activep. 114
7.3 Applying resiliency techniques in practicep. 118
7.4 System software failurep. 119
7.5 Planned downtimep. 120
7.6 Application software failurep. 121
7.7 Developing a resiliency strategyp. 123
7.8 Conclusionsp. 125
Chapter 8 Performance and Scalabilityp. 127
8.1 The un-slippery slopep. 128
8.2 Transaction processingp. 131
8.2.1 Object interfacesp. 133
8.2.2 Transactional component containersp. 135
8.2.3 Two-phase commitp. 135
8.2.4 Message queuingp. 136
8.2.5 Using remote database access for real-time transactionsp. 137
8.2.6 Conclusions on real timep. 139
8.3 Batchp. 139
8.4 Is distribution an alternative?p. 140
8.5 Load balancingp. 141
8.6 Business intelligence systemsp. 143
8.6.1 Ad-hoc database queriesp. 143
8.6.2 Data replicationp. 144
8.7 Backups and recoveryp. 144
8.8 Design for scalability and performancep. 146
8.9 Conclusionsp. 147
Chapter 9 Security and Systems Managementp. 151
9.1 Systems management technologyp. 151
9.2 Security technologyp. 156
9.3 Building application securityp. 161
9.3.1 Circumventing securityp. 163
9.3.2 Handling internal security violationsp. 165
9.3.3 Existing applicationsp. 165
9.4 Application support for systems management and securityp. 166
9.5 Conclusionsp. 168
Chapter 10 Implementation Design and Componentsp. 171
10.1 Some general comments on designp. 171
10.2 Implementation designp. 178
10.2.1 The presentation layerp. 178
10.2.2 Mapping business objects to implementation objectsp. 179
10.2.3 Grouping objects into componentsp. 181
10.2.4 Making reuse workp. 182
10.2.5 Completing the implementation designp. 187
10.3 Conclusionsp. 188
Chapter 11 Implementing Business Processesp. 191
11.1 What is a process?p. 193
11.2 Business processesp. 196
11.3 The alternative view--functional analysisp. 197
11.4 Information and processesp. 199
11.5 Processes and computer applicationsp. 202
11.5.1 Business rulesp. 202
11.5.2 Real time vs. deferrablep. 203
11.5.3 Data distributionp. 203
11.5.4 Long transactionsp. 204
11.5.5 Generic business processesp. 206
11.5.6 Batchp. 206
11.6 Business process flexibilityp. 206
11.7 Conclusionsp. 207
Chapter 12 Information Access and Information Accuracyp. 211
12.1 Information accessp. 211
12.1.1 Basic process informationp. 214
12.1.2 Process managementp. 215
12.1.3 Process improvementp. 216
12.1.4 Customer viewp. 216
12.1.5 Marketing and strategic business analysisp. 216
12.1.6 Summary of requirements for information accessp. 217
12.2 Information accuracyp. 218
12.3 Shared data or controlled duplicationp. 220
12.3.1 Shared datap. 220
12.3.2 Controlled duplicationp. 222
12.3.3 Hybrid strategyp. 224
12.4 Creating consistency in existing databasesp. 224
12.4.1 The technical problemp. 226
12.4.2 The data migration problemp. 227
12.4.3 The business process problemp. 227
12.5 The information controllerp. 228
12.6 Conclusionsp. 229
Chapter 13 Change--Integrationp. 231
13.1 Creating a presentation layerp. 234
13.1.1 Screen-scraping taskp. 235
13.1.2. Interface size mismatchp. 235
13.1.3 Turning existing applications into transaction serversp. 236
13.1.4 Wrappingp. 238
13.1.5 Building a middle tierp. 239
13.2 Business processing change with new interfacesp. 240
13.3 Changing the middleware between transaction serversp. 243
13.4 Runtime integration productsp. 244
13.5 Extensible markup language (XML)p. 246
13.6 Conclusionsp. 247
Chapter 14 Change--Flexibilityp. 249
14.1 Understanding large applicationsp. 251
14.1.1 Airline examplep. 252
14.1.2 Bank examplep. 256
14.2 Batchp. 261
14.3 Conclusionsp. 265
Chapter 15 Building an IT Architecturep. 267
15.1 Integrated applications architecturep. 268
15.2 Business process designp. 270
15.3 Managing informationp. 273
15.4 The organizational and project management contextp. 274
15.4.1 Understanding existing systemsp. 276
15.4.2 Business process change designp. 277
15.4.3 Application functional designp. 277
15.4.4 Implementation designp. 277
15.4.5 Implementation--codingp. 278
15.4.6 Implementation--testingp. 279
15.4.7 Deploymentp. 280
15.4.8 Project managementp. 280
15.5 Breaking down the barriersp. 282
15.6 The futurep. 283
Indexp. 285

Google Preview