NEWS AT SEI
This library item is related to the following area(s) of work:System of Systems
This article was originally published in News at SEI on: February 1, 2005
Government and commercial organizations have been placing increasing reliance on interoperability among large numbers of systems for achieving important mission goals. One mechanism for both achieving interoperability and for leveraging the value of legacy systems is for organizations to expose all or parts of their legacy systems as services. A service is a coarse-grained, discoverable, and self-contained software entity that interacts with applications and other services through a loosely coupled, often asynchronous, message-based communication model [Brown 02]. A collection of services with well-defined interfaces and a shared communications model is called a service-oriented architecture (SOA). A system or application is designed and implemented as a set of interactions among these services.
SOAs allow legacy systems to expose their functionality, sometimes without making significant changes to the legacy systems. SOAs also have characteristics that make effective interoperability easier, such as loose coupling, published interfaces, and a standard communication model. However, constructing services from existing systems to obtain the benefits of an SOA is neither easy nor automatic. In fact, such a migration can represent a complex engineering task, particularly when the services are expected to execute within a tightly constrained environment.
This article is the first of two parts. The first article outlines what service-oriented architectures are as well as general issues that need to be addressed in creating services from legacy components. It also provides a notional DoD-relevant example. The second article will discuss how to evaluate services for migration to an SOA.
We have already said that a service interacts with other services through a message-based communications model. Common communications models include
SOAs differ from other messaging models such as DCOM (Distributed Component Object Model) or Object Request Brokers (ORBs) because services of SOAs are discoverable and coarse-grained. Services must be able to be discovered at both design time and runtime, not only by unique identity, but also by interface identity and type of service. Services are also coarse-grained; that is, they implement more functionality and operate on larger data sets, as compared to components in component-based design [Lewis 04]. A typical example of a service includes a credit card validation service.
A service consumer can
In a service-oriented architecture, “interoperability” refers to the ability of the service to be invoked by any potential client of the service [Stevens 03]. There are several attributes of a SOA that make this possible:
From a syntactic point of view, a service-oriented architecture is promising. The challenge lies in determining the number of adapters to implement and determining the right granularity of service interfaces, because it is not always known how systems will use the services. It is important to keep in mind that services are executed as an exchange of a service request and a service response. If service interfaces are too coarse-grained, clients will receive more data than they need in their response message. If service interfaces are too fine-grained, clients will have to make multiple trips to the service to get all the data they need.
From a semantic point of view, service-oriented architectures by themselves do not offer any guarantees. Semantic interoperability depends on how the interfaces to a service are described and how the meaning of the information is shared with potential clients of the service. Several issues that need to be addressed include
The most common (but not only) form of service-oriented architecture is that of Web services, in which all of the following apply: (1) service interfaces are described using Web Services Description Language (WSDL), (2) payload is transmitted using Simple Object Access Protocol (SOAP) over Hypertext Transfer Protocol (HTTP), (3) Universal Description, Discovery and Integration (UDDI) is used as the directory service [Lewis 04].
Enabling a legacy system to interact within a service-oriented architecture, such as a Web services architecture, is sometimes relatively straightforward; this is a primary attraction to the approach for many businesses. Web service interfaces are set up to receive SOAP messages, parse their content, invoke legacy code directly or through a custom component that invokes the legacy code, and optionally wrap the results as a SOAP message to be returned to the sender. Many modern development environments provide tools to help in this process, and commercial organizations are rapidly employing these environments to expose their business processes to the world.
However, characteristics of legacy systems, such as age, language, and architecture, as well as of the target SOA, can complicate the task. This is the case when migrating to highly demanding and proprietary SOAs such as those being proposed for many DoD systems.
DoD systems have recently focused on the concept of network-centric operations: providing forces with access to integrated information from a variety of previously unconnected sources [Alberts 00]. This focus requires strong interoperability to ensure that systems work together effectively. To facilitate such interoperability, the DoD has initiated a number of projects that focus on different aspects of the infrastructure for network-centric operations. Several of these projects are developing SOAs so that command and communications (C2) applications can be built as a set of interactions between infrastructure services (e.g., communication, discovery) and services that are specific to the C2 domain (application domain services). Current and future DoD program offices have been targeted to contribute application domain services.
A notional example of such an SOA is illustrated in Figure 1.
Figure 1 shows that this example of an SOA includes common services (CS) that are to be used by user applications and application domain services (ADS). The SOA owns the interfaces for the common services. The environment then allows for a set of ADSs that will derive their requirements from user applications. Groups within DoD are invited to submit proposals for services to meet these requirements, either by building them from scratch or by migrating them from legacy components. These requirements must then be analyzed in detail and matched to existing functionality to determine what can be used as is, what has to be modified, and what has to be newly developed.
Such an SOA can impose a number of constraints on organizations that are developing ADSs from existing legacy components. Some of the requirements for developers of ADSs include
DoD migrations to SOAs (such as the notional example that we outlined above) will likely rely less on semi-automated migration and more on careful analysis of the feasibility and magnitude of the effort involved. Such an analysis should consider:
To address these issues, it is important to
The requirements for how potential services interact with the SOA must be identified. Specific types of requirements may include
The second article in this series will describe an approach for addressing these issues and evaluating services for migration to an SOA.
Alberts, D.; Garstka, J.; and Stein, F. Network Centric Warfare: Developing and Leveraging Information Superiority. 2nd Edition (Revised). Washington, DC: CCRP Publication Series. February 2000.
Brown, A; Johnston, S.; and Kelly, K. Using Service-Oriented Architecture and Component-Based Development to Build Web Service Applications. Cupertino, CA: Rational Software Corporation. 2002.
Lewis, Grace and Wrage, Lutz. Approaches to Constructive Interoperability (CMU/SEI-2004-TR-020). Pittsburgh, PA: Software Engineering Institute, 2004.
Stevens, M. "Service-Oriented Architecture Introduction." 2004.
Grace Lewis is a Senior Member of Technical Staff at the Software Engineering Institute (SEI) of Carnegie Mellon University (CMU), where she is currently working in the areas of constructive interoperability, COTS-based systems, modernization of legacy systems, enterprise information systems, and model-driven architecture. Her latest publications include several reports published by Carnegie Mellon on these subjects and a book in the SEI Software Engineering Series. Grace has over fifteen years of experience in Software Engineering. She is also a member of the technical faculty for the Master in Software Engineering program at CMU.
Edwin Morris is a Senior Member of the Technical Staff at the Software Engineering Institute, assigned to the Integration of Software-Intensive Systems (ISIS) Initiative. He is currently investigating approaches to achieving technical interoperability between complex systems and programmatic interoperability between the organizations that build and maintain them. Previous activities involved improving processes and techniques for the evaluation and selection of COTS products, and the development of the COTS Usage Risk Evaluation (CURE) technology. Before coming to the SEI, Ed developed custom operating systems for embedded microprocessors along with support tools to predict and monitor the performance of real time systems.
Dennis Smith is the Lead for the SEI Initiative on the Integration of Software Intensive Systems. This initiative focuses on addressing issues of interoperability and integration in large scale systems and systems of systems. Earlier, he was the technical lead in the effort for migrating legacy systems to product lines. In this role he developed the method “Options Analysis for Reengineering, OARS to support reuse decision-making. Dr. Smith has also been the project leader for the CASE environments project. This project examined the underlying issues of CASE integration, process support for environments and the adoption of technology.
Dr. Smith has published a wide variety of articles and technical reports, and has given talks and keynotes at a number of conferences and workshops. He has an M.A. and PhD from Princeton University, and a B.A from Columbia University.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.