draft_paper_sc_2010
Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentesRévision précédente | |||
draft_paper_sc_2010 [2010/01/13 06:44] – tigli | draft_paper_sc_2010 [2010/01/17 22:02] (Version actuelle) – tigli | ||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
====== TITLE : xxxxx ====== | ====== TITLE : xxxxx ====== | ||
+ | |||
+ | |||
+ | Plan Papier Annie : | ||
+ | |||
+ | Titre : Statefull Service Composition, | ||
+ | |||
+ | 1> Introduction : | ||
+ | |||
+ | Middleware is today cahllenging by grid-computing , ubqutious computing, prevaisive computing, context-awarness ... | ||
+ | |||
+ | Main question : New challenges or new application domains ? | ||
+ | |||
+ | Main message : Middleware have evolved and must eveolved | ||
+ | |||
+ | 1.1 Middleware have evolved | ||
+ | |||
+ | Message : From a restricted definition to a generalized one | ||
+ | |||
+ | Middleware is a bridge at runtime between the software infrastructure, | ||
+ | |||
+ | In a fisrt simple architectural model, middleware if the layer 2 between | ||
+ | Layer N-i provide functionnalities to Layer N or Layer N need functionnalities from Layers N-i. | ||
+ | |||
+ | 1.2 Middleware must evolved | ||
+ | |||
+ | Message : With IAm , we assist to a kinf of inversion of software design méthodology | ||
+ | |||
+ | In fact, since a long time software application | ||
+ | |||
+ | Layer n using and knowing Layer n-1. One layer n-1 for one layer n in a bottom up approach, but also muliple layers n-1 for one layer n in a top down approach. | ||
+ | Even if we using the most recent works for that (ex. from Model Driven Engineering) the various layers n-1 musn't be numerous and such problematic is open and called variability of the configurations. Such approaches are probably convenient for multiple potential configurations but also for long term static configurations. | ||
+ | |||
+ | IAm applications is a much more severe domain : | ||
+ | |||
+ | principe 1 : layers n-1 is partly known at design time. In a first time we can simplify such hypothesis limiting layers n-1 to a set of a priori known TYPE of entities. Nevertheless, | ||
+ | |||
+ | example : | ||
+ | |||
+ | principe 2 : layers n-1 moreover evolve dynamically with its own dynamics. It's what we call Dynamicity | ||
+ | |||
+ | example : | ||
+ | |||
+ | In conclusion, contraly to the classical software design approaches , application layer is now much more stabla then low level layers. During cumerous years, standard was the way to hide the possible evolution of layers n-1 for layer n. Today such approach can be anymore the solution. The layers n-1 is not only changing in an a priori unknown space but also with dynamics close to these of the appication itself. | ||
+ | |||
+ | Adaptation | ||
+ | |||
+ | Adaptation could be a kind of a reengineering cycle of the applications to take into account the modificatiosn of Layers N-i. | ||
+ | |||
+ | Due to the exigences of the required | ||
+ | |||
+ | Reactivity is .... | ||
+ | |||
+ | |||
+ | 2> Related Works : | ||
+ | |||
+ | New challenge | ||
+ | |||
+ | - Deal with the high variablity | ||
+ | |||
+ | The severity of the domain is due to the degree of variability in space and time. | ||
+ | - heterogeneity in an a priori | ||
+ | - dynamicity with high dynamics, close to these of the application | ||
+ | |||
+ | - Require reactive Adaptation | ||
+ | |||
+ | 2.1 Some common approaches with classical Information Systems and Grid Computing for example | ||
+ | |||
+ | To react to the evolution of Layers N-1, this layer must be observable. | ||
+ | That means that we can observe not only appearence of new functionalities and software entities bue we can also detect their disappearence. | ||
+ | |||
+ | 2.2 Some differences | ||
+ | |||
+ | UPnP | ||
+ | DPWS | ||
+ | WS-ECA | ||
+ | |||
+ | |||
+ | |||
+ | Aspect oriented appraoch are classicaly used for adaptation of existing object oreinted code in a kind of incremental, | ||
+ | |||
+ | Recents works has introduced new ways to select | ||
+ | ... (Biblio / Safran .. ] | ||
+ | In fact such approaches : | ||
+ | 1> use external mechanism to select aspects | ||
+ | 2> doesn' | ||
+ | 3> always using AOP in the last step, dedicated to modification of object oriented target entities. | ||
+ | |||
+ | |||
+ | Our previous works answer to such limitations : | ||
+ | 1> Reactive adpatation need to first focus on the structural | ||
+ | |||
+ | 2> the dynamics of the overall weaving mechanism is study in details to manage te relevance of the reactive adaptation using our aspect according to the dynamics of the application. | ||
+ | |||
+ | 3> adaptating the advice to provide different kind modifications compatible with every kind of target model (in the case of aspect of assembly (AA), the target model is not object-oriented code but a components assembly); Various languages can be provided to operate such target modification (ISL4WCOMP (from ISL), BSL, SSL ...) | ||
+ | |||
+ | |||
+ | 3> New limitation and contribution | ||
+ | |||
+ | As we see in section 2> Aspect paradigm | ||
+ | |||
+ | One of the key problem in reactive adaptation | ||
+ | |||
+ | In our AA approach such problem consist in providing a composition mechanism between the differents components assemblies respecting some required properties. | ||
+ | |||
+ | Our previous works used various languages for advice descirption. One of the most efficient was ISL4WComp that allow to compose assemblies verifying the symmettric property of the composition (commutativity, | ||
+ | |||
+ | Nevertheless such approach doesn' | ||
+ | |||
+ | For example in ISL4WComp concurrent access to an " | ||
+ | |||
+ | But concurrent access to an a apriori unknonw component light for example with implicite semantics | ||
+ | |||
+ | Such drawbacks is clearly mentionned in the Daniel Cheung PhD thesis (ref). | ||
+ | |||
+ | The first conclusion is then : a priori known operators corresponding to components is interesting to describe an advice as an asssembly factory in a friendly manner using a language, but is not sufficient to solve the potential conflicts in concurrent access on other components than operators. | ||
+ | |||
+ | 4> a posteriori | ||
+ | |||
+ | We propose in this paper to introduce models of critical components (that means component that they need to properly deal with muliple concurrent access). | ||
+ | |||
+ | In our approche such component are often proxies for service for device and then must reflect the device behavior. For these reason finite automata iare well adpated to the representation of devices | ||
+ | |||
+ | 4.1 What critical | ||
+ | |||
+ | Critical components are components providing : | ||
+ | - a synchronous model of their behaviour | ||
+ | - some additional properties (constrins) | ||
+ | |||
+ | Example | ||
+ | |||
+ | |||
+ | - Synchronsous Model becomes a monitor component beyond the unsafe proxy component | ||
+ | - unverified constrains are solutionned using assertions as a new filter component | ||
+ | |||
+ | TODO : Annie | ||
+ | |||
+ | 4.2 Multiple acces detection | ||
+ | |||
+ | Multiple access can be easily detected. Only conflicted access on a critical component wil be process. | ||
+ | |||
+ | 4.3 How we can compose same critical proxies components ? | ||
+ | |||
+ | New monitor ? New assertations ? | ||
+ | |||
+ | TODO avec Annie | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | 5> Use case and medium-fidelity prototype | ||
+ | |||
+ | Overall use case : | ||
+ | - 4 Traffic Light | ||
+ | - 4 Walking people Light | ||
+ | - 4 Push button Wlaking people | ||
+ | .... | ||
+ | |||
+ | 5.0> Overall Application | ||
+ | |||
+ | dessin | ||
+ | |||
+ | 5.0.1> | ||
+ | 5.0.2> list of AA and list of the resulting sub-assemblies to weave | ||
+ | 5.0.3> conflict detection on concurrent multiple access | ||
+ | |||
+ | 5.1> Zoom on one critical component and detected conflict | ||
+ | |||
+ | 5.1.1> Unsecure Web Service for device Trafffic Light | ||
+ | |||
+ | 5.1.2> Valid behavioral model and critical proxy component | ||
+ | |||
+ | 5.1.2.1> Lustre behavioral Model | ||
+ | |||
+ | 5.1.2.2> Critical proxy component generation | ||
+ | |||
+ | 5.1.3> Additionnal constrains | ||
+ | |||
+ | 5.1.3.1> Safety | ||
+ | |||
+ | |||
+ | |||
+ | 6> Conclusion and Perspectives | ||
+ | |||
+ | |||
+ | |||
+ | 6.2> perspectives | ||
+ | |||
+ | - we need to study, | ||
+ | - other models for components and other model-checkers | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ---- | ||
===== Abstract ===== | ===== Abstract ===== |
draft_paper_sc_2010.txt · Dernière modification : 2010/01/17 22:02 de tigli