© 2008 Carnegie Mellon University Migration of Legacy Components to SOA Environments: Some Lessons...
-
Upload
tyrone-bell -
Category
Documents
-
view
215 -
download
1
Transcript of © 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
3© 2008 Carnegie Mellon University
Agenda
Introduction to SOA
• The 50,000-Foot View
— Basic Concepts
— Common Misconceptions
• The 5,000-Foot View
• 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
4© 2008 Carnegie Mellon University
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.
50,000-Foot View: Basic Concepts
5© 2008 Carnegie Mellon University
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.
50,000-Foot View: Basic Concepts
6© 2008 Carnegie Mellon University
Services and Agility
Order Processing Application
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.
50,000-Foot View: Basic Concepts
7© 2008 Carnegie Mellon University
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
50,000-Foot View: Basic Concepts
8© 2008 Carnegie Mellon University
Agenda
Introduction to SOA
• The 50,000-Foot View
— Basic Concepts
— Common Misconceptions
• The 5,000-Foot View
• 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: Common Misconceptions
9© 2008 Carnegie Mellon University
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.
10© 2008 Carnegie Mellon University
Common Misconceptions 2
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.
11© 2008 Carnegie Mellon University
Common Misconceptions 3
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.
12© 2008 Carnegie Mellon University
Common Misconceptions 4
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.
13© 2008 Carnegie Mellon University
Common Misconceptions 5
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
14© 2008 Carnegie Mellon University
Agenda
Introduction to SOA
• The 50,000-Foot View
• The 5,000-Foot View
— Basic Operations
— Web Services
• Pillars of SOA-Based Systems Development
Challenges of Migration to SOA Environments
SMART (Service Migration and Reuse Technique)
SOA Research Agenda
Conclusions
5,000-Foot View: Basic Operations
15© 2008 Carnegie Mellon University
SOA-Based Systems
Order Management
System
Financial System
Organization 1
Organization 2
Credit Card Validation
System
SO
A In
frastru
ctu
re
Order Processing Application
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
5,000-Foot View: Basic Operations
InternetInternet
16© 2008 Carnegie Mellon University
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
5,000-Foot View: Basic Operations
17© 2008 Carnegie Mellon University
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
5,000-Foot View: Basic Operations
18© 2008 Carnegie Mellon University
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
5,000-Foot View: Basic Operations
19© 2008 Carnegie Mellon University
Agenda
Introduction to SOA
• The 50,000-Foot View
• The 5,000-Foot View
— Basic Operations
— Web Services
• Pillars of SOA-Based Development
Challenges of Migration to SOA Environments
SMART (Service Migration and Reuse Technique)
SOA Research Agenda
Conclusions
5,000-Foot View: Web Services
20© 2008 Carnegie Mellon University
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.
5,000-Foot View: Web Services
21© 2008 Carnegie Mellon University
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.
5,000-Foot View: Web Services
22© 2008 Carnegie Mellon University
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.
5,000-Foot View: Web Services
23© 2008 Carnegie Mellon University
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
5,000-Foot View: Web Services
24© 2008 Carnegie Mellon University
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.
5,000-Foot View: Web Services
25© 2008 Carnegie Mellon University
Agenda
Introduction to SOA
• The 50,000-Foot View
• The 5,000-Foot View
• Pillars of SOA-Based Development
Challenges of Migration to SOA Environments
SMART (Service Migration and Reuse Technique)
SOA Research Agenda
Conclusions
1,000-Foot View
26© 2008 Carnegie Mellon University
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
27© 2008 Carnegie Mellon University
SOA Governance
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
28© 2008 Carnegie Mellon University
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
29© 2008 Carnegie Mellon University
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
Pillars: SOA Governance
30© 2008 Carnegie Mellon University
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?
Pillars: SOA Governance
31© 2008 Carnegie Mellon University
Technology Evaluation
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: Technology Evaluation
32© 2008 Carnegie Mellon University
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?
Pillars: Technology Evaluation
33© 2008 Carnegie Mellon University
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.
Pillars: Technology Evaluation
34© 2008 Carnegie Mellon University
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
Pillars: Technology Evaluation
35© 2008 Carnegie Mellon University
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
Pillars: Technology Evaluation
36© 2008 Carnegie Mellon University
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.
Pillars: Technology Evaluation
37© 2008 Carnegie Mellon University
Agenda
Introduction to SOA
Challenges of Migration to SOA Environments
SMART (Service Migration and Reuse Technique)
SOA Research Agenda
Conclusions
Legacy System Challenges
38© 2008 Carnegie Mellon University
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
Legacy System Challenges
39© 2008 Carnegie Mellon University
Legacy System Challenges
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.
Legacy System Challenges
40© 2008 Carnegie Mellon University
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?
Legacy System Challenges
41© 2008 Carnegie Mellon University
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.
Legacy System Challenges
42© 2008 Carnegie Mellon University
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
43© 2008 Carnegie Mellon University
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
44© 2008 Carnegie Mellon University
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
45© 2008 Carnegie Mellon University
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
46© 2008 Carnegie Mellon University
Agenda
Introduction to SOA
Challenges of Migration to SOA Environments
SMART (Service Migration and Reuse Technique)
SOA Research Agenda
Conclusions
SMART
47© 2008 Carnegie Mellon University
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
48© 2008 Carnegie Mellon University
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
49© 2008 Carnegie Mellon University
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
50© 2008 Carnegie Mellon University
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
51© 2008 Carnegie Mellon University
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
52© 2008 Carnegie Mellon University
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
53© 2008 Carnegie Mellon University
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
54© 2008 Carnegie Mellon University
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
55© 2008 Carnegie Mellon University
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.
SMART: Migration Feasibility Checkpoint
56© 2008 Carnegie Mellon University
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.
SMART: Migration Feasibility Checkpoint
57© 2008 Carnegie Mellon University
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
58© 2008 Carnegie Mellon University
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
59© 2008 Carnegie Mellon University
Agenda
Introduction to SOA
Challenges of Migration to SOA Environments
SMART (Service Migration and Reuse Technique)
SOA Research Agenda
Conclusions
Conclusions
60© 2008 Carnegie Mellon University
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
61© 2008 Carnegie Mellon University
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
62© 2008 Carnegie Mellon University
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
63© 2008 Carnegie Mellon University
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
65© 2008 Carnegie Mellon University
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
66© 2008 Carnegie Mellon University
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
67© 2008 Carnegie Mellon University
Testing - www.SOATesting.org
SOA Testing Research Agenda
Evaluating SOA Testing Tools (SEKE 2008)
72© 2008 Carnegie Mellon University
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
73© 2008 Carnegie Mellon University
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
74© 2008 Carnegie Mellon University
Research Challenges Report Outline
Executive Summary
Introduction
SOA Basics
SOA Research Framework
Research Topics
Next Steps
Conclusions
Glossary
Workshops
Extended Bibliography
75© 2008 Carnegie Mellon University
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
76© 2008 Carnegie Mellon University
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
77© 2008 Carnegie Mellon University
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
78© 2008 Carnegie Mellon University
Contact Information
Scott Tilley
Software Engineering Institute
Carnegie Mellon University
Department of Computer Sciences
Florida Institute of Technology
Goal