Keywords: moèles à composants, langage de description d'architectures, aspects non-fonctionnels

Une extension de l'ADL pour les composants GCM, prenant en compte la spécification exhaustive de la membrane

Résumé : Dans ce document nous proposons un ensemble d'extensions pour la structure actuelle des fichiers ADL, utilisés pour décrire les assemblages de composants GCM. Ces extensions introduisent la spécification exhaustive de la membrane, une meilleure séparation entre la partie fonctionnelle et non-fonctionnelle des composants, et les communications entre le contenu fonctionnel et la membrane. Les extensions que nous proposons sont basées sur le modèle proposé dans [1].

Introduction

This document is a technical report, which goal is to introduce and illustrate possible changes to do in the current GCM ADL file. It concerns improving adls by giving the possibility to design component systems inside GCM membranes.

Currently, there is no possibility to do so. The first proposition to define a component membrane was to specify the reference to an adl file inside the "controllerdesc" tag of traditional GCM adls. This was a pretty good idea, as the description of the membrane can be done in a separate file (just like in previous versions of GCM and Fractal frameworks in general), with no modification of the adl dtd. In this file we could specify the controller system as a classical component assembly (with no difference compared to a classical adl). We call this file the NF adl. The standard way of specifying a component assembly is to include it inside a global "definition" tag, which represents a composite. Thus, the membrane is also specified as a composite. The interfaces defined in this adl represent NF interfaces of the host component (the "owner" of the membrane), that we simply call NF interfaces. We introduced the concept of the "dissolved membrane": the composite wrapping the component controllers is not created : only the interfaces, the inner component system, and the bindings are created.

Taking this NF adl as a starting point, several issues have to be considered:

• The definition and integration of NF interfaces.

• The definition Nf component systems

• The specification of functional internal interfaces

• The definition of interceptors

• The definition of a development process to ease the design of a component with Nf components in the membrane

Development process and roles

According to Szyperski [START_REF] Szyperski | Component Software: Beyond Object-Oriented Programming[END_REF], one person should be able to deal with the design and the implementation of one component. In our case, we will need at least two specialists: one in charge of designing the functional content (the functional assembler) of the component, and one to design the Nf part (the Nf assembler) of the component. We believe that those two persons can work separately, relying only on interfaces between functional and non-functional worlds and constraints of the component architect (the person who expects the component to be produced).

The component architect

The component architect is a person who wants to assemble a component system out of already existing components. Refering to the book of Clemens Szyperski, what we call the component architect is in fact the component assembler: "A component assembler takes application requirements, selects appropriate components, and assembles these". In our case, the component assembler needs to specify the functional interfaces of components he wants to include inside his system and may be also the Nf interfaces, as in the case of Fractal, he also has to know what non-functional features he needs the components of his system to have (besides the ones that are part of the framework). For this, he needs to define what are the (re)configuration possibilities of these components. We suppose that he asks specialists to produce some of the components that will be integrated into his system. He can specify the functionality of the components he needs in several ways, depending on his expertise. First of all, he can specify the functionality of a component in an abstract way, starting with handwritten text. He can also express some preferences regarding the signatures of the interfaces he wants the components to expose, the operational behavior of the component's interfaces and finally an elaborated semantic description. The specialists will have to take those constraints into account when designing and developing the components.

The functional assembler

For a primitive component, the functional assembler is may be what Szyperski calls a component developer. This person is in charge of producing the business code, according to the abstract functional specification of the architect. Instead of developing his own pieces of code, the functional assembler can also reuse some already existing components (or make them produced) and assemble them inside a composite component in order to fulfill the wishes of the component architect. Somehow, at the level of the composite component, the functional assembler becomes the component architect by choosing and putting some constraints on the components he needs.

When designing the functional content of a component, the only specification that the functional assembler takes into account is the abstract functional description of the architect. He then has the possibility to choose whatever he considers best to implement the functionality of the component he is assembling in terms of the interfaces(signatures) and their operational behavior. Indeed, the interfaces that give access to the functional content of a component are internal interfaces. Those internal interfaces can be entirely specified by the functional assembler. If the component architect expresses some constraints on the interfaces exposed by the component, it is up to the Nf assembler to match these constraints by including inside the membrane the components that will consistently connect external interfaces (from the specification of the architect) to internal ones (chosen by the functional assembler). If we consider the new possibilities of GCM components(bindings from the membrane to the content and from the content to the membrane), the functional assembler has to know the specification of the Nf interfaces of the components he is assembling because he will have to choose the Nf interfaces of the functional components that will be accessed from the membrane. Accordingly, the Nf assembler will include those interfaces as internal interfaces of the membrane. For connexions between the content and the membrane, the functional assembler can specify the Nf internal interfaces the membrane should expose. The process of choosing the interfaces between the membrane and the content should be performed in several refinement steps, because the Nf assembler may also put some constraints on the Nf interfaces exposed by components inside the functional content. At the end, both specialists must agree on a set of interfaces between the content and the membrane.

The non-functional assembler

The first job the Nf assembler does is to choose the external interfaces of the component. For functional interfaces, if the component architect did not express any constraints, the best solution for the Nf assembler is to define external interfaces corresponding to the internal interfaces defined by the functional assembler. If the component architect expressed any preferences, the Nf assembler must make sure that the external interfaces will communicate consistently with the internal ones(by including for example the corresponding interceptors). The Nf assembler chooses the Nf interfaces exposed by the membrane according to the specification of the component architect. Then he has to choose and assemble the component controllers that will supervise the functional part of the component by taking into account the environment in which the component will run and the points of interaction with the functional content. We take the assumption that with primitive components it should be not possible to perform structural reconfigurations (for example, dynamically replace the functional content) but only reconfigurations based on parameter tuning.

Internal interfaces

There is an important point to discuss, concerning the way those interfaces are defined and the constraints that we put on them. As in some case we need to explicitly define internal interfaces, we need to introduce a specific tag. We propose to add a new keyword for the interface role, like "internal-server" and "internal-client". In the next sections, we will discuss about the constraints that we put on internal and external interfaces.

Generally, we propose to give freedom on the number of external and internal interfaces of any component.

Primitive components

