BN.com Gift Guide

IT Architectures and Middleware: Strategies for Building Large, Integrated Systems / Edition 1

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 95%)
Other sellers (Paperback)
  • All (23) from $1.99   
  • New (2) from $13.00   
  • Used (21) from $1.99   

Overview

This book focuses on the essential principles and priorities of system design and emphasizes the new requirements emerging from the rise of e-commerce and distributed, integrated systems. It offers a concise overview of middleware technology alternatives and distributed systems. Numerous increasingly complex examples are incorporated throughout, and the book concludes with some short case studies.
Read More Show Less

Editorial Reviews

Booknews
Focuses on the principles and priorities of enterprise systems design, emphasizing the new requirements brought by e-commerce and distributed, integrated systems. Britton, who works for Unisys, discusses middleware technology alternatives, resiliency, performance and scalability, security, systems management, information access and accuracy, and creation of a new presentation layer for existing applications. Annotation c. Book News, Inc., Portland, OR (booknews.com)
From The Critics
IT Architecture And Middleware: Strategies For Building Large, Integrated Systems, presents the essential principles and priorities of system design, emphasizing the new requirements brought about by the rise of e-commerce and distributed, integrated systems. IT professional Christ Britton offers a concise overview of middleware technology alternatives and distributed systems as he covers such topics as information access requirements and data consistency, creation of a new presentation layer for existing applications, application integration, and component architectures. Carl Britton's IT Architecture And Middleware is a highly recommended addition to the growing body of information technology literature and IT architecture reference collections.
Read More Show Less

Product Details

  • ISBN-13: 9780201709070
  • Publisher: Addison-Wesley
  • Publication date: 12/6/2000
  • Series: Unisys Series
  • Edition description: Older Edition
  • Edition number: 1
  • Pages: 336
  • Product dimensions: 6.10 (w) x 8.70 (h) x 0.80 (d)

Meet the Author

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.

Peter Bye has had a long career in IT as a programmer, analyst, and project manager, focusing on telecommunications, transaction processing, and distributed systems. Currently a system architect for Unisys Corporation, his experience includes work in software development centers and field projects around the world. Peter is a contributor to international standards in systems management, the author of a number of papers on middleware and other IT topics, and a frequent speaker at conferences and other events.

Read More Show Less

Read an Excerpt

PREFACE:

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

Read More Show Less

Table of Contents

1 The problem 1
2 The emergence of standard middleware 17
3 Objects, components, and the Web 39
4 Web services 59
5 A technical summary of middleware 77
6 Using middleware to build distributed applications 99
7 Resiliency 123
8 Performance and scalability 143
9 Systems management 169
10 Security 187
11 Application design and IT architecture 205
12 Implementing business processes 223
13 Integration design 241
14 Information access and information accuracy 257
15 Changing and integrating applications 277
16 Building an IT architecture 297
Read More Show Less

Preface

PREFACE:

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

Read More Show Less

Introduction

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 .NET and Windows. In the other corner, ranged against Microsoft, is a group that includes IBM, SUN, Oracle and BEA. This group is focusing their resources around the Java environment. 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 which need to be brought together.

But vendor wars are only part of the problem. Scratch the surface of a large IT department and you see many camps, in particular, workstation/departmental server "decentralizers" in one camp, 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 round 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, what platform will it run on. Modeling to a techyseems 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, wont 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 our contention that modelers need to know something about technology, techies need to know something about modeling, and, while we are about it, vendors, commentators, consultants, academics, marketers need to know why their "solutions" aren't quite the panaceas they claim.

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 in their roles and responsibilities should know everything in this book. (Note we said "know" not "agree with".) They might like to read this book to check up whether our approach to IT Architecture is the same as theirs.

While IT Architects are an important audience for this book, we have tried to write a book for IT management. We have assumed that the IT management in our readership comes from an IT background not a business background; this book is not an introduction to IT. So why do IT management need a book about IT Architecture? It is because it is here that so many of their concerns come together—application flexibility, information quality, resiliency, scalability and so on. One of our aims is to give IT management the knowledge to call the IT Architects to account.

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 in-fighting to examine what it important, what isn't important, and what we need to do differently from ten years ago. Our 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 thousand of users. It's 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 application with modern tools, like Web services. But to succeed you must understand the principles of building large, resilient systems. The principles that served us well for standalone applications do not all apply for distributed systems and vice versa. Many people in IT find discussions of principles as too abstract, so we have tried to avoid too dry a presentation style by giving many examples.

Many organizations today are trying to avoid all these issues by buying 3rd 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, we give you the principles that should help in this task, but have chosen not to address the challenge directly. There are so many packages that to do the subject justice would need a book in 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 in passing. We have no apologies 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 application design. There are many books for this as well. But we 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 the 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.

What has changed in the Second Edition



Changes leading to the second edition fall into three categories.

First authorship has now become a team—Peter Bye has joined Chris. Peter brings a long standing expertise in integration, networking and system management, and in all matters concerned with designing an IT architecture. While Peter has concentrated on adding to the technical content in the first part of the book, all parts are mulled over by both of us and authorship is shared. Compare the new text with the old and you will notice small changes scattered everywhere. As befits his additional expertise, where there was one chapter on system management and security, there are now two.

Second, the book has been updated to take into account new technology, in particular web services, and consequently new ways of thinking about IT architecture, in particular loosely-coupled architectures.

I (Chris) was in the final stages of writing the first edition of the book when Microsoft announced .NET and had no time to digest the merits of the announcement and incorporate it into the text. When Web services became more center stage it became clear that a fundamental driver was a desire for a more loosely-coupled architecture, or more specifically a loosely-coupled integration of tightly-coupled archipelagos of system. The integrated applications architecture described in the first edition of the book was a quintessentially tightly-coupled approach. Many people were saying that they could never reach enough agreement across an organization to impose a tightly-coupled architecture. There is some truth to these complaints, though in my defense loosely-coupled integration is impossible without some common standards and web services are providing them.

However "loosely-coupled" is a fuzzy term, easily bandied about by sales people and consultants, and you can't just apply web services pixie dust to create loosely-coupled integrated applications. One of our aims with this new edition is to identify when loosely-coupled works and when it doesn't, and to lay out the advantages and disadvantages of the different approaches to architecture. In consequence our approach to IT architecture is more flexible and we present a range of architectural options such as middleware bus architectures, hub and spoke architectures and web services architectures. The common theme throughout is the notion of services oriented architectures.

In concrete terms describing web services and other new technology has led to one new chapter and substantial changes to three others.

The third major area of change in this book is in the chapters on design. As in the technology chapters this is partly a response to changes in the industry. In particular we have felt the need to discuss agile approaches to development and how they can cooperate with an architectural approach. But the wider reason for change is that the authors' understanding has developed in the intervening years. In particular we have been able to describe a lightweight approach to integration design and to provide a better view on how the IT architecture supports business processes. These changes have led to one new chapter and substantial changes to two others.

We have also tidied up some of the material on changing existing system and in the process eliminated one chapter. Also two of the earlier history of middleware chapters have been merged as some of the technology has sunk in importance.

With all these changes to the body of the book the first and last chapters have needed a rewrite.

In spite of all the changes in the IT industry, it has been gratifying to observe how much of the book has remained useful. There are a large number of changes in this edition including three new chapters, but they, in the main, provide new content or (we hope) improve the text's clarity. We have retained the original structure. The first few chapters are about technology. The middle chapters are about using the technology to meet performance, resilience, security and system management goals, and the last few chapters are on design.

Finally, we have also providing an appendix about further reading which consist mainly of a pointer to a web site which we plan to keep updated with additional information.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)