Dynamic System Configuration using SOA

Saxion Hogeschool Enschede

Thesis

Dynamic System Configuration using SOA

Version 1.0

Contractors:

Jeroen [email protected]

Lesley [email protected]

Supervisors:

Richard van der [email protected]

Ferenc [email protected]

Douwe van [email protected]

Abstract

Thales uses a static configuration to map software components to hardware compo-nents. In case of hardware failures, this mapping has to be adapted manually to restorethe system. This requires the system to be inoperative for a significant amount of time,which isn’t acceptable in the mission critical systems Thales builds. Thales feels they werenot technologically able to find a solution for this problem in the past, but they now seean opportunity to tackle the problem using the principles and patterns of service orientedarchitectures (SOA). To recover the system, processes which ran on failed processing nodescould be moved to available processing nodes. A SOA layer has been defined on top ofthe radar chain model to coordinate the process of restoring the system. This SOA layer isrealized using the SOA based OSGi framework and the R-OSGi extension.

Hengelo, December 22, 2009

Change log

Version Date Modifications

0.1 2009-02-09 Initial version0.2 2009-03-13 Distributed Systems, SOA characteristics0.3 2009-04-17 Case Study Radar Chain Case, SOA principles and patterns0.4 2009-05-08 Introduction, Systematic Approach chapter0.5 2009-05-25 Background, Assignment, Problem Analysis, Solution, Design

and Implementation1.0 2009-06-01 Summary, Conclusion, Retrospective

1

Samenvatting

Deze scriptie is geschreven in het kader van een afstudeerproject bij luminis in de klantcontextvan Thales. Thales gebruikt zeer omvangrijke gedistribueerde systemen om de ingewikkeldeberekeningen uit te voeren die te pas komen bij het verwerken van radarsignalen. De mappingvan software componenten op hardware componenten in deze radarketen vindt plaats op basisvan een statische configuratie. Als er componenten uitvallen in het systeem of er veranderingenin de configuratie plaatsvinden, dient deze mapping in de huidige situatie handmatig aangepastte worden, waardoor het systeem voor een significant tijdsbestek inoperatief is. Dit is onac-ceptabel in de kritieke systemen die Thales gebruikt, zoals de hierboven beschreven radarketen.Derhalve is in dit afstudeerproject onderzoek gedaan naar de mogelijkheden van service orientedarchitecture (SOA) om (her)configuratie dynamisch te laten plaatsvinden, waarbij de focus lagop de representatieve Thales radarketen.

In een gedistribueerd systeem, zoals de radarketen, kunnen er hele andere problemen optredendan in een volledig lokaal systeem. Een slecht ontworpen gedistribueerd systeem kan volledig platkomen te liggen doordat er een component uit is gevallen. Componenten dienen te allen tijdebeschikbaar te zijn en zo min mogelijk last te hebben van het uitvallen van andere componenten.Met deze gegevens dient er in het ontwerp van een dynamisch configureerbaar gedistribueerdsysteem rekening gehouden te worden. Bij het ontwerpen van het systeem passen we een aantalprincipes en patterns van SOA toe. SOA is een architectueel paradigma binnen software designdat gebaseerd is op samenwerkende services die een bepaalde taak uitvoeren. Een aantal SOApatterns lossen verschillende subproblemen op die we tegenkomen bij het ontwerpen van eendynamisch configureerbaar gedistribueerd systeem. Het lookup pattern helpt bij het vinden vanbeschikbare services; met behulp van het leasing pattern kan gedetecteerd worden of servicesinactief worden en met het whiteboard pattern kan de levenscyclus van componenten consequentbeheert worden. In een logisch ontwerp definieren we een aantal SOA services om dynamischeconfiguratie mogelijk te maken.

Voor de implementatie van een proof-of-concept is gebruik gemaakt van het op SOA gebaseerdeOSGi framework in combinatie met R-OSGi, een extensie van OSGi. OSGi biedt ons een aantalvan de benodigde faciliteiten die gedefinieerd zijn in het logisch ontwerp. Zo zorgt de OSGiModule layer dat de afzonderlijke componenten ongevoelig zijn voor het falen van andere com-ponenten; de Life cycle layer voor dynamisch beheren van de levenscyclus van componenten ende WireAdmin voor het dynamisch configureren van de verbindingen tussen componenten.

R-OSGi implementeert het Service Location Protocol (SLP), waardoor het ook mogelijk is omservices op andere processing nodes binnen een netwerk te lokaliseren en te gebruiken. Daar-naast biedt R-OSGi de zogeheten RemoteEvents welke door middel van broadcasting kunnenworden verzonden om andere services binnen een netwerk op de hoogte te stellen van bepaaldegebeurtenissen, zoals het wegvallen van een zekere service. Het logisch ontwerp is vertaald naareen oplossing binnen het OSGi model.

In eerste instantie is er een implementatie gemaakt van een vereenvoudigde weergave van deThales radarketen, waarin faal scenario’s gesimuleerd konden worden. Vervolgens is het logischontwerp geımplementeerd bovenop het OSGi framework, zodat het systeem dynamisch confi-gureerbaar was binnen een lokale machine. Tenslotte is het systeem aangepast met behulp vanR-OSGi, waardoor herconfiguratie ook mogelijk was in een gedistribueerde omgeving.

2

Summary

This thesis is written as a part of the graduation internship at luminis in the client context ofThales. Thales uses very large distributed systems to make complicated computations which areneeded for the processing of radar signals. The mapping of software components to hardwarecomponents in this radar chain is based on a static configuration which has to be adapted man-ually in case of failures. As a result the system could be inoperative for a significant amount oftime, which isn’t acceptable in the critical systems Thales uses, such as the so-called radar chain.In this project research to the possibilities of service oriented architecture (SOA) for dynamic(re)configuration has been carried out while we focused on the representative Thales radar chain.

A distributed system such as the radar chain can pose quite different problems than a fully localsystem. A poorly designed distributed system could crash completely if one component hasfailed. Components should be available at all times and be fault-tolerant with regard to failuresof other components. These aspects have to be taken into account while designing a dynamicconfigurable distributed system. In the design of the system several principles and patterns ofSOA are applied. SOA is an architectural paradigm in software design based on interoperableservices which perform a certain task. Several subproblems we face while designing the systemare solved by SOA patterns. The lookup pattern allows finding available services; the leasingpattern provides detection of services becoming inactive and the whiteboard pattern allows con-sequent life cycle management of components. In a logical design a set of SOA services isdefined to allow dynamic configuration.

The SOA-based OSGi framework and the R-OSGi extension have been used to implement aproof-of-concept. OSGi provides several capabilities defined in the logical design. The OSGiModule layer allows components to be fault-tolerant; the Life cycle layer provides dynamic lifecycle management and the WireAdmin allows dynamic wiring between components.

R-OSGi implements the Service Location Protocol (SLP) which allows finding and using re-mote services within a network. Additionally, R-OSGi provides RemoteEvents which could bebroadcasted to notify other services within a network of certain events, such as the failure of aparticular service. The logical design is translated to a solution within the OSGi model.

Firstly, a simplified model of the Thales radar chain is implemented, as such fail scenarios couldbe simulated. Secondly, the logical design is implemented on top of the OSGi framework sothe system was dynamic configurable on a local machine. Finally, the system has been adaptedusing R-OSGi for integration in distributed environments.

3

Preface

This thesis is written as part of the documentation of the graduation internship of Jeroen Rosen-berg and Lesley Wevers. This internship is part of the study in computer science provided bySaxion Hogescholen in Enschede, the Netherlands. The thesis work has been carried out fromFebruary 2009 to June 2009 at the Surface Radar Department of Thales Hengelo, and consistedof one paper and a developed prototype as a proof-of-concept. This thesis marks the end of ourstudy.

The following people are acknowledged for their assistance: Ing. D.A. van Twillert, R. van derLaan, F. Schopbarteld and R. van Hees. We wish to take this opportunity to express our grati-tude to Ir. J.W.M. Stroet and Mr. dr. H.J.A. Mentink for support, advice and encouragementthrough ups and downs.

Hengelo, June 2009

Lesley WeversJeroen Rosenberg

4

CONTENTS CONTENTS

Contents

Samenvatting 2

Summary 3

Preface 4

1 Introduction 91.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2 Client and organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3 Document structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

I Problem Analysis & Assignment 11

2 Problem analysis 122.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2 Case Study: The Thales Radar Chain . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 System context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.2 System components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3 Problem definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4 Research questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Assignment 183.1 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 Study scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.1 Solution criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.2 Outside the scope of this study . . . . . . . . . . . . . . . . . . . . . . 19

3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

II Literature Study 20

4 Distributed Systems 214.1 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.3 Challenges and Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5 Service Oriented Architectures 245.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.2 Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.3 Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5

CONTENTS CONTENTS

6 OSGi 336.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.2 Module Layer and Fault-Tolerance . . . . . . . . . . . . . . . . . . . . . . . . 346.3 Lifecycle Layer and Dynamic Life Cycle Management . . . . . . . . . . . . . . 346.4 Service Layer and Service Discovery . . . . . . . . . . . . . . . . . . . . . . . 356.5 Event Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.6 Wiring of Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.7 R-OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.7.1 Remote Service Discovery . . . . . . . . . . . . . . . . . . . . . . . . . 376.7.2 Using Remote Services through Dynamic Proxies . . . . . . . . . . . . 376.7.3 Remote Event Handling . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

III Solution Approach & Analysis, System Design & Implementation 40

7 Solution approach 417.1 Analysing a naive solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417.2 Solution proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427.3 Prototype considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427.4 Conlusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

8 Solution analysis 438.1 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

8.1.1 System instantiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438.1.2 Restoring the system . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

8.2 Use-case analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468.2.1 Use-case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468.2.2 Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478.2.3 Administrator use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 478.2.4 Configuration system use-cases . . . . . . . . . . . . . . . . . . . . . . 47

8.3 Secundairy use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

9 System design 509.1 Design challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509.2 Service decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519.3 Service interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519.4 Service capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529.5 Service descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

10 System implementation 5510.1 Process and link implementations . . . . . . . . . . . . . . . . . . . . . . . . . 55

10.1.1 Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5610.1.2 Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5610.1.3 Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

10.2 Configuration system local implementation . . . . . . . . . . . . . . . . . . . . 57

6

LIST OF FIGURES LIST OF FIGURES

10.2.1 OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5710.2.2 OSGi service mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 5710.2.3 OSGi bundles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5810.2.4 Service implementations . . . . . . . . . . . . . . . . . . . . . . . . . . 5910.2.5 Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

10.3 R-OSGi integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6110.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

IV Conclusion & Recommendations 63

11 Conclusion 6411.1 System recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6411.2 Service oriented architecures . . . . . . . . . . . . . . . . . . . . . . . . . . . 6411.3 OSGi and R-OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6511.4 Final conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

12 Recommendations 6712.1 Applying the study results to the O2 framework . . . . . . . . . . . . . . . . . 6712.2 Remove single point of failures . . . . . . . . . . . . . . . . . . . . . . . . . . 6712.3 Code provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6712.4 Dynamic configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

References 69

Glossary 70

Appendices 72

A Sequence diagrams 73A.1 Service lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73A.2 Mapping service start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74A.3 Process service lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75A.4 Processing node start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76A.5 Processing node goes down . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77A.6 Software system specification changed . . . . . . . . . . . . . . . . . . . . . . 78

List of Figures

1 A high-level overview of the Thales radar chain. . . . . . . . . . . . . . . . . . 122 A more detailed view of the software processing subsystem. . . . . . . . . . . . 133 OSGi Framework layering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 Use-case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 Class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556 Class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587 Service lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738 Mapping Service start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749 Process Service lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7

LIST OF FIGURES LIST OF FIGURES

10 Processing node start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7611 Processing node goes down . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7712 Software system specification changed . . . . . . . . . . . . . . . . . . . . . . 78

8

1 INTRODUCTION

1 Introduction

1.1 Purpose

This document is a final report of our study during the graduation period. The main purposeof this study is to validate the following thesis statement:

Thesis statement. The principles and patterns of service oriented architecture contribute toimplementing a system which can automatically restore the health of a software system instanceafter it has become damaged due to processing nodes becoming unavailable.

1.2 Client and organization

The graduation assignment was commissioned by Thales and is performed in an intensive part-nership with luminis under supervision of Ferenc Schopbarteld from Thales and Richard van derLaan from luminis.

luminis is a free thinking and innovative company which has a wide range of services in the fieldof consulting, coaching, training, application development and software engineering. Richardvan der Laan, the project supervisor on behalf of luminis, is a part of the Software Developmentdepartment, one of the six cores of luminis.

Thales operates in several market segments, from marine radar to eTicketing and security.Within Thales, the software section of the Surface Radar / Technical Unit Processing businessunit is responsible for the development of software for use in radar and optronic systems fornaval and air defense applications.

1.3 Document structure

This document has been structured into four parts which cover different aspects of this study.Each part consists of a number of chapters discussing related matters. Below, a general overviewis provided of the document structure, including a brief description of the content of the chapters.

• Part I: Problem Analysis, Assigment & Approach

– Problem AnalysisThe motivation of the problem is explained, the terminology used in this thesis isdefined, the problem is defined and the research questions are introduced.

– AssignmentThe goal of the project is defined and the scope of the study is defined by definingthe solution criteria and the assumptions which have been adopted during the study.

9

1.3 Document structure 1 INTRODUCTION

• Part II: Literature Study

– Distributed SystemsThe main characteristics and common issues of a distributed system are described.

– Service Oriented ArchitectureThe principles and relevant patterns of Service Oriented Architecture are detailed.

– OSGiThe OSGi framework is explained and solutions of case related issues are provided.Furthermore, the additional solutions provided by the R-OSGi framework are detailed.

• Part III: System Analysis, Design & Implementation

– Solution ApproachThe problem is analysed and a functional solution to the problem is provided.

– Solution AnalysisScenarios for the solution proposed in the previous chapter illustrate the workings ofthe solution. Following, the scenarios are analysed using a use-case analysis.

– System DesignThe design challenges posed by the use-cases are identified. A logical design ofcooperating services conquers these challenges.

