Date post: | 16-Dec-2015 |
Category: |
Documents |
Upload: | william-lawson |
View: | 216 times |
Download: | 0 times |
Sponsored by the U.S. Department of Defense© 2006 by Carnegie Mellon University
Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 1
Pittsburgh, PA 15213-3890
Migration of Legacy Assets to SOA Environments
Dennis Smith and Grace LewisSoftware Engineering Institute
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 2
Our Goal Today
Present and discuss
• Basic concepts related to SOA
• Challenges of implementing SOA-based systems
• Effects of SOA characteristics on migration of legacy assets to services
• Technique for determining feasibility and effort required to migrate legacy assets as services for a specific SOA environment
Goal
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 3
Agenda
Introduction to SOA
Pillars of SOA-Based Systems Development Issues in Migration to SOA Environments
SMART (Service Migration and Reuse Technique)
Conclusions and Next Steps
Agenda
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 4
Agenda
Introduction to SOA• The 50,000 Foot View
- Basic Concepts- Common Misconceptions
• The 5,000 Foot View• The 1,000 Foot View
Pillars of SOA-Based Systems Development
Issues in Migration to SOA Environments
SMART (Service Migration and Reuse Technique)
Conclusions and Next Steps
SOA: 50,000 Foot View
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 5
What is SOA?
Service-oriented architecture is a way of designing systems that enables• Cost-efficiency• Agility• Adaptability• Leverage of legacy investments
SOA: The 50,000 Foot View—Basic Concepts
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 6
Services
Services are reusable components that represent business tasks.• Customer lookup• Account lookup• Credit card validation• Credit check• Hotel reservation• Interest calculation
Services can be• Globally distributed across
organizations• Reconfigured into new business
processes
SOA: The 50,000 Foot View—Basic Concepts
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 7
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
SOA: The 50,000 Foot View—Basic Concepts
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 8
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
easily use available services.
New services can be used by
other applications as
well.
SOA: The 50,000 Foot View—Basic Concepts
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 9
Services and AdaptabilityOrder Processing
Application
Customer Lookup Service
Credit Check
Service
Item Lookup Service
Inventory Check
Service
SOA Infrastructure
The SOA Infrastructure
provides a standard
communication mechanism
between applications and
services.
Changes in services have potentially no
impact on existing
applications that use them.
SOA: The 50,000 Foot View—Basic Concepts
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 10
Services and Legacy Leverage
Order Processing Application
Customer Lookup Service
Credit Check
Service
Item Lookup Service
Inventory Check
Service
SOA Infrastructure
Customer Management
System
The applications access the
services in a standard way.
It is the service’s task to
invoke the legacy
system.
Legacy platform
diversity and complexity is transparent
to the application.
SOA: The 50,000 Foot View—Basic Concepts
Manufacturing System
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 11
Components of an SOA-Based System
Application X
Service A
SOA Infrastructure
Enterprise Information System
Application Y
Application Z
Internet
Internet
External System
Service B
Service C
Service D
Internal Users
DiscoverySecurityDevelopment Tools
Legacy or New Code
SOA: The 50,000 Foot View—Basic Concepts
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 12
In Summary …SOA is an approach to software development where• Services provide reusable functionality with well-defined
interfaces.• An SOA infrastructure enables discovery, composition
and invocation of services. • Applications are built using functionality from available
services.
If managed well, SOA adoption can lead to• Cost-efficiency• Agility• Adaptability• Leverage of legacy investments
The hard part is the “if managed well”.
SOA: The 50,000 Foot View—Basic Concepts
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 13
Agenda
Introduction to SOA• The 50,000 Foot View
- Basic Concepts- Common Misconceptions
• The 5,000 Foot View• The 1,000 Foot View
Pillars of SOA-Based Systems Development
Issues in Migration to SOA Environments
SMART (Service Migration and Reuse Technique)
Conclusions and Next Steps
SOA: The 50,000 Foot View—Common Misconceptions
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 14
An 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.• The concrete elements and their interactions are the
architecture of the system.
Any number of systems can be developed based on an architectural pattern.• An architecture based on SOA inherits both the good and the
bad.
Corollary: SOA cannot be bought off-the shelf.• System qualities have to be built into the architecture of the
system.• Decisions have to be made—service design and
implementation, technologies, tradeoffs.
SOA: The 50,000 Foot View—Common Misconceptions
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 15
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?
Is this cost plus the cost of maintaining the legacy system more than the cost of replacing it with a new one?
What changes will have to be done to the legacy system?
How much will these changes affect current users and other production systems?
SOA: The 50,000 Foot View—Common Misconceptions
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 16
Using XML and WSDL Guarantees Interoperability Among Web Services Provided by Multiple OrganizationsWeb Services enable syntactic interoperability• XML Schema defines structure and data types• WSDL defines the interfaces: operations, parameters
and return values• Available information, technologies and tool support
Web Services do not guarantee semantic interoperability• XML and WSDL do not define the meaning of data• WSDL does not define what a service does• Active research area—unresolved issues
Interoperability needs agreement on both syntax and semantics
SOA: The 50,000 Foot View—Common Misconceptions
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 17
SOA Is All About Technology
SOA not only means a shift in technology but also changes in the organizational governance model.
• Service definition• Service repositories• Ownership
- Common services? Data?• Evolution • Conflict resolution• Deployment mechanisms• Monitoring mechanisms• Enterprise-wide policies• Service-level agreements
SOA: The 50,000 Foot View—Common Misconceptions
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 18
It Is Easy To Develop Applications Based on ServicesIt is relatively easy to build services to work with a particular infrastructure … but designing a “good” service might not be that easy.
• From a implementation standpoint- Ease depends on tool availability for SOA
infrastructure- Most difficult part is composition—data
mismatches
• From a design standpoint- Not many best practices for designing services- Have to anticipate potential users and usage
patterns- What is the right Quality of Service? Can you
guarantee it?- “If you build it they will come” – Can you afford
this?
SOA: The 50,000 Foot View—Common Misconceptions
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 19
It is Easy to Compose Services Dynamically at RuntimeCurrent technologies have not advanced to the point that this is possible in production environments.
Requires the use of a common ontology by service providers and client applications within a domain
Requires the construction of extremely intelligent applications that• Construct the right queries for the discovery of
services• Compose services when there is not a single service
that can process the request• Provide the right data to invoke a service that was
discovered at runtime
SOA: The 50,000 Foot View—Common Misconceptions
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 20
In Summary …
Our intent is not to discourage, but to caution.
An SOA approach may be the best way to achieve common goals of interoperability, agility, and reuse.
But …• Most of the mentioned issues are active areas of research.• Some solutions will require time to mature.
Also keep in mind …• Not everything in an SOA-based system has to be a service
- It might not make sense for your whole system• Most case studies will show that the key is governance
- Which has very little to do with technology
SOA: The 50,000 Foot View—Common Misconceptions
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 21
Agenda
Introduction to SOA• The 50,000 Foot View• The 5,000 Foot View
- Web Services• The 1,000 Foot View
Pillars of SOA-Based Systems Development
Issues in Migration to SOA Environments
SMART (Service Migration and Reuse Technique)
Conclusions and Next Steps
SOA: The 5,000 Foot View
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 22
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, it is often equated to SOA.
SOA: The 5,000 Foot View—Web Services
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 23
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
DiscoveryUDDI
DescriptionWSDL
Message FormatSOAP
EncodingXML
TransportHTTP
Se
curity
Ma
na
ge
me
nt
Tra
nsa
ction
s
Qu
ality of S
ervice
Orchestration and Choreography
WSCL, WSCI, BPEL4WS, WS-Coordination
BPML, BPSS
Base Stack
Adapted from “XML and Web Services Unleashed”, SAMS Publishing
SOA: The 5,000 Foot View—Web Services
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 24
Web Services At Design Time
Alice obtains the WSDL
corresponding to Bob’s web
service
Alice runs the WSDL document
through tools that generate all the necessary
message construction code (e.g.
WSDL2Java)
Bob exposes functionality in a system as a
service (or creates a specific
service) and places a WSDL
document in an “accessible
place”
Alice adds code to her application that executes the
message construction
code to connect to Bob’s web
service and any additional code that uses the
response obtained from
Bob’s web service
SOA: The 5,000 Foot View—Web Services
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 25
Web Services At Run Time
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.
SOA: The 5,000 Foot View—Web Services
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 26
Static vs. Dynamic
With today’s technology, discovery and composition of services are done at design time—Static• Developer discovers services and obtains addresses• Developer writes code to invoke the services located at these
addresses
There is a great amount of research to enable discovery and composition at runtime—Dynamic• Application discovers services and obtains addresses• Application contains code to invoke the discovered services
and “knows” what information to provide
There are a lot of “In-Between” techniques• Application discovers services but requires user intervention to
select services and provide the required information• Portals are configured such that “portlets” correspond to
services
SOA: The 5,000 Foot View—Web Services
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 27
In Summary …
Web Services are the most currently used approach to SOA implementation.• Basic infrastructure standards are fairly stable• More higher level standards are emerging
Web Services are not the only approach to SOA implementation.
SOA: The 5,000 Foot View—Web Services
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 28
Agenda
Introduction to SOA• The 50,000 Foot View• The 5,000 Foot View• The 1,000 Foot View
Pillars of SOA-Based Systems Development Issues in Migration to SOA Environments
SMART (Service Migration and Reuse Technique)
Conclusions and Next Steps
SOA: The 1,000 Foot View
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 29
Components of an SOA-Based Systems
1. Services
2. Applications
3. SOA Infrastructure
SOA: The 1,000 Foot View
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 30
Our Scenario: SOA-Based System Components
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
Internet
Internet
SOA: The 1,000 Foot View
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 31
Distribution of SOA-Based System Development
SOA: The 1,000 Foot View
Organizational ESB
Incorporation of Map Data
“Just-In-Time” Inventory Management
Software as a Service
Single Organization
Multiple Organizations
Net-Centric Operations
On the left side of the spectrum all three types of components are developed within the same organization.
On the right side of the spectrum each type of component is developed by a different organization.
There are many possibilities in between.
As you move to the right, the challenges are greater.
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 32
Application Developers 1
Focus on the discovery, composition and invocation of services, either statically at design time or dynamically at run time
SOA: The 1,000 Foot View
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 33
Application Developers 2
1. Identify appropriate
services (both
internal and external)
that can be reused
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
Internet
Internet
… as well as if it needs to become a service
provider itself
2. Understand the interfaces in terms of the functionality and QoS
provided by them
Application Developer needs to create a new application
using the SOA approach
SOA: The 1,000 Foot View
3. Create the new system
using as many existing services
as possible
4. The application needs to be architected in such a way
that it can easily accommodate changes in
services interfaces …
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 34
Tasks for Application Developers
Understand the SOA infrastructure
Discover appropriate services to be incorporated into applications
Retrieve service description documentation
Invoke the identified services in applications• Data conversions• Error handling• Availability handling
Test the services for correctness in the context of the application being developed
SOA: The 1,000 Foot View
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 35
Service Developers
Focus on the description and granularity of services so that applications can easily locate and use them with acceptable Quality of Service (QoS)
SOA: The 1,000 Foot View
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 36
Service Developers
1. Identify what existing business
functionality can be
exposed/reused as services
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
Internet
Internet
4. Design, create and
publish services to internal and
external organizations
3. Anticipate requirements for future consumer systems and architect services in a
scalable fashion
2. Analyze service
interface, functionality and
QoS requirements for new consumer
systems
SOA: The 1,000 Foot View
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 37
Tasks for Service Developers
Understand requirements of potential service users
Understand SOA infrastructure
Develop code that receives the service request, translates it into calls into new or existing systems, and produces a response
Describe and publish the service
Develop service initialization code and operational procedures• Service-Level Agreements (SLAs) are a topic of current
interest among service providers.
SOA: The 1,000 Foot View
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 38
Infrastructure Developers
Focus on providing a stable infrastructure• Standards• Common services• Development tools
NOTE: The Enterprise Service Bus (ESB) is an example of an infrastructure designed to support the SOA paradigm.
SOA: The 1,000 Foot View
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 39
Infrastructure Developers 2
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
Internet
Internet
Infrastructure developers have to design, create
and maintain these common services for
both internal and external use (if required)
Discovery
Security
Development Tools
Service Registry
There are common
services that are used by all applications
SOA: The 1,000 Foot View
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 40
Tasks for Infrastructure DevelopersSelection of standards to implement as part of the infrastructure
Development of a set of common infrastructure services for discovery, communication, security, etc.
Identification and development of binding mechanisms to satisfy the largest set of potential service users
Provision of tools for application and service developers
Documentation and support for the infrastructure
SOA: The 1,000 Foot View
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 41
The Potential Problem
If the three types of components are developed within the same organization, the challenges are less.• Simpler communication between developers (or might
even be the same developers)
However, it is becoming increasingly common for these three types of components to be developed independently by separate organizations. • Decisions made locally by any one of these development
groups can have an effect on the other groups.
SOA: The 1,000 Foot View
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 42
Sample Consequences of Decisions: Service Granularity 1The granularity of service interfaces can affect the end-to-end performance of an SoS because services are executed across a network as an exchange of a service request and a service response.
• If service interfaces are too coarse-grained, clients will receive more data than they need in their response message.
• If service interfaces are too fine-grained, clients will have to make multiple trips to the service to get all the data they need.
SOA: The 1,000 Foot View
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 43
Sample Consequences of Decisions: Service Granularity 2
Order Management
System
[Basic Info, Order History, Pending Orders] getCustomerInfo( CustomerId )
The Order Management System can expose the business functionality of
getting all the customer information in one call
OrderHistory getOrderHistory( CustomerId )
CustInfo getCustBasicInfo( CustomerId )
Order[] getPendingOrders( CustomerId )
Or the service can be more granular and provide three
different operations for each type of information
SOA: The 1,000 Foot View
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 44
Sample Consequences of Decisions: Requirements 1
If service developers do not understand functionality and QoS needs of potential users of services, they might end up developing and deploying services that are never used
SOA: The 1,000 Foot View
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 45
In Summary …SOA-based systems are about more than just technology.
SOA-based systems development requires
1. Strategic approach to SOA implementation• Alignment with business goals
2. SOA governance• Policies, coordination and guidance for SOA
infrastructure providers, service providers, and application developers
3. Realistic technology evaluation• Context-based technology evaluations
4. Change of mindset• Different development and implementation approach
SOA: The 1,000 Foot View
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 46
Agenda
Introduction to SOA
Pillars of SOA-Based Systems Development Issues in Migration to SOA Environments
SMART (Service Migration and Reuse Technique)
Conclusions and Next Steps
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 47
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
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 48
Strategic Alignment
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: Strategic Alignment
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 49
Alignment with Business Goals
Any successful SOA strategy has to be aligned with business goals.
Examples• Reduce time to market for applications• Increase information available to customers• Integrate business partners• Decrease development cost by increasing reuse• Reduce maintenance costs• Improve customer service• Improve internal processes
Pillars: Strategic Alignment
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 50
Service Conception
1. Business processes to support business goals are identified.
2. Candidate services are identified.• 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.
Pillars: Strategic Alignment
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 51
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
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 52
Lack of Governance Inhibits SOA AdoptionAn InfoWorld 2006 SOA Trend Survey indicates that Lack of Governance is the main inhibitor for SOA adoption (48%)
Greater than other inhibitors that would seem more obvious• Unresolved security issues (40%)• Performance and reliability (39%)• Incomplete and immature standards (38%)
Pillars: SOA Governance
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 53
SOA Governance
Policies and procedures
Roles and responsibilities
Design-time governance
Run-time governance
Pillars: SOA Governance
Source: Integration and SOA: Concepts, Technologies and Best Practices. Beth Gold-Bernstein & Gary So.
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 54
Policies and ProceduresService providers• Service conception• Service modeling• Service development• Service deployment
Infrastructure providers• Infrastructure versioning• Upgrades
Application developers• Service composition• Application testing
Pillars: SOA Governance
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 55
Roles and Responsibilities
Roles• SOA Governance Manager• Close work with
- Business process managers and analysts- Project managers- Infrastructure managers- Service managers
Responsibilities• Creation• Approval• Implementation• Enforcement
Pillars: SOA Governance
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 56
Challenges of SOA Governance
Seems counterintuitive• If SOA is all about loose coupling and flexibility, why all this
central control?
Multiple organizations• How to create governance for service providers, infrastructure
providers, and application developers? What if policies conflict?
Dealing with exceptions• How to record and maintain sometimes necessary
exceptions?
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
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 57
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
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 58
Match of Technologies to the Problem Domain
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
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 59
Technology Checks
TechChecks are prototypes, situated in a specific context, with the goal of providing a “technology sanity check”.
Model problems are ruthlessly efficient—no glitz; just answer the question.
The model problem approach involves1. Formulating hypotheses about
the technology2. Examining these hypotheses
against very specific criteria through experimentation
Develop Hypotheses
Develop Criteria
Design and Implement Solution
Evaluate Solution Against Criteria
[Hypothesis Sustained] [Hypothesis Refuted]
Pillars: Technology Evaluation
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 60
TechCheck Example: 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
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 61
TechCheck Example: Hypotheses and Criteria
Pillars: Technology Evaluation
Hypothesis 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 that will allow for manual serialization and deserialization of SOAP messages.
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.
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 62
Change of Mindset
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: Change of Mindset
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 63
SOA-Based Systems Require a Different Development Approach
Traditional System Development
Tight coupling between system components
Shared semantics at design time
Known set of users and usage patterns
System components all within the same organization
SOA-Based System Development
Loose coupling between applications and services
Semantics ideally enable dynamic discovery and execution of services
Potentially unknown service users and usage patterns
Multiple organizations providing system components
Pillars: Change of Mindset
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 64
Less Control
Requires giving up control—not easy
Anticipate objections and understand validity• Security• Performance• Control
Greatest challenges come from• Single organization may not own the system• Services used in unknown ways by (potentially) unknown
users
Education and training on new mindset is needed
Pillars: Change of Mindset
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 65
Agenda
Introduction to SOA
Pillars of SOA-Based Systems Development Issues in Migration to SOA Environments• Reuse Issues• SOA Issues
SMART (Service Migration and Reuse Technique)
Conclusions and Next Steps
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 66
Reuse in the SOA Context
Reuse at a higher level• Reuse of business functionality• Encapsulation of technical details
Reuse across organizations• Organizations can “sell” their core business expertise as
services • Functionality can be acquired as opposed to developed
from scratch—potential savings
Option for leveraging legacy system investment• In most cases, legacy components can be reused by
exposing them as services, independent of vendor, platform and technology
Migration Issues: Reuse
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 67
Reuse Issues 1
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
Migration Issues: Reuse
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 68
Reuse Issues 2
It may not always be possible to reuse business functionality of legacy applications by exposing them as services
• Technical constraints due to the nature of the legacy application - 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 business application as services may be higher than actually replacing the system with a new SOA-based system
Migration Issues: Reuse
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 69
Addressing Reuse Issues
Identify relevant and non-relevant legacy assets• Not all legacy assets can be meaningfully reused as
services—both from a strategic and 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 Issues: Reuse
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 70
Agenda
Introduction to SOA
Pillars of SOA-Based Systems Development Issues in Migration to SOA Environments• Reuse Issues• SOA Issues
SMART (Service Migration and Reuse Technique)
Conclusions and Next Steps
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 71
Migration to SOA Environments: A Complex Engineering TaskThe characteristics of SOA enable the exposure of legacy system functionality as services• Presumably without making significant changes to the
legacy systems
Constructing services from existing systems in order to obtain the benefits of SOA is neither easy nor automatic
Such a migration can represent a complex engineering task• Particularly when the services are expected to execute
within a tightly constrained environment
Migration Issues: SOA Characteristics
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 72
Legacy System Characteristics
There are aspects of the legacy system that could make the effort challenging• Poor separation of concerns
- User interface code tightly coupled with business function code
• Tool availability- 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?
Migration Issues: SOA Characteristics
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 73
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 Issues: SOA Characteristics
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 74
Agenda
Introduction to SOA
Pillars of SOA-Based Systems Development Issues in Migration to SOA Environments
SMART (Service Migration and Reuse Technique)
Conclusions and Next Steps
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 75
SMART: The Service-Oriented Migration and Reuse TechniqueAssists organizations in making initial decisions when analyzing legacy components for reuse as services
Focuses on the reuse of legacy components as services in an SOA
Outcome is a migration strategy for the organization
SMART: Introduction
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 76
Three Elements of SMART
1. Process that • Gathers information about
- Goals of migration effort- Candidate services- Legacy components- Target SOA
• Analyzes gap between legacy and target state
2. Service Migration Interview Guide (SMIG)• Guides discussions in initial SMART activities
3. Templates for Output Products – examples:• Component table• Service table• Migration strategies
SMART: Elements
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 77
SMART Process Activities
Establish Migration Context
Describe Existing
Capability
Describe Target SOA
State
Analyze the Gap
Develop Migration Strategy
SMART Elements: Process Activities
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 78
Sample SMIG Content
Migration Context• Goals and Expectations• Critical Business Processes• Potential Service Users• Legacy System Developers,
End Users and Owners
Existing Capabilities• Legacy System
Characteristics• System Architecture• Code Characteristics• Interfaces with Other
Systems
Target SOA State• Service Requirements• Target SOA• Data Models• Legacy System Adaptation• Service-Oriented Changes• Quality of Service
Support• Service Setup• Problem Reporting and
Feedback• Updates and Upgrades• User Communities
SMART Elements: SMIG
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 79
SMART ArtifactsEstablish
Migration ContextDescribe Existing
Capability Describe the
Target SOA State Analyze the Gap
Develop Migration Strategy
Stakeholder List Create Update Update Update Update
Characteristics List
Create Update Update Update
Migration Issues List
Create Update Update Update
Critical Business Processes
Create UpdateUpdate Update
Service Table Create Update Update Update
Component Table Create Update Update
Component Service Options
Table Create Update
Migration Alternatives Table
Create
Service Migration Strategy
Create
Final Presentation Create
SMART Artifacts
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 80
Case Study: Clinical Lab System
SMART Case Study: Context
Patient
Clinic
Doctor’s visit
Hospital
Hospital
Admission
Clinical Lab
Order Test
Order Test
Billing information
Insurance
Aggregate data for research
Clinical Research Center/
University
Results
Patient
Portal
Patient Data
Patient Data
Results
Results
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 81
Case Study: Clinical Lab System Context DiagramLab information shared between many systems
Need to move to a SOA environment to increase reusability of common lab tasks
Key questions:
1. Which services should be created from legacy assets?
2. In what order? 3. Should some legacy
components be replaced with new components?
Lab System
Inpatient System
Outpatient System
Research System
Patient Information
Online
Insurance
SMART Case Study: Context
SMART Engagement Scope
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 82
Establish Migration Context
Understand the business and technical context for migration
Identify stakeholders
Select candidate services for migration
SMART Activities: Establish Migration Context
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 83
Case Study: Understand Business Drivers for Legacy Migration Improve patient care by • Standardizing the access to lab information using services• Providing access to lab information from any clinical
system in real time (current access is mostly batch-oriented)
• Making lab information accessible to patients via the Internet using a patient portal
Reduce IT costs by • Creating common and reusable services • Reducing the multiple redundant interaction points
(interfaces)• Lowering maintenance and upgrade costs by using an
SOA environment
SMART Case Study: Understand Business Context
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 84
Case Study: Identify Stakeholders
Lab System
InpatientSystem
Outpatient System
Research System
PatientInformation
Online Insurance
Legacy system: Clinical Lab
Legacy system developers, service designers, business manager, project manager
Outpatient physicians, architects, Service designer, IT/Infrastructure staff
Inpatient doctors, software architects, service designers, IT/Infrastructure staff
Patients, Portal architect, Developers
Researchers, IT infrastructure developers
Insurance policy makers, architect
Existing system: Medical School
Existing system: Clinics Existing system: Hospitals
New system: Patients on Internet Existing system: Insurance Companies
SMART Case Study: Identify Stakeholders
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 85
Establish Migration Context: SMIG Examples
Discussion Topic
Related Questions
Rationale Why is the migration to an SOA environment being considered?
Expectations What are the expectations from the migration effort?
Potential Service Users
Have users or systems that will use the services been identified? How were their service requirements identified?
Legacy System Stakeholders
Who owns the legacy system? Who developed the legacy system?
Business Goals and Processes
What are the main business goals?What are the main business processes that support these goals?What are common steps/tasks between these business processes?
SMART Activities: Establish Migration Context
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 86
Establish Migration Context: Tasks
Create Stakeholder List
Create Stakeholder List
Create Characteristics
List
Create Characteristics
List
CreateMigration Issues
List
CreateMigration Issues
List
Update at any time!
•Stakeholders•Contact
Information•Information to
be elicited from each
•Identify component characteristics to be gathered
•Some are predefined•Others vary with
context•Provides data for
analysis process
Identify issues as they become evident
•General issues affect the overall migration effort
•Component- or service-specific issues
Create Service Table
Create Service Table
•Identify candidate services and the business processes they support
•Identify potential information sources
• Architects• Service users• Domain groups• Communities of Interest
(COIs)
SMART Activities: Establish Migration Context
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 87
Case Study: Service Table
Service Description Service Type Business Process Supported
Get Test Results Details
Obtains detailed test results either for one patient or for all the patients for which tests were completed on a day for a particular location.
Business
• Analysis and mining for trends
• Review and report of results• Archival and retrieval of test
results
Data Transfer Service Wraps and transfers all data payload to external systems. Infrastructure
• Business services internal to the Lab system
• External applications or services that need to provide bulk data back to the Lab system
ServicePotential
Service Users… … … …
Get Test Results Details Hospital, Clinic and Patient applications
Data Transfer Service Internal services and external applications and services
SMART Case Study: Service Table
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 88
Describe Existing Capability: Tasks
Update Characteristics
List
Update Characteristics
List
Create Component
Table
Create Component
Table
UpdateMigration Issues
List
UpdateMigration Issues
List
•Identify components for potential migration
•Gather characteristic data for each component
•Characteristics become columns of the component table
•Indicate data to be gathered about each component
•Issues will appear as data is gathered
SMART Activities: Describe Existing Capability
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 89
Case Study: Implementation Characteristics Written in C++ and Java
Some components run on Windows operating system and some on Unix OS
~2500 C++ classes and ~1500 Java class
800,000 lines of code
Dependencies on several commercial products:• Oracle Database• Weblogic Application Server
SMART Case Study: Legacy System Characteristics
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 90
Case Study: Updated Migration Issues
Description: All service consumers do not plan to move to the XML compliant version (v3) of HL7Description: Some legacy components are designed only for
batch operations …..
Description: Some legacy components have direct calls to UI embedded in the core business logic of the codeIssue Type: Technical
Related Component: Lab Results Reporting, Order Processing Complexity: Medium
Description: Different data filtering policies are applied to the same data depending upon on the interacting external system Issue Type: Business, Policy
Related Component: Results Retrieval
Complexity: Low
SMART Case Study: Migration Issues
New
New
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 91
Describe Target SOA State: Tasks
Update Characteristic
s List
Update Characteristic
s List
Create SOA
Description
Create SOA
Description
Update Service and Component
Tables
Update Service and Component
Tables
Update Migration
Issues List
Update Migration
Issues List
SOA Description will most likely provide additional characteristics to be gathered about services and components
SMART Activities: Describe Target SOA State
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 92
Case Study: Updated Component Table
Component Programming Language Age (years) Size (SLOC) Complexity Level of
Documentation Version
LabTestCatalog Java 6 12,000 Medium High 5.6
OrderProcessor C++ 8 8,000 Very High Medium 8.2
ComponentLast Release
DateMax. Depth of
InheritanceCoupling
(# of classes)Cohesion COTS Dependency
LabTestCatalog 02/10/2005 5 60 MediumOracle database, Weblogic
Application Server, HL7 v2.3
OrderProcessor 06/01/2005 8 80 FairCustomer Interface Engine, Some 3rd
party libraries
ComponentDirect Calls to UI Hard coded
Policies and RulesSecurity
Requirement LevelUpdated Detailed Design Document
Available?
LabTestCatalog Yes No Medium No
OrderProcessor Yes Yes High Yes
SMART Case Study: Component Table
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 93
Case Study: Target SOA StateBusiness Services• Reusable business services that are created by reusing the
existing legacy code base
Policy Manager • Centralizes the configuration, deployment, change management
and storage of policies
Infrastructure Data Transfer Service• Used by all the business services to transfer and receive data
from external systems
Infrastructure Security Service• Provides secure transmission of a confidential data • Provides authorization and authentication services from external
interacting systems
Infrastructure Data Format Service• Formats messages according to HL7 v2.x or HL7 v3 as needed
by business services and external applications
SMART Case Study: Target SOA Characteristics
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 94
Case Study: Target SOA Constraints
Services shall support different versions of the HL7 standard• Patient Portal will use the new XML complaint version (v3)
of HL7• Some other systems (Outpatient, Inpatient) plan to move to
HL7 v3 in near term while others don’t have any plans
Services shall take into account the different policy requirements for the same data• Research data should be completely anonymous (without
any Personally Identifiable Information – PII) • Inpatient/outpatient data should be completely identifiable
for each patient
SMART Case Study: Target SOA Characteristics
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 95
Case Study: High-Level Target SOA
Research Database
Test Results Service
Security Service
Order Lab Test Service
Get Patient
Information
Enterprise Service Bus (ESB)
Results and Reporting
Order Processing Component
Inpatient System
Outpatient System
Insurance Company System
Data Transfer Service
SMART Case Study: Target SOA Characteristics
Data Format Service
Patient Portal
Policy Manager
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 96
Analyze the Gap: Tasks
Create Component
Service Options
Table
Create Component
Service Options
Table
Identify Additional
Data Needed
Identify Additional
Data Needed
Gather Additional
Data
Gather Additional
Data
Analyze Component/Servic
eOptions
Map components to services
•Need not be one-to-one
•Alternate approaches may be possible
Incomplete or untrustworthy data?
• Architectural analysis• Architectural
reconstruction• Code analysis
Update all tables!
•Estimate cost/effort
•Determine risk
SMART Activities: Analyze the Gap
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 97
Case Study: Analyses Performed
Three types of analysis performed
• Informal evaluation of code quality - No consistent coding standards in force- Parts of the code had little cohesion- Awkward and non-standard class/modules
organization
• Architectural reconstruction to gain a better understanding of code dependencies when the SMART team found discrepancies
• Effort and cost estimation of changes necessary to migrate legacy components
SMART Case Study: Gap Analysis
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 98
Case Study: Key Findings
Insufficient architectural and other high-level documentation to accurately determine class dependencies• Potential for underestimation of the amount of code used
by the potential services• No details on code module dependencies
No consistent programming standard • Automated code analysis is not easy
Violation of Model-View-Controller architecture• Undocumented dependencies between potential
services and user interface code have to be identified and removed
SMART Case Study: Gap Analysis
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 99
Select Recommended
Options
Select Recommended
Options
Develop Migration Strategy: Tasks
Create Migration Alternatives
Table
Create Migration Alternatives
Table
Analyze OptionsAnalyze Options PresentFindings
PresentFindings
•What components?
•What services?
There can be more than one viable strategy
• Different sequencing
• Use of external services
• Use of COTS products
Estimate comparative cost, effort, and risks
SMART Activities: Develop Migration Strategy
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 100
Migration Alternatives Table
$K % % Q QQ QQ Q Q $KMM MMN
MigrationOption
# 1
ServiceNeed
Satisfied
OptionNumber
MigrationEstimates
New DevelopmentEstimates
Migration VersusNew Development
Name of Service Need
OptionSummation
$K % % Q QQ QQ Q Q $KMM MMN
MigrationOption
# 3
Name of Service Need
OptionSummation
$K % % Q QQ QQ Q Q $KMM MMN
MigrationOption
# 2
Name of Service Need
OptionSummation
SMART Activities: Develop Migration Strategy
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 101
Outcome of SMART
Summary
Report
RESULTS
List of stakeholders List of candidate services Description of legacy components, target SOA Results of analyses Description of various migration options Cost and effort of selected options
RESULTS
List of stakeholders List of candidate services Description of legacy components, target SOA Results of analyses Description of various migration options Cost and effort of selected options
SMART Activities: Develop Migration Strategy
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 102
Case Study: Recommendations
• Perform a workshop with all the key stakeholders to- Validate the expectations and requirements for the new
services- Define a roadmap for the migration effort
• Identify services that are both important and less complex than the ones initially identified
• Implement these services a pilot using the current target architecture
• Revisit the new architecture (SOA) after the pilot phase to make changes based on the lessons learned in pilot phase
• Identify the order in which services should be implemented based on greatest impact with lowest risk; prioritize and plan accordingly
• Recalculate cost/effort when- Code dependencies are better documented- User requirements are better understood- Target SOA is better defined
SMART Case Study: Migration Strategy
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 103
Agenda
Introduction to SOA
Pillars of SOA-Based Systems Development Migration to SOA
SMART (Service Migration and Reuse Technique)
Conclusions and Next Steps
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 104
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 applications from existing services • Platform and language independence• Reuse of services through loose coupling• Easy service upgrade due to separation of service
interface from implementation
Conclusions
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 105
Conclusions 2
End-to-end engineering approach for SOA requires addressing the unique challenges, risks and technical issues of three different development perspectives
• Applications that make use of services
• Services used by applications and other services
• Infrastructure that allows the discovery of services and the data exchange between application and services
Conclusions
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 106
Conclusions 3
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
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
Conclusions
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 107
Conclusions 4
Reuse in the services world requires
• Identification of needs of the target architecture
• 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 fit into target architecture
Conclusions
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 108
Conclusions 5
SMART analyzes the viability of reusing legacy components as the basis for services by answering these questions:
• 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?
Conclusions
© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 109
References
Pointers to Technologies and StandardsISIS Guide to Interoperability http://www.sei.cmu.edu/isis/isis-guide.htm
SMART: The Service-oriented Migration and Reuse Techniquehttp://www.sei.cmu.edu/publications/documents/05.reports/05tn029.html
References