Leigh A. Davis

The impact of component architectures on interoperability

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.

A notation for problematic architecture interactions

The progression of component-based software engineering (CBSE) is essential to the rapid, cost-effective development of complex software systems. Given the choice of well-tested components, CBSE affords reusability and increases reliability. However, applications developed according to this practice can often suffer from difficult maintenance and control, problems that stem from improper or inadequate integrate solutions. Avoiding such unfortunate results requires knowledge of what causes the interoperability problems in the first place. The time for this assessment is during application design. In this paper, we define problematic architecture interactions using a simple notation with extendable properties. Furthermore, we delineate a multi-phase process for pre-integration analysis that relies on this notation. Through this effort, potential problematic architecture interactions can be illuminated and used to form the initial requirements of an integration architecture.

Identifying Evolvability for Integration

The seamless integration of commercial-off-the-shelf (COTS) components offers many benefits associated with reuse. Even with successful composite applications, unexpected interoperability conflicts can arise when COTS products are upgraded, new components are needed, and the application requirements change. Recent approaches to integration follow pattern-based design principles to construct integration architecture for the composite application. This integration architecture provides a design perspective for addressing the problematic interactions among components within the application environment. However, little attention has been paid to the evolvability of these architectures and their embedded functionality. In this paper, we discuss the need for design traceability based on the history of interoperability conflicts and resolution decisions that comprise the integration architecture. Additionally, we advocate that certain functional aspects of a pattern can be pinpointed to resolve a conflict. Combining these two aspects of integration architecture design, we illustrate that often evolution is possible with minimal changes to the integration solution.

Patterns of conflict among software components

Integrating a system of disparate components to form a single application is still a daunting, high risk task, especially for components with heterogeneous communication expectations. It benefits integration to know explicitly the interoperability conflicts that can arise based on the current application design and the components being considered. However, there is no consistent representation of identified conflicts that also defines strategies to resolve them. Instead, developers use prior experience which may have consequential gaps. In this paper, we formulate a common representation for six major interoperability conflicts that arise through discrepancies or direct mismatches among architectural properties of interacting components. We use an Extender-Translator-Controller (ETC) classification scheme to describe the conflict resolution strategies. Detailing these associations as patterns provides insight into formulating an overall integration architecture design reflecting the solution strategy for developers to codify with respect to all components in the application. This approach moves conflict detection and resolution toward automation, immediately reducing the risk associated with the development of component based integrated systems.

A patterned approach for linking knowledge-based systems to external resources

Knowledge-based systems (KBSs) have been developed and used in industry and government as assistance systems, voting partner systems, and embedded applications. As web-based systems change the face of software implementations, these closed, internal KBSs need to be integrated into multicomponent applications that provide updated and extensible services. Therefore, KBSs must be adapted to an environment in which data and control are exchanged with external processes and resources; complementing other participating systems or using them to refine its own results. This integration can be a daunting task. If improperly done, it can result in an inefficient and unmanageable composite application. One approach to simplifying this task is the use of architectural patterns for integration. These patterns are assembled from functional entities that resolve component interoperability conflicts. In this paper, we describe an architectural pattern called the Knowledge Director pattern, which directs the integration of a closed KBS into a broader application environment.

Toward formalizing service integration glue code

Application integrations employ interacting software components and services. Components - distributed, black-box, processing elements - may have distinct communication styles. Services can be used to augment the interaction of components to deliver on a common task. Unfortunately, there exist scenarios where components and services do not interact congenially. At issue is the service design that, even with standards in place, may ignore important aspects of component communication expectations. Thus, a complete integration is not achieved without implementing ad hoc glue code external to the design strategy. Introducing glue code, without design traceability, limits control, dynamism, and upgrades to components and services. We specify templates for framing glue code as integration completion functions (ICFs). Uniform designs are given using multiple modeling techniques to foster compilation of an ICF repository, where their instantiation can be plug-ins to application integrations.

Understanding Services for Integration Management

With the advent of web services, service-oriented architectures (SOAs), which promise interoperable communication in an application integration, are now primarily web-based. Due to the high degree of encapsulation and heterogeneity among commercial-off-the-shelf (COTS) components, their use is limited within these SOAs. This is because the definitions of web-based services do not differentiate between component services and integration functionality nor has this integration functionality been classified specifically for COTS components. Understanding what inhibits COTS components from participating in a SOA is essential to enabling their integration. In this paper, we identify and define common enablement services that facilitate service-oriented integrations in which COTS components participate as integration management services. Software architecture can express integrated system design by identifying needed integration functionality independent of communication mechanisms. Therefore, we describe common web services in architecture terms and, through design patterns, define the integration functionality by which they are distinguished.

Classifying Interoperability Conflicts

A common path for application development is to pick the COTS or legacy products, choose a middleware product, and determine what additional functionality is needed to make it all work. While this may seem the most expedient and least costly way to develop an integrated application, unexpected interoperability conflicts can surface after implementation, deployment and/or evolution of any of the participating components. An interoperability conflict is any factor inhibiting communication of control or data among components.Current research has shown that interoperability conflicts can be traced to the software architecture of the components and integrated application, making this level of abstraction a suitable domain for conflict description. In this paper, we describe and substantiate a set of architecture-based conflicts that embody the predominant interoperability problems found in software integrations.

How system architectures impede interoperability

Interoperability problems arise when complex software systems are constructed by integrating distinct, and often heterogeneous, components. By performing interoperability analysis on the software architecture design of the system and its components, potential incompatibilities can be anticipated early in the design process. In this paper, we focus on an application’s structural requirements as reflected in values of particular architectural characteristics, describing how they can be incompatible with individual component system properties.

Discovery and composition of services in dynamic mobile environments

Service-oriented computing exhibits dynamically composed, complex services in order to manage wide ranges of requests and adapt to the greatest number of system paradigms. Mobile ad hoc and ubiquitous networks exhibit characteristics that require note when participating in a service-oriented model. Often, neither computationally expensive requests nor bandwidth intensive communications are possible due to the resource limitations of such networks devices. Communication is unreliable, which prohibits a centralized solution common in a wired service-oriented system. Furthermore, services running in mobile environments can move in and out of communication range of their encompassing composed services during request fulfillment. All of these issues pose unique challenges when postulating service-oriented approaches to further the state of the art. With this workshop, we seek to provide a forum for members of the services, ubiquitous, and distributed systems computing areas to explore the related issues in dynamic service composition approaches for distributed and mobile environments.