– System ImplementationDescribes the mapping of OSGi and R-OSGi to the logical design. Additionally, theimplementation of the prototype is explained and motivated.

• Part IV: Conclusion, Recommendations & Retrospective

– ConclusionThe main research question is answered, conclusions are drawn regarding the suit-ability of service oriented architecture for dynamic reconfiguration and the thesisstatement is validated.

– RecommendationsRecommendations regarding usage of service oriented architecture and future devel-opment are made.

10

Part I

Problem Analysis & Assignment

11

2 PROBLEM ANALYSIS

2 Problem analysis

This chapter analyses the problem posed by Thales. First, the context of the problem is ex-plained. Next, a case which captures the essence of the problem is analysed and the associatedterminology is defined. And finally, based on the case study the problem is defined along withthe main research question.

2.1 Motivation

The Surface Radar department of Thales has developed a generic middleware and service frame-work which goes under the name of O2. Within the O2 framework, hardware systems andsoftware applications can be modelled using UML diagrams and XML. These models can beread and validated by O2 to generate software components (C or Java) which can run on amultitude of platforms. Besides software components, O2 is also able to generate hardwarecomponents (VHDL) for applications demanding high-performance.

For processing radar signals, Thales uses distributed systems running their O2 framework. Thesesystems can contain hundreds of hardware boards on which distributed O2 applications can berun. To instantiate the system, a configuration is defined which maps O2 software componentsto the available hardware boards.

While the system is operational, it is not uncommon for hardware boards to fail. In case thishappens to one of the hardware boards running a crucial O2 component the whole system mayfail, possibly resulting in significant downtime of mission critical systems.

To repair the system in the current situation, a hardware board needs to be replaced and themapping has to be adapted to match the new hardware configuration. As this process may takea while, the system may be down for a significant period of time. This is a serious problem inmission-critical situations, a solution to this problem has to be found.

2.2 Case Study: The Thales Radar Chain

Thales has defined a case which captures the essence of the problem as described in the previoussection. The case is based on an existing O2 based system where the output of a physical radarsystem is processed and transformed to a form which can be displayed on a radar screen. In thissection the case and the terminology will be defined to be used in later chapters.

2.2.1 System context

In a radar chain, a radar system generates data which has to be displayed on a radar screen in aform that is understandable by humans. The complete system can be divided into a number ofsubsystems. Figure 1 provides a high-level overview of the radar chain, showing the subsystemsand the flow of data between them.

Figure 1: A high-level overview of the Thales radar chain.

12

2.2 Case Study: The Thales Radar Chain 2 PROBLEM ANALYSIS

The first subsystem is the physical radar system itself. The radar system picks up an analogsignal of electromagnetic waves and transforms this into a digital signal which can be processedto extract relevant information.

The radar system can generate hundreds of gigabytes of data per second which all needs to beprocessed in realtime. At present this is a lot of data to handle by software running on generalpurpose processors. Thales has chosen to reduce the data stream to a more manageable levelbefore moving to software processing. This first processing step is implemented in hardware asthis allows for much higher processing rates than software implementations.

After this initial processing step, at most a few megabytes of data per second remain to beprocessed, which allows further processing to be performed in the software domain. Softwareprocessing is performed on a distributed system to distribute the workload onto multiple pro-cessing nodes. This part of the system will be referred to as the software processing subsystem.

The final step in the radar chain is to actually do something with the processed data. The datacan for example be visualized and send to a screen for an operator to view.

The problem, which is introduced in the next chapter, revolves mainly around the softwareprocessing subsystem. The details of the other subsystem are not in the scope of this studyand they will therefore not further be discussed. The next section will continue by defining thesoftware processing system in more detail.

2.2.2 System components

As noted in the previous section, this case study will primarily focus on the software processingsubsystem. This section will define the elements of which this subsystem consists. Also, therelations between these elements will be defined, together providing a global overview of thearchitecture of this subsystem.

Figure 2: A more detailed view of the software processing subsystem.

The software processing subsystem can broadly be divided into two domains, the hardwaredomain containing physical hardware, and the software domain containing the software elements.

13


Hardware domain

The software processing subsystem’s hardware domain consists of processing nodes which areinterconnected by physical connections. A processing node is a physical hardware board capableof running processes from the software domain.

A processing node is considered to be available if it is able to host processes, or already hostingprocesses. Otherwise, the processing node is considered to be unavailable. A processing nodemay become unavailable at any time due to hardware failures or by an administrator turning thesystem off.

A collection of interconnected processing nodes is called a hardware system. The topology of ahardware system may change during operation of the system in the event of processing nodesbecoming available or unavailable.

For the purpose of this case, it can be assumed that all processing nodes within a hardware systemare able to communicate with eachother at all times. Processing nodes can’t get isolated by thenetwork failing and processing nodes are always connected to the network while they are in anunavailable state.

Software domain

The software processing subsystem’s software domain consists of the non-physical elements thatmake up a system. For the purpose of this case, the software domain consists of processes andlinks which together form a software system.

• Process A process is a unit of software which can accept input on an input port andwhich can produce output on an output port.

For every process in a software system, a process configuration is available. The processconfiguration contains a name which unique identifies a process, and the name of theruntime which implements the functionality of the process. Based on this configuration, aprocess instance can be instantiated on a processing node. A process is considered to beinstantiated if a process instance exists for the process, otherwise the process is consideredto be uninstantiated. For the purpose of this case, it can be assumed that processes canonly be instantiated once.

A process instance can be destroyed to make a process uninstantiated. Also, if a pro-cessing node becomes unavailable, the processes running on it get destroyed and becomeuninstantiated.

• LinkA link is a connection between the output port of one process to the input port of anotherprocess. A link allows a data stream to be set up between two processes. The processproducing the output is defined as the producer of the link, and the process acceptingdata is defined as the consumer of the link.

14


For every link in a software system, a link configuration is available. This link configura-tion specifies the name of the producer process and the name of the consumer process.If the producer process is instantiated, a link instance can be instantiated by making theproducer process send its output to the address of the consumer process’s input port.

If a link instance is available for a link, the link can be considered to be instantiated,otherwise the link is uninstantiated. A link can further be considered valid or invalid. Ifboth the producer process and the consumer process of a link are instantiated, the link isvalid. If one of both processes of the link is not instantiated, the link is invalid.

A link can be instantiated and invalid at the same time, in this case the producer processof the link is still sending its output to the previous location of the consumer process, butthe consumer process is no longer instantiated. Furthermore, if an uninstantiated link isvalid, it can be instantiated to set up a data stream between the processes.

A link instance is considered to be healthy if the link it represents is valid, otherwise thelink instance is considered to be damaged. A healthy link instance becomes damaged ifthe consumer process becomes uninstantiated.

A link instance can be destroyed to make a link become uninstantiated. This is accom-plished by making the producer process stop sending its output to the consumer process.Also, a link instance gets destroyed if the producer process becomes uninstantiated.

• Software systemA collection of processes and links which make up a processing chain is defined as a soft-ware system.

The configuration of a software system is defined by a software system specification con-sisting of a collection of process configurations and link configurations.

Based on a software system specification, a software system instance can be instanciatedby instantiating processes for all process configurations, and instantiating links for all linkconfigurations. If a software system instance is instantiated for a software system, thesoftware system is considered to be instantiated, otherwise it is uninstantiated.

A software system instance is considered to be healthy if all processes and links, as definedin the software system configuration, are instantiated, and all link instances are healthy.If this is not the case, the instance is considered to be damaged.

When a software system instance is created, at first all processes and links are uninstan-tiated. This means that a software system instance always starts in a damaged state.Bringing a software system instance from a damaged state to a healthy state is definedas recovering the software system instance.

15

2.3 Problem definition 2 PROBLEM ANALYSIS

2.3 Problem definition

To instantiate a software system, the processes and links as specified in a software system speci-fication need to be be mapped onto available processing nodes. In the current situation, Thalesdefines this mapping in a static configuration of hardware components and software compo-nents. In case the configuration of software components or hardware components changes, themapping has to be adapted manually to match the new configuration.

While a software system instance is operational, the processing nodes it is instantiated on maybecome unavailable due to hardware failures. This causes any processes running on these pro-cessing nodes to become uninstantiated, resulting in a damaged software system instance. Torestore the software system instance back to a healthy state, its processes and links which havebecome uninstantiated have to be instantiated again, and link instances which have becomedamaged have to become healthy again.

In the current situation, a failed processing node has to be replaced and configured to performthe tasks of the processing node it is replacing. After replacing the failed processing node, thesystem becomes healthy again. Thales wants the radar systems to be more reliable in the eventof processing nodes becoming unavailable. In case of the software processing subsystem, thismeans downtime of software system instances need to be minimized in the event of a processingnode becomes unavailable. To accomplish this, Thales wants a software system instance to beable to recover by itself automatically in case of processing nodes becoming unavailable.

The problem to be solved to get from the current situation to the desired situation can now bedefined as follows:

“How can a software system instance be automatically restored to health after it has becomedamaged due to processing nodes becoming unavailable?”

Thales feels they were not technologically able to handle this problem in the past, so no workhas been done yet to solve the problem. They now see an opportunity to tackle the problem bythe use of the principles and patterns of service oriented architectures .

A service oriented architecture, or SOA in short, is an architectural style in which related businessprocesses are grouped and packaged as services which can interoperate to coordinate actions.Over the past years, SOA has been widely adopted in the industry and as such principles andpatterns have started to emerge to solve common design problems. Some of the principles andpatterns of SOA might be helpful to solve the problem.Thales wants to know how a system can be implemented to solve the problem just defined,which incorporates the patterns and principles of SOA. The problem to be solved can now bedefined as follows:

“How can a system be implemented, based on the principles and patterns of SOA, which canautomatically restore the health of a software system instance after it has become damaged dueto processing nodes becoming unavailable?”

16

2.4 Research questions 2 PROBLEM ANALYSIS

2.4 Research questions

Now the problem is defined, additional sub-questions rise. Below is an overview of the sub-questions we’re about to answer in the upcoming chapters.

Which techniques and implementations could contribute to implementinga system to solve the problem?

Par

tII

What characterizes a distributed system such as the Thales radar chain?

What is service oriented architecture?

How can the principles and patterns of service oriented architecture con-tribute to implementing a system to solve the problem?

Which existing implementations of service oriented architecture could con-tribute to implementing a system to solve the problem?

How can a dynamic configurable system be realized based on the principlesand patterns of SOA?

Par

tII

I

What kind of approach could be taken to restore the health of a damagedsystem?

Which scenarios can be identified?

Which use-cases can be identified?

Which design challenges need to be solved?

How can the principles and patterns of SOA be applied to solve these designchallenges?

How can a system be designed to implement the solution?

How can the system design be implemented?

What conclusions can be drawn based on this study?

Par

tIV

In what ways does service oriented architecture contribute to solving to themain problem?

Which recommendations can be made?

2.5 Conclusion

In this chapter, first the context of the problem was defined. Next, the Thales radar chain casewas introduced in order to define the problem domain and terminology used in this document.Finally, the problem was defined based on the Thales radar chain case.

17

3 ASSIGNMENT

3 Assignment

This chapter describes the assignment as given by Thales. First, the goals of this study aredefined. Next, the scope of the study is defined by specifying the solution criteria, makingassumptions about the problem domain as defined by the Thales radar chain case, and specifyingwhat is outside the scope of this study.

3.1 Goal

The main goal of this study is to determine how a system can be implemented, based on theprinciples and patterns of SOA, to automatically restore the health of a software system instanceafter it has become damaged due to processing nodes becoming unavailable.

To reach this goal, the following partial goals have been defined:

1. Determine how a software system instance can be restored to health after it has becomedamaged due to processing nodes becoming unavailable.

2. Determine how SOA can contribute to implement a system to automatically restore asoftware system instance after it has become damaged due to processing nodes becomingavailable.

3. Design and implement a prototype of a solution based on the principles and patterns ofSOA.

3.2 Study scope

3.2.1 Solution criteria

The solution to be found must adhere to the following criteria:

1. The current architecture as described in the case study should be kept intact as much aspossible.

2. Every distinct piece of data may be only processed once per process

3. The design and implementation must be based on the principles and patterns of SOA.

Further, the following assumptions are made:

1. Processes can run on any processing node.

2. If a processing node is available, it is always connected to all other available processingnodes.

3. A processing node which is already running is never connected afterwards to anotherrunning processing node.

4. Addresses of processing nodes do not change while the system is operational.

5. All processing nodes have access to all runtimes required by processes.

18

3.3 Conclusion 3 ASSIGNMENT

3.2.2 Outside the scope of this study

This study does not deal with the following aspects:

• Multiple software system specifications.

• Management of software system specifications.

• Connections to the exterior of the software processing subsystem.

• Loss of data which is processes by a software system instance.

• Handling of software failures.

• Optimizing system performance by any means.

• Removing single point of failures from the system.

• Applying the system to or integrating the system with any existing technologies.

3.3 Conclusion

In this chapter the assignment given by thales was defined. First, the study goals were defined.Next, the study scope was defined by specifying the solution criteria, assumptions made aboutthe problem and defining what is outside the scope of this study.

19

Part II

Literature Study

20

4 DISTRIBUTED SYSTEMS

4 Distributed Systems

Processing radar signals requires many complicated computations to be performed. To accom-plish this, Thales has distributed these computations throughout hundreds of hardware boards,using a technique called distributed computing. Distributed computing is a form of parallelcomputing and deals with both hardware and software systems containing more than one pro-cessing element, storage element, concurrent process or program. Within distributed computinga program is divided into parts which can run simultaneously on multiple computers within anetwork. Such hardware or software systems are called distributed systems.

The subsequent sections provide a more detailed overview of distributed systems, their charac-teristics and challenges. This chapter thereby attempts to answer the research question:

Research question. What characterizes a distributed system such as the Thales radar chain?

Firstly, the main characteristics regarding distributed computing are detailed. Secondly, (un)handledissues of distributed systems are discussed. These topics are relevant with respect to the Thalesradar chain case.

4.1 Characteristics

