Enterprise application integration / David S. Linthicum.

By: Linthicum, David S, 1962-.

Material type: materialTypeLabel

BookSeries: Addison-Wesley information technology series.Publisher: Reading, Mass. : Addison-Wesley, c2000Description: xvii, 377 p. : ill. ; 23 cm.ISBN: 0201615835 .Subject(s): Application software -- Development

| Business enterprise -- Data processingDDC classification: 005.1

Contents:

Defining EAI -- Data-level EAI -- Application Interface-Level EAI -- Method-Level EAI -- User Interface-Level EAI -- The EAI Process-Methodology or Madness? -- An introduction to EAI and Middleware -- Implementing and integrating packaged applications-The general idea -- Integrating SAP R/3 -- Integrating peoplesoft -- e-Business: Inter-Enterprise application integration -- XML and EAI -- Message Brokers-The Preferred EAI Engine -- Process Automation and EAI -- EAI Moving Forward.

Holdings
Item type	Current library	Call number	Copy number	Status	Date due	Barcode	Item holds
General Lending	MTU Bishopstown Library Lending	005.1 (Browse shelf(Opens below))	1	Available		00086330

Total holds: 0

Enhanced descriptions from Syndetics:

Enterprise Application Integration (EAI) offers a solution to this increasingly urgent business need. It encompasses technologies that enable business processes and data to speak to one another across applications, integrating many individual systems into a seamless whole. Enterprise Application Integration provides a comprehensive examination of EAI. You will find an overview of EAI goals and approaches, a review of the technologies that support it, and a roadmap to implementing an EAI solution. You will also find an in-depth explanation of the four major types of EAI: data-level, application interface-level, method-level, and user interface-level. The book describes in detail the middleware models and technologies that support these different approaches, including: *Application servers, including the use of Enterprise JavaBeans (EJB) and ActiveX *Message-oriented middleware (MOM) and remote procedure calls (RPCs) *Distributed objects, looking at CORBA and COM *Database-oriented middleware and standards, including ODBC, JDBC, and OLE DB *Java middleware standards *Message brokers *New process automation and workflow technology This practical guide to implementing an EAI solution l

Bibliography: (pages 361-366) and index.

Table of contents provided by Syndetics

