NEWS AT SEI
This library item is related to the following area(s) of work:Service-Oriented Architecture
This article was originally published in News at SEI on: January 1, 2005
A previous column described the role of service-oriented architectures (SOAs) in a modern information technology environment. With the advent of universal Internet availability, many organizations have leveraged the value of their legacy systems by exposing all or parts of them 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 [Lewis 05]. A collection of services with well-defined interfaces and shared communications model is called a service-oriented architecture (SOA). A system or application is designed and implemented using functionality from these services. The characteristics of SOAs (e.g., loose coupling, published interfaces, standard communication model) offer the promise of enabling existing legacy systems to expose their functionality as services, presumably without making significant changes to the legacy systems.
However, constructing services from existing systems to obtain the benefits of an SOA is neither easy nor automatic. There are no effective published strategies for building end-to-end systems1 based on SOAs; there are no approaches for understanding end-to-end quality of service (QoS); the technologies that SOAs are based on are still immature, and it is not clear what works and what does not work [Ma 05, Manes 05]. This column distinguishes three different perspectives that should be addressed in developing an effective SOA or in developing a component of an SOA-based system. For each perspective, it identifies the issues, tasks, and risks and outlines a set of research issues.
The three different development perspectives are illustrated in Figure 1.
The focus, tasks, and risks that must be addressed by each perspective are outlined in the following sections.
Developers of SOA infrastructure or middleware must provide a stable infrastructure for the discovery and invocation of services. Specific challenges include
Based on these challenges, the tasks for infrastructure developers are
Infrastructure developers face some risks:
Developers of applications that use services must either discover and connect to services statically at design time or build the applications so that services can be located and invoked dynamically at run time. The semantics of the information being exchanged are always a challenge, as is the question of what to do when a service is no longer available in the case of static binding. Specific challenges for application developers include
Tasks for developers of applications that use services include
Application developers, therefore, face these risks:
Developers of services must describe and develop services that applications can easily locate and use with acceptable QoS. If there are existing systems that can provide service functionality, developers must focus on the development of proper interfaces, the extraction of information from the systems, and the wrapping of this information according to the requirements of the SOA infrastructure. If services are non-existent, developers must focus on the service-specific code that must be written or reused from legacy systems. In this case, there are additional issues of service initialization. If code is reused, developers must analyze the feasibility of migration from legacy to target. Specific challenges for service providers include
Tasks for service developers, therefore, include
Risks faced by service providers are these:
In a system-of-systems (SoS) context, it is common for these three types of components to be developed independently by separate organizations. This, in fact, is the idea behind SOAs: loose coupling and separation of concerns. Nonetheless, decisions made locally by any one of these development groups can have an effect on the other groups and can potentially have a global effect on the SoS:
Most literature and analyses related to SOAs focus on only one of the development perspectives and tend to assume an ideal environment in which there are no conflicts among the three perspectives. The SEI is beginning to develop a research agenda to examine each of the perspectives—application developer, infrastructure developer, and service provider—and to answer questions such as how to select the appropriate services and infrastructure for the organization's system goals, how to determine the QoS delivered by a system when some of its components are discovered and composed at runtime, and how to build services that can be used in a wide range of applications. All of these three perspectives require awareness of the needs and challenges of the others so they can contribute overall to the quality of the SOA-based system. Addressing these issues can ultimately lead to a disciplined approach to building end-to-end systems based on SOAs. Such an approach must focus on an interrelated set of critical issues, including
Lewis, Grace and Wrage, Lutz. Approaches to Constructive Interoperability (CMU/SEI-2004-TR-020). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2005.
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 more than 15 years of experience in software engineering. She is also a member of the technical faculty for the Master's in Software Engineering program at CMU.
Dennis Smith is the lead for the SEI Integration of Software Intensive Systems (ISIS) Initiative. 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. 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. 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 MA and PhD from Princeton University, and a BA 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.