columns
eye on integration
Three Perspectives Required of Service-Oriented
Architectures
Introduction
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.
Development Perspectives in SOAs
The three different development perspectives are illustrated in Figure 1.
- Middleware or infrastructure providers (shown in the middle level of
Figure 1) must identify the network and communications protocols and standards
to be employed. They must also determine what additional SOA infrastructure
capabilities are necessary and provide them as common services (e.g., service
registry, service-orchestration mechanisms). Infrastructure providers must
allow the discovery of services and the data exchange between application
and services.
- Application developers (shown at the top level of Figure 1) must locate
or select appropriate services to be used by the application and develop
application-specific code to invoke the selected services. They are concerned
with whether services invoked by the application meet a full range of capability,
QoS, and efficiency-of-use expectations.
- Service providers (shown at the bottom level of Figure 1) must identify a needed service, identify legacy code that potentially can satisfy the needed service, develop the appropriate interfaces, and finally modify the legacy code and/or develop new code to provide the service so that it has useful capability to the widest range of applications possible.
Figure 1: High-Level View of an SOA
The focus, tasks, and risks that must be addressed by each perspective are outlined in the following sections.
1. Middleware or Infrastructure Providers
Developers of SOA infrastructure or middleware must provide a stable infrastructure for the discovery and invocation of services. Specific challenges include
- development of a set of common infrastructure services for discovery, communication, security, etc.
- identification and development of binding mechanisms to satisfy the largest set of potential service users
Based on these challenges, the tasks for infrastructure developers are
- development of a set of common infrastructure services for discovery, communication, security, etc.
- provision of tools for application and service developers
Infrastructure developers face some risks:
- Constraints of the infrastructure may limit the availability of services and applications that use it.
- The effort for development, support, and training for the use of tools and infrastructure may be underestimated.
- Delays in schedule will affect the schedule of applications and services that depend on the infrastructure.
- Changes in the infrastructure will affect the applications and services that use it.
2. Application Developers
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
- identification of the right services
- understanding of the semantics of the information being exchanged
- determination of rules to follow when services are no longer available (in the case of static binding)
- creation of an architecture that is stable enough to accommodate changes in services that are often outside of the control of the organization
Tasks for developers of applications that use services include
- understanding the SOA infrastructure: bindings, messaging technologies, communication protocols, service-description languages, and discovery services
- discovering services to be incorporated into applications2
- retrieving service-description documentation—description, parameters, bindings, transport protocol
- invoking the identified services in applications
- composition
- service request
- error handling
- availability handling
Application developers, therefore, face these risks:
- Available services might not meet functional and non-functional application requirements.
- Services may change or disappear without notification.
- With proprietary SOAs, there might be dependencies on tools and programs provided by the infrastructure developers that require training and that may conflict with the development and deployment environments.
3. Service Providers
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
- mapping of service requirements to component capabilities, often having to anticipate requirements because the complete set of potential service users is not known
- description and granularity of services with acceptable QoS
- development of new service-specific code and wrappers to existing code
- determination of migration feasibility of potential services from legacy applications, if required
Tasks for service developers, therefore, include
- gathering requirements from potential service users: Who would use the services and how would they use them?
- understanding the SOA infrastructure: bindings, messaging technologies, communication protocols, service-description languages, and discovery services
- developing code that receives the service request, translates it into calls into existing systems, and produces a response
- describing and publishing the service
- developing service-initialization code and operational procedures
Risks faced by service providers are these:
- Developed services may not be used because they do not meet functional and/or non-functional requirements.
- The effort to translate legacy data types into data types that are allowed by the SOA infrastructure can be greater than expected, especially in the case of complex data types such as audio, video, and graphics.
- If dealing with proprietary SOAs,
- there may be multiple constraints imposed on developed services; and
- there might be dependencies on tools and programs provided by the infrastructure developers that require training and that may conflict with the development and deployment environments.
Why End-to-End SOA Engineering is Important
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:
- The granularity of service interfaces can affect the end-to-end performance of an SoS because services are executed across a network 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.
- If developers of the SOA infrastructure offer only an asynchronous communication mechanism, system developers requiring high performance and availability will encounter problems.
- If service developers do not gather functionality and QoS needs from potential users of services, they might develop and deploy services that are never used.
- If service interfaces are constantly changing and there is no formal mechanism for communicating these changes, users of the SOA-based system might find that certain system functionality is no longer available because the system was not able to anticipate and accommodate these changes.
Conclusions and Next Steps
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
- QoS in a system where service discovery, composition, and invocation play a major role
- insights on paths and limitations of technologies that enable SOAs
- understanding critical functional and QoS needs of potential users of services
- service-level agreements in a dynamic environment
References
[Lewis 05]
Lewis, Grace and Wrage, Lutz. Approaches
to Constructive Interoperability (CMU/SEI-2004-TR-020 ESC-TR-2004-020).
Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University,
2005.
[Ma 05]
Ma, Kevin. "Web Services: What's Real and What's Not." IT
Professional 7, 2 (March-April 2005).
[Manes 05]
Manes, Anne. VantagePoint 2005-2006 SOA Reality Check. Midvale,
UT: Burton Group, 2005.
1 By end-to-end, we mean the complete pathway through applications, the communication infrastructure and network, and the actual services to perform a specific task.
2 Dynamic discovery, composition, and invocation are still extremely limited with existing technologies.
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 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.