Liste des Professeurs

Tables des matières :

Liste Leur association à des manifestations auto-immunes ou inflammatoires (MAI) est connue mais reste mal définie, avec une efficacité fréquente des corticoïdes mais des taux de rechutes ou de cortico-dépendance élevés. Plusieurs travaux suggèrent l'intérêt potentiel de l'azacitidine (AZA) dans la prise en charge de ces MAI, dont l'influence pronostique reste débattue.

Patients et méthodes :

Nous avons réalisé une étude cas-témoins rétrospective mono centrique sur la cohorte de patients porteurs de SMD/LMMC traités par AZA au CHU de Nice entre 2005 et 2019 afin de comparer les caractéristiques épidémiologiques, cliniques et la survie des patients porteurs ou non de MAI associées. Nous avons par ailleurs centré notre travail sur l'influence de l'AZA dans le contrôle des MAI et sur différents facteurs pouvant influencer la survie.

Résultats :

Au sein de la cohorte, 20 patients étaient porteurs de MAI et 110 utilisés comme contrôles, soit une prévalence des MAI de 15% au sein de la cohorte. L'âge moyen était de 69 ans avec une prédominance masculine (60%). Dans la majorité des cas, le diagnostic des MAI était concomitant à celui du SMD/LMMC (55%), récent (20%) ou secondaire (20%) avec un délai moyen de 5.25 mois entre les deux diagnostics. On notait plus d'antécédents de MAI dans le groupe MAI que dans le groupe contrôle (25% vs 5% p=0.013). Au sein des MAI on notait des dermatoses neutrophiliques (n=5, 25%), des vascularites systémiques (n=4, 20%), des MAI spécifiques d'organe (n=4, 20%), des connectivites (n=3, 15%), des rhumatismes inflammatoires chroniques (n=3, 15%), une cytopénie auto-immune (n=1, 5%).

La classification OMS des SMD/LMMC était statistiquement différente au diagnostic (p<0.001) avec dans le groupe MAI, plus de LMMC1 (35% vs 9.1%) ou de SMD avec dysplasie multilignée (15% vs 3.6%) que dans le groupe témoin qui se présentait plus souvent sous la forme d'AREB2 (45% vs 10%).

On observait une différence statistique sur le score IPSS entre les deux groupes à l'introduction de l'AZA avec plus de patients à faible risque (Int-1 et low) dans le groupe MAI que dans le groupe témoin (48% vs 19% respectivement, p<0.001).

Les histoires antérieures d'évènements cardiovasculaires ou de cancers étaient comparables entre les deux groupes, ainsi que la survenue d'infections nécessitant une hospitalisation après le diagnostic de SMD/LMMC. Concernant les MAI, avant introduction de l'AZA, 90% des patients avaient reçu une première ligne de traitement, qui comportait des corticoïdes chez 75% d'entre eux. Une seconde ligne était nécessaire dans 30% des cas, une troisième dans 10% des cas et une quatrième ligne dans 5% des cas.

A l'introduction de l'AZA, 31.5% des patients restaient cortico-dépendants avec une posologie médiane de 43.3 mg/jour de prednisone dans ce sous-groupe. Au sein des patients n'ayant pas atteint une réponse complète, on observait une amélioration de la réponse dans 81% des cas après traitement par trois à six cycles d'AZA. Sur l'ensemble des patients atteints de MAI on observait une amélioration de la réponse dans 47% des cas et une diminution globale du taux de cortico-dépendance à 5.5% après introduction de l'AZA.

La réponse des SMD/LMMC à l'AZA était comparable entre les deux groupes et n'était pas corrélée à la réponse des MAI.

Aucune différence de survie globale n'était observée entre les deux groupes (survie médiane de 20.6 mois). La survie était statistiquement modifiée par la catégorie de risque IPSS-R et par la survenue d'une transformation en LAM. L'existence d'un antécédent de cancer était également associée à une survie altérée (17.4 vs 28.5 mois, p=0.029). La survenue d'infection nécessitant une hospitalisation après le diagnostic de SMD/LMMC ne semblait pas influer la survie globale.

Conclusion :

L'AZA semble apporter un bénéfice en termes de contrôle des MAI et de cortico-dépendance chez des patients porteurs de SMD/LMMC majoritairement à risque élevés. L'association d'une MAI ne semble pas influencer la survie globale. Le pronostic apparait principalement relié aux caractéristiques intrinsèques des maladies hématologiques sous-jacentes et aux fragilités des patients.

Introduction:

Myelodysplastic syndromes (MDS) and chronic myelomonocytic leukaemia (CMML) are chronic myeloid stem cell neoplasms characterized by an impairment of hematopoiesis with a variable risk of clonal progression into acute myeloid leukemia (AML) [START_REF] Arber | The 2016 revision to the World Health Organization classification of myeloid neoplasms and acute leukemia[END_REF]. The frequency of auto-immune or inflammatory manifestations (AIMs) is higher in MDS/CMML patients in comparison with the general population or with lymphoid malignancies (2,3) ranging from 10 to 30% of patients [START_REF] Ustwani | Myelodysplastic syndromes and autoimmune diseases-Case series and review of literature[END_REF]. Accumulation of genetic abnormalities within bone marrow progenitors is known to be responsible for local immune dysregulation that could be linked by many pathways to AIMs (5) [START_REF] Grignano | Autoimmune manifestations associated with myelodysplastic syndromes[END_REF]. Yet, the pathophysiological link between these conditions is not univocal as illustrated by the wide spectrum of observed AIMs and the frequency of undefined or atypical manifestations, compared to traditional AIMs. Furthermore, therapeutic management of MDS/CMML related AIMs is challenging. Despite an important response rate with steroids, most patients require the use of a second line therapy.

Treatment strategies in steroid-dependent or refractory patients remain uncodified. Efficacy of azacitidine (AZA) in these patients is suggested in various case reports and small retrospective series [START_REF] Fraison | Efficacy of Azacitidine in autoimmune and inflammatory disorders associated with myelodysplastic syndromes and chronic myelomonocytic leukemia[END_REF].

Moreover, patient outcome with MDS/CMML related AIMs remains controversial [START_REF] Seguier | Autoimmune diseases in myelodysplastic syndrome favors patients survival: A case control study and literature review[END_REF].

We conducted a single-center retrospective case control study in order to describe the clinical features, outcomes and treatment strategies in our cohort of AZA treated high risk MDS/CMML patients with or without AIMs. We focused our work on AIMs response to AZA and potential factors that could influence outcomes in each group such as infections, past cardiovascular events, or history of cancer.

Patients and methods:

Medical records of patients treated with AZA for myeloid neoplasms according to international recommendations in the Nice University Hospital between 2005 and 2019 were evaluated.

Patients were included if age ≥ 18 years with a diagnosis of MDS or CMML confirmed by a bone marrow aspiration. Patients with an initial diagnosis other than MDS or CMML, or those referred by other medical centers that had subsequently too much missing data were excluded.

MDS and CMML diagnosis were classified according to WHO 2016 criteria (1) at diagnosis and at AZA onset. MDS and CMML were stratified by IPSS [START_REF] Greenberg | International scoring system for evaluating prognosis in myelodysplastic syndromes[END_REF] and IPSS-R [START_REF] Greenberg | Revised International Prognostic Scoring System for Myelodysplastic Syndromes[END_REF] prognosis scoring systems at AZA onset. The time of MDS diagnosis retained was the date of bone marrow aspiration. We also collected laboratory data and karyotypes when available, number of prior hematologic treatments to AZA and use of bone marrow transplantation. AZA response was assessed for MDS and CMML using the International Working Group 2006 criteria [START_REF] Cheson | Clinical application and proposal for modification of the International Working Group (IWG) response criteria in myelodysplasia[END_REF].

Autoimmune and inflammatory manifestations (AIMs) were recorded based on the medical records and classified according to expert review and usual international classification criteria such as the Chapel Hill classification for systemic vasculitis [START_REF] Jennette | Revised International Chapel Hill Consensus Conference Nomenclature of Vasculitides[END_REF], Michet criteria for relapsing polychondritis [START_REF] Michet | Relapsing polychondritis. Survival and predictive role of early disease manifestations[END_REF], or Von den Driesch criteria for Sweet syndrome [START_REF]Sweet's syndrome (acute febrile neutrophilic dermatosis)[END_REF]. Hypothyroidism or isolated biological anomalies were not considered as clinical AIMs. When complete classification criteria were not met, AIMs diagnosis had to be confirmed by an expert and was considered incomplete.

AIMs were grouped as follows: systemic vasculitis, connective tissue diseases (CTD), inflammatory arthritis, neutrophilic dermatosis, immune cytopenia or organ limited immunologic disease. We recorded clinical manifestations, organ involvement, immunological AIMs response to both specific treatments and AZA was assessed based on clinical, biological and radiological evaluations and submitted to expert review. Complete response was defined as the disappearance of clinical features and normalization of biological and immunological parameters present at baseline. Partial response was defined as a ≥ 50% improvement of clinical, biological and immunological parameters. Failure was defined either as an < 50% improvement, a worsening of clinical, biological, immunological and imagery features under treatment or a flare with a need for intensification in AIMs treatment. Steroid dependence was defined as a prednisone equivalent amount > 20 mg/day during at least 2 months without worsening. Patients with no AIMs were used as a control group.

In addition, we collected information about prior medical history of all patients before MDS/CMML diagnosis. We recorded cardiovascular risk factors (hypertension, dyslipidemia, diabetes, obesity, tobacco use), occurrence of major cardiovascular events (peripheral artery disease, coronary artery disease, vascular chronic kidney disease or strokes). Was also recorded history of cancer and use of chemotherapy, radiotherapy or surgery.

Finally, we compared the propensity of patients to develop infections after MDS/CMML diagnosis and their potential influence on overall survival. Every infection related hospitalization in the Nice University hospital was recorded as well as its duration. When available, infectious cause of death was recorded.

