Replaceable Components and the Service Provider Interface

Several popular component-based standards have emerged recently, including JavaBeans and Enterprise JavaBeans from Sun Microsystems and the Component Object Model from Microsoft. These component models are being adopted for use in software development, as they eliminate opportunities for architectural mismatch and are supported by standard services. A highly touted property of component models is that they support the development of replaceable components. Unfortunately, a robust, commercial marketplace of replaceable components has not been established for any of these component models. On the other hand, the properties of the Service Provider Interface (SPI), used in many Java language packages, has resulted in the development of reusable components in several technology areas. Examples of successful SPI packages include Java Database Connectivity, Java Cryptography Extension, Java Naming and Directory Interface, and the Java Application Program Interface for XML Processing. This technical note considers the motivation for using replaceable components and defines the requirements of replaceable component models. It evaluates the properties of standard component models and the SPI approach that affect their ability to support replaceable components

A Process for Context-Based Technology Evaluation

In order to determine a fit between systems and technology, it is necessary to evaluate technologies within the contexts that they will be used. This report describes a process called context-based evaluation that determines the fitness of a technology within a specific context. It includes hands-on experimentation with the technology for a greater understanding of its implications, as well as early competence development of the people conducting the experiments. An integral part of the process is the development of model problems; these are prototypes, situated in a specific context, with the goal of satisfying evaluation criteria. The focus of this report is on evaluation of software technologies, such as Web services, database systems, or architectural frameworks and development tools. The report also includes a case study of the use of this process for the evaluation of Web service technology

Approaches to Constructive Interoperability

Interoperability between systems requires the capability for users to exchange information (syntactic interoperability) and a common understanding of its meaning or how to act upon it (semantic interoperability). This report will discuss several current approaches to constructing systems of systems that have interoperability requirements, with respect to syntactic and semantic interoperability. The areas examined include Model-Driven Architecture, Service-Oriented Architecture, Web services, Open Grid Services Architecture, and Component Frameworks. These initial discussions assume that the interoperating systems agree on a common approach. Reaching an agreement can be challenging, especially when legacy systems are involved. Technical techniques and recommendations for reaching an agreement between systems that use differing technologies are also briefly explored

Model Problems in Technologies for Interoperability: Model-Driven Architecture

Model-driven architecture (MDA) is a technology produced and maintained by the Object Management Group (OMG), an open membership, not-for-profit consortium that produces and maintains computer industry specifications for interoperable enterprise applications. This technical note examines two claims regarding the benefits of MDA, namely, that it (1) reduces development time, and (2) allows the developer to focus on business logic rather than on details about the target platform and architecture. Such advantages would greatly benefit interoperability; as target platforms and underlying infrastructure change, deployment of applications would be quick and easy. This note presents the results of applying the model problem approach to verify these claims

Model Problems in Technologies for Interoperability: Web Services

Web service technologies (or Web services) are experiencing a growing popularity in U.S. Department of Defense, industry, and non-defense government organizations due to their potential to enable interoperability between applications implemented on different platforms. This potential stems from Web services being based on standards that have been widely accepted and implemented, such as the Simple Object Access Protocol and the Web Services Description Language. The large number of products and tools created to facilitate the development of Web services has also contributed to their popularity. This technical note presents the results of applying the model problem approach in an initial investigation of the potential of Web services to enable interoperability

A Requirement Specification Language for AADL

<p>This report describes a textual requirement specification language, called ReqSpec, for the Architecture Analysis & Design Language (AADL). It is based on the draft Requirements Definition and Analysis Language Annex, which defines a meta-model for requirement specification as an-notations to AADL models. A set of plug-ins to the Open Source AADL Tool Environment (OSATE) toolset supports the ReqSpec language. Users can follow an architecture-led requirement specification process that uses AADL models to represent the system in its operational con-text as well as the architecture of the system of interest. ReqSpec can also be used to represent existing stakeholder and system requirement documents. Requirement documents represented in the Requirements Interchange Format can be imported into OSATE to migrate such documents into an architecture-centric virtual integration process. Finally, ReqSpec is an element of an architecture-led, incremental approach to system assurance. In this approach, requirements specifications are complemented with verification plans. When executed, these plans produce evidence that a system implementation satisfies the requirements. This report introduces the ReqSpec notation and illustrates its use on an example.</p

T-Check in Technologies for Interoperability: Business Process Management in a Web Services Context

In Business Process Management (BPM), many technologies are available to describe, analyze, execute, and monitor business processes. Composition languages are one type of BPM technology. Through the use of composition languages, business processes that are implemented through software and available as web services can be combined into new processes. The most popular language in this field is the Business Process Execution Language (BPEL). BPEL allows a user to declaratively combine existing services within and outside an organization to implement a full business process. This technical note presents the results of applying the T-Check approach in an initial investigation of BPEL and related technologies for the implementation of BPM. This approach involves (1) formulating hypotheses about the technology and (2) examining these hypotheses against specific criteria through hands-on experimentation. The outcome of this two-stage approach is that the hypotheses are either fully or partially sustained or refuted. In this report, three hypotheses are examined: (1) business process descriptions can be exchanged between different design tools and runtime engines; (2) the development effort for integration is reduced through the use of a BPM tool; and (3) business processes can be changed dynamically at runtime. From the T-Check investigation, the first two hypotheses are partially sustained and the last hypothesis is fully sustained

T-Check for Technologies for Interoperability: Open Grid Services Architecture (OGSA): Part 1

Many current technology approaches exist for building systems that have interoperability requirements. This report investigates Open Grid Services Architecture (OGSA), one of the many technologies for accomplishing interoperability, using the T-Check technique. A T-Check is a simple and cost-efficient way to understand what a technology can and cannot do in a specific context. This report describes a T-Check exploration of the feasibility of using OGSA in the context of data management, finding that OGSA (a) provides data storage and retrieval where the specific implementation of the data store implementation is transparent and (b) allows addition or removal of data stores at runtime without affecting system operation. This report is part one of a two-part investigation; part two will look at OGSA in the context of load distribution

Assumptions Management in Software Development

Software developers constantly make assumptions about the interpretation of requirements, design decisions, operational domain, environment, characteristics of input data, and other factors during system implementation. These assumptions are seldom documented and less frequently validated by the people who have the knowledge to verify their appropriateness. Additionally, the business, legal, and operating environments are always changing, as well as the software itself, rendering previously valid assumptions invalid. This technical note explores assumptions management as a method for improving software quality. This exploration covers assumptions management concepts, results of work on a prototype Assumptions Management System, conclusions, lessons learned, and potential work in this area

What’s New in V2 of the Architecture Analysis & Design Language Standard?

<p>This report provides an overview of changes and improvements to the Architecture Analysis & Design Language (AADL) standard for describing both the software architecture and the execution platform architectures of performance-critical, embedded, real-time systems. The standard was initially defined in the document SAE AS-5506 and published in November 2004 by SAE International (formerly the Society of Automotive Engineers). SAE International published the revised language, known as AADL V2, in January 2009. Feedback from users of the standard guided the plan for improvements. Their experience and suggestions resulted in the addition of component categories to better represent protocols as logical entities (virtual bus), scheduler hierarchies and logical time partitions (virtual processor), and a generic component (abstract). The revisions also led to the abilities to (1) explicitly parameterize component declarations to better express architecture patterns, (2) specify multiple instances of the same component in one declaration (component array) and corresponding connection patterns, (3) set visibility rules for packages and property sets that access other packages and property sets, (4) specify system-level mode transitions more precisely, and (5) use additional property capabilities including property value records.</p