Three Perspectives Required of Service-Oriented Architectures



Grace Lewis

Dennis B. Smith

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.

Development Perspectives in SOAs

The three different development perspectives are illustrated in Figure 1.

  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.
  2. 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.
  3. 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

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


[Lewis 05]
Lewis, Grace and Wrage, Lutz. Approaches to Constructive Interoperability (CMU/SEI-2004-TR-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.

Find Us Here

Find us on Youtube  Find us on LinkedIn  Find us on twitter  Find us on Facebook

Share This Page

Share on Facebook  Send to your Twitter page  Save to  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

For more information

Contact Us


Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.