A Monitoring Approach for Dynamic Service-Oriented Architecture Systems

Yufang Dan, Nicolas Stouls, Stéphane Frénot and Christian Colombo, A Monitoring Approach for Dynamic Service-Oriented Architecture Systems. The Fourth International Conferences on Advanced Service Computing, SERVICE COMPUTATION 2012, pages 20--23. ISBN 978-1-61208-215-8.

In the context of Dynamic Service-oriented Architecture(SOA), where services may dynamically appear or disappear transparently to the user, classical monitoring approaches which inject monitors into services cannot be used. We argue that, since SOA services are loosely coupled, monitors must also be loosely coupled.

In this paper, we describe an ongoing work proposing a monitoring approach dedicated to dynamic SOA systems. We defined two key properties of loosely coupled monitoring systems: dynamicity resilience and comprehensiveness. We propose a preliminary implementation targeted at the OSGi framework.

Keywords: Monitoring, Dynamic SOA, OSGi, Larva

Transcript

1. A Monitoring Approach for Dynamic Service-Oriented Architecture Systems Y. Dan1,3, N. Stouls1, S. Fr´ enot1, and C. Colombo2 1Universit´ e de Lyon, INRIA, INSA-Lyon, CITI, F-69621, France – Email: first.second@insa-lyon.fr 2Department of Computer Science, University of Malta – Email: first.second@um.edu.mt 3College of Computer Science Chongqing University, Chongqing, China
2. Introduction Case study Related works Contributions Conclusion Monitoring What kind of monitoring Observation of an execution Check observed behavior against a property Observation granularity : external I/O of services Our objectives Considering dynamics in SOA Focus observation technique Future work Property description language expressiveness 2 / 14
3. Introduction Case study Related works Contributions Conclusion Dynamic SOA Service Oriented Architectures Loosely coupled client-server through interfaces A client request a service System fulfils the interface with an implementation Client uses the service But : Used service can disappear Used service can be substituted Each invocation can be provided with a different service Our case study: developed under OSGi. 3 / 14
4. Introduction Case study Related works Contributions Conclusion Our case study Init Commit Init Local service 1 (3G) Local service 2 (WiFi) Commit Init Commit Init Client System Property: Distant controlled Dynamic SOA Platform (mobile platform) Commit Distant system controlled through local services Local services can dynamically (dis)appear Objective: to check the respect of a property through the substitution of services 4 / 14
5. Introduction Case study Related works Contributions Conclusion Our case study WiFi connexion Commit Init Local service 1 (3G) Local service 2 (WiFi) Commit Init Commit Init Client GestService System Property: Distant controlled Dynamic SOA Platform (mobile platform) Commit Init Distant system controlled through local services Local services can dynamically (dis)appear Objective: to check the respect of a property through the substitution of services 4 / 14
6. Introduction Case study Related works Contributions Conclusion Our case study WiFi connexion Commit Init Local service 1 (3G) Local service 2 (WiFi) Commit Init Commit Init Client Init GestService System Property: Distant controlled Dynamic SOA Platform (mobile platform) Commit Init Distant system controlled through local services Local services can dynamically (dis)appear Objective: to check the respect of a property through the substitution of services 4 / 14
7. Introduction Case study Related works Contributions Conclusion Our case study Dynamic SOA Platform (mobile platform) Commit Init Local service 1 (3G) Commit Init Client Init GestService System Property: Local service 2 (WiFi) Commit Init Distant controlled Commit Init Distant system controlled through local services Local services can dynamically (dis)appear Objective: to check the respect of a property through the substitution of services 4 / 14
8. Introduction Case study Related works Contributions Conclusion Our case study 3G connexion Commit Init Local service 1 (3G) Commit Init Commit Init Client GestService Init GestService System Property: Local service 2 (WiFi) Distant controlled Dynamic SOA Platform (mobile platform) Commit Init Distant system controlled through local services Local services can dynamically (dis)appear Objective: to check the respect of a property through the substitution of services 4 / 14
9. Introduction Case study Related works Contributions Conclusion Our case study Init Commit Init Local service 1 (3G) Commit Init System Local service 2 (WiFi) Commit Init Client GestService Init GestService Commit Property: Distant controlled 3G connexion Dynamic SOA Platform (mobile platform) Commit Distant system controlled through local services Local services can dynamically (dis)appear Objective: to check the respect of a property through the substitution of services 4 / 14
10. Introduction Case study Related works Contributions Conclusion Guidelines Our objectives What’s the meaning of monitoring a dynamic SOA? How to define/interface such monitor? Our contributions Definition of two main properties: dynamicity resilient comprehensiveness Proposition of an architecture: A non-intrusive proxy Declared neither in client, nor in service OSGiLarva : proof of concept 5 / 14
11. Introduction Case study Related works Contributions Conclusion Related works – Classified by monitor configuration Hard-coding Properties manually written inside the code Ex: JML or Spec#, annotation languages not resilient to dynamic code loading Soft-Coding Properties automatically injected inside the code Ex: Larva or JavaMOP, monitors by aspects not resilient to dynamic code changing Agnostic-Coding Properties kept out of the code Ex: EventLog, IDS trace analyzer not comprehensive, depends on what is logged 6 / 14
12. Introduction Case study Related works Contributions Conclusion Monitor properties First contribution: monitoring properties Dynamicity resilient monitor kept in memory even if a service is unloaded property is not hardly linked to the code Comprehensiveness monitor can not be bypassed the monitor is not provided as a part of the code 7 / 14
13. Introduction Case study Related works Contributions Conclusion OSGi-Larva Second contribution: proof of concept under OSGi Hello() Hello() Monitored Events Larva Property Checking Automaton Client Server User Analyzed Report OSGi-Larva Checks the use of services VS a property Based on OSGi framework, LogOS proxy and Larva Monitor 8 / 14
14. Introduction Case study Related works Contributions Conclusion OSGi-Larva OSGi-Larva LogOS Logging proxy based on OSGi Patched to generate events description to send to Larva Larva Java Monitor based on aspects Property description language based on parametrized timed automaton Patched to replace aspects by events description 9 / 14
15. Introduction Case study Related works Contributions Conclusion OSGi-Larva Life Cycle OSGi bundle: Deployment Unit Interfaces Service implementations Deployment code Property life cycle Associated to Interfaces Can be deployed without any implementation Kept in memory at least while the client needs it 10 / 14
16. Introduction Case study Related works Contributions Conclusion OSGi-Larva Comparison with Aspects: Some Results 11 / 14
17. Introduction Case study Related works Contributions Conclusion Conclusion Contributions Two main properties to monitor D-SOA systems Resilience to dynamicity Comprehensiveness Proof of Concept: OSGiLarva Monitor for OGSi services Based on Larva monitor and LogOS logger Larva property description language Time cost really close to aspect approach Non intrusive approach (Binary unchanged) 12 / 14
18. Introduction Case study Related works Contributions Conclusion Future Work To increase the property language with dynamic primitives (Loading / unloading / substituting services) To complete the tool to consider value of I/O parameters to make the deployment to be automatic to externalize the monitor in another thread To merge this approach with our substitution API to make some autonomous and intelligent substitutions 13 / 14
19. Introduction Case study Related works Contributions Conclusion Questions ? 14 / 14