SOEN6461: Software Design Methodologies Manel Abdellatif - - PowerPoint PPT Presentation

SOEN6461: Software Design Methodologies

Manel Abdellatif Service-Oriented Architecture And Legacy-To-SOA Migration

1

What is a Service-oriented architecture ?

2

Each role appropriates SOA differently:

A set of services that the company wants to expose to their customers and partners, or other parts of the organization A programming model with its standards, paradigms, tools and associated technologies An architectural style based on a vendor, a consumer and a service description. It supports the properties of modularity, encapsulation, decoupling, reuse and composability Middleware offering functionality in terms of integration, orchestration, monitoring and service management Director Business Analyst Architects Developers Integrators

Service-oriented Architecture

3

q A service-oriented architecture (SOA) is a style of software design where services are provided through a communication protocol over a network. q Principles of service-oriented architecture –Independent of vendors –Products –Technologies. q A service is a discrete unit of functionality that can be accessed remotely and updated independently.

4

* *

Object-Oriented

*

services services

services Components

Ø Growing levels of abstraction

Assembler Procedural Language

01011 10100 11000 01011

Evolution of programming paradigms

SOA is an evolution of platforms

• Preserves the successful characteristics of traditional

architectures while adding some new principles

• Shares the following characteristics of an object

v Modularity (set of features that make sense)

• Shares the following characteristics of a component

v Black box (interface / implementation separation) v Location independent v Neutrality to transport protocols

• Corresponds to a functional scope that we wish to expose

to consumers

5

Service Properties

6

Standardized contracts Service Abstraction Service Reusability Service Autonomy Service Statelessness Service Discoverability Service Composability Loose Coupling

Example of tight coupling: Loan Management

7

LoanAgent

calculateRisk

Loan Account

createLoan checkCredit

LoanApproval SMSGateway

sendConfirmation

Entity

Ø LoanAgent is related to LoanApproval and Loan Ø LoanApproval is related to Account Ø Loan is related to SMSGateway

Example of loose coupling: Loan Management

8

LoanProcess CreateLoan CheckAccount Balance Calculate LoanRisk Notify ViaSMS

Services

Ø What is LoanProcess ? Ø A business process ! It orchestrates the services => low coupling

Types of coupling in SOA

9

* *

?

E x :

? ?

Different types of coupling in a SOA It depends on the architectural level

Types of coupling in SOA

10

* *

h i g h c

• u

p l i n g L

• s

e c

• u

p l i n g t e c h n i c a l l e v e l

• r

a t l

• g

i c a l l e v e l ( S C A ) L

• w

c

• u

p l i n g l

• g

i c a l l e v e l

Different types of coupling in a SOA It depends on the architectural level

E x :

SOA Standards

SOA vs Web Services

12

Be careful not to confuse SOA with Web Service!

• SOA is a set of concepts
• Web Services are about the technology
• Can we implement a SOA without Web Services?

SOAP Web Services

13

• SOAP stands for Simple Object Access Protocol
• SOAP is an application communication protocol
• SOAP is a format for sending and receiving messages
• SOAP is platform independent
• SOAP is based on XML
• SOAP is a W3C recommendation

SOAP Web Services

14

Transport protocol

SOAP

W3C

Simple Object Access Protocol Spec for Repository/Registry

UDDI

Microsoft, IBM, HP

Universal Description Discovery and Integration

WSDL

W3C

Web Services Description Language Contract Specification

BPEL

Oasis

Business Process Execution Language

Main components of Web Services

Describes the business process

SOAP Web Services

15

Restful Services

16

• Representational State Transfer
• It was introduced and defined in 2000 by the doctoral

dissertation of Roy Fielding, one of the principal authors of the HTTP specification versions 1.0 and 1.1.

• The most important concept in REST is resources, which

are identified by global IDs— typically using URIs.

• Client applications use HTTP methods (GET/ POST/

PUT/ DELETE) to manipulate the resource or collection of resources.

Restful Web Services

17

HTTP Method Resource Location

Resource Representation

Restful vs SOAP

18

SOA layers

19

e-store : layer

• 20 -

Presentation Layer CartController AccountController Business Logic Layer Account Cart Inventory Item OrderInsert OrderRead Product Profile Category Check

• ut

Create Account Default Error Help Item Details Items My Account Edit Account Order Billing Order Process Order Shipping SignOut Shopping Cart Search SignIn Data Access Layer IAccount IInventory IItem IOrder IProduct IProfile

