Dr Marta Martínez-Alonso

Dr Albert Gandioso

Chloé Thibaudeau

Xue Qin

Philippe Arnoux

Nurikamal Demeubayeva

Céline Vincent Guérineau

# Chloé Thibaudeau

Dr Céline Frochot

Dr Alain C Jung
email: a.jung@icans.eu

Dr Christian Gaiddon
email: gaiddon@unistra.fr

Dr Prof Gilles Gasser
email: gilles.gasser@chimeparistech.psl.eu

A Novel Near-IR Absorbing Ruthenium(II) Complex as Photosensitizer for Photodynamic Therapy and its Cetuximab Bioconjugates

niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Currently approved anticancer metal-based drugs are mainly based on platinum.

However, these complexes usually lack selectivity and cause harmful side effects. In order to tackle these drawbacks, other therapeutic modalities, as well as other types of transition metal complexes, have been investigated. Photodynamic Therapy (PDT) is an approved medical technique based on the combined action of a photosensitizer (PS), molecular oxygen, and light. The PS is biologically harmless in the dark but becomes active upon light irradiation thanks, among others, to the formation of singlet oxygen ( 1 O2), a strong oxidizing agent able to cause cell death. [1] Recently, a Ru(II) polypyridyl complex from the McFarland group (TLD-1433) [2,3] has entered into phase II clinical trials as a new PS for the treatment of a certain form of bladder cancer. [START_REF] Inc | TLD-1433 Clinical Trial[END_REF] Conti and coworkers have recently reviewed the Ru(II) polypyridyl complexes as PS for PDT. [START_REF] Conti | [END_REF] One of the aims of a PDT PS is to absorb light in the red or NIR region of the spectrum (> 600 nm), so that complexes can be irradiated with low energy (i.e., better tissue penetration [6] to treat deep-seated or large tumours and less harmful light than UV). In order to prepare PSs that absorb in the red or NIR, we decided to use a strategy based on the cyclometalation of ruthenium(II) polypyridyl complexes. Cyclometalation lowers the energy of the triplet metal-to-ligand charge transfer state ( 3 MLCT) and shortens the excited state lifetime of these complexes. [7] Furthermore, the anionic character of the ligand causes a bathochromic shift of the MLCT absorption band of Ru(II) cyclometalated complex. [8] Worthy of note, Chao and co-workers reported drastic improvements in cytotoxicity for Ru(II) complexes bearing C^N ligands with regards to those bearing N^N. [9,10] However, there are few examples of cyclometalated complexes as PDT PSs. Ruiz and co-workers have recently reported some green-absorber Ru(II) complexes active in hypoxic conditions with high phototoxicity indexes (PI > 580). [11] Huang and co-workers prepared a coumarin-modified cyclometalated Ru(II -complex photoactive on both hypoxic and normoxic conditions. [12] Dunbar and co-workers reported a cyclometalated Ru(II) compound with photoactivity at λ = 633 nm (PI = 7). [13] In all the cases, the absorption is red-shifted with regards to the bipyridyl counterpart.

One of the strategies to improve selectivity in tumoral tissues is bioconjugation. [START_REF] Hermanson | Bioconjugate Techniques[END_REF][START_REF] Gunnoo | [END_REF] Nucleotides, peptides, lipids, carbohydrates, and vitamins have been widely used in combination with ruthenium polypyridyl complexes to reach better internalization and selectivity. [16] Nonetheless, scarce examples of antibody-drug conjugates (ADC) with ruthenium have been reported. Our group previously reported a Ru-nanobody conjugate for targeted PDT. [17] Cetuximab (CTX) is a human-mouse chimeric monoclonal antibody (mAb) that targets the epidermal growth factor receptor (EGFR), overexpressed in some tumours. CTX was approved to treat RAS wild-type metastatic colorectal cancer (mCRC) and head and neck squamous cell carcinoma (HNSCC). Maleimide and benzoyl acrylic acid were selected as the functional groups for the CTX-bioconjugation. Maleimide is the representative moiety commonly used for cysteine conjugation. However, the maleimide strategy has some limitations. On the one hand, an acidic pH is recommendable to avoid side reactions. On the other hand, once attached to the cysteine, the conjugate can undergo a rapid retro-Michael addition with another thiol-containing biomolecule (e.g., glutathione), leading to the release of the antibody and the formation of a thioether maleimide. [18,19] Bernardes and co-workers recently reported the use of carbonyl acrylates as efficient and irreversible scaffolds for cysteine conjugation. [20] Therefore, we decided to select both types of functionalization for comparison.

In this work, we report on the synthesis and characterisation of a novel phenylpyridinebased cyclometalated Ru(II) complex with a terminal amino group, and its corresponding maleimide and benzoylacrylic derivatives, as well as their CTX conjugates. All the complexes have been tested as NIR-PSs for PDT with CT-26 cell line and human SQ20B HNSCC cell line.

Results and discussion

Synthesis and characterization.

The ligands L2-L5 were prepared as displayed in Scheme 1. The synthesis is described in the experimental part and the characterization data are displayed in the SI for both the ligands (Fig. S1-S11) and the complexes (Fig. S12-S29). Direct reaction of the aminopyridine moiety with a carboxylic acid was unsuccessful, as aromatic amines are known to be weak nucleophiles. [21] Therefore, a linker was introduced to separate spatially the cyclometalating ligand and the targeting functional group (i.e., maleimido or benzoyl acrylate). We substituted the amine group of L1 for a bromine through the Sandmeyer reaction (L2), [22] followed by the reaction of the aryl bromide with ethylene diamine under reflux (L3). [23] This alkyl amine is much more reactive and easier to functionalize. Finally, we coupled the benzoyl acrylic acid and the maleimide NHS ester to the amino-terminal group to yield the corresponding amides (L4 and L5).

The complexes (Ru-NH2, Ru-Br, Ru-BAA, and Ru-Mal) were prepared through the reaction of the corresponding 2-phenylpyridine ligand and [Ru(bphen)2Cl2], along with a silver salt (AgPF6) and a base (NMe4OH) in a CH2Cl2/MeOH (5:1 v/v) mixture at 60 °C for 24 h, as shown in Scheme 2. [24] All the Ru(II) complexes were isolated as the PF6 ‾ salts, purified by column chromatography and characterized by 1 H, 19 F, and 13 C NMR, and ESI-MS. The purity was assessed by HPLC and by elemental analysis.

Photophysical properties.

The absorption UV-vis spectra of the complexes were recorded in acetonitrile and are shown in Fig. 1. The complexes show similar patterns and present bands between 250 and 350 nm with absolute maxima at 277-278 nm, corresponding to the spin-allowed ππ* transitions. The shoulder around 320 nm is assigned to 1 MLCT and 1 LLCT. The broad band appearing over 450 nm is ascribed to the 3 MLCT transitions, bathochromic shifted due to cyclometalation. Relative maxima were found around 500 and 580 nm, except for Ru-Br, whose maxima are blue-shifted when compared with the amino-derivatives. This observation implies that bromine, as an example of EWG, in para to the coordinating N atom blue-shifts the absorption, whereas the amine, as EDG, has the opposite effect. It is important to highlight that all the complexes exhibit absorption at 700 nm, with molar absorptivities shown in Table 1. Furthermore, Ru-Mal and Ru-BAA functionalized complexes display absorption up to 725 nm with ε > 1000 M -1 cm -1 . The emission spectra of the complexes were recorded in degassed acetonitrile. As expected, and already reported, cyclometalation causes a rapid decay of the excited states. [9] Thus, the cyclometalated complexes exhibited weak emission (see Fig. 2), with bands centred in the NIR region (764-799 nm). Ru-Br was the most emissive complex, 5 times more intense than Ru-NH2, and 14 times more than Ru-BAA and Ru-Mal (Fig. S30). All the absorption and emission data are gathered in Table 1. 1 O2 is the main toxic species for a PS working through the type II mechanism. The emission spectrum of Ru-NH2 was recorded again after leaving the cuvette open to air for 2 h. The emission intensity decreased 1.5 times as a consequence of oxygen quenching (Fig. S31). Therefore, the production of 1 O2 upon irradiation of the PSs was quantitatively evaluated in acetonitrile using the direct method of detecting the phosphorescence of 1 O2.

The quantification of the characteristic luminescence produced by the relaxation of 1 O2

(λem= 1275 nm) was monitored as a function of the irradiation time (λexc = 450 nm). The 1 O2 quantum yield was calculated using [Ru(bpy)3]Cl2 as a control in acetonitrile. The Ru-NH2 1 O2 quantum yield (Fig. S32) was 19 % and 77 % for the control. The low yield obtained with the novel ruthenium complex could be explained by the presence of the amine group, which is able to quench the 1 O2 generation, as previously reported [25] . One of the explanations for the quenching mechanism is due to a charge transfer between the ground state of a nitrogen-containing compound and 1 O2. All in all, we cannot discard the possibility of the PS to undergo type I mechanism.

Phototoxicity Studies of Ru-NH2 on 2D Monolayer Cells

The first step toward the biological investigation of the Ru-NH2 complex was the evaluation of its photocytotoxicity in monolayer cultures of CT-26 (mouse colon adenocarcinoma) cell line using a fluorometric resazurin cell viability assay. Protoporphyrin IX (PpIX), clinically approved for PDT, was tested in the same cell line as a positive control. To study its efficiency as a PDT PS, the cytotoxicity of both the complex and the control was tested in the dark and upon irradiation at 670 nm (60 min, 3.75 mW cm -2 , 13.5 J cm -2 ) based on the absorption spectra (Fig. 3 and Fig. S33).

Importantly, the Ru(II) complex was found to be nontoxic in the dark (IC50, dark > 100 μM). This is an important requirement for a PDT agent. As desired, it was found to be phototoxic in the lower-micromolar range (IC50, 670 nm = 0.27 ± 0.02 μM). Furthermore, the non-dark cytotoxicity of the ruthenium complex led to excellent phototoxicity indexes (PI) of > 370. PI is defined as the ratio between dark toxicity and phototoxicity. Based on this promising result, we investigated its photocytotoxicity upon irradiation at 740 nm (60 min, 3.50 mW cm -2 , 12.6 J cm -2 ) and 770 nm (60 min, 6.75 mW cm -2 , 24.3 J cm -2 ).

Interestingly, Ru-NH2 was found to be cytotoxic after irradiation with near-infrared light in the micromolar range (IC50, 740 nm = 0.64 ± 0.03 μM, PI = > 156; IC50, 770 nm = 23.7

± 4.6 μM, PI = > 4). Importantly, we could demonstrate that complex Ru-NH2 exhibits a phototoxic effect up to 740 nm (see Table S1). To the best of our knowledge, this is one of the first examples of a Ru(II)-NIR PS, highly phototoxic, without using upconverting nanoparticles [26,27] , two-photon absorption [28,29] or conjugating it with red-absorbing fluorophores such as BODIPYs [30] or porphyrins [31] . Only scarce examples of Ru(II)-NIR PSs have been reported with low-to-moderate PIs at such wavelengths. [2,32,33] In light of these promising results, the phototoxicity of the targeting ability of two novel cetuximabconjugates was evaluated in more detail.

Ru-CTX bioconjugates

The promising results obtained for the Ru-NH2 complex prompted us to prepare Antibody-Drug Conjugates (ADCs), using cetuximab (CTX) as the antibody, and applying two different conjugation strategies. We used the well-known and classic maleimido functionalization and a benzoylacrylate as a non-typical, promising conjugation method. Both moieties undergo rapid Michael addition, but the benzoylacrylic derivative is more stable. [20] Nonetheless, CTX has no cysteine moiety available for conjugation. Therefore, in a first step, CTX was combined in PBS (pH = 8.0) with the Traut's reagent (2-iminothiolane, a thiolating agent of primary amines) to thiolate the amino groups from accessible lysins. [34] DTNB (5,5′-dithiobis(2-nitrobenzoic acid) and BCA (bicinchoninic acid) assays were performed to determine the number of thiol groups and the concentration of antibody, respectively (see Table S2, Fig. S34 2 and Fig. 4). These are, to the best of our knowledge, the first CTX-Ru bioconjugates described in literature.

Phototoxicity Studies of CTX-Ru bioconjugates on human 2D Monolayer HNSCC

Cells

CTX is the only FDA-approved targeted therapy used for the management of recurrent/metastatic locally advanced head and neck squamous cell carcinoma (HNSCC). [35,36] In order to evaluate the efficiency of red-light-based PDT using the Ru-NH2 complex as well as the Ru-Mal-CTX and Ru-BAA-CTX bioconjugates as PSs, we chose the human SQ20B HNSCC cell line as a model. Interestingly, SQ20B cells have been described to be resistant to conventional therapy, like radiotherapy, [37] and to EGFR blockade with CTX. [38] We first wanted to measure the phototoxicity of the Ru-NH2 complex to SQ20B independently of its functionalization to CTX. To this end, SQ20B cells were grown with increasing concentrations of the Ru-NH2 complex, both in the dark and upon red light irradiation, and cell viability was assessed 48 h after treatment using a MTT assay. The Ru-NH2 complex was not found to be toxic in the dark (IC50 dark > 50 µM; Fig. 5A). However, it was phototoxic in the lower-micromolar range upon illumination (IC50 = 0.99 ± 0.31 µM; PI > 50; Fig. 5A and Table S1). These results show that NIR-PDT using the Ru-NH2 complex as a PS displays interesting phototoxicity toward human HNSCC cells. Ru(II)-based PSs were previously shown to be effective on three different human HNSCC cell lines. [39] However, the complexes were irradiated by visible light (525 nm -green light). To the best of our knowledge, our work is the first study that shows the efficacy of a Ru(II)-based PS in the human HNSCC model.

To further assess the gain in specificity brought by the Ru-Mal-CTX and Ru-BAA-CTX bioconjugates, we downregulated the expression of EGFR in SQ20B by transfecting cells with a specific siRNA (siEGFR). A western blot analysis of the expression of EGFR in whole protein extracts from transfected cells showed that the siEGFR efficiently reduced the expression of EGFR in SQ20B cells as compared to cells transfected with non-specific siRNA used as a negative control (siCTRL; Fig. S36A). In order to have a more resolutive idea of siRNA-mediated EGFR downregulation at the individual cell level, the expression of EGFR was also assessed with an immunohistochemistry approach: consistently with the results from the western blot analysis, we observed that the expression of EGFR was downregulated in about 90 % of the cells (Fig. S36B). We then analysed the phototoxicity of the Ru-Mal-CTX and Ru-BAA-CTX bioconjugates on siRNA-transfected SQ20B cells using a cell viability MTT assay. Disappointingly, red-light-based PDT using both bioconjugates only induced a mild reduction of cell viability of SQ20B cells, which was not found to be statistically significant (Fig. 5B). Downregulation of EGFR expression poorly impaired the efficacy of the treatment, and the observed trend was not found to be statistically significant. One possibility to explain this disappointing result could be due to the fact the EGFR expression is still observed in 10 % of the siRNA-transfected cells.

Yet, the percentage alone is unlikely to be the only reason to explain the absence of specificity in the treatment. Another explanation could be related to the receptor. The EGFR is found on the cell membrane and therefore the CTX will anchor the receptor without internalizing the cell. Thus, the Ru(II) unit attached to CTX is not able to cross the cell membrane unless it is able to break off from CTX. Therefore, to overcome this problem, we may design the conjugates with longer linker chains, or labile bonds.

Conclusions

In summary, we have reported a Ru(II) PS for PDT, Ru-NH2, with excellent phototoxic performance in the near infrared region. To the best of our knowledge, this is one of the first examples of Ru(II) polypyridyl complex that operate in the near infrared range. One of the key factors in the successful design of this PS has been cyclometalation. The introduction of a cyclometalated ligand in the complex bathochromic shifts the absorption, reaching the infrared region of the spectrum, a fundamental requirement for a good PS for treatment of deep-seated or large tumours. Despite the low generation of 1 O2, Ru-NH2 is able to cause cell death after light irradiation at 740 nm, whereas is nontoxic in the dark (PI > 156). We have also reported two novel Ru(II)-containing bioconjugates with cetuximab, a monoclonal antibody that targets the EGFR, overexpressed in some tumours. The bioconjugation was selected to gain selectively and efficiently target the tumoral tissue. Two different strategies were used to prepare the ADC, the classic maleimide and the recent and innovative benzoylacrylate. However, only a mild effect in the PDT activity of the conjugates was observed without a significant difference between them. In spite of these results, this is the first example of a Ru-CTX conjugate. As future prospects, an improvement in the bioconjugates design is required and could be achieved by extending the length of the linker. Finally, it is important to highlight the relevance of the outstanding phototoxicity of the nude complex. This high PI exclusively comes from the PS without using techniques or strategies other than cyclometalation.

Experimental section

Materials

All the chemicals were purchased from commercial suppliers and were used without further purification. Solvents were dried on a solvent distillation system (SDS). TOF experiments. Mass spectra were obtained in linear positive ion mode. The laser intensity was set just above the ion generation threshold to obtain peaks with the highest possible signal-to-noise (S/N) ratio without significant peak broadening. All data were processed using the FlexAnalysis software package (Bruker Daltonics). Sinapic acid (SA) was used as the matrix. UV-vis absorbance spectra were recorded in a quartz cuvette using a Cary 4000 UV-vis spectrometer (Agilent). Emission spectra were recorded in a FLS980 Edinburgh Instrument. 1 O2 luminescence was measured with an infrared detector InGaAs (800 -1550 nm) via the dual network emission monochromator SPEX (600 lines / mm blazed at 1 μm) and a long-wave pass (780 nm). The singlet oxygen quantum yield was determined by the equation ( 1):

Deuterated solvents

𝛷𝛷 𝛥𝛥 = 𝛷𝛷 𝛥𝛥0 • 𝐼𝐼 𝐼𝐼 0 • 𝐷𝐷𝐷𝐷 0 𝐷𝐷𝐷𝐷 ( 1
)
where ΦΔ and ΦΔo, I and Io, DO and DOo are the singlet oxygen quantum yield, the singlet oxygen luminescence intensities and the optical densities respectively of the sample and of the standard. The standard used for the singlet oxygen quantum yield was Ru(bpy)3 in acetonitrile with a ΦΔo of 0,77 [40] . HPLC analysis was performed using two Agilent Chromatograms were detected at 215 nm. The solvents (HPLC grade) were Millipore water (0.1 % TFA, solvent A) and acetonitrile (0.1 % TFA, solvent B). The sample was dissolved in 1:1 (v/v) ACN/H2O 0.1% TFA solution and filtered through a 0.2 mm membrane filter. ), 3.27 (q, J = 5.7 Hz, 2H), 3.00 (t, J = 5.9 Hz, 2H) ppm.

