| Les deux révisions précédentes
Révision précédente
|
|
draft_paper_sc_2010 [2010/01/13 07:44]
tigli |
draft_paper_sc_2010 [2010/01/17 23:02] (Version actuelle)
tigli |
| |
| ====== TITLE : xxxxx ====== | ====== TITLE : xxxxx ====== |
| | |
| | |
| | Plan Papier Annie : |
| | |
| | Titre : Statefull Service Composition, the key in Multi-device Applications |
| | |
| | 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, the low level computational model and the application, the high level conceptual (sometimes abstract) model, at runtime. |
| | |
| | In a fisrt simple architectural model, middleware if the layer 2 between first software level fo the operating system (layer 1) and last software level of the application (layer2). But generally much more layers exists between the first adn the last one [ref] following a simple principle : |
| | 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 were designed using a layered approach. |
| | |
| | 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, the real problem for IAm is to deal with uncourtered possible configuration ( "a priori unknown"). Its what we call Heterogenity. |
| | |
| | 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 is a subsequent consequence. How layers n must take into account evolutions of layers n-1. In the cas of service continuity, the main hypothesis is : the application must be always running and must provide the most of the functionnalities it'a a priori dedicated to. |
| | |
| | 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 dynamics of the adaptation, self-adaptation is much more convenable to the challenge. Due to the proximity of the dynamics of such adaptation with the dynamics of the application itself, such self-adaptation will be called reactive adaptation. |
| | |
| | Reactivity is .... |
| | |
| | |
| | 2> Related Works : |
| | |
| | New challenge are then : |
| | |
| | - Deal with the high variablity of the entities of low leval layers (insfrastructure) (variability in space : semantic heterogeneity and time : dynamicity ) |
| | |
| | The severity of the domain is due to the degree of variability in space and time. |
| | - heterogeneity in an a priori partly known space |
| | - 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, multiple cycle, evolution of the code of the application (at design or even at runtime). From the overall system point of view is still a user (expert user) driven approach that can't be use like that for self-adaptation. |
| | |
| | Recents works has introduced new ways to select sets of aspects to apply at runtime. |
| | ... (Biblio / Safran .. ] |
| | In fact such approaches : |
| | 1> use external mechanism to select aspects |
| | 2> doesn't care on the dynamics of such adaptation cycle in front of the dynamics of the application |
| | 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 evolution of the infrastructure, because in IAm the first reason to adapt the application is the dynamic appearence and disappearence of device in the environment of the application. We use pointcut matching to fit the strcutural requirements in the infrastrcuture to apply one aspect. |
| | |
| | 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 appears like a good way to combine (weave) in an existing software entity, a fortiori layer, some modifications and dependencies to new functionalities (a fortiorei layer). Moreover our previous works provide interesting results to reactivly adapt IAm applications like Services for Device Compositions. |
| | |
| | One of the key problem in reactive adaptation is then weaving or how to combine the various modifications from produced by the different selected aspects with the current application. |
| | |
| | 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, associativity, indempotence for the composition between proposed componenet assemblies to weave). (cite Berger , DAniel , papiers..) |
| | |
| | Nevertheless such approach doesn't solution properly how to deal with potential conflict in concurrent muliple access to a unknown a proiri component unknonw by the langage. |
| | |
| | For example in ISL4WComp concurrent access to an "operator of hte language" component like IF, can be rewritten properly, knowing semantic of IF. |
| | |
| | But concurrent access to an a apriori unknonw component light for example with implicite semantics doesn't allow to manage the consequences of the concurrent access light.on light.off ... |
| | |
| | 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 modeled components and properties after weaving as constrains |
| | |
| | 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 behaviors and moreover provide a lot of verifiers tools based on efficient model-checking to verify properties. |
| | |
| | 4.1 What critical component means ? |
| | |
| | Critical components are components providing : |
| | - a synchronous model of their behaviour |
| | - some additional properties (constrins) to verify when such component is used. |
| | |
| | Example |
| | |
| | |
| | - Synchronsous Model becomes a monitor component beyond the unsafe proxy component |
| | - unverified constrains are solutionned using assertions as a new filter component beyond the monitor 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 : Traffic Light |
| | |
| | Overall use case : |
| | - 4 Traffic Light |
| | - 4 Walking people Light |
| | - 4 Push button Wlaking people |
| | .... |
| | |
| | 5.0> Overall Application |
| | |
| | dessin |
| | |
| | 5.0.1> list of Devices |
| | 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 constrains |
| | |
| | |
| | |
| | 6> Conclusion and Perspectives |
| | |
| | |
| | |
| | 6.2> perspectives |
| | |
| | - we need to study, temporal behavior of conflict detection and composition beween critical components |
| | - other models for components and other model-checkers |
| | |
| | |
| | |
| | |
| | ---- |
| |
| ===== Abstract ===== | ===== Abstract ===== |
