© 2008 carnegie mellon university migration of legacy components to soa environments: some lessons...

© 2008 Carnegie Mellon University

Migration of Legacy Components to SOA Environments:Some Lessons Learned

Scott Tilley

2© 2008 Carnegie Mellon University

Our Goal

Present and discuss

• Basic concepts related to SOA

• Challenges of implementing SOA-based systems

• A technique for determining feasibility and effort required to migrate legacy components to SOA environments (SMART)

• A SOA research agenda

Learn more about

• The NASA Earth Science initiative

• Sensor webs

• How we can help each other

Goal


Agenda

Introduction to SOA

• The 50,000-Foot View

— Basic Concepts

— Common Misconceptions


• Pillars of SOA-Based Systems Development

Challenges of Migration to SOA Environments

SMART (Service Migration and Reuse Technique)

SOA Research Agenda

Conclusions

50,000-Foot View: Basic Concepts


What is SOA?

Service-oriented architecture is a way of designing, developing, deploying, and managing systems, in which

• Services provide reusable business functionality (e.g., customer lookup, credit card validation, hotel reservation).

• Service consumers are built using functionality from available services and bind programmatically to service providers.

• Service interface definitions are first-class artifacts.

• An SOA infrastructure enables discovery, composition, and invocation of services.

• Protocols are predominantly, but not exclusively, message-based document exchanges.



Services and Cost-Efficiency

Order Processing Application

Customer Lookup - 1

Invoicing Application

Customer Lookup - 2

CRM Application

Customer Lookup - 3

Customer Lookup Service

A service with equivalent

functionality can be implemented, and used by all

three applications.



Services and Agility


Customer Lookup Service

Credit Check

Service

Item Lookup Service

Inventory Check

Service

Course Management Application

Room Availability

Service

The new application can use available

services.

New services can be used by

other applications as

well.



Components of an SOA-Based System

End User Application

Service A

SOA Infrastructure

Enterprise Information System

Portal

InternetInternet

External System

Service B

Service C

Service D

Internal Users

DiscoverySecurityDevelopment Tools

Legacy or New Service Code

Internal System

Service Consumers

Infrastructure

Service Implementation

Service Interfaces

External Consumer



Agenda

Introduction to SOA


— Basic Concepts

— Common Misconceptions





SOA Research Agenda

Conclusions

50,000-Foot View: Common Misconceptions


Common Misconceptions 1

SOA Provides the Complete Architecture for a System

SOA is an architectural pattern/style/paradigm and not the architecture of the system itself.

• An architectural pattern provides guidance that embodies best practices

• Any number of systems can be developed (good and bad) based on an architectural pattern

Corollary: SOA cannot be bought off-the shelf.

All Legacy Systems Can Be Easily Integrated into an SOA Environment

Upfront hands-on analysis on the technical feasibility and return-on- investment must be performed to avoid last-minute surprises.

• Is it technically feasible to create a service from the legacy system or part of the system?

• How much would it cost to expose the legacy system as services?

• How much will these changes affect current users and other production systems?

It might just not make sense to migrate the legacy system to an SOA environment.



SOA Is All About Standards and Standards Are All That Is Needed

Comes from misconception that SOA and Web Services are the same.

Most Web Services standards are emerging—subject to multiple interpretations.

The Use of Standards Guarantees Interoperability in an SOA Environment

Interoperability needs agreement on both syntax and semantics.

Web Services enable syntactic interoperability.

• XML Schema defines structure and data types.

• WSDL defines the interfaces: operations, parameters and return values.

Web Services do not guarantee semantic interoperability.

• WSDL does not define the meaning of data or what a service does.

• It is an active research area—unresolved issues.



SOA Is All About Technology

SOA not only means a shift in technology but also changes in the

organizational governance model.

What life-cycle model should be followed for services?

What other governance mechanisms are required?

It Is Very Easy To Develop Applications Based on Services

It is relatively easy to build applications and services that work with a particular

infrastructure . . . but designing a “good” service might not be that easy.

From a service provider perspective

• Not many best practices for designing services (e.g., granularity, QoS)

From a service consumer perspective.

• Ease depends on tool availability for SOA infrastructure.



Testing SOA-Based Systems Is Equal to Testing Other Types of Systems

Testing service consumers, as well as the services themselves, is challenging for various reasons.

For service consumers

• End-to-end testing is only possible when the invoked services (or test instances of them) are available.

• Service consumers will necessarily have to be prepared to deal (or not to deal) with degraded service modes and complete service failure.

