Service-Oriented Architecture and its Implications for Software Maintenance and Evolution

Transcription

1 Service-Oriented Architecture and its Implications for Software Maintenance and Evolution Grace A. Lewis, Dennis B. Smith Software Engineering Institute {glewis, Abstract It is clear that Service-Oriented Architecture (SOA) is having a substantial impact on the way software systems are developed. According to a 2007 Gartner Group report, 50% of new mission-critical operational applications and business processes were designed in 2007 around SOA, and that number will be more than 80% by This means that as service-oriented systems are deployed and legacy systems are migrated to this environment, a main concern is now their maintenance and evolution. This paper provides an overview of SOA concepts, best practices for implementation of service-oriented systems, the implications that SOA environments have on software maintenance and evolution activities, and finally some research challenges for the software maintenance and evolution research community. 1. Introduction Service-Oriented Architecture (SOA) is a way of designing, developing, deploying and managing systems characterized by coarse-grained services that represent reusable business functionality and service consumers that compose applications or systems using the functionality provided by these services through standard interfaces. Benefits commonly associated to SOA adoption are cost-efficiency, business agility, adaptability and leverage of legacy systems. There are many successful case studies of SOA adoption, mainly in commercial enterprises, where the main goal for SOA implementation is internal integration and business process improvement. There are also multiple studies, such as the InfoWorld SOA Trend Survey, that state that main SOA adoption barriers are lack of governance and finding people with the right skills [1]. The reality is that SOA is currently the best option available for systems integration and leverage of legacy systems. According to a 2007 Gartner Group report, 50% of new mission-critical operational applications and business processes were designed in 2007 around SOA, and that number will be more than 80% by The technologies to implement SOA will most probably change over time, but the concepts will remain. This means that from a maintenance and evolution perspective there are two concerns: (1) deployed service-oriented systems will have to be maintained and evolved and (2) legacy systems will migrate to SOA environments to make their legacy functionality available to other systems and applications. This paper will first present some basic concepts related to SOA, including high-level components of service-oriented systems. It will then present the four pillars of service-oriented systems development as a set of best practices for systems development in SOA environments. Finally, it will present the implications of SOA adoption for maintenance and evolution activities and some research challenges in this area. 2. SOA Basics At a high level, SOA is a way of designing, developing, deploying and managing systems, in which Services provide reusable business functionality. Applications or other service consumers are built using functionality from available services. Service interface definitions are first-class artifacts. A SOA infrastructure enables discovery, composition, and invocation of services. Protocols are predominantly, but not exclusively, message-based document exchanges. From a more technical point of view, SOA is an architectural style or design paradigm it is neither a system architecture nor a complete system. As any architectural style, it is characterized by a set of components and connectors, situations when the style is applicable, and benefits associated with /08/$ IEEE 1 FoSM 2008

2 implementing the style. The following subsections will cover these aspects Major Components of Service-Oriented Systems At a very high level, as shown in Figure 1, there are three major components of service-oriented systems: services, service consumers and SOA infrastructure. Services: reusable components that represent business tasks, such as customer lookup, weather, account lookup, or credit card validation. Services can be globally distributed across organizations and reconfigured to support new business processes. They are reusable because they can be used by a number of business processes. They usually provide coarse-grained functionality, such as customer lookup, as opposed to finer-grained functionality such as customer address lookup. A distinguishing factor of this architectural style is that service interface definitions are standardized, well-defined, first-class artifacts, ideally available in a service registry so that services can be discovered by service consumers. Service interfaces are separate from service implementation, which makes services platform-independent as long as service consumers can access the service interfaces, service implementation is irrelevant to the service consumer. Service Consumers: These are clients for the functionality provided by the services. Some examples of service consumers are end-user applications, portals, internal and external systems, or even other services in the context of composite services. In a typical business setting, an order processing application may use services such as customer lookup, credit check, and item lookup that are derived from a number of sources inside and outside the enterprise. Service consumers programmatically bind to services, making it a machine-to-machine interaction. SOA Infrastructure: The infrastructure connects service consumers to services. It usually implements a loosely coupled, synchronous or asynchronous, message-based communication model, but other mechanisms are possible such as publish/subscribe or CORBA. The infrastructure often contains elements to support service discovery, security, data transformation and other operations. A common SOA infrastructure is an Enterprise Service Bus (ESB) to support Web Service environments. Figure 1. High-level representation of a serviceoriented system 2.2. Basic Operations to Support Service Oriented Systems There are three main operations that need to be supported in service-oriented systems to obtain the greater benefits of this approach: service discovery, service composition, and service invocation. Service discovery: In a service-oriented environment, service providers place information about their services in a service registry and service consumers query this registry for services with desired characteristics. The complexity of a service registry varies from a simple directory of services categorized by type to a more complex registry where services are categorized according to a predefined ontology, with quality of service (QoS) information in addition to binding information. A service registry contains basic information about available services, such as description, specification (contract), documentation; and should include additional information such as classification, usage history, test results, and performance metrics. Challenges of supporting service discovery are the proper description of services and the maintenance of the service registry. Service composition: Applications and other service consumers compose functionality provided by services to fulfill their goals. A challenge for service consumers is often the conversion of service inputs and outputs as services are combined. Another challenge, and a major area of research, is the guarantee of QoS properties such as performance, security, or properties that are common in distributed systems such as the support for transactions, especially when services are distributed across multiple organizations [2, 3]. There are languages such as the Business Process Execution Language (BPEL) that support the orchestration of services in a Web Services environment [4]. 2

3 Service invocation: Services are invoked by service consumers and the corresponding service implementation code is executed. There are two common patterns for service invocation o a simple invocation pattern where service consumers directly invoke services over a network, typically via synchronous, direct, request-reply connections o a richer invocation pattern where service consumers invoke services via a middleware component that supports SOA environments, such as an Enterprise Service Bus (ESB) [5] A challenge for service consumers is dealing with service availability and having robust exception handling in the event that services are no longer available Common Benefits Associated with SOA Adoption As indicated earlier, common benefits of SOA adoption are cost-efficiency, business agility, adaptability and leverage of legacy systems. Cost-Efficiency: This benefit is associated with the elimination of redundancy, which is common to find in traditional stove-piped system environments. For example, three applications may have their own customer lookup functionality. A service with equivalent functionality can be implemented and used by all three applications. This translates into cost-efficiency because there is a single point of maintenance and the service can now be used by other applications that require this functionality without any additional development. Business agility: This benefit is associated with being able to quickly assemble new functionality from existing services, as illustrated by the example of an Order Processing application that uses a set of services to implement part of its functionality. If the organization decides to go into the education business, a series of services already used by the Order Processing application would be available, such as Customer Lookup and Credit Check. The organization could move more quickly into its new line of business and the new services created specifically to support the education line of business, such as Room Reservation, could also be used by other applications. Adaptability: This benefit is associated with the adaptation of systems to changing needs and technologies. Because in a SOA environment services are accessed by applications in a standard way through the selected SOA infrastructure, as long as the interface remains stable, the logic and technologies supporting the services can change as needed and not have an effect on existing service consumers. Leverage of legacy systems: SOA is an attractive option to expose functionality in legacy systems. By allowing access to the legacy system through a standard service interface, the details of connecting to the legacy system are the responsibility of the SOA infrastructure and the service interface and not of the applications. As a result, the legacy platform diversity is hidden from service consumers. This also makes it attractive for incremental migration, where legacy systems are replaced incrementally without an effect on service consumers Web Services The most common approach to SOA implementation is Web Services. The reason is because Web Services rely on a set of accepted and widespread standards that include HTTP, SOAP, and WSDL, and that there is a large group of vendors providing products and tools to support development in this environment. However, service-oriented systems can be implemented using other technologies such as message-oriented middleware (MOM) (e.g. IBM Websphere MQ), publish-subscribe technologies (e.g. Java Messaging Service (JMS)), and Common Object Request Broker Architecture (CORBA). The Web Service protocol stack is presented in Figure 2. At a very high level: In the base stack, service interfaces are described using Web Services Description Language (WSDL), and XML payload is transmitted using Simple Object Access Protocol (SOAP) over Hypertext Transfer Protocol (HTTP). These basic infrastructure standards that support the exchange of messages between service consumer and provider are the most developed and mature of the Web Service standards. To support discovery, there is a specification for the implementation of directory services called Universal Description, Discovery and Integration (UDDI). However, this specification has not received much support from industry and therefore many products implement directory services using their own proprietary APIs. The terms orchestration and choreography refer to the composition of processes from existing services. The difference between the two terms is that orchestration deals with the internals of the processes while choreography describes the service interactions from the perspective of an 3

4 external observer, seeing only what is happening at the services interfaces [6]. At this level of the stack there are multiple standards and specifications. However, the specification that has the greatest industry support at this moment is Business Process Execution Language (BPEL) which specifies business processes in a Web Service context [4]. At the right hand of the stack there are crosscutting issues that need to be addressed at all levels of the stack. In this area the amount of specifications for Web Services is so large that there is confusion as to which are important, when and why. The degree of maturity, industry acceptance and implementation varies, adding to the complexity. Examples of specifications in this area are WS-Security, WS-Reliability, WS- Management and WS-Transaction. Figure 2. Web Services protocol stack Figure 2 corresponds to what is known as the WS* implementation of Web Services. Another implementation approach for Web Services that is gaining popularity is that of RESTful Web Services [7]. REST (REpresentational State Transfer) is an architectural style that represents a more lightweight implementation of Web Services, based on the definition of resources that provide the same interfaces, as defined by HTTP. Each implementation has its advantages and disadvantages and there are situations where the use of one over the other is more appropriate [8]. 3. The Four Pillars of Service-Oriented Systems Development SOA is more than just an architectural style. It is a way of developing systems, it requires a change of mindset, and it requires alignment with business goals and processes to be of value. What follows is a set of best practices that we have termed the four pillars. These pillars do not guarantee successful implementation of service-oriented systems, but most success stories show that if they are not acknowledged and addressed, the chances of success are limited Strategic Alignment Any successful SOA strategy has to be aligned with business goals. At a minimum, a SOA strategy includes Evidence of fulfillment of critical business goals this part is crucial because SOA adoption may not even make sense for the organization if critical business goals are not addressed Alignment with organizational enterprise architecture and current and future IT infrastructure Realistic choices of technologies and infrastructures Realistic and gradual adoption strategy Adequate SOA governance structure (the next pillar) Priorities for implementation Reuse strategy across internal and external organizations SOA provides the potential of enabling greater cost-efficiency, agility, adaptability, leverage of legacy investments, and interoperability between systems and organizations. However, if the wrong strategy is selected, it can result in an expensive collection of random services that are never used. Table 1 shows some examples of how different business needs and goals lead to different SOA strategies. Another part of SOA strategy is service identification and prioritization. At a very high-level, a good approach to service identification to fulfill business goals is: 1. Business processes to support business goals are identified. 2. Candidate services are identified in a top-down and bottom-up approach. Top-Down: Shared steps between business processes are identified as service candidates. Bottom-Up: Legacy system inventory is performed. Systems with functionality to support business processes are identified as migration candidates. 3. Services are selected based on relationship to business goals, using any consistent grading scheme designed by the organization. 4

5 Table 1. Examples of SOA Strategies Business Needs Focus of SOA Strategy and Goals Increase Easy-to-use and customizable information portal available to Services that provide information customers of interest for customers Integrate business partners Improve internal business processes Infrastructure to support integration with business partners potentially running on different computing platforms Back office integration Identification of business rules Identification of key business processes Elimination of redundancy Services that access legacy systems Finally, SOA implementation needs to be disciplined. A SOA implementation can start with a big bang approach that attempts to get SOA implemented at once throughout an enterprise. However, it is more prudent to begin with a pilot project that will provide a proof of concept. Pilot projects should focus on areas that provide high impact and visibility with the lowest risk. Gradual implementation can then lead to other projects that integrate a single organizational unit, to projects that integrate multiple business units, and later to largescale efforts that provide a virtual enterprise where all applications are built based on services [9] SOA Governance Governance has been rated as the main inhibitor of SOA adoption [1]. SOA governance provides a set of policies, rules, and enforcement mechanisms for developing, using and evolving service-oriented systems, and for analysis of their business value. SOA governance includes policies, procedures, roles and responsibilities for design-time governance and runtime governance. Design-time governance includes elements such as rules for strategic identification of services, development, and deployment of services; reuse; and legacy system migration to services. It also enforces consistency in use of standards, SOA infrastructure and processes. Runtime governance develops and enforces rules to ensure that services are executed only in ways that are legal and that important runtime data is logged. Runtime governance procedures address consistent approaches to concerns such as 1) access to applications and data, 2) the replacement of services, and 3) interactions with the SOA infrastructure. Service level agreements (SLAs) also fall under runtime governance. SLAs can include runtime validation of contractual specifications on performance, throughput, and availability; the use of automated metrics for tracking and reporting; and problem management. A well-defined governance model needs to answer questions such as: What is the process for determining what services to create? What is the process for evolving and changing services if there are many consumers of the service? Who "owns" and is responsible for shared services if they are distributed across several lines of business? What is the resolution mechanism if there are conflicting requirements or change requests for shared services? What mechanisms, tools and policies are used for maintaining and monitoring deployed services? How are enterprise-wide policies enforced across various services both internal as well as external to the organization? How are service level agreements (SLA) defined and enforced between service consumers and providers? 3.3. Contextual Technology Evaluation Because a SOA implementation may use a number of technologies in novel contexts, it is important to evaluate whether a specific set of technologies is appropriate for the task at hand. This pillar requires determining the fitness of a technology within a specific context, before making a long term commitment to it. In service-oriented systems, a number of different technologies, standards and tools may be part of an implementation. Examples of these different technologies are specific Web Service standards, versions and tool implementations; custom SOA infrastructures; enterprise service buses (ESBs); interfaces to specific databases; and service bindings. All technologies work well within a specific context and under certain conditions. For example, Web Services work well for asynchronous communication over the Internet. In a business environment these conditions are very common, but in a military tactical command and control environment this might not be the case because of high performance and availability requirements. 5