Synthesis and characterization

4-bromo-2-phenylpyridine (L2

(E)-4-oxo-4-phenyl-N-(2-((2-phenyl-4-pyridinyl)amino)ethyl)-2-butenamide (L4).

Benzoyl acrylic acid (753 mg, 4. Hz, 1H), 5.34 (s, 1H), 3.57 (q, J = 5.8 Hz, 2H), 3.34 (q, J = 5.1 Hz, 2H) ppm. 13

3-(2,5-dioxo-2,5-dihydro-1H-pyrrol-1-yl)-N-(2-((2-phenyl-4-pyridinyl)amino)ethyl)

propenamide (L5). N 1 -(2-phenyl-4-pyridinyl)-1,2-ethanediamine (555 mg, 2.6 mmol) was dissolved in dichloromethane (degassed, 20 mL) and TEA (0.4 mL, 2.9 mmol) was added. Separately, 3-(Maleimido)propionic acid N-hydroxysuccinimide ester (630 mg, 2.4 mmol) was dissolved in dichloromethane (degassed, 20 mL) and when completely dissolved, the solution was transferred to the previous one. The reaction was tracked by TLC in DCM/MeOH/NH3 (80:10:1) until completion after 3.5 h. The solvent was evaporated to dryness and the residue redissolved in dichloromethane and washed with water (x1) and brine (x2). After drying the organic phase with sodium sulphate and filtering, the solvent was evaporated to dryness. Yield: 60 % (528 mg, 1.45 mmol). (t, J = 6.7 Hz, 2H), 3.54 (q, J = 5.9 Hz, 2H), 3.33 (q, J = 5.3 Hz, 2H), 2.56 (t, J = 6.8 Hz, 2H) ppm. 13

[Ru(bphen)2Cl2]. [Ru(dmso)4Cl2] (2 g, 4.1 mmol), bathophenanthroline (bphen, 2.88 g, 8.7 mmol) and LiCl (1.23 g, 28.9 mmol) were dissolved in anhydrous DMF under inert atmosphere and refluxed at 150 °C for 24 h. The mixture was cooled to rt and some DMF was evaporated. Cold acetone was added, and the mixture was left in the fridge overnight to favour precipitation. The crystalline solid was filtered and washed with lots of water, acetone and diethyl ether to yield a purple solid. Yield: 65 % (2.27 g, 2.7 mmol).

[Ru(bphen)2(L1)]PF6. Ru-NH2. [Ru(bphen)2Cl2] (120 mg, 0.14 mmol) was dissolved in a DCM/MeOH (5:1) mixture under inert atmosphere and protected from light. AgPF6 (83 mg, 0.33 mmol) was added and after 2 h stirring at rt, 4-amino-2-phenylpyridine (26 mg, 0.15 mmol) and NMe4OH (16 mg, 0.18 mmol). The mixture was refluxed overnight. The dark pink solution was cannula-filtered to remove silver salts and the solvent was evaporated to dryness. The crude product was purified by column chromatography on silica in DCM/ACN (50:1) and dried under vacuum to obtain a purple solid. Yield: 53 % (80 mg, 0.074 mmol).

DTNB Assay -concentration of thiols

A calibration curve was prepared taking L-cysteine as a reference of thiols. Six solutions were prepared using 0-12.5 μL of L-cysteine (2 mM), 50 μL of Ellman's reagent (4 mg/mL) and completing volume with PBS buffer to get 1000 μL. After 15 min, the colourless samples changed to yellowish and the absorption spectra of both the calibration and the samples were recorded. Absorption at 412 nm vs concentration of L-cysteine was plotted to obtain the calibration curve adjusted to a linear fit.

BCA Assay -concentration of CTX

A calibration curve was prepared using BSA as the protein. The protocol was followed as stated by Thermo Fisher Scientific ® . Nine standard solutions of BSA were prepared (0-2 mg/mL) using solution A -solution B in 50:1. After mixing both solutions and incubate for 30 min at 37 °C, the absorption spectra of the samples were recorded in the next 10 min. Absorption at 562 nm vs concentration of BSA was plotted to obtain the calibration curve.

Estimation of the number of thiol groups

The number of thiol groups per unit of bioconjugate were calculated as the coefficient of the concentration of CTX and the concentration of CTX or Ru-CTX conjugate.

𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁 𝑜𝑜𝑜𝑜 𝑆𝑆𝑆𝑆 𝑝𝑝𝑁𝑁𝑁𝑁 𝐴𝐴𝑁𝑁 = [𝐶𝐶𝐶𝐶𝐶𝐶] [𝑆𝑆𝑆𝑆]

Phototoxicity Studies of Ru-NH2 on 2D Monolayer Cells

Cell Culture

The CT-26 cell line was cultured in DMEM media (Gibco) supplemented with 10% fetal calf serum (Gibco) and 1% Penicillin-Streptomycin antibiotic (Gibco). Cell lines were maintained in a humidified atmosphere at 37 °C with 5% CO2.

Phototoxicity

Cells were seeded at a 4,000 cells/well density in 96-well plates (100 µL/well) and were incubated at 37 °C, 5% CO2 for 24 h. The medium was replaced by test compound dilutions in fresh medium (100 µL/well), and cells were incubated at 37 °C, 5% CO2 for 4 h. The medium was replaced with 100 µL of fresh medium. Plates were then irradiated at the corresponding wavelength for 1 h using a LUMOS-BIO photoreactor (Atlas Photonics). As a control, a plate was kept in the dark for the same amount of time at 37°C, 0% CO2. Cells were then incubated for an additional 44 h at 37 °C, 5% CO2. The medium was replaced with 100 µL of fresh medium containing resazurin (0.2 mg/mL). After 4 h of incubation at 37 °C, 5% CO2, plates were read using a Cytation 5 (Agilent) Cell

Imaging Multimode Reader (λexc = 540 nm; λread = 590 nm). Fluorescence data were normalized, data were fitted using GraphPad Prism Software, and IC50 was calculated by non-linear regression.

Phototoxicity Studies of CTX-Ru bioconjugates on human 2D Monolayer HNSCC

Cells

Cell Culture

The laryngeal squamous cell carcinoma cell line SQ20B was cultured in DMEM medium (D. Dutcher) added with 10% of inactivated fetal bovine serum (Gibco). Cells were grown at 37 °C in a humidified atmosphere containing 5% CO2.

Phototoxicity of Ru-NH2

4,000 cells/well (100 µL/well) were seeded in 96-well plates and incubated at 37 °C, 5 % CO2 for 24 h. Cells were then treated with a range of increasing concentrations of Ru-NH2 diluted in medium and incubated for 4 h at 37 °C. Medium was then replaced and cells were exposed to red light for 1h using the Photograph Fill Light MFL-06R, Moman® with the following settings: 25% intensity, Current color (H):360° and saturation (S)=100. As a control, an identical culture plate was kept in the dark. 44 h after illumination, the medium was replaced by 100 µL of a 10 % MTT solution (5 mg/mL bromide 3-(4,5-dimethylthiazol-2-yl)-2,5-diphenyl tetrazolium, Sigma Aldrich) diluted in medium. Cells were incubated 1 h at 37 °C before replacing MTT with 100 µL of DMSO (VWR Chemicals). Plates were stirred at room temperature to ensure that all crystals were dissolved, and absorbance was then read at 590 nm (Tristar 2 Multimode Reader LB942, Berthold Technologies®). Dose-response curves were obtained from nonlinear regression using GraphPad Prism Software.

EGFR expression downregulation

Cells were seeded in 6-well plates at a density of 125,000 cells/well (2 mL/well) and were incubated at 37 °C, 5% CO2 for 48 h. Cells were transfected with a specific small interfering RNA (siRNA) targeting EGFR (Ambion) or a non-specific siRNA used as a negative control (Ambion), at a final concentration of 5, 10 or 20 nM with the transfecting agent Lipofectamine RNAiMAX (Invitrogen). Medium was replaced 6 h after transfection and cells were kept at 37 °C for 18 h.

SDS-PAGE and western blot analysis

Total protein extraction was carried out by homogenizing 1.10

Scheme 1 .Scheme 2 .

 12 Scheme 1. Synthesis of cyclometalating ligands (L1-L5). a) HBr, NaNO2, CuBr, H2O, rt, overnight; b) ethylenediamine, reflux, 24 h; c) benzoylacrylic acid, HATU, DIPEA, DMF, rt, overnight; d) 3-(Maleimido)propionic acid N-hydroxysuccinimide ester, TEA, DCM, rt, 4 h.