Acknowledgments (p. xvii)
Chapter 1 Defining EAI (p. 1)
What Is EAI? (p. 3)
Applying Technology (p. 4)
How Did Things Get This Bad? (p. 6)
Chaos Today, Order Tomorrow (p. 8)
Evolution of Stovepipes (p. 11)
Traditional Systems (p. 12)
Microcomputer Systems (p. 13)
Distributed Systems (p. 13)
Packaged Applications (p. 13)
Making the Business Case for EAI (p. 14)
The Virtual System (p. 15)
e-Business (p. 17)
Types of EAI (p. 18)
Middleware and EAI (p. 20)
Chapter 2 Data-Level EAI (p. 23)
Going for the Data (p. 24)
Data-Level EAI by Example (p. 27)
Database-to-Database EAI (p. 28)
Federated Database EAI (p. 29)
Consider the Data Source (p. 30)
Relational Data (p. 30)
Object-Oriented (p. 33)
Multidimensional (p. 33)
Other Data Storage Models (p. 35)
Working with Data-Level EAI (p. 36)
Chapter 3 Application Interface-Level EAI (p. 37)
Application Interfaces (p. 38)
What's an API? (p. 39)
Interface by Example (p. 40)
Approaching Application Interfaces (p. 42)
The Interface Tradeoff (p. 42)
Packaged Applications (p. 43)
Packaged Application Technology Architecture (p. 44)
Packaged Application APIs (p. 47)
Other Interfaces (p. 53)
Custom Applications (p. 57)
Rolling Your Own API (p. 57)
Application Wrapping (p. 57)
Using Application Interfaces (p. 60)
Chapter 4 Method-Level EAI (p. 61)
Method-Level Example (p. 63)
What's a Process? (p. 64)
Scenarios (p. 64)
Rules (p. 64)
Logic (p. 65)
Data (p. 66)
Objects (p. 66)
Method Warehousing (p. 66)
Leveraging Frameworks for EAI (p. 67)
The Value of Frameworks (p. 69)
Framework Functionality (p. 70)
Framework Types (p. 72)
Framework Categories (p. 75)
Enabling Technology (p. 75)
Application or Transaction Servers (p. 75)
Message Brokerss (p. 76)
Distributed Objects (p. 76)
Sharing Methods to Bind Your Enterprise (p. 77)
Chapter 5 User Interface-Level EAI (p. 79)
Leveraging User Interface-Level EAI (p. 80)
Going to the User Interface (p. 80)
Understanding the Application (p. 82)
Creating the Screen Catalog (p. 83)
Mapping Screens (p. 84)
Approaches (p. 85)
Enabling Technology (p. 87)
Chapter 6 The EAI Process-Methodology or Madness? (p. 91)
Applying a Procedure/Methodology (p. 92)
Step 1 Understanding the Enterprise and Problem Domain (p. 93)
Step 2 Making Sense of the Data (p. 93)
Identifying the Data (p. 94)
Step 3 Making Sense of the Processes (p. 104)
Process Integration (p. 104)
The Common Business Model (p. 106)
Leveraging Patterns for Method-Level EAI (p. 108)
Step 4 Identifying Application Interfaces (p. 112)
Application Interface Directory (p. 113)
Step 5 Identifying the Business Events (p. 114)
Step 6 Identifying the Schema and Content Transformation Scenarios (p. 114)
Step 7 Mapping Information Movement (p. 115)
Step 8 Applying Technology (p. 115)
Step 9 Testing, Testing, Testing (p. 116)
Step 10 Considering Performance (p. 116)
Step 11 Defining the Value (p. 117)
Step 12 Creating Maintenance Procedures (p. 117)
Method or Madness? (p. 118)
Chapter 7 An Introduction to EAI and Middleware (p. 119)
Middleware: The Engine of EAI (p. 119)
What's Middleware? (p. 120)
Types of Middleware (p. 120)
Middleware Models (p. 132)
One-to-One versus Many-to-Many (p. 132)
Synchronous versus Asynchronous (p. 135)
Connection-Oriented and Connectionless (p. 137)
Direct Communications (p. 137)
Queued Communications (p. 137)
Publish/Subscribe (p. 137)
Request Response (p. 138)
Fire and Forget (p. 138)
Conversational-Mode (p. 139)
Tough Choices (p. 139)
Chapter 8 Transactional Middleware and EAI (p. 141)
Notion of a Transaction (p. 143)
The ACID Test (p. 144)
Scalable Development (p. 145)
Database Multiplexing (p. 146)
Load Balancing (p. 146)
Fault Tolerance (p. 147)
Communications (p. 148)
XA and X/Open (p. 148)
Building Transactions (p. 149)
Application Servers (p. 149)
Evolving Transactions (p. 151)
Future of Transactional Middleware (p. 160)
Chapter 9 RPCS, Messaging, and EAI (p. 163)
RPCs (p. 164)
DCE (p. 165)
Message-Oriented Middleware (MOM) (p. 166)
MSMQ (p. 168)
IBM MQSeries (p. 170)
Getting the Message (p. 175)
Chapter 10 Distributed Objects and EAI (p. 177)
What Works (p. 178)
What's So Difficult? (p. 179)
What's So Easy? (p. 180)
What's a Distributed Object? (p. 181)
The General Idea (p. 182)
CORBA (p. 183)
Shortfalls (p. 183)
CORBA Internals (p. 184)
COM (p. 186)
OLE Automation (p. 186)
Moving to DCOM (p. 188)
The Realities (p. 189)
Chapter 11 Database-Oriented Middleware and EAI (p. 191)
What's Database-Oriented Middleware? (p. 193)
Types of Database-Oriented Middleware (p. 195)
ODBC (p. 196)
JDBC (p. 198)
OLEDB (p. 203)
Going Native (p. 205)
Database Gateways (p. 205)
Ready for Prime Time (p. 207)
Chapter 12 Java Middleware and EAI (p. 209)
Categories of Java Middleware Standards (p. 210)
Database-Oriented (p. 210)
Interprocess (p. 210)
Message Oriented (p. 211)
Application-Hosting (p. 216)
Distributed Objects (p. 218)
The Future of Java and Middleware (p. 220)
Chapter 13 Implementing and Integrating Packaged Applications-the General Idea (p. 221)
Why Packaged Applications? (p. 222)
Installing Packaged Applications (p. 224)
Business Drivers (p. 224)
Architectures Drive Success (p. 225)
Testing What Has Already Been Tested (p. 226)
Implementing Specific Packages (p. 227)
Packaged Application Tools (p. 229)
Database Issues (p. 230)
Web Enablement (p. 231)
The Opportunity (p. 233)
Web-Enabled Selling and EAI (p. 233)
Integrating the Supply Chain (p. 234)
Applying EAI to Packaged Applications (p. 236)
Our Packaged Future (p. 239)
Chapter 14 Integrating SAP R/3 (p. 241)
The Basic Problem (p. 242)
SAP Architecture (p. 244)
The SAP Repository (p. 245)
The SAP Presentation Layer (p. 245)
The SAP Application Server Layer (p. 245)
The SAP Database Layer (p. 245)
SAP Middleware (p. 246)
ALE (p. 249)
IDOC (p. 251)
BAPI (p. 252)
Using the Repository (p. 253)
SAP and EAI (p. 254)
Chapter 15 Integrating Peoplesoft (p. 255)
PeopleSoft Architecture (p. 256)
Data Level (p. 258)
Data Mover (p. 258)
SQRs and Moving Data (p. 259)
Workflow and Moving Data (p. 259)
Application Interfaces (p. 260)
Screen Scraping (p. 261)
EDI (p. 261)
Workflow (p. 262)
Workstation (p. 263)
What's Best? (p. 265)
Chapter 16 Supply Chain Integration: Inter-Enterprise Application Integration (p. 267)
Defining Your Supply Chain (p. 268)
Extending EAI outside the Enterprise (p. 270)
Binding the Home System to a Stranger's (p. 271)
The Process (p. 272)
Supply Chain Technology (p. 274)
ERPs and the Supply Chain (p. 276)
Supply Chains Organize (p. 276)
Chapter 17 XML and EAI (p. 279)
The Rise of XML (p. 279)
What's XML? (p. 281)
Data Structures (p. 281)
DTDs (p. 282)
XML Parsers (p. 283)
XML Metadata (p. 283)
XML and Middleware (p. 284)
Persistent XML (p. 286)
RDF and EAI (p. 286)
XSL and EAI (p. 287)
XML and EAI (p. 288)
Chapter 18 Message Brokers-the Preferred EAI Engine (p. 291)
Integration, not Perspiration (p. 292)
Why a New Direction? (p. 293)
Considering the Source (and Target) (p. 296)
Message Translation Layer (p. 297)
Schema Conversions (p. 298)
Data Conversion (p. 300)
Intelligent Routing (p. 301)
Rules Processing (p. 302)
Message Warehousing (p. 304)
Repository Services (p. 305)
Graphical User Interface (p. 307)
Directory Services (p. 308)
Management (p. 309)
Adapters (p. 309)
Thin Adapters (p. 310)
Thick Adapters (p. 311)
Static and Dynamic Adapters (p. 313)
Using an API (p. 314)
Toplogies (p. 314)
The Future of EAI and Brokers (p. 316)
Chapter 19 Process Automation and EAI (p. 319)
What Is Process Automation? (p. 320)
Process Automation and EAI Levels (p. 324)
Implementing Process Automation (p. 325)
Documenting Processes (p. 326)
Defining Processes (p. 326)
Executing Processes (p. 326)
Tools and Approaches (p. 327)
Workflow Standards (p. 330)
Process Automation and EAI (p. 330)
Chapter 20 EAI Moving Forward (p. 333)
Problem Domains Change (p. 334)
Moving from Intra- to Inter-Enterprise Application Integration (p. 334)
Moving from Data-Level to Application-Level Integration (p. 335)
Loose Ends (p. 336)
Vendor Approaches (p. 338)
Data-Oriented (p. 339)
Application Integration-Oriented (p. 341)
Process Automation-Oriented (p. 343)
Transaction-Oriented (p. 344)
Distributed Object-Oriented (p. 344)
Technologies Join Forces (p. 345)
Future Directions (p. 347)
Importance of the Architecture (p. 347)
Importance of Application Design (p. 348)
EAI and the Modern Enterprise (p. 349)
Glossary (p. 351)
Bibliography (p. 361)
Index (p. 367)