6 One way to perform contextual technology evaluation is through T-Checks [6, 10, 11, 12, 13]. The T-Check process consists of the following steps: Identify technology requirements and context. Determine and document why the organization wishes to conduct the evaluation, what the expectations and concerns are with respect to the technology capabilities, and what is the context in which the technology plans on being used. Determine the environment in which the evaluation will take place, including expectations and constraints of the technology, and measures of success. Develop hypotheses that are derived from the expectations placed on the technology. Hypotheses are claims about the technologies that are to be sustained or refuted. Develop criteria to determine if the results sustain or refute a hypothesis. Criteria are stated as a clearly measurable statement of capability. Each hypothesis can have one or more criteria, depending on the breadth covered by the hypothesis. Design and implement an experimental solution composed by the simplest set of applications and/or components that are able to answer the questions posed by the hypotheses and associated criteria, within the identified scenario (s). The experimental solution is implemented, run, and observed, until there is enough information to sustain or refute the set of hypotheses. Evaluate solution against criteria in order to make a decision with respect to the fitness of the technology for the context in which it is intended to be used. Based on the results of the evaluation there should enough information to decide if: o The technology is a good fit with requirements. o The technology is not a good fit with requirements. o The technology has some mismatches that could potentially be solved by modifying the context or modifying the technology itself. o Additional issues about the technology have appeared that trigger a new set of hypotheses and therefore require another iteration of the T- Check process. o An alternate technology has been identified during the process that requires another T- Check Change of Mindset There are a unique set of challenges in building service-oriented systems and with them comes a development approach that deals with the characteristics of these systems. Although it is difficult to generalize, some of the differences between serviceoriented systems and traditional systems are presented in Table 2. Table 2. Some Differences between Traditional and Service-Oriented Systems Traditional Systems Service-Oriented Systems Tight coupling between Loose coupling between system components service consumers and Semantics shared explicitly at design time Known set of users and usage patterns System components owned by the same organization services Semantics shared without much communication between developers of consumers and services Potentially unknown set of users and usage patterns Systems components potentially owned by multiple organizations The differences listed in Table 2 have to be addressed by the processes used in the development of service-oriented systems. Some generic characteristics of development processes to be used in SOA environments include: Development processes need to include activities to ensure alignment with an organization s business goals and business processes to get the most out of SOA adoption. Agility to respond to changing demand in a serviceoriented system is not a given and must be engineered through careful analysis of the appropriate granularity for services and by establishing the variety of services that are necessary to support the range of potential uses or scenarios. Incorporation of business process management (BPM) activities can help in this area. Development of service-oriented systems is a continuous activity services are usually deployed in an incremental fashion. Therefore, development processes should be iterative, closely tied with business processes, with short iterations, in order to provide the business agility that is expected of SOA adoption. Governance processes must be incorporated in the full life cycle, with emphasis on those areas that are expected to be problematic for the organization due to internal policies, choices of technology, or organizational structures, among others. For example processes related to service identification, publication in registries, and deployment have to be 6