Fig. 1 .Fig. 2 .

 12 Fig. 1. Absorption spectra of complexes in acetonitrile (10 -5 M).

Fig. 3 .

 3 Fig. 3. Dose-response curves of Ru-NH2 in CT-26 cell line in the dark, after excitation at 670 nm and 740 nm.

  and S35). The Ru-containing bioconjugates (Scheme 3), Ru-Mal-CTX, and Ru-BAA-CTX, were prepared by the rection of the thiolated cetuximab (CTX-SH) with the corresponding Ru-Mal and Ru-BAA complexes in different buffer solutions (PBS, pH = 7.4 and NaPi, pH = 7.0, respectively). MALDI-TOF mass spectra were evaluated to determine the number of Ru units per CTX (Table

Scheme 3 . 1 Fig. 4 .

 314 Scheme 3. Representation of the synthesis of the Ru-CTX conjugates. The structure of the conjugates is representative, as there is more than one ruthenium unit per cetuximab.

Fig. 5 .

 5 Fig. 5. A. MTT-based analysis of the survival of SQ20B cells treated with Ru-NH2 in the dark and with red light. B. Analysis of the cell survival of SQ20B transfected with control (siCTRL) or EGFR siRNA (siEGFR) and treated with Ru-BAA-CTX or Ru-MAL-CTX-based PDT.

Instrumentation 1 H

 1 Chloroform-d and Methylene Chloride-d were purchased from Eurisotop. and 13 C NMR were recorded on a Bruker 400 MHz NMR spectrophotometer. chemical shifts were internally referenced to TMS via the residual 1 H signal of solvents. Chemical shift values are reported in ppm and coupling constants (J) in Hertz. Microanalysis (CHNS) were performed in an Elementar Vario instrument, with two or three repeats per sample. Electrospray ionization-mass spectrometry (ESI-HRMS) experiments were carried out using a LTQ-OrbitrapXL from ThermoScientific (Thermo Fisher Scientific) instrument and operated in positive ionization mode, with a spray voltage at 3.6 kV. A UltrafleXtreme mass spectrometer (Bruker Daltonics, Bremen) was used for all MALDI-

G1361 1260

 1260 Prep Pump, an Agilent G7115A 1260 DAD WR detector equipped with an Agilent Pursuit XRs 5C18 (100 Å, C18 5 μm 250 × 4.6 mm) column. The flow rate was 1 mL/min with the following gradient: 0-3 min: isocratic 95% A (5% B); 3-17 min: linear gradient from 95% A (5% B) to 0% A (100% B); 17-23 min: isocratic 0% A (100% B).

  26 mmol) was dissolved in anhydrous dimethyl formamide(15 mL, degassed). HATU (1.87 g, 4.92 mmol) and DIPEA (2.0 mL, 11.5 mmol) were added, and the reaction was left stirring at rt for 2 h. N 1 -(2-phenyl-4pyridinyl)-1,2-ethanediamine (413 mg, 1.9 mmol) was dissolved in dimethyl formamide (10 mL), and DIPEA was added (3.9 mL, 22.4 mmol). The amino solution was transferred into the acid one, and the rest of the DIPEA (2.0 mL, 11.5 mmol) was added. The reaction was left stirring overnight at rt. The solvent was evaporated to dryness and dichloromethane was used to dissolve the product, which was then washed with water (x1) and brine (x2). After drying with sodium sulphate and filtrating, the solvent was evaporated to dryness. The product was purified by column chromatography in DCM (dichloromethane)/MeOH/NH3 (80:10:1) to yield a white solid. Yield: 12 % (85 mg, 0.23 mmol).1 H NMR (400 MHz, Chloroform-d) δ 8.15 (d, J = 5.6 Hz, 1H), 8.00 -7.88 (m, 3H), 7.86 -7.75 (m, 2H), 7.57 (td, J = 7.6, 1.2 Hz, 1H), 7.45 (t, J = 7.8 Hz, 2H), 7.40 -7.30 (m, 4H), 6.99 (d, J = 15.1 Hz, 1H), 6.78 (d, J = 2.3 Hz, 1H), 6.35 (dd, J = 5.8, 2.1

CTX-SH.

  In an Eppendorf tube, 200 µL of cetuximab (CTX, 5 mg/mL), 33 µL of Traut's reagent (2-iminothiolane, 1 mM) and 750 µL of PBS (pH 8.0, 0.1 M, 0.5 mM EDTA) were stirred for 1 h at rt. Excess of Traut's reagent was removed by overnight dialysis in PBS (pH 7.4, 0.1 M) or NaPi (pH 7.0, 20 mM). The number of thiol groups in CTX-SH were determined by the DTNB assay. 250 µL of CTX-SH, 1 mL of PBS (pH 7.4, 0.1 M)or NaPi (pH 7.0, 20 mM) and 50 µL of 4 mg/mL Ellman's reagent were incubated for 15 min, and the absorbance was recorded at 412 nm. L-cysteine (0-12.5 µM) was used as a standard for calibration. The concentration of CTX and CTX-SH was determined by the BCA assay. 0.1 mL of standard (BSA) or sample solution and 2 mL of working reagent (50 parts of reagent A and 1 part of reagent B) were incubated at 37 °C for 30 min. After cooling and within 10 min, the absorbance was recorded at 562 nm. Standard BSA solutions (0-2000 µg/mL) were used for calibration.CTX-Ru-Mal and CTX-Ru-BAA. The ruthenium-CTX conjugates were prepared by reacting the thiolated Ab, CTX-SH (50 µL) with the corresponding Ru-Mal or Ru-BAA (1 µL, 5 mM in DMF), TCEP (5 µL, 10 mM), DMF (24 µL) in 200 µL of buffer (PBS = pH 7.4, 0.1 M or NaPi = pH 7.0, 20 mM, respectively). After incubation with stirring at rt r.t. for 6 h, the excess of Ruthenium complex was removed by overnight dialysis in the corresponding buffers (PBS for the maleimido conjugate and NaPi for the benzoyl acrylic acid derivative). MALDI-TOF was run to determine the mass and the number of Ruthenium units per CTX.

Table 1 .

 1 Photophysical properties of complexes.

Complex λmax, nm [ε, M -1 •cm -1 ] ε700, M -1 •cm -1 λem, nm

	Ru-Br	278 [105555], 495 [22974], 544 [22196]	873	764
	Ru-NH2	278 [66937], 506 [11361], 582 [15330]	1274	799
	Ru-Mal	278 [115339], 506 [20071], 584 [26049]	2302	797
	Ru-BAA	277 [107389], 507 [17240], 584 [22436]	2028	796

  H6 ), 8.00 -7.94 (m, 2H, H Ph-o ), 7.90 (dd, J = 1.8, 0.6 Hz, 1H, H 3 ), 7.52 -7.41 (m, 3H, H Ph-m , H Ph-p ), 7.39 (dd, J = 5.3, 1.8 Hz, 1H, H 5 ) ppm.13 C NMR (101 MHz, Chloroform-

	d) δ 159.0 (s, 1C), 150.5 (s, 1C), 138.2 (s, 1C), 133.6 (s, 1C), 129.7 (s, 1C), 129.0 (s, 2C),
	127.1 (s, 2C), 125.4 (s, 1C), 124.0 (s, 1C) ppm.
	N 1 -(2-phenyl-4-pyridinyl)-1,2-ethanediamine (L3). 4-bromo-2-phenylpyridine (1.329 g,
	5.68 mmol) were refluxed over ethylenediamine (20 mL, 370 mmol) for 24 h under
	nitrogen. The reaction mixture was extracted with dichloromethane and the organic phase
	was washed once with water and twice with brine. It was dried with sodium sulphate,
	filtered and the solvent evaporated to dryness to obtain a dark brown oil. Yield: 89 %
	(1.074 g, 5.04 mmol). 1 H NMR (400 MHz, Chloroform-d) δ 8.29 (d, J = 5.7 Hz, 1H), 7.91
	(dd, J = 7.0, 1.7 Hz, 2H), 7.48 -7.34 (m, 3H), 6.88 (d, J = 2.3 Hz, 1H), 6.44 (dd, J = 5.7,
	2.3 Hz, 1H), 4.74 (s, 1H
	). Hydrobromic acid (60 mL, 48 % aqueous solution) and
	copper bromide (4.22 g, 29.4 mmol) were added over 4-amino-2-phenylpyridine (L1, 1
	g, 5.88 mmol). The colour immediately changed to purple. An aqueous solution of sodium
	nitrite (8.11 g in 35 mL) was slowly added, leaving a scape for gases to release. The
	mixture colour changed to dark brown, and the slurry was left stirring overnight at room
	temperature. A saturated sodium hydroxide solution was added, and the mixture was