e-store : Domains

• 21 -

Data Access Layer IAccount IInventory IItem IOrder IProduct IProfile Presentation Layer Business Logic Layer Account Cart Inventory Item OrderInsert OrderRead Product Profile Category Check

• ut

Create Account Default Error Help Item Details Items My Account Edit Account Order Billing Order Process Order Shipping SignOut Shopping Cart Search SignIn

Catalog Inventory Shopping Customer Billing

1.0 1.1 1.2 1.0 2.0 3.5 10.0 11.2 11.5 5.1 5.2 5.3 1.0 6.0 7.0

e-store : Domains

• 22 -

Data Access Layer Presentation Layer Business Logic Layer

Catalog Inventory Shopping Customer Billing

e-store : Services

• 23 -

Presentation Layer Business Logic Layer Data Access Layer Service Layer

Show Catalog Make Inventory Shop Manage Customer Bill

Business Process Execution Language

• In SOA, Programmers use BPEL to define how a business

process that involves web services will be executed in XML format.

• BPEL messages are used to
• invoke remote services,
• orchestrate process execution
• manage events and exceptions.
• BPEL is often associated with Business Process Management

Notation

• Developers transform the visualizations to BPEL for execution.
• Transaction management
• Fault management

26

BPEL Example

27

flow PartnerLink PartnerLink PartnerLink

loan.bpel

BPEL Example

28

flow PartnerLink PartnerLink PartnerLink

<PartnerLink> references to the services participating in the process flow <invoke> a credit rating service synchronously <faultHandlers> catch and manage exceptions when customer has a bad credit history <flow> initiates asynchronous loan processors in parallel of execution <receive> asynchronous callbacks from longrunning loan processors

loan.bpel

SOA Benefits

• Increased Intrinsic Interoperability
• Increased Business and Technology Alignment
• Increased ROI
• Reduce the time of development cycle
• Reduce the complexity of the system
• Increased Organizational Agility
• Reduced IT Burden
• Increase maintainability

33

SOA Challenges

• Difficult to test
• Security vulnerabilities
• Increased overhead
• Risk of proliferation of messages (between

services)

• Not suitable for real-time systems

34

Migration Of Legacy Systems To SOA

35

What is a legacy system?

• Definition 1: « Large software systems that we don't know how to cope

with but that are vital to our organization. Legacy software was written years ago using outdated techniques, yet it continues to do useful work. » Bennett (1995)

• Definition 2: « Aging application systems developed during the last

three decades. They constitute a large number of existing systems. » Rahgozar&Oroumchian (2002)

• Definition 3: « Older IT systems—legacy systems such as mainframes

and COBOL based software. » Geetha (2012)

36

37

Maintenance tasks become central activities in many businesses Legacy software systems are still essential in many businesses 70% of today’s transactional operations are still managed by legacy systems Legacy systems cannot simply be removed / replaced as they execute complex business logic

Legacy-to-SOA Migration Context

Legacy Apps Are Critical But Challenging To Maintain

38

• Legacy systems suffer from several shortcomings
• High maintenace cost
• Lack of flexibility
• Lack of scalability with the evolution of the increasing business needs and

technology in the market

• The lack of sufficient support to the old technologies and infrastructure of

legacy systems

Legacy systems modernization remains essential to ease their maintenance and make them more flexible without loosing their business values

Motivations For Legacy-To-SOA Migration

40

Reducing maintenance costs, improving the flexibility and interoperability of legacy systems are the main motivations to migrate legacy systems to SOA.

82% 64% 64% 42% 38% 38% 38% 24%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90%

M a i n t e n a n c e I n t e r

• p

e r a b i l i t y F l e x i b i l i t y R e l i a b i l i t y P e r f

• r

m a n c e A v a i l a b i l i t y T e s t a b i l i t y O t h e r

We asked 45 professionals about the main reasons of Legacy-To-SOA migration

Types of the Migrated Systems

(a) Age of the migrated systems (b) Size of the migrated systems (c) Programming Languages of migrated systems

41

Practitioners migrate different types of old legacy systems implemented mainly in Cobol and Java.

53% 49% 33% 29% 18% 18% 13% 13% 11% 4% 4% 4% 2% 2% 2% 0% 10% 20% 30% 40% 50% 60% C O B O L J a v a C I C S J a v a s c r i p t C C # C + + A s s e m b l e r P L / 1 R P G F