Descriptive statistics included the mean, median and standard deviation (SD) for continuous variables and frequencies (percentages) for categorical variables. A chi-square test or Fisher's exact test was used to compare categorical variables, and if normality was verified, Student's t-test was used to compare continuous variables. Survival was calculated from the time of MDS/CMLL diagnosis and compared in MDS/CMML patients with and without AIMs. To account for missing data, results were expressed as observed data (missing data were not replaced). Survivals were estimated according to Kaplan-Meier method and compared by the log-rank test (at the 5% level). A P-value <5% was considered significant. Statistical analyses were performed using SAS version 9.4 (SAS Institute, Cary, NC, USA).

Results:

Between 2005 and 2019, 385 patients were treated by AZA in Nice University Hospital. Onehundred and ninety-seven had an initial diagnosis other than MDS or CMML and were excluded. Among the remaining patients, 58 had been referred by other centers and were excluded due to missing clinical data. One-hundred and thirty patients were included in the analysis. Seven patients had a past medical history of inflammatory or auto-immune disease with no clinical nor biological activity in the previous years and were not considered as active MDS/CMML related AIMs, thus excluded of AIMs group (Figure 1). These seven patients had presented psoriasis n=1, Behcet's disease n=1, psoriatic rheumatism n=1, rheumatoid arthritis n=2, vitiligo n=1, and polymyalgia rheumatica n=1.

AIMs characteristics:

Out of the 130 patients with MDS/CMML, 20 presented an active AIM (15%).

Baseline demographic characteristics were comparable between AIMs and control groups (Table 1) with a mean age at diagnosis of 68.0 years in AIMs group and 69.1 years in the control group (SD 9.25 and 9.79 respectively, p=0.53). Male to female ratio was strictly identical in the two groups with 60% males (p=1).

Mean delay between AIMs and MDS/CMML diagnosis was 5.25 months (SD 29.9). Four patients had recent AIM diagnosis (20%), 11 a concomitant diagnosis (55%), 4 a secondary diagnosis (20%) and one patient had an old diagnosis of AIM (still active psoriasis, with a severe relapse at MDS diagnosis). No association was found between diagnosis temporal association and AIMs subtype (p=0.43).

Among AIMs patients, five (25%) had a prior history of AIM (Sweet dermatosis n=1, Kikuchi disease n=1, rheumatoid arthritis n=1, auto-immune thyroiditis n=1, severe psoriasis n=1,).

Among them, one patient experienced a relapse of AIM concomitant to MDS onset (severe psoriasis). Past history of AIM was significantly lower in the control group (n=7, 6,4%, p=0.013). In the AIMs group, five patients had received a prior disease modifying antirheumatic drug (DMARD) treatment (Methotrexate n=4, Leflunomide n=1). No immunosuppressive therapy or biologics was recorded.

AIMs subtypes were classified as neutrophilic dermatosis n=5 (25%), systemic vasculitis n=4 (20%), organ-limited AIMs n=4 (20%), connective tissue disease n=3 (15%), inflammatory arthritis n=3 (15%) and immune cytopenia n=1 (5%). Three patients (15%) had incomplete classification criteria (Behcet like syndrome, giant cell arteritis, relapsing polychondritis). No undefined AIM was recorded. AIMs diagnosis are detailed in Table 2.

At AIMs diagnosis 17 patients (85%) presented with general symptoms, including fever n=8 (40%), weight loss n=8 (40%), anorexia n=12 (60%) or asthenia n=15 (75%). Furthermore, the main clinical manifestations in AIMs patients involved skin (60%), joints (45%), vessels (30%) (vasculitis in 20%, Raynaud syndrome in one patient (5%) and extensive veinous thrombosis associated with anti-phospholipid syndrome (APLS) and livedo in one patient (5%)), lungs (20%), digestive tract (20%) and kidneys (10%). No specific neurologic or cardiac involvement were observed.

Eleven patients (55%) presented with a non-infectious inflammatory syndrome (defined as a C Reactive protein (CRP) > 30 mg/dL), with a mean CRP level of 146 mg/dL (SD 97.8) at AIMs diagnosis. Presence of an inflammatory syndrome was more frequently observed in systemic vasculitis and neutrophilic dermatosis (p=0.013). Immunologic abnormalities were diverse: positive anti-nuclear factors (n=5), rheumatoid factor (n=5), complements anomalies (n=2), 12 weeks persistent APL-antibodies (n=1), and anti-CCP (n=1). No native DNA antibodies, cryoglobulinemia or ANCA positivity was observed. At least one biopsy was performed in fourteen patients (skin = 11, kidney = 2, muscle = 1) with informative results.

Hematologic characteristics:

Hematologic characteristics of each group are detailed in Table 1. MDS/CMML WHO classification at diagnosis were significantly different between the two groups (p<0.001). AIMs patients presented more frequently with CMML1 (35% vs 9.1%) or MDS with MLD (15% vs 3.6%). Controls more frequently presented as RAEB2 (45% vs 10%). RAEB1 repartition between the two groups was similar (30% vs 29%). No correlation was found between WHO classification and AIMs subtypes. Number of AZA cycles or prior bone marrow transplantation rates were similar between both groups.

At AZA onset, IPSS score was significantly different between the two groups (p<0.001). In AIMs group, 48% of patients were low or intermediary-1 (Int-1) IPSS score versus 19% in control group. We observed a trend for IPSS-R (p=0.069) with more low and very-low IPSS-R categories in the AIMs group. Consistently, bone marrow blasts were higher in the control group (13.9 (±8.58) vs 9.89 (±7.58), p<0.01) whereas monosomal karyotypes and IPSS-R cytogenetic prognosis were comparable between the two groups (p=0.43 and 0.55 respectively). AML transformation rates were similar in both groups: 60% in AIMs group and 53% in control group (p=0.55).

Cardiovascular and prior cancer:

Classical cardiovascular risk factors and history of major cardiovascular event repartition were homogenous between the two groups. Similarly, prior cancer, chemotherapy, radiotherapy and surgery rates were not statistically different in the two groups (Table 3).

Hospitalizations related to infections:

Percentage of patients who were hospitalized for at least one infection after MDS/CMML diagnosis was similar, 63% in the control group versus 55% in the AIMs group (p=0.55). The mean number of hospitalizations, cumulative duration of hospitalizations, and death attributed to infections were similar in the two groups (Table 3).

AIMs

AIMS response to AZA:

One patient developed Sweet syndrome during AZA treatment that resolved with steroids alone and was not included in the analysis of AIMs response to AZA. Patients data are detailed in Table 4.

At AZA onset, eleven patients (58%) did not achieved AIMs complete response. Six had achieved a partial response (two with steroid dependence). Five patients experienced failure in AIMs treatments (Behcet like syndrome, sweet syndrome, pyoderma gangrenosum, dermatomyositis and leucocytoclasic vasculitis) with four of them dependent to high dose steroids (30-70 mg/day). Eight patients had achieved a complete response with no steroiddependence.

After 3 AZA cycles, each of the five patients who experienced failure in AIMs treatment were in partial remission and 4 patients already in partial remission experienced a complete remission.

At cycle 6, five patients had stopped AZA for toxicity (n=2), progression of MDS/CMML and treatment switch (n=2) or death (n=1). Two of the three remaining patients that initially failed in AIMs response maintained partial remission and one achieved complete remission.

Finally, among all patients, 9/19 (47%) showed an improvement with AZA. Among the patients that were not in remission at AZA onset, 9/11 (82%) showed an improvement in AIMs response.

Steroid-dependence after AZA:

At AZA onset, a total of 6/19 patients were steroid dependent (31,5%). Mean prednisone dosage in steroid dependent patients was 43,3 mg/d (SD 22,5) versus 1,43 mg/d (SD 2,3) in non-steroid dependent patients (p<0.001). In steroid-dependent patients, mean amount of daily prednisone decreased from 43,3 mg/d to 21,83 mg/d at cycle 3 (n=6) and to 10,2 mg/d at cycle 6 (n=5) with only one patient (5,5%) staying dependent to steroids. AZA allowed an improvement in AIMs response in all steroid dependent patients.

MDS/CMML response to AZA:

According to IWG MDS/CMML criteria, no statistical difference in MDS/CMML response to AZA was observed between the two groups (p=0.69). In the control group and the AIMs group respectively, complete response was observed in 26% and 10%, stable disease in 25% and 35%, partial response in 7.3% and 10% and marrow complete response without hematologic improvement in 10% and 10% respectively. Other patients experienced progression. Among the six AIMs steroid dependent patients at AZA onset, one patient achieved a prolonged complete response, one patient a marrow complete response, three patients a stable disease, and one patient experienced progression. No correlation was found between AIMs response and MDS/CMML response to AZA.

Survival:

Median overall survival (OS) in the entire cohort was evaluated at 20,6 months (SD 3,7). We did not observe a significant difference in OS between AIMs and control group. Median OS in AIMs group was 28,7 months (SD 5,0) and 20,3 months (SD1,9) in controls (p=0,517). We did not observe any difference in OS among patients who presented at least one infection related hospitalization in comparison with those who did not (p=0,571). OS in the entire cohort was significantly altered in patients with prior cancer, with an OS of 17,4 months and 28,5 months in patients with no prior cancer (p=0,029). The influence of a history of major cardio-vascular event on OS was at the limit of statistical significance (p=0,07). Hematological characteristics such as IPPS-R and AML transformation were found to influence OS in the entire cohort (p=0,003 and 0,012 respectively), whereas surprisingly, IPSS was at the limit of statistical significance (p=0,058) (Figure 2).

Discussion:

Although AIMs association with MDS/CMML is well established, treatment strategies in steroid dependent or refractory patients remains challenging. To our knowledge, this work is the first to focus on AZA efficacy in AIMs management in a "real-life" cohort of high-risk MDS/CMML.