A distributed system is not just another name for a network of computers. It is an applicationthat executes a collection of protocols to coordinate the actions of multiple processes on a net-work, such that all components cooperate together to perform a single or small set of relatedtasks. Components in networked computers communicate and coordinate their actions only bypassing messages. A distributed system is build on top of a network, presenting separated com-ponents and multiple computers as if they were a single entity, providing the user, the consumer,whatever services are required.

The main goal of a distributed system is to connect users and resources in a transparent, open(i.e. each subsystem is continually open to interaction with other systems), and scalable way.Ideally this arrangement is drastically more fault-tolerant and more powerful than many combi-nations of stand-alone computer systems.

To accomplish this goal, a few requirements have to be met:

• The system must be extremely robust. For instance, it’s unacceptable that error messageshold up the entire system until required user input is provided.

• Plug and play capability. Additional hardware or software can be instantly added to thesystem, without needing to install them.

• High compatibility. Services and devices can interact with one another without the needof additional configuration.

• Automatic detection of new services or devices (e.g. a camera detects a newly connectedprinter)

21

4.2 Objectives 4 DISTRIBUTED SYSTEMS

4.2 Objectives

Reliability is an important aspect in distributed computing. Because different subsystems in-clude heterogeneous, overlapping and possibly conflicting information (pluralism), the systemhas to deal with concurrency and inconsistency. Besides, executed actions or made publicationscannot be reverted (monotonicity).

To be truly reliable, a distributed system must have certain characteristics, which are summarizedin the listing below. [3, 4, 5] A distributed system needs to be:

Fault-tolerant It can recover from component failures without performing incorrect actions.

Highly available It can restore operations, permitting it to resume providing services even whensome components have failed.

Recoverable Failed components can restart themselves and rejoin the system, after the causeof failure has been repaired.

Consistent The system can coordinate actions by multiple components often in the presenceof concurrency and failure. This underlies the ability of a distributed system to act like anon-distributed system.

Scalable It can operate correctly even as some aspect of the system is scaled to a larger size(e.g. increasing the size of the network, or the number of users).

Predictable performance The ability to provide desired responsiveness in a timely manner.

Secure The system authenticates access to data and services

Extensible Interfaces should be cleanly separated and publicly available to enable easy exten-sions to existing components and add new components.

Interoperable despite heterogeneity Various entities in the system must be able to interop-erate with one another, despite differences in hardware architectures, operating systems,communication protocols, programming languages, software interfaces, security models,and data formats.

4.3 Challenges and Issues

Distributed systems cause problems more frequently than fully local systems. Moreover, someproblem categories aren’t even relevant in local systems, for example (potential) networkingproblems. In the first place, because processes and their required resources are distributedacross the network, the code or the data used by a process needs to be moved over and overagain. This requires compilation and installation respectively uniformity in data formats. Sec-ondly, it can take a lot longer to access remote data, due to latency. Therefore the time thatit will take to complete an operation cannot be bounded in advance (unbounded determinism).Thirdly, partial failures of the network can be a huge problem if the unavailability of a node cancause disruption of the other nodes.

The characteristics listed in the previous section are high standards, which are challenging toachieve. Probably the most difficult challenge is that a distributed system must be able tocontinue operating correctly even when components fail. Services have to be highly available

22

4.4 Conclusion 4 DISTRIBUTED SYSTEMS

and fault-tolerant. A highly available service is one that continues to provide a possibly de-graded service despite a certain number and type of process failures and despite disconnectedoperations. A fault-tolerant service is one that always behaves correctly despite up to a givennumber and type of failures.

To design a distributed system with the characteristics listed in the previous section, one mustdesign for failure. This implies not making any assumptions about the reliability of the com-ponents of a system. Below is a listing of the eight most commonly (yet premature) madeassumptions, better known as the eight fallacies of distributed computing [1, 2].

Eight Fallacies

1. The network is reliable

2. Latency is zero

3. Bandwidth is infinite

4. The network is secure

5. Topology doesn’t change

6. There’s one administrator

7. Transport costs are zero

8. It’s an homogeneous network 1

4.4 Conclusion

This chapter focused on several aspects of distributed systems which are relevant with regardto the Thales radar chain case. We’ve overlooked some important requirements and objectiveswhen designing a distributed system. For the Thales radar chain case, robustness, fault-toleranceand high availability are the most important among these requirements and objectives. The lastpart of this chapter focused on important challenges and issues which should be conquered inour system’s design. Especially the eight fallacies of distributed computing should be taken intoaccount.

1This fallacy was added six years later by James Gosling (inventor of Java).

23

5 SERVICE ORIENTED ARCHITECTURES

5 Service Oriented Architectures

The previous chapter focused on common issues and challenges regarding distributed systemswhich should be taken into account by designing a dynamic reconfigurable system. This chapterdetails about architectural patterns that could be of use while designing such a system. Thischapter thereby attempts to answer the research questions:

Research question. What is service oriented architecture?

Research question. How can the principles and patterns of service oriented architecture con-tribute to implementing a system to solve the problem?

The principles and patterns of service oriented architecture treated in this chapter provide thefirst step to a logical design.

5.1 Overview

Service oriented architecture, or SOA for short, can essentially be defined as an architecturalparadigm in software design which is based on services which interoperate to perform a certaintask. There is no official definition of SOA, but a more elaborate one is stated by OASIS (Or-ganization for the Advancement of Structured Information Standards):

“A paradigm for organizing and utilizing distributed capabilities that may be under the controlof different ownership domains. It provides a uniform means to offer, discover, interact withand use capabilities to produce desired effects consistent with measurable preconditions andexpectations.”

This definition still leaves a lot of gaps to be filled if one wants to implement SOA. As can beseen by studying existing SOA implementations, the vision put forth in existing implementationscan vary greatly for most aspects of this definition.

This chapter will further explore the field of SOA by first looking at the characteristics whichdefine a SOA. The principles for a good SOA design are explained followed by patterns for solvingcommon design problems in SOA. Finally, the key elements of some SOA implementations arediscussed.

5.2 Principles

Services are the building blocks of SOA applications. They are an embodiment of the separationof concerns theory which is based on the notion that large problems become easier to handleas they are broken down into smaller problems. In a way services in SOA are similar to classesin object oriented programming. Using classes to break down a problem into seperate concernworks well on small levels, but as a system gets bigger the shear number of classes can introducea lot of complexity.

Services, however, break problems down on a much more granular level to solve these complexityissues. They provide a collection of related capabilities to service consumers and are called assuch service providers. The definition of a service does not place any limits on what kind ofcapabilities a service can provide. A service could for example provide functionality for user au-thentication, but it could as well provide access to hardware systems to allow service consumers

24

5.2 Principles 5 SERVICE ORIENTED ARCHITECTURES

to perform computations on those systems.

Over the past years, the industry defined a common set of design principles for SOA whichshould make implementing a SOA more successful. Interoperability is fundamental to every oneof these principles and therefore an expected service design characteristic. Moreover, statingthat services should exist implies stating that services should be interoperable. Each of the eightcommon principles supports or contributes to interoperability in a way. These principles andtheir relation to the overarching principle of interoperability will be discussed in the subsequentsections.

Loose Coupling

Coupling implies some kind of connection or relationship between entities, thus, a level of de-pendency. There are numerous types of coupling involved in the design of a service within thecontext of SOA, regarding service contracts, their implementation and service consumers. Theprinciple of loose coupling addresses to reduction (’loosening’) of these dependencies, by thecreation of a specific type of relationship within and outside of service boundaries. By makingthe individual services less dependent on others, they are more accessible for different consumersand interoperability is increased.

Loose coupling could obviously be achieved by detaching the service interface from its underlyingimplementation, but the appropriate level of coupling requires that practical considerations bebalanced against various service design preferences. This includes the independent design andevolution of a service’s logic and implementation while still guaranteeing baseline interoperabilitywith dependent consumers. [19]

Having loosely coupled components also means having a more fault-tolerant system, becausedependencies between components are minimalized. When a single component fails, the othercomponents could still be in a operational state. This is very important in the previouslydescribed Thales radar chain case.

Service Contracts

A service contract communicates the purpose and capabilities of a service and describes how theservice interacts with its consumers. It could be viewed as a composition of functional meta-data and a set of policies, such as security constraints, transport and service level agreements.For instance, security requirements may differ when the service is consumed outside a trustednetwork. Information about services is limited to what is published in service contracts.

A service contract consists of the following components:

Header section including the name, version, owner and type (e.g. process, data, etc. ) of theservice. The name should indicate the functionality of the service in general terms. Thetype helps to distinguish the layer in which the service resides.

Functional section contains the functional requirements, invocation means (e.g. SOAP, REST,Event Trigger, etc.) including the URL and interface, supported operations, methods andactions of the service. The description should be very accurate.

25


Non-Functional section contains security constraints and roles, service level agreement whichdetermines the amount of latency allowed and quality of service which determines theallowable failure rate. Additionally, in case the service is part of a larger transaction themeans to control this should be indicated.

All services within the same repository should use a standardized format for describing a servicecontract to maximize interoperability. Service contracts enable loose coupling by hiding service-internal details from the outside world behind a facade.

Abstraction

A service should never detail about how it goes about its business to meet the requirements ofthe contract. For example, it doesn’t matter which programming language or platform was usedto implement the service, as long as the service sticks to its side of the contract. Abstractingservice details limits all interoperation to the service contract.

By obeying these guidelines, the underlying service logic can be exchanged or evolved indepen-dently of the components which rely on the service. This increases the long-term consistencyof interoperability.

Reusability

Reusability forms the base of key service models. The official definition for this principle states:”Services contain and express agnostic logic and can be positioned as reusable enterprise re-sources.” Individual service capabilities should be appropiately defined in relation to an agnostic(i.e. asserting the uncertainty of all claims to knowledge) service context. Reusability fur-ther requires a high-level of interoperability between the service and several potential serviceconsumers.

Autonomy

The underlying service logic requires a certain autonomy with regard to its execution environ-ment and resources to provide their capabilities in a consistent and reliable way. Increasing thisdegree of control to a significant level leads to minimization or at least reduction of depen-dencies on shared resources. Moreover, it contributes to making the behaviour of the servicemore consistently predictable by simultaneously increasing its reuse potential and thereby itsattainable level of interoperability.

Autonomy on a service level distinquishes service boundaries from one another, although theservice might still share several underlying resources. This can be illustrated, for instance, bya wrapper service that encapsulates a legacy system which is independently utilized from theservice and still shares resources with other legacy based clients.

Autonomy could also be taken one step further, as such the underlying logic is completely ownedby the service. This generally is the case when the supportive service logic has been built fromthe ground up. On the one hand, this obviously is advantageous with regard to scalability.Besides, it provides a more reliable solution to countering the single point of failure (i.e. a partof a system which, if it fails, will stop the entire system from working) risk. This is particularlyrelevant in the previously explored Thales radar chain case, which currently contains such a

26


single point of failure due to its static configuration. Increasing service autonomy could decreasemutual dependency of components of the radar chain and thereby increasing the system’s fault-tolerance. On the other hand, this implies the need of rendering and deployment of new servicelogic, which could increase expenses and efforts.

Statelessness

Services, ideally, are designed to contain state information only when this is explicitly required.Management of this information could namely compromise their availability and undermine theirscalability potential. Therefore, a stateless design allows services to interoperate more frequentlyand reliably. In such a design, adequacy of the surrounding technology architecture to providestate management delegation and deferral options should be taken into account.

Discoverability

The discoverability characteristic of a SOA is meant to help avoiding the accidental creation ofservices that are either redundant or implement redundant logic. Owing to the fact that eachparticular service operation is meant to provide a potentially reusable piece of automation logic,metadata that comes attached to a service must sufficiently describe the functionality offeredby its individual operations in addition to its overall purpose.

Although this particular characteristic is distinct from discoverability on an architectural level,in which case the term service discoverability refers to the technology architecture’s ability toprovide a mechanism of discovery (e.g. a service directory or registry), it is largely consistentwith it. This actually becomes part of the overall infrastructure that is meant to support theimplementation of a SOA.

On a service level, the term discoverability refers to the design of an individual service so discov-erability is maximized, regardless the needs for it in its surrounding implementation environment.Even if there’s no need for a service registry, services should be designed as highly discoverableresources by equipping them with sufficient metadata to properly communicate its purpose andcapabilities. This simply allows services to be more easily located by potential consumers. Be-sides, the evolutionary governance can be better managed when the service portfolio increasesin size. [10, 11]

When looking at the previously posed Thales radar chain case, service discovery could solve theproblem of checking whether all required services are still up and running. This is of particularlyimportance, because all services are essential and if they appear to be down, they should berestarted in some ways.

Discovery mechanism To allow service consumers to access their requested services, it’srequired for them to know how to find and access the service. To accomplish this, the so-calledOffer-Discover-Interact model can be used. This model consists of the following steps:

Offer When a service becomes available, it publishes its services by registering it’s interface, soother entities can make use of them.

Discover Service consumers can find published services by using a discovery mechanism. Usu-ally, a consumer sends a lookup request to a service registry, which contains all available

27

5.3 Patterns 5 SERVICE ORIENTED ARCHITECTURES

services and provides a service interface for the consumer to ’communicate’ with.

Interact The service consumer can now use the published services to accomplish its tasks,through the service interface. The consumer thereby monitors the progress of the service.

These steps can be accomplished by using a service discovery protocol such as the Service Lo-cation Protocol (SLP) or the one provided by the Jini framework. SLP provides a frameworkwhich allows discovering the existence, location and configuration of networked services. Jiniis an open software architecture that enables developers to create services that are adaptableto changes in the network. Its specification offers a standard lookup service, which can bediscovered with a simple API call once running. [15]

The following steps summarize the procedure for using the SLP or Jini lookup service:

1. The address, respectively a connector stub is registered with the lookup service, possiblygiving additional attributes that qualify the connector, and can be used as filters.

2. The client queries the lookup service, and retrieves one or more addresses, respectivelyconnector stubs that match the query.

3. Finally, the client obtains a connector that is connected with the server identified by aretrieved address respectively connects directly to the server using the provided connectorstub.

Composability

