The Trivadis Integration Architecture Blueprint

Exclusive offer: get 50% off this eBook here
Service Oriented Architecture: An Integration Blueprint

Service Oriented Architecture: An Integration Blueprint — Save 50%

Successfully implement your own enterprise integration architecture using the Trivadis Integration Architecture Blueprint with this SOA book and eBook

$20.99    $10.50
by Daniel Liebhart Guido Schmutz Peter Welkenbach | June 2010 | Enterprise Articles SOA

The Trivadis Integration Architecture Blueprint specifies the building blocks needed for the effective implementation of integration solutions. It ensures consistent quality in the implementation of integration strategies as a result of a simple, tried-and-tested structure, and the use of familiar integration patterns (Hohpe, Wolf 2004).

In this article by Guido Schmutz, co-author of Service-Oriented Architecture: An Integration Blueprint, we will cover:

  • Standards, components, and patterns used
  • Structuring the integration blueprint

(For more resources on Trivadis Integration and SOA, see here.)

Introduction

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.

Standards, components, and patterns used

The Trivadis Integration Architecture Blueprint uses common standardized techniques, components, and patterns, and is based on the layered architecture principle.

A layered architecture divides the overall architecture into different layers with different responsibilities. Depending on the size of the system and the problem involved, each layer can be broken down into further layers. Layers represent a logical construct, and can be distributed across one or more physical tiers. In contrast to levels, layers are organized hierarchically, and different layers can be located on the same level. Within the individual layers, the building blocks can be strongly cohesive. Extensive decoupling is needed between the layers. The rule is that higher-level layers can only be dependent on the layers beneath them and not vice versa. Each building block in a layer is only dependent on building blocks in the same layer, or the layers beneath. It is essential to create a layer structure that isolates the most important cohesive design aspects from one another, so that the building blocks within the layers are decoupled.

The blueprint is process oriented, and its notation and structure are determined by the blueprint's dependencies and information flow in the integration process. An explanation of how the individual layers, their building blocks, and tasks can be identified from the requirements of the information flow is given on the basis of a simple scenario. In this scenario, the information is transported from one source to another target system using an integration solution.

In the blueprint, the building blocks and scenarios are described using familiar design patterns from different sources:

  • (Hohpe, Wolf 2004)
  • (Adams et al. 2001)
  • (Coral8 2007)
  • (Russel et al. 2006)

These patterns are used in a shared context on different layers. The Trivadis Integration Architecture Blueprint includes only the integration-related parts of the overall architecture, and describes the specific view of the technical integration domain in an overall architecture. It focuses on the information flow between systems in the context of domain-driven design.

Domain-driven design is a means of communication, which is based on a profound understanding of the relevant business domain. This is subsequently modeled specifically for the application in question. Domain models contain no technical considerations and are restricted exclusively to business aspects. Domain models represent an abstraction of a business domain, which aims to capture the exemplary aspects of a specific implementation for this domain. The objectives are:

  • To significantly simplify communication between domain experts and developers by using a common language (the domain model)
  • To enable the requirements placed on the software to be defined more accurately and in a more targeted way
  • It must be possible to describe, specify, and document the software more precisely and more comprehensibly, using a clearly defined language, which will make it easier to maintain

The technical aspects of architecture can be grouped into domains in order to create specific views of the overall system. These domains cover security, performance, and other areas. The integration of systems and information also represents a specific view of the overall system, and can be turned into a domain.

Integration domain is used to mean different things in different contexts. One widely used meaning is "application domain," in other words, a clearly defined, everyday problem area where computer systems and software are used. Enterprise architectures are often divided into business and technical domains:

  • Business domains may include training, resource management, purchasing, sales or marketing, for example.
  • Technical domains are generally areas such as applications, integration, network, security, platforms, systems, data, and information management.

The blueprint, however, sees integration as a technical domain, which supports business domains, and has its own views that can be regarded as complementary to the views of other architecture descriptions.

