ForeverSOA: Towards the Maintenance of Service-Oriented Architecture (SOA) Software Dionysis Athanasopoulos, PhD student In collaboration with A. Zarras, V. Issarny SQM 2009 Dept. of Computer Science, University of Ioannina, Greece
Agenda 2 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
Introduction 3 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
Introduction 4 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
Introduction 5 Maintenance is even more important for SOA software due to: independent evolution of services variation in their quality (performance, availability, reliability)
Introduction 6 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?
Introduction 7 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
Agenda 8 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
Design principles in OO 9 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
Conventional use of principles 10 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
Conventional use of principles 11 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 public class ClientApplication { public static void main(string args[]){ CiteseerWSInterface ref = new CiteseerWSSOAPBindingStub(url); //. String publications = ref.cis(args[0]); } }
Conventional use of principles 12 A maintenance scenario: Problem: If the requirements of the SOA client are no longer satisfied by this Citeseer service implementation Necessity of maintenance public class ClientApplication { public static void main(string args[]){ CiteseerWSInterface ref = new CiteseerWSSOAPBindingStub(url); //. String publications = ref.cis(args[0]); } }
Conventional use of principles 13 A maintenance scenario: Solution: the Citeseer service provider must extend the implementation hierarchy with a new Citeseer service implementation Hypothetically, it is extended by the Citeseer provider
Conventional use of principles 14 Nothing should be changed into SOA client code except for url 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?
Conventional use of principles 15 It is unrealistic for a SOA client to require from a service provider to develop a new service implementation Unrealistic development
In practise... 16 Typical Maintenance scenario: The same problem: If the requirements of SOA client are no longer satisfied by the Citeseer service implementation
In practise... 17 Typical Maintenance scenario: Solution: SOA client discovers another service that offers the same functionality via a different interface (e.g. Googlescholar)
In practise... 18 The changes into SOA client code will not be minimal since Citeseer, Googlescholar have different interfaces public class ClientApplication { public static void main(string args[]){ CiteseerWSInterface ref = new CiteseerWSSOAPBindingStub(url); //. String publications = ref.cis(args[0]); } } So, the conventional use of principles is not effective How can we refine the principles to deal with such realistic maintenance scenarios without code changes?
Agenda 19 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
Refinement of principles in SOA 20 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
Refinement of principles in SOA 21 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
Refinement of principles in SOA 22 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 public class ClientApplication { } public static void main(string args[]){ } SearchEngine ref = new SearchEngineSOAPBindingStub(url); //. String publications = ref.cis(args[0]);
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 public class ClientApplication { } public static void main(string args[]){ } SearchEngine ref = new SearchEngineSOAPBindingStub(url); //. String publications = ref.cis(args[0]);
Agenda 24 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
ForeverSOA infrastructure 25 Clustering mechanism: 1. Groups of similar services 2. Produces a recovered abstract interface for each group client application developer service provider Code generation mechanism: Produces an adaptor accessing the services that realize an abstract interface +discover service abstraction +publish service ForeverSOA Registry +manages Service Group 1 * * AbstractionRecovery / Clustering Mechanism Code Generation * Service 1 Service Abstraction +input Service * +input * Service Abstraction * +output Service Abstraction Adaptor * +input +output * * 1
ForeverSOA infrastructure 26 ForeverSOA Registry manages information about: 1. Available services 2. Client applications that use these services 3. Groups of services 4. Abstract interfaces for each group client application developer service provider +discover service abstraction ForeverSOA Registry +publish service +manages Service Group 1 * * AbstractionRecovery / Clustering Mechanism Code Generation * Service 1 Service Abstraction +input Service * +input * Service Abstraction * +output Service Abstraction Adaptor * +input +output * * 1
Agenda 27 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
Wrap-up 28 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
Future work 29 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
Liskov Substitution Principle (LSP) 32 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.