• QoS may vary with the load on the network and on the service.

For service providers

• Testing has to be based on anticipated usage patterns and scenarios.

• Testing for satisfaction of service-level agreements (SLAs) is challenging.

• Changes can potentially affect consumers in a negative way.



Everything in an SOA-Based System Has To Be a Service

A service-oriented approach might not make sense for the whole system.

Guidelines for service identification are an important part of SOA strategy and governance.

• Represent reusable tasks

• Have (or may have) multiple consumers

• Permit consumers to bind to services programmatically

• Correspond to functionality of a stateless nature

— Service has no knowledge of previous visits

• Enable service inputs and outputs that do not require the construction of very complex consumers

• Are of a request-response nature

— Although SOA 2.0 supports events

50,000-Foot View: Common Misconceptions


Agenda

Introduction to SOA



— Basic Operations

— Web Services




SOA Research Agenda

Conclusions

5,000-Foot View: Basic Operations


SOA-Based Systems

Order Management

System

Financial System

Organization 1

Organization 2

Credit Card Validation

System

SO

A In

frastru

ctu

re


CRM Application

Shipping System

FedEx

Shipping System

UPS

Shipping System

DHL

Order Placement Application

Customer Organization

Applications can interact with systems

from different

organizations via standard interfaces.

Applications can interact with internal systems via

standard interfaces.

External organizations can access

internal functionality

.

Applications can automate processes using external

functionality.

New applications can be created by reusing existing functionality.

Fire

wa

ll


InternetInternet


Three Basic Operations to Support SOA-Based Systems

Service Discovery

• Services repositories are queried for services with desired characteristics.

• Major Challenges: Service description and repository maintenance

Service Composition

• Applications/service consumers are built by integrating functionality provided by services.

• Major challenges: Process/data mismatch and transaction management

Service Invocation

• Services are invoked and service code is executed.

• Major challenge: Dealing with service availability



DiscoveryDiscovery

Service Invocation

Service Consumer

Service Request

Service Response

1

Service Request

Service Response

2Service Query

Service Location

Service Request

Service Response

3

Service Query

Service Location

Service Query

Service Location

Service

Discovery

Discovery

Service Broker



So What Is Different?

There is nothing conceptually new, but it has brought together existing technologies in a way that works.

• More aligned with business

— Services represent coarse-grained business tasks

• Backed by industry

• Standards-based

• Greater degree of rigor in interface specifications

• Truly loosely-coupled

— No need to install specific components

— Platform-independent

o What is behind the interface is invisible to the consumer



Agenda

Introduction to SOA



— Basic Operations

— Web Services

• Pillars of SOA-Based Development



SOA Research Agenda

Conclusions

5,000-Foot View: Web Services


Web Services

Web Services is one mechanism for implementing an SOA-based system.

• Service interfaces are described using Web Services Description Language (WSDL).

• Data is transmitted using SOAP over HTTP.

• UDDI is optionally used as the directory service.

Because it is the most common mechanism, Web Services is often equated to SOA.



Web Service Protocol Stack

The highlighted standards are the most commonly used.

Most Web service standards are emerging and even competing.

Security, QoS, Transactions, and Management have to be addressed in all layers.



WSDL

Web Services Description Language

XML-based description of

• What a Web Service can do

• Where it resides

• How to invoke it

Supports simple and complex interactions defined by message exchange patterns.



WSDL Document Basic Structure

<?xml version="1.0" encoding="UTF-8"?><definitions

<types>

</types>

<message> </message> <portType> </portType>

<binding>

</binding>

<service>

</service> </definitions>

Data types defined using XML Schema

Messages defined with parameters (based on types)

Location of service

Operations re-defined based on binding mechanisms — Concrete

Operations defined based on messages (in/out) — Abstract



Web Service at Runtime

1. User executes Alice’s application.

3. When Bob’s HTTP server sees a SOAP message it sends it to the SOAP engine.

2. Application builds a SOAP message and sends it to Bob’s service via HTTP.

4. SOAP engine parses the message and constructs the call to Bob’s system.

5. Bob’s system executes the invoked operation.6. Bob’s system returns operation results.

HTTPRequest Call

ReturnHTTPResponse

7. SOAP engine builds response message and returns it via HTTP.

HTTP Server Bob’s SystemUser at Alice’s Application

8. Alice’s application interprets response and displays results to the user.



Agenda

Introduction to SOA



• Pillars of SOA-Based Development



SOA Research Agenda

Conclusions

1,000-Foot View


Pillars of SOA-Based Systems Development