extracted with diethyl ether (x3). The organic phase was dried over sodium sulphate, filtered and the solvent was evaporated to dryness to obtain an orange oil. Yield: 97 % (1.33 g, 5.68 mmol).

1

H NMR (400 MHz, Chloroform-d) δ 8.50 (dd, J = 5.3, 0.6 Hz, 1H,

  C NMR (101 MHz, Chloroform-d) δ 171.3, 170.7, 158.2, 154.2, 150.1, 140.

  After stirring for 1 h, a solution of the ligand L4 (44 mg, 0.12 mmol) in DCM/MeOH (5:1, 4 mL) and the base NMe4OH (12 mg, 0.13 mmol) were added. The mixture was refluxed overnight. After completion of the reaction, the solution was filtered, and the solvent evaporated to dryness. The purple crude was purified by

	and protected from light. column chromatography on alumina in DCM/acetone (gradient from 1 % to 10 %
	acetone). Yield: 9 % (13 mg, 0.01 mmol). 1 H NMR (400 MHz, Methylene Chloride-d2)
	δ 8.52 (bs, 1H), 8.31 -8.03 (m, 7H), 7.98 -7.91 (m, 3H), 7.82 (d, J = 15.2 Hz, 2H), 7.71
	-7.50 (m, 28H), 7.46 (dd, J = 8.3, 7.1 Hz, 2H), 7.37 -7.24 (m, 1H), 7.21 -7.03 (m, 1H),
	6.88 (d, J = 15.2 Hz, 1H), 6.60 (t, J = 6.1 Hz, 1H), 5.92 (bs, 1H), 3.63 (q, J = 6.0 Hz, 2H),
	3.51 (m, 2H). 19 F NMR (376 MHz, Methylene Chloride-d2) δ -73.10 (d, J = 711.3 Hz).
	Anal. Calcd for C71H52N7O2PF6Ru•(H2O): C 65.63; H 4.19; N 7.55; Found: C 65.38; H
	4.06; N 7.40.
	HRMS (ESI) m/z: [M]+ Calcd for C71H52N7O2Ru 1136.3220. Found 1136.3242; (Error:
	1.9 ppm).
	[Ru(bphen)2(L5)]PF6. Ru-Mal. This complex was synthesised in the same manner as Ru-
	BAA, using [Ru(bphen)2Cl2] (130 mg, 0.16 mmol), AgPF6 (91 mg, 0.36 mmol), L5 (62
	mg, 0.19 mmol) and NMe4OH (17 mg, 0.19 mmol). The purple crude was purified by
	column chromatography on alumina in DCM/ACN (gradient from 50:1 to 5:1). Yield: 10
	% (20 mg, 0.024 mmol). 1 H NMR (500 MHz, Methylene Chloride-d2) δ 8.27 -8.15 (m,
	4H), 8.05 (d, J = 9.5 Hz, 1H), 8.00 (s, 1H), 7.92 (s, 1H), 7.76 (s, 1H), 7.69 (t, J = 7.6 Hz,
	2H), 7.65 -7.59 (m, 9H), 7.59 -7.52 (m, 8H), 7.52 -7.44 (m, 4H), 7.02 (s, 1H), 6.75 (s,
	1H), 6.60 (s, 2H), 6.18 (t, J = 6.1 Hz, 1H), 5.05 (s, 1H), 3.75 (t, J = 6.9 Hz, 2H), 3.53 (s,
	2H), 3.44 (t, J = 5.8 Hz, 2H), 2.46 (t, J = 7.0 Hz, 2H).
	Anal. Calcd for C68H51N8O3PF6Ru•(H2O)3: C 61.49; H 4.33; N 8.44; Found: C 61.62; H
	3.96; N 8.28.
	HRMS (ESI) m/z: [M]+ Calcd for C68H51N8O3Ru 1129.3122. Found 1129.3144; (Error:
	1.9 ppm).
	1 H NMR (400 MHz, Methylene Chloride-d2) δ 8.68 (d, J = 5.6 Hz,
	1H), 8.50 (d, J = 5.6 Hz, 1H), 8.21 (d, J = 5.3 Hz, 1H), 8.14 (s, 2H), 8.15 -8.04 (m, 3H),
	7.76 (d, J = 6.8 Hz, 1H), 7.65 -7.52 (m, 23H), 7.39 (d, J = 5.5 Hz, 1H), 7.28 (d, J = 2.4
	Hz, 1H), 7.16 (d, J = 6.4 Hz, 1H), 6.92 (td, J = 7.7, 1.2 Hz, 1H), 6.81 (td, J = 7.3, 1.2 Hz,

  6 cells in 100 µL of 1X lysis buffer [1X NP40, 50mM Tris, 150mM NaCl, 1X protease inhibitor, Sigma]. 15 μg of total proteins were resolved by 6 %-12 % gradient SDS-PAGE according to standard methods. Proteins were detected with primary antibodies raised against EGFR (D38B1, rabbit mAb, 1:2,000, Cell Signaling) and GAPDH (6C5, mouse mAb, 1:2,000, Santa Cruz). Blots were probed with secondary antibodies (1:8,000 anti-mouse IgG-HRP linked antibody, Cell Signaling, 7076; 1:10,000 anti-rabbit IgG-HRP linked antibody, Cell Signaling, 7074) Proteins were visualized with enhanced chemiluminescence using the Clarity™ ECL Western blotting Substrate Bio-Rad reagent, according to the manufacturer instructions. Signals were acquired on a Pxi Imager (Syngene®).

Immunofluorescence staining

Cells were seeded on coverslips at a 100,000 cells/well density in 12-well plates (1 mL/well) for 24 h and transfected as described above, with a siRNA final concentration of 5 nM. Cells were fixed with 4 % PFA for 10 min and permeabilized with 0.1 % Triton 1X PBS for 5 min at rt room temperature. Saturation of specific sites was achieved with 5 % Normal Goat Serum for 30 min at room temperature. Cells were incubated with an anti-EGFR antibody (D38B1, rabbit mAb, 1:500, Cell Signaling) 4 h at 4 °C and then washed three times in 1X PBS. Coverslips were further incubated with a goat anti-rabbit-alexa488 secondary antibody (A11034, 1:1,000, Invitrogen). After 3 washes in 1X PBS, nuclei were labeled with a DAPI (4',6-diamidino-2-phenylindole) solution (1:20,000) for 5 min, and coverslips were mounted in Calbiochem FluorSave TM reagent (Merck Millipore). Pictures were taken with a Zeiss Axio Imager M2-Apotome2 fluorescence microscope.

Phototoxicity of CTX-Ru bioconjugates

4,000 transfected cells/well (100 µL/well) were seeded in 96-well plates and incubated at 37 °C, 5 % CO2 for 24 h. Then, cells were treated with different concentrations of Ru-BAA-CTX and Ru-Mal-CTX diluted in medium for 15 min. Cells were washed twice quickly and once 5 min with medium before light exposure as previously described. A MTT cell viability assay was carried out as described above.

ASSOCIATED CONTENT Supporting Information available. Characterization of ligands and complexes ( 1 H, 13 C and 19 F NMR spectra, mass spectra and HPLC chromatograms), photophysical properties, additional biological experiments, and characterization of the bioconjugates (DOC).

Conflicts of interest

The authors declare that they have no conflict of interest.

Aknowledgements

The

TOC Graphics

A new Ru(II) cyclometalated complex activatable at 740 nm is reported as a photosensitizer for photodynamic therapy. Two ruthenium-cetuximab bioconjugates have been prepared to gain cancer cell specificity, but were found to be not phototoxic.

Twitter: @marta.martinez.09, @Agandioso; @GasserGroup @ChimieParisTech @psl_univ


Ludovic Henrio
email: lhenrio@sophia.inria.fr

Florian Kammüller

Marcela Rivera
email: mrivera@sophia.inria.fr

An Asynchronous Distributed Component Model and its Semantics

This paper is placed in the context of large scale distributed programming, providing a programming model based on asynchronous components. It focuses on the semantics of asynchronous invocations and component synchronisation. Our model is precise enough to enable the specification of a formal semantics. A variant of this model has been implemented, together with tools for managing components. This paper explains why we consider that our component model is efficient and provides a convenient programming model. We show how futures play a major role for such asynchronous components, and provide a reduction semantics for the component model. This reduction semantics has been specified in the Isabelle theorem prover, and will be used to prove properties on the component model and its implementations.

Introduction

Component models provide a structured programming paradigm, and ensure a better re-usability of programs. Indeed application dependencies are defined together with provided functionalities by the means of provided/required ports; this improves the program specification and thus its re-usability. In distributed systems, this takes even more importance as the structure of components can also be used at runtime to discover services or adapt component behaviour. Several effective distributed component models have been specified, developed, and implemented in the last years [START_REF]CCA-Forum: The Common Component Architecture (CCA) Forum home page[END_REF][START_REF](OMG): CORBA Component Model Specification[END_REF][START_REF] Beisiegel | SCA service component architecture, assembly model specification[END_REF][START_REF] Baude | GCM: A Grid Extension to Fractal for Autonomous Distributed Components[END_REF] ensuring different kinds of properties to their users. To be able to prove such properties, one must rely on some well defined semantics for the underlying programming language or middleware. This paper provides such a background for a category of component models.

This work is a study of asynchrony in component models. We present here a model for distributed components. This model is based on one key principle: Components are the unit of concurrency. More precisely, components only communicate by sending requests or results for those requests. We say that this model is asynchronous because requests can be treated in an asynchronous manner thanks to the introduction of futures (place-holders for request results). In order to prevent other communications or concurrency to occur, we require that components do not share memory, which ensures that components really are the concurrency units. From a computational point of view, components are loosely coupled: the only strong synchronisation consists in waiting for the result of a request, and can be performed only when and where this result is really needed thanks to the use of futures.

Such components can then provide a convenient abstraction for distribution: each component can be placed on a different (virtual) machine. Indeed, the abstractions suggested above imply that each memory location is only accessible by one component, and thus it is easy to place each component on a different independent location. This makes our component model adapted to distribution.

This component model is closely related to the Grid Component Model (GCM). Indeed, this work can be considered as the GCM model, where communication is chosen to be a request / reply mechanism with futures. ProActive/GCM is a reference implementation of the GCM. Our objective is to provide a programming model more general than the one adopted in ProActive/GCM, but more precise than the strict GCM definition. Indeed, GCM provides a structural description of components. From this definition, we precise component composition and communication semantics; more precisely we define composite component behaviour and an asynchronous communication mechanism using futures. ProActive/GCM can also be considered as a possible implementation of our model where components are implemented as active objects. Our definition of components being both precise and formalised, we expect it to be a strong guide and a reliable basis for both component system implementation and formal tools.

Our components are loosely coupled, with a data-flow oriented synchronisation. While being a very convenient way of parallelising computations, loose coupling can raise issues when one wants to synchronise the management of several components. We will show in this paper some of the issues that can arise for synchronising the management of components, and some possible solutions.

We first detail the component model we suggest and explain why we think the proposed constructs are efficient (Section 2). After this introduction of our major concepts, we offer a comparison by summarising the main component models found in the literature (Section 3). Next, we introduce our formal model of asynchronous components (Section 4), and we present several implementation and component management issues (Section 5). Finally, we conclude this paper.

An Asynchronous Component Model

The GCM [START_REF] Baude | GCM: A Grid Extension to Fractal for Autonomous Distributed Components[END_REF] is a component model defined by the European Network of Excellence CoreGrid. It extends the Fractal component model, by addressing Grid computing: it supports deployment, scalability, autonomic behaviour, and asynchronous communications. The GCM relies on the following aspects:

-Fractal as the basis for the component architecture: the main characteristics GCM benefits from Fractal are its hierarchical structure, the enforcement of separation between functional and non-functional concerns, its extensibility, and the separation between interfaces and implementation. -GCM supports collective communications -one-to-many, many-to-one, but also many-to-many. -GCM also comes with a support for autonomic aspects and better separation of concerns (functional vs. non-functional).

In this section, we will first recall precisely the component structure of GCM components; then we will refine this model to define the semantics of our asynchronous components.

Component Structure

Let us start by the structure of the component model that is inherited from Fractal [START_REF] Bruneton | Recursive and dynamic software composition with sharing[END_REF]. GCM is a hierarchical and reflective component model. A GCM component can be either composite (i.e. composed of subcomponents), or primitive (a basic element encapsulating the business code). A component comprises a content (providing the functional code) and a membrane (a container managing non-functional operations).

The interfaces are the access points to components. The components have client interfaces -emitting messages/invocations-and server interfaces -able to receive messages/invocations. A binding connects a client interface to a server interface (shown in Figure 2), with the implicit semantics that the message emitted by the client will be received by the server interface. Each client interface is bound to a single server interface. For composite components, if the interface is exposed to subcomponents this is an internal interface. If, on the contrary, the interface is exposed to other components this interface is an external interface. All the external interfaces of a component as well as its internal interfaces must have distinct names. Depending on its functionality, each interface is either functional or non-functional. Each internal functional interface must have a corresponding external interface of the same name. The implicit semantics is that a call received on a server external (resp. internal) interface will be transmitted -unchanged -to the corresponding internal (resp. external) client interface. Among those notions, only non-functional client interfaces have been introduced in GCM compared to Fractal. A GCM component architecture can be described using an architecture description language (ADL).

A GCM component and its different parts are shown in Figure 1. Functional interfaces are shown horizontally, and non-functional ones vertically. Client interfaces are on the right (or bottom) and server on the left (or top). Note that each external functional interface has a corresponding internal one, whereas nonfunctional interfaces may not have any corresponding internal ones in case nonfunctional requests are treated by the membrane. Figure 2 shows a component assembly composed of two main components, the left one is a composite composed of two primitives; the figure also illustrates all the kind of bindings that can be encountered in a GCM component assembly.

Adaptation mechanisms are triggered by the control part of the components; we call this part non-functional (NF). This NF part, named membrane, is composed of controllers that implement NF concerns. The membrane is a set of (controller) components that can be (re)configured. These controllers can manage configurations and reconfigurations. Compared to Fractal, GCM gives a component structure to the membrane; moreover in GCM controllers inside the membrane can interact with the membranes of other components through bindings between NF interfaces.

Interface cardinality

The interface cardinality indicates how many bindings can be made from or to this interface. We have three kinds of cardinalities: singleton, collection, and collective. Collection interfaces were defined in Fractal to let an interface be instantiated as many times as necessary. GCM defines collective interfaces: multicast (one-to-many) and gathercast (many-to-one).

A multicast interface is a client interface that transforms a single invocation into a list of invocations, forwarded in parallel to a set of connected interfaces. The result of an invocation on a multicast interface is a list of results. Invocation parameters can be distributed according to a distribution policy: for example, broadcast sends the same parameter to each of the connected server interfaces; and scatter strips the parameter so that the bound components work on different data. Distribution policy can also be customized.

Symmetrically, a gathercast interface is a server interface that synchronises a set of invocations toward the same destination. A gathercast interface coordinates a set of incoming invocations before continuing the invocation flow, forwarding a single invocation. This interface may define synchronisation barriers and may gather incoming data.

Formalising collection and collective interfaces is outside the scope of this paper and we will focus on singleton interfaces. Singleton cardinality is to our mind sufficient to express the crucial points of asynchrony, and many-to-many communications can be studied as an extension to this work.

Informal Semantics

We focus now on the semantics of our component model; for this we make a few additional assumptions compared to the GCM component model. First of all, we start from the point of view presented in the introduction: "components are the unit of concurrency" and components do not share memory. This way interaction between components is limited to communication.

Communication The basic communication paradigm we consider is asynchronous message sending: upon a communication the message is enqueued at the receiver side in a queue. To prevent shared memory between components, messages can only transmit parameters which are copied at the receiver side; no object or component can be passed by reference. 3 This communication semantics is similar to requests in an active object model like ASP [START_REF] Caromel | A Theory of Distributed Objects[END_REF], but also to communication in Actors [START_REF] Agha | A foundation for actor computation[END_REF], where messages are enqueued in the message delivery system of the destination.

We call requests the messages that are transmitted between components, and that can contain parameters also transmitted (copied) between components.

References to components cannot be passed between components, for example, method parameters cannot contain references to components. More precisely, in order to allow non-functional features to be aware of component structure and manage the component system, we restrict component manipulations to non-functional concerns.

Returning results

We call our component model asynchronous because communication does not trigger computation on the receiver side immediately, it just enqueues a request. Such a mechanism can be implemented with synchronous or asynchronous communications. As in ASP and ProActive, the model defined in Section 4 relies on a rendez-vous (enqueueing a request is done synchronously but the receiver component is always ready to enqueue a request). Asynchronous invocations could be performed by enforcing request results to be returned by an explicit call-back mechanism, but we prefer handling results automatically in order to prevent business code from dealing with communication purposes.

To allow for transparent asynchronous requests with results, we use futures, first introduced in [START_REF] Yonezawa | Object-oriented concurrent programming in ABCL/1[END_REF][START_REF] Halstead | Multilisp: A language for concurrent symbolic computation[END_REF]. A future is an empty object that represents the result of a computation and will be updated when the result is available. In our case, futures are a transparent and natural way to handle asynchronous requests: a future is automatically created when sending a request from a component to another, it represents the result of this request. Transparent futures come with a natural and automatic synchronisation called wait-by-necessity: futures can be safely transmitted between components or stored while the real value of the result is not needed. When the value is really needed the thread accessing the future is automatically blocked until the result is available.

Transmitting a future between components is not considered as an operation requiring the value. Consequently, the result or the parameters of a request can contain a future, or even can simply be a future. Consequently, several components in the system may have a reference to the same future, the component platform will then be in charge of updating all those references. Updating a future consists in replacing a future reference by the result for the corresponding request. We call those futures first-class because they can be transmitted between components as any other value.

Primitive component behaviour Let us now detail a behaviour for primitive components that will ensure asynchronous communications and future handling.

The primitive components encapsulate the business code, thus in our model we consider they can have, internally, any behaviour. They will serve requests in the order they wish, providing answer for all the requests they receive. They can call other components by emitting a request on one of the client interface. However, each primitive component must always be able to accept a request (that will just be enqueued in its request queue), and to receive a result (that will replace a future reference by the received value).

Figure 3 illustrates a primitive component and its behaviour. A primitive component consists of a request queue, a content, a membrane, and a result list. Its content contains the business code that serves the requests; requests arrive from the server interfaces on the left and are emitted by the client interface on the right. An incoming request is enqueued immediately, associated with its future identifier. Later this request is served and treated by the component content, possibly emitting new requests to the clients. When the service is finished and a value is calculated for its result, this value is stored in the result list, stating that the future for the request is mapped to this calculated value. The calculated value can itself contain references to other futures. Later, the result will be sent from the result list to the components that hold a reference to the corresponding future. As future references can spread in all the components, including requests, results, and current component states, received results are used to update future references in all parts of the component.

Mono-threaded components

In our model, a given thread manipulates a single component, but nothing prevents our components from being multi-threaded. Even, a component can serve several requests at the same time.

However, like in ProActive/GCM, components can be chosen to be monothreaded; this simplifies concurrency, as each component has a sequential behaviour but can create deadlocks. For example, if there is a cycle of dependencies between results of requests: in a subsystem with two components, C1 and C2, a request A, computed by C1 depends on the result of a request B to component C2, itself depending on the result of another request C, but awaited from C1. In that case, C1 will be indirectly waiting for itself, which could only be resolved by a second thread in C1. Fortunately, most applications can be written without such cyclic dependencies, especially thanks to first-class futures.

i 1 i 2 Request(f) f f'=f f' Request(f')

Fig. 4. Request delegation

Composite component behaviour To summarise, the behaviour of the primitive components is highly parameterised. We have just specified the handling of requests and futures in the preceding paragraphs. By contrast, composite components have a predefined behaviour. 4 Composite components serve requests in a FIFO order, delegating request to the bound components or to the external ones in a much transparent and natural way. Globally, a request emitted by the client interface of a primitive component will be sent unchanged to the server interface of the primitive component that is linked by a binding. More precisely, several bindings may be used and several composite components may be crossed. This request transmission can rely on a mechanism similar to the handling of requests by primitive components; this mechanism is illustrated by Figure 4. Requests are dequeued in a FIFO order from the request queue. Consider one request (associated with the future f ), suppose the request has been received from the outside of the composite, i.e., it was received on an external server interface. There is necessarily an internal client interface matching this external one. Handling the requests consists in sending another request from the internal client interface matching the interface that receives the request (i1). This request is sent to the interface bound to i1, that is i2 in the figure; this interface necessarily belongs to an inner component. This new request corresponds to a future f ′ , and the result for the first one is just a reference to f ′ , i.e. f = f ′ . In case the request was received from the inside of the composite, the mechanism is similar, with a new request sent from the matching external client interface.

An alternative approach would consist in implementing a delegation mechanism, like in allowing a component to delegate the calculation of a result to another component, like handlers of [START_REF] Niehren | A concurrent lambda calculus with futures[END_REF]. However, we did not choose this technique in order to avoid introducing a new mechanism, but also to ensure that the component calculating a value for a given future will not change along time.

Comparison with some Component Models

This section presents the main distributed component models, focusing on their main characteristics with respect to structure, distribution, and synchronisation. We summarise this comparison in Table 1.

CCA [START_REF]CCA-Forum: The Common Component Architecture (CCA) Forum home page[END_REF] aims at a minimal specification of component architecture for highperformance computing. CCA builds on core concepts, defining a component (the software entity), a framework (the container), and ports (the access towards the environment). The components are assembled at runtime connecting ports together, thanks to scripts that interact with the CCA framework. The container allows building, connecting and running components. Component composition is not hierarchical. CCA considers parallelism and distribution of data.

CCM (CORBA Component Model) [START_REF]CORBA Component Model[END_REF][START_REF](OMG): CORBA Component Model Specification[END_REF] is a specification for business components which can be distributed, heterogeneous, and implemented over different programming languages or operating systems. CCM components communicate through ports that can be interconnected. Also, the OMG D&C specification [START_REF] Omg | Deployment and configuration of component-based distributed applications[END_REF] supports hierarchical assemblies. All component instances are handled at runtime by their container. A fortitude of CCM is to provide a clear separation between functional and non-functional concerns.

SCA (Service Component Architecture) [START_REF] Beisiegel | SCA service component architecture, assembly model specification[END_REF] provides a component-oriented programming model for building applications and solutions based on a Service Oriented Architectures. SCA provides a model for both the composition of services and the creation of service components, including the reuse of existing application functions within SCA composites. SCA is a hierarchical component model, but its component structure is not specified at runtime. Additionally, SCA components can be implemented with different languages such as Java, BPEL, and state machines.

ASP [START_REF] Caromel | A Theory of Distributed Objects[END_REF][START_REF] Caromel | Asynchronous and deterministic objects[END_REF] is the computation model behind ProActive. This calculus of active objects starts from ς imp -calculus [START_REF] Abadi | A Theory of Objects[END_REF] extending it with explicit commands for activating an object and for serving requests. Activities contain an active object, possibly several passive objects, and are managed by only one thread. Communication is realized using an asynchronous request reply mechanism with futures. A request is associated to each future, and the request service aims at providing a result value to the future. Using a translational semantics, ASP components are defined as hierarchical combinations of activities.

Creol [START_REF] Johnsen | An asynchronous communication model for distributed concurrent objects[END_REF][START_REF] Johnsen | Creol: a types-safe object-oriented model for distributed concurrent systems[END_REF] is a programming and modelling language for distributed systems based on active objects communicating via asynchronous method calls using futures. Creol's base language is -at least in more recent publications, e.g. [START_REF] Grabe | Executable interface specifications for testing asynchronous creol components[END_REF] an extended version of the functional ς-calculus [START_REF] Abadi | A Theory of Objects[END_REF]. Besides explicit distinction between fields and methods of objects the authors introduce classes and threads as first class citizens. Classes contain implementation of methods; threads are sequences of method calls referenced by futures; objects' fields contain the values resulting from thread evaluation. Concurrent access to objects is controlled by an explicit lock mechanism. The operational semantics is a reduction style structural operational semantics based on rewriting logic implemented in Maude which enables testing of model specifications [START_REF] Meseguer | Conditional reqriting logic as a unified model of concurrency[END_REF]. Interfaces are integral part of the Creol language. They describe the observable behaviour of objects using assumption guarantee specifications [START_REF] Jones | Development Methods for Computer Programs Including a Notion of Interference[END_REF]. Traces of communication events between the object and its environment specify input and output behaviour based on visible parts of an object's features. More recently, [START_REF] Grabe | Executable interface specifications for testing asynchronous creol components[END_REF] defines Creol components, and a framework for describing and testing them. The authors use a simple specification language over communication labels enabling the expression of component behaviour as a set of traces at the interfaces.

A Creol component is a collection of classes, objects, and threads where the threads are simply composed in parallel. Thus, components are not hierarchical. Threads -or sets of threads -define concurrent components. A thread never leaves the object in which it is defined. Thus objects are the unit of concurrency. Distribution is not given by explicit locations but using independent object evaluation and asynchronous method call invocations. In comparison to Creol, our approach is hierarchical. We use a separate level of component specification with an abstract behaviour model. We separate the structural component level from the program semantics.

focus [START_REF] Broy | The design of distributed systems -an introduction to focus[END_REF] is a framework for the systematic formal specification and development of distributed components communicating by asynchronous messages. Contrarily to other models, in this framework the basic notion is the stream. There are two types of streams: streams of actions (traces) and streams of messages. Streams of messages are used to represent communication histories of channels. The behaviour of a component is described by logical formulas specifying stream processing functions. Compared to this approach, our formalization focuses on components that could be imperative and can have a much richer behaviour, more difficult to specify, but more expressive. We expect to be able to prove automatically properties on component composition and component behaviour.

The Relational Calculus of Object and Component Systems (rCOS) [START_REF] He | rcos: A refinement calculus for object systems[END_REF] is based on the Unifying Theory of Programming by He and Hoare supporting concurrency and relational refinement. In the rCOS component model [START_REF] Chen | A model of component-based programming[END_REF] components are aggregations of objects; it uses required and provided interfaces together with contracts. rCOS has a rich and fine-grained object model but lacks -in comparison to our approach -the variety of hierarchical composition at the component level and consequently the explicitness of component interaction.

Fractal [START_REF] Bruneton | Recursive and dynamic software composition with sharing[END_REF] and GCM [START_REF] Baude | GCM: A Grid Extension to Fractal for Autonomous Distributed Components[END_REF] were presented in the preceding section. Let us simply recall their main differences. Contrary to Fractal, GCM specifies distribution aspects of the component model, and defines one-to-many and many-toone communication, which are particularly efficient for distributed components. The GCM model also refines the structure of the membrane, and defines some controllers for autonomic behaviour.

A GCM reference implementation is based on ProActive [START_REF] Caromel | ProActive: an integrated platform for programming and running applications on grids and P2P systems[END_REF]. In this implementation each component and each composite membrane is an active object. The controllers are encapsulated in the membrane which also dispatches functional calls to inner components. In this implementation, components communicate through asynchronous method calls with futures. Futures can be for-warded to any component in a non-blocking manner. A property inherent to this implementation is the absence of shared memory between components, this leads to constraints but also greatly simplifies the reasoning about concurrency. The primitive components act as the unit of distribution and concurrency (each thread is isolated in a component). In order to formalise Fractal components, several models and calculi have been designed, addressing different aspects. The Kell-calculus was introduced as a very general calculus able to represent component containment, control and passivation [START_REF] Schmitt | The kell calculus: A family of higher-order distributed process calculi[END_REF]. Then, this work was extended and adapted in order to deal with shared components [START_REF] Hirschkoff | Componentoriented programming with sharing: Containment is not ownership[END_REF]. In Fractal, a component is shared if it is the subcomponent of several different composite components. The formalism we present does not deal with component sharing. More recently, the Fractal component model has been formalised in Alloy [START_REF] Merle | A formal specification of the Fractal component model in Alloy[END_REF]. This paper gives a very precise and unambiguous formalisation of Fractal component's structure and control. Compared to this framework, our work focuses on the asynchronous aspects of components, and somehow takes the decision of giving a less general semantics to components and component communications in order to provide a formal model of the interplay between component communication, component behaviour, their control and their structure.

Amongst the formal models for distributed computing, our work relies on the notion of futures and requests that have already been formalised, outside the context of components, see for example [START_REF] De Boer | A complete guide to the future[END_REF] in the context of Creol or [START_REF] Niehren | A concurrent lambda calculus with futures[END_REF] in the context of functional programming.

Formal Model

This section defines a semantics for our component model. It is being formalised in Isabelle/HOL [START_REF] Nipkow | Isabelle/HOL -A Proof Assistant for Higher-Order Logic[END_REF]. 5 This explains some design choices made here.

Structure and Notations

We let v j , p j range over values, f j range over futures, i j range over interfaces, N range over component names, and C over components. A list is denoted [a i ] i∈1..n . The operator # is the list append operation. l \ f removes f from the list l, whatever its position is.

Component definition We build requests as triples (future identifier, parameter value, invoked interface): R j ::= [f j , v j , i j ]. A result maps a value to an identified future: A behaviour is a labelled transition system between internal states where labels are actions defined below. An internal state contains a set of current requests (currRq), and a state referencing a set of futures.

F j ::= [f j , v j ]. A component
s.queue returns the current queue of state s. The constituents of a state s, e.g. its queue, can be updated individually, for example s queue := Q denotes a new state obtained by changing the queue of s to Q. Bindings Each binding is of the form [N.i 1 , N ′ .i 2 ], if interface i 1 of component named N is plugged to the interface i 2 of N ′ (where N and N ′ can be This if the plugged interface is the composite component that defines the bindings).

Subcomponents

Futures For any value, state, or component, futs(v) (resp. futs(s), futs(C)) represents the set of futures referenced by this element. We use a function UpdFut that is applied to values;

UpdFut(v i , f, v) replaces the future f -if present -in value v i by v. Note that futs(UpdFut(v i , f, v)) ⊆ futs(v) ∪ futs(v i ) \ {f } (\
is the set subtraction). findRes(S, f ) looks inside a component system S and returns the value which is the result corresponding to future f , if it is already computed.

Local Actions

The behaviour of the primitive components is greatly customisable. For the purpose of the component model, we suppose this behaviour is specified by an (infinite) labelled transition system, it is denoted by B C for a given primitive C. The actions of the primitive components are the labels of the transitions, and states are those of the primitive component. Actions of interest are the following:

NewService itfs p f dequeues a request on an interface of the set itf s and starts serving it; f receives the future identifier and p the request parameter. Tau is a non-observable action allowing to encapsulate internal behaviour. Call i p f sends a request on interface i with parameter p; f receives the future identifier that corresponds to the request. i must be one of the client interfaces of the primitive component. EndService f v finishes a service associating value v to future f ; this action adds a new entry in the result list. ReceiveResult f v receives a result value: future f is updated with value v. A primitive component must always be able to receive a future (if f / ∈ futs(s) this action has no effect):

(∀f, s, v. ∃s ′ . (s, ReceiveResult f v, s ′ ) ∈ B C )
Constraints on current requests The set currRq of requests currently handled by the primitive component changes only when a request is served (one current request added), or a service is finished (one current request removed). Additionally, one can only finish a service for a request that is current; this leads to the following constraints:

(s, NewService itf s p f, s ′ ) ∈ B C ) ⇒ s ′ .currRq = f #s.currRq (s, EndService f v, s ′ ) ⇒ (f ∈ s.currRq ∧ s ′ .currRq = s.currRq \ f )
For all the other actions we have (s, action, s ′ ) ∈ B C ⇒ s ′ .currRq = s.currRq.

Constraints on referenced futures Futures referenced by the internal state of a primitive component are also constrained. In general (s, action, s ′ ) ∈ B C implies futs(s ′ ) ⊆ futs(s), except when a new request is served or a result is received. In those cases, the request parameter or the result may contain new futures. Additionally, when a result is received, the future updated should not be referenced any more.

(s, NewService itf s p f, s ′ ) ∈ B C ) ⇒ futs(s ′ ) ⊆ futs(s) ∪ futs(p) (s, ReceiveResult f v, s ′ ) ∈ B C )∧f ∈ futs(s) ⇒ futs(s ′ ) ⊆ (futs(s) \ {f })∪futs(v)
Moreover, sent values can only reference futures known by the internal state:

(s, Call i p f, s ′ ) ∈ B C ) ⇒ futs(p) ⊆ futs(s) (s, EndService f v, s ′ ) ⇒ futs(v) ⊆ futs(s)
Handling received values When an action receives a value, for example, NewService itfs p f receives p, the action must accept any value for parameter p and alter the internal state accordingly; p is, in fact, a variable that will, in turn, receive a value from the request queue. Similarly, f will receive the identifier of the future to handle. Instead of introducing variables and scoping, we simply chose to state that some of the parameters must be able to receive any value:

(s, NewService itf s p f, s ′ ) ∈ B C ⇒ ∀ p ′ , f ′ . ∃s ′ . (s, NewService itf s p ′ f ′ , s ′ ) ∈ B C
This applies also for f in Call p f : the future must be chosen fresh, and v in ReceiveResult f v : the received result is given by another component.

Semantics of the Component Model

The formal semantics of the component model defines a reduction relation → R by a set of inductive rules. S ⊢ C → R C ′ if, in the component system S, the component C can be reduced to the component C ′ ; S is the composite component containing all the components of the system. It is necessary to know the whole component system to retrieve request results and update futures. From → R , a reduction for the global component system can then be defined:

S S ′ ⇔ S ⊢ S → R S ′ .
There is a second parameterised relationi 1 , f, v → allowing to express that a component is willing to emit a request, and must be matched with a reception action; statements of the formi 1 , f, v → used as hypotheses to the rules for composite components lead back to statements of

→ R . If ⊢ C -i 1 , f, v → C ′ ,
then C emits a request on the interface i 1 , with parameter v, and associated to a future f ; after the emission, C becomes C ′ .

There are two kinds of reduction rules: the ones for primitive components (Figure 5), and the ones dealing with composite components (Figure 8).

In detail, the behaviour defined in primitive components determines the following rules of reduction.