In our group of MDS/CMML related AIMs, 58% of patients did not achieve a complete response with traditional AIMs treatments before AZA (n=11). Among them, 82% showed an improvement after AZA introduction (n=9). Among all AIMs patients, 47% showed an improvement in AIMs response, with a remarkable decrease in steroid dependence rate (31,5% before and 5% after AZA). These results are concordant with those observed by Fraison et al. in a cohort of 22 MDS/CMML related AIMs in whom AZA improved clinical signs of AIMs in 86% of the cases and permitted a decrease in steroid dosage in 64% [START_REF] Fraison | Efficacy of Azacitidine in autoimmune and inflammatory disorders associated with myelodysplastic syndromes and chronic myelomonocytic leukemia[END_REF]. Several case reports are consistent with a positive influence of AZA in AIMs management [START_REF] Mekinian | Systemic inflammatory and autoimmune manifestations associated with myelodysplastic syndromes and chronic myelomonocytic leukaemia: a French multicentre retrospective study[END_REF][START_REF] Frietsch | Paraneoplastic inflammation in myelodysplastic syndrome or bone marrow failure: case series with focus on 5-azacytidine and literature review[END_REF][START_REF] Pilorge | The autoimmune manifestations associated with myelodysplastic syndrome respond to 5-azacytidine: a report on three cases: Correspondence[END_REF][START_REF] Raj | Complete response of deep neutrophilic dermatosis associated with myelodysplastic syndrome to 5-azacytidine[END_REF]. Yet, larger prospective trials are needed to confirm this hypothesis.

We did not identify any difference neither in overall survival, nor in AML transformation between the two groups as already underlined in several studies [START_REF] Seguier | Autoimmune diseases in myelodysplastic syndrome favors patients survival: A case control study and literature review[END_REF], with a similar response to AZA. Classical hematologic prognosis factors such as IPSS, IPSS-R and AML transformation had an influence on patients' outcomes. Surprisingly, in the whole cohort, survival was not influenced by the occurrence of infectious related hospitalizations, maybe thanks to the effectiveness of modern antimicrobial strategies in immunocompromised hosts such as MDS/CMML or AIMs patients.

In addition, infectious related hospitalization rates and durations were similar in both groups, implying that infection rates and intensity did not seem affected by immunosuppressive or steroid treatments received by AIMs patients. This could be explained by the aggressiveness of hematologic malignancies themselves in higher risk MDS/CMML, leading to an equivalent level of immunosuppression in which AIMs themselves or treatments may have a lower impact.

Prior cancer or cardiovascular event were related to a worse outcome, highlighting the fact that comorbidities and past medical history may have a greater influence on survival than AIMs or treatment related complications. Therapy related MDS/CMML are known to be associated to poorer karyotypes, treatment response and outcome [START_REF] Smith | Clinicalcytogenetic associations in 306 patients with therapy-related myelodysplasia and myeloid leukemia: the University of Chicago series[END_REF][START_REF] Morton | Association of Chemotherapy for Solid Tumors With Development of Therapy-Related Myelodysplastic Syndrome or Acute Myeloid Leukemia in the Modern Era[END_REF]. We did not exclude patients that had priorly received genotoxic therapies, to stay close to a "real-life" cohort. The repartition of therapy related MDS/CMML was similar in both groups as prior cancer, chemotherapy or radiotherapy use was comparable in each group.

In our study, CMML-1, RAEB-1 and MDS-MLD, were the most frequent WHO subtypes associated with AIMs at MDS/CMML diagnosis, consistently with Mekinian et al. [START_REF] Mekinian | Systemic inflammatory and autoimmune manifestations associated with myelodysplastic syndromes and chronic myelomonocytic leukaemia: a French multicentre retrospective study[END_REF]. AIMs patients also presented with more favorable prognosis factors at AZA introduction (WHO subtypes and IPSS) supporting the idea that in a real-life management, AIMs could have favored an earlier introduction of AZA. On the other hand, AIMs clinical manifestations may have favored earlier medical explorations and diagnosis of MDS/CMML in some cases. Yet, more favorable IPSS in AIMs group at AZA onset and the absence of difference in OS between the two groups may underline a lack of power from our study.

Consistently with published data, no correlation was found between timing of AIMs emergence and AIMs subtype or WHO classification. In the whole AIMs group, main clinical manifestations at diagnosis were consistent with literature data, with a predominance of general symptoms with fever, skin and joints involvement [START_REF] Grignano | Autoimmune manifestations associated with myelodysplastic syndromes[END_REF][START_REF] Seguier | Autoimmune diseases in myelodysplastic syndrome favors patients survival: A case control study and literature review[END_REF].

A 77 year-old male presented with franc deterioration of general status, fever, arthralgias, mouth and genital sores and diarrhea related to terminal ileitis. Colonoscopy and histopathology were non consistent with Crohn's disease. Karyotype showed trisomy 8 that lead us to diagnose a Behcet-like syndrome as previously described in literature with typical digestive involvement [START_REF] Toyonaga | Refractoriness of Intestinal Behçet's Disease with Myelodysplastic Syndrome Involving Trisomy 8 to Medical Therapies -Our Case Experience and Review of the Literature[END_REF][START_REF] Wesner | Gastrointestinal Behcet's-like disease with myelodysplastic neoplasms with trisomy 8: a French case series and literature review[END_REF][START_REF] Wesner | Inflammatory disorders associated with trisomy 8-myelodysplastic syndromes: French retrospective casecontrol study[END_REF]. Interestingly, we observed two cases of MDS/CMML related nephrotic syndromes, one extra-membranous glomerulonephritis (EMG) and one membranoproliferative glomerulonephritis (MPGN). MPGN patient met partial response with steroid dependence and anti-proteinuric treatment and achieved complete response after AZA treatment. Association between MDS/CMML and glomerulonephritis seems rare but described in case reports [START_REF] El Mehdi | Glomérulonéphrite extra-membraneuse et syndrome myélodysplasique: une association rare[END_REF]. EMG patient experienced a complete response with exclusive antiproteinuric treatment before AZA introduction, raising the doubt of a fortuitous association.

To assess the efficacy of AZA towards AIMs, we included patients that had received AZA treatment for MDS/CMML treatment. This made our recruitment different from those found in other works about MDS/CMML related AIMs. For comparison, patients with Int-2 or High IPSS represented 71% of our cohort, but only 18% in Seguier et al. and 26% in Mekinian et al.

cohorts [START_REF] Seguier | Autoimmune diseases in myelodysplastic syndrome favors patients survival: A case control study and literature review[END_REF][START_REF] Mekinian | Systemic inflammatory and autoimmune manifestations associated with myelodysplastic syndromes and chronic myelomonocytic leukaemia: a French multicentre retrospective study[END_REF]. Fraison et al. focused on 22 MDS/CMML related AIMs patients treated by AZA but with no control group, Int-2 and High IPSS represented as low as 50% of their patients [START_REF] Fraison | Efficacy of Azacitidine in autoimmune and inflammatory disorders associated with myelodysplastic syndromes and chronic myelomonocytic leukemia[END_REF].

In our cohort, both AIMs and control group presented with a male predominance and with a similar age repartition. These findings contrast with other works where AIMs patients appeared younger [START_REF] Mekinian | Systemic inflammatory and autoimmune manifestations associated with myelodysplastic syndromes and chronic myelomonocytic leukaemia: a French multicentre retrospective study[END_REF][START_REF] Giannouli | Autoimmune phenomena in myelodysplastic syndromes: a 4-yr prospective study[END_REF] and without male predominance [START_REF] Giannouli | Autoimmune phenomena in myelodysplastic syndromes: a 4-yr prospective study[END_REF][START_REF] De Hollanda | Systemic and immune manifestations in myelodysplasia: A multicenter retrospective study[END_REF] as usually known in MDS [START_REF] Adès | Myelodysplastic syndromes[END_REF]. In Fraison's cohort, a male predominance was noted (73%), consistently with our results, suggesting that in higher risk MDS/CMML, AIMs may prevail in men [START_REF] Fraison | Efficacy of Azacitidine in autoimmune and inflammatory disorders associated with myelodysplastic syndromes and chronic myelomonocytic leukemia[END_REF].

The distribution of AIMs subtypes was different from that observed by Mekinian et al. and Seguier et al. [START_REF] Seguier | Autoimmune diseases in myelodysplastic syndrome favors patients survival: A case control study and literature review[END_REF][START_REF] Mekinian | Systemic inflammatory and autoimmune manifestations associated with myelodysplastic syndromes and chronic myelomonocytic leukaemia: a French multicentre retrospective study[END_REF]. We observed a higher prevalence of neutrophilic dermatosis (25% compared to 10% and 11% respectively). Consistently, in the largest retrospective cohort by Mekinian et al, neutrophilic dermatosis was statistically associated with higher risk MDS/CMML. Conversely, we observed lower rates of connective tissue diseases and inflammatory arthritis that were associated to lower risk MDS/CMML, under-represented in our cohort.

We observed only one case of immune cytopenia, whereas Seguier et al. observed a prevalence of 15% in their 81 patients' cohort. This difference could underline the fact that immune cytopenias may prevail in association with low risk MDS/CMML and may be more challenging to detect in higher risk patients with forefront major cytopenias. Systemic vasculitis repartition among MDS/CMML varies from 4-60% of AIMs subtypes according to different series [START_REF] Seguier | Autoimmune diseases in myelodysplastic syndrome favors patients survival: A case control study and literature review[END_REF] and are known to be associated to CMML [START_REF] Mekinian | Systemic inflammatory and autoimmune manifestations associated with myelodysplastic syndromes and chronic myelomonocytic leukaemia: a French multicentre retrospective study[END_REF][START_REF] Grignano | Autoimmune and inflammatory diseases associated with chronic myelomonocytic leukemia: A series of 26 cases and literature review[END_REF]. Vasculitis represented 20% of AIMs in our cohort and CMML were highly represented but a lack of power may explain the absence of statistical association between AIMs subtypes and MDS/CMML WHO classification or risk groups.

In their literature review, Seguier et al. underlined the important discrepancies in AIMs subtype repartition among different works. The combination of an important heterogeneity in patient phenotypes, AIMs subtype classifications, inclusion criteria and the retrospective methods used in most works may induce an important variability in AIMs identification.

In our cohort, no undefined AIMs were retained, due to the difficulty in retrospectively ruling out differential diagnosis to undefined clinical manifestations and the will to include only patients with authentical AIMs.

