JY Tigli Homepages

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.

====== 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 =====
 
===== Introduction =====

===== Ambient Intelligence  =====

===== For example : Activity Recognition  =====

===== Related Works =====

===== Service or Component ? =====

==== Reusability : duplication and sharing ====

==== Statelessness or statefulness ====

    * StateLess versus StateFull service 
Statefull service must care about multiple access. 

===== Service oriented Devices Composition  =====

==== Services  Composition  ====

    * Language based 
    * Assembly based 

==== Concurrent Access to service ====  

    * Lack of determinism and proof in the case of Stateful Service ... 
    * 
===== Our Approach =====

  * Synchronous Hypothesis and Prooved Monitor Component 

  * Activity Recognition Application
JY Tigli Homepages

Outils pour utilisateurs

Outils du site

Outils de la page