Composability of a service addresses its requirement to be capable of participating as an effectivecomposition member, regardless of whether there is a direct need to be listed in a composition.Again, interoperability is an important precondition. In addition, succeeding in meeting thecomposability requirements often depends on the extent to which services are standardized anddata exchange between them is optimized.

5.3 Patterns

As more and more software systems are developed, similar solutions will be used to solve prob-lems which cause patterns to emerge. Just like in object-oriented design, in SOA the samearchitectural problems arise over and over again. In this section we’ll take a look at a couple ofrelevant SOA patterns with regard to the several problems we need to solve.

Lookup

The lookup pattern provides a way of finding and accessing resources, regardless of whetherthey are local or distributed. [12] A resource could initially be anything, for instance a piece ofdata. In the current context, a service is regarded as a resource.

Problem A fundamental problem of resource acquisition is finding the concerning resource (ifavailable) in the first place. Resources could be managed (i.e. adding and removing resources)by resource providers. Such a resource providers could, for example, frequently send broadcastmessages offering available resources, so interested consumers become aware of their existence.

28


Conversely, consumers could send broadcast messages requesting required resources. The con-sumer could then choose the offered resources it needs from all replying resource providers.

Both ways, however, could frustrate efficiency since lots of messages are send across the network(in case of a distributed system). An efficient and inexpensive solution requires [12]:

Availability A resource consumer must be aware of available resources in its environment.

Bootstrapping A resource consumer should be able to obtain an initial reference to a resourceprovider that offers the resource.

Location independence Resource consumers and providers should be able to acquire respec-tively provide a resource, regardless of whether they know each others locations.

Simplicity Resource consumers and providers shouldn’t be burdened.

Solution The lookup pattern addresses this problem by using a so called lookup service as amediating instance. Via this lookup service, the resource provider publishes resources along withdescribing properties. In the same ways, resource providers also register references to themselves,so consumers could retrieve these, search for required resources using the properties, retrieveand finally use these resources. [12]

A Jini lookup services contains service type, id’s and specific attributes of registered services.Consumers search into the lookup service for their desired service, based on type, service id (ifthey happen to know this) or specific attributes. [16].

Leasing

Leasing solves a lot of the problems inherent in distributed computing. Self-healing addressesone of the primary concerns. Distributed systems should function for a long time without needinghumans to make repairs or reconfigurations. A second concern is evolvability (e.g. upgradingthe system). It is out of the question to take the system down for maintenance. Moreover,it isn’t guaranteed every machine is reachable to be upgraded smoothly without failures. Onemust be able to evolve the system incrementally.

Problem At a certain point, a resource user may lose his interest in using the concerningresource. The resource is then needlessly consumed, unless the user releases it by explicitlyterminating its relationship with the provider. This not only negatively affects the performanceof resource user and provider, but may also have a degrading effect on resource availability forother users.

A second problem could occur when dealing with distributed resource users and providers. Whenthe machine of the latter crashes, the resource user, being uninformed about resources becomingunavailable, may continue to reference resources which are no longer available. [12]

Solution The primary idea behind leasing is that a lease holder must establish a continuedproof-of-interest in using some resource, which can be essentially anything, if it is allowed accessto it in the first place. So, for every resource used by some resource user a lease is introduced.This lease is granted by a grantor and obtained by a holder, typically the resource provider

29


respectively the resource user. Additionally, a time duration for usage of the ’reserved’ resourceis specified by the lease.[12] If the lease holder fails to demonstrate interest, the lease expiresand the resource is released.

By granting a lease, the system guarantees that failures will be detected without requiring anyseparate component other than the lease grantor. Leasing also guarantees that irrelevant datawill simply be forgotten when leases expire; it automatically cleans up after failed componentsand the concerning service will be forgotten. This provides also a way to evolve parts of thesystem in isolation. One is free to run a different version of a ’forgotten’ service and plug it in.

In a Jini system, for instance, the lookup service uses time-based resource reservation for storingservice items, called a lease. The grantor of the lease, the lookup service, makes the call,accepting or denying the lease. While a lease is active, the lease holder can cancel it, in whichcase the corresponding resource is also freed. The holder, the service, can renew the lease. Ifthe lease isn’t renewed for a certain amount of time, the service is supposed to be unavailableand will be ’forgotten’ (i.e. the service item will be cleaned up) [16].

Proxy

The proxy pattern lets resource consumers communicate with a representative, rather than tothe resource itself. This straightforwarded principle serves many purposes, such as providingeasier access and protection of unautorized access. [14]

Problem In many cases it is often considered inappropriate to access a component or resourcedirectly. It is undesired to configure their physical location in a static way and unrestrictedaccess to them may be inefficient or even insecure. Additional control mechanisms are neededto ensure access to entities lapses in an efficient, safe and transparent 2 way. In addition, aconsumer should be able to access any component or resource using the same calling behaviourand syntax.

Solution The solution to the problems stated above is to a representative, a so called proxy,to offer the interface of the concerning entity. This representative performs additional pre- andpostprocessing (e.g. access-control, checking or making read-only copies of the original).

In a Jini system, each application uses services through so-called proxies. A proxy allows theprogram to communicate with the service, but shields its details. Proxies are dynamically down-loaded by the consumers of the service. This way, extension of functionality can be accomplishedon-the-fly. Proxies use the same protocol as the backend portion of the service. Consumers areshielded from this information. All they care about is the provided functionality of the service.

One special service, the Lookup Service, keeps track of all the available services and providesaccess to them. Services publish themselves by storing their specific proxy in the lookup service.This publishing process is called join [16]. The Lookup Service now contains a so-called serviceentry, which consists of a unique service id, a proxy and a number of attributes which describethe functionality of the service. Consumers query the lookup service for available services andthe Lookup Service provides the proxy of the requested service (type).

2Full transparency can obscure cost differences between services.

30


Publish-subscribe

Publish-subscribe is an asynchronous messaging paradigm where senders (publishers) of mes-sages are programmed to characterize the messages into classes before posting them, regardlesswhat receivers (subscribers) might or might not read them. Subscribers express interest in oneor more classes, and only receive messages that are of interest, without knowing what publishersposted these messages.

Problem In the traditional tightly-coupled client-server paradigm, the client cannot post mes-sages to the server while the server process is not running, nor can the server receive messagesunless the client is running. This means that system components need to check if a specificservice is up and running each time they want to send a message to it. This unnecessarilyburdens the system.

Solution The solution to the problem stated above is the decoupling of publishers and sub-scribers, which can allow for greater scalability and a more dynamic network topology.

Distributed event-based systems use the publish-subscribe paradigm in which an event-generatingobject publishes the type of events that will be available for other objects. These systems areuseful for communication between heterogeneous components and their asynchronous natureallows publishers and subscribers to be decoupled.

Whiteboard pattern

The whiteboard pattern defines a central application manager to handle dependencies betweenevent sources and event listeners. This straightforwarded principle is of great importance whendealing with dynamic behaviour of system components.

Problem The most relevant but not so obvious issue with the traditional Listener pattern isthe dependency that is created between the event source and the listener. This is called the lifecycle issue: If the event source goes away, the listener must clean up any references it holds andvice versa. This removal phase is hard to verify. It is often not handled at all in workstationenvironments, where an application is started by the user, because management of listenersis a non-issue and will be handled when exiting the application. However, when dealing withcontinuously running applications in a dynamic environment, as in the Thales radar chain case,consequent life cycle management is extremely important.

Solution Applying the whiteboard pattern solves the problem stated above. Unlike the listenerpattern, the whiteboard pattern leverages a central application manager for handling life cyclemanagement. Instead of having event listeners track event sources and then register themselveswith the event source, the whiteboard pattern has event listeners register themselves at a centralapplication manager. When the event source has an event object to deliver, the event source callsall event listeners in this application manager. As a result, both server and application becomesimpler because they reuse the central application manager and can delegate the responsibilityfor managing the details of dependencies between source and listeners to it.

31

5.4 Conclusion 5 SERVICE ORIENTED ARCHITECTURES

5.4 Conclusion

This chapter explained what service oriented architecture (SOA) means. It focused on severalrelevant SOA principles and patterns which could be applied when designing our system. Es-pecially the lookup pattern (locating available resources), leasing pattern (detection of servicesgoing down) and the whiteboard pattern (consequent life cycle management) have proven to bevery useful.

By using these patterns and keeping the SOA principles in mind a set of interoperable servicescould be defined for dynamic life cycle management of system components. This way, a logicaldesign is defined for a dynamic reconfigurable system. The next chapter details about an existingSOA implementation which could provide a lot of the required facilities.

32

6 OSGI

6 OSGi

This chapter details about an existing SOA implementation named OSGi. Only the Thales radarchain case related aspects of the OSGi framework will be described. For each aspect will bedefined which problem posed by the Thales radar chain case is solved. This chapter therebyattempts to answer the research question:

Research question. Which existing implementations of service oriented architecture could con-tribute to implementing a system to solve the problem?

6.1 Overview

OSGi provides a service-oriented, component-based environment for developers and offers stan-dardized ways to manage the software lifecycle. Technically, OSGi is a specification for a serviceplatform framework and service bundles. An OSGi implementation has to implement the frame-work and can optionally provide service bundles which support basic functionalities such aslogging.

The OSGi Framework implements a complete and dynamic component model, which doesn’texist in standalone Java/VM environments. It is a service framework in which services, pack-aged into software components called bundles, can be installed, updated and removed withoutrestarting the framework. Although it is intended for relatively small embedded devices, it iswidely applicable.

The OSGi framework consists of three layers (see figure 3), namely the module layer, the lifecyclelayer and the service layer. Each of these layers contribute to solving subproblems posed in theprevious chapter.

Figure 3: OSGi Framework layering

33

6.2 Module Layer and Fault-Tolerance 6 OSGI

6.2 Module Layer and Fault-Tolerance

Owing to the fact that we’re dealing with a distributed system in our case, loose coupling be-tween system components is very important. The system must be fault-tolerant in such waythat when a processing node fails, the rest of the system remains in an operational state. Toaccomplish this, modularization is an important issue.

The modularization concept in OSGi Framework is supported by the module-based class loadingpolicy defined by the module layer. Usually, Java applications have a flat class loader architec-ture. OSGi bundles add a modularization layer to Java which allows modules to declare sharedand private class space and controls linking between modules.

A bundle is the central unit of OSGi. It’s a JAR file which contains resources such as Java codeor native libraries. Bundles are encapsulated and separated from each other by a name spaceconcept.

OSGi applications can consist of several bundles which are loaded by (at least) one individualprivate class loader. Bundles could be used by other applications running on the same platform,but unless Package-Exports are defined, bundle code is private. Package-Imports and Package-Exports define dependencies between bundle code and are stored as additional entries in the JarManifest File. Exported packages are public and could be used for resolving imports of otherbundles who defined a package import. These bundles resolve the import by consulting thepackage database and creating a delegation from the importing class loader to the exportingclass loader. This allows dynamic runtime linking of bundle code.

When, for instance, a service must input every class within the framework, import dependenciesof packages cannot be determined during compilation time. In these cases the DynamicImportmechanism could be used by defining a wildcard asterisk (*) in the bundle manifest. Thisindicates that additional packages might be required.

6.3 Lifecycle Layer and Dynamic Life Cycle Management

The second important issue is dynamic life cycle management. This means in our case that pro-cessing nodes running container services, as defined in the logical design in the previous chapter,could be added to or removed from the system on-the-fly. The rest of the system should remainin an operational state.

The lifecycle layer introduces this kind of dynamics that are normally not part of an applica-tion. It deploys application or components as OSGi bundles which can be managed at runtime.Bundles can be remotely installed, started, stopped, updated and uninstalled without the needof rebooting the system. They rely on the module layer for class loading but add an API tomanage the modules in run time. Each container from our logical design is implemented as anOSGi bundle and could be inserted to the system on-the-fly.

Bundles have their own Activator class which implements the start and stop methods of theBundleActivator interface. These methods will be invoked when a Bundle is started respectivelystopped. A so-called BundleContext object which is passed by these methods supports usage ofthe OSGi framework. In general, bundles hold a public static reference to the BundleContext

34

6.4 Service Layer and Service Discovery 6 OSGI

object after receiving it in the start method. This allows other classes to interact with theframework.

Bundles are installed by creating at least one new class loader. Deinstallation is achieved bydisposing the private class loaders. Implicitly, all the bundle code is then removed from thesystem without affecting other bundles. Private code parts of active bundles could be updatedat runtime. Exported code could only be updated when the PackageAdmin services enforces theframework to reload.

6.4 Service Layer and Service Discovery

In our design we’ve defined several services, each with different responsibilities. Services needto be available for other services or components throughout the system, so some kind of lookupservice, as defined in the previous chapters, is required.

OSGi provides these mechanisms in the service layer. Each bundle may provide multiple servicesby registering service objects using the BundleContext. A service is a java object which can beused by other bundles. This way, interaction between bundles is decoupled. The service layermaintains a service registry with all provided services together with an optional set of serviceattributes that can be passed to the framework during registration. The service registry makesit possible for bundles to detect newly added or removed services.

Bundles can retrieve a service by requesting a service reference for the name of an interface,not knowing whether a service that implemented that interface actually exists on the serviceplatform. Service requests could also contain LDAP String Filters. These filters are matchedagainst the service attributes3 of a candidate.

ServiceFactories are special kinds of service provider classes. For every bundle that requestsa service, a new instance of the service object is created. However, the framework caches in-stances per bundle so a bundle might get the same instance all the time. To track the lifecycleof bundles that provide services, the ServiceTracker can be used. The ServiceTracker is a serviceand provides tracking of all bundles matching certain criteria.

The ServiceTracker could contribute to solving our problem of detection of services becomingunavailable. When, for instance, a container service becomes unavailable, the ServiceTrackerdetects this. This way, we could find out that a processing node and all its process runtimeshave become unavailable.

6.5 Event Handling

As stated before, a ServiceTracker could be used to keep track of the status of a certain service.Additionally, a mechanism is required to notify the rest of the system in case of state changesof services or components.

OSGi signals state changes in the framework by Events. Bundles can subscribe for certainevent types by implementing corresponding listeners. Events related to lifecycle management