As previously underlined, the retrospective design and the small number of patients constitute the principal weaknesses of our work. Nevertheless, our study is the first to compare a reallife cohort of predominantly high risk MDS/CMML AZA treated patients with or without AIMs.

Conclusion

AIMs are commonly associated to high-risk MDS/CMML with various presentations. Although the presence of AIMs does not impact neither OS nor progression to AML, their management is crucial to improve patients' quality of life and to avoid serious or fatal complications of AIMs.

Increasing evidence suggests that MDS/CMML specific therapies such as AZA, based on their immunomodulatory effect, may be effective in treating AIMs and sparing steroids concomitantly to MDS/CMML disease control. Larger and prospective studies are needed to address the place of AZA and to help physicians to choose the best therapeutic strategy.

Tables and figures:

22 Figure 1 :

 221 Figure 1 : Inclusion flow chart ........................................................................................................

Table 1 :

 1 Baseline demographical and hematological characteristics in AIMS and control groups. ....................................................................................................................................................... Table 2: AIMs diagnosis and classification.................................................................................... Table 3: Comparative data about cardiovascular events, prior cancer and infectious complications in both groups .........................................................................................................

Figure 2 :

 2 Figure 2: Overall survival from MDS/CMML diagnosis according to different parameters: .......... Table 4: AIMs group patients characteristics before and after AZA treatment ............................. References : .............................................................................................................28

  abnormalities at AIMs diagnosis and each specific AIMs treatment received before MDS/CMML diagnosis and during follow up. Patients with AIMs diagnosed more than 5 years before MDS/CMML and who had no clinical nor biological activity for years and during follow-up were not considered as MDS/CMML associated AIMs. Temporal association between active AIMs and MDS/CMML diagnosis were classified as : 1) old (AIMs diagnosed > 5 years before and still active at the diagnosis of MDS/CMML), 2) recent (AIMs diagnosed < 5 years before MDS/CMML), 3) concomitant (AIMs diagnosed 3 months before or after MDS/CMML) or 4) secondary (AIMs diagnosed > 3 months after MDS/CMML).

  treatments before AZA onset: Eighteen patients had received a specific AIMs treatment (90%) before AZA onset. A patient with extra-membranous glomerulonephritis was treated only by anti proteinuric treatment and achieved complete remission without AIM treatment except AZA. A patient developed a Sweet syndrome after AZA introduction. Mean number of treatments used was 1.40 (SD 1.35). As a first AIMs treatment line, fourteen patients received steroids (70%), alone n=9 (45%) or in combination n=5 (25%) with Cyclophosphamide (n=1), Methotrexate (n=2), Leflunomide (n=1), or Etanercept (n=1). Four patients received other AIMs treatments with no systemic steroids: Colchicine (n=1), Salazopyrine (n=1), topical steroids alone (n=2). One patient with APL syndrome received an adjuvant curative heparinotherapy. Among all AIMs patients, six (30%) required a second line treatment including steroids in 5, alone in 1 patient and combined in 4 patients, with Methotrexate n=2, Azathioprine n=1, plasma exchanges n=1. Two patients (10%) required a third line treatment, always combined with steroids (Rituximab n=1, Polyvalent immunoglobulins n=1). One patient with severe relapsing dermatomyositis required a fourth line treatment by Cyclophosphamide.

Figure 1 :

 1 Figure 1 : Inclusion flow chart MDS: myelodysplastic syndroms, CMML : chronic myelomonocytic leukaemia, AML : acute myeloïd leukaemia, MPS : myeloproliferative syndrom, AIMs : Autoimmune or inflammatory manifestations

Table 1 : Baseline demographical and hematological characteristics in AIMS and control groups.

 1

	Controls, n=110 (%) AIMs, n= 20 (%)	p

Table 2 : AIMs diagnosis and classification

 2

	Controls n=110 (%)	AIMS n=20 (%)	p

The (+) sign indicates complete classification criteria, (-) indicates incomplete classification criteria AIM: auto immune or inflammatory manifestation, RS3PO:

Remitting seronegative symmetrical synovitis with pitting oedema.

Table 3 : Comparative data about cardiovascular events, prior cancer and infectious complications in both groups

 3

AIMs: auto immune or inflammatory manifestations, CV: cardiovascular, Nb: number.

Figure 2: Overall survival from MDS/CMML diagnosis according to different parameters:

	2A N, Age at MDS/CMML diagnosis, gender	WHO at AZA onset	IPSS	AIM subtype	AIM diagnosis	Temporal association	2B Anterior AIMs treatments	Best IWG response	Steroid dependence at AZA onset	AIM status at AZA onset	Prednisone dose at AZA onset (mg/j)	AIM status at AZA cycle 3	Steroid dependence after cycle 3	Prednisone dose after cycle 3 (mg/d)	AIM status at AZA cycle 6	Steroid dependence after cycle 6 (yes/no)	Prednisone dose after cycle 6 (mg/d)
	1. 53(F)	RAEB2	Int-1 CTD	Myositis	Concomitant	Steroids/MTX/Pex IgIV/CYC	Marrow CR	1		F	60	PR	1	20	PR	1	20
	2. 54(F)	RAEB1	Int-1 ND	PG	Concomitant Steroids	Stable D	1		F	70	PR	0	30	CR	0	10
	3. 58(F)	CMML2	Int-2 ND	Sweet	Secondary	Steroids	Stable D	1		F	30	PR	1	25	(Toxicity)
	4. 59(M)	AML MLD	High Vasc	Leuc vasc Concomitant Steroids	Stable D	1		F	60	PR	1	45	PR	0	17,5
	5. 72(M)	RAEB1	Low CTD	APLS	Concomitant Steroids	CR	1		PR	20	CR	0	10	CR	0	7
	6. 75(M)	RAEB1	Low OL	MPGN	Concomitant Steroids	Progression 1		PR	20	CR	0	10	CR	0	7,5
	7. 58(M)	RAEB2	Int-2 OL	Psoriasis	Old	Steroids/Eta/Ada	NE	0		CR	0	CR	0	0	(Progression)
	2C 8. 62(M)	RAEB2	Int-2 IA	SPA	Recent	Salazo	2D	Stable D	0		PR	0	PR	0	0	PR	0	0
	9. 63(M)	GS	Int-1 OL	EMG	Recent	Anti Pu	Marrow CR	0		CR	0	CR	0	0	CR	0	0
	10. 64(M)	RAEB2	Int-1 OL	Psoriasis	Concomitant Topical S	Stable D	0		PR	0	CR	0	0	CR	0	0
	11. 66(F)	RAEB2	High ND	PG	Recent	Steroids/MTX/RTX Stable D	0		PR	5	CR	0	0	CR	0	0
	12. 66(M)	AML	High IA	RA	Recent	Steroids/Lef/MTX	NE	0		CR	0	CR	0	0	CR	0	0
	13. 72(F)	RAEB2	Int-2 IC	ITP	Concomitant Steroids	CR	0		CR	5	CR	0	0	CR	0	0
	14. 75(M)	RAEB2	Int-2 CTD	RP	Concomitant Steroids	PR	0		CR	5	CR	0	0	CR	0	0
	15. 77(F)	RAEB2	Int-2 Vasc	GCA	Secondary	Steroids	Stable D	0		CR	0	CR	1	40	CR	0	0
	16. 77(F)	AML MLD	High Vasc	PAN	Concomitant Steroids/CYC/Azat Progression 0		CR	0	(Death)
	2E 17. 77(M)	RAEB1	Int-1 Vasc	Behcet	Secondary	2F Colchicine	Stable D	0		F	0	PR	0	0	(Toxicity)
	18. 79(M)	CMML2	Low IA	RS3PO	Secondary	Steroids	Progression 0		CR	5	CR	0	5	CR	0	0
	19. 88(M)	MDS MLD Low ND	Sweet	Concomitant Topical S	Progression 0		PR	0	(Progression)
	20. 55(F)	RAEB2	Int-2 ND	Sweet	Concomitant None		PR	0	(Sweet syndrome developed after AZA onset that resolved with steroids)

2A: OS in patients with or without AIMs 2B: OS in patients with or without infection related hospitalization 2C: OS in patients with or without prior cancer 2D: OS in patients with or without prior major cardiovascular event 2E: OS in patients with or without AML transformation 2F: OS regarding IPSS-R category

Table 4 : AIMs group patients characteristics before and after AZA treatment RAEB

 4 : refractory anemia with excess blasts, CMML: chronic myelomonocytic leukemia, AML: acute myeloïd leukemia, MLD: multilineage dysplasia, GS: granulocytic sarcoma, MDS : myelodysplastic syndrome, CTD: connective tissue disease, ND: neutrophlic dermatosis, Vasc: systemic vasculitis, OL: Organ-limited AIM, IA: inflammatory arthritis, IC: immune cytopenia, APLS: anti-phospholipid syndrome, MPGN: membrane-proliferative glomerulonephritis, SPA: spondyloarthritis, EMG: extra-membranous glomerulonephritis, PG: pyoderma gangrenosum, RA: rheumatoid arthritis, ITP: immune thrombocytopenia, RP: relapsing polychondritis, GCA: giant cell arteritis, PAN: periarterites nodosa, RS3PO: remitting seronegative symmetrical synovitis with pitting oedema.

, MTX : methotrexate, Pex: plasma exchanges, IgIV: intravenous polyvalent immunoglobulins, CYC: cyclophosphamide, Eta: etanercept, Ada: adalimumab, Salazo : salazopyrine, Anti Pu : anti-proteinuric treatment, Topical S: topical steroids, RTX : rituximab, Lef : leflunomide, Azat : azathioprine, CR: complete response, Stable D: stable disease, PR: partial response, NE: non evaluable, F: failure

Version anglaise au format article :

Title: Efficacy of azacitidine in management of auto-immune or inflammatory manifestations associated to high risk myelodysplasia and chronic myelomonocytic leukemia.


Romain Belafia

Pierre Jeanjean

Olivier Barais

Gurvan Le Guernic
email: gurvan.leguernic@inria.fr

Benoit Combemale
email: benoit.combemale@irisa.frpierre.jeanjean