From the Fractal specification, there are no internal interfaces for primitive components, as the set of internal interfaces is accessed through the ContentController, which is a controller that is specific to composite components. From what we said in Section 2.2, we consider that internal interfaces for primitive components are necessary. Indeed, the functional assembler has the possibility to choose whatever he considers best to implement the functionality of the component in terms of the interfaces(signatures) and their operational behavior. However, we put an aditional constraint on primitive components: each external functional interface has a complementary internal interface of the same name, signature, and contingency , and of opposite role. This is a first version of the constraints (that may be improved) justified by the fact that external interfaces of primitive components are tightly coupled with its content (inside an adl, the content is specified by a class that implements the external server interfaces and contains the external client interfaces of the primitive component). What is the point of introducing those internal interfaces? This will be an improvement of the old way of intercepting used in the GCM framework. At the moment, if there is any interceptor defined, it intercepts any call on a functional interface. With internal interfaces, we will be able to specify interceptors that are specific to an external interface (in the case on input interceptors) and connected to a specific internal interface. Interceptors are presented with more details in Section 4.1. The cardinality of any internal interface should be singleton, no matter what is the cardinality of the external interface. This is because the sigleton interface does not brake the behavior of an external interface. For example, if an external server interface is gathercast, after all the calls are synchronized, a call is emmited on the corresponding internal interface which will simply forward the call to the content without adding any extra behavior. Symmetrically, if an external client interface is multicast, the content will first perform a call on the corresponding server internal interface, which will forward the call without doing any change to the external interface or to an interceptor if there is one.

We are still working on those constraints, trying to figure out a way to introduce more flexilibity for primitive components.

We can think of several ways of accessing those internal interfaces, which for me is just an implementation issue(which controller will give access to the internal interfaces??). Thte good thing is that we don't need to define them inside an adl because they are somehow implicitely defined.

Composite components

From the Fractal specification, we can read: "... each internal functional interface has a complementary external interface of the same name, signature, contingency and cardinality, and of opposite role (but the converse is not necessarily true)"

We propose to give freedom on the number of external and internal interfaces for composite components. This means that the content section of a composite may define an arbitrary set of internal interfaces and that the set of external interfaces may be totally different both in number and concerning the usual attributes of an interface (signature, role, cardinality and contingency). As explained earlier, it is up to the Nf assembler to connect the interfaces in a consistent way, by making sure that the functionallity of the component is implemented.

Designing a membrane with components

Here, we will introduce several ways of defining component systems inside GCM membranes.

Non-functional type

With the idea of defining nf systems inside adls, the first thing to consider is how to explicitely define the non-functional type of a component(the set of Nf interfaces of the component). The most intuitive decision is that it has to be defined the same way as the functional type. Figure 1 gives an example of a NF type. This way, this NF type can be included inside adls as a preexisting Nf type, with the help of the extends tag(extends="org.objectweb.NFType"). Notice that the Paul Naoumenko definition of internal interfaces is allowed for the Nf type. The org.objectweb.NFType can be extended by the adl file that is specific to the membrane(see for example Figure 7). Further in this document, we will present how to use the Nf type.

1 <?xml version="1.0" encoding="ISO-8859-1" ?> 2 <!DOCTYPE .... > 3 <definition name="org.objectweb.NFType"> 4 <interface signature="org.objectweb.fractal.api.control.BindingController " role="server" name="binding-controller"/> 5 <interface signature="org.objectweb.fractal.api.control. LifeCycleController" role="server" name="lifecycle-controller"/> 6 </definition>

Primitive component

Here, we will describe various ways of defining a primitive component, starting with a description compatible with the old adl, ending with fully-fledged component systems for the membrane. In Figure 3 there is a standard description of a primitive component. In Figure 2, there is the corresponding graphical representation. This description is compatible with the old GCM adl. The keyword "primitive" means that a default file will be chosen for the description of the membrane's structure.

Notice that the internal interfaces that can be seen on Figure 2 are implicit (are not declared in the adl), because they correspond to the external interfaces, as explained in Section 2.4.1. Nevertheless, those internal interfaces need to be explicitely mentionned when statically defining the binding with an interceptor. The dashed bindings that you can see between the class and the internal interfaces are not real bindings. They only mention an implicit connection between the the content and those interfaces.

In Figure 5, there is the definition of a primitive component with a componentized membrane. In Figure 4, there is the graphical representation of this system. The particularity of this adl is that the membrane is defined in an inline component system (inside the same adl) in the controller section (between lines 7 and 15). Indeed, the controller section has been extended in order to give the possibility to define interfaces, components and bindings. Interfaces declared in this section are either NF interfaces exposed by the membrane, or references to functional interfaces, which will be discussed in Section 4. Components declared in this section are only NF components. The bindings are either bindings connecting elements of the membrane or bindings connecting interceptors to functional interfaces. It is important to notice that this controller section contains only interfaces, components and bindings, with some other optional properties (cf. the dtd of the new adl). If any other section is included inside the controller one, it will be ignored (for example, no controller section as this section is already defining the membrane).

An alternative for the same architecture is described in Figure 6 and Figure 7. Those two figures show that the membrane can be defined in a separate file and then referenced in the main file.

One of the main goals of this new adl structure is to reflect the separation of roles during the design process of a component like explained in Section 2.

Composite component

In this section, we are going to introduce how to define the adl of a composite component according to the new specification. We will define various and equivalent ways, starting from definitions compatible with the old adl, ending with membranes equipped with GCM components and interceptors. In Figure 8, we graphically represented a simple composite component, with a set of functional components inside its functional content and a set of Nf components inside its membrane. In Figure 9, there is the corresponding adl description. Notice that this adl reuses some previously introduced concepts, like using an external file for the definition of its MyServerInterface"/> 5 <interface name="itf2" role="client" signature="org.objectweb.

MyClientInterface"/> 6 <content class="org.objectweb.MyClass"/> 7 <controller desc="primitive"/> 8 </definition> membrane. Of course, for composite components, defining the membrane can be done the same way as presented for primitives(inline component system, separate file). Here, the file describing the membrane is described in Figure 10. It is very similar to the previous description of the membrane (Figure 7), except the fact that the composite additionally has inside its membrane the ContentController.

Going back to Figure 9, the functional content of the composite is described as in the old versions of the adl. Some alternatives to describe the same composite are presented in Figures 11, 12 and 13. In Figure 11, there is a new structure that we introduced. Indeed, just like the inline controller section, we can also define an inline content section. We can notice that on lines 7 and 8, some interfaces are defined. Inside the content section for a composite component, defined interfaces are internal ones. In this particular case, the internal interfaces correspond to the external ones (same name , same signature, same contingency, but inverted role). The role is opposite, to correspond to what we can see on the graphical representation. The adl file presented in Figure 11 shows a particular usage of the content section. It introduces some redundancy inside the same file in the case internal interfaces are corresponding to the external ones. In this case, the definition of the system should be done like in Figure 9. If the set of internal and external interfaces is different, the representation of Figure 11 can be adopted. For small systems, it offers some clarity, as everything is defined inside the same file. However, it it highly recommended to choose the approach described in Figures 12 and13.