7 more carefully specified in organizations where service development is carried out by multiple groups. Governance automation will make it easier for users of the SOA environment to comply. Also, different governance processes may be necessary for integration with internal services and with external services. Processes should be targeted at service providers, infrastructure providers, or service consumers. The more aligned these processes are, the better. Technology evaluation becomes an integral part of almost all life cycle activities, especially architecture and design. All lifecycle activities have to include tasks to make sure that runtime monitoring of service-oriented systems is possible, also in support of the strategic approach to service-oriented systems development and the dynamic nature of such systems. What follows are some examples of changes for specific life cycle activities, derived from the previous statements about development processes in SOA environments [15]. During requirements, it is important to have close ties to BPM activities to strengthen the tie between business goals and system implementation. In addition, there is the need for service providers to anticipate potential service requirements from unknown consumers, similar to the way commercial off-the-shelf (COTS) product vendors work. During architecture and design, it is important to have technology evaluations and to perform explicit tradeoff analyses. The characteristics of SOA as an architectural style, as well as the characteristics of the technology selection for SOA implementation, will tend to favor some system qualities over others [14]. Implementation of service-oriented systems suffers from the same problems of any type of distributed system development: what works well in a controlled and constrained development environment does not usually work once deployed in the production environment. This problem is amplified in service-oriented systems due to the greater number of standards and products that are needed to support the execution of the system, some of which are still emerging. Implementation activities need to account for access to the production environment or a simulation of it in case it is not accessible. End-to-end testing of a service consumer requires all services, or test instances of them, to be available. This leads to the following implications, from a service consumer perspective: (1) Services are black boxes and should be tested as such, especially if these are external services, and (2) the use of dynamic analysis and testing techniques becomes increasingly important, and (3) because services could become unavailable, or even disappear without notification, greater and more diverse exception handling is required. The next section will focus on the implications of SOA for maintenance and evolution activities. 4. Some Implications of SOA for Maintenance and Evolution Activities Given that SOA adoption is fairly recent, much of current research has focused on the earlier stages of the life cycle. The increasing SOA adoption rate cited earlier will have a substantial impact on maintenance and evolution because (1) deployed service-oriented systems will have to be maintained and evolved and (2) legacy systems will increasingly migrate to SOA environments to make legacy functionality available. As mentioned earlier, service-oriented systems are significantly different from traditional systems, resulting in new issues that need to be addressed that affect maintenance and evolution activities. These differences include: 1) the diversity of service consumers and service providers, 2) shorter release cycles because of the capability of rapidly adapting to changing business needs, and 3) the potential to leverage legacy investments with potentially minimal change to existing systems. An important question is therefore: What does maintenance and evolution look like in this dynamic, heterogeneous and potentially distributed development and maintenance environment? 4.1. Maintenance Processes The complexity of maintenance processes in a SOA environment increases, especially if there are external service consumers and providers involved. Impact analysis activities for service providers have to consider a potentially unknown set of users, unless there are mechanisms for tracking service consumers in the SOA infrastructure. Impact analysis for service implementation code has to consider direct users of the service implementation code, as well as users of the system through service interfaces. Configuration management also becomes more complex, starting from the decision of what to put under configuration management: service 7