Tau: if the state s of a primitive component Prim[itfs, s] contains a Tau transition from the internal state s.intState to another state s 2 then the component's internal state can be replaced by s 2 . In Figure 3, this rule corresponds to internal transitions inside the content of the composite. RcvResultPrim: the primitive component's behaviour always contains a transition defining the reception of value v for future f , i.e. ReceiveResult f v, changing the internal state into the result state s 2 defined in the behaviour. The result value is found in the component system S; it is returned by the function findRes(S, f ). The future is also updated in the request queue and the result list by the function UpdFut. After such a reception, the future f is not referenced anymore by the primitive. In Figure 3, this rule corresponds to the three thick arrows with "results received from other components". Call: the call to an interface i 1 with future f and parameter value v presupposes that the future f is fresh. Such a call transition in the behaviour of

Tau (s.intState, T au, s2) ∈ s.behaviour S ⊢ Prim[itfs, s] →R Prim[itfs, s intState := s2 ] RcvResultPrim (s.intState, ReceiveResult f v, s2) ∈ s.behaviour findRes(S, f ) = v s.queue = [fj, vj, ij] j∈1..n Q = [fj, UpdFut(vj, f, v), ij] j∈1..n s.results = [f k , v k ] k∈1..n ′ R = [f k , UpdFut(v k , f, v)] k∈1..n ′ S ⊢ Prim[itfs, s] →R Prim[itfs, s intState := s2, queue := Q, results := R ] Call (s.intState, Call i1 v f, s2) ∈ s.behaviour f / ∈ futs(S) ⊢ Prim[itfs, s] -i1, f, v → Prim[itfs, s intState := s2 ] EndService (s.intState, EndService f v, s2) ∈ s.behaviour S ⊢ Prim[itfs, s] →R Prim[itfs, s intState := s2, results := s.results#[f, v] ] ServeNext (s.intState, N ewService itf s v f, s2) ∈ s.behaviour [f ′ , v ′ , i ′ ] ∈ Q ⇒ i ′ / ∈ itf s s.queue = Q#[f, v, i]#Q ′ S ⊢ Prim[itfs, s] →R Prim[itfs, s intState := s2, queue := Q#Q ] Fig. 5. Primitive Component Semantics
a primitive component creates now a parameterised reductioni 1 , f, v → of the primitive component because this call is passed on to the enclosing composite component. Upon synchronisation with the component bound to this one, the reduction will occur, modifying the internal state and storing locally the future f . In Figure 3, this rule corresponds to the "request sent" arrow sent to the client interface. EndService: the end of a service denotes that one of the current requests of a primitive component is finalised yielding value v. Hence, the respective primitive component's result list is extended by the pair [f, v] where f is the future that corresponds to the finalised current request. After reduction the primitive component's current requests does not contain f anymore (see above). In Figure 3, this rule corresponds to the arrow. ServeNext: finally, a NewService itf s v f transition in a primitive component's behaviour leads to the creation of a new current request in the internal state of the component. The oldest request on the interface i is served. The parameter v matches the parameter of the first request in the request queue, and f , its corresponding future. The reduction updates the internal state by plugging in the target state s 2 of the behaviour's transition, and by popping off the head of the request queue. In Figure 3, this rule corresponds to the "end of service" arrow.

CommBrothers CompositeCall

RcvResultComp findRes(S, f ) = v s.queue = [fj, vj, ij] j∈1..n Q = [fj, UpdFut(vj, f, v), ij] j∈1..n s.results = [f k , v k ] k∈1..n ′ R = [f k , UpdFut(v k , f, v)] k∈1..n ′ S ⊢ Comp[itf, subCp, bindings, s] →R Comp[itf, subCp, bindings, s queue := Q, results := R ] CommBrothers [N.i1, N ′ .i2] ∈ bindings ⊢ subCp[N ] -i1, f, v → C SubCp ′ = subCp[N → C] C ′ = Enqueue(subCp ′ [N ′ ], [f, v, i2]) S ⊢ Comp[itfs, subCp, bindings, s] →R Comp[itfs, SubCp ′ [N ′ → C ′ ], bindings, s] CommParent [N.i1, T his.i2] ∈ bindings; ⊢ subCp[N ] -i1, f, v → C S ⊢ Comp[itfs, subCp, bindings, s] →R Enqueue(Comp[itfs, subCp[N → C], bindings, s], [f, v, i2]) CommChild s.queue = [f, v, i1]#Q [This.i1, N ′ .i2] ∈ bindings f ′ / ∈ futs(S) C ′ = Enqueue(subCp[N ′ ], [f ′ , v, i2]) s ′ = s queue := Q, results := s.results#[f, f ′ ] S ⊢ Comp[itfs, subCp, bindings, s] →R Comp[itfs, subCp[N ′ → C ′ ], bindings, s ′ ] CompositeCall s.queue = [f, v, i1]#Q i1is a client
(f,v) i 1 i 2 ], [f, v, i2]) CommParent [N.i1, T his.i2] ∈ bindings; fresh f Fig. 9. CommParent rule i 1 i 2 (f',v) fresh f' N' f'=f [This.i1,N .i2] ∈ bindings =[f, v, i1]# 1]#Q [ ], [f , v, i2])
Fig. 10. CommChild rule queue. The bindings must bind the component N interface to the (inner server) interface of the parent. CommChild, illustrated in Figure 10: this rule is the inverse case of the preceding one -a component communicates to a child -corresponds to a delegation of a request to subcomponents as shown in Figure 4. The parent component's request queue is reduced by its first element, a new future f ′ for the result of this request is created and added to the result list of the parent component, and the request -with the new future -is queued into the respective subcomponent. The subcomponent is determined using the bindings: if the original request was on the (external server) interface i 1 and This.i 1 is bound to N.i 2 then the request will be sent to the interface i 2 of the subcomponent N . The composite component records in its request queue that the result for the future f is in fact the newly created future f ′ . CompositeCall: this rule explains how a call received by a subcomponent is emitted on the external client interface onto the context of the enclosing component. This rule corresponds to the Call rule for the primitive components. The first request f, v received on (internal server) interface i 1 is sent on the matching external client interface (with same name). This call will be matched against a Comm rule that will enqueue this request. A fresh future f ′ is found for this new request and the composite records that the value of f is in fact the future f ′ .

Figure 11 illustrates a sequence of rules allowing a client component Cli to send, on interface c, a request to the interface s of a component Srv; Srv is encapsulated in a composite component Cmp, thus the request transits by the interface i. The first reduction sends a request from Cli to the composite, then the request is delegated to Srv by the composite, with a new future f ′ aliased to f . Finally, Cli obtains a direct reference to future f ′ while Srv starts serving the request. The original configuration is of the following form (for the sake of exposition, we only mention internal states of primitives, and interface descriptions are omitted).

Comp[∅, Cli → Prim[{c}, s c 0 ], Cmp → Comp[{i}, Srv → Prim[{s}, s s 0 ], {[This.i, Srv.s]}, s 0 ] {[Cli.c, Cmp.i]}, s ′ 0 ]
5 Tools/Middleware

This section presents component management tools which are necessary to provide adaptation mechanism for distributed components. Proving the correctness of these tools could be a great opportunity for using the formal component model presented in the preceding section. We focus below on two aspects: stopping components, and component reconfiguration; tools for dealing with these two aspects have been implemented in the ProActive/GCM component platform, thus showing already their practical impact.

CommChild + CompositeCall ServeNext + RcvResultPrim 1 ]#Q [ ], [f , v, i 2 ]) f = f f = f NewService {s} pf

