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

SOEN6461: Software Design Methodologies

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

1

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

What is a Service-oriented architecture ?

Service-oriented architecture

q A service-oriented architecture (SOA) is a style

• f 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 acted upon and updated independently.

3

4

* *

Object-Oriented

*

services services

services Components

Ø Growing levels of abstraction

Assembler Procedural Language

01011 10100 11000 01011

Evolution of programming paradigms

5

SOA is an evolution of platforms

• It 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

Service properties

6

• Standarized contracts services de-fine their capabilities using a

standard, implementation-neutral language.

• Service Abstraction
• Service Reusability
• Service Autonomy
• Service Statelessness
• Service Discoverability
• Service Composability
• Loose Coupling

7

Example of tight coupling: Loan Management

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

8

Example of loose coupling: Loan Management

LoanProcess CreateLoan CheckAccount Balance Calculate LoanRisk Notify ViaSMS

Services

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

9

Types of coupling in SOA

* *

?

E x :

? ?

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

10

Types of coupling in SOA

* *

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, or REST, 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 Representatio n

Restful vs SOAP

18

SOA layers

19

• 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

e-store : layer

Data Access Layer IAccount IInventory IItem IOrder IProduct IProfile

• 21 -

Data Access Layer IAccount IInventory IItem IOrder IProduct IProfile

e-store : Domains

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

• 22 -

Data Access Layer Presentation Layer Business Logic Layer

e-store : Domains

Catalog Inventory Shopping Customer Billing

• 23 -

e-store : Services

Presentation Layer Business Logic Layer Data Access Layer Service Layer

Show Catalog Make Inventory Shop Manage Customer Bill

Business Process Management (BPM)

24

• Goal: To give the Company the means

to manage its business processes in an automated way (modeling, simulation, execution and audit)

• Optimization, adaptation to real-time

needs.

• A process is composed of sub-

processes, business rules and activities

• An under process has its own purpose,

inputs and outputs

• KPIs for Key Performance

Indicators capture process performance

• A process is the result of a

service orchestration

• The process itself is accessible

as a service Activities :

• correspond to parts of the business

process that

• do not include a decision and are

associated with roles

• Are performed by systems or humans

jBPM -Business Process Management (BPM) Suite

25

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 <switch> to the lowest loan offer

loan.bpel

Enterprise Service Bus

29

Enterprise Service Bus

30

Avoids the mess of Traditional point-to-point integration!!

Enterprise Service Bus

31

Enterprise Service Bus

• An ESB is the entry point to a service : Indirect invocation of the service via

the bus.

• An infrastructure that optimizes the communication between consumers and

service providers.

• An ESB can handle:
• Routing
• Data transformation
• Transactions
• Messaging
• Protocol bindings
• Security, etc.
• The goal of an ESB is to ensure a simple and standardized way of

communication between different applications

32

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

Legacy-to-SOA Migration Context

• Today’s businesses must be able to flexibly and

quickly adapt to market needs

• Software systems maintenance efforts must be

reduced

• IT systems must continue to evolve

Today's best solutions are tomorrow's legacy systems

36

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)

37

What is a legacy system?

• Use of old technologies
• Requires skills that are difficult to find
• Lack of documentation
• Hard to maintain
• Weak resistance to change, integration

and replacement

38

Why do we migrate legacy systems to SOA?

40

We asked 37 professionals about the main reasons of legacy-to-SOA migration

Legacy-To-SOA migration process

Legacy-To-SOA migration process

Legacy System Assessment

• Detailed analysis of the legacy system
• Using 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

▪ It is the most challenging phase

• fthe overall modernization process

and important for software reuse. ▪The identified services must meet a range of expectations concerning their capability, quality of service, and efficiency of use. ▪Avoid development from scratch ▪ Minimize the migration cost

Input Output

Service Identification Algorithm

Quality metrics Guide the algorithm Fitness function

51

Service Identification

• We asked 37 professionals about the

artefacts they use to identify services

What are the used inputs for SI in industry?

• 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

56

• 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.

FCA based techniques

5 7

▪Use of ontologies ▪Ontology is by definition a structured set of terms and concepts representing the meaning of an information field, whether through the metadata of a namespace, or elements of a knowledge domain ▪Only tow works proposed an ontology service identification based approach :

▪ M. Djeloul, “Locating services in legacy software: information retrieval techniques, ontology and fca based approach,” WSEAS Transactions on Computers, vol. 11, no. 1, pp. 19 – 26, 2012/01/ ▪ ¨F. Chen, Z. Zhang, J. Li, J. Kang, and H. Yang, “Service identification via ontology mapping,” in 2009 33rd Annual IEEE International Computer Software and Applications Conference, vol. 1. IEEE, 2009, pp. 486– 491.

▪Challenge of ontology based identification = well defining the proper

• ntologies in the different system levels K

▪These endeavors are complex, not mature enough and require a lot of human expertise K

Clustering

58