8 interfaces, service test instances, configuration files, infrastructure services, business processes, etc. Release cycles between services and consumers, services and infrastructure, and consumers and infrastructure ideally should be coordinated, but may not be possible when these are external. Another aspect that makes maintenance challenging in this environment is that services are shared among multiple business processes or consumers. Processes need to be in place to provide the answers for the following questions, and these processes should become part of SOA governance. Who is responsible for the maintenance of a shared service? What happens when multiple business units have different requirements for the same service? How is a service evolved in the context of the multiple business processes that use it? 4.2. Platform Independence: A Blessing and a Curse One of the benefits associated with SOA, and especially Web Services, is true platform independence. What this means is that even though standard interfaces are exposed, the underlying service implementation could be written in any language. While this is a huge benefit, it makes looking at the system as a whole difficult, especially with current program analysis tools that tend to work for a single programming language. What this means from a maintenance and evolution perspective is that the detail of the documentation of service interfaces has to be such as to infer service behavior just from documentation. Even though it does not replace program analysis, it will help in maintenance activities, especially in cases where maintainers are not familiar with all programming languages used by service implementation code or in the case of third-party services where all that is available is the service interface definition. Examples of documentation elements for service interfaces are pre-conditions, post-conditions, and behavior expressed in pseudo-code or more formal languages such as OCL (Object Constraint Language) Reengineering Processes Because it has characteristics of loose coupling, published interfaces, and a standard communication model, SOA enables legacy systems to expose their functionality as services, presumably without making significant changes to the legacy systems. Migration of legacy components to services has been achieved within a number of domains, including banking, electronic payment, and development tools, showing that the promise is beginning to be fulfilled. While migration can have significant value, any specific migration requires a concrete analysis of the feasibility, risk and cost involved. The strategic identification and extraction of services from legacy code is crucial as well. The ideal reengineering process would be one that focuses on a full-circle model, such as the "SOA- Migration Horseshoe" proposed by Winter and Ziemann [16]. This approach integrates software reengineering techniques with business process modeling and recommends applying reverse engineering techniques to extract a Legacy Enterprise Model from the legacy code. Then, applying enterprise modeling techniques to create a Consolidated Enterprise Model from which services are identified using forward engineering techniques. Finally, legacy code is mapped to services via wrapping or transformation. 5. Research Challenges in Maintenance and Evolution of Service-Oriented Systems The implications of SOA adoption just described trigger the need for research in areas related to the maintenance and evolution of service-oriented systems. Some of these research topics have been described as part of a Research Agenda for SOA [17]. Tools, Techniques and Environments to Support Maintenance Activities in SOA Environments. The development of specialized methods and tools to support the maintenance and evolution of large serviceoriented systems is in the early stages. Current efforts in this area seem to indicate that maintenance activities for service-oriented systems are not that different than in traditional systems. However, we are still in the stage where most service-oriented systems are deployed for internal integration, where there is still some control over deployed services. Also, the emergence of the market for third-party services and the deployment of more service-oriented systems that cross organizational boundaries will have to change current maintenance practices. From an engineering perspective, processes to support the incremental evolution of service-oriented systems, configuration management, impact analysis and versioning in this environment are challenges. From a business perspective, the organizational structures and roles to support maintenance of service-oriented systems as well as models to support the development and 8

