Home > Store

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

Register your product to gain access to bonus material or receive a coupon.

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

Book

  • Sorry, this book is no longer in print.
Not for Sale

Description

  • Copyright 2001
  • Dimensions: 6-1/4" x 9-1/4"
  • Edition: 1st
  • Book
  • ISBN-10: 0-201-70907-4
  • ISBN-13: 978-0-201-70907-0

The challenges of designing, building, and maintaining large-scale, distributed enterprise systems are truly daunting. Written for all IT professionals, IT Architectures and Middleware will help you rise above the obscuring conflicts of new business objectives, new technologies, and vendor wars so that you can think clearly and productively about the challenges you face.

IT Architectures and Middleware focuses on the essential principles and priorities of system design and emphasizes the new requirements brought to the fore by 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 guidelines on the practice of IT architecture.

Specific topics covered include:

  • Middleware technology, covering Distributed Transaction Processing, Message Queuing, CORBA, COM+ and EJB
  • Key principles of distributed systems: resiliency, performance and scalability, security, and systems management
  • Information access requirements and data consistency
  • Creation of a new presentation layer for existing applications
  • Application integration
  • Component architectures

Once you get your mind around the concepts, principles, and alternatives discussed in IT Architectures and Middleware, you can proceed with greater confidence to design complex enterprise systems.



0201709074B04062001

Sample Content

Downloadable Sample Chapter

Click below for Sample Chapter related to this title:
brit01.pdf

Table of Contents



List of Figures.


List of Boxes.


Preface.


Acknowledgments.


1. The Nature of the Problem.

Example: Moving to e-business.

What is IT architecture?

Why is it different from what we did before?

The IT architecture approach.

Alternatives.

Why not surround?

Packages.

How do we get there?

Rewrite.

Evolution.

Bringing the techies and modelers together.

Conclusions.



2. A Short History of Middleware Technology-- From the Stone Age to Message Queuing.

Early days.

Preliminaries.

Remote procedure calls (RPC).

Remote database access.

Distributed transaction processing.

Message queuing.

Message queuing vs. distributed transaction processing.

What happened to all this technology?



3. A Short History of Middleware Technology-- Object Middleware.

Object-oriented concepts.

Object middleware concepts.

Object middleware technologies-- DCOM and CORBA.

Using object interfaces.

Conclusions.



4. A Short History of Middleware Technology-- Components and the Web.

Internet applications.

Transactional component middleware.

COM1.

EJB.

The issues of state.

Conclusions.



5. Middleware Classification and Middleware Architectures.

Middleware elements.

Networking and interoperability.

The programmatic interface.

Server control.

System administration infrastructure.

A technical classification of middleware?

What is communicating?

How they communicate.

What is the interface?

Classifying middleware from technological principles.

Vendor architectures.

Positioning.

Strawman for user target architecture.

Marketing.

Implicit architectures.

Conclusions.



6. What Is Middleware For?

Support for business processes.

Transactional, real-time.

Transactional, deferrable.

Information retrieval.

Collaboration.

The presentation layer.

The transaction server layer.

The data layer.

A generic functional architecture.

Mediators.

Conclusions.



7. Resiliency.

Using backup servers.

Detecting failure.

Clean-up work in progress.

Activating the application.

Reprocessing "lost" messages.

Dual active.

Applying resiliency techniques in practice.

System software failures.

Planned downtime.

Application software failure.

Developing a resiliency strategy.

Conclusions.



8. Performance and Scalability.

The un-slippery slope.

Transaction processing.

Object interfaces.

Transactional component containers.

Two-phase commit.

Message queuing.

Using remote database access for real-time transactions.

Conclusions on real time.

Batch.

Is distribution an alternative?

Load balancing.

Business intelligence systems.

Ad-hoc database queries.

Data replication.

Backups and recovery.

Design for scalability and performance.

Conclusions.



9. Security and Systems Management.

Systems management technology.

Security technology.

Building application security.

Circumventing security.

Handling internal security violations.

Existing applications.

Application support for systems management and security.

Conclusions.



10. Implementation Design and Components.

Some general comments on design.

Implementation design.

The presentation layer.

Mapping business objects to implementation objects.

Grouping objects into components.

Making reuse work.

Completing the implementation design.

Conclusions.



11. Implementing Business Processes.

What is a process?

Business processes.

The alternative view--functional analysis.

Information and processes.

Processes and computer applications.

Business rules.

Real time vs. deferrable.

Data distribution.

Long transactions.

Generic business processes.

Batch.

Business process flexibility.

Conclusions.



12. Information Access and Information Accuracy.

Information access.

Basic process information.

Process management.

Process improvement.

Customer view.

Marketing and strategic business analysis.

Summary of requirements for information access.

Information accuracy.

Shared data or controlled duplication.

Shared data.

Controlled duplication.

Hybrid strategy.

Creating consistency in existing databases.

The technical problem.

The data migration problem.

The business process problem.

The information controller.

Conclusions.



13. Change-Integration.

Creating a presentation layer.

Screen-scraping task.

Interface size mismatch.

Turning existing applications into transaction servers.

Wrapping.

Building a middle tier.

Business processing change with new interfaces.

Changing the middleware between transaction servers.

Runtime integration products.

Extensible markup language (XML).

Conclusions.



14. Change-Flexibility.

Understanding large applications.

Airline example.

Bank example.

Batch.

Conclusions.



15. Building an IT Architecture.

Integrated applications architecture.

Business process design.

Managing information.

The organizational and project management context.

Understanding existing systems.

Business process change design.

Application functional design.

Implementation design.

Implementation-coding.

Implementation-testing.

Deployment.

Project management.

Breaking down the barriers.

The future.



Index. 0201709074T05142003

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

Updates

Submit Errata

More Information

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020