ForeverSOA: Towards the Maintenance of Service-Oriented Architecture (SOA) Software

(1)

SQM 2009 Dept. of Computer Science, University of Ioannina, Greece

Dionysis Athanasopoulos, PhD student

In collaboration with A. Zarras, V. Issarny

ForeverSOA: Towards the Maintenance of

Service-Oriented Architecture (SOA)

(2)

Agenda

1. Introduction

2. Conventional use of design principles in SOA 3. Refinement of design principles in SOA

4. Overview of ForeverSOA 5. Conclusions – Future work

(3)

Introduction

 Service-Oriented Architecture (SOA) is an

architectural style that is the answer to the requirements for loosely-coupled distributed computing systems

 The basic architectural elements of SOA are the services  Services are autonomous systems that have been

developed independently from each other.

 SOA software is built by composing services

(4)

Introduction

 Until now, state of the art

research has focused on issues concerning the construction

phase (Design, Implementation) of SOA

We focus on the maintenance phase of SOA software

(5)

Introduction

 Maintenance is even more important for SOA

software due to:

 independent evolution of services

 variation in their quality (performance, availability,

reliability)

(6)

Introduction

 Fundamental design principles generally improve the

quality of conventional Object-Oriented (OO)

software

 ... maintainability, in particular....

 OCP (Open Closed Principle),

 DIP (Dependency Inversion Principle),  LSP (Liskov Substitution Principle), ...

 The issue is whether we can apply them in realistic

SOA maintenance scenarios?

(7)

Introduction

 To address this issue:

 We examine the conventional use of the fundamental

design principles in realistic SOA maintenance scenarios

 We discuss why this conventional use is not effective

 So, we propose the refined design principles such that

their use in SOA becomes effective

 We sketch the ForeverSOA infrastructure which aims to

facilitating the adoption of the refined principles 7

(8)

Agenda

1. Introduction

2. Conventional use of design principles in SOA

3. Refinement of design principles in SOA 4. Overview of ForeverSOA

5. Conclusions – Future work

(9)

Design principles in OO

 OCP:

 states that software should be open for extensions and closed to

modifications

 Achieving OCP can rely on DIP & LSP principles  DIP:

 states that higher level OO software elements should not depend on

lower level software elements, they should depend on abstractions

 LSP:

 formalizes correctness criteria guaranteeing that software that uses

elements of a particular type can further use elements of another type

(10)

Conventional use of principles

 SOA development:

1. Service provider:

1. defines an abstraction element (service interface) for each

software responsibility

2. develops a concrete implementation for every service

interface hopefully with respect to LSP

2. Service client:

 develops, as suggested by DIP, the client software using

references to service interfaces without depending on particular implementations

(11)

Conventional use of principles

 Example:

 SOA client manipulates information about scientific

publications

 It uses a Web search engine (e.g. Citeseer ) for publications

that is exposed via a Web service interface 11

public class ClientApplication { public static void main(String args[]){

CiteseerWSInterface ref = new CiteseerWSSOAPBindingStub(url);

//……….

String publications = ref.cis(args[0]);

} }

(12)

Conventional use of principles

 A maintenance scenario:

 Problem:

 If the requirements of the SOA client are no longer satisfied

by this Citeseer service implementation… 12

Necessity of maintenance

CiteseerWSInterface ref = new CiteseerWSSOAPBindingStub(url);

//……….

} }

(13)

Conventional use of principles

 A maintenance scenario:

 Solution:

 the Citeseer service provider must extend the implementation

hierarchy with a new Citeseer service implementation

13

Hypothetically, it is extended by the Citeseer provider

(14)

Conventional use of principles

 Nothing should be changed into SOA client code except

for url

14

public class ClientApplication {

public static void main(String args[]){

CiteseerWSInterface ref = new CiteseerWSSOAPBindingStub(url); //……….

//……….

String publications = ref.cis(args[0]); }

}

… Is this solution via the conventional use of the principles practical?

(15)

Conventional use of principles

 It is unrealistic for a SOA client to require from a service

provider to develop a new service implementation

15

(16)

In practise...

 Typical Maintenance scenario:

 The same problem:

 If the requirements of SOA client are no longer satisfied by

the Citeseer service implementation … 16

(17)

In practise...

 Typical Maintenance scenario:

 Solution:

 SOA client discovers another service that offers the same

functionality via a different interface (e.g. Googlescholar)

(18)

In practise...

The changes into SOA client code will not be minimal …

since Citeseer, Googlescholar have different interfaces

18