▪ Clustering algorithms are generally used for service identification by matching candidate sets of legacy system features (or classes in the case of object

• riented systems) with targeted business rules or

depending on a fitness function

• Z. Zhang, R. Liu, and H. Yang, “Service identification and packaging in service oriented reengineering.” in SEKE, vol. 5, 2005, pp. 620–625

Revues

Author defined heuristics based techniques

5 9

▪Heuristic based Algorithms: A formal approach to problem solving based on heuristic rules ▪Approaches based on clustering algorithms, service quality metrics (coupling, cohesion,

• etc. ), or a mix of them.

▪The challenge = Well defining the heuristics to efficiently identify reusable services

• S. Adjoyan, A.-D. Seriai, and A. Shatnawi, “Service identification based on quality metrics.”

Fitness function generation

Revues

Author defined heuristics based techniques

6

▪Heuristic based with agglomerative clustering technique based on quality metrics is applied in order to get the migrated web services architecture based on maximizing the fitness function. ▪Only a small case study was considered ▪Human expertise needed ▪Subjective final choice of cutting point level

Revues

Genetic Algorithms based example

6 1

▪ Considering both static and dynamic relationships between classes

• H. Jain, H. Zhao, and N. R. Chinta, “A spanning tree based approach to identifying web services,” International Journal of Web Services

Research, vol. 1, no. 1, p. 1, 2004.

Genetic Algorithms based example

6 2

• H. Jain, H. Zhao, and N. R. Chinta, “A spanning tree based approach to identifying web services,” International Journal of Web Services

Research, vol. 1, no. 1, p. 1, 2004.

▪ 5 possibles solutions ▪What is the best solution ??? High cohesion + low coupling

Targeted quality metrics

Service identification directions

Service identification directions

• Top-down process start by targeting high level artifacts

by performing domain analysisand 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

Service identification directions

• 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

SI directions

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

SI automation degree

Analyses Types

Types of services

• Business services: they correspond to business processes or use cases.

Theseare the services that are generally consumed by the end-users; for in- stance a service that enables an on-line booking. To implement businessprocesses, these services compose the capabilities/functions providedby the Enterprise, Application and Entity services

• Entreprise services: they are of finer granular-ity than Business services.

They implement generic business functionsthat are generally reused across different app

• 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

• Stats from the industry
• High concentration on the identification of business and application services
• low concentration on the identification of utility and infrastructure services

Suggested best practices for Service Identification based on the survey results

A- Service identification as a business value driven process

• Services design should be guided by business needs.
• (1) Map the current business process.

(2) watch legacy transactions with the business process to establish what transactions have to work together (high cohesion). (3) identify the services to support the business process. B- Good comprehension of and expertise in legacy software systems

• Separation of concerns
• . A lot of knowledge on lot of different systems

C- Focus on source code

• Legacy source code is the only reliable source of information where conclusions can be drawn from.
• Componetize code based on cyclomatic complexity for example
• Don’t be too granular. It may result in too many services
• Prioritize targeted quality criteria based on the costumer needs

D- Define the idenification direction based on the availbale artifacts

79

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 Ø Consider 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) Sevice Composition and orchestration

(1) (2)

Implementation

• Choice of service technologies:
• SOAP
• REST
• Service Component Architecture
• Microservices

Implementation

Microservice

• Small Independent services
• Each microservice runs in a process and communicates via a lightweight protocol, most often based
• n HTTP resource
• Consistency and logic of the system: any service must correspond to a specific feature;
• Specificity of the features: each service does only one thing and it does it well;
• Service autonomy: each service has its own code, manages its own data and does not share them

(not directly anyway) with other services;

• Loose coupling: each microservice must not include a strong link with another microservice.

There is no standard for microservice :(

SOA vs Microservices

SOA Microservice architecture

Built on the idea of “share-as-much-as-possible” architecture approach Built on the idea of “share-as-little-as-possible” architecture approach Uses enterprise service bus (ESB) for communication Uses less elaborate and simple messaging system Supports multiple message protocols Uses lightweight protocols such as HTTP/REST & AMQP Use of containers (Dockers, Linux Containers) less popular Containers work very well in MSA Maximizes application service reusability More focused on decoupling Uses traditional relational databases more often Uses modern, non-relational databases DevOps / Continuous Delivery is becoming popular, but not yet mainstream Strong focus on DevOps / Continuous Delivery Coarse-grained / fine grained services Only fine grained services

Legacy-To-SOA migration process

Deployment

• The goal is to ensure that the SOA environment works

reliably and efficiently

• Life cycle management of a service
• Security - authorization of the request, encryption and

decryption as required, validation, etc.

• Deployment and redeployment (moving) of the service
• ver the network for performance reasons, redundancy for

availability or other reasons

• Maintenance - management of new versions of the service
• TEST of services

Service Testing Tools

Interview Session

Interview Session

Interview Session

Interview Session

Interview Session

Interview Session

Interview Session

Interview Session

• 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 services identified

• 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!