The impact of component architectures on interoperability

https://doi.org/10.1016/S0164-1212(01)00112-1Get rights and content

Abstract

Component interoperability has become an important concern as companies migrate legacy systems, integrate COTS products, and assemble modules from disparate sources into a single application. While middleware is available for this purpose, it often does not form a complete bridge between components and may be inflexible as the application evolves. What is needed is the explicit design information that will forecast a more accurate, evolvable, and less costly integration solution implementation.

Emerging research has shown that interoperability problems can be traced to the software architecture of the components and integrated application. Furthermore, the solutions generated for these problems are guided by an implicit understanding of software architecture. Current technology does not fully identify what must be made explicit about software architecture to aid in comparison of the architectures and expectations of participating entities within the integrated application. Thus, there can be no relief in the expense or the duration of implementing long-term reliance on middleware. The overall goal of our research is to extract and make explicit the information needed to define and build this technology. This paper focuses on identifying, classifying, and organizing characteristics that help to define an architectural style by using abstraction and semantic nets. We illustrate the relationships between the characteristics and their relevance to interoperability via examples of integrated applications.

Introduction

With the on-going need for more rapid development schedules and less expensive implementations, innovations in system design are a must. Hypothetically, the composition of existing software components and the migration of legacy components to other environments or applications should cut development cost and time. Unfortunately, components often are not as adaptable to new applications or environments as developers assume they would be. Moreover, addressing interoperability problems is often postponed until implementation, in favor of the use of vendor provided middleware.

Middleware is a variety of distributed computing services and application development environments that operate between the application logic and the underlying system (Charles, 1999). The motivation behind middleware is to provide a generic and reusable solution to communication conflicts. Unfortunately, these solutions have failed to perform as expected. One reason is that they require developers with expertise in the product and the respective middleware framework to define a solution. Due to the infancy of component reusability, this level of skill is hard to find in-house. Customizations and large-scale coding efforts by experts in the field may be necessary to deploy a product. Consequently, project managers recruited to make middleware choices have limited understanding of their domain and services. They have to rely on commercial middleware vendors for consulting, which can lead to dependence on a particular product even if it is not well suited to the integration at hand and its future evolution. These aforementioned factors can make heterogeneous component integration costly and time-consuming.

In order for developers to make prudent middleware decisions, they must first understand the root causes of interoperability problems in the system (Mevidovic et al., 2000). Without this understanding, they cannot determine how a given middleware framework manifests solutions to these conflicts. Problems with obtaining this knowledge are compounded by disagreement on exactly what type of component description is most useful for analysis. Technology is therefore essential to assist the developer in analyzing interoperability problems. It is important that this technology must not be orthogonal to industry demands, but rather complimentary.

The main challenges to developing this technology are:

  • 1.

    Accumulating and identifying relevant properties of the participating components and application requirements for analysis.

  • 2.

    Organizing key properties into a uniform representation.

  • 3.

    Developing algorithms to analyze properties for identification of established interoperability conflict types.

  • 4.

    Defining resolution techniques that can express potential middleware frameworks.


The approach that we advocate is to use software architecture (Shaw and Garlan, 1996) to reveal system properties which are currently implicit in interoperability conflicts (Davis et al., 2000). Our working hypothesis is that there exists a minimal, usable set of architecture characteristics that can determine the early presence of interoperability conflicts. Once defined, this set can be used further to determine the appropriate architecture connectors to resolve those conflicts (Keshav and Gamble, 1998; Mehta et al., 2000).

Our focus in this paper is the identification and organization of fundamental architectural characteristics for explicit consideration as culprits of interoperability conflicts, described in problems 1 and 2 above. This is the first step toward establishing the technology for assessing interoperability conflicts and formulating integration solutions. Hence, the goal of the paper is to establish a standard set of characteristics using principled methods by which each component can be architecturally identified. We utilize the abstract properties from software architecture because they provide a means for powerful assessment without burdening the developer with unnecessary details.

Principled methods allow us to establish that the set we seek to define contains properties that qualify as

  • highly relevant,

  • wide-encompassing, and

  • having values that can be obtained with relative ease.


We believe that a vast number of architectural characteristics play a part in interoperability as evidence by published case studies (Garlan et al., 1995; Allen and Garlan, 1997; Abd-Allah, 1996; Sitaraman, 1997; Barret et al., 1996). Past approaches, while providing the foundation for identification, have not been principled (Abd-Allah, 1996; Allen and Garlan, 1997; Garlan et al., 1995; Shaw and Clements, 1997; Sitaraman, 1997; Barret et al., 1996; Gacek, 1997). As a result, properties have been incompletely and/or redundantly defined. In addition, similar properties have been defined at different levels of abstraction, causing comparison difficulties. In this paper, we provide a comprehensive treatment of these various published characteristics. This treatment involves the use of distinct levels of abstraction and semantic networks to show how properties can be grouped for comparative evaluation. We conclude the paper to show how implicit understanding of the characteristic set aids in discerning interoperability conflicts.

Section snippets

Related work

The software architecture of a system is a high-level description of its computational elements, the means by which they interact, and the structural constraints on that interaction (Perry and Wolf, 1992; Shaw and Garlan, 1996). Characteristics have been defined with respect to architectural styles that include the various types of components and connectors, data issues, control issues, and control/data interactions. Many characteristics are used to differentiate among architectural styles,