In Figure 12, the description follows the separation of roles introduced earlier in Section 2, with content and membrane described in two separate files. <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE .... > <definition name="org.objectweb.primitivecomponent"> <interface name="itf1" role="server" signature="org.objectweb.MyInterface" /> <interface name="itf2" role="client" signature="org.objectweb.

MyClientInterface

Connexions membrane-content and content-membrane

Membrane-content and content-membrane connexions are defined in the content section of a composite. Once again, this is done following the graphical intuition: graphically, the arrows representing connexions between the membrane and the content and vice-versa are inside the For membrane-content connexions, the functional assembler must declare references to internal interfaces of the membrane. Those references are declared the same way as any interface is declared. Inside the functional content Nf interfaces are not allowed, which means that if an Nf interface is declared, then we can be sure that this is a reference to an internal Nf interface(which must itself be declared in the Nf adl).

Figures 15,16, 18 and 19 are extensions of Figures 13 and10. They introduce only additional declarations made to the content and the membrane of the composite in order to connect the functional and non-functional worlds. In Figures 15 and18 representing the content of the composite, we can see the reference to the internal Nf interface of the membrane on line 6 and the binding with this interface on line 8. The name of the interface should be the same as in the Nf adl (where this interface must be declared, like in Figures 16 and19). Notice that inside the content section, we don't have to keep the same role description as the declaration in the Nf adl. Indeed, all the interfaces declared inside the content section(functional interfaces or references to Nf interfaces) are internal ones. Thus, we don't need to mention that the interface is internal. Nevertheless, if the internal role is mentioned, it will be accepted.

Figures 16 and19 represent the additional declarations added to the membrane for connexions between functional and Nf worlds. On line 5, we can the declaration of the internal interfaces. In the membrane file, the internal role must be mentioned, as inside the membrane (contrary to the content section) both external and internal interfaces are declared.

Defining interceptors

The idea is that an interceptor is connected to a functional interface, from which it will seamlessly intercept method calls. When an interceptor intercepts a method call, it can decide what <definition name="org.objectweb.compositecomponent"> <interface name="itf1" role="server" signature="org.objectweb.MyInterface" /> <interface name="itf2" role="client" signature="org.objectweb.

MyClientInterface"/> <component definition="org.objectweb.Foo" name="foo"/> <component definition="org.objectweb.Bar" name="bar"/> <binding client="this.itf1" server="foo.foo"/> <binding client="foo.bar" server="bar.bar"/> <binding client="bar.itf2" server="this.itf2"/> <controller desc="org.objectweb.MyCompositeMembrane"/> </definition> to do with it. The idea with interception is to perform additional processing before delegating the call to the interface it was adressed to. This additional processing can be delegated to NF components located inside the membrane. I think that once processed, the call has to return to the functional world (sent to a functional interface), because originally it was adressed to a functional component. This question still remains as pending. Indeed, we could imagine scenarios where an intercepted call is not sent to the functional component in charge of processing it: according to some policies, a particular functional call is not forwarded to the corresponding functional component. There are two types of interceptors : input and output. Input interceptors intercept incoming calls on a functional interface. Output interceptors intercept calls emitted from a functional interface. The problem of adding interceptors inside the NF adl is that they have to be connected to functional interfaces. But the definition of functional interfaces is not included in the NF adl, as they are defined in the "functional" part of the adl. One solution to solve this problem is to define interceptors outside the Nf adl. We do not want to do this, as we want follow the graphical intuition and keep interceptors inside the membrane. Just like for non-functional in- <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE .... > <definition name="org.objectweb.compositecomponent"> <interface name="itf1" role="server" signature="org.objectweb.MyInterface" /> <interface name="itf2" role="client" signature="org.objectweb.

MyClientInterface"/> <content> <interface name="itf1" role="client" signature="org.objectweb.

MyInterface"/> <interface name="itf2" role="server" signature="org.objectweb.

MyClientInterface"/> <component definition="org.objectweb.Foo" name="foo"/> <component definition="org.objectweb.Bar" name="bar"/> <binding client="this.itf1" server="foo.foo"/> <binding client="foo.bar" server="bar.bar"/> <binding client="bar.itf2" server="this.itf2"/> </content> <controller desc="org.objectweb.MyMembrane"/> </definition>

Primitive component

In Figures and 21 there is respectively the graphical description of a primitive component containing an interceptor inside its membrane and the corresponding adl description. In Figure 21, the membrane is described inside an inline controller system. Between lines 10 and 14, we can find the definition of an interceptor component. It is described in the same way as any component. In fact, I made the choice to make no distinction between a Nf component and an interceptor (one of the first ideas was to "tag" interceptors in such a way that only components tagged as interceptors could connect to functional interfaces). On line 7, we can see the reference to the external functional interface of the component. On line 20, we connect the external interface to the interceptor and on line 21 we connect the interceptor to the internal functional <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE .... > <definition name="org.objectweb.compositecomponent"> <interface name="itf1" role="server" signature="org.objectweb.MyInterface" /> <interface name="itf2" role="client" signature="org.objectweb.

MyClientInterface interface. Notice that for primitive components the internal functional interface is not declared.

For the binding between the interceptor and this interface, the internal interface is referenced by the name of the external one. Indeed, what matters in this case is the orientation of the binding.

As we are binding a client interface of an interceptor to an interface with the name of an external one, we can be sure that we are binding the interceptor component to an internal interface.

Composite component

In Figures 22 and23, we can see the graphical representation of a composite component with an interceptor inside its membrane with the corresponding adl representation. In the adl description, we introduced only the noticeable changes in the Nf adl. the functional content remains the same(as in Figure13). The definition of the interceptor and the bindings between the interceptor and the functional interfaces are the same as in Figure 21. The internal interface is not declared, because we are using the name of the external interface to reference the corresponding internal one. Following the constraints on internal interfaces of composite components introduced in Section 2.4.2, the set of external and internal interfaces can be different. If an external interface has no corresponding internal interface, the internal interface has to be explicitely referenced. MyCompositeContent"> <interface name="itf1" role="client" signature="org.objectweb.MyInterface" /> <interface name="itf2" role="server" signature="org.objectweb.

DTD of the new adl

MyClientInterface"/> <interface name="internal-lifecycle-controller" role="server" signature=" org.objectweb.MyLifecycleController"/> ... <binding client="foo.mylifecycle-controller" server="this.internallifecycle-controller"/> </definition> Figure 15: Bindings between the content and the membrane: the content file <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE .... > <definition name="org.objectweb.MyCompositeMembrane" extends="org.