From Monolithic to Microservice Architecture: The Case of Extensible and Domain-Specific IDEs

Keywords: Microservice, DevOps, Domain-Specific Languages

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

I. INTRODUCTION

In order to be fully functional and integrated into their usage environment, software languages need to be delivered with Integrated Development Environments (IDEs). These tools provide facilities to the programmers, such as syntax highlighting or auto-completion. These services, called Language Services allow the developer to use these languages more effectively in order to implement new software. Recently, a new trend for IDEs has emerged: Cloud-Based IDEs. These IDEs aim to relocate language services from the user's machine to a distant server. These IDEs have many benefits in comparison to more traditional IDEs, such as automatic saving and backup of code or real time pair programming, without the need to install anything [START_REF] Gadhikar | Browser Based IDE to Code in the Cloud[END_REF]. Protocols such as LSP 1 allowed to standardize the communication between a generic IDE client and a Language Server providing language services. However, the way these servers are deployed, typically as monolithic application, is currently not optimal for such an IDE usage. Indeed, language services have specific requirements in terms of bandwidth or memory [START_REF] Coulon | Modular and Distributed IDE[END_REF]. Some need to be accessed frequently, but do not require important computation capabilities, for instance auto-completion, while others such as refactoring are accessed less frequently but need more resources. Besides, modern IDEs tend to move towards an open-world philosophy: in this paradigm, an IDE consists of a basic kernel, which 1 https://microsoft.github.io/language-server-protocol/ allows the addition of new features incrementally that have access to the same resources, making it more modular. For these reasons we explore a different software architecture more likely to meet these constraints: the Microservice architecture.

Microservices have been recently introduced by the Software Engineering community as a support for new distributed and dynamic software architectures. In contrast to traditional monolithic architectures, a microservice architecture consists of small self-contained lightweight services working together. This new architecture has been widely adopted in the case of complex and heterogeneous projects by companies such as Netflix [START_REF] Bukoski | How we build code at netflix[END_REF], Spotify [START_REF] Engineering | How we use backstage at spotify[END_REF] or Uber [START_REF] Haddad | Service-oriented architecture: Scaling the uber engineering codebase as we grow[END_REF]. Indeed, microservices provide many benefits for Cloud-based applications, such as better scalability, autonomy and deployment times [START_REF] Jamshidi | Microservices: The journey so far and challenges ahead[END_REF]. As a result, such architectures are a good fit for DevOps practices [START_REF] Waseem | A systematic mapping study on microservices architecture in devops[END_REF]. However, the transition from a monolithic to a microservice2 application is still considered as a long and risky process [START_REF] Seacord | Modernizing Legacy Systems: Software Technologies, Engineering Process and Business Practices[END_REF]. Furthermore, even though academic work has been done to provide guides and tools to help companies performing such a modernization, the refactoring of legacy systems remains overall a case-by-case process [START_REF] Fritzsch | From monolith to microservices: A classification of refactoring approaches[END_REF].

This work aims to study the transition process of monolithic applications towards microservices, by focusing on the migration of Domain Specific Cloud-Based IDEs. This case study allows to explore the specific features of such software. These applications offer services to the user, which are heterogeneous in their response time and their computation requirements. They also add an important layer of complexity for the deployment of the services. Last, but not least, these applications manipulate rich data structures which adds challenges for the organization of the microservices.

In this paper we report our experience from the migration towards microservices of Sirius Web 3 , an open-source framework allowing the development of Cloud-Based Graphical Language Workbenches. Based on the encountered difficulties, we develop a basis for practitioners to execute the modernization process of systems sharing similar specificities.

This paper is structured as follows: Section II presents the motivations for this work and establishes technical back-grounds on the domains of Software Language Engineering and Microservices. Section III describes the specificities of Cloud-Based IDEs in a microservicization context. Section IV presents the experimental setup of the study, before describing the technologies used. Section V describes the experimentations performed, and the encountered difficulties. Section VI presents the lessons learned in this work: guides on microservicization process for specific industrial cases related to the case study. Section VII reflects on existing and related work to position our contribution. Finally, Section VIII performs a summary of the presented results, before bringing some perspectives for future works.

II. MOTIVATION

A. Software Language Engineering (SLE) 1) Language Implementation: Modeling a language from scratch is a tough process. Indeed, several steps are involved in the creation of a language: first on the syntactic aspect, with the specification of the concrete syntax, the abstract syntax, the static semantics and the dynamic semantics, but also on the behavior that can consist of either compilation or interpretation. Moreover, in order to provide a usable environment for the users, the language has to be delivered with tools that assist its uses. These tools form an Integrated Development Environment, or more simply, an IDE.

An IDE is a software which assists its user in the development of a program using a particular language. Examples of these are JetBrains CLion4 for C or C++ development and RStudio5 for R development. These pieces of software provide Language Services: functionalities aiming to assist the developer in writing programs in a particular language. For instance, the auto-completion advises the user to automatically complete a string of characters they are typing, with the most relevant proposition. Compilation can also be considered as a language service which converts source code to object code. Examples of other language services are refactoring, searching for references, etc.

Currently, IDEs tend to move towards an Open World philosophy, that is to say the ability to incrementally add functionalities to an existing software. These IDEs such as Microsoft Visual Studio Code6 or Atom7 are called modular IDEs. They initially act as simple text editors, that do not offer language specific functionalities. However, these IDEs allow the installation of modules which provide Language Services, for instance the syntax highlighting of C programs or the debugging of Java programs. The trend of modularity in IDEs is very noticeable if we look at the 2019 Stack Overflow's annual Developer Survey 8 . According to this survey, the majority of the most popular IDEs (8 out of 10), such as Visual Studio Code or IntelliJ 9 , heavily rely on a plug-in mechanism to customize the environment according to the needs of the users.

With the different steps of specification and the development of an IDE -or modules for modular IDEs -the development of a language can become a fastidious task. In order to facilitate this language development process, tools have been developed: the Language Workbenches. Languages workbenches have been introduced and popularized by Martin Fowler in 2005 [START_REF] Fowler | Language workbenches: The killer-app for domain specific languages?[END_REF], as environments that can drive the development and the maintenance of Domain Specific Languages (DSLs). Examples of language workbenches are the Eclipse Modeling Framework10 (EMF) or JetBrains Meta Programming System11 (MPS). These tools aim to support the development and the evolution of a language. They support every step of the conception of a language, from its design, to the support of its evolution, including the development of the associated IDE [START_REF] Combemale | Engineering Modeling Languages[END_REF].

In the end, from the point of view of its implementation, a DSL corresponds to a set of language services provided by an IDE to develop a program [START_REF] Coulon | Modular and Distributed IDE[END_REF].

2) Cloud-Based IDEs: Cloud-based IDEs aim to relocate software from the user desktop to a distant server providing the main functionalities of the application, following the Software As A Service (SaaS) model. On the client side remains only a user interface with minimal functions. The client side can be localized either in a browser, or a basic desktop application.

There are a lot of opportunities for Cloud-Based IDEs. To begin with, a SaaS architecture saves the user the trouble of installing heavy and specific software to program such as linters or a JDK [START_REF] Gadhikar | Browser Based IDE to Code in the Cloud[END_REF]: this can possibly allow any user to use the IDE, no matter the resources they have available locally. An important feature of Cloud-based IDEs is the ability to work simultaneously with other coworkers [START_REF] Gadhikar | Browser Based IDE to Code in the Cloud[END_REF], [START_REF] Wang | New opportunities for extracting insights from cloud based ides[END_REF], allowing to ease real-time pair programming. Another aspect which has been recently studied is the ability to take advantage of these platforms to analyze the coding habits of either a particular user or a community of users to provide a more relevant assistance, based on their behaviors on the IDE [START_REF] Wang | New opportunities for extracting insights from cloud based ides[END_REF], [START_REF] Wang | Characterizing developer behavior in cloud based ides[END_REF]. These explain why Cloud-Based IDEs, such as Jupyter Notebook 12 or Overleaf 13 , have gained in popularity.

A Cloud-based IDE works the following way: the clientside is composed of a language agnostic IDE (which mostly acts as a simple text editor), and the server-side exposes a language server which provides language services. Figure 1 illustrates the typical way Cloud Based IDEs are implemented.

The LSP protocol 14 , introduced by Microsoft in 2016, standardizes the communication between a language agnostic IDE and a language server. Instead of specifying how each language service of each language works for each IDE, the Client IDE Language server

• Completion • References • Refactoring • Compilation • . . .

Communication protocol

Fig. 1: Legacy implementation of Cloud-based IDEs LSP protocol allows to standardize the way these services are rendered to the user. This protocol was originally developed for the creation of modules for Microsoft Visual Studio Code, but has become a standard for other environments as well.

Through its use, a single language server implementation can be used as-is in a landscape of development environments, and any environment can leverage on the existence of multiple language servers. Modular IDEs also allow their users to personalize their own user experience by choosing the functionalities they judge necessary. However, current Cloud-Based DSL IDEs are still generally implemented in a monolithic way [START_REF] Coulon | Modular and Distributed IDE[END_REF]. All the services are rendered by one non-modular application. In addition to the lack of customization of these IDEs, the language services are not optimal in their response time. Indeed, each service has specific requirements in terms of bandwidth or latency, but they are all still deployed on the same hardware. Another way to implement such a language server has been explored by Coulon et al. [START_REF] Coulon | Modular and Distributed IDE[END_REF]. This new approach is based on a microservice architecture, which is a deployment organization that separates every functionality of the system as independent services.

Cloud-Based DSL IDEs have a lot to gain to transition towards microservices. The different language services provided by the IDE have different requirements in terms of bandwidth or latency. Moreover, IDEs tends to move towards an open-world philosophy, by separating the language services in clear modules which can be added to the IDE incrementally. Such requirements could be more easily met in a microservice architecture rather than in a monolithic one.

B. Microservice Architectures 1) Definition and Properties of Microservice Architectures:

Microservice architecture is an approach of software service design, development and delivery, which has gained a lot of popularity in the recent years. It has been widely used in the industry, more particularly in the case of large-scale applications. For instance, companies such as Netflix [START_REF] Bukoski | How we build code at netflix[END_REF], Spotify [START_REF] Engineering | How we use backstage at spotify[END_REF] and Uber [START_REF] Haddad | Service-oriented architecture: Scaling the uber engineering codebase as we grow[END_REF] have been using it as the basis for complex infrastructures with great success.

The main characteristic of a microservice architecture is the decomposition of the system in clear modules. These modules, the microservices, are lightweight and independent. They support a single functionality in the program the best way possible [START_REF] Newman | Building Microservices: Designing Fine-Grained Systems[END_REF]. Therefore, such a service would typically only be a hundred to a thousand lines of code long [START_REF] Thones | Microservices[END_REF]. Each service is deployed independently, and depending on its specific needs, a lightweight service can be deployed locally while a heavier service, needing more resources but not a fast response time, can be deployed on a remote server. These services communicate between each other using a Language Agnostic API [START_REF] Erl | Service-Oriented Architecture: Concepts, Technology, and Design[END_REF]. Microservices are generally packaged and deployed in the cloud using lightweight container technologies such as Docker 15 , following the fashion of DevOps practices. These architectures are typically supported by fully automated software integration and delivery machinery such as Gitlab 16and Jenkins 17 .

Such architectures are currently becoming a standard in software engineering. In [START_REF] Waseem | A systematic mapping study on microservices architecture in devops[END_REF], the authors emphasize the benefits that microservices architectures can bring to DevOps practices. For instance, microservices are known for their ability to deal with scalability [START_REF] Jamshidi | Microservices: The journey so far and challenges ahead[END_REF], i.e. the ability to make the size of the system evolve as the project evolves. This ability is crucial in a DevOps-driven development, to quickly adapt a system to its usage. In addition to such technical benefits, microservices also allow for more process-related benefits, such as the distribution of the workforce into small and selfmanaged teams, each focused on a microservice. This fits very well DevOps practices which recommend to vertically divide the workforce into small cross functional teams [START_REF] Balalaie | Microservices architecture enables devops: Migration to a cloud-native architecture[END_REF].

2) Transition Process from Legacy Systems Towards a Microservice Architecture: Here, we discuss the modernization process, which is undertaken by industrials when performing a transition from legacy systems towards microservice architectures. In [START_REF] Wolfart | Modernizing Legacy Systems with Microservices: A Roadmap[END_REF], the authors establish 4 phases to transition monolithic applications towards microservices, based on a body of academic works studying the microservicization process.

a) Analysis of the Driving Forces: First, the analysis of the driving forces is considered as a crucial step of a modernization. Indeed, while the transition to microservice can bring significant improvements to the application in the long term, and ease future developments, transition from legacy systems towards microservice architecture is a long and risky process [START_REF] Seacord | Modernizing Legacy Systems: Software Technologies, Engineering Process and Business Practices[END_REF]. Thus, companies often establish cost-benefit analysis, based on the potential benefits such as increased performances, better scalability and ease of the development process [START_REF] Jamshidi | Microservices: The journey so far and challenges ahead[END_REF].

b) Modernization Planning: The next phase of a modernization is the establishment of a plan for the transition towards microservices. To begin with, practitioners explore, analyze and understand the legacy systems: the different features, how they interact, how they are implemented. This process is called feature location. In order to accomplish this task, practitioners can rely on high-level artifacts such as UML diagrams, graphs, or texts based on low-level artifacts such as source code [START_REF] Erl | SOA Design Patterns[END_REF]. The next step is to decompose the legacy system in small modules which will then be implemented as microservices. This very complex step has been investigated by a lot of research works. Here, the practitioners decide on the granularity of the decomposition, that is to say the balance between the number of microservices and their size. Finally, the microservice architecture is properly defined, by describing the microservices behavior and the way they communicate. This is done by defining the services' APIs and the communication protocols, such as HTTP or SOAP, used for the exchanges between microservices [START_REF] Jamshidi | Microservices: The journey so far and challenges ahead[END_REF]. However, the decomposition of legacy systems remains in most cases a manual process. Indeed, the microservices are often designed around business capabilities, to allow their independent deployment [START_REF] Levcovitz | Towards a technique for extracting microservices from monolithic enterprise systems[END_REF]. These capabilities are not easily identifiable through an automatic process.

c) Modernization Execution: Once the modernization has been planned, the next step is to execute this plan, by developing and integrating the microservices. A few research works aimed at automating the modernization execution. For instance, in [START_REF] Bucchiarone | A Model-Driven Approach Towards Automatic Migration to Microservices[END_REF] the authors developed a Model-Driven approach which automates the transition from a Java based monolithic application to a microservices-based application. However, here again, such tools are rarely used in the industry, and the implementation task remains mostly manual. In parallel, or after the development of these microservices, comes the test phases. While automated unit tests or integration tests are usually done alongside the implementation, some validation tests can still come afterwards.

d) Monitoring: Based on metrics defined upstream, the microservicized application needs to be monitored in order to verify that the aims have been reached. Tools have been developed to assist this process such as Micrometer 18 which provides interfaces to evaluate JVM-based applications.

Our work aims to explore the specific case of Cloud-Native IDEs, as a way to analyze the constraints linked to the manipulation of rich data structures, in the case of a migration towards microservice architectures. The next section describes in more details this case study.

III. ON IDE MICROSERVICIZATION

As shown in Section II-A2, Cloud-Based IDEs have a lot to gain to be migrated from a monolithic to a microservice architecture. Besides, IDEs are interesting case studies due to their particularities as software.

A. Heterogeneous Services

As explained in Section II-A1, an IDE provides multiple language services (auto-completion, compilation, refactoring, etc.). In a microservices approach, each one of these language services would correspond to a single microservice. An important aspect of these services is their heterogeneity, whether they have different access frequencies or required resources. For instance, auto-completion aims to propose to the user to automatically complete a string of characters they 18 https://micrometer.io/ are typing. Such a service is accessed very often -almost at each user input. However, such a service usually does not require a lot of computation power, in comparison to other services. Conversely, compilation is usually a heavy process. The compilation of a C program can take in some cases tens of minutes. Nevertheless, such a time-consuming process is usually accepted since compilation is called far less frequently than auto-completion for instance. Such a diversity of services often means a diversity of services implementations, but also of deployments.

B. Complexity of Deployment

The question of microservices deployment and more generally of cloud deployment is complex due to the multiple factors taken into account in addition to the response time [START_REF] Ma | Multi-objective microservice deployment optimization via a knowledge-driven evolutionary algorithm[END_REF]. Elements such as availability, free storage, CPU usage or memory usage are constraints that are imposed to the deployment centers, which have specific needs [START_REF] Fadda | Monitoring-aware optimal deployment for applications based on microservices[END_REF]. In the case of Domain-Specific IDEs, the question of services deployment is even more complex due to the volatility of the resources. Depending on the usage of the IDE, the optimal deployment for the microservices differs. For instance, if a user is the only one to use a given instance, the deployment will be different from when a 10-person team is fully committed to a project. Furthermore, in the last case, the resources available for the deployment are susceptible to be unavailable at a certain point. The deployment mechanism must thus adapt more or less dynamically to the resources currently available. The black box aspect of the services is also a challenge. Indeed, the resource consumption of the services can be difficult to evaluate before the deployment, and the resources needed are often only known once the application begins to run.

C. Rich and Shared Data Structures

The goal of an IDE is to provide assistance to the user to write a program. A program is manipulated as a rich data structure, usually in the form of an Abstract Syntax Tree (AST). These structures have to be accessible by language services, more or less frequently depending on the services, as explained previously. Therefore, the transfer and the serialization of these structures have to be handled properly to avoid any drop in performances. If the entirety of the program and the associated resources were transferred at every call of a service such as auto-completion, this could have a great impact on the performances and make the overall environment feel sluggish. Thus, one has to make choices, both about the structures of the microservices and the data to transfer between them. For instance, we can imagine a system that keeps a copy of the AST in every microservice, which would be modified on each call through diffs and patches to stay coherent with the other services.

IV. EXPERIMENTAL SETUP

A. Case Study Overview

In order to study the modernization of Cloud-Native IDEs, we rely on Sirius Web by Obeo. Sirius Web is a framework A graphical modeling workbench can be described as an IDE that manipulates graphical modeling languages. Sirius Web is mainly used in the context of model engineering, an approach which relies heavily on models instead of textual code as the source to generate software.

The first implementation of Sirius was a desktop application, integrated as an Eclipse application. Examples of Sirius usages are Capella 19 by Thales, dedicated to the development of system architectures, or AdvoCATE 20 by NASA, used to specify safety and assurance cases. Recently, Sirius has been ported to the Cloud, as a monolithic application.

Here, we study the transition process of Sirius Web from a monolithic application to microservices. The aim of this work is to study the modernization process of Sirius, in order to highlight some difficulties that such architectures can cause. Figure 2 represents the legacy architecture of Sirius Web and the modern microservice architecture we aim for.

B. Technologies Overview 1) Eclipse Modeling Framework & Meta-models:

To describe a meta-model, Sirius uses the Eclipse Modeling Framework 21 (EMF), a set of Eclipse plug-ins which can be used 19 https://www.eclipse.org/capella/ 20 https://ti.arc.nasa.gov/tech/rse/research/advocate/ 21 https://www.eclipse.org/modeling/emf/ in the practice of modeling engineering. EMF provides a tool, Ecore, to describe graphically a meta-model. Ecore is a framework composed of a set of concepts, that can be manipulated by EMF to build a meta-model. In addition, EMF allows specifying, in a genmodel file, the generation of Java code from an Ecore meta-model, which will be then manipulated by Sirius.

2) Eclipse Sirius: Once the meta-model of the manipulated model has been generated, Sirius allows the user to define its graphical representation. On top of an EMF Project, Sirius allows the creation of an odesign file, to specify the graphical representation of the different concepts described with Ecore. For instance, choosing icons to represent the instances of an EClass, or the EReferences with straight lines.