Architecture characteristics for interoperability

Software architecture characteristics have the potential to deliver clear and early warnings of interoperability problems. To illustrate, suppose you need to put together an investigative task force to examine the reasons why high school girls leave math and science studies. Requirements for the team include timely conclusions, voluntary participation in which only travel is paid, and heterogeneity among team members. Candidate members might be psychologists, mathematicians, computer

Determining connectivity

Knowing a characteristic's level of abstraction provides the foundation for determining its relationship with other characteristics. For instance, we can separate drinks into categories such as champagne, wine, and beer, and compare their price. We could compare price within a category and across categories, but our motivation for comparison would be different, e.g. which champagne should you choose (intra-category) versus whether or not (due to its higher price) you should buy champagne at all

The presence of characteristics

The objective of the previous sections was to identify, through principled means, a representative set of architectural characteristics as a foundation for the interoperability analysis of component architectures. In this section, we discuss the emergent characteristic set with respect to three integrated applications. In fact, we illustrate that these characteristics are implicitly considered, rather than explicitly used for analysis of interoperability; the point being that their influence is

Conclusion

Development can be paralyzed if misunderstood interoperability issues are addressed well after the application requirements are established. This is made more complex by poorly detailed or unorganized information concerning a system's data and control communication and interoperation. In this paper, we isolate architectural characteristics that are relevant to interoperability problems in distributed component architectures. Through the reduction, abstraction, and linking of the original set of

Acknowledgements

This research is supported in part by grants from the Air Force Office of Scientific Research (F49620-98-1-0217 and F49620-01-1-0002) and the National Science Foundation (CCR-9988320). The US government has certain rights to this material.

Leigh A. Davis is a member of SEAT at the University of Tulsa. She attended New York University where she received a B.F.A. in Film Production. Being a great lover of film, but not a financially successful filmmaker, she began her graduate studies in Computer Science at the University of Tulsa, where she will receive an M.S. in May 2001. She intends to continue for a Ph.D. Besides film, Davis is a devotee of pillates, as well as a writer and performer.

References (35)

  • Abd-Allah, A., 1996. Composing heterogeneous software architectures. Ph.D. dissertation, University of Southern...
  • G Abowd et al.

    Formalizing style to understand description of software architecture

    ACM TOSEM

    (1995)
  • R Allen et al.

    A formal basis for architectural connection

    ACM TOSEM

    (1997)
  • R Allen et al.

    Formal modeling and analysis of the HLA component integration standard

    FSE-6

    (1998)
  • Barret, D., Clarke, L., Tar, P., Wize, A., 1996. An event-based software integration framework. Technical report 95-048...
  • M.R Cantor

    Object-Oriented Project Management with UML

    (1998)
  • J Charles

    Middleware moves to the forefront

    Computer

    (1999)
  • Chen, C., 1995. Integrating Existing Event-based Distributed Applications, Xerox...
  • L Davis et al.

    How system architectures impede interoperability

  • D Garlan et al.

    Architectural mismatch or why it is so hard to build systems out of existing parts

  • D Garlan et al.

    ACME: An architecture description interchange language

  • D Garlan

    Higher-order connectors

  • Gacek, C., 1997. Detecting architectural mismatches during systems composition, Technical report USC/CSE-97-TR-506,...
  • V Gruhn et al.

    Integration of heterogeneous software architectures – an experience report

  • P Inverardi et al.

    Static checking of system behaviors using derived component assumptions

    ACM TOSEM

    (2000)
  • R Kazman et al.

    Classifying architectural elements as foundation for mechanism mismatching

  • A Kelkar et al.

    Understanding the architectural characteristics behind middleware choices

  • Cited by (34)

    • Patterns of conflict among software components

      2006, Journal of Systems and Software
    • An open system architecture framework for interoperability

      2022, International Journal of Business Information Systems
    • Inserting components incrementally

      2012, Proceedings of the 6th IASTED International Conference on Software Engineering and Applications, SEA 2002
    • A Framework for end-to-end approach to Systems Integration

      2010, International Journal of Industrial and Systems Engineering
    • Simulation interoperating mechanism of logistic information system driven flexsim

      2009, Hunan Daxue Xuebao/Journal of Hunan University Natural Sciences
    View all citing articles on Scopus

    Leigh A. Davis is a member of SEAT at the University of Tulsa. She attended New York University where she received a B.F.A. in Film Production. Being a great lover of film, but not a financially successful filmmaker, she began her graduate studies in Computer Science at the University of Tulsa, where she will receive an M.S. in May 2001. She intends to continue for a Ph.D. Besides film, Davis is a devotee of pillates, as well as a writer and performer.

    Rose F. Gamble is an Associate Professor of Computer Science and the Director of the Software Engineering and Architecture Team (SEAT) at the University of Tulsa. Gamble received her Ph.D. from Washington University in St. Louis in Computer Science. Her research interests are in software engineering and knowledge based systems.

    Jamie Payton attends the University of Tulsa, where she has participated in the university's undergraduate research program for the past four years. In May of 2001, she will complete her Bachelor of Science degree in Computer Science. After graduation, Payton plans to attend graduate school to obtain a doctoral degree in Computer Science.

    Technical report UTULSA-MCS-99-30.

    View full text