Excerpt provided by Syndetics

Enterprise Application Integration, or EAI, is a buzzword that gives a name to the informal process that's been going on for years--the integration of various applications so that they may share information and processes freely. However, with a new, intense focus on EAI from both the vendor and analyst community, the opportunity finally exists to get ahead of the curve on a problem--the integration of applications--that costs the Fortune 1000 over $100 billion per year.Forester Research estimates that more than 30 percent of IT dollars are currently being spent linking systems together for the common good. Perhaps it's time to consider whether that is too great a cost.The EAI twist to this old story is not so much about system integration as it is about rethinking the technologies and approaches that would allow EAI to become a short-term and cost-effective reality. EAI also represents a technology-business philosophy that focuses on the business issues at hand and suggests that all systems existing either inside or outside an enterprise should be free to share information and logic in ways inconceivable in the past. EAI is the nexus of technology, method, philosophy, and desire to finally address years of architectural neglect.Make no mistake--this is an emerging space. Now is the time to ask the tough questions. Now is the time to determine the real value of applying EAI in an enterprise. It's time to question which technologies add value, and to determine which problems they solve. And now is the time to reflect on some of the architectural and design decisions that have been made over the years. Why EAI? Because enterprise architectures have been poorly planned for the last two decades and longer, it is time to return distributed enterprises into the realm of sanity. Many organizations built systems based on the "cool" technology of the day, suckered into the hype without properly considering how these systems would somehow, someday, share information. For example, there are organizations with dozens, if not hundreds, of different types of open and proprietary systems, each with its own development, database, networking, and operating system religion. The result is a heterogeneous mass (read, chaos) that only the bravest--or most foolhardy--enterprise architects are willing to sort out without gutting the entire enterprise just to get things back on a sane track.Again, EAI as such is not new. However, the science behind linking varied types of information systems certainly is. EAI has become a sophisticated set of procedures with newly refined technologies, such as message brokers, that allow users to tie systems together using a common glue. The concept of EAI may not be new, but the power of the tools and technology, as well as the techniques available to solve the EAI problem, sure are. Middleware, for example, once clearly a programmer's toy, is now a business tool that allows enterprises to freely move information between any number of systems at will--in many cases, without having to change the source or the target systems. Cutting-edge technology has created the opportunity to solve a problem that has been becoming more intractable for years. Enter ERPs Another factor that is driving enterprises toward the promised land of EAI is the broad acceptance of Enterprise Resource Planning (ERP) applications as the new IT infrastructure for the post-millennium corporation. Packaged applications, such as those from SAP, PeopleSoft, and Baan, have revolutionized the way integrated information technology systems are built within most enterprises. Rather than creating new systems from scratch, the modern enterprise is able to leverage existing business rules and processes defined by a single, or several, vendors.Companies such as SAP have become multibillion dollar entities thanks to the wide acceptance of ERP applications in larger enterprises. What's more, interest in packaged applications has increased in general, with sales automation packages, customer care packages, and vertical market-oriented packages making headlines in the trade publications.As much as ERP applications can help the integration solution, however, they can also hurt. Organizations are discovering that ERP applications are difficult to install and configure and that, too often, once they are up and running, they turn out not to be all that they were cracked up to be. There is the "little problem" of extracting information from these beasts, information that may be vital to other information systems within the enterprise. For example, if SAP replaces five systems within an enterprise and those five systems supply information to any number of other systems that may also be in place, then the SAP systems must also communicate with these other systems in the enterprise. Making this happen demands an incredible degree of coordination, programming, and testing.Although coordinating these systems may seem like a minor problem to those who have linked custom systems, it is important to remember that a packaged application typically does not allow for any modification to its source that would enable it to pump information out of a common middleware pipe. This requires interfaces that the ERP application vendor provides. While it would seem like an easy stretch to expect the vendor to have solid and easy-to-use interfaces already in place, the reality is much different. In fact, the major ERP application vendors are beginning to create these interfaces within their products. For the time being, the interfaces are immature and difficult to use. This immaturity represents another aspect of EAI and its real value within many enterprises. EAI is able to link many disparate systems--including ERP applications. It is not unreasonable to suggest that the growing interest in ERP could very well be driving the interest in EAI as well. Why Write a Book on EAI? If EAI has been around for a while in everything but name, why write a book on it now? As we've already suggested, the need for EAI is a result of many years of building distributed computing systems with poor architectural planning. The systems using traditional techniques and technology simply cannot communicate with one another without changing a significant portion of the application. In other words, a logical approach is necessary in order to integrate existing enterprise applications, as well as to address the new breed of technology. This book is designed to provide the average computer-literate person with enough information to determine if his or her enterprise needs, or would benefit from, EAI--and, if so, how to approach enterprise information planning requirements using the concepts of EAI.We will present approaches to implementing EAI within typical enterprises, or between two or more enterprises, using the supply chain integration scenarios. We will also discuss the enabling technologies of EAI, technologies such as middleware, system management layers, standards (such as XML), and application development tools that allow applications and databases to share information with one another. Interfaces into complex systems such as SAP and PeopleSoft will not be left out of the mix. We'll also take a look at the future of EAI technology and discuss how you can prepare for it now.Ultimately, this book is designed to save you money. Because the lack of proper EAI means that many existing information systems cannot coordinate or share information--resulting in a tremendous loss of revenue--then the addition of EAI within most enterprises has the potential of saving that revenue. Much of those savings come either with the automation of processes that are currently being completed through mechanical mechanisms or through viewing all enterprise systems as a single virtual system and thus having access to all relevant data for decision support.Of course, any number of other types of savings may be derived from EAI; they vary case by case, enterprise by enterprise. In most situations, the value of EAI is apparent.In addition to the benefit of application integration within the enterprise, a tremendous benefit is also derived from sharing information with applications that exist outside of the enterprise. eBusiness integration is a mechanism by which information systems are connected with information systems that are owned and maintained by a trading partner. The result is the ability to share information, such as order inventory and sales data. Sharing such information speeds up all aspects of business, including production, sales, order processing, and invoice processing. Increased efficiency in any and all of these areas results in increased profitability.eBusiness is the next frontier of EAI. Analysts have already begun to double the estimates for business-to-business electronic commerce. 0201615835P04062001 Excerpted from Enterprise Application Integration by David S. Linthicum 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.

Author notes provided by Syndetics

David S. Linthicum is Chief Technology Officer for SAGA Software, and is an internationally known EAI and e-Business expert. He has consulted for hundreds of major corporations engaged in deploying complex distributed systems. In addition, he is the author of several regular columns, including "Middleman" in Enterprise Developer, and "Site Builder" in Computer Shopper, as well as more than three hundred other articles on technology. David Linthicum is a frequent speaker at technical conferences, including E-Business Expo, Comdex, iEC, Comdex Enterprise, Software Development, and Application Integration and Application Architecture.