In accordance with Evans (Evans, 2004), the Trivadis Integration Architecture Blueprint is a ubiquitous language for describing integration systems. This and the structure of the integration domain on which it is based, have been tried and tested in a variety of integration projects using different technologies and products. The blueprint has demonstrated that it offers an easy-to-use method for structuring and documenting implementation solutions. As domain models for integration can be formulated differently depending on the target platform (for example, an object-oriented system or a classic ETL solution), the domain model is not described in terms of object orientation. Instead, the necessary functionality takes the form of building blocks (which are often identical with familiar design patterns) on a higher level of abstraction. This makes it possible to use the blueprint in a heterogeneous development environment with profitable results.

An architecture blueprint is based on widely used, tried-and-tested techniques, components, and patterns, which are grouped into a suitable structure to meet the requirements of the target domain.

The concepts, the functionality, and the building blocks to be implemented are described in an abstract form in blueprints. These are then replaced or fine-tuned by product-specific building blocks in the implementation project. Therefore, the Trivadis Integration Architecture Blueprint has been deliberately designed to be independent of individual vendors, products, and technologies. It includes integration scenarios and proposals that apply to specific problems, and can be used as aids during the project implementation process. The standardized view of the integration domain and the standardized means of representation enable strategies, concepts, solutions, and products to be compared with one another more easily in evaluations of architectures.

The specifications of the blueprint act as guidelines. Differences between this model and reality may well occur when the blueprint is implemented in a specific project. Individual building blocks and the relationships between them may not be needed, or may be grouped together. For example, the adapter and mapper building blocks may be joined together to form one component in implementation processes or products.

Service Oriented Architecture: An Integration Blueprint Successfully implement your own enterprise integration architecture using the Trivadis Integration Architecture Blueprint with this SOA book and eBook
Published: June 2010
eBook Price: $20.99
Book Price: $34.99
See more
Select your format and quantity:

(For more resources on Trivadis Integration and SOA, see here.)

Structuring the integration blueprint

The following diagram is an overview of the Trivadis Integration Architecture Blueprint. It makes a distinction between the application and information view and the integration view.

The Trivadis Integration Architecture Blueprint

The application and information view consists of external systems, which are to be connected together by an integration solution. These are source or target entities in the information flow of an integration solution. Generally one physical system can also take on both roles. The building blocks belonging to the view, and the view itself, must be regarded as external to the integration system that is being described and, therefore, not the subject of the integration blueprint. The external systems can be divided into three main categories:

  • Transactional information storage: This includes classic relational database management systems (RDBMS) and messaging systems (queues, topics). The focus is on data integration.
  • Non-transactional information storage: This is primarily file-based systems and non-relational data stores (NoSQL) with a focus on data integration.
  • Applications: Applications include transactional or non-transactional systems that are being integrated (ERP—Enterprise Resource Planning, CMS—Content Management System, and so on) and can be accessed through a standardized API (web service, RMI/IIOP, DCOM, and so on). The focus is on application and process integration.

The integration view lies at the heart of the integration blueprint and is divided (on the basis of the principle of divide and conquer) into the following levels:

  • Transport level: The transport level encapsulates the technical details of communication protocols and formats for the external systems. It contains:
    • Communication layer: The communication layer is part of the transport level, and is responsible for transporting information. This layer links the integration solution with external systems, and represents a type of gateway to the infrastructure at an architectural level. It consists of transport protocols and formats.
  • Integration domain level: The integration domain level covers the classic areas of integration, including typical elements of the integration domain, such as adapters, routers, and filters. It is divided into:
    • Collection/distribution layer: This layer is responsible for connecting components. It is completely separate from the main part of the integration domain (mediation). The building blocks in this layer connect the mediation layer above with the communication layer below. The layer is responsible for encapsulating external protocols and their technical details from the integration application, and transforming external technical formats into familiar internal technical formats.
    • Mediation layer: This layer is responsible for forwarding information. Its main task is to ensure the reliable forwarding of information to business components in the process layer, or directly to output channels that are assigned to the collection/distribution layer, and that distribute data to the target systems. This is the most important functionality of the integration domain. In more complex scenarios, the information forwarding process can be enhanced by information transformation, filtering, and so on.
  • Application level: The application level encapsulates the integration management and process logic. It is an optional level and contains:
    • Process layer: The process layer is part of the application level, and is responsible for orchestrating component and service calls. It manages the integration processes by controlling the building blocks in the mediation layer (if they cannot act autonomously).