Strateg

ic A

lign

men

t

SOA Design Principles

SOA-Based Systems Development

Tech

no

log

y E

valuatio

n

SO

A

Go

vernan

ce

Ch

ang

e of

Min

dset

Pillars


SOA Governance

Strateg

ic A

lign

men

t



Tech

no

log

y E

valuatio

n

SO

A

Go

vernan

ce

Ch

ang

e of

Min

dset

Pillars: SOA Governance


SOA Governance

SOA governance provides a set of policies, rules, and enforcement mechanisms for developing, using, and evolving SOA assets and for analysis of their business value.

It provides the who, that what and the how decisions business, engineering and operations are made in order to support a SOA strategy.

• Policies and procedures

• Roles and responsibilities

• Design-time governance

• Runtime governance

Can embed compliance with government and industry regulations

• Sarbanes-Oxley, HIPAA, GLBA

Source: Integration and SOA: Concepts, Technologies and Best Practices. Beth Gold-Bernstein & Gary So. Pillars: SOA Governance


Examples of Governance Elements

Governance elements adapted from a presentation by Dr Mohamad Afshar from Oracle Corporation and Ben Moreland from The Hartford at the Business Transformation Conference 2007

Projects

Service OwnershipService LifecycleShared Artifacts

People

Roles & ResponsibilitiesService and Process Owners

Financial

Service Funding ModelService Usage FeesPlatform Funding

Portfolio

ProjectsBusiness ServicesApplications Technology

Strategic SOA PlatformEnforcement Platform DecisionsShared Infrastructure Services

Information

Data OwnershipData StandardsData Quality

Architecture

Reference ArchitecturesArchitectural StandardsBlueprints & Patterns

Operations

Capacity PlanningEnforcement Service LevelsEnforcement PoliciesMetrics Collection

Business

Engineering

Operations



Challenges of SOA Governance

Seems counterintuitive

• If SOA is all about loose coupling and flexibility, why all this central control?

• Goal should be to automate governance as much as possible

Multiple organizations

• How to create governance for service providers, infrastructure providers, and service consumers?

• What if policies conflict?

Dealing with exceptions

• How to record and maintain sometimes necessary exceptions to the rules?

Enforcing compliance

• How to make sure that policies and procedures are being followed at design time and runtime?

• What are the incentives for compliance?



Technology Evaluation

Strateg

ic A

lign

men

t



Tech

no

log

y E

valuatio

n

SO

A

Go

vernan

ce

Ch

ang

e of

Min

dset

Pillars: Technology Evaluation


Match of Technologies to the Problem Domain

Need a realistic understanding on what technologies can do in the specific problem domain

How to understand and keep up with the “alphabet soup”?

• XML, SOAP, WSDL, UDDI, WS-Security?

How to determine which standards and technologies to implement in specific situations?

How to build systems that are resilient to changes in standards and commercial products that implement them?



Greatest Technology Challenge: QoS

How to determine if selected technologies will meet QoS requirements?

• Security

• Availability

• Performance

All the above questions suggest a need for contextual experimentation.



T-CheckSM

Experiment, situated in a specific context, with the goal of providing a “technology sanity check”

The approach

1. Formulate hypotheses about the technology

2. Examine these hypotheses against very specific criteria through experimentation

Extremely efficient

• Focus on implementing the simplest experiment to validate technology claims



T-Check Example 1: Context

Organization migrating from a federated suite of legacy applications and data stores to a solution based on Web services

Establish feasibility of

• Adapting current systems

• Maintaining (or improving) current response time

• Allowing image transfer

• Providing single sign-on



T-Check Example 1: Hypotheses and Criteria

Hypotheses Criteria

75% or more of existing applications can be adapted to Web services.

1. There are SOAP libraries that can be easily linked into 75% of existing applications.

2. If not, there are clear mappings between native data types and XML Schema data types.

Response time will not be degraded due to the use of Web services.

Response times using Web services will be within the same order of magnitude from current response times for representative applications.

Images can be transmitted as part of SOAP messages.

An image can be requested using Web services and viewed on a client application.

It is possible to have single sign-on using Web services.

A user is able to login once and obtain information from three different Web services residing on three different machines.



Agenda

Introduction to SOA



SOA Research Agenda

Conclusions

Legacy System Challenges


Reuse Challenges in the SOA Context

Reuse at the service level is more complex than reuse at the module or component level.

• From the service provider perspective

— Designing reusable services requires a different approach, skill set, and mindset

