The impact of component architectures on interoperability☆
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...
- et al.
Formalizing style to understand description of software architecture
ACM TOSEM
(1995) - et al.
A formal basis for architectural connection
ACM TOSEM
(1997) - 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...
Object-Oriented Project Management with UML
(1998)Middleware moves to the forefront
Computer
(1999)- Chen, C., 1995. Integrating Existing Event-based Distributed Applications, Xerox...
- et al.
How system architectures impede interoperability
- et al.
Architectural mismatch or why it is so hard to build systems out of existing parts
ACME: An architecture description interchange language
Higher-order connectors
Integration of heterogeneous software architectures – an experience report
Static checking of system behaviors using derived component assumptions
ACM TOSEM
Classifying architectural elements as foundation for mechanism mismatching
Understanding the architectural characteristics behind middleware choices
Cited by (33)
Patterns of conflict among software components
2006, Journal of Systems and SoftwareAn open system architecture framework for interoperability
2022, International Journal of Business Information SystemsKnowledge management and reuse in collaborative product development - A semantic relationship management-based approach
2014, International Journal of Product Lifecycle ManagementInserting components incrementally
2012, Proceedings of the 6th IASTED International Conference on Software Engineering and Applications, SEA 2002A Framework for end-to-end approach to Systems Integration
2010, International Journal of Industrial and Systems EngineeringSimulation interoperating mechanism of logistic information system driven flexsim
2009, Hunan Daxue Xuebao/Journal of Hunan University Natural Sciences
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.