The integration view contains additional functionality that cannot be assigned to any of the levels and layers referred to above. This functionality consists of so-called cross-cutting concerns that can be used by building blocks from several other layers. Cross-cutting concerns include:

  • Assembly/deployment: Contains configurations (often declarative or scripted) of the components and services. For example, this is where the versioning of Open Service Gateway initiative (OSGi) services is specified.
  • Transaction: Provides the transaction infrastructure used by the building blocks in the integration domain.
  • Security/management: This is the security and management infrastructure used by the building blocks in the integration domain. It includes, for example, libraries with security functionality, JMX agents, and similar entities.
  • Monitoring, BAM, QoS: These components are used for monitoring operations. This includes ensuring compliance with the defined Service Level Agreements (SLA) and Quality of Service (QoS). Business Activity Monitoring (BAM) products can be used for monitoring purposes.
  • Governance: These components and artifacts form the basis for SLAs and QoS. The artifacts include business regulations, for example. In addition, this is where responsibilities, functional and non-functional requirements, and accounting rules for the services/capacities used are defined.

Summary

In this article we have covered:

  • Standards, components, and patterns used
  • Structuring the integration blueprint

In the next article we will cover Implementation scenarios.


Further resources on this subject:


Service Oriented Architecture: An Integration Blueprint Successfully implement your own enterprise integration architecture using the Trivadis Integration Architecture Blueprint with this SOA book and eBook
Published: June 2010
eBook Price: $20.99
Book Price: $34.99
See more
Select your format and quantity:

About the Author :


Daniel Liebhart

Daniel Liebhart has over 20 years of experience in the information technology field, which has culminated in a broad technical and business know-how. For 10 years he has been working in different management positions, leading IT professional services or product development. His broad know-how comprises the engineering, realization, and operation of complex and internationally operated IT systems for the Telecommunication, Finance, Logistic, and Chemical industries, as well as for public services. He has authored three books for Hanser Publications, is a passionate computer science engineer, possesses several awards, and has worked for Trivadis, a leading independent IT service company operating in Germany, Austria, and Switzerland. He works as an assistant professor at the University of Applied Science in Zurich.

Guido Schmutz

Guido Schmutz is an Oracle ACE director for Fusion Middleware and SOA and works for the Swiss Oracle Platinum Partner Trivadis. He has more than twenty years of technology experience ranging from mainframes, integration, and SOA technologies in financial services, government, and vendor environments. At Trivadis he is responsible for SOA, application integration, and open source-based development. He has lengthy experience as a developer, coach, trainer, and architect in the area of building complex Java EE and SOA-based applications. Currently, he is focusing on SOA and application integration projects using the Oracle SOA Suite. Guido is also co-author of the books Service-Oriented Architecture: An Integration Blueprint, "Spring 2.0 im Einsatz," "Architecture Blueprints," and "Integration Architecture Blueprints".

Peter Welkenbach

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. 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. His current focus is on enterprise architecture and lean architecture methodologies. In his current projects he works as an enterprise architect for a well known German retailer.

Books From Packt


Oracle SOA Suite 11g R1 Developer's Guide
Oracle SOA Suite 11g R1 Developer's Guide

Service Oriented Java Business Integration
Service Oriented Java Business Integration

SOA Patterns with BizTalk Server 2009
SOA Patterns with BizTalk Server 2009

RESTful Java Web Services
RESTful Java Web Services

SOA Governance
SOA Governance

Business Process Driven SOA using BPMN and BPEL
Business Process Driven SOA using BPMN and BPEL

WCF Multi-tier Services Development with LINQ
WCF Multi-tier Services Development with LINQ

BPEL PM and OSB operational management with Oracle Enterprise Manager 10g Grid Control
BPEL PM and OSB operational management with Oracle Enterprise Manager 10g Grid Control


No votes yet

Post new comment

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
w
a
w
7
f
c
Enter the code without spaces and pay attention to upper/lower case.
Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software