• r

t r a n O R A C L E f

• r

m s P H P P a s c a l S P L

Legacy-To-SOA migration process

Legacy-To-SOA migration process

Legacy System Assessment

• Detailed analysis of the legacy system
• Using of program comprehension tools
• Architectural recovery techniques
• Reverse engineering aims at automating the extraction

and exploitation of information about a system in order to improve its quality and use.

• Reengineering aims at automating the extraction and

exploitation of information about a system in order to redesign all or part of an existing system.

Legacy-To-SOA migration process

Target SOA System Assessment

• Specification of functional and non-

functional requirements

• Specification of the target

technology

• Standards specification, etc.

Legacy-To-SOA migration process

Study of migration feasibility

• « Does it make sense to migrate legacy system to SOA? »
• Consideration of three aspects: technical, economic and
• rganizational.
• Economic aspect:
• Analysis of the cost of the migration (cost of the re-engineering of

the legacy system)

• Analysis of the cost-benefit ratio (compare the cost of the

reengineering compared to the gain in maintenance costs of the system)

• The cost of the exposing of existing system features as services

may be higher than the actual replacement of the system with a new service-oriented system.

Study of migration feasibility

• Organizational aspect:
• Risk analysis;
• Study of short-term and long-term objectives
• Clearly define the needs of all stakeholders in the

system

• Technical aspect:
• Measure of the complexity of the legacy code, coupling,

cohesion, reusability, etc.

Legacy-To-SOA migration process

Service Identification

• SI is the most challenging phase of the overall

modernization process

• The identified services must meet a range of

expectations concerning their capability, quality of service, and efficiency of use.

• Avoid development from scratch.
• Minimize migration costs

52

What are the used inputs for SI in industry?

76% 58% 71% 16% 49% 53% 9% 27% 7% 9% 69% 44% 0% 10% 20% 30% 40% 50% 60% 70% 80% S

• u

r c e C

• d

e D a t a b a s e B u s i n e s s P r

• c

e s s E x e c u t i

• n

t r a c e s U s e r I n t e r f a c e s U s e C a s e A c t i v i t y d i a g r a m s D a t a F l

• w

d i a g r a m s S t a t e M a c h i n e s d i a g r a m s O n t

• l
• g

y H u m a n E x p e r t i s e D

• c

u m e n t a t i

• n

• Black Box techniques:

The legacy system is considered a black box. Only the public interfaces of the system are studied No modification is made on the system (example code packaging or "wrapping")

• White Box techniques :

The legacy system is exposed Changes can be made to the code (eg grouping classes / features)

Service Identification Techniques

Wrapping

59

• Legacy software system encapsulation with an accessory software layer and exporting public system

functionalities without touching the core of the legacy system.

• Black-box Technique
• Do not require full understanding of the architecture components of the legacy system.
• It avoids the decomposition of legacy systems to identify reusable services.
• Suitable for integration problems
• Do not solve legacy systems problems (maintenance cost, performance, scalability etc.)

Sneed, Harry M., Chris Verhoef, and Stephan H. Sneed. "Reusing existing object-oriented code as web services in a SOA." Maintenance and Evolution of Service- Oriented and Cloud-Based Systems (MESOCA), 2013 IEEE 7th International Symposium on the. IEEE, 2013.

Service Identification Techniques In Industry

22% 60% 20% 13% 47% 7% 4% 13% 9% 0% 10% 20% 30% 40% 50% 60% 70%

Class clustering Functionality clustering Formal concept analysis Heuristics−based Wrapping Genetic algorithms Machine learning Feature location None of the above

Functionality clustering and wrapping are the most used techniques of service identification in industry

Service identification directions

Service identification directions

• Top-down process start by targeting high level artifacts

by performing domain analysis and requirement characterization of the targeted SOA system to define concretely what are the supported services.

• Do not involve legacy code analysis to identify reusable

services.

Service identification directions

• Bottom-up identification starts the identification from

an IT-perspective.

• This identification direction starts from low level

software artifacts to identify higher level ones.

• It starts generally from the source code and extracts

higher abstraction artifact

• Mixed process starts from software requirements by

applying a top-down process and from the source code by applying a bottom-up process to identify the corresponding software architecture.

Service identification directions

Service identification directions

SI directions In Industry