9 maintenance of shared services are areas of needed research. Multilanguage System Analysis and Maintenance. Most research in this area is limited to small size projects and a small number of languages, which is a problem for an environment that promotes platform independence. In the case of third-party service providers, access to source code is most probably not possible. If that is the case, an important area of research is the identification of the type of information that service providers would need to expose to service consumers in interfaces or service registries/repositories that wish to do code analysis, as well as tools to support the process. Reengineering Processes for Migration to SOA Environments. As mentioned earlier, the ideal reengineering process would be one that implements the SOA-Migration Horseshoe. The problem is that there are currently techniques and tools that implement portions of the horseshoe but not the full horseshoe. An important area of research would be the development of concrete processes that implement the horseshoe and tools (or suites of tools) to support the process. The automation of this process would be a very complex task that worth investigating. Also, as stated by most of the people doing work in this area, the real challenge is mining legacy code for services that have business value. Research topics in this area include (1) tools and techniques for analyzing large source code bases to discover code that is of business value, (2) metrics for "wrapability" and business value to determine reusability, and (3) application of feature extraction techniques to service identification, given that services usually correspond to features [18]. Evolution Patterns of Service-Oriented Systems. There have been multiple studies over the years of how systems evolve over time. The purpose of these studies is usually to prepare maintenance organizations to do a better job, by identifying portions of the system that are stable, portions that are prone to change, as well as the forces that drive change. An important area of research could be the identification of evolution aspects that are specific to service-oriented systems or patterns of evolution that could help build systems that are more resilient to change, given that change is the norm in this type of environment. This work could also lead to metrics to determine resiliency to change. 6. Conclusions Service-Oriented Architecture (SOA) is a way of designing, developing, deploying and managing systems characterized by coarse-grained services that represent reusable business functionality and service consumers that compose applications or systems using the functionality provided by these services through standard interfaces. Organizations are increasingly moving to SOA environments to realize benefits such as cost-efficiency, business agility, adaptability and leverage of legacy systems. However, the benefits of SOA adoption, although real, are not automatic. Organizations need to align business strategy and SOA strategy, establish SOA governance processes, and perform contextual technology evaluation of technologies of choice for their SOA implementation to realize these benefits. Most importantly, organizations need to recognize that SOA adoption requires a change of mindset that needs to be reflected in the full life cycle of service-oriented systems. Maintenance and evolution activities will have to evolve and adapt to support this dynamic and changing environment, taking into consideration the emergence of third-party services over which there is less control and visibility. Tools and techniques to support maintenance and evolution activities in these environments, reengineering processes that combine business as well as technical aspects, and capabilities for multi-language analysis are a good starting point. 7. References [1] InfoWorld, InfoWorld Research Report: Service Oriented Architecture (SOA), April [2] D. Menascé, QoS Issues in Web Services, IEEE Internet Computing, November - December 2002, pp [3] B. Lieberman, SOA Transaction Management, IBM developerworks, May 2006, lieberman/index.html [4] Organization for the Advancement of Structured Information Standards, Web Services Business Process Execution Language Version 2.0, 2007, [5] D. Chappell, Enterprise Service Bus, O Reilly, June [6] F. Hueppi, L. Wrage, and G. Lewis, T-Check in Technologies for Interoperability: Business Process Management in a Web Services Context, CMU/SEI TN-005, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, June [7] R. Fielding and R. Taylor, Principled Design of the Modern Web Architecture, ACM Transactions on Internet Technology (TOIT), Association for Computing Machinery, New York, Vol. 2, No. 2, May 2002, pp

