System Integration Using Model-Driven Engineering

System Integration Using Model-Driven Engineering

Krishnakumar Balasubramanian (Vanderbilt University, USA), Douglas C. Schmidt (Vanderbilt University, USA), Zoltán Molnár (Vanderbilt University, USA) and Ákos Lédeczi (Vanderbilt University, USA)
Copyright: © 2009 |Pages: 31
DOI: 10.4018/978-1-59904-699-0.ch016
OnDemand PDF Download:
$37.50

Abstract

With the emergence of commercial-off-the-shelf (COTS) component middleware technologies software system integrators are increasing faced with the task of integrating heterogeneous enterprise distributed systems built using different COTS technologies. Although there are well-documented patterns and techniques for system integration using various middleware technologies, system integration is still largely a tedious and error-prone manual process. This chapter provides three contributions to the study of functional integration of distributed enterprise systems. First, we describe the challenges associated with functionally integrating software for these types of systems. Second, we describe how the composition of domain-specific modeling languages (DSMLs) can simplify the functional integration of enterprise distributed systems. Third, we demonstrate how composing DSMLs can solve functional integration problems in an enterprise distributed system case study by reverse engineering an existing CCM system and exposing it as Web service(s) to Web clients who use these services.
Chapter Preview
Top

Introduction

Functional Integration of Component Middleware

With the maturation of commercial-off-the-shelf (COTS) component middleware technologies, such as Enterprise Java Beans (EJB) (Sun Microsystems, 2001), CORBA Component Model (CCM) (CORBA Components, 2002), and Microsoft .NET Framework (Microsoft Corporation, 2002), software developers are increasingly faced with the task of integrating heterogeneous enterprise distributed systems built using different COTS technologies, rather than just integrating proprietary software developed in-house. Although there are well-documented patterns (Hohpe & Woolf, 2003) and techniques (Britton & Bye, 2004) for integrating systems via various component middleware technologies, system integration is still largely a tedious and error-prone manual process. To improve this process, therefore, component developers and system integrators must understand key properties of the integration technologies they are applying and the systems2 they are integrating.

There are multiple levels at which system integration is done today (TrowBridge, Roxburgh, Hohpe, Manolescu, & Nadhan, 2004), including:

  • Data integration: which integrates systems at the logical data layer, typically using some form of data transfer/sharing. Example technologies that allow data integration include commercial databases (such as IBM DB2, Oracle, and Microsoft SQL Server) and tools (such as Microsoft BizTalk Mapper and IBM WebSphere Integration Developer) that provide database schema mapping between different databases.

  • Functional integration: which integrates systems at the logical business layer, typically using distributed objects/components, service-oriented architectures or messaging middleware. Examples of technologies that allow functional integration include the Java Connector Architecture and Service-oriented Integration adapters available in commercial products, such as IBM’s Websphere.

  • Presentation integration: which allows access to an application’s functionality through its user interface by simulating a user’s input and by reading data from the screen. This “screen scraping” is usually done via programming languages like Perl that use regular expressions to parse the screen output of legacy systems.

  • Portal integration: which creates a portal application displaying information retrieved from multiple applications via a unified user interface, thereby allowing users to perform required tasks. Examples of technologies that allow portal integration include Microsoft ASP.NET and Java portlets combined with Java Server Pages (JSP), which provide technologies to build Web-based portals for integrating information from a variety of sources.

  • Process integration: which defines a business process model describing the individual steps in a complex business function and coordinates the execution of long-running business functions that span multiple disparate applications. Example technologies that support process integration include implementations of Business Process Execution Language (BPEL) and its Web services incarnation (WS-BPEL).

This chapter describes technologies that help simplify the functional integration of systems built using component middleware. This type of integration operates at the logical business layer, typically using distributed objects/components, exposing service-oriented architectures, or messaging middleware, and is responsible for delivering services to clients with the desired quality of service (QoS). We focus on functional integration of systems in this paper because:

  • Component middleware is typically used to implement the core business logic of a system. In this context it is inappropriate to use portal integration because there may be no direct user interaction and because component middleware usually resides in the second tier of a typical three-tier enterprise architecture. In contrast, the entities that make up a “portal,” for example, portlets, are usually user-facing and belong in the first tier, that is, the front-end tier.

  • Unlike legacy systems, component middleware technologies usually expose an API to access functionality. Employing presentation integration to integrate systems built using component middleware technologies is problematic. For example, techniques used in typical presentation integration (such as parsing the output of a system to enable integration) are ad hoc compared with using the well-defined APIs exposed by component middleware technologies.

  • Updates to data at the business logic layer occur frequently during system execution. Due to the cost of remote data access operations and the rate at which such operations are generated by the business logic components in the second tier of a three-tier enterprise architecture, it is therefore infeasible to employ data integration to keep the data consistent among the different systems. Data integration is usually appropriate for the back-end (i.e., third tier) of a three-tier enterprise architecture, where the data is long-lived and not transient.

  • The business logic of a system is often proprietary and organizations tightly control the interfaces exposed by the system. It is often unnecessary, therefore, to employ process integration, which usually applies to interorganizational integration where loose-coupling is paramount. Process integration is a superset of functional integration, and usually relies on functional integration within autonomous organizational boundaries.

Functional integration of systems is hard due to the variety of available component middleware technologies, such as EJB and CCM. These technologies differ in many ways, including the protocol level, the data format level, the implementation language level, or the deployment environment level. In general, however, component middleware technologies are a more effective technology base than the brittle proprietary infrastructure used in legacy systems (Sharp, 2000), which have historically been built in a vertical, stove-piped fashion.

Despite the benefits of component middleware, key challenges in functional integration of systems remain unresolved when integrating large-scale systems developed using heterogeneous COTS middleware. These challenges include (1) integration design, which involves choosing the right abstraction for integration, (2) interface mapping, which reconciles different data types, (3) technology mapping, which reconciles various low-level issues, (4) deployment mapping, which involves planning the deployment of heterogeneous COTS middleware, and (5) portability incompatibilities between different implementations of the same middleware technology. The lack of simplification and automation in resolving these challenges today significantly hinders effective system integration.

Complete Chapter List

Search this Book:
Reset