— Bigger stakeholder community because services are typically reused at organization and sub-organization level

— Services need to be as generic as possible so that they are of interest to multiple service consumers and at the same time need to add value to potential consumers

• From the service consumer perspective

— Larger granularity may lead to larger incompatibilities




It may not always be possible to reuse functionality of legacy systems by exposing them as services.

• Technical constraints due to the nature of the legacy system

— A batch system needs to be exposed as a service for an interactive online Web application.

• Immature technology or lack of technology for a particular legacy environment

Cost of exposing a legacy system as services may be higher than replacing it with a new SOA-based system.



Examples of Challenging Legacy System Characteristics

Poor separation of concerns

• User interface code tightly coupled with business function code

Tool availability

• Target is Web Services; XML and SOAP libraries are not available for all legacy platforms.

Architectural mismatch

• The asynchronous call to the service might be in conflict with legacy system synchronous behavior.

Operational mismatch

• The legacy system is batch-oriented, the service user expects an immediate response.

Dependencies on commercial products

• Licensing issues?



Addressing Legacy System Challenges

Identify relevant and non-relevant legacy components.

• Not all legacy components can be meaningfully reused as services—from a strategic and a technical perspective.

Make decisions based on “hands-on,” contextual analysis.

• System-specific analysis is important because every system is unique.

• Previous analysis and results can be used a guidelines.

Estimate cost, risk, and confidence of estimates of changes required to each legacy component.



Migration to SOA Environments: A Potentially Complex Engineering Task

The characteristics of SOA enable the exposure of legacy system functionality as services.

• Presumably without making significant changes to the legacy systems

The complexity of the migration will largely depend on the characteristics of the SOA environment—some examples:

• User community

• SOA infrastructure technology

• SOA strategy

• Operations

SOA Challenges


User Community

EnterpriseIntranet

Community of InterestHealth Services

Internet with RegistrationAmazon Web Services

InternetPublic Web Services

SmallKnown

LargeUnknown

Moving to the right requires greater effort to understand

• How services will be used

— What is the information expected to be exchanged? In what format?

— What is the right granularity? How generic?

• Scalability and Performance

• Security

• Operational procedures

• Change management

SOA Challenges


SOA Infrastructure Technology

Moving to the right requires greater effort

• Understanding of the target environment requires time

— Bindings, messaging technologies, communication protocols, service description languages, service discovery mechanisms

• Tool availability

• Proprietary SOA-environment constraints

— Platform, use of commercial products, deployment, infrastructure services

Basic Web ServicesWSDL+SOAP+HTTP

Basic + DiscoveryUDDI

Extended Web ServicesComposition, Security

ProprietaryDomain-specific SOA

Standards-Based Proprietary

SOA Challenges


Bottom Line

There are issues to take into consideration that go beyond adding a service interface to an existing system.

SMART is an initial approach to the identification and analysis of issues in migration to services.

Migration Challenges


Agenda

Introduction to SOA



SOA Research Agenda

Conclusions

SMART


SMART Goals

SMART analyzes the viability of reusing legacy components as the basis for services by answering these questions:

• Does it make sense to migrate the legacy system to services?

• What services make sense to develop?

• What components can be mined to derive these services?

• What changes are needed to accomplish the migration?

• What migration strategies are most appropriate?

• What are the preliminary estimates of cost and risk?

SMART: Introduction


Three Elements of SMART

ProcessService Migration

Interview Guide (SMIG)Artifacts

Gathers information about• Goals and expectations of

migration effort

• Candidate services

• Legacy components

• Target SOA environment

Analyzes gap between legacy and target state

Guides discussions in initial SMART activities

• Stakeholder List • Characteristics List • Migration Issues List• Business Process-Service

Mapping• Service Table• Component Table• Notional SOA-Based

System Architecture• Service-Component

Alternatives• Migration Strategy

SMART: Elements


SMART Process Activities

SMART: Process Activities

Establish Migration Context

Describe Existing

Capability

Describe Target SOA

Environment

Analyze the Gap

Develop Migration Strategy

Migration Feasible? No

Define Candidate Services

YesYes


Service Migration Interview Guide (SMIG)

62 categories of questions that gather information about the migration context, the legacy components, the candidate services, and the target SOA environment

SMART: SMIG

The goal is to assure broad and consistent coverage of the factors that influence the cost, effort, and risk in migration to services.

Guides information gathering for the first set of activities

Establish Migration Context

Describe Existing

Capability

Describe Target SOA

Environment

Analyze the Gap

Develop Migration Strategy