objectweb.NFType"> <interface name="mylifecycle-controller" role="internal-server" signature= "org.objectweb.MyLifecycleController"/> ... <binding client="this.mylifecycle-controller" server="lifecycleController.

lifecycle"/> </definition> MyCompositeContent"> <interface name="itf1" role="client" signature="org.objectweb.MyInterface" /> <interface name="itf2" role="server" signature="org.objectweb.

MyClientInterface"/> <interface name="internal-binding-controller" role="client" signature="org .objectweb.MyBindingController"/> ... <binding client="this.internal-binding-controller" server="bar.bindingcontroller"/> </definition> <interface name="itf1" role="server" signature="org.objectweb. MyInterface "/> ... <component name="interceptor"> <interface signature="org.objectweb.Interceptor" role="serverinterceptor" name="serverIntercept"/> <interface signature="org.objectweb.Interceptor" role="clientinterceptor" name="clientIntercept"/> <content class="org.objectweb.InterceptorImpl"/> </component> ... <binding client="this.itf1" server="interceptor.server-interceptor"/> <binding client="interceptor.client-interceptor" server="this.itf1"/> </definition> <?add ast="definition" itf="org.objectweb.fractal.adl.Definition" ?> <!--components module --> <?add ast="component" itf="org.objectweb.fractal.adl.components.Component" ?> <?add ast="definition" itf="org.objectweb.fractal.adl.components.ComponentDefinition" ?> <!--interfaces module --> <?add ast="interface" itf="org.objectweb.fractal.adl.interfaces.Interface" ?> <?add ast="definition" itf="org.objectweb.fractal.adl.interfaces.InterfaceContainer" ?> <?add ast="component" itf="org.objectweb.fractal.adl.interfaces.InterfaceContainer" ?> <!--types module --> <?add ast="interface" itf="org.objectweb.fractal.adl.types.TypeInterface" ?> <!--bindings module --> <?add ast="binding" itf="org.objectweb.fractal.adl.bindings.Binding" ?> <?add ast="definition" itf="org.objectweb.fractal.adl.bindings.BindingContainer" ?> <?add ast="component" itf="org.objectweb.fractal.adl.bindings.BindingContainer" ?> <!--attributes module --> <?add ast="attribute" itf="org.objectweb.fractal.adl.attributes.Attribute" ?> <?add ast="attributes" itf="org.objectweb.fractal.adl.attributes.Attributes" ?> <?add ast="definition" itf="org.objectweb.fractal.adl.attributes.AttributesContainer" ?> <?add ast="component" itf="org.objectweb.fractal.adl.attributes.AttributesContainer" ?> <!--content module --> <?add ast="component" itf="org.objectweb.fractal.adl.components.Component" ?> <?add ast="definition" itf="org.objectweb.fractal.adl.components.ComponentDefinition" ?> <!--implementations module --> <?add ast="implementation" itf="org.objectweb.fractal.adl.implementations.Implementation" ?> <?add ast="definition" itf="org.objectweb.fractal.adl.implementations.ImplementationContainer" ?> <?add ast="component" itf="org.objectweb.fractal.adl.implementations.ImplementationContainer" ?> <?add ast="controller" itf="org.objectweb.fractal.adl.implementations.Controller" ?> <?add ast="definition" itf="org.objectweb.fractal.adl.implementations.ControllerContainer" ?> <?add ast="component" itf="org.objectweb.fractal.adl.implementations.ControllerContainer" ?> <!--loggers module --> <?add ast="logger" itf="org.objectweb.fractal.adl.loggers.Logger" ?> <?add ast="definition" itf="org.objectweb.fractal.adl.loggers.LoggerContainer" ?> <?add ast="component" itf="org.objectweb.fractal.adl.loggers.LoggerContainer" ?> <!--nodes module --> <?add ast="virtualNode" itf="org.objectweb.proactive.core.component.adl.nodes.VirtualNode" ?> <?add ast="definition" itf="org.objectweb.fractal.adl.nodes.VirtualNodeContainer" ?> <?add ast="component" itf="org.objectweb.fractal.adl.nodes.VirtualNodeContainer" ?> <!--arguments module --> <?add ast="definition" itf="org.objectweb.fractal.adl.arguments.ArgumentDefinition" ?> <!--coordinates module --> <?add ast="coordinates" itf="org.objectweb.fractal.adl.coordinates.Coordinates" ?> <?add ast="definition" itf="org.objectweb.fractal.adl.coordinates.CoordinatesContainer" ?> <?add ast="component" itf="org.objectweb.fractal.adl.coordinates.CoordinatesContainer" ?> <!--comments module --> <?add ast="comment" itf="org.objectweb.fractal.adl.comments.Comment" ?> <?add ast="definition" itf="org.objectweb.fractal.adl.comments.CommentContainer" ?> <?add ast="component" itf="org.objectweb.fractal.adl.comments.CommentContainer" ?> <?add ast="interface" itf="org.objectweb.fractal.adl.comments.CommentContainer" ?> <?add ast="binding" itf="org.objectweb.fractal.adl.comments.CommentContainer" ?> <?add ast="attributes" itf="org.objectweb.fractal.adl.comments.CommentContainer" ?> <?add ast="attribute" itf="org.objectweb.fractal.adl.comments.CommentContainer" ?> <?add ast="controller" itf="org.objectweb.fractal.adl.comments.CommentContainer" ?> <?add ast="templateController" itf="org.objectweb.fractal.adl.comments.CommentContainer" ?> <?add ast="implementation" itf="org.objectweb.fractal.adl.comments.CommentContainer" ?> ... ... <!--exported virtual nodes module --> <?add ast="exportedVirtualNodes" itf="org.objectweb.proactive.core.component.adl.vnexportation .ExportedVirtualNodes" ?> <?add ast="exportedVirtualNode" itf="org.objectweb.proactive.core.component.adl.vnexportation.

ExportedVirtualNode" ?> <?add ast="composedFrom" itf="org.objectweb.proactive.core.component.adl.vnexportation.

ComposedFrom" ?> <?add ast="composingVirtualNode" itf="org.objectweb.proactive.core.component.adl.vnexportation .ComposingVirtualNode" ?> <?add ast="definition" itf="org.objectweb.proactive.core.component.adl.vnexportation.

ExportedVirtualNodesContainer" ?> <?add ast="component" itf="org.objectweb.proactive.core.component.adl.vnexportation.

ExportedVirtualNodesContainer" ?> <?add ast="exportedVirtualNodes" itf="org.objectweb.proactive.core.component.adl.vnexportation .ExportedVirtualNodeContainer" ?> <?add ast="exportedVirtualNode" itf="org.objectweb.proactive.core.component.adl.vnexportation.