3Although every Comparable object can be used as an attribute, only Boxed types of the eight basic types,Vectors and Arrays containing them could be safely matched unambiguously.

35

6.6 Wiring of Processes 6 OSGI

are grouped into FrameworkEvents and BundleEvents. State changes related to services fireServiceEvents which are detected by the previously described ServiceTracker. Bundles can alsogenerate their own events.

FrameworkEvents are fed into a so-called EventAdmin service. This service provides a genericframework for interservice communication. Owing to the fact that services dynamically appearand disappear, the EventAdmin uses the publish-subscribe pattern which reflects loose coupling.It could be seen as a channel between sending and receiving services.

Events are published under a certain topic based on hierarchical name spaces. This topic isstored in the property field EVENT TOPIC. OSGi services generally use the form fully/qualified/-package/Classname/ACTION. For instance, framework events have the topic org/osgi/frame-work/FrameworkEvent/STARTED. Similar to service attributes, events can have EventProper-ties that provide additional information about the event.

Bundles can subscribe for events by registering an EventHandler instance as a service. TheEVENT TOPIC property is set to an array of relevant topics. To solve the problem of detectingservices becoming unavailable, a bundle which depends on a service could register for servicedown events regarding that service. Again, the asterisk (*) is the wildcard character whichindicates all events with a matching prefix in the topic name will be handled. As with services,an additional LDAP style filter string can be assigned to the EVENT FILTER property to narrowthe scope.

To publish events, a bundle has to retrieve the EventAdmin service and invoke sendEvent()or postEvent() for synchronous respectively asynchronous delivery of events. The former oneshould be used with care due to the risk of deadlocks.

6.6 Wiring of Processes

In addition to (remotely) starting and stopping container services and their corresponding pro-cess runtimes, we need a mechanism for linking the output of a process to the input of anotherprocess. In OSGi, this can be accomplished by the use of the so-called WireAdmin Service.

The goal of the OSGi WireAdmin Service is to enable services that generate some sort of datato send it to the services interested in the same data. The data can be updated dynamicallyso that the interested services can receive the new values regularly. The WireAdmin Serviceprovides configuration data (in the OSGi ConfigurationAdmin Service) through which new virtualconnections (known as wires) can be established when a new service needs to receive the dataoutput. Useless wires can easily be removed. The main advantage of using the WireAdminservice is that it decreases the need for wired bundles to have context-specific knowledge aboutthe opposite party. They never need to communicate with each other directly but through theWireAdmin Service.

6.7 R-OSGi

OSGi solves a couple of problems related to detection and tracking of services and other systemcomponents on a local machine. Now we need to go one step further, because we’re dealingwith a distributed system. This poses a whole lot of new problems, for instance, some services

36

6.7 R-OSGi 6 OSGI

could exist as a single instance, but others need to be distributed across the system to preventthe risk of a single point of failure. OSGi itself doesn’t provide us enough facilities for directintegration in a distributed system and solving these problems. Therefore, we’ve used R-OSGito come up to these additional requirements.

R-OSGi is a lightweight extension framework of OSGi. Derived from Jini, it is designed forintegration of distributed environments. It allows existing OSGi services to be accessed fromremote clients by introducing Remote Services. Discovery of these services is based on SLP,proxies are dynamically created on client side and proxy bundles are registered on the localservice platform.

6.7.1 Remote Service Discovery

OSGi provides a mechanism for service discovery in a local machine. Now we need to extendthis mechanism so it’s able to discover services in a distributed system such as the radar chain.

As stated above, service discovery in R-OSGi is based on SLP. SLP [18] is a lightweight, packet-level protocol for service discovery. The registration part is called Service Agent (SA), the lookupand request part User Agent (UA). Services are identified by a ServiceURL which contains theservice type, location and connection information. A general ServiceURL is of the form ser-vice:type://addrspec.

SLP messages could be TCP packets as well as UDP datagrams. Service Agents provide everymessage with a numeric transaction ID (XID). Retransmissions and replies get the same XIDas the original message, otherwise the XID is increased for every new message. This allows therequester to match replies to individual requests.

SLP appeared to be the best choice for integrating remote OSGi services among the set of wellestablished discovery protocol specifications, because mapping OSGi services to SLP service reg-istrations is straightforward. Both systems use a unique identifier as a string for each service type,allow service registration attributes and support filtering based on these attributes. OSGi hasthe interface class name, SLP uses ServiceURLs of the form ’service:osgi:my service Interface’.

Sadly, there is no designated generic method in the framework that allows tracking failed servicereference requests so running a fallback protocol that tries to find a remote service is out of thequestion. R-OSGi specifies a configuration file containing all potential useful services for theservice platform. In addition, it registers discovery listeners for service interfaces and attributefilters so explicit service discovery is supported. Those listeners can be provided by separatebundles that serve as remote extension. For instance, when a log bundle is needed, a tinyremote log listener bundle can be installed to notify the R-OSGi core about the bundle’s interestin services with the interface org.osgi.service.log.LogService.

6.7.2 Using Remote Services through Dynamic Proxies

Once a requested remote service is discovered there’s still another problem before this servicecould be used. We need a mechanism to call the methods of the remote service to actuallymake use of the service’ capabilities. R-OSGi solves this potential problem by the use of so-called

37

6.7 R-OSGi 6 OSGI

dynamic proxies.

In R-OSGi, on the client side proxy bundles are created dynamic. Whether the R-OSGi systemis preconfigured to fetch services of a certain type or the registered discovery listener is fired,either way the system retrieves the service interface with associated attributes from the remotepeer. This is sufficient for the client to build a proxy bundle. R-OSGi then creates a class onthe fly using bytecode manipulation. This class implements the service interface such that allmethods are mapped to a corresponding remote method call in a generic way. All that needs tobe done is calling the method

1 public Object invokeMethod( String serviceURL, String method, Object[] args) throws

RemoteOSGiException;

in the appropriate manner. This looks a lot like Java’s reflection mechanism. After everyabstract method in the interface is implemented by a remote call, the system adds the methodsof a BundleActivator to the class. The implementation body mainly gets the service referenceto the Remoting service and retrieves the service object. Subsequently, the implemented classis registered as service under the interface that was retrieved from the remote peer. All remoteservice attributes are also registered on the local peer with two exceptions:

1. Service.PID is excluded since the PID (persistent ID) of a service must be unique andlocal services might already use the same PID.

2. R-OSGi provides a special type called Timestamp which will be transformed to local timewhen detected as an attribute.

A jar file is created containing the generated class and the bundle is installed and started on thelocal framework. As usual, the framework calls the bundle Activator on start. The proxy class isregistered under the service interface and consumers can now use the service in the same waysas a local service.

R-OSGi also supports code mobility in a similar way like Jini for more delicate setups. It usesa so-called smart proxy, which is an abstract class implementing a few methods of the serviceinterface, instead of simply registering a service interface. When the proxy bundle is generated,only abstract methods are mapped to remote method calls. Smart proxies can therefore movearbitrary pieces of service code to the client.

6.7.3 Remote Event Handling

OSGi already provides us a mechanism to send and receive events within an instance of theOSGi framework. Again, we need to extend this mechanism to support event transmission inour distributed environment.

R-OSGi extends OSGi’s EventAdmin service by implementing EventAdmin and supporting trans-mission of events to remote peers. Bundles create an instance of RemoteEvent, which is anextension of Event. The constructor of RemoteEvent takes an additional service URL parameter.The remote event is unicast to the peer that maps the service URL or multicasted to all listeningR-OSGi peers if no destination is set. This way, events could be used with the semantics ofgroup communication.

38

6.8 Conclusion 6 OSGI

Incoming remote events are published to the local EventAdmin service and processed in thesame ways as local event instances. Remote enabled bundles can check whether an event isa remote events or not. Normal bundles won’t see any difference between normal and remoteevents.

6.8 Conclusion

This chapter introduced the OSGi and R-OSGi frameworks. Thales radar chain case relatedaspects are described and a lot of case related problems are solved, namely fault-tolerance(OSGi Module Layer), dynamic life cycle management (OSGi Lifecycle Layer), dynamic wiring(WireAdmin service), remote service discovery (R-OSGi with SLP) and remote event handling(R-OSGi RemoteEvent).

Furthermore, several SOA patterns described in the previous chapter have already been imple-mented, such as the lookup and the leasing pattern. Using this knowledge a set of interoperableservices could be defined in a logical design.

39

Part III

Solution Approach & Analysis, SystemDesign & Implementation

40

7 SOLUTION APPROACH

7 Solution approach

The goal of this chapter is to analyse the problem in order to find a possible approach to solvethe problem on how a software system instance can be restored to health after it has becomedamaged due to processing nodes becoming unavailable. The aim of this chapter is to find afunctional solution and not to focus on the technical details to implement the given solution.

In the first section of this chapter, a naive solution is analysed to determine which factors areimportant for a solution to be acceptable. Next, a general solution to the problem is presentedbased on the knowledge gathered from the previous section. Finally, some considerations re-garding the prototype are presented.

The following question will be answered in this chapter:

Research question. What kind of approach could be taken to restore the health of a damagedsystem?

7.1 Analysing a naive solution

To find a feasible solution to the recovery problem, first a simple naive solution can be examinedto identify possible problems with this solution.

First, for every process configution in the software system specification, a process instance hasto be available for the software system instance to be healthy. In case any processing node cango down, a naive solution to make sure a process instance is available is to simply run a processinstance for every process on every available processing node. If a processing node goes down,a process instance will still be available on other available processing nodes.

Next, for the links to be set up, link instances need to exist for every link configuration betweenat least one producer process instance and one consumer process instance specified in the linkconfiguration. However, if any linked process in the chain gets uninstantiated, the softwaresystem becomes damaged. A naive solution to this problem would be to link every consumerprocess instance to all available producer process instances for which a link is specified.

In theory, the naive solution as described above should keep the system healthy as long as atleast one processing node is available. However, this solution has some serious problems whichmake it very infeasible.

First, all data is processes by every processing node, in the first place this leads to a lot of wastedprocessing time and bandwidth resources. In the second place, data is processed multiple timesby the same process because of multiple process instances of the process, violating the solutioncriteria that data may only be processed once per process.

Also, as processing instances are running on every processing node for every process, a lot ofmemory is wasted on running these processes, even if they were not processing data.

To come up with a better solution, these problems need to be solved. Based on the analysisjust performed, the main problem seems to be running multiple process instances per process.For the solution proposed in the next section, only one process instance should be allowed per

41

7.2 Solution proposal 7 SOLUTION APPROACH

process. The next section describes a solution which is based on just a single process instanceper process.

7.2 Solution proposal

If a processing node running a process instance becomes unavailable, the associated processbecomes uninstanced. Also, links for which the process instance was the producer become unin-stanced, and link instances are damaged for which the process instance was the consumer. Thisin total leads the software system instance to become damaged.

To restore the software system back to a healthy state, two things have to be done. First theprocess which has become uninstantiated has to be instantiated again. Second the uninstan-tiated links have to be instantiated again and damaged link instances have to be restored tobecome healthy again.

The proposed solution is to implement a system which can perform these tasks in order to beable to restore the system. This system will further in this document be reffered to as theconfiguration system.

7.3 Prototype considerations

In order to implement a prototype of the system, it is neccesary to be able to load a systemconfiguration. If a system configuration is loaded as soon as the system is started, the firstavailable processing node will be assigned to host all process instances as no other processingnodes will be available at that time.

This problem can be solved by starting the configuration system using a null-configuration,containing an empty set of process configurations and link configurations. As soon as all theprocessing nodes have been started, the software system configuration can be loaded to dis-tribute the hosting of processes over the available processing nodes.

This solution requires the system to accept a software system specification after it has beenstarted. The proposed solution is to let the system accept adding process configurations andlink configurations while it is running.

7.4 Conlusion

In this chapter a naive solution to the problem was analysed. Based on the results of this analy-sis, a general solution to the problem was proposed. Finally, a problem regarding the prototypewas noted and a solution to this problem was proposed.

From this chapter, it can be concluded that the system is realisable from a functional point ofview. In order to validate the solution, a technical analysis of the solution has to be performedto determine if the solution is feasible from a technical perspective.

42

8 SOLUTION ANALYSIS

8 Solution analysis

In the previous chapter a general solution to the problem was defined. In this chapter thesolution is further analysed by defining solution scenarios. Finally, a use-case analysis providesa detailed overview of the use-cases and processes within the system.The following questions will be answered in this chapter:

Research question. Which scenarios can be identified?

Research question. Which use-cases can be identified?

8.1 Scenarios

The following sections describe some typical scenario’s the system has to deal with.

The hardware system used in these scenario’s consists of three processing nodes which are la-belled by A, B and C.

Further in this section, the following conventions are used for denoting configurations and in-stances of software components:

• i(x) denotes an instance of x, e.g: i(p1) denotes an instance of p1

• c(x) denotes a configuration of x.

The software system specification constists of the following configurations:

1. Process configurations c(p1), c(p2) and c(p3)

2. A link configuration c(l1), linking i(p1) to i(p2)

3. A link configuration c(l2), linking i(p2) to i(p3)

8.1.1 System instantiation

The following scenario illustrates the starting of a hardware system, followed by the starting ofthe configuration system, and finally the instantiation of the software system instance s.

1. The configuration system is started

(a) The configuration system instantiates a null-configurated software system instance

2. Processing nodes A, B and C become available

(a) The configuration system detects A, B and C are available

3. The administrator adds c(p1) to the software system specification

(a) The configuration system finds that p1 is uninstantiated

(b) The configuration system finds a processing node on which to instantiate p1

(c) The configuration system requests A to instantiate p1

(d) Processing node A instantiates i(p1)

43

8.1 Scenarios 8 SOLUTION ANALYSIS

(e) The configuration system detects p1 has been instantiated

4. The administrator adds c(l1) to the software system specification

(a) The configuration system detects l1 is uninstantiated and invalid




(c) The configuration system requests B to instantiate p2

(d) Processing node B instantiates p2


(f) The configuration system detects l1 has become uninstantiated and valid

(g) The configuration system requests p1 to instantiate a link to p2