Synchronisation and stop

Fractal component lifecycle proposes a stop action, and a stopped state. Existing frameworks for Fractal and GCM sometimes consider recursively stopping a component assembly. However, safely stopping asynchronous components cannot be addressed by stopping procedures proposed so far.

The paper [START_REF] Henrio | Stopping safely hierarchical distributed components: application to gcm[END_REF] proposes an algorithm for stopping a GCM component system. This algorithm recursively stops a component together with all its subcomponents, and reaches a safe state where the component is idle and has no request to serve. This algorithm defines as master component the component that receives initially a stop request. The algorithm is split into two phases. In the first phase the master component marks all the requests it sends. This phase lasts until all the requests, for which the master awaits the results, are marked. In the second phase the master component blocks all the requests it receives (except the marked ones) and the inner components continue processing their requests. When all the components are idle, and all inner components have empty request queues, the components are stopped. Let us only focus here on the request marking mechanism. This mechanism is useful to identify re-entrant requests, and to avoid deadlocks involving such requests. Roughly, the algorithm relies on a propagation of marks: each request sent during the service of a marked request is marked too. The master does not propagate marks to its subcomponents; thus only requests outside the master component are marked.

The formal component model presented in this paper allows, for example, the identification of waiting states, of deadlocks, and of re-entrant requests; it will allow us to reason about such requests, and to prove the correctness of the algorithm sketched above. This model also could verify properties on the algorithm termination and the state of the components when stopped.