ComposedFromContainer" ?> <?add ast="composedFrom" itf="org.objectweb.proactive.core.component.adl.vnexportation.

ComposingVirtualNodeContainer" ?> <?add ast="implementation" itf="org.objectweb.proactive.core.component.adl.content.Content" ?> <?add ast="implementation" itf="org.objectweb.fractal.adl.interfaces.InterfaceContainer" ?> <?add ast="implementation" itf="org.objectweb.fractal.adl.bindings.BindingContainer" ?> <?add ast="implementation" itf="org.objectweb.fractal.adl.components.ComponentContainer" ?> <?add ast="controller" itf="org.objectweb.fractal.adl.components.ComponentContainer" ?> <?add ast="controller" itf="org.objectweb.fractal.adl.interfaces.InterfaceContainer" ?> <?add ast="controller" itf="org.objectweb.fractal.adl.bindings.BindingContainer" ?> <?map xml="binding.client" ast="binding.from" ?> <?map xml="binding.server" ast="binding.to" ?> <?map xml="content" ast="implementation" ?> <?map xml="content.class" ast="implementation.className" ?> <?map xml="controller.desc" ast="controller.descriptor" ?> <?map xml="virtual-node" ast="virtualNode" ?>

Figure 1 :

 1 Figure 1: Specifying the non-functional type

Figure 2 :

 2 Figure 2: Graphical representation of a simple primitive component 1 <?xml version="1.0" encoding="ISO-8859-1" ?> 2 <!DOCTYPE .... > 3 <definition name="org.objectweb.primitivecomponent"> 4 <interface name="itf1" role="server" signature="org.objectweb.MyServerInterface"/> 5 <interface name="itf2" role="client" signature="org.objectweb.MyClientInterface"/> 6 <content class="org.objectweb.MyClass"/> 7 <controller desc="primitive"/> 8 </definition>

Figure 3 :

 3 Figure 3: ADL description of a simple primitive component

Figure 4 :

 4 Figure 4: Graphical representation of a primitive component with componentized membrane

Figure 5 :

 5 Figure 5: ADL description of a primitive component with componentized membrane: inline NF system

Figure 7 :

 7 Figure 7: Primitive component with componentized membrane: the content of the separate file

Figure 8 :

 8 Figure 8: Graphical representation of a composite component <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE .... >

Figure 9 :

 9 Figure 9: Description of a composite close to the old adl

Figure 10 :

 10 Figure 10: Description of the membrane of the composite component: the separate file including the ContentController

Figure 11 :

 11 Figure 11: Description of a composite with inline content section

FiguresFigure 14 :

 14 Figures 24, 25 and 26 represent the full DTD of the new adl.

Figure 16 :Figure 17 :

 1617 Figure 16: Bindings between the content and the membrane: the membrane file

Figure 18 :

 18 Figure 18: Bindings between the membrane and the content: the content file <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE .... > <definition name="org.objectweb.MyCompositeMembrane" extends="org.objectweb.NFType"> <interface name="internal-binding-controller" role="internal-client" signature="org.objectweb.MyBindingController"/> ... <binding client="bindingController.mybinding" server="this.internalbinding-controller"/> </definition>

Figure 19 :Figure 20 :

 1920 Figure 19: Bindings between the membrane and the content: the membrane file

Figure 21 :Figure 22 :

 2122 Figure 21: Primitive component with membrane and interceptor

Figure 23 :

 23 Figure 23: Composite component with interceptor: the membrane file

Figure 24 :

 24 Figure 24: DTD of the new adl: part 1

<

  !--********************************************************************** --> <!--Mapping from XML names to AST names --> <!--********************************************************************** -->

  <!--********************************************************************** --> <!--XML syntax definition --> <!--********************************************************************** --> <!ELEMENT definition (comment * ,interface * ,exportedVirtualNodes?, component * ,binding * ,content?, attributes?,controller?,logger?,virtual-node?,coordinates * ) > <!ATTLIST definition name CDATA #REQUIRED arguments CDATA #IMPLIED extends CDATA #IMPLIED > <!ELEMENT component (comment * ,interface * ,exportedVirtualNodes?, component * ,binding * ,content?, attributes?,controller?,logger?,virtual-node?,coordinates *

Figure 25 :Figure 26 :

 2526 Figure 25: DTD of the new adl:part 2

  Primitive component with componentized membrane: reference to a separate file describing the membrane 1 <?xml version="1.0" encoding="ISO-8859-1" ?> 2 <!DOCTYPE .... > 3 <definition name="org.objectweb.MyMembrane" extends="org.objectweb.NFType" >

	4	<component definition="org.objectweb.proactive.core.component.
		componentcontroller.local.BindingControllerComponent"
		name="bindingController"/>
	5	<component definition="org.objectweb.proactive.core.component.
		componentcontroller.local.LifecycleControllerComponent"
		name="lifecycleController"/>
	6	<binding client="this.binding-controller" server="
		bindingController.binding"/>
	7	<binding client="this.lifecycle-controller" server="
		lifecycleController.lifecycle"/>
	8	<binding client="lifecycleController.binding" server="
		bindingController.binding"/>
	9 </definition>

INRIA

Figure 6:

RT n°7001


张晓龙 Xiaolong Zhang

Vadim S Nikolayev

Time-averaged approach to the dewetting problem at evaporation

Dewetting of liquid films on solid surfaces in the presence of evaporation is a common phenomenon and has been studied by many researchers. The previous numerical approach has revealed that evaporation accelerates the dewetting speed of the triple contact line and established correlations between the dewetting speed and the surface wettability and superheating. However, such a numerical calculation is time-and resource-consuming. We examine dewetting physics and propose a time-averaged approach based on the multiscale theory. The new approach averages the dewetting process over time and consists of only several algebraic equations, making the problem easier to solve. It can produce time-averaged values of essential quantities, such as the dewetting speed and contact angle as a function of superheating, which agrees with the previous numerical results. This simple approach is valuable for many applications, such as modeling pulsating heat pipes and describing the microlayer dynamics under growing vapor bubbles in nucleate boiling.

Introduction. -Dewetting of liquid films is a common phenomenon, which can be observed on a daily basis and used in numerous industrial applications. We recapitulate the classical dewetting theory. Consider an ideally smooth and homogeneous solid surface initially covered by a liquid film of viscous fluid. Such a film is metastable under partial wetting conditions; once a dry hole is created in the film (the contact line appears), the dry area will grow spontaneously, because capillary forces drive the motion. As the dry hole enlarges, a liquid ridge forms ahead of the expanding contact line by collecting the liquid that previously covered the solid surface. Due to the high viscous friction in the thin film, the liquid in the ridge cannot re-enter back the film. Therefore, the ridge grows at the rate of liquid accumulation during the dry area expansion. This problem can be described in two dimensions, illustrated in fig. 1. Understanding the hydrodynamics of the contact line (CL) that demarcates the boundary between the wetted and dry solid surface parts is fundamental to the dewetting problem.

