back to: Bartosz Kosarzycki home page

This is just an abstract of the full work translated from Polish.
This paper is a partial result of a 2-year project at Poznań University of Technology (PUT).

Thesis on SOA:
Service Execution Management for SOA Systems

authors:
Bartosz Kosarzycki
Jakub Misiorny
Tomasz Pawlak
Łukasz Rek
Aleksander Wieczorek

1.1 Service Oriented Architecture
    SOA (Service Oriented Architecture) is a relatively new paradigm in the creation on computer software. In this approach programmers write small fragments of business logic as components of the whole application. SOA-driven application is therefore a collection of services that communicate with each other to accomplish complex tasks. [...]
    SOA systems are distributed (scattered) across several physical computer severs and communicate with each other with the help of REST/SOAP. Services are collected into a public repository where they can serve as part of the whole business logic separately. [...] One can download these or use them online.
    SOA services can be owned by different shareholders but it does not matter to the end-client who buys the functionality and connects the parts to create his own business logic. [...] SOA services are loosely coupled meaning that they can work separately and do partial tasks without the need to communicate with each-other. [...]
    The SOA paradigm does not force any communication standards but encourages to use well-defined and widely-used protocols (such as REST or SOAP). [...]
 
1.2 Problem description and concept of the chosen solution
    Rising popularity of SOA systems brings new challenges. One of these is the monitoring of created SOA services. Service monitoring eases the implementation of smaller systems but is definitely a must when it comes to bigger solutions. [...]
    Monitoring is done but the appropriate Execution Management System that we have implemented. [...]
    The administrator defines an "abstract metric" which is a metric template. Templates are stored in a repository. "Specific metric" is created when we combine abstract metric with the name of the specific service and specific host that the service is running on. Specific metrics are used by the monitoring system to measure the quality of services. The quality is measured with the help of QoS (Quality Factor) factor and is part of the quality contract that is formed between the service provider and service recipient. The deal contains not only the QoS factor values that need to be met but the percentage of Service uptime as well. If the service does not meet the QoS it is considered down. 
    Reliability and quality of services is assured thanks to service replication. [...]

1.3 Work goals and its scope
    Our goal is to implement a fully working management system for SOA. The functionality includes the management of metrics to evaluate SOA systems. The system add, deletes, modifies abstract and specific metrics; Management of SLA contracts which includes warning the administrator and service recipient if the contract is not met (service is down, QoS factor is not met); Initialization of automated service recovery procedures in case of abnormal service behavior; Help to provide high quality services thanks to load balancing and service on-line cloning; Anomaly detection service that can predict crushes before they happen. Web graphical user interface for controlling service execution management. 

2. Technologies used

2.2 Technologies in management system
    The main service was written in Java 2 Standard Edition (J2SE). Equinox was used as a extension to J2SE enabling the implementation of OSGi standard (Open Services Gateway initiative). OSGi defined a way of creating software as plug-ins (or so-called bundles). As IDE we used "Eclipse for RCP/Plug-in Developers" because it enabled the creation of applications in OSGi standard. 
    Spring dynamic modules library was used as a run-time environment and transaction manager. [...] Transaction management was connected with Hibernate library and as a database systems we used PostgreSQL.
    For serializing/deserializing Java objects into XML we used XStream library which enabled us to freely change XML structure. [...] REST protocol was implemented thanks to Restlet library.

2.5 Technologies in web graphical user interface WebGUI
    Graphical user interface was implemented as an internet application. DJango was used as production environment. The whole web page was written in python 2.6. REST communication was implemented with the help of restclient library and XML serialization/deserialization was done with generateDS. [...]

3.1 Runtime context
    The management system described above is supposed to integrate with several monitoring systems [...] that perform not only monitoring but replication as well. [...] The scope of cooperation includes generation of well defined metric descriptions, sending them to monitoring system, collecting measurement results, checking SLA (Service Level Agreement) contract terms fulfillment and anomaly detection with failure detection. [...]
    When it comes to QoS module it has to cooperate with external proxy server that divides traffic between appropriate service replicas. [...] One of the tasks of QoS module is the preparation of load statistics of individual services. 



6.3 Logical Perspective
    Management system consists of two main parts. The first one serves as data repository, the second is the core application. Apart from these two parts there is also REST server through which we can call the functionality of any module. 

yellow - data processing units
green - business logic
blue - presentation layer


    QoS Manager implements the functionality connected with quality factors. Metric Manager is responsible for the communication with monitoring system and generating definitions of metrics. SLA Manager checks fulfillment levels of SLA contracts. [...] If the contract is not fulfilled SLA Manager uses one of the notifiers to send warnings to the administrator. [...] Notifiers mentioned before are handled by Notifier Manager. 
    User Manager handles users and their passwords, as well as add, deleting and granting access rights. REST server conducts authorization.

6.4 Concurrency Perspective
    Interaction with the system is done in a couple of separate layers. WebGUI is the main source of all events but they can come from QoS proxy, Metric consumer, SLA module or anomaly detector as well. Events from users can go to any module in the system - a perfect example of direct communication with any module is sending configuration which is done with the help of REST directly to the module. [...]
    Metric consumer (REST) gets metric values from an engine that calculates them and sends to the SLA manager.  



6.5 Implementation Perspective
    Our system is divided into two parts. The first part is implemented in Java and computes all the business logic. The second is a "thin client" which is written in DJango and serves as a GUI. These two parts communicate with each other with the help of simple HTTP protocol. All administrator actions are password protected. The architecture makes it extremely easy to write extensions - you can always write a second "service" that will be connected to the GUI or write a completely different GUI. You can always reuse any number of smaller services that the main business logic is composed of which saves time and money. 
    System runs on Equinox platform which is part of OSGi standard. Every service is a separate OSGi plugin which gives an ability to turn it on/off during system uptime (while the system is running). Spring Dynamic Modules was used as system runtime environment. One of SDM modules is a Hibernate library used to cast object into relational database. 


violet - run-time platform
yellow - data processing units
green - business logic
blue - presentation layer


6.6 Physical perspective
    Management system was developed/run entirely on a single virtual machine. It communicates with monitoring system that was run on another machine. Anomaly Detection and Prediction were put inside monitoring system. QoS proxy serves outside user demands and because of high load was moved to another virtual machine. WebGUI is run on a separate Web server. [...] Using virtual environment allowed us to better utilize physical resources, use replication features and protected us from failure and viruses.






you can contact me at: kosiara87 [at] gmail.com    (Bartosz Kosarzycki)

©2010 Bartosz Kosarzycki, JakubMisiorny, Tomasz Pawlak, Łukasz Rek, Aleksander Wieczorek

BibT EX:
@mastersthesis{ key,
  author = "Bartosz Kosarzycki nand Jakub Misiorny nand Tomasz Pawlak
      nand Łukasz Rek nand Aleksander Wieczorek ",
  title = "{System zarz ˛adzania wykonaniem usług w systemach SOA}",
  school = "Poznan University of Technology",
  address = "Pozna{n’n}, Poland",
  year = "2010",
}

translation: Bartosz Kosarzycki
Comments