Adaptation and reconfiguration

One of the main purposes of stopping a component system is to be able to reconfigure it in order to adapt it to a different execution context, or to provide new functionalities. Indeed, for safely reconfiguring a component system, a component assembly must be in a state where components are stopped, and considered as easily reconfigurable.

In Fractal and GCM, adaptation is performed by dynamic reconfiguration. For adaptivity purposes, the GCM extends the reconfiguration capabilities of Fractal to the non-functional aspects: the control part of a component can be reconfigured dynamically. Moreover, the GCM specifies interfaces for the autonomic management and adaptation of components. Autonomicity is the ability for a component to adapt to situations without relying on the outside. By default, support for some autonomicity concerns are implemented by GCM components with precise non-functional interfaces, but the model being extensible, autonomic behaviour can easily be improved, adapted, and extended.

The formal model presented above enables reasoning on the interplay between the component configuration and the communications. To our mind, it is a crucial tool to prove correctness of autonomic adaptation procedures. Also, in order to ease the development of adaptation procedures, we are developing a scripting reconfiguration language that can be interpreted in a distributed manner, and that can synchronise with communication events or component state.

Conclusions

In this paper we presented a model for asynchronous components. Compared to existing component models and language specifications, our work is focused on the interaction between the programming model and the component model. More precisely, we defined the structure of our component model: it relies on the notion of interfaces, separation of non-functional and functional aspects, hierarchy, and bindings transmitting communications. Then, we presented a coherent model for allowing components to communicate asynchronously through a request/reply mechanism, but also through the use of futures. The semantics of our model is flexible enough to allow for multiple implementations and design choices, like multi-threaded versus mono-threaded components, choice of a future update strategy, choice of one of several local programming models, etc. On the contrary the interplay between hierarchy, asynchrony, and communication is quite precisely defined.

The definition of the component model's semantics is precise enough for a formal specification of this semantics to be written, for example in a theorem prover like Isabelle/HOL. We expect this formal specification to allow us to prove properties on component systems, management protocols for those components, or design choices of the different implementations of the model. Such a framework will provide a consequent step toward safe compositions of components, design of verification frameworks for asynchronous components, and safety of their management procedures.

On the other hand, we have taken care that the component model stays sufficiently abstract to be refined to different execution models. Since our component model abstracts from a concrete execution model it can be instantiated to others. One suitable execution model could be ASP, but also Creol is a candidate that could thereby be extended by hierarchical components. Even in the context of SOA, our model could enable SCA to be extended with a precise semantics for asynchronous communications.

Fig. 2 .

 2 Fig. 1. A GCM component

Fig. 3 .

 3 Fig. 3. Component behaviour

  The set of subcomponents of a composite is a mapping from component names to components: SubCp ::= [N → C] i∈1..n . The subcomponent named N of the composite component Comp[itfs, subCp, bindings, CompState] is denoted subCp[N ], and subCp[N → C] denotes a new set of subcomponents where C is the new component associated to the name N .

Fig. 6 .

 6 Fig. 6. Component Communications

  f, v, i2]) [N.i1,N .i2] ∈ bindings

Fig. 7 .

 7 Fig. 7. Subcomponents communicate

  Figure 6 illustrates the different kinds of communications expressed by the four last rules.

Fig. 8 .

 8 Fig. 8. Semantics of the component composition

  i, Srv.s] ∈ bindings [Cli.c, Cmp.i] ∈ bindings

1 Fig. 11 .

 111 Fig. 11. Example of a Reduction (Hierarchy not mentioned)

Table 1 .

 1 Comparison of component models

	Component	Hierarchy Distribution	Concurrency	Communication
	Model		Unit
	CCA	no	Application	Unspecified	Synchronous
			dependent
	CCM	yes	Application	Unspecified	Synchronous or
			dependent		Asynchronous
	SCA	yes	Unspecified	Unspecified	Call-and-return
					messages
	ASP-	yes	Active Object Monothreaded	Asynchronous,
	component			Active Objects	implicit futures
	Creol	no	Object	Multi-threaded	Asynchronous,
				Active Objects	explicit futures
	Fractal(Julia)	yes	Unspecified	Multi-threaded	Synchronous
				Components
	GCM	yes	Primitive	Unspecified	Request-Reply
			Component		Paradigm
	GCM	yes	Primitive	Unique control thread	Asynchronous,
	(ProActive)		Component	per component	implicit futures

  is either a primitive or a composite, each one has a state and a set of interfaces, a composite has additionally bindings and subcomponents (subCp): Prim[itfs, PrimState], Comp[itfs, subCp, bindings, CompState]. Enqueue(C, R) enqueues a request R in the request queue of the component C. States Each state (PrimState, CompState) is a record containing a queue, and a list of computed results (results); additionally a primitive component state (PrimState) contains an internal state (intState), and a behaviour (behaviour).

  Hierarchy: this rule is a compositionality rule; it expresses that if a subcomponent subCp[N ] reduces in isolation to a component C then it does so as well in the context of a component hierarchy -given by updating SubCp with SubCp[N → C] in the context Comp[itfs, SubCp, bindings, s]. RcvResultComp: this rule is very similar to the RcvResultPrim rule for primitive components. However, this one is simpler because the composite component does not have any internal state; only the request queue and the result list are updated by the received result. CommBrothers, illustrated by Figure 7: a subcomponent N can pass a call to subcomponent N ′ inside the set of subcomponents subComp of a composite component. The respective client interface of N , on which the call was emitted -N.i 1 -must be bound to the interface i 2 of the destination component -N ′ .i 2 -this binding must be stored in bindings. The call parameters f, vparameterised in the request emission relation -are passed to interface i 2 of subcomponent N ′ . The operator Enqueue denotes that the request [f, v, i 2 ] is properly added onto the request list of subcomponent N ′ . N is reduced simultaneously, sending a request. CommParent, illustrated by Figure 9: if a subcomponent -a child -N of a composite component utters a request i 1 , f, v to its parent component, then -similar to the previous rule -N is reduced simultaneously as it sends a request, and the request is added to the composite component's request

	Hierarchy
	S ⊢ subCp[N ] →R C
	S ⊢ Comp[itfs, subCp, bindings, s] →R Comp[itfs, (subCp[N → C]), bindings, s]

To be precise, only futures are passed by reference, because their value will be finally transmitted by a copy semantics.

In the future, we want to study how the behaviour of the composite component could be changed safely but this is not the purpose of this paper.

Prototype specification available at www.inria.fr/oasis/Ludovic.Henrio/misc


Eric Venot

Sylvain Dechaumet

Blanche Guillon

Mikaïl Berdi

Sophie Cholet

Ghita Tajeddine

Manon Mutaner

Aline Meirhaeghe

Barbara Heude

Blandine De Lauzon-Guillain

Influence of FUT2/FUT3 polymorphism on human breastmilk oligosaccharide composition in the EDEN mother-child cohort

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Material & Methods

Results

•

•

  Deeper insight into different HMOs clusters (HMOs mother profiling?) • Assessment of influence of environmental factors on milk HMO composition & association between HMO composition and health outcomes in childhood What's next? • Association between FUT2/FUT3 polymorphisms and several HMOs (2'FL, LNFP I, LNFP II...) already described in the literature (Lefebvre et al., 2020) found back in this study. • But new potential HMOs with higher or similar association levels with FUT2/FUT3 polymorphisms were also identified. Influence of FUT2/FUT3 polymorphism on human breastmilk oligosaccharide composition in the EDEN mother-child cohort. Eric Venot 1 , Sylvain Dechaumet 2 , Blanche Guillon 1 , Mikaïl Berdi 1 , Sophie Cholet 2 , Ghita Tajeddine 1 , Manon Mutaner 3 , Aline Meirhaeghe 3 , Barbara Heude 4 , Blandine de Lauzon-Guillain 4 , Etienne Thevenot 2 , François Fenaille 2 , and Karine Adel-Patient 1 1-INRAE: Laboratoire d'Immuno-Allergie Alimentaire (LIAA) 2-CEA: Laboratoire Innovations en spectrométrie de masse pour la santé (early breast milk collected between 1 and 6 days after delivery in the EDEN mother-child cohort between 2003 and 2006. EDEN Early Breast Milk samples Contact: eric.venot@inrae.fr • High impact of FUT2 & FUT3 polymorphisms on HMOs composition • Results for 2 Lefebvre et al. SNPs confirmed and larger list of impacted HMOs identified • Different clusters of HMOs identified The samples were analyzed by Liquid Chromatography coupled to High Resolution Mass Spectrometry (Q-TOF TM , res: 40000, PGC Hypercarb column) • HMO references: -19 commercial standards analyzed -m/z ratios of 8 953 HMO computed in silico based on all possible monosaccharide combinations. • specific in house HMO workflow from mzML files developed with & to detect m/z ratios corresponding to potential HMOs  130 HMOs detected after selection criteria including 18 HMOs annotated based on commercial standard (including 2'FL, LNFP I & LNFP II)

LC-HRMS analysis & HMO workflow

• Maternal genetic predispositions induce HMO synthesis differences (Lefebvre et al., 2020):

2 fucosyltransferase enzymes production depends on mother FUT2 (Secretor) and