Until recently, the dewetting studies [1,2] concerned the adiabatic conditions (in the absence of net heat and mass transfer between liquid, solid and ambient gas). The work of [3] investigated dewetting in the presence of phase change over the liquid film (evaporation/condensation). The co-occurrence of the two processes is frequently encountered in studies of heat exchange systems, such as liq- uid film dynamics in pulsating heat pipes [4] and the drying of liquid microlayer beneath vapor bubbles in nucleate boiling [5]. In these cases, the liquid film is surrounded by the pure vapor of the same fluid. The numerical results of [3] indicated that evaporation accelerates the dewetting; the contact line recedes faster when the solid substrate is heated. This Letter is structured as follows. First, we will briefly summarize the problem in [3] because these results will help to understand the multiscale analysis discussed next. Based on it new ("time-averaged") approach will be finally introduced.

2D lubrication problem. -The problem is described in [3] in the 2D cross-section of the liquid ridge shown in fig. 1. It uses the "one-sided" formulation, where the vapor-side hydrodynamic stress and the heat flux into the vapor at the interface are neglected compared to those on the liquid side. Therefore, the vapor pressure p v is assumed to be spatially homogeneous. The solid substrate is highly conductive and thus isothermal. Its temperature T w = T sat + ∆T can differ from the saturation temperature T sat = T sat (p v ), which induces liquid evaporation or condensation for positive or negative ∆T , respectively. We focus on the evaporation case ∆T > 0, the most important for applications.

As the interface slope increases considerably in the presence of evaporation, the conventional lubrication theory, valid for slopes below ∼ 30 • , becomes insufficient. The generalized lubrication theory [6][START_REF] Mathieu | Etudes physiques, expérimentale et numérique[END_REF][START_REF] Janeček | Interfacial Phenom[END_REF] is used to describe the thin film flow and free liquid-vapor interface of local height h(x). The theory uses the parametric interface description in terms of the curvilinear coordinate s that runs along the interface (fig. 2a), with s = 0 at the CL. Therefore, the following geometrical relations hold:

∂h/∂s = sin φ, ∂x/∂s = cos φ, (1a,b)
where φ is the local interface slope. The major convenience of this parametrization is the simplicity of rigorous expression for curvature K,

K = ∂φ ∂s = 1 cos φ ∂ 2 h ∂s 2 .
(

) 2
Consider an interfacial point A (fig. 2a). A straight wedge can be formulated by the tangent line and the solid surface with the opening angle equal to the local interface slope φ. The length of the intercepted arc ζ is expressed as φr, where r is the radius of the straight wedge (fig. 2b) and is related to h through h = r sin φ. Therefore, ζ = hφ/ sin φ.

The generalized lubrication theory approximates the liquid pressure p l at A (fig. 2a) by the pressure created by the flow in the corresponding straight liquid wedge with the opening angle φ, cf. fig. 2b.

The interfacial pressure jump

∆p ≡ p v -p l = σK -J 2 (ρ -1 v -ρ -1 l ), (3)
accounts for the vapor recoil effect, where K can be expressed with eq. ( 2) and J is the local mass flux assumed positive at evaporation. Because the liquid films are thin, heat conduction is the main energy exchange mechanism, which can be taken as stationary due to their low thermal inertia. The liquid temperature is assumed to vary linearly along the arc ζ from T w to T i , as suggested by the rigorous thermal analysis of straight wedges where the heat flow is radial [9]. The heat flux supplied to the vapor-liquid interface is spent to vaporize the liquid. Therefore, the energy balance at the interface reads

J = k(T w -T i )/(ζL), ( 4
)
where L is the latent heat. The interfacial temperature T i is impacted by the Kelvin, vapor recoil, and molecularkinetic effects:

T i = T sat [1+∆p/(Lρ l )+J 2 (ρ -2 v -ρ -2 l )/(2L)]+R i JL, (5) where
R i = T sat √ 2πR v T sat (ρ l -ρ v ) 2L 2 ρ l ρ v . ( 6
)
is the kinetic interfacial thermal resistance. Here R v is the specific gas constant.

The governing equation

∂h ∂t cos φ A + ∂ ∂s 1 µG(φ) ζ 2 (ζ + 2l s ) ∂σ ∂s B1 + ζ 2 3 (ζ + 3l s ) ∂∆p ∂s B2 -U cl ζ F (φ) G(φ) C = - J ρ l D , (7)
is written in the frame of reference of the moving CL, which is receding at speed U cl . Here, µ and σ are the liquid viscosity and surface tension, respectively; l s is the hydrodynamic slip length. Several other effects counterbalance the capillarity (term B2). Since the interface temperature T i is not constant, cf. eq. ( 5), the flow due to variation of surface tension is accounted for by the term B1, ∂σ/∂s ≃ -γ∂T i /∂s,

where γ = -∂σ/∂T is generally positive. The term C reflects the flow induced by the CL motion. The functions [6,[START_REF] Mathieu | Etudes physiques, expérimentale et numérique[END_REF]]

F (φ) = 2φ 2 3 sin φ φ -sin φ cos φ , (9)
and

G(φ) = φ 3 3 4 sin φ cos φ -φ cos 2φ , (10)
are the correction factors. With F (φ → 0) = 1 and G(φ → 0) = 1, this formulation reduces to the conventional lubrication theory. The flow induced by the phase change corresponds to the term D. Finally, the term A describes the temporal ridge growth.

The governing equation ( 7) can be solved for s ∈ [0, s f ], with a point s f far from the ridge, where the interface is flat of thickness h ∞ . At (s f , h ∞ ), the boundary condition is zero spatial derivatives φ = 0. Due to evaporation, h ∞ decreases with time,

h ∞ = h 0 1 -t/t d , (11)
where h 0 is the initial (t = 0) film thickness and

t d = Lρ l h 2 0 /(2k∆T ) (12)
is the time of complete film drying. At CL (s = 0), the geometry implies

h = 0, ( 13
)
∂h/∂s = sin θ micro ,

where θ micro is the microscopic contact angle controlling the wetting conditions. The set of lubrication equations (3, 7) is of fourth order; one more boundary condition is needed. It expresses the solution regularity at CL [10], in particular, the pressure finiteness:

∂∆p/∂s| s→0 = 0. ( 15
)
This form is convenient [11] to provide good numerical stability. Another equation determines the CL speed U cl (which is a part of the problem). The relation between U cl and the evaporation flux at CL [3]