(h) The configuration system detects l1 has become instantiated and valid




(c) The configuration system requests C to instantiate p3

(d) Processing node B instantiates p3


7. The administrator adds c(l2) to the software system specification

(a) The configuration system finds that l2 is uninstantiated and valid

(b) The configuration system requests p2 to instantiate a link to p3

(c) The configuration system detects l2 has become instantiated and valid

44

8.1 Scenarios 8 SOLUTION ANALYSIS

8.1.2 Restoring the system

This scenario starts in the end state of the previous scenario where the system considers i(s) asbeing healthy. In this scenario, processing node B becomes unavailable leading to i(p2) and i(l2)being destroyed and i(s) becoming damaged. First, the system destroys i(l1) which has becomeinvalid but is still instantiated. Finally, the system restores the health of i(s) by instantiatingi(p2) on processing node A and instantiating l1 and l2.

1. Processing node B becomes unavailable

(a) The configuration system detects B has become unavailable

(b) The configuration system detects p2 has been uninstantiated

(c) The configuration system detects l2 has been uninstantiated

(d) The configuration system detects l1 has become instantiated and invalid

(e) The configuration system requests p1 to uninstantiate its link to p2

(f) The configuration system detects l1 has become uninstantiated and invalid

(g) The configuration system finds a processing node on which to instantiate p2

(h) The configuration system requests A to instantiate p2

(i) Processing node A instantiates p2

(j) The configuration system detects p2 has been instantiated

(k) The configuration system detects l1 has become uninstantiated and valid

(l) The configuration system detects l2 has become uninstantiated and valid

(m) The configuration system requests p1 to instantiate a link to p2

(n) The configuration system detects l1 has become instantiated and valid

(o) The configuration system requests p2 to instantiate a link to p3

(p) The configuration system detects l2 has become instantiated and valid

45

8.2 Use-case analysis 8 SOLUTION ANALYSIS

8.2 Use-case analysis

8.2.1 Use-case diagram

Figure 4: Use-case diagram

46

8.3 Secundairy use-cases 8 SOLUTION ANALYSIS

8.2.2 Actors

From the scenarios described in the previous section, the following actors can be identified:

1. AdministratorAn administrator is a user who provides the configuration system with the software systemspecification.

2. Configuration systemThe configuration system itself is an actor as it notifies the system of processing nodesbecoming available or unavailable.

8.2.3 Administrator use-cases

1. Add a process configurationThe administrator provides the configuration system with a process configuration.

The system invokes use-case “Notify a process has been uninstantiated”.

2. Add a link configurationThe administrator provides the configuration system with a link configuration.

If the link is valid, use-case “Notify a link has become valid” will be invoked.

8.2.4 Configuration system use-cases

1. Notify a processing node has become availableThe configuration system detects a processing node has become available and notifies thesystem of this fact

2. Notify a processing node has become unavailableThe configuration system detects a processing node has become unavailable and notifiesthe system of this fact.

The configuration system checks if there were any process instances on the processingnode and invokes use-case “Notify a process has been destroyed” to notify the system ofthese process instances having been destroyed.

8.3 Secundairy use-cases

The following use-cases are not directly used by the actors, but they are used by other use-cases.

1. Request a processing node to instantiate a processThe system requests a given processing node to instantiate a process instance based on agiven process configuration.

After the process has been instantiated, use-case “Notify a process has been instantiated”is invoked.

2. Request a process to instantiate a linkThe system requests a given process instance to instantiate a link to another process.

47

8.3 Secundairy use-cases 8 SOLUTION ANALYSIS

After the link has been instantiated, use-case “Notify a link has been instantiated” isinvoked.

3. Request a process to uninstantiate a linkThe system requests a given process instance to uninstantiate a link to another process.

After the link has been uninstantiated, use-case “Notify a link has been uninstantiated”is invoked.

4. Find a processing node on which to instantiate a processThe system finds and returns a reference to an available processing node on which toinstantiate a process.

5. Notify a process has been instantiatedThe system gets notified that a process has been instantiated.

If the system determines a link has become valid, use-case “Notify a link has becomevalid” is invoked.

6. Notify a process has been uninstantiatedThe system gets notified that a process has been uninstantiated.

If the system determines that a link instance has been destroyed, use-case “Notify a linkhas been uninstantiated” is invoked.

7. Notify a link has been instantiatedThe system gets notified that a link has been instantiated.

8. Notify a link has been uninstantiatedThe system gets notified that a link has been uninstantiated.

If the system determines that the link is valid, use-case “Notify a link has become valid”will be invoked.

9. Notify a link has become validThe system gets notified that a link has become valid.

10. Notify a link has become invalidThe system gets notified that a link has become invalid.

If the system detects a link instance is still available for this link, use-case “Notify a linkinstance has become damaged” will be invoked.

11. Notify a link instance has become healthyThe system gets notified that a link instance has become healthy.

12. Notify a link instance has become damagedThe system gets notified that a link instance has become damaged.

The system invokes use-case “Request a process to uninstantiate a link”.

48

8.4 Conclusion 8 SOLUTION ANALYSIS

8.4 Conclusion

In this chapter scenarios were defined for the proposed solution and a use-case analysis wasperformed. The use-cases can now be used to design a system which can automatically recovera software system instance.

49

9 SYSTEM DESIGN

9 System design

In the analysis performed in the previous chapter, a number of use-cases have been defined.Designing a system to implement these use-cases poses some design challenges which need tobe solved. In this chapter, these challenges are identified in order to find solutions to them.Next, the principles and patterns of SOA are applied to these design challenges to come up witha design for a SOA layer. Finally, the complete design of the SOA layer is presented.

The following questions are answered in this chapter:

Research question. Which design challenges need to be solved?

Research question. How can the principles and patterns of SOA be applied to solve thesedesign challenges?

Research question. How can a system be designed to implement the solution?

9.1 Design challenges

Based on the use-cases defined in the previous chapter, the following problem specific designchallenges can be identified:

1. How can process configurations and link configurations be added to the system?

2. How can the configuration system detect a processing node has become available orunavailable?

3. How can the configuration system detect a process instance has been instantiated oruninstantiated?

4. How can the configuration system detect a link has become valid or invalid?

5. How can the configuration system detect a link has become instantiated or uninstantiated?

6. How can an available processing node be found to instantiate a process?

7. How can a remote processing node instantiate a process?

8. How can a remote process instance instantiate or uninstantiate a link to another process?

9. How can the system recover processes?

10. How can the system recover links?

Also, the following general architectural design challenges remain to be solved:

1. How can the configuration system be decomposed into services?

2. How can services interact?

To tackle the design challenges, this chapter applies the principles and patterns of SOA in orderto conceive a logical system design which is unimpaired by the design choices of any existingSOA framework.

50

9.2 Service decomposition 9 SYSTEM DESIGN

9.2 Service decomposition

The principles of SOA state that a system should be decomposed into a number of serviceswhich provide capabilities accessible by other services.

Within the system the following resources can be identified: a software system configuration,process configurations, link configurations, processing nodes, process instances, link instancesand a software system instance.

All activities within the system are centered around these resources, either adding, modifyingor removing resources, monitoring resources or using resources. To decompose the system intoservices, services can be wrapped around these resources to manage them. Based on this notion,the following services have been defined:

1. Process serviceLink instances are created by processing instances, as there is a close correspondencebetween these resources, both types can be managed by one kind of service. For everyprocess instance, a service can be created to manage the processes and its correspondinglinks.

2. Processing node serviceA processing node can be regarded as a resource providing processing power to run processinstances. A processing node service can be run on every processing node to manage thecapabilities the processing node provides.

3. Process configuration serviceThe process configuration service manages the process configurations.

4. Link configuration serviceThe link configuration service manages the link configurations.

9.3 Service interaction

To make services interact, the principles of SOA state they should be able to discover eachotherusing a discovery mechanism to publish their interface for other service to consume. A discoverymechanism is usually implemented in the form of a lookup service where services can registertheir interface.

Furthermore, in order for services to be able to interact, they must be able to communicatewith eachother. To implement a mechanism for remote communication, the proxy pattern canbe used. Services can register their proxy with the lookup service to publish their interface foruse by service consumers.

Another way to make services communicate is to use an event mechanism. Using the publishsubscribe pattern allow services to register themselves to receive events so they get notified incase the event occurs. This method of communication allows loose coupling between a ser-vice provider and a service consumer which is for example useful to send events detailing statechanges in system components.

51

9.4 Service capabilities 9 SYSTEM DESIGN

As services may become unavailable while the system is operational, the lookup service shouldkeep its list of service proxies up-to-date by removing the proxies of services which have becomeunavailable. The leasing pattern can be used to implement a mechanism to achieve this. Usingan event mechnism, the lookup service can send events about changes in the availability ofservices to interested service consumers.

9.4 Service capabilities

The capabilities of the services as defined in the service decomposition section have to bespecified in order to solve the remaining problem specific design challenges. This section walksthrough the remaining design challenges to describe the service capabilities required to completethe system design.

1. How can process configurations and link configurations be added to the system?The process configurations are managed by the process configuration service and the linkconfigurations are managed by the link configuration service. To allow configurations tobe added to the system, the configuration services have to provide methods to add theseconfigurations.

The process configuration service interface is extended with the following method:

1 void addProcessConfiguration(ProcessConfiguration processConfiguration)

The link configuration service interface is extended with the following method:

1 void addLinkConfiguration(LinkConfiguration linkConfiguration)

2. How can the configuration system detect a process instance has been instantiatedor uninstantiated?As process instances are managed by a process service, the service will register itself withthe lookup service. The lookup service can send an event when a process instance servicebecomes available or unavailable.

3. How can the configuration system detect a link has become valid or invalid?The link configuration service has an overview of all link configurations. By registering withthe lookup service for process instance service availability events, the link configurationservice can determine if a link is valid or invalid. As soon as a link has been detected tobe valid, an event can be dispatched to allow a process service to instantiate the link.

4. How can the configuration system detect a link has become instantiated or unin-stantiated?As link instances are managed by the process service, the system does not need to know iflinks are instantiated or uninstantiated. The process service can instantiate links as theyreceive events about them becoming valid and uninstantiate their links as they becomeinvalid.

5. How can the configuration system detect a processing node has become availableor unavailable?Every processing node runs a processing node service. The processing node servicesregister themselves with the lookup service. As soon as a processing node is registered,

52

9.5 Service descriptions 9 SYSTEM DESIGN

the lookup service sends an event telling the processing node service has become available.In case a processing node becomes unavailable, the processing node service gets destroyedand the lease at the lookup service expires. The lookup service now sends an event tellingthe processing node service has become unavailable.

6. How can a process instance instantiate or uninstantiate a link to another process?process services can register themselves to receive events about links becoming valid orinvalid. These events are sent by the link configuration service. As soon as a link becomesavailable for which the process instance is the producer, the process instance can set upthe link to the consumer service.

In order for a connection to be set up, the network address of the consumer processinstance is needed. The proxy of the consumer process instance can be retreived from thelookup service to query the consumer process instance about its network address. To dothis, the interface of the process service needs a method to get its network address:

1 NetworkAddress getNetworkAddress()

7. How can an available processing node be found to instantiate a process?The lookup service contains proxies of all available processing node services. The lookupservice can be queried to return one of those processes node service on which the processcan be instantiated.

8. How can a remote processing node instantiate a process?A processing node service can be accessed remotely by getting its proxy from the lookupservice. The processing node service interface is extended with the following method toallow processing services to be instantiated:

1 void startProcessInstanceService(ProcessConfiguration processConfiguration)

9.5 Service descriptions

• Lookup serviceThe lookup service provides a mechanism for service discovery. Services can register andretreive proxies from the lookup service to allow communication between services. Eachservice registers its proxy under a unique name identifying the service. Also services canhave specific attributes which can help to identify services. The lookup service allowconsumer services to retreive one or multiple services based on the identifying name ofservices and their attributes.

The lookup service uses the leasing pattern to determine if services are still available or ifthey have become unavailable. When services are registered or become unavailable, thelookup service sends events to any interested consumers in order to give them the abilityto handle these events.

• Process serviceA process service manages the lifecycle of a single process instance and its correspondinglink instances. In order to instantiate a process, a process service can be created which

53

9.6 Conclusion 9 SYSTEM DESIGN

will instantiate and manage the lifecycle of the process instance.

The process service registers itself to get notified of link validity events. If a link becomesvalid for a producer process instance, the process service retreives the network address ofthe consumer process by invoking getNetworkAddress() on the consumer service. Next,the process service requests the process instance to instantiate a link to the given address.On the other hand, if a link becomes invalid for a producer process instance, the processservices requests the process instance to destroy the link.

• Processing node serviceA processing node service provides the capabilities of a processing node as a service. Theprocessing node service allows consumer processes to instantiate process instances on theprocessing node by creating process services.

• Process configuration serviceThe process configuration service manages the process configurations and makes sure allprocesses are instantiated. An administrator can add process configurations through theprocess configuration service’s interface. As process configurations are added, the processconfiguration service will instantiate the corresponding process instances on available pro-cessing nodes. Further, the process configuration service listens for events related to theavailability of process services. If a process service becomes unavailable, the correspondingprocess instance will be restored by the process configuration service by instantiating anew process instance on an available processing node.

• Link configuration serviceThe link configuration service manages link configurations and sends events about thevalidity of links. Links are added by specifying the services which have to be connected.The link configuration service subscribes itself to receive events about the availability ofthe linked services. If the link configuration service detects both services required by a linkare available, a LINK VALID event is sent. If the link configuration service detects oneof the linked services becoming unavailable, a LINK INVALID event is sent. The linkedservices subscribe to these events and handle them accordingly.

9.6 Conclusion

In this chapter a design was provided for the system proposed in earlier chapters. First, thedesign challenges were identified. Next, the principles and patterns of SOA were applied toovercome these design challenges. Finally a system design was proposed which can be used toimplement the solution.

From this chapter, it can be concluded that the design challenges of the system relate mostly tothe system architecture and the dynamic and distributed nature of the system. The principlesand patterns of SOA provide general methods to overcome these design challenges. Using theprinciples and patterns of SOA, a system could be designed which is open to extentions, easyto maintain and reusable.

