27,59 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Service Oriented Architecture (SOA) refers to building systems that offer applications as a set of independent services that communicate and inter-operate with each other effectively. Such applications may originate from different vendor, platform, and programming language backgrounds, making successful integration a challenging task. This book enables you to integrate application systems effectively, using the Trivadis Integration Architecture Blueprint, which is supported by real-world scenarios in which this Integration Blueprint has proved a success.This book will enable you to grasp all of the intricacies of the Trivadis Architecture Blueprint, including detailed descriptions of each layer and component. It is a detailed theoretical guide that shows you how to implement your own integration architectures in practice, using the Trivadis Integration Architecture Blueprint. The main focus is on explaining and visualizing the blueprint, including comprehensive descriptions of all of its layers and components. It also covers the more basic features of integration concepts for less experienced specialists, as well as shedding light on the future of integration technologies, such as XTP and Grid Computing. You will learn about EII and EAI, OGSi, as well as base technologies related to the implementation of solutions based on the Blueprint, such as JCA, JBI, SCA and SDO.The book begins by covering fundamental integration for those less familiar with the concepts and terminology, and then dives deep into explaining the different architecture variants and the future of integration technologies. Base technologies like JCA and SCA will be explored along the way, and the structure of the Trivadis Integration Architecture Blueprint will be described in detail, as will the intricacies of each component and layer. Other content includes discovering and comparing traditional and modern SOA driven integration solutions, implementing transaction strategies and process modeling, and getting to grips with EDA developments in SOA. Finally, the book considers how to map software from vendors like Oracle and IBM to the blueprint in order to compare the solutions, and ultimately integrate your own projects successfully.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 288
Veröffentlichungsjahr: 2010
Ähnliche
Table of Contents
Service-Oriented Architecture: An Integration Blueprint
Service-Oriented Architecture: An Integration Blueprint
A real-world SOA strategy for the integration of heterogeneous Enterprise systems
Copyright © 2010 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: June 2010
Production Reference: 1160610
Published by Packt Publishing Ltd.
32 Lincoln Road
Olton
Birmingham, B27 6PA, UK.
ISBN 978-1-849681-04-9
www.packtpub.com
Cover Image by Sandeep Babu (<[email protected]>)
Credits
Authors
Guido Schmutz
Daniel Liebhart
Peter Welkenbach
Reviewers
Albert Blarer
Tony Fräfel
Christoph Pletz
Patrick Blaser
Karsten Krösch
Acquisition Editor
James Lumsden
Development Editor
Stephanie Moss
Technical Editor
Ishita Dhabalia
Indexer
Rekha Nair
Editorial Team Leader
Gagandeep Singh
Project Team Leader
Lata Basantani
Project Coordinator
Sneha Harkut
Proofreader
Sandra Hopper
Graphics
Nilesh Mohite
Geetanjali Sawant
Alwin Roy
Production Coordinator
Alwin Roy
Cover Work
Alwin Roy
Foreword
Developing integration solutions is not a simple task, despite the fact that the integration of individual databases, applications, and complete systems is increasingly becoming part of software engineers’ day-to-day work. In addition, developers of Enterprise Service Buses (ESBs); Enterprise Information Integration (EII) infrastructures; messaging systems; service-oriented architecture (SOA) frameworks; Extract, Transform, and Load (ETL) tools; and software for data integration, all take very different approaches, and many organizations already have one or more different integration solutions in place. The Trivadis Integration Architecture Blueprint is the result of work on a large number of projects (not all of them successful), of detailed discussions with customers and specialists, and of careful study of the technical literature.
The development of the integration blueprint took several months, as the main objective was to structure the integration solution in such a way that standardized, tried-and-tested basic components could be combined to form a functioning whole, with the help of tools and other products. It was also important that the solution met customers’ requirements, and could be implemented without the excessive use of resources.
We believe that by structuring the integration layer into different, clearly defined levels and layers, and by assigning best practice patterns to these layers, we can make the process of developing integration solutions significantly simpler in practice.
The concept behind the Trivadis Integration Architecture Blueprint was developed by the authors, together with Fernand Hänggi and Albert Blarer, and formulated by Daniel Liebhart, Guido Schmutz, and Peter Welkenbach. Large parts of the book have been revised several times by the authors, and have also been the subject of intense debates in workshops. We would like to thank the reviewers Albert Blarer, Patrick Blaser, Christoph Pletz, and Karsten Krösch and, in particular, Tony Fräfel for his detailed input.
Further technical information is available on our website (www.trivadis.com) in the download area and the blog (under Know-How Community).
We would like to thank everyone who has contributed to this book in any way. This includes, in particular, the reviewers and our patient colleagues who were always prepared to discuss things in detail, and clarify any number of aspects of the book. We would also like to thank our customers and business partners, with whom we have worked on a variety of projects that have given us many interesting and enriching experiences. Finally, we would like to thank our colleagues, friends, families, the proofreaders, and the publishers for their patience.
About the Authors
Guido Schmutz has worked as a software developer, IT consultant, lead architect, trainer, and coach for more than 20 years. As head of the Application Development area of the Trivadis Technology Center, he has written numerous technical publications, developed IT strategies, courses, and technocircles and spoken at international conferences. Guido Schmutz is responsible for innovating, designing, and implementing many data warehouse, customer relationship management (CRM), customer satisfaction measurement (CSM), management information system (MIS), and Enterprise Application Architecture (EAI) solutions for international banks, pharmaceutical companies, public authorities, and logistics companies. He specializes in enterprise architecture, bi-temporal data management, Java Persistence, and the Spring framework. You can contact him at <[email protected]>.
Daniel Liebhart has more than 20 years experience of IT, and 10 years experience of managing IT services and product development. His industry and technical knowledge covers the design, architecture, implementation, and operation of complex, international systems in telecommunications, financial services, logistics, and the manufacturing industry. Daniel Liebhart is passionate about IT. He has received a number of awards and he gives lectures on software architecture and business informatics at the Hochschule für Technik in Zurich. You can reach him at <[email protected]>.
Peter Welkenbach works as a consultant, senior architect, and trainer in the fields of requirement engineering, object-oriented methodologies, software engineering, and quality management. He has more than 20 years experience of designing and implementing complex information systems for banks, automotive manufacturers, and pharmaceutical companies. For 10 years he has been a technology evangelist for Java technology and the use of the corresponding frameworks in customer projects. His current technical focus is model-driven software development, the Unified Modeling Language (UML), aspect-oriented programming, Java Server Faces (JSF), asynchronous Java Script, and XML (AJAX) and architecture design methodology. Peter Welkenbach is a course developer, author of numerous publications, and speaker at JAX and international Oracle conferences. He has been using Spring in numerous customer projects since it first appeared in summer 2003. You can get in touch with Welkenbach at <[email protected]>.
Preface
With the widespread use of service-oriented architecture (SOA), the integration of different IT systems has gained a new relevance. The era of isolated business information systems—so-called silos or stove-pipe architectures—is finally over. It is increasingly rare to find applications developed for a specific purpose that do not need to exchange information with other systems. Furthermore, SOA is becoming more and more widely accepted as a standard architecture. Nearly all organizations and vendors are designing or implementing applications with SOA capability. SOA represents an end-to-end approach to the IT system landscape as the support function for business processes. Because of SOA, functions provided by individual systems are now available in a single standardized form throughout organizations, and even outside their corporate boundaries. In addition, SOA is finally offering mechanisms that put the focus on existing systems, and make it possible to continue to use them. Smart integration mechanisms are needed to allow existing systems, as well as the functionality provided by individual applications, to be brought together into a new fully functioning whole. For this reason, it is essential to transform the abstract concept of integration into concrete, clearly structured, and practical implementation variants.
The Trivadis Integration Architecture Blueprint indicates how integration architectures can be implemented in practice. It achieves this by representing common integration approaches, such as Enterprise Application Integration (EAI); Extract, Transform, and Load (ETL); event-driven architecture (EDA); and others, in a clearly and simply structured blueprint. It creates transparency in the confused world of product developers and theoretical concepts.
The Trivadis Integration Architecture Blueprint shows how to structure, describe, and understand existing application landscapes from the perspective of integration. The process of developing new systems is significantly simplified by dividing the integration architecture into process, mediation, collection and distribution, and communication layers. The blueprint makes it possible to implement application systems correctly without losing sight of the bigger picture: a high performance, flexible, scalable, and affordable enterprise architecture.
The background: Integration instead of isolation
Many enterprises are converting their operational structure from a functional hierarchy to a process-oriented, flexible organizational form. A characteristic feature of function-oriented organizations is a vertical division into independent functions. As a result, process chains are typically interrupted at departmental boundaries. This leads to the creation of so-called process islands, which often fall under different areas of responsibility and administration. If the departments in question are also geographically separated, the potential for communication problems increases. In general, the formation of these islands also has an impact on the IT landscape. In such companies, there are usually large numbers of redundant applications and data islands, and integrating them represents challenges from technical, social, and organizational perspectives.
Information transparency is normally not one of the strengths of this type of organization. Instead, the necessary knowledge about implemented process logic, and the accompanying data, is stored at a departmental level in a non-transparent and incomplete form. Redundant and inconsistent data is a common challenge/problem for these companies, and the process of integrating this data is time consuming as well as costly.
As a result, function-oriented organizations have difficulties in reacting in an appropriate, agile fashion to rapidly changing markets, customer requirements, and technologies. Process-oriented organizations, on the other hand, are considerably more flexible and, from an IT perspective, have the support of corresponding process-oriented concepts, such as SOA and EDA.
Process-oriented organizations need to be supported by process-oriented IT systems. Nowadays, the close links between operational processes and the underlying IT systems, make it necessary for the IT landscape to be closely tailored to the enterprise's technical requirements, and not to be regarded simply as an end in itself. In recent years, the term "Service-Oriented Architecture" has been widely used to describe a concept that puts process-oriented, technical services at the heart of the technical perspective, with the aim of offering reusable service components which allow for the implementation of business processes in a quick, cost-effective, and easily traceable way.
If the IT landscape of a process-oriented organization is considered as a whole, strategic aspects such as the implementation of an enterprise architecture (Bernus et al. 2003), a business motivation model (Hall et al. 2005), the Open Group Architecture Framework (Haren 2007), the Zachman Framework (Zachman 2007), or process architectures, come into play. Although this approach has a very small role in the concrete implementation of applications, there is, nevertheless, a common denominator here: the integration architecture. Putting an integrated solution (based on a blueprint) in place supports the systematic and strategic implementation of an enterprise architecture.
What this book covers
Despite the wide variety of useful and comprehensive books and other publications on the subject of integration, the approaches that they describe often lack practical relevance. The basic issue involves, on the one hand, deciding how to divide an integration solution into individual areas so that it meets the customer requirements, and on the other hand, how it can be implemented with a reasonable amount of effort. In this case, this means structuring it in such a way that standardized, tried-and-tested basic components can be combined to form a functioning whole, with the help of tools and products. For this reason, the Trivadis Integration Architecture Blueprint subdivides the integration layer into further layers. This kind of layering is not common in technical literature, but it has been proven to be very useful in practice. It allows any type of integration problem to be represented, including traditional ETL (Extract, Transform, and Load), classic EAI (Enterprise Application Integration), EDA (event-driven architecture), and grid computing. This idea is reflected in the structure of the book.
Chapter 1, Basic Principles, covers the fundamental integration concepts. This chapter is intended as an introduction for specialists who have not yet dealt with the subject of integration.
Chapter 2, Base Technologies, describes a selection of base technologies. By far the most important of these are transaction strategies and their implementation, as well as process modeling. In addition, Java EE Connector Architecture (JCA), Java Business Integration (JBI), Service Component Architecture (SCA), and Service Data Objects (SDO) are explained. Many other base technologies are used in real-life integration projects, but these go beyond the scope of this book.
Chapter 3, Integration Architecture Blueprint, describes the Trivadis Integration Architecture Blueprint. The process of layering integration solutions is fully substantiated, and each step is explained on the basis of the division of work between the individual layers. After this, each of the layers and their components are described.
Chapter 4, Implementation Scenarios, demonstrates how the Trivadis Integration Architecture Blueprint represents the fundamental integration concepts that have been described in Chapter 1. We will use the blueprint with its notation and visualization to understand some common integration scenarios in a mostly product-neutral form. We will cover traditional, as well as modern, SOA-driven integration solutions.
Chapter 5, Vendor Products for Implementing the Trivadis Blueprint, completes the book with a mapping of some vendor platforms to the Trivadis Integration Architecture Blueprint.
Appendix, References holds a list of all the referenced books and articles. It's a collection of additional important and interesting material covering modern SOA-driven as well as traditional integration solution.
What you need for this book
The book assumes a comprehensive understanding of SOA; however, previous knowledge of the Trivadis Blueprint is not necessary. Those less experienced in integration will benefit from the explanation of integration concepts and terminology, while the more advanced can move straight onto getting to grips with the Blueprint's structure.
Who this book is for
This book is intended for IT professionals, architects, managers, and project managers who are responsible for planning, designing, providing, and operating integration solutions.
Conventions
In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.
New terms and important words are shown in bold.
Note
Warnings or important notes appear in a box like this.
Tip
Tips and tricks appear like this.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply send an e-mail to <[email protected]>, and mention the book title via the subject of your message.
If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or e-mail <[email protected]>.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration, and help us to improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/support, selecting your book, clicking on the let us know link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata added to any list of existing errata. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Piracy
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or web site name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors, and our ability to bring you valuable content.
Questions
You can contact us at <[email protected]> if you are having a problem with any aspect of the book, and we will do our best to address it.
Chapter 1. Basic Principles
This chapter describes the fundamental concepts of integration, and is intended as an introduction to integration technology and terminology. You will:
Integration
The term integration has a number of different meanings. A fundamental knowledge of the terms and concepts of integration is an essential part of an integration architect's toolkit. There are many ways of classifying the different types of integration. From an enterprise-wide perspective, a distinction is made between application-to-application (A2A), business-to-business (B2B), and business-to-consumer (B2C) integration. Portal, function, and data integration can be classified on the basis of tiers. Another possible grouping consists of integration based on semantics.
Fundamental integration concepts include Enterprise Application Integration (EAI), Enterprise Service Bus (ESB), middleware, and messaging. These were used to define the subject before the introduction of SOA, and still form the basis of many integration projects today. EAI is, in fact, a synonym of integration. In David Linthicum's original definition of EAI, it means the unrestricted sharing of data and business processes among any connected applications. The technological implementation of EAI systems is, in most cases, based on middleware. The main base technology of EAI is messaging, giving the option of implementing an integration architecture through asynchronous communication, using messages which are exchanged across a distributed infrastructure and a central message broker.
The fundamental integration architecture variants are:
A point-to-point architecture is a collection of independent systems, which are connected through a network.
Hub-and-spoke architecture represents a further stage in the evolution of application and system integration, in which a central hub takes over responsibility for communications.
In pipeline architecture, independent systems along the value-added chain are integrated using a message bus. The bus capability is the result of interfaces to the central bus being installed in a distributed manner through the communication network, which gives applications local access to a bus interface. Different applications are integrated to form a functioning whole by means of distributed and independent service calls that are orchestrated through an ESB and, if necessary, a process engine.
A fundamental technique for integration is the usage of design patterns. These include process and workflow patterns in a service-oriented integration, federation, population, and synchronization of patterns in a data integration, and direct connection, broker, and router patterns, which form part of EAI and EII. It is important to be familiar with all of these patterns, in order to be able to use them correctly.
The most recent integration architectures are based on concepts such as event-driven architecture, grid computing, or extreme transaction processing (XTP). These technologies have yet to be tested in practice, but they are highly promising and of great interest for a number of applications, in particular, for corporate companies and large organizations.
Concepts
The Trivadis Integration Architecture Blueprint applies a clear and simple naming to each of the individual layers. However, in the context of integration, a wide range of different definitions and terms are used, which we will explain in this chapter.
A2A, B2B, and B2C
Nowadays, business information systems in the majority of organizations consist of an application and system landscape, which has grown gradually over time. The increasing use of standard software (packaged applications) means that information silos will continue to exist. IT, however, should provide end-to-end support for business processes. This support cannot, and must not, stop at the boundaries of new or existing applications. For this reason, integration mechanisms are needed, which bring together individual island solutions to form a functioning whole. This happens not only at the level of an individual enterprise or organization, but also across different enterprises, and between enterprises and their customers. At an organizational level, a distinction is made between A2A, B2B, and B2C integration (Pape 2006). This distinction is shown in the image below. Each type of integration places specific requirements on the methods, technologies, products, and tools used to carry out the integration tasks. For example, the security requirements of B2B and B2C integrations are different from those of an A2A integration.
Modern concepts such as the Extended Enterprise integration across organizational boundaries, (Konsynski 1993) and the Virtual Enterprise (Hardwick, Bolton 1997) can be described using a combination of the different integration terms.
Integration types
Integration projects are generally broken down into information portals, shared data integration, and shared function integration. Portals integrate applications at a user interface level. Shared data integration involves implementing integration architectures at a data level, and shared function integration at a function level.
Information portals
The majority of business users need access to a range of systems in order to be able to run their business processes. They may need to be able to answer specific questions (that is, a call center taking incoming customer calls must be able to access the latest customer data) or to initiate or implement certain business functions (that is, updating customer data). In these circumstances, employees often have to use several business systems at the same time. An employee may need to access an order system (on a host) in order to verify the status of a customer order and, at the same time, may also have to open a web-based order system to see the data entered by the customer. Information portals bring together information from multiple sources. They display it in one place so that users do not have to access several different systems (which might also require separate authentication) and can work as efficiently as possible (Kirchhof et al. 2003). Simple information portals divide the user's screen into individual areas, each of which displays the data from one backend system independently, without interacting with the others. More sophisticated systems allow for limited interaction between the individual areas, which makes it possible to synchronize the different areas. For example, if the user selects a record in one area, the other areas are updated. Other portals use such advanced integration technology that the boundaries between the portal application and the integrated application become blurred (Nussdorfer, Martin 2006).
Shared data
Shared databases, file replication, and data transfers fall in the category of integration using shared data (Gorton 2006).
Shared business functions
In the same way that different business systems store redundant data, they also have a tendency to implement redundant business logic. This makes maintenance and adapting to new situations both difficult and costly. For example, different systems must be able to validate data using predefined, centrally managed business rules. It makes sense to manage such logic in a central place.
Differences between EAI and SOA
In many cases, EAI solutions have only been able to fulfill the expectations placed on them to either a limited extent, or in an unsatisfactory way. This is, among other things, due to the following factors (Rotem-Gal-Oz 2007):
If EAI solutions are used in combination with web services to link systems together, this is still not the equivalent of an SOA. Although the number of proprietary connection components between the systems being linked are reduced by the use of open WS-* standards, a "real" SOA involves a more extensive architectural approach, based on a (business) process-oriented perspective on integration problems.
While EAI is data driven and puts the emphasis on application interface integration, SOA is a (business) process-driven concept, which focuses on integrating service interfaces in compliance with open standards encapsulating the differences in individual integration approaches. As a result, it removes the barrier between the data integration and application integration approaches. However, SOA has one significant problem, which is that of semantic integration. Existing web services do not provide a satisfactory answer to this problem, but they do allow us to formulate the right questions in order to identify future solutions.
Semantic integration and the role of data
The challenge represented by semantic integration is based on the following problem:
This means that the data structure and data information (its meaning) are often not the same thing and, therefore, have to be interpreted (Inmon, Nesavich 2008).
The following example will help to make this clearer:
A date, such as "7 August 1973," forms part of the data. It is not clear whether this information is a text string or in a date format. It may even be in another format and will have to be calculated on the basis of reference data before runtime. This information is of no relevance to the user.
However, it might be important to know what this date refers to, in other words, its semantic meaning in its reference context. Is it a customer's birthday, or the date on which a record was created? This example can even be more complex.
Another example that can be interpreted differently in different contexts is the term Caesar, for instance. Depending on the context, it could be the name of a pet or the name of pet food, a well-known salad, a gambling casino, or the name of a Roman emperor.
It is clear that data without a frame of reference is lacking any semantic information, causing the data to be ambiguous and possibly useless. Ontologically-oriented interfaces, as well as adaptive interfaces, can help to create such semantic reference and will become increasingly important in the field of autonomous B2B or B2C marketplaces in the future.