J(s → 0) = U cl F (θ micro ) G(θ micro ) θ micro ρ l + l s Lθ micro µk γ . (16)
A numerical result is illustrated in fig. 3, which includes the interface profiles at selected time moments (in the CL frame reference) fig. 3a, and the corresponding U cl dependence of time (expressed with the capillary number Ca = µU cl /σ), fig. 3b.

Numerically solving eq. ( 7) is a delicate issue because it is a non-linear and non-stationary partial differential equation. Producing the results in fig. 3 took dozens of hours of calculation time on a regular PC.

Multiscale analysis. -Our new approach is based on the multiscale analysis of dewetting problem. To explain it, we plot in fig. 4 the interface slope φ(x) at t = 0.5t d obtained from the numerical result (fig. 3). Three regions can be identified [12,[START_REF] Nikolayev | Evaporation effect on the contact angle and con in The Surface Wettability Effect on Phase Change[END_REF]. In the microregion (the distance from the CL x 100 nm), phase change dominates the flow that is described by the balance of the terms B1, B2 and D of eq. ( 7). The CL motion term (C) and slow ridge growth (A) can both be neglected [12]. The microregion problem is thus steady, and the corresponding curve is identified for this reason as Ca = 0 in fig. 4. The microregion problem has been investigated by many researchers (see [START_REF] Nikolayev | Evaporation effect on the contact angle and con in The Surface Wettability Effect on Phase Change[END_REF] for a review). To solve the microregion problem, one applies the zero-pressure jump condition far from CL, ∆p| s→∞ = 0.

The other three boundary conditions are [START_REF] Nikolayev | Evaporation effect on the contact angle and con in The Surface Wettability Effect on Phase Change[END_REF][START_REF] Janeček | [END_REF][START_REF] Zhang | Liquid film model for pulsating heat pipes in proc[END_REF]. At x → ∞, φ saturates to the value θ V that is called hereafter the Voinov angle; in the case of fig. 4, θ V ≃ 33.3 • ; θ V (∆T = 0) = θ micro . A particularity of the problem statement [START_REF] Janeček | [END_REF] presented here is its applicability to the partial wetting case. Note that the solution results in θ V as a function of the local superheating (that at CL, cf. fig. 5) and wetting properties. Note that θ V = θ micro at ∆T = 0. Above the microregion, there is an "intermediate" region, within which the CL motion governs fluid flows (fig. 4). The nanoscale effects: the hydrodynamic slip, vapor recoil, and Marangoni effects are nonessential here [12]. The interface is thus controlled by the balance of the terms C and B2 (with l s → 0) in eq. [START_REF] Mathieu | Etudes physiques, expérimentale et numérique[END_REF]. It is the classical dynamic CL problem studied by Voinov and Cox, and has an asymptotic solution

φ 3 = θ 3 V -9Ca ln(x/ℓ V ), (18)
where the Voinov length ℓ V can be found by fitting eq. ( 18) (blue dashed curve in fig. 4) to the full numerical solution [12]. In the case of fig. 4, ℓ V ≃ 13 nm. θ V appears in the intermediate region solution as an integration constant defined from the condition φ(Ca → 0) = θ V . Finally, at the macroscopic (millimetric) scale, the ridge growth is described by the balance of the terms A and B2 in eq. ( 7). Its profile is defined by the capillary forces only and can thus be fitted by a circular arc (violet dotted curve in fig. 4). The limit x → 0 of this latter solution results in the apparent contact angle θ app , which is an apparent slope at the CL seen from the macroscopic viewpoint: θ app ≃ 17 • in this case.

A multiscale approach has been applied [2] to solve the conventional adiabatic dewetting case ∆T = 0 (where θ V ≡ θ micro as mentioned above) by analytical asymptotic methods. They resulted in two expressions giving θ app and Ca,

θ 3 app = θ 3 V -9Ca ln[2w/(eℓ V )], Ca = θ 3 V 9 ln 4a e 2 Ca 1/3 w 2 ℓ V h ∞ -1 , (19)
where a ≃ 1.094, e = 2.71 . . . is the Euler number, and w is the ridge half-width (fig. 1). The second asymptotic expression is obtained in the limit of large times, where the ridge growth is slow so the ridge is quasi-steady.

Time-averaged model. -During the ridge growth, all the quantities, Ca, w and h ∞ (considering phase change), are not constant. Ca slowly decreases with time, cf. fig. 3b; w grows as the ridge collecting more liquid, and h ∞ decreases because of evaporation, cf. eq. ( 11). The variation in ℓ V turns out to be small during the film evaporation [3].

In applications (e.g. in pulsating heat pipe modeling), the focus is primarily on Ca and θ app , which experience slow variations during the dewetting process. Therefore their time-averaged values are sufficient. We perform the averaging of the lubrication 2D approach [3] over a time interval ∆t = t 2 -t 1 with t 1 = 0.1t d and t 2 = 0.6t d ; the time-averaged quantities are denoted hereafter by the angle brackets. Such a time interval is reasonably large, as it corresponds to a half of the thin film lifetime t d . Fig. plots the Ca data from the lubrication approach as characters with bars for three fluids and several θ micro values. The upper and lower limits of the bars correspond to the Ca values at t 1 and t 2 , respectively. The bars are relatively short with respect to the absolute values of Ca, indicating that the averaging is reasonable. Noticeably, these numerical data demonstrate that the dewetting accelerates with superheating, i.e. with the evaporation rate. As shown in fig. 7, θ app also grows with superheating.

The characters in figs. 6, 7 result from the full numerical solution of eq. [START_REF] Mathieu | Etudes physiques, expérimentale et numérique[END_REF]. However, such a solution is time-and resource-consuming because of several reasons: (i) necessity to resolve a big range of the length scales; (ii) numerical iteration at each time moment to manage the nonlinear terms (iii) solving of a transient ridge evolution. A simpler approach is thus desirable.

The adiabatic asymptotic expressions (19) can be generalized [3] to the case ∆T = 0 thanks to the scale separation between the three asymptotic regions discussed above. We propose here the time averaging of the above expressions. When this process is slow with respect to the dewetting dynamics, the evolution is quasi-static, and eqs. (19) should hold for the time-averaged quantities:

θ app 3 = θ 3 V -9 Ca ln 2 w eℓ V , Ca = θ 3 V 9 ln 4a e 2 Ca 1/3 w 2 ℓ V h ∞ -1 . (20)
Consider now all the parameters in these expressions. For given θ micro , θ V can be calculated from the microregion model (fig. 5). As shown in [3], ℓ V can be approximated by the formula

ℓ V ≃ 3l s /(eθ V ). ( 21
)
This expression is inspired by the adiabatic result [2] and signifies that ℓ V is largely controlled by the hydrodynamic slip. Two remaining parameters, w and h ∞ are yet to be defined. During the film evaporation, h ∞ decreases, which affects the dynamics. The value of h ∞ can be computed with eq. ( 11),

h ∞ = 1 ∆t t2 t1 h 0 1 - t t d dt = βh 0 , (22)
where the time averaging is performed over ∆t = t 2 -t 1 ; for the same time interval ∆t = 0.5t d as in fig. 6, β ≃ 0.8. Following the theory simplified in the spirit of [1], we can calculate w . Recall the dewetting physics; as the contact line recedes, the liquid previously covering the solid surface accumulates in the ridge (fig. 1). Because of capillary action, the interface profile of the dewetting ridge is approximated by a circular arc of radius R, and the center of the circle is marked as point O. The arc intersects the solid surface at point A of apparent contact angle θ app and the liquid film surface with an angle ϕ. Point B on the substrate is under the ridge peak. The radius R satisfies

R sin θ = w, (23)
where w = AB. The angles θ app and ϕ satisfy the geometrical relation OC -OB = CB, resulting in

R(cos ϕ -cos θ app ) = h ∞ . ( 24
)
The substitution of ( 23) into (24) and averaging leads to cos ϕ = cos θ app + 1 w sin θ app ,

where w = w /h ∞ . The volume of liquid (per unit CL length)

S = t2 t1 h ∞ (t)U cl (t)dt (26)
collected from A ′ to A (during the time ∆t) is approximately equal to the excessive ridge area

S = R 2 (ϕ -sin ϕ cos ϕ), (27)
colored in light blue in fig. 1. Since the evolution is slow, one can replace eq. ( 26) with S ≃ U cl h ∞ ∆t. By combining eqs. (23, 25, 26) and averaged eq. ( 27), we arrive at

sin 2 θ app ∆ t = N w2 ( ϕ -sin ϕ cos ϕ ), (28)
where ∆ t = ∆t/t d and the dimensionless parameter

N = h ∞ /(t d U cl ) (29)
is a ratio of drying and CL receding speeds. The N smallness is a necessary condition for validity of the quasisteady approximation and then of the whole model. Another quasi-steadiness criterion is a smallness of the viscous relaxation time with respect to t , i.e. of M = µ h ∞ /(σt d ) ≡ N Ca . However, as Ca ≪ 1, this criterion always holds if N ≪ 1 holds. The set of algebraic equations (20, 21, 25, 28) is complete provided that θ V is known for the working fluid and for given θ micro and ∆T (fig. 5). We can now compute four quantities ϕ , w, θ app and Ca , the latter two being the most significant. Note that their dependence on a particular choice of ∆t is extremely weak.

The ∆T variations of θ app and Ca produced by the time-averaged method (lines) are compared to the numerical solution of eq. ( 7) in figs. 6 and 7 for several contact angles and three different fluids commonly used in heat transfer applications. A good agreement between the lubrication solution and the time-averaged theory is achieved. It is explained by N ∼ 10 -3 in all the cases considered here. Note that N given by eq. ( 29) remains bounded at increasing ∆T due to θ app growth with ∆T slightly faster than linear (figs. 6) thus compensating the t d decrease, cf. eq. ( 12). While remaining small, M grows with ∆T nearly linearly, which probably explains a small but growing discrepancy between the lines and the characters in figs. 6 and7.

While figs. 6 and 7 may look similar to figs. 6 and 7 of [3], they are not the same at all. Certainly, the characters representing the numerical data, which gives a reference for comparison, are the same in both cases. However, the lines are different. To obtain the lines in [3], one averaged the time-dependent results for w, h ∞ , and ℓ V of numerical simulations; by using these values, Ca was calculated with eqs. (19). In contrast, the lines in the present Letter are produced directly by solving equations (20, 21, 25, 28), which are independent of the non-stationary lubrication simulation. Only the microregion solution is needed for them. Such an approach requires only seconds of computation time instead of weeks to obtain the results in [3].

Conclusions. -The dewetting phenomenon in the presence of evaporation can be described in two dimensions with the generalized lubrication approach. Its numerical solution has shown that the dewetting speed increases with the substrate superheating, indicating that evaporation accelerates the dewetting. However, this numerical approach requires solving a non-linear and nonstationary partial differential equation, which is time and resource-consuming. To obviate heavy numerical calculations, we propose a time-averaged approach, which is based on the multiscale theory and consists of several algebraic equations. The new approach employs an integration quantity as input data, the Voinov angle, which can be obtained by solving the stationary microregion problem. This value is much easier to calculate and is familiar to many researchers. We compared the time-averaged model to the full numerical solution for different wettability and three different fluids. Thanks to the slowness of the film evaporation (with respect to dewetting), the results of this simple model are in good agreement with the numerical results. This approach is original and valuable for multiple applications involving liquid film evaporation, for instance, in the modeling of heat transfer systems such as pulsating heat pipes [START_REF] Zhang | Liquid film model for pulsating heat pipes in proc[END_REF], and bubble growth in boiling [START_REF] Tecchio | Microlayer dynamics at bubble growth in boiling in proc[END_REF].

Fig. 1 :

 1 Fig. 1: Dewetting of a liquid film: the ridge collects liquid as the contact line (CL) recedes.

Fig. 2 :

 2 Fig. 2: Sketches of the curved interface (a) and the straight liquid wedge (b) corresponding to the point A.

  micro =5°( b) The CL receding deceleration.

Fig. 3 :Fig. 4 :Fig. 5 :

 345 Fig. 3: Numerical results showing the evolution of dewetting ridge for ethanol at pv = 23.2 kPa; ∆T = 10K, θmicro = 5 • , ls = 10 nm, and h0 = 50 µm. macro

6

 6

Fig. 6 :

 6 Fig. 6: Comparison of numerical (characters with bars) and time-averaged model (lines) results of Ca(∆T ) for several θmicro and different fluids.

Fig. 7 :

 7 Fig. 7: Comparison of numerical (characters) and timeaveraged model (lines) results of θapp (∆T ) for several θmicro and different fluids.

Acknowledgments. -The present work is supported by the project TOPDESS, financed through the Microgravity Application Program by the European Space Agency. This article is also a part of the PhD thesis of X. Zhang, co-financed by the CNES and the CEA NUMERICS program, which has received funding from the European Union's Horizon 2020 research and innovation program under grant agreement No 800945 NUMERICS H2020-MSCA-COFUND-2017. Additional financial support of CNES awarded through GdR MFA is acknowledged.