Sirius also offers the possibility to specify conditional rules, for the representation of models. For instance, an element could appear bigger if a numeric attribute x is superior to 10. To specify these conditions, Sirius uses a query language, the Acceleo Query Language22 (AQL). AQL is a Domain-Specific Language (DSL) developed by Eclipse, to perform queries over an Ecore meta-model. If a behavior is too complex to be specified using AQL, it can be described by adding additional Java code through what is referred to as "Java Services".

The original version of Sirius, Sirius Desktop, allows to produce an RCP application, but recently Obeo released a Cloud-Native version of Sirius: Sirius Web. Sirius Web allows the development of a Web Application running in a Web Browser.

A Sirius Web application relies on a set of modules called Sirius Components 23 . In this work, we focus in particular on the backend components managing the back-end part of Sirius Web. They are implemented using Java, and rely on the Spring Boot framework 24 : a Java framework, particularly adapted for the creation of Web Applications. Each component provides a particular functionality of Sirius Web or describes their associated API. Other Sirius Components are dedicated to testing the behaviors of a set of Components designed to work together.

V. EXPERIMENTATION

A. Feature Location & Analysis of Dependencies

To begin with, the first step to migrate Sirius Web towards microservices is to analyze the different functionalities of the legacy system. The idea being to locate features which could lead to a specific microservice. As explained in Section IV-B2, Sirius Web relies on Sirius Components, which are the building blocks of any Sirius Web application. This decomposition is an example of code modularity. It tends to ease the identification of features inside the application, and make the overall structure easier to understand.

However, the current decomposition has some limitations. Indeed, this code modularity does not necessarily correspond to the deployment modularity we aim for: each component does not correspond directly to a specific functionality, which could correspond to a microservice. For instance, some components only provide the API of the system while other specify some annotations used in others. Features to isolate are often features contained inside Sirius Components.

An important part in this process is the identification of dependencies between the different features to isolate. Here again, the modular structure of the Sirius Components allows to easily identify them since each Sirius Component is built as a Maven 25 project. Thus, all the dependencies of a Sirius component are specified in the corresponding pom.xml file.

Identifying dependencies between components allows to determine the decomposition in microservices and the overall architecture. The components which have the fewer dependencies on others will be easier to extract. Based on this study we plan the decomposition of the application in different services. The identified features to isolate consist of:

• The AQL Interpreter, performing AQL queries of the meta-model; • The Document Service, dealing with create, read, update and delete (CRUD) operations; • The Layout Service, organizing the layout of the representations; • The ODesign Reader, which aims to compute an odesign file.

The interactions between the different features of the application being very complex, we decided to perform the decomposition of the application incrementally. That is to say, we decided to plan and execute the decomposition of one microservice at a time, rather than planning the microservicization of all the features identified, before executing their modularization. This approach is not specific to this work. Indeed, some academic research such as [START_REF] Hassan | Microservice ambients: An architectural meta-modelling approach for microservice granularity[END_REF] argue that the microservicization process of an application should be incremental. Due to the complexity of the activity, one will slowly learn how to better perform this decomposition for each microservice successfully extracted from the monolithic system. Thus, this organization would help us to better apprehend the microservicization process at each increment.

For each component extracted from the rest of the application, we pay attention to the difficulties encountered, and how they can be generalized to other applications. This will allow us to derive practice guides for the modernization of a monolithic application.

B. AQL Interpreter Decomposition

The first feature chosen for the decomposition of Sirius Web in microservices is the Acceleo Query Language Interpreter -or AQL Interpreter. This part of the application aims to interpret AQL expressions, which are queries performed on EMF models. The reason for this choice is that the AQL Interpreter does not have any dependencies on other Sirius components, which tends to make the decomposition in microservices easier. Moreover, an AQL Interpreter microservice could be reused in future Cloud-Based IDEs using the Eclipse Modeling Framework.

1) Original Implementation: The AQL interpreter was fully implemented in the sirius-web-interpreter component. Before evaluating an AQL expression, an AQLInterpreter needs to be initialized. To do so, one must pass two arguments:

• A set of Java classes, corresponding to the Java services available to the AQL interpreter; • A set of EPackages, the Java code generated for additional meta-models which can be interpreted by the AQL interpreter. Once an AQL interpreter has been initialized, it can start evaluating AQL expressions. Here, two elements are required:

• A set of variables, that the AQL evaluator can use;

• The AQL expression to evaluate. The result of an evaluation can be an instance of various types: a String, an Integer, an Object, etc. This result is wrapped in an instance of Result. A Result encapsulates the result of the expression, and allows delaying the typing of the resulting value.

AQL interpreters are used in other components. The original implementation of the AQL interpreter consisted in many instances of AQLInterpreter used in the various components. The idea of the microservicization was instead to have only one AQL interpreter service which could be called by other components.

2) Microservice Architecture: In order to explore the different ways to perform microservice migration, two implementation approaches were explored: a stateless and a stateful approach.

a) Stateless Approach: In accordance to the current trends of microservices, the first approach investigated was a Stateless approach. This means that the AQL interpreter should not retain any information from previous interactions. Thus, no initialization phase is done in this implementation. Each time an AQL expression is evaluated, the Java services and additional metamodels needed are passed to the AQL interpreter. This approach has the typical advantages of Stateless architectures: the on-demand elasticity and the reliability through redundancy. Moreover, an AQL expression can be directly evaluated without the need for an initialization phase. However, this approach turns out to be very cumbersome for the rest of the application. Indeed, the Java services and additional packages must be carried between the components. If this can be handled in a monolithic approach, it can quickly become an issue in a microservice architecture. Moreover, since no initialization phase is done with the AQL interpreter, a similar work has to be done at each evaluation. This can result in an important drop in performances, similar to the one observed in [START_REF] Coulon | Modular and Distributed IDE[END_REF].

b) Stateful Approach: The Stateful approach has also been investigated. In this approach, the initialization phase is preserved. Thus, before performing an evaluation, one must call the initialization function of the AQL microservice. A "session" will be created as a IQueryEnvironment. This corresponds to the information built during the initialization of the Interpreter based on Java services and additional metamodels. Each session is identified with an integer (more precisely, a Long, to avoid running out of session IDs). Thus, each time an evaluation has to be done, the session ID has to be passed in order to evaluate the expression in the right environment. This approach loses the advantages of statelessness, in particular the reliability through redundancy: the same call to the AQL interpreter will not always produce the same output. However, it allows to make the manipulation of the AQL interpreter less complex. Instead of manipulating an instance of AQLInterpreter like the original implementation, or a set of Java classes and EPackages like the Stateless approach, here a simple integer is enough to communicate with the AQL Interpreter. For these reasons the Stateful approach has been selected.

3) New Implementation: The new AQL interpreter microservice has been developed using the Quarkus Framework 26 . This Java framework, similar to Spring Boot, is here again particularly suitable for the development of Cloud applications, and microservice applications in particular. Quarkus consists of a set of technologies optimized for GraalVM 27 . GraalVM is a virtual machine considered as "universal". It allows running applications written in many languages: JVM-based languages such as Java, Scala or Kotlin, LLVMbased languages such as C and C++, and other dynamic languages such as JavaScript, Python, R or Ruby. GraalVM makes possible for Quarkus to perform ahead-of-time (AOT) compilation, converting the produced Java bytecode into native machine code, resulting in an optimized binary that can be executed natively. This allows to reduce considerably the startup time and the memory footprint of the application, compared to similar software made with Spring-boot [START_REF] Decanay | Quarkus vs. spring[END_REF].

For communicating with the microservices, we decided to use a RESTful implementation. This was implemented using the RESTEasy Framework28 by JBoss. This framework provides an implementation of the JAX-RS API, a Java API for RESTful services.

C. Next Components

Unfortunately, the decomposition of the AQL Interpreter was a very complex process which did not allow us to focus on other services. In future works, the decomposition of other components will be explored. For instance, the Document Service, dealing with CRUD operations, will allow to explore the decomposition of a service dealing with a database. The ODesign reader, which relies on the AQL Interpreter, can serve as a case study to explore the communications between differents microservices. However, the difficulties encountered during the decomposition of the AQL Interpreter allowed us to derive practice guides, that we will talk about in the next Section.

VI. LESSONS LEARNED

This section discusses the difficulties encountered during the microservicization of Sirius Web, and the lessons learned for future applications. We describe broader contexts where such difficulties can be encountered, and discuss the possible solutions which can be applied.

A. Serialization Issues

A difficulty encountered during the microservicization of Sirius concerned the serialization process. The serialization allows converting Java objects to streams of bytes, in order to easily transfer these data between services -typically using json or XML formats. In the case of complex data structures such as Abstract Syntax Tree, serialization can be a tough process. Indeed, elements such as inheritance of concepts defined in external projects or self-references can add a layer of complexity to the process. Nevertheless, in the case of Sirius, some tools already existed to serialize EObjects. The basic way to serialize EMF objects consisted in using the XML Metadata Interchange29 (XMI) standard. This standard allows specifying the representation of meta-data in an XML format. More recently, the emf-json project 30 provided a support for the JSON format to the Eclipse Modeling Framework. However, even though these formats were adapted to transfer the EMF instances found in models, they were not designed to deal with the EMF classes specifying the meta-models.

1) Application Cases: Such an issue can be encountered in a lot of situations, as soon as the elements to exchange are not trivial to serialize. The presence of rich and complex data structures to transfer can be an evidence for such issues.

2) Practice Guide: In the planning phase, practitioners aim to plan the decomposition of the application. It is important at this point to anticipate which data must be transferred between the services, and how they will be serialized. In the case of uncommon data structures, practitioners have to be aware of whether dedicated tools already exist for the serialization of these structures or not. If this is not the case, they must anticipate the difficulties that will be encountered and decide on the way to resolve them before attempting any decomposition.

Lesson Learned 1 Serialization of data to transfer can be an arduous process when rich and complex structures are manipulated. These difficulties should be planned upstream, especially to audit existing solutions or to schedule the development of a new one.

B. Rupture of Pass-by-Reference Chains

In a program, a method or a function is characterized by the elements passed as actual parameters. The way these elements are passed can be grouped up in two main categories:

• In a pass by value evaluation strategy, the parameters are passed as a copy of the object passed to the function, which will prevent the original object from being affected by the operations done by the function; • In a pass by reference evaluation strategy, a reference to the object is passed, which allows modifying directly the element pointed by the reference. In a Java program, the evaluation strategy is called Shared Object Transfer, and is in practice similar to the pass-byreference strategy. It allows to easily manipulate Java objects passed as the actual parameters of successive methods or functions, creating pass-by-reference chains. However, this way of manipulating data can cause issues in a microservicization context. Indeed, when a feature is separated from the legacy application to its own microservice, the communication by pass-by-reference is cut during the serialization process. Basically, this means that every object passed to a microservice is in fact "passed by value", breaking up existing pass-byreference chains.

1) Application Cases: If the legacy applications relies heavily on a pass-by-reference strategy, such problems can occur. In particular, such issues are more likely to occur if the possibility to alter a function parameter is not made explicit.

2) Practice Guide: During the analysis of the legacy systems, practitioners must take note of the way variables are transferred throughout the program. If the application is planned for a migration toward microservices, one would prefer a more functional style. Otherwise, practitioners must meticulously adapt the structure of the application. The called microservice has to apply any changes on function parameters and notify its caller afterwards. Some future works could explore the development of a framework that allows to explicitly specify how a parameter should be treated during the microservicization. For instance, in the case of a Java program, an annotation framework could be developed to indicate if a parameter is expected to be affected by side effects or not. This could allow developers to analyze with more correctness the feature map in a program, but could also open the way for microservicization processes based on these annotations.

Lesson Learned 2 An application which heavily relies on pass-by-reference chains exposes itself to issues during the modernization process. One must thus be vigilant to adapt these behaviors to the future microservices' interactions.

C. Open-World Challenges

Sirius Web relies on the open-world philosophy. Indeed, it allows the enrichment of the application through the addition of new functionalities, in particular using Java Services. This philosophy makes a lot of sense in the context of IDEs, since it allows a user to add functionalities incrementally to fit its usecases, as many other modular IDEs do. However, this makes the microservicization of the application much more complex. Indeed, multiple microservices must often have access to these added functionalities.

In the case of the AQL interpreter, the problem came from the presence of Java Services required during the initialization phase. However, the microservice architecture prompts the practitioners to develop the microservices to be deployable and usable independently of their usage context. Thus, the microservices need to dynamically adapt to these functionalities.

1) Application Cases: Such problems can be encountered in open-world applications, i.e. applications offering the possibility to dynamically add new functionalities. The closest example to the case study is the case of modular IDEs, but for instance one can also imagine a cloud-based video game which offers the possibility to manage additional mods.

2) Practice Guide: In order to solve these issues, the first element to take into account is the possibility for the technology to adapt to dynamic functionalities. For instance, the AQL interpreter was implemented using Quarkus, which offers the possibility to run native applications, lowering both the memory footprint and the startup time. As a downside, such an approach prevents the deployed microservices to adapt to modular functionalities. However, other technologies allow for a more dynamic behavior. We thus recommend anticipating such problems at the earliest, particularly when deciding on the microservice technologies.

Another choice to handle open-world issues is to better define the granularity. Indeed, the ability to manage modular functionalities can be handled by using dedicated microservices. However, such an implementation is not trivial either: microservices have to coordinate to adapt to this new functionality. New architectural challenges appear to deal with this structure.

Lesson Learned 3

In an open-world application, the availability of modular features for different microservices can be an issue. Practitioners must plan how to make microservices deal with the dynamic addition of features, possibly by taking them into account when considering the granularity of the application.

D. Manipulation of Shared Resources

In some application cases, multiple features can rely on shared resources: heavy data which can be initialized once, and then accessed by different functionalities of the program. For instance, the AQL interpreter, as well as other features of Sirius Web, relies on additional EPackages to initialize an interpreter. The fact that a monolithic application may decide to share the same resources with different features of the application makes sense, and allows mechanisms such as lazy initialization. However, their usage in the case of microservices raises some issues.

As explained in Section VI-A, these issues can be linked to the serialization of these resources or the synchronization between the different components. In addition to these, the horizontal scaling of microservices implies the creation of multiple instances of the same resources in different services, causing higher costs in memory footprint and greater instantiation times.

1) Application Cases: Applications sharing rich resources throughout multiple different features are subject to such challenges.

2) Practice Guide: In the same way as the previous issue, a solution to deal with such a challenge is to carefully plan the microservicization architecture. Centralizing the services which manipulate shared resources can solve the issue. However, such a solution is not always possible and does not fit well with the philosophy of microservices. Another research lead to investigate is the possibility to share such resources locally. Once again, such a solution is difficult to implement and adds additional constraints to the deployment strategy of the application.

Lesson Learned 4 Shared resources in an application raise challenges for the microservicization process. In such cases, one must be aware of the impacts of such elements on the microservice granularity and the overall deployment.

VII. RELATED WORKS

The process of Cloud-based IDE microservicization has already been explored in [START_REF] Coulon | Modular and Distributed IDE[END_REF]. This article develops a systematic approach to migrate monolithic Cloud-Based IDEs towards microservices. Based on the specification of the manipulated language and the desired language services, the approach generates a set of modular language microservices and a toolsupported feature model to configure their deployment. This approach brings disparity in the performances of language services after their modularization. If heavy services such as compilation show improvements on their response time from this approach, lightweight quick-feedback services such as auto-completion suffer greatly in reactivity. This drop in performances is even more accentuated when the length of the code increases. The authors of the paper have already identified two factors as responsible for this disparity: the statelessness of the services and the lack of optimization for the deployment. Some research works have been done to automate the decomposition of a Cloud-based application, based on the expected benefits for the modernization. For instance, Service Cutter relies on an Entity-Relationship model to propose a decomposition of a legacy application [START_REF] Gysel | Service cutter: A systematic approach to service decomposition[END_REF]. In [START_REF] Bucchiarone | A Model-Driven Approach Towards Automatic Migration to Microservices[END_REF], the authors developed a Model-Driven approach which automates the transition from a Java based monolithic application to a microservice application. This approach is based on Jolie31 , a programming language designed to implement microservices and specify microservice architectures. Some academic works established a broader classification on microservicization techniques. In [START_REF] Ponce Mella | Migrating from monolithic architecture to microservices: A rapid review[END_REF], the authors performed a "rapid review" on microservicization techniques and highlighted 3 main approaches to perform such a modernization : model-driven based on high level representations of the system, static analysis of the source code, and dynamic analysis of the running system. Similarly, in [START_REF] Fritzsch | From monolith to microservices: A classification of refactoring approaches[END_REF], the authors identified 10 architectural refactoring approaches for microservicization, classified in similar categories. This work is accompanied by a selection guide to support the practitioners in choosing the more adequate solution.

VIII. CONCLUSION & PERSPECTIVES

We detail in this paper our experience on the microservicization of a Cloud-based IDE. This work aims to provide insights for developers on the difficulties that such applications can raise during a modernization process. These difficulties come from the various specificities that Cloud-based IDEs possess, such as the heterogeneity of the language services' needs or the manipulation of rich and complex data structures. To explore these specificities, we rely on a Graphical Modeling Workbench, Sirius Web: a framework that allows users to deploy Cloud-based IDEs manipulating graphical languages.

This paper focused mainly on the microservicization of the AQL interpreter. This part of the application aims to interpret AQL expressions, which are queries performed on an EMF meta-model. The reason for this choice is that the AQL Interpreter does not have any dependencies over other Sirius components, which tends to make the decomposition in microservices easier. This microservicization allowed identifying four main challenges that a Cloud-based IDE can raise in a microservicization process:

• The serialization issues;

• The rupture of pass-by-reference chains;

• The open-world challenges;

• The manipulation of shared resources. This paper opens the way for future works. To begin with, this experience report focused on the microservicization of Sirius Web's AQL Interpreter. However, other components could be interesting to extract. For instance, the DocumentService, in charge of CRUD operations would allow to explore the manipulation of these operations on a Cloud-Native IDE context. DiagramDescriptionConverter could also be an interesting case study to explore the manipulation of other types of resources. More generally, the decomposition of Sirius Web in many microservices could be interesting to tackle issues linked to microservice deployment.

Finally, the lessons learned here open the way for the development of microservicization automation tools. For instance, solutions to deal with the rupture of pass-by-references chains could be explored. One could develop an annotation framework to specify the way a passed-by-reference parameter should be handled during the modularization. However, these automatic migration strategies should be diverse, to adapt to different use cases. Each strategy would have strengths and weaknesses. For instance, deciding to use a finer granularity could allow dealing efficiently with applications relying on an open-world strategy, but would add additional costs for an application manipulating shared resources.

Fig. 2 :

 2 Fig. 2: Representation of a Sirius Web application structure: (a) the legacy monolithic structure (b) the new microservice structure we aim for

In this article, we use the neologism microservicization, as in[START_REF] Jeanjean | IDE as Code: Reifying Language Protocols as First-Class Citizens[END_REF], to designate the transition process from monolithic to microservice architecture.

https://www.eclipse.org/sirius/sirius-web.html

https://www.jetbrains.com/clion/

https://rstudio.com/

https://code.visualstudio.com/

https://atom.io/

https://insights.stackoverflow.com/survey/2019# development-environments-and-tools

https://www.jetbrains.com/idea/

https://www.eclipse.org/modeling/emf/

https://www.jetbrains.com/mps/

https://jupyter.org

https://www.overleaf.com/

https://microsoft.github.io/language-server-protocol/

https://www.docker.com/

https://about.gitlab.com/

https://www.jenkins.io

https://www.eclipse.org/acceleo/documentation/

https://github.com/eclipse-sirius/sirius-components

https://spring.io/

https://maven.apache.org/

https://quarkus.io/

https://www.graalvm.org/

https://resteasy.github.io/

https://www.omg.org/spec/XMI

https://www.jolie-lang.org/


Gilles Martel

Vincent Thenard

Jean Philippe Choisis

Marc Moraine

Territorial resources mobilisation shapes agroecological transitions in crop-livestock systems

come