54

10 SYSTEM IMPLEMENTATION

10 System implementation

This chapter describes how the system designed in the previous chapter was implemented. Thisimplementation serves as a proof of the concepts explored in this thesis.

The implementation of the system was done in three phases. In the first phase, the processesand links were implemented in order to build a prototype of a system with a static configurtionwithout using the configuration system. In the second phase the configuration system was im-plemented to run on a local machine. In the last phase the system was modified to be able torun in a distributed environment.

The following question is answered in this chapter:

Research question. How can the system design be implemented?

10.1 Process and link implementations

Before implementing the configuration system, first the processes and links were implementedto demonstrate the operation of a system without the configuration system.

Figure 5: Class diagram

55

10.1 Process and link implementations 10 SYSTEM IMPLEMENTATION

10.1.1 Processes

The functionality of a process is implemented in the form of a runtime. To allow the processruntime to be liberated from handling the networking details, a process runtime container isimplemented.

The process runtime container is an abstract class which defines an interface for reading datafrom service producers and writing data to service consumers. Concrete implementations of theprocess runtime container have to implement these methods. The process runtime containeralso contains implementations to start and stop the runtime contained by the container.

The interface of the process runtime container is defined as follows:

1 // Starts the process runtime

2 public void start();

3

4 // Stops the process runtime

5 public void stop();

6

7 // Waits for and reads a message from producer processes

8 public abstract String read(int timeout);

9

10 // Writes a message to consumer processes

11 public abstract void write(String message);

The start() method starts the runtime thread by invoking the Thread.start() method on theruntime. The stop() method is implemented by calling Thread.interrupt() on the runtime. Theinterrupt can be detected by the runtime to allow it to terminate itself.

A process runtime is implemented as thread which has access to its container to allow it toread and write data. An abstract base class has been implemented which extends a thread andstores the a reference to the process runtime container to allow it to be accessed by concreteruntime implementations. Concrete implementations can extend this base class to implementthe Thread.run() method and use the process runtime container’s read() and write() methodsto send and receive data for processing.

10.1.2 Links

The UDP protocol was chosen in order to implement links between processes because the UDPprotocol relates closely to the realtime nature of the protocols used by Thales. Also, UDP cannot detect if messages sent through the connection are actually received, which is also the casefor the protocols used by Thales.

The UdpProcessContainer class extends the ProcessContainer class to implement the function-ality related to links. The UdpProcessContainer class allows instantiating and uninstantiatingof links by implementing link() and unlink() methods. Further, it supports reading and writingof messages on a link by implementing the read() and write() methods of its base class.

Upon instantiation, the UdpProcessContainer creates an UDP socket on which it can receivemessages from producer processes and from which it can send messages to consumer processes.

56

10.2 Configuration system local implementation 10 SYSTEM IMPLEMENTATION

Upon the runtime calling the read() method, it waits for a specified ammount of time for amessage to be received and either returns the received message or returns null if no messagewas received during the time period. This timeout allows a runtime to handle thread interruptsor other tasks in case no messages were received for a longer period of time.

10.1.3 Demonstration

A demonstration was implemented to demonstrate how a static configured system behaves incase of processing nodes failing.For the demonstration, three runtime implementations have been implemented:

• GeneratorThis runtime implementation generates and writes messages to consumer processes atcertain intervals.

• TransformerThis runtime implementation receives messages from producer processes, transformesthem and sends them to consumer processes.

• WriterThis runtime implementation receives messages from producer processes and writes themto the standard output.

Further, three entry points have been implemented to start three processing nodes, all runninga process instance linked to predefined local addresses of other process instances.

When terminating one or more processing nodes, this implementation effective demonstratesthe behaviour of the system in case the configuration system is not used.

10.2 Configuration system local implementation

The next step in implementing the designed system is to get a working implementation of theconfiguration system using the SOA based OSGi framework. This implementation requires theservices as defined in the system design chapter to be implemented using the OSGi programmingmodel.

10.2.1 OSGi

OSGi was chosen as the SOA based framework in which to implement the system. The clientprefers the use of OSGi because of years of positive experiences using this framework. luminis ispart of the OSGi alliance and develops OSGi implementations for the open source community.A detailed description of OSGi is provided in the literature study part of this document.

10.2.2 OSGi service mapping

In this section, the services as defined in the previous chapter are mapped to the services OSGialready provides in order to determine which services still have to be implemented and to deter-mine which have already been implemented.

The service registry in OSGi combined with R-OSGi already provides all abilities required bythe lookup service design for the local implementation of the configuration system. R-OSGi

57


Figure 6: Class diagram

implements remote service discovery and leasing which are required according to the design.

OSGi provides the EventAdmin service to implement event based messaging. Further, R-OSGienables the EventAdmin to support remote event messaging. The EventAdmin uses the white-board pattern, as described in the SOA chapter, to implement the publish / subscribe pattern.

OSGi also provides a WireAdmin to wire services according to the producer / consumer model.The WireAdmin service provides all capabilities required by the link configuration service asspecified in the design. However, R-OSGi is not guaranteed to support the WireAdmin service.Further, the WireAdmin service uses a programming model which conflicts with the design ofthe link configuration service. Further, it provides capabilities not required by the design whichmay overcomplicate the implementation. Because of this, it was decided that the WireAdminservice will not be used in the implementation.

Each processing node in the proposed system will run a single instance of the OSGi framework.One of these framework instance will run the process admin and link admin services.

10.2.3 OSGi bundles

To implement the services, they have to be placed and grouped into bundles. The followingbundle structure is used to implement the system:

58


• Process bundleThis bundle contains the process service and the process admin as these services are closelyrelated. The process bundle activator starts and stops the process admin service. Processservices are created by the process admin and instantiated by the container service.

• Link bundleThe link admin service is designed to be reusable, because of this it has been placed inits own bundle. The link bundle activator starts and stops the link admin service.

• Container bundleThe container service is also designed to be reusable, therefor this service is also placedin its own bundle. The container bundle activator starts and stops the container service.

Further, the following OSGi bundles are used by the system implementation:

• EventAdminA bundle which is part of the OSGi compendium specification. This bundle provides theEventAdmin service as described in the previous section.

• R-OSGiA third-party bundle providing remoting capabilities to O2. A detailed describtion of thisbundle is provided in the OSGi chapter in the literature study part.

10.2.4 Service implementations

Process service

A process configuration is implemented as an object which stores the identifying name of aprocess and the name of the process runtime. This object is implemented as a POJO:

1 class ProcessConfiguration {

2 private String name;

3 private String runtimeClassName;

4

5 // Constructor and getters

6 }

To uniquely identify a process service, a so-called PID is defined for every process. This PIDis defined by setting the “service.pid” property when registering the service with the serviceregistry. The format of the PID given to a process service is the java class name followed by acolon and then the name of the process as defined in the process configuration.

To start the process instance the process service creates a process runtime container. As the run-time is specified as a string in the process configuration, it is instantiated using Class.forName(“runtimeclass name”).newInstance().

In case an event arrives which requires the process service to instantiate a link, the processservice gets the network address of the consumer process instance from the consumer processservice. The network address is stored in a java Map〈Link, NetworkAddress〉. Next, the processservice requests its process runtime container to instantiate the link.

59


In case an event arrives to uninstantiate a link, the consumer process service is already down, sothe network address of the consumer process instance address can not be retreived anymore fromthe consumer process service. Now the process service can retreive the network address of theconsumer process instance from the map where it was stored earlier. Finally, the process servicecan request its process runtime container to uninstantiate the link by providing the networkaddress of the link to be uninstantiated.

Container service

The container service implements the processing node service as defined in the system design.The container bundle defines an interface “Service” for a service instantiation which can betransferred over a wire and started by the container service. The container service implementsa method startService() which accepts such a service and starts it on the processing node.

Process admin

The process admin implementation is a straightforward implementation of the service as specifiedin the design. No noteworthy implementation details have to be covered.

Link admin

The link admin bundle defines an interface “Linked” which can be implemented by services whichcan be linked. Every linked process must also register itself with the “service.pid” property sothe link admin can distinguish the linked services.

A link configuration is implemented as an object which stores the “service.pid” of the producerprocess and the consumer process:

1 class Link {

2 private String producerPid;

3 private String consumerPid;

4

5 // Constructor and getters

6 }

The OSGi framework does not guarantee that service status events are received in the order theywere sent. It is possible to receive an event that a service went up while it still is up and thenan event that the service went down while it still is up. To solve this, a workaround has beenimplemented. Instead of storing if a service is simply registered or unregistered, the amount oftimes a service is registered is stored. If a service is registered twice according to the events, itcan be considered to have become unregistered and registered again.

The link admin keeps track of services being registered and unregistered implementing the Linkedinterface. The status of each known service is stored in a Map〈String, Integer〉, where the Stringstores the service.pid and the Integer signifies how many times the service is detected as beingup. If a service is not in the list, the status of the service is unknown, but it might actually beregistered. If the status of a service is unknown the link admin requests the status of the servicefrom the service registry.

If a configuration is added or removed, or a Linked services becomes registered or unregistered,the link admin checks if a link is valid or invalid and sends an event accordingly. Because of the

60

10.3 R-OSGi integration 10 SYSTEM IMPLEMENTATION

anomaly described earlier, it is also possible that a link has become invalid and valid again. Inthis case, a LINK MODIFIED event is sent.

10.2.5 Demonstration

Based on the local implementation of the system a demonstration has been implemented toserve as a proof-of-concept of the system. The implementation demonstrate processes whichdestroy themselves after which the system restores these processes.

To destroy running processes, the process service was extended with a thread which sleeps fora period of time and then stops its hosting process service.

A configuration bundle has been implemented which invokes the configuration methods of theprocess admin and the link admin in order to specify the configuration of a software system.When the configution bundle is started, it announces the configuration to the configurationsystem which then starts the software system and keeps it healthy.

10.3 R-OSGi integration

The goal of the last implementation phase was to integrate R-OSGi and SLP into the systemin order for the system to work in a distributed environment. The R-OSGi documentation sug-gested that R-OSGi offers an almost completely transparent mechanism to support distributedsystems within OSGi. However, due to problems related to the SLP R-OSGi documentation,the implementation was not finished on time for inclusion in this thesis. Also, the integrationof R-OSGi does require some modifications to the existing implementation. This section willdescribe which modifications have to be implemented to enable R-OSGi support.

First, R-OSGi remote service calls do not support complex types other than Dictionary objects,only java primitives can be sent over a wire. The implementation has to be modified in a fewspots in order to only communicate using primitive types. Below, an overview is provided of themodifications to be made:

1. Service objectsServices can not be instantiated on one processing node and then transferred to anotherprocessing to be started there. To solve this, the container service can be given the nameof a process to instantiate. The disadvantage of this solution is that it will destroy thegenericity of the container service.

2. Link objectsThe link admin should not use the Link objects for communicate with other services. Alink object consists only of two strings, these could be passed to other services instead ofthe Link objects.

3. ProcessConfiguration objectsLike a Link object, a ProcessConfiguration object consists of only two strings. Thesestrings could be passed during communication instead of the ProcessConfiguration objects.

4. NetworkAddress objectsNetwork addresses could be serialized before sending and deserialized after receiving.

61

10.4 Conclusion 10 SYSTEM IMPLEMENTATION

While integrating R-OSGi, the documentation specified that a so-called Adapter Bundle shouldbe implemented to register remote services with the local OSGi service registry. However, nodocumentation or sample code has been found on how to actually implement such an adapter.As of such, no distributed service calls could yet be implememented.

10.4 Conclusion

In this chapter, the implementation for the design created in the previous chapter was described.First, an implementation was created for the processes and links from the Thales radar chaincase.

62

Part IV

Conclusion & Recommendations

63

11 CONCLUSION

11 Conclusion

The main question to be answered in this study is the following:

“How can a system be implemented, based on the principles and patterns of SOA, which canautomatically restore the health of a software system instance after it has become damaged dueto processing nodes becoming unavailable?”

In this thesis, a general solution was described to restore a damaged software system instance.Next, the solution was analyzed and a design was created for a system which can automaticallyrestore the health of a damaged software system instance. Finally, the designed system wasimplemented based on the SOA based OSGi framework.

In this chapter, the findings and conclusions regarding the study are presented. First, theresults regarding to the system recovery problem are described. Second, the findings related toservice oriented architectures are detailed. Finally, the findings related to OSGi and R-OSGi arepresented.

11.1 System recovery

Based on the Solution Approach chapter, it can be concluded that restoring a software systeminstance which has become damaged due to processing nodes becoming unavailable is possiblefrom a functional point of view.

Scenarios were defined for the proposed solution which show how the proposed solution op-erates, and a use-case analyses was performed to determine the different processes that takeplace in the system while restoring a software system instance. Based on this analysis it canbe concluded that, given a way to implement the analysed solution, a system should be realizable.

In system design chapter, a SOA based service layer was defined to overcome the design chal-lenges posed earlier in the chapter. The lookup service could be regarded as the glue of thesolution, providing many abilities required by the other services. Further, communication throughevents played a crucial role while defining the capabilities of the services.

The solution logic of the system was divided into four services, each containing some part ofthe solution logic.In the system implementation chapter, a proof of concept of the system was implemented todemonstrate a technical realisation of the solution. All in all, it can be concluded that thesystem recovery problem has been solved.

11.2 Service oriented architecures

In the system design chapter a number of design challenges were formulated based on the so-lution analysis done in the chapter before. From the results in the chapter the main conclusionthat can be drawn is that the principles and patterns of SOA contributed greatly in designingthe system.

64

11.3 OSGi and R-OSGi 11 CONCLUSION

Most of the design challenges posed in the design chapter could be mapped to principles andpatterns defined by SOA. For a lot of design challenges, solutions were readily available in theform of SOA patterns. The principles of SOA provided the basic means of setting up the SOAarchitecture.

The principles and patterns of SOA assist in creating an architecture which is based on the ideasof seperation of concerns. The designed architecture is consists of a few small services whicheach only have a few responsibilities. From the perspective of software engineering, a SOAbased architecture is very interesting as it leads to a system design which is open to extentions,easy to maintain and reusable.