10 [8] B. Spies, Web Services, Part 1: SOAP vs. REST, Ajaxonomy, May 2008, soap-vs-rest [9] Schulte, R. Meeting the Challenges of SOA Adoption, Keynote at the SOA in Action Virtual Conference, November [10] G. Lewis and L. Wrage, A Process for Context-Based Technology Evaluation, CMU/SEI-2005-TN-025, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, June [11] G. Lewis and L. Wrage, Model Problems in Technologies for Interoperability: Web Services, CMU/SEI TN-021, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, September [12] C. Metcalf and G. Lewis, Model Problems in Technologies for Interoperability: OWL Web Ontology Language for Services (OWL-S), CMU/SEI-2006-TN-018, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, April [13] L. Wrage, S. Simanta, G. Lewis, and S. Jaspan, T- Check[SM] in Technologies for Interoperability: Web Services and Security--Single Sign-On, CMU/SEI TN-026, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, January Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, September [15] G. Lewis, E. Morris, S. Simanta, and L. Wrage, Effects of Service-Oriented Architecture on Software Development Lifecycle Activities, Software Process Improvement and Practice, January 2008, pp [16] A. Winter and J. Ziemann, Model-Based Migration to Service-Oriented Architectures, Proceedings of the International Workshop on SOA Maintenance and Evolution (SOAM 2007), 11th European Conference on Software Maintenance and Reengineering (CSMR 2007), Amsterdam, the Netherlands, March 20-23, [17] K. Kontogiannis, G. Lewis, and D. Smith, A Research Agenda for Service-Oriented Architecture: Research Needs for Maintenance and Evolution of Service-Oriented Systems, Proceedings of the 2 nd International Workshop on SOA-Based System Maintenance and Evolution (SOAM 2008), 12th European Conference on Software Maintenance and Reengineering (CSMR 2008), Athens, Greece, April 1-4, [18] H. Sneed, Migrating to Web Services: A Research Framework, Proceedings of the International Workshop on SOA Maintenance and Evolution (SOAM 2007), 11th European Conference on Software Maintenance and Reengineering (CSMR 2007), Amsterdam, the Netherlands, March 20-23, [14] P. Bianco, R. Kotermanski, and P. Merson, Evaluating a Service-Oriented Architecture, CMU/SEI-2007-TR-015, 10