Migration Feasible? No

Define Candidate Services

YesYes


Sample SMIG Content

Migration Context

• Goals and Expectations• Business Processes• Stakeholders• High-level understanding of legacy

system, target SOA environment, and candidate services

Existing Capabilities

• Legacy System Characteristics• System Architecture• Code Characteristics• Interfaces with Other Systems

Target SOA Environment

• Target SOA Infrastructure• Constraints• Infrastructure Services• Quality of Service• Support

Candidate Services

• Potential Service Consumers• Service Requirements• Service Inputs and Outputs• Usage characteristics

SMART: SMIG


Mapping Business Process to Services

Business Process 1

Business Process 2

Business Process 3

Service 2

Service 1

Service 3

Infrastructure Service 1

Infrastructure Service 2

Maps to

Uses

Key

SMART: Establish Migration Context


Establish Migration Context: SMIG Examples

Discussion Topic

Related Questions Potential Migration Issues

Goal and Expectations of Migration Effort

• What are the business and technical drivers for the migration effort?

• What are the short-term and long-term goals?

• No SOA strategy• Goals for migration are not clear.

High-Level Understanding of Legacy System

• What is the main functionality provided by the legacy system?

• What is the high-level architecture of the system?

• What is the current user interface to the system?

• Legacy system knowledge is not available.

• Architectural mismatch• User interface complexity hard to

replicate in service consumers

High-Level Understanding of Target SOA Environment

• What are the main components in the target SOA environment?

• Is this the organization’s first attempt to deploy services in this environment?

• Target SOA environment has not been identified.

• No in-house knowledge of target SOA environment

Potential Service Consumers

• Who are the potential service consumers? • Consumers for services have not been identified.

SMART: Establish Migration Context


Migration is Initially Feasible

Migration goals are clear and shared among stakeholders.

There is a high-level understanding of the legacy system and the target SOA environment.

Candidate services and potential service consumers have been identified.

A very preliminary mapping of services to legacy components has been done.

SMART: Migration Feasibility Checkpoint


Migration has Potential—More Information to be Gathered

Business goals must be identified in order to clearly understand what is expected from the migration.

Potential service consumers must be identified to provide a clear justification of the need for the services.

Key stakeholders must be available to support the process: project sponsors, legacy system developers/maintainers, future service developers, target SOA environment owners, etc.

Target SOA environment must be identified.



Migration is Not Feasible

There are no identifiable consumers for the services to be migrated from the legacy system.

Functionality in the legacy system does not have potential for use by multiple consumers.

There is no functionality in the legacy system of a stateless nature.

Input for the candidate services is so complex that it would require the construction of very complex applications.

There is evident incompatibility between the legacy system and the target SOA environment.



Describe Existing Capability: SMIG Examples

Discussion Topic

Related Questions Potential Migration Issues

Legacy System Characteristics

• What is the history of the system? • Is the system a proof of concept, prototype, under

development, in testing, or a fielded system?• What system documentation is available?• Does the system have interfaces to other

systems? • What are potential locking, persistence, or

transaction problems if accessed by multiple users when migrated to services?

• Planned development concurrent with service migration

• Limited system documentation• Interfaces to other systems will open

doors to service consumers.• Single-user system may have problems

in a multi-user environment.

Legacy System Architecture

• What architecture views are available? • What are the major modules of the system and

dependencies between modules?• Is user interface code separate from the business

logic code? • Are there any design paradigms or patterns

implemented in the system? • What are the key quality attributes built into the

current architecture of the system?

• Lack of architecture documentation may lead to underestimation of complexity.

• Tight coupling between user interface code and business logic code increases effort.

• Undocumented violations of design patterns may cause problems.

• Key quality attributes may not hold true in a services environment.

Code Characteristics

• What code documentation is available?• What coding standards are followed?

• Poor coding practices will increase migration effort.

SMART: Describe Existing Capability


In Summary …

SMART analyzes the viability of reusing legacy components as the basis for services by answering these questions:

• Does it make sense to migrate the legacy system to services?

• What services make sense to develop?

• What components can be mined to derive these services?

• What changes are needed to accomplish the migration?

• What migration strategies are most appropriate?

• What are the preliminary estimates of cost and risk?

SMART


Agenda

Introduction to SOA



SOA Research Agenda

Conclusions

Conclusions


Problem

Current efforts evolve in many directions, without a central compass

Vendors often frame the SOA discourse—with their own agendas

No clear, commonly agreed upon, overarching themes to focus research activity