public class ClientApplication {

public static void main(String args[]){

CiteseerWSInterface ref =

new CiteseerWSSOAPBindingStub(url);

//……….

} }

 So, the conventional use of principles is not effective

 How can we refine the principles to deal with such realistic

(19)

Agenda

1. Introduction

2. Conventional use of design principles in SOA

3. Refinement of design principles in SOA

4. Overview of ForeverSOA 5. Conclusions – Future work

(20)

Refinement of principles in SOA

 Refined OCP:

 SOA software that uses a service can be extended

towards using another service offering the same

functionality possibly via a different interface

 The extension of SOA software should involve minimum

modifications

 To achieve the refined OCP, we should refine DIP:

 SOA Client software should not depend on particular

service interfaces but it should depend on abstractions

beyond service interfaces

(21)

Refinement of principles in SOA

 Typically, service abstractions beyond service interfaces aren’t defined by the service providers

 Then, our challenge is to derive:

 A systematic reverse engineering process that extracts service abstractions out of existing services that offer the same

functionality possibly via different interfaces

 This abstraction recovery process should respect LSP which must hold between the recovered abstractions and the service interfaces

 The objective of ForeverSOA is to facilitate this

abstraction recovery process

(22)

Refinement of principles in SOA

22

1 public class Application {

2 public static void main(String args[]){

3 SearchEngineAdaptor ref = new SearchEngineAdaptor();

4 //……….

5 ref.configure(args[0]);

6 //……….

7 String publications = ref.search(args[1]);

8 }

9 }

 Given the Citeseer & Googlescholar services, the recovery process should be able to

extract a generic search engine interface  The client should be developed with respect

to the generic search engine

SearchEngine ref = new

SearchEngineSOAPBindingStub(url);

//……….

} }

(23)

Refinement of principles in SOA

23

 Finally, an implementation of the generic search engine should be generated.

 This implementation should provide access to any of the two services

 This is a typical use of the adaptor design pattern

SearchEngine ref = new

SearchEngineSOAPBindingStub(url);

//……….

} }

1 public class Application {

2 public static void main(String args[]){

3 SearchEngineAdaptor ref = new SearchEngineAdaptor();

4 //……….

5 ref.configure(args[0]);

6 //……….

7 String publications = ref.search(args[1]);

8 }

(24)

Agenda

1. Introduction

4. Overview of ForeverSOA

5. Conclusions – Future work

(25)

ForeverSOA infrastructure

25

client application

developer service provider

ForeverSOA Registry

+discover service abstraction _{+publish service}

Service Abstraction

AbstractionRecovery / Clustering Mechanism

* +output * Service Group ** * +manages * 1 1 1 1 Service * +input * ** Service Abstraction Code Generation * +input *

Service Abstraction Adaptor * +output * Service * +input * * 1 * 1 Clustering mechanism:

1. Groups of similar services

2. Produces a recovered abstract interface

for each group

Code generation mechanism:

Produces an adaptor

accessing the services that realize an abstract interface

(26)

ForeverSOA infrastructure

26

client application

developer service provider

ForeverSOA Registry

+discover service abstraction _{+publish service}

Service Abstraction

AbstractionRecovery / Clustering Mechanism

* +output * Service Group ** * +manages * 1 1 1 1 Service * +input * ** Service Abstraction Code Generation * +input *

Service Abstraction Adaptor * +output * Service * +input * * 1 * 1

ForeverSOA Registry manages information about: 1. Available services

2. Client applications that use these services 3. Groups of services

(27)

Agenda

1. Introduction

4. Overview of ForeverSOA

5. Conclusions – Future work

(28)

Wrap-up

 We showed that the conventional use of the design

principles is insufficient to address maintainability in SOA

 We argued about the need to adapt/refine these

principles to address realistic maintenance scenarios

 We proposed an approach that relies on a reverse

engineering process to enable the adoption of the refined principles in the development of SOA

(29)

Future work

 We are in the process of developing the main mechanisms of the ForeverSOA approach

 We also investigate the potential of employing

further OO design principles in the context of SOA

such as the Single Responsibility Principle (SPR) and the Interface Segregation Principle (ISP).

(30)

Questions?

(31)

Appendix

(32)

Liskov Substitution Principle (LSP)

 In OO languages, if class B is a subtype of class A,  then all member functions of B must return the same or

narrower set of types as A; the return type is said to be

covariant.

 the member functions of B must take the same or broader set of arguments compared with the member functions of A; the argument type is said to be contravariant.

 a precondition is a condition that must always be true just prior to the execution of some section of code.

 a postcondition is a condition that must always be true after the execution of some section of code.