NEWS AT SEI

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.

Service-Oriented Architectures

We have already said that a service interacts with other services through a message-based communications model. Common communications models include

• Web services using Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL)
• Message-oriented middleware (MOM) such as IBM WebSphere MQ
• Publish-subscribe system such as Java Messaging Service (JMS)

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

• invoke a service directly from a service provider
• use a directory service to find a service provider based on some criteria. The directory service returns the location of the service so the service consumer can invoke the service provider.
• use a service broker to pass on its request to one or more directory services.

SOA and Interoperability

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:

• Common payload (the actual data that is being exchanged) and protocol: each service provides an interface that is invoked through a payload format and protocol that are understood by all the potential clients of a service.
• Published and discoverable interfaces: each service has a published and discoverable interface that allows systems to search for services that are best suited for their purposes.
• Loose coupling: services are connected to other services and clients using standard, dependency-reducing, decoupled message-based methods such as XML document exchanges.
• Multiple communication interfaces: services can implement separately defined communication interfaces. For example, a service could have a Web services adapter, an IIOP (Internet Inter-ORB Protocol) adapter, and an MQSeries adapter to serve clients of these different types.
• Composability: Because services are coarse-grained reusable components that expose their functionality through a well-defined interface, systems can be built as a composition of services and evolve through the addition of new services.

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

• how to know exactly what a service offers
• the quality of service it offers

Creation of Services From Legacy Components

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 SOA Context

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: Physical View of Example Target SOA

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

1. An ADS must be self-contained; that is, it should be able to be deployed as a single unit.
   
   As expressed earlier, the reason why SOAs have been a success, especially in industry, is that they provide standard interfaces to legacy systems, while these systems remain largely unchanged.
   
   This is not the case in the sample target SOA. Services must be independent so that they can be deployed as needed on standardized platforms. In a legacy component, functionality that has been identified as part of a service must be fully extracted from the system, including code that corresponds to shared libraries or the core of a product line.
2. In the target SOA, an ADS may need to be deployed on a specific operating system.
   
   For legacy components deployed on a different operating system, this could be a problem, especially if there are dependencies on the operating system through direct system calls or if there is a dependency on commercial products that are available only for specific systems. Ideally, system calls should be eliminated. If it is not possible, they should be evaluated to see if there are equivalents in the target operating system or if this functionality is part of one of the common services.
3. All services will share a common data model and all data will be accessed through a Data Store common service.
   
   The need for a common data model is driven by a desire for information to be shared and understood by all user applications. As a result, services will no longer define internal data. All data will be defined as part of the common data model. Legacy components must replace all dependencies on databases and file systems with calls to the data store service and make sure that all the data they need is part of the common data model.
4. An ADS will use the Discovery common service to find and connect to other services.
   
   If the ADS will rely on other services, code to discover and connect to these services will have to be written. Once the service is developed, it must be advertised. This is done by registering the service with the naming service. Once this advertised service has been registered, other applications that wish to use this service will perform a discovery on the available services and choose which service(s) they desire to use.
5. An ADS will use the Communications common service for communicating with other services.
   
   The target SOA provides tools for generating data readers and data writers that will take incoming and outgoing data and format it accordingly.

Information Required for Decision-Making

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:

1. Requirements from potential service users. It is important to know what applications would use the services and how they would be used. For example, what is the information expected to be exchanged? In what format?
2. Technical characteristics of the target environment. There are many technical underpinnings that must be understood, especially in proprietary environments, such as bindings, messaging technologies, communication protocols, service description languages, and service discovery mechanisms.
3. The architecture of the legacy system. It is critical to identify architectural elements that could be problematic in the target environment or that could increase the difficulty of the effort, such as dependencies on commercial products or specific operating systems, or poor separation of concerns.
4. The effort involved in writing the service interface. Even if it is expected that the legacy system will remain intact, there must be code that receives the request, translates it into calls to the legacy systems, and produces a response.
5. The effort involved in the translation of data types. Service interfaces usually prescribe a set of data types that can be transmitted in messages. For newer legacy systems and basic data types, this can be a small effort, especially if messages are XML documents. But, in the case of complex data types such as audio, video, and graphics, or in legacy programming languages that do not provide capabilities for building XML documents, this effort can be non-trivial.
6. The effort required to describe the services. In an SOA, services advertise their capabilities for other systems to use, and systems find the services they need by using the discovery mechanism prescribed by the target environment. The more detailed and precise the description of the service, the greater the chances it will be discovered and used appropriately. In critical DoD situations, the description may have to include information about qualities of service, such as performance, reliability, and security, or it may include service level agreements (SLAs) [SLMLC 05].
7. The effort involved in writing service initialization code and operational procedures. Code that is deployed as services will need to initialize itself, announce its availability, and be ready to take requests. This will require the establishment of operational procedures for the deployment of services.
8. Estimates of cost, difficulty, and risk. The information gathered in the previous points should provide for realistic estimates.

Conclusions and Next Steps

To address these issues, it is important to

• gather evidence about potential services that can be created from the legacy components
• gather sufficient detail about the target SOA to support decisions about what services may be appropriate and how they will interact with the architecture

The requirements for how potential services interact with the SOA must be identified. Specific types of requirements may include

• standards and technologies to be employed and relevant guidance documents
• execution platforms, substrates, and middleware
• deployment requirements
• special requirements regarding handling of data and state
• specific quality of service requirements that affect potential services directly and end-to-end quality of service requirements that affect related collections of services

The second article in this series will describe an approach for addressing these issues and evaluating services for migration to an SOA.

References

[Alberts 00]
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 02]
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 04]
Lewis, Grace and Wrage, Lutz. Approaches to Constructive Interoperability (CMU/SEI-2004-TR-020). Pittsburgh, PA: Software Engineering Institute, 2004.

[SLMLC 05]
The Service Level Management Learning Community.

[Stevens 03]
Stevens, M. "Service-Oriented Architecture Introduction." 2004.

About the Authors

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.