Danger that important research needs will be overlooked, while other efforts will focus on issues of peripheral long-term significance in practice


SEI Independent Research and Development Project

Conclusions

Goals

• Assemble an international research group to analyze the current state of the practice and current research initiatives in SOA

• Propose a long-term consensus SOA research agenda


Approach

Assembled an international research group to analyze the current state of the practice and current research initiatives in SOA

Proposed a long-term consensus research agenda

Performed an extensive literature review and looked at case studies of successful SOA adoption

Created a service-oriented system development lifecycle that supports the strategic approach to SOA adoption shown in case studies

Identified areas of SOA research necessary to fill in the gaps

Validated end evolved finding through multiple workshops and interviews


SOA Problem and Solution Space

The development of a service-oriented system requires business, engineering and operations to be made, as well as other cross-cutting decisions.

Our proposed taxonomy of research topics is divided into these decision areas.

The research topics correspond to areas where new/more/different research is needed to support a strategic

approach to service-oriented systems development


Sample of Engineering Research Topics


Development Processes and Methodologies—Rationale

Development processes and methodologies have to deal with a very dynamic SOA environment—market, business processes, technology

• State of “Perpetual Beta”—though we do not like the term, it does indicate constant evolution

More and more SOA-based development is concerned with security and governance—how does this fit into processes?

• Policy-Driven Development—following policies through to deployment

SOA is business-driven and demand-driven• Business-Driven Development—business requirements drive service

design and construction

• Business-Process Oriented Development

SOA is more about reuse and less about development


Development Processes and Methodologies—Challenges and Gaps

There is some work that makes the distinction between service provider and consumer, but most development processes are targeted to single-organization development environments

Software development processes for SOA environments have been identified, but there are few concrete processes


Testing - www.SOATesting.org

SOA Testing Research Agenda

Evaluating SOA Testing Tools (SEKE 2008)


Sample of Business Research Topics


Sample of Operations Research Topics


Sample of Cross-Cutting Research Topics


Curricula - www.swecp.org/2007


Conclusions on Key Challenges 1

Engineering challenges are significant if SOA is to be used in “advanced ways”• Semantics

• Dynamic discovery and composition

• Real time applications

Main challenges for enterprise applications are related to business and operations, and not engineering. As third-party services become the new business model, there needs to be support for

• Service-level agreements

• Runtime monitoring

• End-to-end testing involving third parties

• Pricing models for third-party services

• Service usability—from a design and an adoption perspective


Conclusions on Key Challenges 2

There are some areas where what is needed is not more basic research, but rather non-vendor surveys, studies and experiments to produce more concrete guidance

• SOA governance

• Business case for SOA adoption

• ROI for SOA adoption

• Development processes and practices for SOA-based development

There needs to be more collaborative research between industry and academia to create real practices


Research Challenges Report Outline

Executive Summary

Introduction

SOA Basics

SOA Research Framework

Research Topics

Next Steps

Conclusions

Glossary

Workshops

Extended Bibliography


Conclusions 1

SOA offers significant potential for

• Leveraging investments in legacy systems by providing a modern interface to existing capabilities

• Exposing functionality to a greater number of users

They accomplish this by promoting

• Assembly of consumers from existing services

• Platform and language independence

• Reuse of services through loose coupling

• Easy service upgrade due to separation of service interface from service implementation

Conclusions


Conclusions 2

End-to-end engineering approach for SOA requires addressing the unique challenges, risks, and technical issues of three different development perspectives.

• Service consumer developers

• Service developers

• Infrastructure developers

Reuse at the service level is more complex than reuse at module or component level.

• Designing reusable services requires a different approach, skill set, and mindset

• Bigger stakeholder community because services are typically reused at organization and sub-organization level

Conclusions


Conclusions 3

Cost of exposing legacy system functionality as services may be higher than actually replacing the system with a new SOA-based system.

• Detailed analyses are needed

Reuse in the services world requires

• Identification of requirements of the target SOA infrastructure

• Clear distinction between the needs that can be satisfied by the legacy system and those that cannot be satisfied

• Systematic analysis of changes that need to be made to work with target SOA infrastructure

SMART analyzes the viability of reusing legacy components as the basis for services.

The SOA research agenda identifies many opportunities for collaboration

Conclusions


Contact Information

Scott Tilley

Software Engineering Institute

Carnegie Mellon University

[email protected]

Department of Computer Sciences

Florida Institute of Technology

[email protected]

Goal

© 2008 carnegie mellon university migration of legacy components to soa environments: some lessons...

Documents