Top-Down (starting by the use of domain-specifc conceptual models like business concept and process models to identify services, which are then specified and mapped onto a software landscape) Bottom-Up (starting by analysing the existing software landscape and modularising it) Mixed (starting by the use of both domain-specific conceptual models and the analyses of the software source code to identify services) No idea

Targeted Quality Metrics

44% 24% 47% 29% 20% 62% 29% 40% 42% 11%

0% 10% 20% 30% 40% 50% 60% 70% L

• s

e C

• u

p l i n g H i g h C

• h

e s i

• n

G r a n u l a r i t y C

• m

p

• s

a b i l i t y S e l f − d e s c r i p t i v e n e s s S e r v i c e R e u s e N u m b e r O f s e r v i c e s C

• s

t A d a p t a t i

• n

E f f

• r

t N

• n

e

• f

t h e a b

• v

e

Only few service quality criteria are desired by practitioners in the SI process: reusability, granularity, and loose coupling

80% 44% 40% 16% 7%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90%

Source code analysis Runtime Analysis Textual Analysis Historical Analysis None of the above

76

Practitioners mostly relied on static analyses of the source code of their legacy systems for service identification.

Analyses Types for Service Identification

• The full automation of service identification

process is not the primary focus of practitioners

• Automation in wrapping and reverse

engineering techniques to document and extract the business logic of legacy systems

• Practitioners do not take the risk to try to

fully automate the SI process

• Challenging problem
• Unpredictable results
• Time consuming
• Needs a lot of research investments

6% 50% 44%

Fully automatic Semi-automatic Manual

77

Automation Of Service Identification

Types Of Services

• Business services:
• They correspond to business processes or use cases.
• Generally consumed by the end-users (online booking).
• To implement business processes, these services compose the

capabilities/functions provided by the Enterprise, Application and Entity services

• Entreprise services:
• They are of finer granularity than Business services.
• They implement generic business functions that are generally reused across

different apps

• Application services:
• These services implement business functions that are specific to an

application.

• They may be created to support reuse within the application scope or to

enable the decomposition of a complex business process

• Entity services:

Ø They are also called information or data services depending on the taxonomy. Ø They provide access to and management of the persistent data of the business. Ø They generally support actions on data (create, read, update and delete) Ø They may have side-effects (i.e.,they modify shared data).

• Utility services:

Ø They may be seen as services that do not support directly the business

processes of the company.

Ø They generally embody some cross-cutting capabilities required by domain-

specific services.

Ø Logging and security services are examples of such services.

Types Of Services

• Infrastructure services:

Ø These services represent the facilities that are required

for deploying and running an SOA application.

Ø Examples : integration services which include services for

routing, protocol conversion, message processing and transformation.

Ø Typically supported by an Enterprise Service Bus (ESB). Ø Compared to utility services, infrastructure services have

a broader scope of reuse.

Types Of Services

• Types of the identified services in Industry
• High concentration on the identification of business and application services
• low concentration on the identification of utility and infrastructure services

73% 49% 56% 73% 38% 38%

0% 10% 20% 30% 40% 50% 60% 70% 80%

Business Entreprise Entity Application Utility Infrastructure

Service identification is a business driven process that prioritize the identification of domain-specific services rather than technical services.

Recommandations for Service Identification

82

Service identification should be a business- value driven process A deep understanding of the domain and a great familiarity with the legacy systems are necessary The input must be source code and production data The output must be high-value, coarse- grained services The process must follow a proven methodology

Legacy-To-SOA migration process

Service Implementation

• It is necessary to consider:

Ø The specification of the services identified in terms of the interfaces offered to their consumers and the interfaces required for external services Ø Service design best practices and target SOA variant

• In the context of bottom-up and mixed approaches it is necessary

to consider moreover: Ø Restructuring the existing application to invoke the identified and specified services through their interfaces. Ø Architectural refactoring of the system

Implementation

• When there is a gap between the targeted business process and the identified

services: (1) modernize/modify/adjust the business process (2) Add new services; (3) Service composition and orchestration

(1) (2)

Conclusion

• The migration process to service-oriented architecture is

complex

• There are no systematic migration approaches
• All approaches are either manual or semi-automatic.
• Need to study the feasibility of migration
• The success of the migration process depends on the quality of

the identified services

• Promote code reuse to minimize costs
• Choose the direction of migration that depends heavily on

available legacy artifacts

• Consider the business and IT perspective of the system at a time

Conclusion

Thank you!