Designing distributed system is usually more of a challenge than designing systems which runon a local machine due to the problems which arise due to parralel execution of code and com-munication between multiple machines. The service oriented approach defined by SOA worksespecially well for implementing distributed systems as the SOA paradigm embraces failure indistributed systems instead of trying to avoid it.

Further, the patterns in SOA provide solutions to many communication challenges in distributedsystems. For example, the whiteboard pattern provides a very clean solution to implement thepublish / subscribe communication paradigm while avoiding problems which occur while usingthe observer design pattern. Also, there are a lot of other patterns available for all kinds ofcommunication related problems which might provide useful in future studies.

A lot of principles and patterns of SOA were not directly relevant to this study. However infuture studies these may still provide valuable to solve other design problems.

Always applying the principles of SOA might also have some drawbacks. The principles of SOAdictate for example that services should be reusable. Sometimes a tradeoff has to be madebetween the principles of SOA and realworld requirements such as performance, as might bethe case when applying the results of this study to the O2 framework. This does not mean thatthe principles of SOA are not useful in these cases, but sometimes a tradeoff might have to bemade depending on the application.

All in all, it can be concluded that the principles and patterns of SOA provide valuable tools indesigning software systems consisting of multiple cooperating entities.

11.3 OSGi and R-OSGi

To implement the prototype, OSGi was used in combination with the R-OSGi bundle to enableremote communication. The OSGi framework provided a good basis to implement the system.Especially the dynamic life cycle management has proven it’s value with regard to fault-toleranceof components. OSGi created the opportunity to remotely start and stop components withoutaffecting other components. This has solved a significant part of the problem.

However, there are some side notes. OSGi is not originally designed to support distributedsystems. The current OSGi specification is designed only for local systems. Because of this,OSGi lacks some basic functionality which could normally be expected to be available for a SOAbased framework designed for distributed systems. R-OSGi attempts to solve some of these

65

11.4 Final conclusion 11 CONCLUSION

shortcomings, but it cannot be regarded as a complete solution to the problem.

While implementing the prototype, some problems were found using OSGi. First, the OSGispecification does not guarantee that events are received in the same order they are sent. Thisis absolutely crucial when dealing with events related to components becoming available or un-available. Second, the OSGi specification does not guarantee that events are received at all.This is really unacceptable for a system which relies on the flow of events. In order to builda reliable system, either these problems have to be solved in OSGi, or the system has to beextended to handle these cases.

Next, R-OSGi seems to have not really matured yet as a solution to enable OSGi applicationsto be deployed in distributed environments. First, a lot of bugs are reported on the R-OSGiwebsite. Second, there is a serious lack of documentation which makes it very hard to implementR-OSGi. For now, R-OSGi should be regarded as an experimental solution. If it is decided touse R-OSGi it is recommended to at least test the current implementation thoroughly.

The OSGi alliance is currently working on the next version of the OSGi specification. The nextversion will include support for distributed systems. Altogether, it might be better to wait for theversion of OSGi, or use another SOA based framework, than to use the current implementationtogether with R-OSGi.

11.4 Final conclusion

The principles and patterns of SOA have certainly proven to contribute to designing a systemwhich can automatically restore the health of a software system instance after it has becomedamaged due to processing nodes becoming unavailable. The current version of the OSGiframework and the R-OSGi framework in the current state don’t come up to the expectationsregarding integration in a distributed environment. Future studies should point out whether thenext version of the OSGi framework meets our requirements or whether there’s an alternativeSOA-based framework which does.

66

12 RECOMMENDATIONS

12 Recommendations

Now the conslusion of this study has been demonstrated, the results of this study can be appliedto other projects. Furthermore, the solution proposed still leaves a lot of room for additions andimprovements. In this chapter recommendations are made for possible future research topicsrelated to this study.

12.1 Applying the study results to the O2 framework

The case study relates closely to the design of the O2 framework, most concepts covered bythis study could probably be mapped to the O2 architecture without much effort. However, it isrecommended to extend the case study to account for network routing as is currently performedby O2. Network routing might provide some completely new challenges not accounted for inthis study.

To implement the studied system in O2, it might be possible to use a SOA based frameworksuch as OSGi. However, some way has to be found to integrate the SOA based framework withthe O2 framework. It is however not mandatory to use an exiting framework. The O2 frameworkcould also be extended with the same capabilities a SOA based framework provides.

Finally, the O2 framework has to be extended to be able to dynamically start software compo-nents and set up communication channels in order for the proposed system to be implemented.

12.2 Remove single point of failures

The current system design contains single point of failures in the form of the process configu-ration service and the link configuration service. The problem here lies in the fact that theseservices are now designed to be localized.

In order to remove the single point of failure property, the services should be distributed amongmultiple processing nodes, but acting as one coordinating entity. The way to accomplish thisis to make use of distributed algorithms. For example, a distributed voting algorithm could beused to pick a processing node on which to instantiate a process. Problems to be solved relateto distributing the system configuration and detecting and distributing the system state amongmultiple processing nodes.

The principles and patterns of SOA should provide the means to solve most architectural prob-lems to implement such a system.

12.3 Code provisioning

For the current solution it is assumed that all processing nodes have access to all runtimesrequired by the processes. In a complex system this would require all runtimes to be deployedon every processing node. If this was to be done manually this could be costly to do.

At first glance, a mechanism could be implemented to simultaneously deploy runtimes on allprocessing nodes. However, this approach requires all processing nodes to be available duringdeployment, and if new processing nodes are added to the system later, they might not have

67

12.4 Dynamic configuration 12 RECOMMENDATIONS

the required runtimes.

A possible solution to this problem is to use code provisioning. A provisioning service is addedto the system which has access to all required runtimes. In case a process service is started on aprocessing node, the process service can contact the provisioning service to acquire the runtimefor the process.

Using this solution, deployment of runtimes would take a minimal effort. Also the system couldbe modified to support updating of runtimes while the system is operational by the provisioningservice sending events which can be handled by process services.

12.4 Dynamic configuration

In the prototype, processes are assigned to processing nodes at random. In practise this willusually not lead to optimal performance, maybe even unacceptable performance.

A simple to implement means to optimize system performance is to manually assign processesto processing nodes. A configuration containing configurations for different scenarios can beused to describe the system behaviour in case specific processing nodes fail. The advantage ofthis system is that given some scenario, the system can be reconfigured to perform optimally.However in large systems, not every possible scenario can be accounted for.

A more interesting solution would be to model the reconfiguration behaviour of the system incase a processing node becomes unavailable in the form of an algorithm. First, this minimizeseffort when deploying a system as no software to hardware mapping has to be defined specifi-cally for one system configuration. And also, all possible scenarios can be accounted for withoutmuch effort during the development of a software system.

If the configuration of a software or hardware system is altered in any way, an algorithm canprovide a suitable configuration, whereas a configuration file needs to be adapted manually.Using an algorithm to create a software to hardware mapping removes the human factor fromconfiguring a system, resulting in a shorter development cycle and making the system morerobust.

Finally, in the O2 framework the topology of a hardware system is defined in a static hardwaresystem configuration file. Using the service discovery protocol it is possible to discover thetopology of the hardware system during runtime. Using the service location protocol, the systemcan account for changes in the hardware configuation and the static hardware configuration filesmight no longer be required.

68

REFERENCES REFERENCES

References

[1] A. Rotem-Gal-Oz, Fallacies of Distributed Computing Explained. 2006.

[2] M.K. Goff, Network Distributed Computing: Fitscapes and Fallacies. Prentice-Hall, Inc.,Upper Saddle River, 2004.

[3] G. Coulouris, J. Dollimore & T. Kindberg, Distributed Systems: Concepts and Design.Addison-Wesley/Pearson Education, UK, 4th Edition, 2005.

[4] K. Birman, Reliable Distributed Systems: Technologies, Web Services and Applications.Springer-Verlag, New York, 2005.

[5] A. Tanenbaum and M. Van Steen, Distributed Systems: Principles and Paradigms. Prentice-Hall, Inc., Upper Saddle River, 2002.

[6] F. Schneider, Distributed Systems: Replication management using the state-machine ap-proach. Addison-Wesley, Massachusetts, 2nd Edition, 1993.

[7] L. Lamport, Computer Networks: The implementation of reliable distributed multiprocesssystems. 1978.

[8] J. Gray & A. Reuter, Transaction Processing: Concepts and Techniques. Morgan Kaufmann,San Mateo, 1993.

[9] C. Mohan, B. Lindsay & R. Obermarck, Transaction Management in the R* DistributedDatabase Management System. 1986.

[10] T. Erl, The Principles of Service-orientation: Service Discoverability and Composition.Available at http://searchsoa.techtarget.com (September 5, 2006).

[11] M. Poulin, Evolution of principles of Service Orientation: Service Composability and Dis-coverability. Available at http://www.ebizq.net (February 26, 2009).

[12] M. Kircher, Pattern-Oriented Software Architecture: Patterns for Resource Management.John Wiley & Sons, West Sussex 2004.

[13] D. Schmidt, M., H. Rohnert & F. Buschmann, Pattern-Oriented Software Architecture:Patterns for Concurrent and Networked Objects. John Wiley & Sons, West Sussex 2000.

[14] F. Buschmann, R. Meunier, H. Rohnert, P. Sornmerlad & M. Stal, Pattern-Oriented Soft-ware Architecture: A System of Patterns. John Wiley & Sons, West Sussex 1996.

[15] Sun Microsystems, Java Management Extensions (JMX) Technology Overview. Availableat http://life.csu.edu.au (September 2004)

[16] W. Keith Edwards, Core Jini. Prentice-Hall, Inc., Upper Saddle River, 2nd Edition, 2001.

[17] G. Bieber, J. Carpenter, OpenWings Whitepaper: Introduction to Service-Oriented Pro-gramming. Available at http://www.openwings.org 2001.

[18] E. Guttman, IEEE Internet Computing: Service Location Protocol. 1999.

[19] R. Schmelzer, The Seven Levels of Loose Coupling. Available at http://www.zapthink.com(November 2007)

69

http://searchsoa.techtarget.com

http://www.ebizq.net

http://life.csu.edu.au

http://www.openwings.org

http://www.zapthink.com

Glossary Glossary

Glossary

asynchronous An asynchronous system oper-ates under distributed control, with con-current hardware components communi-cating and synchronizing on channels .31, 36

bandwidth A measure of the capacity of acommunications channel. The higher achannel’s bandwidth, the more informa-tion it can carry . 23

boxed type A dynamic object containing a value,so that the value can be used as a refer-ence object. 35

distributed computing Dividing a program intoparts which can run simultaneously onmultiple computers within a network . 21

distributed system An application that exe-cutes a collection of protocols to coor-dinate the actions of multiple processeson a network, such that all componentscooperate together to perform a single orsmall set of related tasks, only by passingmessages. 21–23, 36

fault-tolerant always behaving correctly de-spite up to a given number and type offailures . 21–23, 34

highly available continuing to provide a pos-sibly degraded service despite a certainnumber and type of process failures anddespite disconnected operations . 22, 23

homogeneous network A network running asingle network protocol. 23

latency The time between initiating a requestfor data and the beginning of the actualdata transfer . 23

legacy system An old computer system or ap-plication that continues to be used eventhough newer technology is available, typ-ically because it still functions for theusers’ needs. 26

lightweight directory access protocol An ap-plication protocol for querying and modi-fying directory services running over TCP/IP. 35, 36

loose coupling some kind of connection or re-lationship between entities where the levelof dependency is minimized . 25, 36

monotonicity when executed actions or madepublications cannot be reverted . 22

pluralism when one’s dealing with heteroge-neous, overlapping and possibly conflict-ing information . 22

protocol A formal description of message for-mats and the rules that two processesmust follow in order to exchange mes-sages. 21, 30, 70

publish-subscribe an asynchronous messagingparadigm where senders (publishers) ofmessages . 31, 36

separation of concerns theory based on thenotion that large problems become easierto handle as they are broken down intosmaller problems . 24

service contract Communicates the purposeand capabilities of a service and describeshow the service interacts with its con-sumers. 25

service location protocol A service discoveryprotocol that allows computers and otherdevices to find services in a local areanetwork without prior configuration . 37

service oriented architecture A paradigm fororganizing and utilizing distributed capa-bilities that may be under the control ofdifferent ownership domains. It providesa uniform means to offer, discover, inter-act with and use capabilities to producedesired effects consistent with measur-able preconditions and expectations. 24

70

Glossary Glossary

single point of failure A crucial part of a sys-tem which, if it fails, will stop the entiresystem from working . 26, 27, 37

topology The different configurations that canbe adopted in building networks, such asa ring, bus, star or meshed. 23

unbounded determinism a property of con-currency by which the amount of delayin servicing a request can become un-bounded as a result of arbitration of con-tention for shared resources while still guar-anteeing that the request will eventuallybe serviced . 22

whiteboard pattern defines a central appli-cation manager which is responsible forhandling dynamic behaviour with regardto life cycle management of system com-ponents . 31

71

Appendices

72

A SEQUENCE DIAGRAMS

A Sequence diagrams

The sequence diagrams in this section are part of the first version of the logical design. Wecreated our prototype based on this logical design, but some tiny changes had to be made.

A.1 Service lifecycle

Figure 7: Service lifecycle

73

A.2 Mapping service start A SEQUENCE DIAGRAMS

A.2 Mapping service start

Figure 8: Mapping Service start

74

A.3 Process service lifecycle A SEQUENCE DIAGRAMS

A.3 Process service lifecycle

Figure 9: Process Service lifecycle

75

A.4 Processing node start A SEQUENCE DIAGRAMS

A.4 Processing node start

Figure 10: Processing node start

76

A.5 Processing node goes down A SEQUENCE DIAGRAMS

A.5 Processing node goes down

Figure 11: Processing node goes down

77

A.6 Software system specification changed A SEQUENCE DIAGRAMS

A.6 Software system specification changed

Figure 12: Software system specification changed

78

Dynamic System Configuration using SOA

Technology

Transcript of Dynamic System Configuration using SOA