Dr Nizar Messai

Web services have established themselves as an essential technology for the development of real-world applications that may wrap a wide range of Web-accessible functions, resources, programs, databases, sensors, devices, etc. This unprecedented proliferation of Web services not only accentuated the already known challenges of service discovery and composition, but also raised new ones regarding extending service interactions to usercentric perspectives. This includes the challenges of contextualizing and personalizing service recommendation, handling user contributions and feedbacks, preserving privacy and trust while evolving in highly dynamic contexts. At the same time, other hot-topic research areas such as Semantic Web, Machine Learning and Blockchain, achieved high maturity level techniques and tools that can be adapted to address these challenges.

In our research, we focus on the convergence of the previous areas of study, aiming to introduce cutting-edge approaches that leverage semantic-awareness, to handle major challenges encountered throughout the cycle of life of web services. Our ultimate goal is to allow successful and effective interactions in service-service scenarios within compositions, as well as in user-service scenarios. First, to address the mismatch problem in service discovery and recommendation, we propose semantic similarity measures based on ontologies and Linked Open Data. These measures are the basis for a semantically enabled Web service interaction framework including service discovery and composition which also appeals for additional formal models such as Formal Concept Analysis and Graphs. Second, we tackle the lack of personalized service recommendation and multiple-device service migration in user-centric service interactions. We propose a Configuration-based approach to meet highly personalized and contextualized service recommendation and Liquid Software based approach for smoothly migrating user-service interactions in multiple-device contexts. Third, we address the challenge of dynamic evolution of service interactions in open untrusted environments. We combine graph network representations with Machine Learning models to capture service interactions and user feedbacks to achieve accurate service recommendation. We finally address the untrusted collaboration issues in service interactions through the use of Blockchain and Smart contracts. We implemented our methodologies in prototypes. We tested them rigorously on contemporary datasets, proving their robustness and showcasing their effectiveness over prevailing state-of-the-art strategies. 1

Résumé

Les services Web se sont imposés comme technologie incontournable pour le développement d'applications accessibles sur le Web. La prolifération des services Web a accentué les défis déjà connus liés à leur découverte et leur composition. Elle en a aussi soulevé des nouveaux notamment ceux liés aux interactions centrées utilisateur tels que la recommandation personnalisée et contextualisée de services, la prise en compte des retours et commentaires utilisateurs, le respect de la vie privée, la gestion de la sécurité et de la fiabilité des échanges, tout en évoluant dans des contextes très dynamiques. Parallèlement, des domaines de recherche complémentaires, tels que le Web sémantique, l'apprentissage automatique et la Blockchain, ont également connu beaucoup d'évolutions aboutissant à la proposition de techniques et d'outils qui peuvent être adaptés pour répondre à ces défis.

Nos travaux se situent à la croisée de ces domaines et visent à proposer des approches novatrices et efficaces capables de répondre aux défis liés aux interactions à base de services Web. Nos deux premières contributions ont pour but d'améliorer la qualité et l'efficacité des recommandations de services Web à travers l'intégration de la sémantique pour l'annotation des services et leur appariement. Nous proposons pour cela deux mesures de similarité sémantiques qui s'appuient respectivement sur les ontologies et sur les données liées. Nous faisons également appel à des formalismes tels que l'Analyse de Concepts Formels et les graphes. Nos deux contributions suivantes visent à améliorer la personnalisation et la contextualisation dans les interactions à base de services. Nous utilisons la théorie de configuration pour fournir des recommandations personnalisées et sensibles au contexte de l'utilisateur. Nous utilisons les principes du Liquid Software pour permettre la migration fluide des interactions à base de services d'un appareil utilisateur à l'autre. Nos deux dernières contributions répondent à l'évolution dynamique des interactions à base de services dans les environnements distribués, ouverts et non fiables. Nous combinons des modélisations en réseaux sociaux avec des modèles d'apprentissage automatique pour gérer les différents types d'interactions et prendre en compte les commentaires d'utilisateurs afin d'entretenir la qualité des recommandations dans le temps. Nous utilisons les Blockchain pour répondre à la problématique de fiabilité dans les collaborations à base de services.

Les approches proposées ont été implémentées en prototypes et évaluées sur des jeux de données, réels et synthétiques, afin de montrer leur efficacité et leur pertinence. the concept of Service as an abstraction of autonomous software component regardless of any underlying implementation. Any service can then be run separately to provide the function it was designed for or be combined with other services into composite ones to provide a new value-added function. In this way, services act as loosely coupled building blocks that can be assembled into a network of services to create flexible, dynamic business processes and agile applications [START_REF] Papazoglou | Service-oriented computing: State of the art and research challenges[END_REF]. The SOC paradigm promise was quickly realized through Software Oriented Architectures (SOA) that enable the complete ecosystem for interoperable service discovery, utilization, and combination to support virtually any business process in any organizational structure or user context [START_REF] Georgakopoulos | Service-Oriented Computing[END_REF]. One of the most successful realizations of SOA is Web services which extends SOA principals over the Web as the largest infrastructure for service interactions. Web services took advantage of Web protocols and their highly dynamic evolution. They in turn contributed to the emergence of new application-to-application interactions over the Web in a service centric perspective that progressively replaced the data centric perspective of the Web. Web services was first designed over XML-based standards resulting from intensive standardization activities for all Web services lifecycle aspects including WSDL, SOAP, and UDDI, among others, respectively for service description, messaging, and registration/discovery. This variant of Web services implementation usually referred to as SOAP Web services gave way to Representational State Transfer (REST) [START_REF] Fielding | Principled design of the modern web architecture[END_REF] Web services also referred to as RESTful Web services [START_REF] Richardson | RESTful Web Services[END_REF][START_REF] Pautasso | RESTful Web Services: Principles, Patterns, Emerging Technologies[END_REF]. REST architecture relies on HTTP protocol and brings more flexibility for service interactions. The simplicity and flexibility of REST motivated the shift towards RESTfull Web services which consequently became the most commonly advocated approach for developing service-based applications. REST architecture is also the most used for Application Programming Interface (API) developments which supports more features and communication possibilities than Web services. Quickly adopted and supported by the major IT firms, REST APIs are today established as the means for Web application interactions. They range from the most complex applications including Web giants (Google, Amazon, Microsoft, etc.) tools and processes to the most basic cases of connected devices in Internet of Things (IoT) contexts. Following the service integration paradigm, APIs are also composed into bigger applications called Mashups. The last most-known variant of service implementations exposing the functionalities on the Web are Cloud services. They go further than just the main functionality of Clouds as online data storage solutions to a wide range of cloud service categories including Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS), Function/Machine Learning as a Service (MLaaS) and more generally Every thing as a Service (*aaS).

ABSTRACT

II Semantically enabled service interactions

List of Tables

The success of Web services to propose a flexible and cost-effective way for distributed application development that meets enterprise interaction requirements, has significantly increased the number of available atomic and composite Web services. This large heap of 1.2. GENERAL RESEARCH CONTEXT AND MOTIVATION available services exponentially grows when it comes to building new composite services over all the composition possibilities. This straightforwardly rises the challenge of identifying relevant services either for single function invocation or for designing composite service for more complex tasks. First generation tools for service discovery based on their syntactic functional and non-functional descriptions fall short to face this challenge [START_REF] Medjahed | Introduction to special issue on semantic web services[END_REF]. At the same time ontologies and the Semantic Web were gaining a wide interest towards providing machine understandable Web contents [START_REF] Berners-Lee | The semantic web[END_REF]. Enhancing Web services using semantic Web standards quickly became a thriving area and gave birth to semantic web services [START_REF] Mcilraith | Semantic web services. Intelligent Systems[END_REF] as a new generation of Web services. Existing standards were extended with semantic dimensions describing service capabilities, eg. WSDL-S, and new ones were also proposed as a full semantic language for web services, eg. OWL-S. These languages mainly concern SOAP Web services and rather harden the complexity of service integration while the trend is to promote lightweight service architectures. Semantic handling is then left to an annotation process within service engineering frameworks. Such process relies on external semantic resources to automatically annotate service operations and parameters with external resources [START_REF] Saquicela | Semantic annotation of restful services using external resources[END_REF]. Domain ontologies were largely used for service annotation with abstract semantic concepts. However the domain specific focus of ontologies makes them less relevant when it comes to connecting heterogeneous services with complementary functions from complementary domains to build composite services. Cross-domain ontologies such as DBPedia and then the Linked Open Data (LOD) brought some answers for "domain-independent" semantic service annotation. Recent advances in Machine Learning and Natural Language Processing gave rise to active researches to capture service functionalities and underlying semantics from text descriptions, interaction logs, and user feedbacks [START_REF] Labbaci | A deep learning approach for web service interactions[END_REF][START_REF] Zou | Deepwsc: Clustering web services via integrating service composability into deep semantic features[END_REF].

Over the last ten years, I have been particularly interested in the intersection of the two research topics of Web services and the Semantic Web. My aim was to bring innovative sound approaches that leverage all Web service life-cycle steps with native semantic awareness to achieve high level of successful and effective interaction in service-service scenarios within compositions and mashups as well as in user-service scenarios. I was particularly interested in defining declarative models with evolving rules to keep pace with context changes. Within this perspective, my research contributions started with semantic similarity measures proposal for service classification and recommendation, and progressively moved to handle personalized service-service and user-service interactions including privacy and trust awareness. These contributions appealed for the most hot topics in interaction with Web service research fields including (i) ontologies and Linked Open Data (LOD) for semantic similarity measures, (ii) Formal Concept Analysis (FCA), Configuration Theory, First Order Logic and Dynamic Condition Response (DCR) Graphs for declarative frameworks, (iii) Machine Learning for service interaction handling, and (iv) SOLID standards, 1.3. MANUSCRIPT ORGANIZATION Blockchain and Smart Contracts (SC) for privacy and trust in service interactions. These contributions were achieved in strong collaboration with colleagues and PhD students from University of Tours and other universities within international collaborations. They were mostly supported by two scientific projects, Smart Loire and SQVALD, funded by Région Centre Val de Loire. These projects provided application contexts with specific challenges respectively in the Tourism and Healthcare domains. This dissertation will go through these contributions with sufficient details to be self-contained and easily understood. In case of need for in-depth focus the reader can go through the corresponding published research papers which contain fully detailed description of each contribution with related work review, experiments and links on used libraries and datasets.

Manuscript organization

The manuscript is organized into five parts :

Introduction: This initial part, which contains the current chapter and Chapter 2, presents the general context of my research activities. It raises the identified research challenges, and summarizes key contribution I come up with to answer these challenges.

Semantically-Enabled Service Interaction (Part II): This part is dedicated to our contributions on enabling service interaction via semantic capabilities. Chapter 3 explores our work on ontology-based similarity. Chapter 4 discusses the details of our new LODbased similarity.

Context-Aware and Personalized Service Interactions (Part III) : This part presents the details of our contributions towards context-aware and personalized service interactions. A service perspective approach is discussed in Chapter 5, while Chapter 6 focuses on the perspective of running devices.

Handling Service Interaction Evolutions (Part IV) : This part highlights the details of our contributions towards handling service interaction. Chapter 7 discusses our work on handling evolutions via leveraging ML models. Chapter 8 describes the exploitation of Blockchain technology to set trustworthy service interactions.

Conclusion and Research Perspectives (Part V) :

This final part provides a general conclusion, sets the ongoing research efforts and suggests potential next steps to consider as future research directions. Chapters 1, 2, and 9 outline a summary of our contributions, highlighting the essential elements of research and providing insights on future perspectives. The remaining chapters elaborate on the deep details of the proposed contributions, providing an in-depth comprehensive exploration of each one.

RESEARCH PROBLEMS

This chapter introduces the research challenges we identified in service interaction contexts and summarizes the scientific contributions achieved towards dealing with these challenges. In Section 2.1, I discuss three main research challenges: Semantically-enabled service interactions, in Section 2.1.1, Contextualized and user-centric service interactions, in Section 2.1.2, and Dynamic service interactions and evolution, in Section 2.1.3. Then, in Section 2.2, I give an overview of the ways we tackled each challenge respectively. For each contribution, I discuss the main ingredients, the formal models, and the architecture elements to help understanding the main idea and the ways we proceeded to achieve it. I leave detailed presentation to dedicated chapters.

Research problems

After two decades of intense development and innovation, Web services have established themselves as an essential technology for fast establishing next generation real-world applications that may wrap a wide range of Web-accessible functions, resources, programs, databases, sensors, devices, etc. This unprecedented proliferation of Web services not only accentuated the already known challenges of service discovery and composition, but also raised new ones regarding extending service interactions to user-centric perspectives. This includes the challenge of contextualizing and personalizing service recommendation, handling user feedbacks, preserving privacy and trust while evolving in highly dynamic contexts, etc. For both types of challenges we believe that a successful approach should provide declarative formal models capable of capturing semantic meanings underlying service descriptions, functions, compositions, evolutions, and interaction contexts. Our research activities towards achieving such approach mainly address the following specific research challenges.

Semantically-enabled service interactions

Handling Web services semantics was an evident answer for several efficiency problems faced by first generation Web services. Indeed, service management frameworks that relied only on syntactic descriptions of services were error prone because of the mismatch problem between descriptions of service functionalities and parameters. They were also time consuming because of the lack of abstraction structures of service collections which also leads to low accuracy when it comes to discover relevant services for specific use. Semantics brought new perspectives and challenges towards efficient automation of service life-cycle management with machine understandable and processable services. Too many approaches were proposed since then and covered different facets of enhancing Web service life-cycle 2.1. RESEARCH PROBLEMS management with semantic level. The main focus was to annotate services with abstract concepts from semantic resources such as domain ontologies. The abstraction semantics are then used to identify services in discovery process, to classify services into classes based on their semantics, and to decide how likely two services can successfully build a new composite one that matches the expected value-added function in composition process or to which end one service can substitute another service to ensure continuous composition running.

These intensive research and development activities in semantic Web service management resulted in significant improvements of Web service management tools and frameworks to achieve high performance and accuracy especially in basic use-cases with optimum conditions of use including: identified specific domain, full accurate descriptions of Web services, rich and expressive domain ontologies, etc. In general, however, such conditions are not always met. Web service composition process may involve heterogeneous services with complementary functions referring to complementary domains rarely covered by one single domain ontology, rising evident need for cross-domain semantic resources. In addition, service descriptions provided by service providers may not be exhaustive as this task requires a high domain expertise to choose the most appropriate description terms. Service descriptions may also result from aggressive advertising and campaigns to promote providers services, and again used terms may not be the appropriate ones to use. Consequently the right meanings for service functions may not be captured by semantic annotation process. It therefore becomes necessary to complete service annotation with data from feedbacks on real service running and interactions.

Once the semantic service annotation challenge is tackled, the next challenge to cope with is twofold. First, defining efficient metrics and measures that exploit semantic annotation together with additional criteria to provide accurate similarity measures for Web services. Second, building dynamic and flexible structures over the similarity measure that makes it easy to quickly and efficiently identify relevant services for a given usage. To this end, typical graph-based representations could bring interesting solutions. However, they require the integration of a semantic layer to support relationships between atomic Web services as well as those within compositions. The built structures should in turn serve as flexible search space for service discovery and for composition building. Efficient algorithms have therefore to be defined over the classification structure to support the discovery process as well as to generate successful compositions through the use of planning tools.

Another major challenge yet to be addressed is to define the underlying formal models for a full round-trip service management framework that enables accurate annotation, flexible classification, efficient discovery, reliable composition generation, and efficient recovery 2.1. RESEARCH PROBLEMS from service failures. These points among others show that there are still challenges lying ahead of the semantically-enabled service interactions. This dissertation is partly focused on our contribution regarding these challenges.

Contextualized and user-centric service interactions

Need for personalized service recommendation

The digital transformation of the society brought new ways and opportunities for service-based application development and consuming. Powerful mobile devices have become a basic must for even trivial daily-life use. They allow access to a wide range of Mobile and Web applications covering professional use such as shared workspaces, calendar scheduling, remote meeting, team managing, etc. as well as personal use such as weather forecast, gaming, home monitoring, online shopping, etc. In many cases these applications are built as mashups of existing services and APIs through the use of mashup tools and platforms such as ProgrammableWeb. These tools have significantly lowered the barriers to mashup development allowing less experienced contributors with few programming skills to assemble their own applications [START_REF] Cappiello | Information quality in mashups[END_REF][START_REF] Xie | Personalized service recommendation with mashup group preference in heterogeneous information network[END_REF] in an intuitive way. This straightforwardly led to evident increase of available services resulting in an unparalleled large scope of choices on selecting services for further mashups. Consequently, the technical facility for mashup building comes up against the challenge of choosing the appropriate services to compose from the plenitude of the available ones.

In this context, semantically enabled frameworks (Section 2.1.1) can bring partial answer as they can be employed as the preliminary selection criteria indeed for coarse ranking. Semantic matchmaking process will likely find a large set of candidate web services with close semantic similarity. The challenge then is to define additional ways to achieve highly relevant service recommendation approaches able to provide mashup builders with the most relevant services to achieve their specific added-value needs. This challenge of service recommendation fine-tuning has been addressed through considering contextual information characterising the situation for service interaction, which led to the context-aware services discovery research topic defined as the ability to make use of context information to discover the most relevant services for the user [START_REF] Suraci | Context-aware semantic service discovery[END_REF][START_REF] Bhargava | Bootstrapped discovery and ranking of relevant services and information in context-aware systems[END_REF]. Contextaware service discovery was widely studied from the perspective of ubiquitous computing. In the earlier proposed approaches the context was usually reduced to the user/service location. More advanced ones introduced a wide range of heterogeneous contents relying on predefined ontologies and user context history with the promise to delivering "the right information at the right place and the right time" to users [START_REF] Bhargava | Bootstrapped discovery and ranking of relevant services and information in context-aware systems[END_REF]. Service interaction contexts may vary within highly heterogeneous situations making it difficult for any approach 2.1. RESEARCH PROBLEMS to define a global view with sufficiently relevant criteria to capture service usage interest and therefore provide an accurate service recommendation. This straightforwardly raised the need to consider specific application domains to focus on relevant selection criteria for service recommendation [START_REF] Casati | Developing mashup tools for end-users: On the importance of the application domain[END_REF]. This is the case of the Tourism domain for example where the need for service recommendation systems have grown as far as the tourists need shifted to more personalized experience.

Although a lot of work has been done in this direction, there is still a gap regarding user contribution within Mashup creation in intuitive and efficient way. The challenge that still needs to be addressed is to achieve efficient framework that first provides inexperienced users with intuitive ways to create abstract mashups that capture user needs and preferences and then rely on efficient formal and declarative models to derive relevant context-aware and domain specific mashup instances that meet the user needs. This dissertation tackles this twofold challenge from the perspective of Tourism domain. We discuss our contribution towards a visual intuitive language for mashup creation and a configuration-based framework for personalized and user-centric service recommendation in the Tourism domain.

Need for fluent user-side service running management

In the same context of digital transformation of the society, end-users use mobile devices to interact with the services and applications discussed so far from the perspective of personalized service recommendation. The most commonly used devices are smartphones and pads. However, depending on the interaction context the mobile device may range in a larger variety including sensors, screens, home-devices, wearable devices, etc. What becomes more common is that the user may interact with the same service from more than one device simultaneously or more usually in sequence to continue an interaction on a second device when it becomes impossible or uncomfortable to use the first one. The related research topic is known as service synchronization and migration in multipledevices scenarios [START_REF] Hamilton | Conductor: Enabling and understanding crossdevice interaction[END_REF][START_REF] Wolters | Cross-device integration of android apps[END_REF]. The best known contributions that addressed this topic relied on the concepts of Liquid Software [START_REF] Hartman | Liquid software: A new paradigm for networked systems[END_REF] to adapt the service interactions to the used device [START_REF] Mikkonen | Towards liquid web applications[END_REF][START_REF] Gallidabino | On the architecture of liquid software: Technology alternatives and design space[END_REF].

Although these approaches succeeded to adapt service interactions to the chosen running device, they mostly relied on service-side synchronization. Cloud-based solution indeed brought a wide range of support regarding elasticity and resource management for service execution. On the user-side, however, these approaches do not yet allow to obtain simple data-flow without restarting user-service interaction sessions from scratch each time the user moves to a new device.

RESEARCH PROBLEMS

Successful approaches towards the challenge of user-side service migration/synchronization should tackle the following issues to provide the user with high quality of experience: First, it should review synchronization and data-flow handling within the REST protocol. Second, it should provide efficient matching algorithms between user-service interaction requirement and devices capabilities as well as efficient device recommendation for service execution. Last, it should rely on sound formal models that guarantee the approach to be generic and extensible to any application scenario. This dissertation discusses our contribution towards these challenges.

Dynamic service interactions and evolution

Need for handling dynamic evolution of service interactions

Web services compositions and Mashups designed through the challenges discussed so far are then run to provide the expected results. They usually hold over several interaction sessions. Therefore, the next important challenge to cope with is the dynamic evolution of such mashups and compositions over time and the interaction relationships services may hold within. Basically, the most evident relationship between two services is the composition relationship to yield composite added-value services. With the development of mashups and new generation Web services the composition is generalized to collaboration relationship defined as the ability of two or more services to work together to satisfy users requests. Classifying Web services based on their similarities yields the second type of relationship between services which is the substitution or replaceability between the highly similar services to avoid mashup breaking in case of service failure. Substitution is naturally generalized into competition between services providing the same functions being provided by concurrent entities.

The quick and phenomenal progress of social networks development and their highly dynamic evolution inspired researchers on the Web services to model Web service interaction relationships as a social network of services [START_REF] Maamar | Using social networks for web services discovery[END_REF] giving birth to the concept of social Web services [START_REF] Maamar | Towards a method for engineering social web services[END_REF]. In such network, services which are the entities identify those peers with which they'd like to work (collaboration), those that can replace them in case of failure (substitution), and those that compete against them for selection (competition). In the same direction, new types of relationships such as subscription have been proposed later to capture situations when a service tries to keep updated with the evolution of another [START_REF] Labbaci | Follow the leader: A social network approach for service communities[END_REF].

Following the social network metaphor, Web service networks allow comments and feedbacks over services and relationships. This generates relevant new data yet to be considered to keep high quality mashups, or in the in contrast, to prevent the failure of 2.1. RESEARCH PROBLEMS badly constructed ones. Feedback analysis allows also to evaluate the real quality of service (QoS) of given services that can be set against the QoS given by service providers. This highly competitive network of services forces service providers to regularly update their deployed services in order to continue taking part in the engaged collaborations. They also deploy new services to answer new needs and/or follow new trends. These updates and deployments are also described through additional data, largely free text. Consequently, social Web service computing brought new interesting representation models that capture the continuous service deployment and the dynamic interaction relationships services may partake during their lifetime. It however raised the new challenges of handling the generated data, and analyzing it to ensure and maintain network consistency and evolution while providing accurate relationship recommendations. Although many research works tried to tackle this challenge through the use of Machine Learning approaches for text analysis of descriptions and comments on services and their interactions [START_REF] Labbaci | A deep learning approach for web service interactions[END_REF], there is still a need for a more general framework that relies on both semantically-enabled models and machine learning tools.

Need for trustworthy and dynamic service execution

Web services are widely used in today's business world as the functional part of larger Business Processes which also integrate other enterprise perspectives including data and control. In its abstract representation, a business process is modeled as a graph of tasks, events and control operators [START_REF] Van Der Aalst | Business process management: A survey[END_REF]. Service-based business processes rely on Web services to implement their tasks. Business processes are designed to achieve business goal which usually involves the collaboration of many entities in decentralized environments. In such open environments, collaborating entities are also competing for their own business success which leads to untrusted behavior. Therefore, successful collaborations require either a central coordination between involved parties or at least an agreed on reference broker to mediate and control the execution. The first case, mostly known as orchestration, faces several issues including central node congestion, additional fees, etc. The second case, known as choreography, is more suitable for open collaboration as entities collaborate directly without intermediaries. They however still need to rely on well-defined collaboration rules and policies to trust each other towards successful collaborations. These issues have been widely addressed by state-of-the art approaches that usually rely on formal and transactional models to define collaboration rules and on formal verification to ensure execution soundness [START_REF] Van Der Aalst | Choreography conformance checking: An approach based on BPEL and petri nets[END_REF][START_REF] Bhiri | Ensuring customised transactional reliability of composite services[END_REF][START_REF] Hamel | Verifying composite service transactional behavior with EVENT-B[END_REF]. These approaches fail, however, to dispense with the need for independent third party to guarantee compliance with trust policies between engaged entities.

The emergence of Blockchain technologies for decentralized and transactional data shar-

CONTRIBUTION SYNTHESIS

ing across a network of untrusted participants brought the right solution that fits well with the requirements of business process choreographies executions. It didn't take long for the Blockchain technologies to be adopted as infrastructure that handles trustful interactions between business entities without any need of a central authority [START_REF] Hull | Towards a shared ledger business collaboration language based on data-aware processes[END_REF][START_REF] Weber | Untrusted business process monitoring and execution using blockchain[END_REF][START_REF] Mendling | Blockchains for business process management -challenges and opportunities[END_REF][START_REF] Falazi | Blockchain-based collaborative development of application deployment models[END_REF][START_REF] Brahem | Blockchain's fame reaches the execution of personalized touristic itineraries[END_REF]. These approaches mostly rely on second generation blockchains which allow for complex task running through programs called Smart Contracts that enforce the terms of agreement between the untrusted parties. The proposed approaches focus on execution control flow of business processes while leaving transactional flow to the basic blockchain specification that follows standard ACID model which fails to capture advanced reliability requirements of complex business process executions. There is therefore need to define suitable models to handle the transactional flow of blockchain-based process executions.

Collaborating business entities evolve in highly dynamic environments that appeal for continuous updates and improvements of their internal processes to keep high competition level. These dynamic changes may affect the collaborations in which the enterprise takes part. Changes may also directly concern the global collaboration due to new external business policies that should be taken into account. In both cases, changes must be notified and propagated to the involved partners. Change propagation in process choreographies has also been tackled prior to blockchain-based approaches [START_REF] Fdhila | Dealing with change in process choreographies: Design and implementation of propagation algorithms[END_REF]. In the blockchain-based ones however it is still challenging because of the non-mutable nature of shared data. There is therefore need to bring additional levels to cope with the change propagation within blockchain based choreographies execution frameworks. This dissertation will discuss our contribution towards transactional flow modeling and change propagation model for blockchain-based choreographies.

Contribution Synthesis

In this section, I give a summary of our contributions regarding the research problems discussed so far. I will discuss the intuition behind each contribution and its main ingredients including the formal model, the architecture, and the specific application context. Each contribution will then be detailed in a dedicated chapter of the manuscript.

Semantically-enabled service interaction framework based on Ontologies, Formal Concepts Analysis, and Linked Open Data

Our contribution towards the challenge of semantically enabled service interactions discussed in Section 2.1.1 is mainly focused on proposing efficient semantic similarity measures and then designing service life-cycle modules based on these similarities. We first proposed 2.2. CONTRIBUTION SYNTHESIS ontology-based semantic similarity measure within a fully integrated framework for service composition, which appeals for concepts lattices and graphs for service classification and composition generation. Then, following the evolution of semantic Web to Linked Open Data, we proposed a LOD-based semantic similarity measure for service recommendation. The proposed LOD-based similarity measure acts then as the central component of an open source library we developed and proposed to the community as an API and as a Maven dependency. These contributions are summarized in the following subsections.

Ontology-based similarity and Formal Concept Analysis for Web service composition

This contribution starts by proposing an Integrated Development Environment for Composite Services Engineering (IDECSE) that considers semantics in all the composition steps: analyzing user query, classification of services in the registry based on their features semantic relatedness, composing services, and verifying the composition process. The proposed architecture has 3 main components: (i) Service matching component which relies on efficient similarity measure computing, (ii) Service classification component that provides a flexible organisation of service registry to support efficient service discovery, and (iii) Composition generation component that allows the establishment of coherent composite services relevant to the desired functionalities.

Semantic similarity measure for Web services The IDECSE Framework deals with semantic Web services features which are annotated through ontological concepts. Web service description files features include functional features such as Inputs, Outputs, Preconditions, and effects, and non-functional ones such as QoS and service invocation constraints. We propose a similarity measure that focuses on functional features and leaves non functional ones to the composition process. The proposed similarity measure is defined as the sum of weighted similarities between pairwise service Inputs, Outputs, Preconditions, and Effects, denoted as follows for any two services S i and S j :

σ(S i , S j ) = w 1 Sim In (S i , S j )+ w 2 Sim Out (S i , S j )+w 3 Sim P rec (S i , S j )+ w 4 Sim Ef f (S i , S j )
where 4 k=1 w k = 1. The weights w i allow modeling the similarity measure to be adapted to different application cases where it may be required to focus on IO only or any other possible combination of the four aspects. In the case where no specific preferences are given, these weights are equally set to 0.25.

Each of the four Sim functions is in turn defined as the sum of two weighted conceptbased and data-type based measures as follows for the case of Inputs and analogously for 2.2. CONTRIBUTION SYNTHESIS the three other dimensions:

Sim In (S i , S j ) = u In 1 Sim Co (In i , In j ) + u In 2 Sim DT (In i , In j ) where u In 1 + u In 2 = 1.
Web services features are semantically annotated using concepts from ontologies. Measuring their similarity turns out to measuring the similarity between their annotation concepts in the considered ontologies. Comparative study of the state-of-the-art approaches on semantic similarity measures have shown a better correlation coefficient and higher efficiency rates for the measure proposed in [START_REF] Sánchez | Ontology-based semantic similarity: A new feature-based approach[END_REF] which follows the Tversky model [START_REF] Tversky | Features of similarity[END_REF], where common taxonomical features tend to increase similarity while the non-common ones decrease it. We therefore adapt the Sanchez formulas to define Sim Co .

In the same way, we reviewed and adapted the best state-of-the-art data-type measures to define Sim DT . Following works in [START_REF] Plebani | URBE: Web service retrieval based on similarity evaluation[END_REF] and [START_REF] Tibermacine | Wssim: a tool for the measurement of web service interface similarity[END_REF] we propose a practical measure between different data-types that defines abstract groups of compatible data-types and then assigns similarity values to each pair of groups. Considering Sim DT prevents meaningless composite services built upon highly similar services with respect to Sim Co which however fail to match their data-types. Following this intuition, the weight u In 1 must be higher than u In 2 to focus on semantic similarity while keeping data-type similarity for checking the composition consistency. Conducted experiments confirmed that the combination u In 1 = 0.80 and u In 2 = 0.20 gave the highest accuracy.

The proposed Web service semantic similarity measure within the matching component plays the central role in the IDECSE framework as it is the basis for service matching, classification, discovery and composition as it will be discussed hereafter.

Flexible service classification with Formal Concept Analysis

The way services are organized within the service registry highly impacts the efficiency of service identification for any given need. We therefore propose to build the classification component of IDECSE upon the well-established formalism called Formal Concept Analysis (FCA) [START_REF] Ganter | Formal Concept Analysis: Mathematical Foundations[END_REF] and particularly its derived structures called Concept Lattices.

Based on partially ordered sets theory, FCA allows to structure the data into a hierarchy of partially ordered concepts called the Concept Lattice. Each concept corresponds to a maximal set of objects having in common a maximal set of attributes. The concept lattice hierarchical relation is based on the dual partial order between sets of objects and dually sets of attributes. This structure and its properties motivated the use of concept lattices as indexing structure for information retrieval either by direct querying or by progressive navigation [START_REF] Messai | Many-valued concept lattices for conceptual clustering and information retrieval[END_REF][START_REF] Messai | Using domain knowledge to guide lattice-based complex data exploration[END_REF].

Following this direction we apply FCA to automatically organize services into a concept 2.2. CONTRIBUTION SYNTHESIS lattice based on the semantic similarity defined so far. FCA applies on binary matrix data called formal context, which is not the case of service data set. We operate data transformation as follows. Services are considered as attributes and objects and encoded within a matrix SeSimM at of service similarities. We define a similarity threshold θ ∈[0 , 1] and generate a service similarity context matrix SeSimCxt from SeSimM at. SeSimCxt is in turn used to generate a formal context SimCxt represented as a triple (S,S,R Sim θ ), where S is a set of services, and R Sim θ is a binary relation indicating whether two services can offer similar functionality or not.

Starting from SimCxt we can build the corresponding concept lattice structuring the services in the registry. We define querying and navigation algorithms upon the service concept lattice: (i) to find equivalent, similar, and composable services to the requested need, (ii) and to select the most relevant services for the purpose of substitution process to maintain a composite Web service application functionality as much as possible.

Depending on the request need, selected relevant services are transmitted to the corresponding component of the framework.

Planning and Graph-based service composition

The last component of the IDECSE framework is the composition generator. It takes as input a set of similar services returned by the previously presented components to provide a set of coherent composite services relevant to requested function. This component appeals for AI planning techniques and graphs together with the semantic similarity measure and QoS constraints to ensure successful compositions. The key point is the compatibility between Input-Output interfaces of the services to be connected within the resulting composite ones.

The highest level of compatibility is achieved with identical matching between Input-Output which feats the use of AI Planning. In this case, Web service composition problem is mapped to a planning problem based on transformation rules defined in [START_REF] Hatzi | The PORSCE II framework: Using AI planning for automated semantic Web service composition[END_REF] and using the Planning Domain Definition Language (PDDL) [START_REF] Ghallab | Pddl -the planning domain definition language (version 1.2)[END_REF]. In this mapping, each service S i is represented as a state St i , its inputs and preconditions are represented as the state preconditions prec(St i ) = S i Inputs ∪S i P reconditions , and its outputs and effects are represented as the state effects ef f (St i ) = S i Outputs ∪ S i Ef f ects . We apply STRIPS planning algorithms on the resulting mapping problem to generate possible solution plans corresponding to possible service compositions.

In the general case however, there may be no exact Input-Output interface matching. The composition generator relies on the proposed semantic similarity measure to compute approximate matching possibilities. The similarity measure σ(S i , S j ) is redefined to apply on the outputs/effects of S i and the inputs/preconditions of S j . The obtained similarity values are mapped to logical match type as defined by [START_REF] Lécué | A formal model for semantic Web service composition[END_REF]. The logical match types are Services with "Match" or with "Plug-in" are most likely to lead to successful composition. The next step consists of considering these services to build a directed weighted graph with nodes being services and edges being composability values. We formalize satisfiable compositions as S comp ={ I comp , O comp } where I comp is a set of inputs that present a valid degree of match with the set of requested Inputs S R In and O Comp is a set of outputs that present a valid degree of match with the set of requested Outputs S R Out . Then, service composition solutions are those corresponding to paths in the graph between S R In and S R Out . The graph search algorithm is enhanced by considering QoS constraints over services to fine-tune composition solutions ranking.

The work described in this subsection was conducted during the PhD of Ahmed Abid defended on July 2017. More details will be given in Part II, Chapter 3.

Linked Open Data based similarity for Web service recommendation

This contribution takes advantage of the evolution of Semantic Web to Linked Open Data (LOD) to propose efficient similarity measures that operate for any domain overcoming the shortcuts of ontology-based similarities which usually focus on few specific domains. The contribution is threefold: (i) we propose a new similarity measure, called LODS, that assesses the matching degree between pairs of terms represented with LOD resources, (ii) we apply LODS for context-aware service recommendation, and (iii) we propose an open source LOD-based similarity measure library. LODS: a Linked Open Data based Similarity Measure LOD initiative [START_REF] Bizer | Linked data -the story so far[END_REF] aims at making a gigantic interlinked database of interlinked datasets/resources following few basic interlinking principles [START_REF] Berners-Lee | Linked data[END_REF]. LOD have quickly grown and led to an important source of semantic information with high informativeness that can be useful for many applications including semantic similarity calculation [START_REF] Meymandpour | Linked data informativeness[END_REF]. Following these advances, we propose LODS, a LOD-based similarity measure that takes advantage of LOD properties and resources interlinking to compute similarity between any two terms. DBpedia [START_REF] Lehmann | DBpedia -a large-scale, multilingual knowledge base extracted from wikipedia[END_REF], which realizes LOD vision by structuring Wikipedia content and interlinking it with external datasets, acts as a central kernel of the LOD cloud. We therefore consider it as a starting point to glean initial data to compute similarity degree between compared concepts. Then, we follow interlinks to enrich data from other datasets through a data augmentation process. Among the numerous LOD properties, LODS focuses on the following ones:

Instances: LOD resources are described with various multi-domain ontologies making it 2.2. CONTRIBUTION SYNTHESIS possible for a given LOD concept to have multiple instances in different ontologies with different levels of description richness.

Categories: LOD resources can be arranged into categories with different classification granularities and depths.

Resource properties: LOD resources are described with different properties which distinguish and characterize resources.

Interlinking: LOD resources are usually interlinked to each other using owl:sameAs.

Considering these properties we define LODS as the average of 3 sub-measures: Instancebased (SimI ), Category-based (SimC ), and Property-based (SimP ). Formally, for any two LOD resources a and b:

LODS(a, b) = avg(SimI(a, b), SimC(a, b), SimP (a, b))
SimI exploits the taxonomic structure of ontological concepts used to instantiate resources. It extracts resources features by getting their super-concepts from each annotating ontology. It then applies the Tversky model on the set of features. The final similarity value is the average of values obtained for all the annotating ontologies.

SimC follows the same principle as SimI but applies on taxonomic structure of classification schemata and limits the number of extracted super and sub categories while extracting resources features.

SimP exploits ingoing and outgoing resources properties. It applies Partial Information Content (PIC) measure to focus on the discriminant properties rather than the commonly used ones.

The detailed formalization of these sub-measures is given in Chapter 4. The intuition for combining these sub-measures is to take into account the LOD reality where resources are not systematically described with ontological concepts. They are neither always arranged in categories nor well distinguished with properties. The objective is to reduce the negative impact of poorly described resources on the resultant similarity score. Each measure applies on enriched data by following links between different dataset. We define SimI and SimC as feature-based measures based on the Tversky model [START_REF] Tversky | Features of similarity[END_REF] instead of distance-based methods. This is mainly because in multi-domain ontologies, taxonomic relations do not necessarily represent uniform distance [START_REF] Sánchez | Ontology-based semantic similarity: A new feature-based approach[END_REF].

Context-aware LOD-based service discovery LODS similarity measure is applied for context-aware service discovery and recommendation. The proposed approach consists of the following steps: (i) We define an annotation model that captures both functional properties for service actions and non-functional properties for contextual information. (ii) We enrich the service model instances with semantic data from LOD. (iii) We propose 2.2. CONTRIBUTION SYNTHESIS matchmaking algorithms based on LODS to identify relevant services for user needs in a given context. (iv) We illustrate the approach effectiveness in the tourism context provided by the SmartLoire project.

(i) Context-aware service annotation model: We represent a service S as a triple ⟨n s , F s , N F s ⟩, where n s is the service name, F s = {f 1 , f 2 , . . . , f i } is the set of service functionalities, and N F s = {P 1,s , P 2,s , . . . , P n,s } is the set of service non-functional property sets. Due to the diversity of non-functional information, these sets are generally organized in profiles, where each profile P i,s describes a specific context information domain.

(ii) LOD-based enrichment of service model instances: Functional service features in F s are annotated with LOD resources starting with DBPedia and following interlinks as in the previous section. Non-functional features however may be either quantitative or qualitative properties. Only qualitative properties which take string values can be annotated with LOD resources.

(iii) Extending LODS for context-aware service discovery: We define a two-step discovery process. The first step considers functional features and their LOD annotating resources and relies on LODS measure for computing service similarities with respect to requested service. The second step considers non-functional properties with a conditional similarity measure which applies LODS on LOD annotated qualitative properties and adequate numerical similarity measures on quantitative properties. The overall non-functional similarity is a weighted combination of the similarity values of the set of profiles. The weights allow to define importance to a given profile rather than another depending on the context.

(iv) Applying the approach in the Tourism domain: Within the SmartLoire project, we consider a dataset of touristic services provided by ADT37 (Agence Départementale de Tourisme d'Indre-et-Loire) through its platform Tourinsoft (http://www.tourinsoft.com/). The dataset contains 1632 services classified into different touristic offer categories and annotated through functional and non-functional properties. We applied the previously discussed steps and evaluated the discovery relevance by implying more than 20 real users in the query definition and results ratings. Obtained results from different metrics demonstrated the high matchmaking relevance in both functional and non-functional discovery phases.

LDS: LOD-based similarity measures library In order to go further than the LODS similarity measure, we propose LDS (Linked Data Similarity) Library as an open source Java software library of LOD-based semantic similarity measures. LDS defines a generic, reusable, and extensible architecture that integrates the best-known existing LOD-based similarity measures and supports both developers and researchers who intend to use these implemented measures or develop their own new ones.

LDS development follows the following requirements: (i) Simple design to facilitate the reuse of the tool and provide developers the ability to extend and use it with their developed semantic measures; (ii) Efficient LOD querying, caching and indexing to ensure similarity calculation efficiency and scalability; and (iii) Extensibility to offers developers a way to implement rapidly their measures and incorporate the library with their work.

The LDS architecture has 5 main components: (i) Similarity Engine which acts as the interaction interface of LDS with external programs. (ii) LOD-based Similarity which calculates the similarity values. (iii) Linked data Manager which retrieves data for similarity calculation. These two components act as plugability layer allowing to easily integrate new similarity measure as subclass of LOD-based Similarity and the corresponding subclass of Linked data Manager. (vi) Linked data Indexer implements a mechanism for data indexing and caching to allow scalability and efficiency of LDS. (v) Finally Linked data Benchmark is used for testing and measures evaluations. The full architecture of LDS with detailed description of its components is provided in Part II, Chapter 4.

In its current version the library implements the following LOD-based similarity measures: LODS and its sub-measures SimI, SimC, and SimP discussed earlier, Linked Data Semantic Distance (LDSD) [START_REF] Passant | Measuring semantic distance on linking data and using it for resources recommendations[END_REF] and its extensions [START_REF] Passant | Measuring semantic distance on linking data and using it for resources recommendations[END_REF][START_REF] Alfarhood | Exploiting Semantic Distance in Linked Open Data for Recommendation[END_REF], Resource Similarity (Resim) [START_REF] Piao | Computing the semantic similarity of resources in DBpedia for recommendation purposes[END_REF] and its extensions [START_REF] Alfarhood | Exploiting Semantic Distance in Linked Open Data for Recommendation[END_REF], and Partitioned Information Content Similarity (PICSS) [START_REF] Meymandpour | Enhancing recommender systems using linked open data-based semantic analysis of items[END_REF].

In addition, to evaluate the ease of usage and extensibility of LDS, we proposed a new LOD-based similarity measure, Extended Partitioned Information Content Similarity (EPICS), which extends PICSS by considering an additional set of features called similar features, which considers the similarity between resources based on shared properties and directions. The evaluation results not only highlighted the potential of EPICS but more importantly the effectiveness of LDS as a core library for composing, implementing, and testing new similarity measures.

The work described in this subsection was conducted during the scientific stay of Nasreddine Cheniki at the University of Tours between 2016 and 2019 and during the PhD of Fouad Komeiha to be defended in 2023. More details will be given in Part II, Chapter 4.

Semantic and configuration-based contextualized and user-centric service interactions

Our contribution towards the challenge of contextualized and user-centric service interactions discussed in Section 2.1.2 is twofold following two user-service interaction perspectives: (i) service perspective and (ii) running device perspective. From the service perspective, we propose an approach based on Configuration Theory [START_REF] Stein | Functional models in configuration systems[END_REF] for service composition into Mashups. The approach relies also on a set of visual artifacts as Domain 2.2. CONTRIBUTION SYNTHESIS Specific Visual Language to allow end-user express preferences and constraints on the built Mashups. These artifacts are connected with a rule-based declarative language for consistent Mashup generation. From the running device perspective, we propose an architecture following Liquid Software principals [START_REF] Hartman | Liquid software: A new paradigm for networked systems[END_REF] to allow for smooth service migration from one device to another from the user-side. We define semantic and rule-based migration context to ensure service interaction continuity while switching to new devices. These two contributions are summarized in the following sections.

Personalized and context-aware Mashups: A Configuration-based approach

As discussed in Section 2.1.2, high context-awareness is achieved with domain specific approaches. In this work, we tackle the problem of context-aware service interactions from the Tourism domain perspective and propose a declarative approach for Mashup building based on two main ingredients: (i) A visual intuitive language that allows user build an abstract Mashup and express constraints and preferences and (ii) a configurationbased technique to map the abstract Mashup with the relevant service instances while ensuring compliance with the expressed constraints and preferences. The overall approach is implemented within the CART system, a Web/Mobile framework for personalized trip planning in the Val-de-Loire French region.

Visual abstract mashups

We propose a Domain Specific Visual Language containing a set of graphical artifacts with drag-and-drop actions and a set of simplified forms to express user constraints and preferences. The graphical artifacts correspond to the possible attractions, called Points of Interest (POI), that can be done during a touristic trip in the Val-de-Loire, typically Castles and Museum, Gardens and Open spaces, Events, etc. It also includes logistic elements such as Restaurants, Transport (public or car/bike rental). An abstract mashup is then the sequence of artifacts chosen by the user to define her/his trip. Additionally, preferences and constraints can be expressed through intuitive forms built upon the set of service properties. Typical global constraints can be the visit duration as a cumulative value of individual duration and the total budget the tourist should not exceed. Preferences can be expressed over the POI categories such as indoor vs outdoor, guided tour possibilities, etc. Additional contextual constraints such as weather, traffic, etc. are also captured.

The graphical artifacts are mapped to abstract services with corresponding functionalities. The sequence of abstract services is called the mashup query. The preferences and constraints are mapped to semantic rules and called the configuration knowledge. Both will be considered by the service configuration module to derive consistent Mashup in-2.2. CONTRIBUTION SYNTHESIS stance that provides relevant trip plans to the user. The resulting plans are also presented through a user friendly visualisation including Maps and additional representations of the trip steps.

Configuring service mashups

The key point of the proposed approach is the configurationbased service mashup. We formalize the composition problem through the Configuration theory introduced in [START_REF] Stein | Functional models in configuration systems[END_REF] under the property-based configuration model. In this model, a final configuration product is obtained through the aggregation of a set of property-value pairs using a set of pre-specified operators that allows maintaining the configuration in a coherent state by proposing possible compositions and pruning inconsistent ones. Following this model, we formalize the service mashup as a Configuration Problem CP = (m, R, CK) where m denotes the mashup query, R denotes the set of context-aware rules, and CK denotes the configuration knowledge used to aggregate services.

The configuration knowledge describes how to compose service instances by mean of configuration operators and configuration rules. It relies on service's functionalities, property-value pairs, to build composition called functional connections. These functionalities are aggregated through configuration operators that basically apply cumulative operators (eg. addition) on common service properties and composition operators on distinct properties. Configuration rules are a set of restriction rules that guide the configuration process and limit the composition search space.

Configuration solutions are sequences of service instances corresponding to the abstract mashup, following the configuration knowledge, and satisfying the context-aware rules. Formally, a configuration solution is a pair CS = (I, Q) where I refers to the set of items in the form (n, s) representing that the service s appears n times in the mashup to be configured and Q represents the set of mashup features (called quality) in the form of a pair (f, x) that defines the value x of the feature f . Q is progressively built from configuration knowledge CK and with respect to rules in R. The detailed formalization of the service configuration, the semantic matching between the abstract level and the instances, and the search algorithms will be provided in Chapter 5. There can be more than one valid configuration solution for a configuration problem. In this case it is possible to rank theses solutions based on ordering criteria defined on Q.

The CART framework for Personalized trip planning The proposed approach is implemented into a tool called CART (Configured mAshup Recommender application for personalized Trip planning) for personalized travel mashup. The CART's architecture is structured into 3 layers. The service Layer is in charge of collecting travel data from Web APIs in addition to DATAtourisme already used, eg. Google Maps, Google Direction, 2.2. CONTRIBUTION SYNTHESIS Google Places, and Forsquare. The Mashup Layer implements the configuration approach as a SpringBoot Application. The application layer is implemented as a client application consuming services from the mashup application. It includes UIs allowing users to build a query mashup for the trip plan indicating their preferences and constraints. In addition, CART provides end-users with interactive environment to define mashup query and visualizes visit plan recommendations for the Loire Valley French region.

LOD-based mashup reconfiguration

In CART, besides weather forecasting and transportation APIs, we have mainly exploited travel related-data representing places to visit , e.g., castles, museums, parks, events, restaurants and hotels, from Tourinsoft APIs in the context of Loire Valley French region (www.tourinsoft.com). Many other large data sets are however unexploited because they are sitting in isolated data silos. We propose extending the CART system with a semantic layer to constitute an integrated platform bringing together tourists data, locally events data, weather data, etc., from heterogeneous APIs. The extension relies on LODS similarity measure defined in Section 2.2.1.2. Following the LOD-based annotation and data linking, we first enrich the DATAtourisme ontology with contextual concepts from the LOD resources. We then apply LODS similarity measure to generate new service instance alternatives for the mashups already obtained by CART. We call this process a reconfiguration process.

The work described in this subsection was conducted during the PhD of Marwa Boulakbech defended on July 2020. More details will be given in Part III, Chapter 5.

User-side service migration in multiple-device contexts

In this work we tackle the challenge of providing fluent user-side service running management discussed in Section 2.1.2.2. We propose CUBE, a user-centric architecture following Liquid Software principals [START_REF] Hartman | Liquid software: A new paradigm for networked systems[END_REF] to allow for smooth service migration from one device to another from the user-side. We then define semantic and rule-based migration context to ensure service interaction continuity while switching to new devices. CUBE: a user-centric architecture for fluent service/data/session migration in multiple devices environment Our aim in this work is to provide users with usercentric framework that allows to synchronize user-service interactions over multiple devices and to perform smooth migration of such interactions between devices. Services are hosted and managed on Web servers or Cloud which usually allow for multiple device access. They however require the user to login each time a new device is used. Moreover, in most cases, users have to restart interaction sessions from scratch. Two typical scenarios can be considered to illustrate the need for alternative user-centric solution: a light-coupling 2.2. CONTRIBUTION SYNTHESIS scenario with email service and tight-coupling scenario with YouTube service. Considering server-side synchronization, starting email writing on a device and then moving to a second device requires the login on both devices and saving the written part of the email as a draft from the first device to avoid data loss and to continue from the second device. Similarly, for video streaming on YouTube, user should login from both devices and resume video from saved history session on YouTube.

As alternative that allows time and data saving, we propose the CUBE, a user-centric framework that follows Liquid Software principals and defines a layered architecture built upon REST and RESTful constraints to ensure smooth service synchronization and migration in multiple device contexts from the user perspective. With CUBE, both previous scenarios will be handled locally preserving data and session states without the need for multiple login. The user logs in from the first device then the session can be moved to a second device through the use of RESTful properties allowing to manage data status. The multiple-device user context is virtualized for the server which continues interaction as it was with the first device.

In its abstract representation, the CUBE is seen as a four component model geometrically represented as: a central point which represents the user, surrounded by a first cube, called INNER CUBE, representing the set of user devices, contained in turn in a second cube, called the OUTER CUBE, representing the set of services, and between the two cubes the POOL AREA hosting the user-service interactions through the devices. The layered CUBE architecture is made of five different layers: (i) Application, (ii) Request, (iii) Conversation, (iv) Data, and (v) Physical. It is based on an innovative approach with strong specification of principals and constraints of the REST and RESTful models to allow data fluidity and content adaptation to devices characteristics. The detailed descriptions of this architecture and each layer are provided in Chapter 6. We will also provide technical details on the CUBE implementation and illustration on real use of the system.

Semantic rule-based device recommendation for service-migration in multiple device environment A successful migration decision, whether it is done automatically or manually, requires to follow some criteria to know which target device is the most suitable for the service/application that will be migrated. Also, it has to capture the users preferences, timeline and other features related to security, reliability, compatibility of devices, constraints of the services, etc., in order to be able to suggest the right device. Although this issue has been widely covered from the cloud/server perspective as part of cloud resource management, efficient device recommendation is still a challenge from the user-side perspective. It is even more challenging as far as we consider the limited device computation performances and the lack of access to large semantic resources, such as Linked Open Data, for similarity calculation.

To address this challenge, We enhance CUBE with a declarative module that relies first on ontologies and semantic inference rules to ensure device recommendation. The approach is built upon three main contributions: (i) we first model the main concepts describing devices, services, users and contexts into a small OWL ontology that can be held on each device independently. (ii) Second, we define a set of typical semantic inference rules, in Semantic Web Rule Language (SWRL), formalizing the migration requirements based on the concepts of the ontology. (iii) Third, we implement the approach within a prototype that populates the ontology based on APIs and user interactions, applies a reasoning through the semantic rules, and infers device recommendations for service migration.

(i) OWL ontology core concepts: We conceptualize 4 main components: Device, Owner, Service, and Characteristic. Each of them contains specific sub-classes to handle service migration context diversity. We also define necessary properties to model the interactions and relationships between theses concepts. For example, the Owner class has two object properties with the device class: a device is ownedBy an owner, and the owner usesDevice. These two properties are different because a user can own several devices but only uses some of them at a time. Another property is: the user interactsWith the service. Furthermore, in order to define the relationship between the devices and their characteristics or the services with their requirement, we add two main properties. hasCharacteristics property: links between Device and Characteristic, while the requireCharacteristics property: links between Service and Characteristic.

(ii) Formalizing migration rules with SWRL: Based on the defined concepts and properties, we formalise service migration context and conditions through a set of inference SWRL rules. For example, R1: Device(?d) ∧ HasBattery(?d, ?b) ∧ swrlb : greaterT han(?b, 10) → Alive(?d, true) defines the condition to consider a device as alive whereas, R2: Device(?d1) ∧ Device(?d2) ∧ HasLocation(?d1, ?l) ∧ HasLocation(?d1, ?l) → InP roximity(?d1, ?d2) expresses under which condition two devices are considered to be in proximity.

CONTRIBUTION SYNTHESIS

Migration rules are usually a combination of other rules. For example R4 which requires R1, R2, and R3 is an example of migration rule expressing conditions to achieve a successful migration. R3: Device(?d) ∧ HasScreen(?d, ?c) ∧ W atchingService(?s) ∧ RequiresScreen(?s, ?c) → IsCompatiblewith(?d, ?s). R4: Device(?d1)∧Device(?d2)∧Service(?s)∧Alive(?d2, true)∧ InP roximity(?d1, ?d2)∧ IsCompatibleW ith(?d2, ?s) → M igrate(?s, ?d2).

(iii) Implementation: The proposed approach is implemented within an API. The ontology is designed using Protégé and the SWRL rule-based reasoning is performed through Apache Jena. The API manages and stores the facts and rules (both defined in Apache Jena) to finally compute the recommendation results. Facts are very dynamic and change depending on the situation and the devices. They are stored in a ".n3" file. Some characteristics are automatically added by the app from device APIs (Battery, Connectivity, etc.) while others are filled in manually by the user. A set of basic common rules is provided by the app for each device. It can then be enriched by the user to handle specific migration scenarios. Additional details on the prototype and the evaluation is provided in Chapter 6.

The work described in this subsection was conducted during the PhD of Clay Palmeira da Silva defended on September 2019 and during the Master 2 Internship of Dimeth Nouicer defended on December 2020. More details will be given in Part III, Chapter 6.

Machine Learning and Blockchain to handle dynamic and trust-

worthy service interactions and evolution

Handling service evolution with Machine Learning and Linked Open Data

This contribution addresses the challenge of handling dynamic evolution of service interactions discussed in Section 2.1.3.1 through an approach combining semantically-enabled models and machine learning tools on social interaction data. Following the graph-based social network representation of Web services in [START_REF] Maamar | Using social networks for web services discovery[END_REF] and [START_REF] Labbaci | Follow the leader: A social network approach for service communities[END_REF], we define a three-phase process to deal with service continuous deployment and changes. (1) The Bootstrapping Phase performs two tasks: (i) Semantic Annotation associates a profile to each service and annotates it with LOD resources; (ii) Semantic Matchmaking bootstraps relationships for newly deployed and services undergoing updates by running LOD semantic matching of service capabilities. (2) The Updating Phase updates service relationships by gathering and analyzing Web service interactions and their user feedback using sentiment analysis. (3) The Learning phase leverages Web services inter-2.2. CONTRIBUTION SYNTHESIS action experience to learn new open data links that will be reused in further semantic matchmaking, hence improving the accuracy of relationship recommendation.

Formally, the multi-relation network modeling Web service interactions is represented as a weighted directed graph G = (V, R) t where V is a set of services, and

R = k=3 k=1 R k is a set of edges, where R k = {(S u , S v ) ∈ V × V } is
the set of edges of the k-th relationship. Major services interaction relationships are: substitution (R 1 ), composition (R 2 ), and subscription (R 3 ). t is the date time when the graph G is observed.

(1) The Bootstrapping Phase: This phase relies on LODS similarity measure and LODbased service annotation discussed in Section 2.2.1.2. Services profiles are formally represented as pairs of features (F, D) where F is a text description of service functionality and D is a list of description keywords. Following the LOD-based annotation process, service features are linked to a set of LOD resources and LODS similarity measure is applied to compute similarity between pair of services in V . Similarity values are then considered to evaluate how likely two services can yield one of the three defined types of relations and compute a probability for successful interaction. Detailed algorithms are given in Chapter 7.

(2) The Updating Phase: Although semantic matching of service profiles allows building relevant business relationships, it relies however entirely on Web service profile data as isolated components and underlooks their interactive behaviour. The aim of this phase is to consider user rating scores for observed service interactions to update the graph accordingly. User feedbacks are expressed through text comments. We apply sentiment analysis to distinguish between positive comments and negative comments observed in a time interval [t, t + δt]. The updated weight of a relation between two services S u and S v is computed as the average of the previous weight and on the ratio of positive feedbacks over all the feedbacks. Formally, w t+δt (S u , S v ) = avg |positiveF eedbacks(Su,Sv) t+δt | |allF eedbacks(Su,Sv) t+δt | , w t (S u , S v ) . The higher will be positive user feedbacks on the relationship, the higher will get the updated weight. The weight will decrease on the contrary case.

(3) The Learning phase: This phase exploits the highly positively evaluated relationships to enrich LOD with new corresponding relationships. Updating LOD is triggered when the gap between the updated weight value and the bootstrapped weight value gets above a given threshold for the same relationship. If the updated weight is greater than the bootstrapped one, this means that Web services have a strong record of interactions in practice, while bootstrapping phase has not recommended them as such, which proves the lack of information in LOD. Thus, new relationships among resources describing these interoperable Web services should be added to LOD. On the opposite, if the updated weight is the lowest, this means that Web services struggle to interact. The cause can be either Web service description is inadequate with service real capabilities, or Web service suffer 2.2. CONTRIBUTION SYNTHESIS from QoS limitations. LOD relationships among resources describing such services should be destroyed.

The work described in this subsection was conducted during scientific stay of Hamza Labbaci at the University of Tours between 2018 and 2019. More details will be given in Part IV, Chapter 7.

Blockchain and smart contracts for trustworthy execution of business processes in dynamic contexts

The contribution discussed hereafter tackles the challenges discussed in Section 2.1.3.2 regarding the need for transactional flow modeling and change propagation model for blockchain-based choreographies and gives an overview of a threefold declarative approach we propose which includes: (i) a transformation model for mashups into smart-contract choreographies executions, (ii) a flexible transactional business process model for smartcontract business process executions, and (iii) a change propagation model to handle dynamic evolution of business process choreographies.

Mashup to smart contract transformation model. The starting point of this work is to go a step further configuring service mashups in the tourism context discussed in Section 2.2.2.1 to propose a way for personalized trip realization. The deployment and execution of touristic itineraries usually involve many independent entities (tourist, museum, restaurants, hotels, transport, etc.) that cooperate and compete in untrusted distributed context. In order to ensure trust within cooperation to guarantee a successful execution of touristic itinerary, we propose a two steps transformation model: (a) from data mashup itinerary to process choreography (BPMN) and then (b) from BPMN to smart contract. The CART trip planning outputs itineraries following an XML Schema Model with a root element containing a sequence of steps with or without PoIs and with or without payment. It also contains user constraints such as total duration and maximal budget. PoIs may also have additional attributes. The detailed structure of the itinerary generic model will be given in Chapter 8.

The main transformation rules are given in Table 8.1. We first apply a set of transformation rules which associate: a choreography model for each itinerary instance (rule (a)). Within the choreography model we generate a participant pool for every PoI and for the user (rule (b)) as well as a choreography task for each step of the itinerary (rule (c)). Steps without PoI correspond to private tasks (rule (d)). Additional user constraints and PoI attributes are embedded in the model documentation and in the PoI process documentation respectively (rules (e) and (f)).

The resulting choreography BPMN file is in turn used to generate corresponding Smart Only interaction activities are captured and included in the produced Smart contract which encodes only the public view (rule (a)). Each interaction activity, i.e., choreography task, consists of a send task, receive task and the corresponding message flows. This is encoded as two functions in the Smart contract (rule (c)). We consider Hyperledger Fabric which is a permissioned blockchain where only authorized organizations has the access to the network. In our case, authorized organizations are participant pools in the choreography model (rule (b)). Private tasks are left to participant private process and are therefore not included in the Smart contract (rule (d)). Additional constraints and attributes are encoded as global variables (rule (e)) and callbacks (rule (f)).

CONTRIBUTION SYNTHESIS

Extending Smart contracts with transactional business process model. The generated interaction smart contract implements the business logic of interaction activities in the process choreography, that is the control flow. The transactional semantics of a smart contract follow ACID models and are therefore limited to support transactional requirements of business process executions [START_REF] Bhiri | Ensuring customised transactional reliability of composite services[END_REF]. In order to ensure execution reliability of the generated smart contracts we extend them with the Transactional Business Processes models [START_REF] Bhiri | Ensuring customised transactional reliability of composite services[END_REF][START_REF] Hadad | Tqos: Transactional and qos-aware selection algorithm for automatic web service composition[END_REF] which define the transactional flow on top of the control flow of the interaction activities. Transactional Business Processes models define transactional properties of activities: pivot, compensatable, and retriable and the transactional mechanisms which include failure recovery mechanisms. In addition, we enrich the life cycle of a process activ-

CONTRIBUTION SYNTHESIS

ity, enabled → started → completed with four other possible termination states which are aborted, cancelled, failed and compensated which we call transactional termination states.

In this contribution we extend the transformation model introduced in the previous section and generate both the control flow and the transactional flow as well as failure handling mechanisms. For each business process activity we also generate functions and variables in the smart contract as a transactional flow. Generated functions include lifecycle activities (ActivityName_start(), ActivityName(), ActivityName_complete(), and Activi-tyName_fail()) and transition activities (abort(), cancel(), complete(), fail(), and retry()) which allow the activity to move from one state to another. Variables include state vector StateVector_ActivityName to capture the activity state evolution for each activity. The extended transformation model is implemented on top of the Caterpillar tool [START_REF] López-Pintado | Caterpillar: A business process execution engine on the ethereum blockchain[END_REF].

Change propagation in Blockchain-enabled business process choreographies.

Collaborating business entities evolve in highly dynamic environments that appeal for continuous updates and improvements of their internal processes to keep high competition level. These dynamic changes may affect the collaborations in which the enterprise takes part. Changes may also directly concern the global collaboration due to new external business policies that should be taken into account. In both cases, changes must be notified and propagated to the involved partners. Thus, business process management systems should manage change propagation in a trustworthy fashion. Although change propagation in process choreographies has been tackled in general [START_REF] Fdhila | Dealing with change in process choreographies: Design and implementation of propagation algorithms[END_REF], it is however still challenging for blockchain-based choreographies because of the non-mutable nature of shared data.

In running choreography instances, a change may consist of a simple operation, AD-D/REMOVE/UPDATE activity, or a combination of operations. Handling such changes requires the underlying choreography model to be flexible. We therefore consider declarative choreographies modeled through Dynamic-Condition-Response (DCR) graphs [START_REF] Mukkamala | A formal model for declarative workflows: dynamic condition response graphs[END_REF][START_REF] Mukkamala | Towards trustworthy adaptive case management with dynamic condition response graphs[END_REF]. With a DCR graph G = (E, M, Rel), processes are modelled as a set of events E, corresponding to the activities in BPMN, linked together with relations Rel modeling linking constraints. Relations are of five types (condition, response, milestone, include, and exclude) [START_REF] Hildebrandt | Declarative choreographies and liveness[END_REF]. The graph runtime state is captured by a marking matrix M of the events through a triplet of binary values corresponding to (currently included, currently pending, previously executed ). In [START_REF] Henry | Trustworthy cross-organizational collaborations with hybrid on/off-chain declarative choreographies[END_REF], authors propose an approach for trustworthy execution of DCR choreographies. We briefly describe here our contribution which builds on and extend this work with the change management mechanism. Detailed formalization and illustrative scenario will be provided in Chapter 8.

In [START_REF] Henry | Trustworthy cross-organizational collaborations with hybrid on/off-chain declarative choreographies[END_REF] a DCR choreography is defined as C(G, I, R) where G is a DCR graph, I is a set of interactions and R is a set of roles. An interaction i is a triple (e, r, r ′ ) in which

CONTRIBUTION SYNTHESIS

the event e is initiated by the role r and received by the roles r ′ ⊂ R \ {r}. Each partner has a projection of the DCR choreography, called public DCR process, in addition to its private DCR process which refines the public process with local events of the partner. The shared events and interactions are managed through the choreography smart contract on the Blockchain.

We propose to extend this approach with change management through the choreography smart contract. We define the change element G Ref as a refinement of C which occurs on private DCR process and should be propagated to the public DCR process whenever the change impacts common interactions with other partners. G Ref can be either an atomic element (an event or an interaction relation) or a DCR subgraph. When G Ref impacts common interactions, we manage a negotiation phase that leads either to a consensus in which case the public process is updated accordingly or to failure in which case the change is rejected. A change operation can be of three types respectively corresponding to ADD, REMOVE, and UPDATE:

C ⊕ G Ref , C ⊖ G Ref , and C[G Ref → G ′ Ref ].
We describe hereafter the four-steps approach we propose to manage these changes.

(i) Change proposal. The role initiator defines the change of its private DCR process following the previously introduced possible change types and operations. We review a set of integrity rules [START_REF] Debois | Replication, refinement & reachability: complexity in dynamic condition-response graphs[END_REF] to ensure safety and liveness of the updated DCR graph to avoid cycles. Safety means that the DCR graph is deadlock free whereas liveness guarantees the ability of the DCR graph to completion. The integrity rules are of two types. Allowed change rules define what can be done on the graph while Denied ones define what should be rejected. When the change proposal satisfies these rules the private DCR process is updated. In the case where the change also concerns the public DCR choreography we move to the next steps.

(ii) Change request for public-related changes. The change request is sent the choreography smart contract which stores the list of change requests assigned to process instances. Ongoing process instance changes are recorded with the identification hash of the current process instance. During the change request lifecycle, the request is assigned to a status: Init if no change request is ongoing, BeingProcessed during the negotiation stage, Approved or Declined once the change request is processed by all endorsers. The smart contract checks the identity of the change initiator which should belong to the list of partner, checks that no other change request is being processed, and then creates the change request and sends change request notification to the involved partners. The change initiator also sets two response deadlines t1 for change endorsement and t2 for change propagation to be checked by the smart contract. If one of the change endorsers does not reply before deadline t1 during endorsement or t2 during propagation, an alarm clock triggers a smart contract function cancelling the change request. The smart contract function sets the change request status to cancelled and emits an event notifying partners that the change has been cancelled. In this way we prevent any deadlock that could occur due to one of the partners not responding.

(iii) Change negotiation for public related changes. All partners subscribe to the change request events emitted by the smart contract. Endorsing partners must send their decision request to the smart contract based on the Allowed /Denied changes rules. If the change once computed on the endorser's process respects all the rules, then the endorser approves the request. It is otherwise rejected. The smart contract collects all the decisions from the endorsers to lock (or not) the choreography instance and proceed (or not) with the change and update the change status to Approved or Declined. In case of approval the smart contract locks the instance for change propagation. As it manages the negotiation process, a tamper-proof record of the negotiation is accessible by all partners. This prevents conflicts and eases potential claim resolutions.

(iv) Change propagation. Change propagation is to apply the change effect after the negotiation phase succeeds to (i) the affected partners DCR public processes, (ii) each partner propagates the change effect to its private DCR process. To ensure the correctness of the change propagation, we introduce a correctness property that checks the safety and compatibility of the updated graphs. The smart contract receives all the local projection confirmations and notifies the change initiator. That latter forwards the new DCR choreography to the smart contract which updates the relations and resets the change status to allow for new changes.

The work described in this subsection was conducted during the PhD of Amina Brahem to be defended by the end of 2023. More details will be given in Part IV, Chapter 8.

Part II

Semantically enabled service interactions

Chapter 3

Semantic Web Service Composition Using Semantic Similarities and Formal Concept Analysis This chapter describes our first contribution regarding the challenge of semanticallyenabled Web service interactions discussed in Section 2.1.1. It provides a detailed view of the approach described in Section 2.2.1.1 which consists in an integrated framework for semantic web services. The main contribution is threefold: a semantic similarity measure for Web services, a flexible FCA-based Web service classification for Web service discovery, and a planning and graph-based composite service generation.

INTRODUCTION

Introduction

One of the most interesting and relevant properties of services is the possibility to combine a number of existing services to create a more general composite service. Composing services allows for the definition of increasingly complex applications by progressively combining services at increasing levels of abstraction [START_REF] Dustdar | A survey on web services composition[END_REF]. This composition pattern has received much interest to support business-to-business or enterprise application integration. Several efforts have led to the development of platforms and languages to support composition and deployment of services [START_REF] Papazoglou | Service-oriented computing: State of the art and research challenges[END_REF][START_REF] Baryannis | Service composition. In Service Research Challenges and Solutions for the Future Internet -S-Cube -Towards Engineering, Managing and Adapting Service-Based Systems[END_REF][START_REF] Sheng | Web services composition: A decade's overview[END_REF][START_REF] Lemos | Web service composition: A survey of techniques and tools[END_REF]. However, despite this considerable progress, the composition process still poses limitations and challenges which have yet to be addressed by current technologies and tools for Web service composition. For instance, considerable differences on structural, semantic and technical levels along with the growing number of available Web services makes their discovery a significant challenging task. Achieving a required composite functionality requires the discovery of a collection of Web services out of the enormous service space. Each service must be examined to verify its provided functionality, making the selection task neither efficient nor practical [START_REF] Azmeh | Backing composite web services using formal concept analysis[END_REF].

Moreover, using services without considering their underlying semantics, either functional semantics or quality guarantees can negatively affect the composition process by raising intermittent failures or leading to slow performance [START_REF] Vladislava | Semantic description of web services and possibilities of bpel4ws[END_REF]. Indeed, semantics play important roles in Web process life-cycle. They specify the detail semantic information about the underlying functions supported by a service. Another important aspect is related to services compatibility as an essential pre-requisite to service composition. Measuring the similarity of services is an important and valuable task to get useful information about their compatibility. Similarity measure can be considered as an optimization step before composing services since it enables to reduce the search time by functionally classifying similar services.

In this context, this chapter presents a practical approach to measure the similarity of Web services. Both semantic and syntactic descriptions are integrated through specific techniques for computing similarity measures between services. Formal Concept Analysis (FCA) is then used to classify Web services into concept lattices, and therefore generate a hierarchy of classes of similar Web services. Following this step, a composition engine takes as inputs the set of similar services and the specification of the required service, and generates the candidate composition plans that realize the goal through Planning-based and graph-based algorithms.

The remainder of this chapter is organized as follows. Section 2 introduces the components of the composition framework and details their components. Section 3.2 provides an overview on the framework architecture. Section 3.3 details the proposed semantic

Semantic Web Service Composition Framework overview

In this section we introduce the Integrated Development Environment for Composite Services Engineering (IDECSE) framework. The proposed framework is intended to achieve a high abstraction level allowing the continuous and dynamic improvement of the composition to support and encourage the adoption of SOA technologies while reducing costs and composition time. Based on a layered approach, the main general objective is to develop a well-integrated framework to enable the mastery of complexity and dependability of service compositions by offering tools for specifying, discovering and composing services. All service life-cycle processes in the proposed approach are based on native semantic integration. IDECSE general architecture is depicted in figure 3.1. It consists mainly of three complementary components: the semantic matching engine, the service classification engine, and the composition engine. The service matching process which plays the central role as it underlies and supports service discovery and composition processes through providing successful matching services possibilities among all the services in the service space. The goal here is then to define efficient similarity measures which allow ensuring an accurate matching process. The defined similarity measure allows classifying Web services into sets of highly similar ones. Achieving the previous processes will make it easy to define efficient and optimized algorithms for relevant service discovery. Finally, the composition process which is based on efficient tools for ensuring meaningful compositions and dynamically interacting with the other framework modules towards preserving composition continuity. These components will be detailed in the following sections.

IDECSE framework also provides a user-friendly interface to enable end users to specify the high-level description of their desired service. They express their requirements and preferences that mark the boundary of the solution by following some instructions to build the query. A query parser is integrated to parse and validate the query by checking syntactic correctness and decoupling the functional requirements from the non-functional parameters such as QoS properties. The Service Matching Engine is responsible for measuring the similarity between semantically annotated OWL-S services. We define a similarity measure σ over a set S of services as follows:

SEMANTIC SIMILARITY MEASURE FOR WEB SERVICES (SERVICE MATCHING ENGINE)

σ : S × S →[0 , 1] σ(S i , S j ) = α 1 Sim P (S i , S j ) + α 2 Sim M (S i , S j ) + α 3 Sim G (S i , S j ) (3.1)
where 3 k=1 α k = 1. Sim P , Sim M and Sim G correspond to similarity function between Profiles, Models and Groundings, respectively. As Service Model and Service Grounding are used to supplement the initial similarity and specify details of how to access a service, their parameters can be modeled as QoS. In this case, similarity is based on functional features located in the Service Profile of the service OWL-S file.

σ(S i , S j ) ≈ Sim P (S i , S j ) = w 1 Sim I (S i , S j ) + w 2 Sim O (S i , S j ) + w 3 Sim P re (S i , S j ) + w 4 Sim Ef f (S i , S j ) (3.2)
where 4 k=1 w k = 1. Sim I , Sim O , Sim P re , Sim Ef f , correspond to the similarity function between Inputs, Outputs, Preconditions and Effects of compared services, respectively. The weights w i allow modeling the similarity measure to be adapted to different application cases where it may be required to focus on IO only or any other possible combination of the four aspects. In the case where no specific preferences are given, these weights are equally set to 0.25.

SEMANTIC SIMILARITY MEASURE FOR WEB SERVICES (SERVICE MATCHING ENGINE)

In the general case, weights are either expressed by some actor (the user for example) to define personalised preferences regarding the application domain or the actor expectations, or empirically deduced through learning techniques over previous computing scenarios.

Each of the four Sim functions is in turn defined as the sum of two weighted conceptbased and data-type based measures as follows for the case of Inputs and analogously for the three other dimensions:

Sim In (S i , S j ) = u In 1 Sim Co (In i , In j ) + u In 2 Sim DT (In i , In j ) (3.3)
where

u In 1 + u In 2 = 1.
Web service features are semantically annotated using concepts from ontologies. Measuring their similarity turns out to measuring the similarity between their annotation concepts in the considered ontologies. Comparative study of the state-of-the-art approaches on semantic similarity measures have shown a better correlation coefficient and higher efficiency rates for the measure proposed in [START_REF] Sánchez | Ontology-based semantic similarity: A new feature-based approach[END_REF] which follows the Tversky model [START_REF] Tversky | Features of similarity[END_REF], where common taxonomical features tend to increase similarity while the non-common ones decrease it. We therefore adapt the Sanchez formulas to define Sim Co .

Let A and B two concepts, represented by the nodes a and b in a predefined is-a semantic taxonomy. Let C be a set of concepts of such a taxonomy; (≤) is defined as a binary relation ≤: C × C. Having two concepts c i and c j , c i ≤ c j is fulfilled if c i is a hierarchical specialization of c j or if c i ≡ c j (i.e. same concept). The set of taxonomical features describing the concept a is defined in terms of the relation ≤ as follows (Equation 3.4). ϕ(a) = {c ∈ C|a ≤ c} (3.4) [START_REF] Sánchez | Ontology-based semantic similarity: A new feature-based approach[END_REF] defines the semantic similarity between two concepts as follows:

Sim(a, b) Co = 1 -log(1 + |ϕ(a)\ϕ(b)| + |ϕ(b)\ϕ(a)| |ϕ(a)\ϕ(b)| + |ϕ(b)\ϕ(a)| + |ϕ(a) ∩ ϕ(b)| ) (3.5)
In the same way, we reviewed and adapted the best state-of-the-art data-type measures to define Sim DT . Following works in [START_REF] Plebani | URBE: Web service retrieval based on similarity evaluation[END_REF] and [START_REF] Tibermacine | Wssim: a tool for the measurement of web service interface similarity[END_REF] we propose a practical measure between different data-types that defines abstract groups of compatible data-types and then assigns similarity values to each pair of groups. Datatype groups similarity defined in [START_REF] Plebani | URBE: Web service retrieval based on similarity evaluation[END_REF] is summarized in 3.1.

Considering Sim DT prevents meaningless composite services built upon highly similar services with respect to Sim Co which however fail to match their data-types. Following Finally, we define our similarity measure as follows (Equation 3.6):

σ(S i , S j ) = w 1 [u I1 Sim I Co (S i , S j ) + u I2 Sim I DT (S i , S j )] + w 2 [u O1 Sim O Co (S i , S j ) + u O2 Sim O DT (S i , S j )] + w 3 [u P re1 Sim P re Co S i , S j ) + u P re2 Sim P re DT (S i , S j )] + w 4 [u Ef f 1 Sim Ef f Co (S i , S j ) + u Ef f 2 Sim Ef f DT (S i , S j )] (3.6)
where 4 k=1 w k = 1, 2 j=1 u aj = 1 and a ∈ {I,O,Pre,Eff}. The proposed similarity measure will be used for flexible FCA-based service classification as well as for Graph-based composition generation detailed in the following sections.

Flexible Web service classification and discovery with FCA (Service Classification Engine)

The way services are organized within the service registry highly impacts the efficiency of service identification for any given need. We therefore propose to build the classification component of IDECSE upon the well-established formalism called Formal Concept Analysis (FCA) [START_REF] Ganter | Formal Concept Analysis: Mathematical Foundations[END_REF] and particularly its derived structures called Concept Lattices. We illustrate the FCA-based classification and discovery on a set of semantic services in Table 3.2 extracted from a public dataset1 . For each service we focus on the operations and the annotation concepts of its inputs and outputs.

Based on partially ordered sets theory, FCA allows to structure the data into a hierarchy of partially ordered concepts called the Concept Lattice. Each concept corresponds to a maximal set of objects having in common a maximal set of attributes. The concept lattice hierarchical relation is based on the dual partial order between sets of objects and dually sets of attributes. This structure and its properties motivated the use of concept lattices as indexing structure for information retrieval either by direct querying or by progressive navigation [START_REF] Messai | Many-valued concept lattices for conceptual clustering and information retrieval[END_REF][START_REF] Messai | Using domain knowledge to guide lattice-based complex data exploration[END_REF].

Following this direction we apply FCA to automatically organize services into a concept lattice based on the semantic similarity defined so far. We consider services as objects and operations as attributes. We compute the similarity between service operations based on σ in Equation 3.6. Considering the set of services in Table 3.2, this step yields the Service-Operation matrix in Table 3.3. The matrix is symmetric and only the top part is filled in for visibility. In FCA, this representation is called Multi-valued formal context formally represented as a quadruplet (G, M, W, I) where G is a set of objects, M is a set of attributes and (g, m, w) ∈ I means that attribute m has value w for object g. FCA basic settings,

PLANNING AND GRAPH-BASED COMPOSITE SERVICE GENERATION (SERVICE COMPOSITION ENGINE)

however, apply on binary contexts formally represented as a triple (G, M, I) where G is a set of objects, M is a set of attributes and (g, m) ∈ I means that object g has attribute m. We apply the conceptual scaling on the Multi-valued context based on a similarity threshold θ ∈[0 , 1]. Similarity values below the threshold are removed and the remaining ones are replaced with "×", which yield the context in Table 3.4 for θ = 0.4. The corresponding concept lattice is given Figure 3.2 (Left).

op 81 S 1 X X X S 2 X X X S 3 X S 4 X X X S 5 X X X S 6 X X X S 7 X X S 8 X X
The concept lattice structures the services in the registry into classes of services with similar operations. It can then be used as underlying structure for identifying relevant services for a given need: substitution of similar service or composition of complementary services. Relevant service identification can rely on best-known algorithms for FCA-based querying and navigation [START_REF] Messai | Many-valued concept lattices for conceptual clustering and information retrieval[END_REF][START_REF] Messai | Using domain knowledge to guide lattice-based complex data exploration[END_REF]. In the case of querying, an illustration is given with a requested service S R which allows to find an Author as String given a Book Title also as String. S R is modeled as one-operation service, similarity measure σ is applied to compute similarity values of S R with respect to registry services and the corresponding scaled context line is added to the context. The corresponding concept lattice is given in Figure 3.2 (Right).

Selected relevant services can then be returned as query answer for individual invocation or more generally they can be considered as input of the composition engine for composite service generation. This step will be detailed in the following section.

Planning and graph-based composite service generation (Service Composition Engine)

The last component of the IDECSE framework is the composition generator. It takes as input a set of similar services returned by the previously presented components to provide a set of coherent composite services relevant to requested function. This component appeals for AI planning techniques and graphs together with the semantic similarity measure (SERVICE COMPOSITION ENGINE) Figure 3.2: Service concept lattice corresponding to the formal context in Table 3.4 (Left) and with the requested service S R (Right) and QoS constraints to ensure successful compositions. The key point is the compatibility between Input-Output interfaces of the services to be connected within the resulting composite ones.

Planning-based composite service generation

The highest level of compatibility is achieved with identical matching between Input-Output which feats the use of AI Planning. In this case, Web service composition problem is mapped to a planning problem based on transformation rules defined in [START_REF] Hatzi | The PORSCE II framework: Using AI planning for automated semantic Web service composition[END_REF] and using the Planning Domain Definition Language (PDDL) [START_REF] Ghallab | Pddl -the planning domain definition language (version 1.2)[END_REF]. In this mapping, each service S i is represented as a state St i , its inputs and preconditions are represented as the state preconditions prec(St i ) = S i Inputs ∪S i P reconditions , and its outputs and effects are represented as the state effects ef f (St i ) = S i Outputs ∪ S i Ef f ects . We apply STRIPS planning algorithms on the resulting mapping problem to generate possible solution plans corresponding to possible service compositions. In the general case, however, there may be no exact Input-Output interface matching. We therefore propose a graph-based composition generation which relies on the proposed semantic similarity measure to compute approximate matching possibilities.

Semantic Similarity for Graph-based composite service generation

Graph-based composite service generation consists in modeling the set of selected services as a composability graph: a weighted directed graph where nodes correspond to services and edges to their composability similarity values. Composability similarity between two services S i and S j is the matching similarity between S i outputs and S j inputs to evaluate how likely the two services can be connected. Similarity measure σ in Equation 3.

PLANNING AND GRAPH-BASED COMPOSITE SERVICE GENERATION (SERVICE COMPOSITION ENGINE)

3.6 is redefined as follows.

σ Composability (S i , S j ) = u 1 Sim Co (S i Out , S j In ) + u 2 Sim DT (S i Out , S j In ) (3.7)
where S i Out actually denotes the union of S i Outputs and S i ef f ects and S j In actually denotes the union of S j Inputs and S j P reconditions .

The obtained similarity values are mapped logical match type as defined by [START_REF] Lécué | A formal model for semantic Web service composition[END_REF] and illustrated in Table 3.5. Services with "Match" or with "Plug-in" are most likely to lead to successful composition. Composability graph can be reduced to keep only services with these two composability match types. To illustrated the graph building steps we consider the set of selected services in Table corresponding to the use-case of getting access to restaurant menus given the user IP address. The steps of composability graph generation are given in Figure 3.3.

Implementation and evaluation

The proposed approach is implemented as a Java application including an OWL-S parser based on Jena2 and JAXP3 and FCA algorithm based on ConExp implementation 4 . The prototype is evaluated on two datasets: a set of 250 OWL-S services available online 5 , mainly for accuracy, and a set of 1000 randomly generated services, for performance study.

An overview of evaluation results is given hereafter. More detailed experimental study is provided in [2]. We start by evaluating the required time to build the IDECSE registry which is the sum of execution time of three main tasks: parsing service features, measuring similarity, and building lattice of services. Results for the first dataset (250 OWL-S services) are given in Figure 3.4 (Left) and show acceptable performances for this step built before user interactions. Then we moved to requested service matching for which results are given in Figure 3.4 (right). The indicated time includes query processing, S R similarity measure, and lattice querying to identify the set of relevant services.

The composition generation evaluation results are shown on figure 3.5 (Left) showing also acceptable time to get composition plans including important number of composable services. The generation of a plan with 7 services, 6 dependencies and 14 parameters for each service takes less than one second. Plans with more than 20 services takes less than two seconds to be generated.

Finally, the overall performances of the proposed approach is compared to two other existing prototypes corresponding to state-of-the art approaches: PORSCE presented in [START_REF] Hatzi | The PORSCE II framework: Using AI planning for automated semantic Web service composition[END_REF], and 2P presented in [START_REF] Kwon | Redundant-free web services composition based on a two-phase algorithm[END_REF] and results are shown on Figure 3.5 (Right). Experiments are run on a randomly generate dataset of 1000 Web services. Services parameters are uniformly distributed and randomly assigned to services. Then, we generate 100 queries with parameters from the set of service parameters to keep the same semantic domain. For

Related Work

In this section we briefly review the state-of-the-art approaches related to our approach in order to position our contribution accordingly. A more detailed and extended review of related work is presented in [2] and [START_REF] Abid | Semantic web service composition using semantic similarity measures and formal concept analysis[END_REF]. Among the numerous proposed approaches, some surveys in [START_REF] Papazoglou | Service-oriented computing: State of the art and research challenges[END_REF] and [START_REF] Lemos | Web service composition: A survey of techniques and tools[END_REF], we will particularly focus on those which perform service clustering and similarity computing for automating service composition.

Web service clustering was discussed in several approaches. [START_REF] Elgazzar | Clustering WSDL documents to bootstrap the discovery of web services[END_REF] perform service clustering based on WSDL extracted contents such as types, messages, ports, and service name.

RELATED WORK

[171] present a hybrid Web service tag recommendation strategy that employs tag mining and semantic relevance measurement. Web services are clustered according to the similarities of extracted WSDL features. [START_REF] Chen | A semantic similarity measure integrating multiple conceptual relationships for web service discovery[END_REF] present the service cluster net unit used then to check whether any service in the cluster can satisfy user requirements for further use in service substitution process. One more specific service clustering family groups those based on FCA. [START_REF] Azmeh | Selection of composable web services driven by user requirements[END_REF] use FCA to classify services according to keywords extracted from WSDL service descriptions. [START_REF] Naim | Probabilistic approach for diversifying web services discovery and composition[END_REF] proposed a service ranking algorithm for diversifying web service discovery results in order to minimize the redundancy in the search results using FCA. Some other approaches rely on semantic similarity measures or the definition of semantic queries using SPARQL language for service discovery. [START_REF] Tibermacine | Wssim: a tool for the measurement of web service interface similarity[END_REF] consider WSDL descriptions to provide a practical approach for measuring the similarity between Web services by using a set of existing lexical and semantic metrics. Similarly, [START_REF] Liu | Measuring similarity of web services based on WSDL[END_REF] employ external knowledge to compute the semantic distance between terms from two compared services. While [START_REF] Barhamgi | Composing data-providing web services[END_REF] propose an approach based on modeling the available services into RDF views over a mediated ontology. The generated views are then integrated as annotations into WSDL files. User queries are transformed into a mediated ontologies using SPARQL query languages. [START_REF] Mouhoub | A framework for searching semantic data and services with SPARQL[END_REF] introduce a SPARQL-driven approach for searching relevant services to be addressed to service repositories for further automatic service composition.

Regarding service composition integrated frameworks, [START_REF] Hatzi | Semantically aware web service composition through AI planning[END_REF] extend their AI-based planning composition framework using semantic metrics to discover and reason about services. Graph-based approaches such as [START_REF] Lécué | A framework for dynamic web services composition[END_REF] develop an integrated framework for dynamic Web services composition. The framework exploits the semantic Input-Output matchmaking to discover relevant services and perform automatic composition using a graph-based approach, taking into account functional and non-functional properties. [START_REF] Da Silva | Towards runtime discovery, selection and composition of semantic services[END_REF] support both automatic semantic discovery and composition, among other relevant phases of the composition life-cycle taking into account non-functional properties. [START_REF] Rodriguez-Mier | An integrated semantic web service discovery and composition framework[END_REF] develop a framework for discovery and composition which includes optimizations to reduce graph size and an optimal search to extract the best composition from the graph. One of the limitations of the discovery phase is that it does not support fine-grained services retrieval.

Although Web service discovery and composition approaches have presented efficient and performing techniques, they still face challenging tasks, which straightforwardly impact the composition process and the efficiency of composition frameworks. First, providing an accurate service matching requires to consider the maximum number of available features describing services, syntactically and semantically, while defining efficient similarity measures. Second, the discovery process performances and accuracy are highly dependent on how Web services are structured and/or categorised into considered registries. Existing FCA-based approaches suffer from lack of semantics and are limited only to basic common 3.8. CONCLUSION features between services. Considering semantic similarity at this level reduces the research space of relevant services to a specific cluster or class of services instead of the whole registry. Third, the composition process depends mainly on two elements. The the list of selected services and the composition algorithm. Fourth a successful framework should ensure the matching, classification, discovery, and composition processes. Unfortunately, the literature review stresses the lack of such integrated frameworks. Discovery and composition of Web services have indeed been usually developed separately. Also, matching methods always rely on similarity measures independently defined for abstract concepts, semantically annotating services, regardless services additional features. In this work, we addressed these tasks through the proposed integrated framework considering semantics in all stages of service life-cycle, defining efficient similarity measure that also considers data type compatibility, combining semantic similarity with FCA for service clustering and discovery, and using AI planning and Graph-based efficient algorithms for composition generation.

Conclusion

In this chapter, we presented a integrated approach for Web services discovery and composition using semantic similarity measure which combines semantic features together with data type compatibility. Formal Concept Analysis was used for building Web service lattices according to functional and operational service similarities. Generated classes of similar services are then used to identify the candidate composition plans that realize the desired goal based efficient planning and graph-based algorithms. The approach is implemented and evaluated over two data sets and compared to state-of-the-art baselines. Results show the approach efficiency and performances which outperform baselines.

The key point of this work is semantic similarity measure for OWL-S services which considers ontological hierarchies. The measure efficiency is therefore domain-dependant, limiting its applicability in general cases where services may refer to complementary domains. The next logical step is therefore to consider cross-domain ontologies. This objective meets the emergence and recent advances in Linked Open Data (LOD). In the next chapter, we take advantage of LOD to define efficient cross-domain similarity measure to be applied for service recommendation.

The work described in this chapter was conducted during the PhD of Ahmed Abid defended on July 2017 [2]. It is mainly published in the following journal and conference papers: [START_REF] Abid | IDECSE: A semantic integrated development environment for composite services engineering[END_REF], [START_REF] Abid | A semantic-aware framework for composite services engineering based on semantic similarity and concept lattices[END_REF], [START_REF] Abid | A semantic similarity measure for conceptual web services classification[END_REF], [START_REF] Abid | Semantic similarity based web services composition framework[END_REF], [START_REF] Abid | A semantic matching engine for web service composition[END_REF], and [START_REF] Abid | Semantic web service composition using semantic similarity measures and formal concept analysis[END_REF].

Chapter 4

Linked Open Data Similarity for Web services This chapter describes our second contribution regarding the challenge of semanticallyenabled Web service interactions discussed in Section 2.1.1. It provides a detailed view of the approach described in Section 2.2.1.2 which consists in exploiting the Linked Open Data (LOD) for efficient service recommendation. The main contribution is threefold: a LOD-based semantic similarity measure, a context-aware service recommendation, and a Library for LOD-based similarity calculation.

INTRODUCTION

Introduction

The continuous improvement of mobile network performances together with the significant evolution of hardware and software of mobile devices has deeply transformed the way users interact with information systems. A new era of computing, called "ubiquitous computing", based on these two evolutions, has emerged. Nowadays, a mobile user has an ubiquitous access to multiple resources, in particular services. In order to satisfy user needs in terms of functional and non-functional service requirements, discovery process have to be applied. This process performs at first stage a functional matchmaking to return services having functionalities that user requested. At the second stage, non-functional parameters (contextual information) are taken into consideration to rank services depending on user's task or situation. Incorporating context information during discovery process reduces improves the discovery accuracy by filtering results that are functionally relevant but do not correspond to user context. Despite the interest of using ontologies in context-aware mobile services discovery, they present in our opinion two major weaknesses. First, they are resources limited and its knowledge covers generally restricted domains. Second, they are generally isolated, i.e., their concepts are not interconnected with concepts in other ontologies, which limits their exploitation. It is not possible for example to enrich concept definition in one ontology from an equivalent one defined in another ontology because of missing links. These two limitations implicitly impact any ontology-based service discovery process.

Researchers over the past few years have addressed this issue in two different ways. Either by replacing domain specific ontologies by multi-domains ontologies such as WordNet or by using textual knowledge sources such as Wikipedia to bootstrap service discovery [START_REF] Bhargava | Bootstrapped discovery and ranking of relevant services and information in context-aware systems[END_REF]. However, both directions have drawbacks. Although multi-domains ontologies are relatively rich, they remain non-interconnected. Textual knowledge sources also suffer from the concepts interconnection problem. In addition, they require exhaustive processing to calculate relevance. We are thus convinced that, the use of data from Web of Data, commonly called (Linked Open Data) [START_REF] Bizer | Linked data -the story so far[END_REF], will make it possible to overcome the previous limitations. These data are mainly intended to be processed by machines, and therefore designed and thought to be open, structured, semantically described and linked to each other.

In this chapter we takes advantage of the evolution of Semantic Web to Linked Open Data (LOD) to propose, in Section 4.2, an efficient similarity measure, LODS, that assesses the matching degree between pairs of terms represented with LOD resources. We then use LODS measure in an approach that addresses context-aware service recommendation, described in Section 4.3. We describe, in Section 4. [START_REF] Abid | IDECSE: A semantic integrated development environment for composite services engineering[END_REF], the open source LOD-based similarity measure library we propose on top of the LODS. We provide in Section 4.5 an insight on 4.2. LODS: A LINKED OPEN DATA SIMILARITY MEASURE the evaluation and results of the proposed approach. We review in Section 4.6 the main related work. Finally we conclude the chapter in Section 7.8.

LODS: a Linked Open Data Similarity Measure

Background

In this section, we provide the main necessary constructions and characteristics of LOD and DBpedia to be used in the description of our proposed similarity measure.

RDF triples. Consider a set of URIs U and literals L, an rdf triple is defined as ⟨s, p, o⟩, where the subject s ∈ U, the property p ∈ U and the object o ∈ U ∪ L. Linked Open Data. A dataset that follows a linked data principles [START_REF] Bizer | Linked data -the story so far[END_REF] is a graph G = (R, L), where R = {r 1 , r 2 , ..., r |R| } is a set of resources and L = {l 1 , l 2 , ..., l |L| } a set of links. l i is defined as l i = ⟨r, p, r ′ ⟩ ∨ ⟨r, p, v⟩, where p is a property that interlinks the resource r with the internal/external resource r ′ or with a literal attribute v, which is a basic value (string, date, number ...). So, Linked Open Data is a set of interlinked open datasets LOD = i G i .

Ontology. An ontology is a graph of triples that describe domain concepts and their relations. In LOD, it is preferred to use concepts from widely used ontologies to instantiate its resources [START_REF] Heath | Linked Data: Evolving the Web into a Global Data Space[END_REF]. This allows efficient data integration and reuse by LOD-based applications. We denote by O all ontologies used to describe the whole LOD resources.

Classification schema. Classification schemata classify resources into categories and may contain cycles in their taxonomic structure. This requires to limit the level of extracted categories to avoid retrieving useless ones. We denote by C all classification schemata used to classify the whole LOD resources.

Triple patterns, Basic Graph Patterns (BGP). Triple patterns are similar to RDF triples except that each of the subject, predicate or object may be a variable (started with ' ?'). BGP are constructed from a set of triple patterns. We adopt SPARQL BGP1 to represent queries over RDF datasets.

Properties types. An infinite set of properties could be used to describe LOD resources. In this work we consider the 4 following property types.

• Instantiation properties (IP). An IP τ ∈ U maps a concept c from an ontology o ∈ O to a particular resource r, we write ⟨r, τ, c⟩. rdf:type is an example of IP.

• Classification properties (CP). A CP ς ∈ U is used to classify a resource into a particular category in a schema. dcterm:subject is an example of CP.

• Linking properties (LP). An LP ξ ∈ U is used to interconnect two equivalent resources r and r ′ from distinct LOD datasets, we write ⟨r, ξ, r ′ ⟩. owl:sameAs is an example of LP.

• Subsumption properties (SP). An SP δ ∈ U is used to define specialization or subclass relation in a given ontology or classification schemata. Given two concepts c i and c j from an ontology, ⟨c i , δ, c j ⟩ denotes that concept c i is a specialization of c j .

owl:subClassOf is an example of SP.

We call the remaining properties characterization properties, denoted by P , since they distinguish LOD resources. Properties that have a resource r as subject, i.e. ⟨r, p, ?o⟩, are called outgoing properties and those having r as object, i.e. ⟨?o, p, r⟩, ingoing properties.

Property paths and paths patterns. We adopt SPARQL1.1 property path notations such as ZeroOrMorePath, ZeroOrOnePath, OneOrMorePath, SequencePath, Alterna-tivePath, denoted respectively * , +, ?, / and |. They are used to navigate between resources and reach particular data inside a single or distinct LOD datasets.

Using property paths in a triple that contains variables, expresses a path pattern that retrieves all triples satisfying it. For instance, the pattern : ⟨r, ξ/τ, ?c⟩ retrieves all instantiation concepts c for the resource r from its equivalent resources. It is worth noting here that we consider property paths traversal over different LOD datasets.

DBpedia. DBpedia [START_REF] Lehmann | DBpedia -a large-scale, multilingual knowledge base extracted from wikipedia[END_REF] is the semantic counterpart of Wikipedia that realizes LOD vision by structuring its content and interlinking it with external datasets such as Wikidata and YAGO. DBpedia transforms every Wikipedia article into a resource, annotated with a set of properties extracted from the article Web page. Many LOD datasets are producing data pointing to DBpedia resources making it as a central kernel of LOD cloud2 . We therefore consider in this work DBpedia as starting point to glean initial data to compute similarity degree between compared concepts. Afterward, follows interlinks we enrich data from other datasets within a data augmentation process.

Similarity measure for Linked Data Resources

In the following we define a similarity measure composed of three sub-measures: SimI, SimC, and SimP . SimI exploits the taxonomic structure of ontological concepts used to instantiate resources. SimC operates on classification schemata used to categorize resources. SimP uses characterization properties of compared resource. The combination of these sub-measures allows to reduce the negative impact of possibly poorly described resources. Each sub-measure applies on enriched data by following links between LOD dataset. The sub-measures are defined as feature-based similarity measures based on Tversky [START_REF] Tversky | Features of similarity[END_REF] model to handle multi-domain ontologies as well as multiple annotation ontologies for the same concept [START_REF] Sánchez | Ontology-based semantic similarity: A new feature-based approach[END_REF].

We provide hereafter the formalization of the proposed LOD based similarity measure. A more detailed presentation with illustrations on a running example can be found in [START_REF] Cheniki | Découverte des Web Services Mobiles[END_REF].

Let O r ⊆ O be the subset of ontologies containing concepts that instantiate a resource r. We define a function ϕ o (r) that returns all taxonomic features of a resource r, i.e. all concepts and their subsumers in an ontology o ∈ O r . Formally,

ϕ o (r) = {?c ∈ o|⟨r, τ |δ * |τ /δ * , ?c⟩} (4.1)
To enrich taxonomic features or even increasing the size of instantiation ontologies space of a resource. We follow equivalent resources belonging to the same or to different LOD datasets. Formally, we define ϕ * o (r), an augmented function as follows.

ϕ * o (r) = ϕ(r) ∪ {?c ′ ∈ o | ⟨r, ξ, r ′ ⟩ ∧ ⟨r ′ , τ |δ * |τ /δ * , ?c ′ ⟩, ?c ′ / ∈ ϕ(r)} (4.2)
After applying the function ϕ * o (r), the set of instantiation ontologies of r will be so augmented. We denote this new set by O *

SimI * o i (a, b) = |ϕ * o i (a) ∩ ϕ * o i (b)| |ϕ * o i (a) ∩ ϕ * o i (b)|+|ϕ * o i (a) \ ϕ * o i (b)|+|ϕ * o i (b) \ ϕ * o i (a)| (4.3)
The overall instantiation similarity SimI * over the set of augmented ontologies O * a,b is defined as follows.

SimI * ∀o i ∈O * a,b (a, b) = o i ∈O * a,b SimI * o i (a, b) |O * a,b | (4.4)
We consider with SimI * the average of the resulted similarities from all shared augmented ontologies to hold the balance between ontologies having a rich taxonomic structure and those with a poor taxonomic structure. Now, given a resource r classified within categories following a set of classification schemata C r ⊆ C, we denote ∆ ℓ t (r) the function that returns, for a resource r, all the classification categories and their super-categories in a classification schema t ∈ C r . The parameter ℓ limits the deepness of the hierarchical level in which categories are retrieved. In the opposite, we denote ∇ ℓ ′ t (r) the function that returns all the classification categories and their sub-categories, for a resource r, in a schema t ∈ C r , with respect to ℓ ′ levels Formally,

∇ ℓ ′ t (r) = {?c 1 , .., ?c ℓ ′ ∈ t|(⟨r, ς, ?c 1 ⟩ ∧ ⟨?c 2 , δ, ?c 1 ⟩) ∨ ...⟨?c ℓ ′ , δ, ?c ℓ ′ -1 ⟩} (4.6)
We combine, the two functions to obtain all classification features of a resource r as follows.

φ ℓ,ℓ ′ t (r) = ∆ ℓ t (r) ∪ ∇ ℓ ′ t (r) (4.7)
Following the same principle of augmenting the space of instantiation concepts of a resource r, we can define augmented classification features function denoted by φ * ℓ,ℓ ′ t (r). We can as well obtain its set of augmented classification schemata, denoted by C * a,b with respect to limited super-categories and sub-categories hierarchy levels ℓ and ℓ ′ , is computed based on the cardinalities of differential and common categories features of compared resources as follows.

SimC * ℓ,ℓ ′ t (a, b) = |φ * ℓ,ℓ ′ t (a) ∩ φ * ℓ,ℓ ′ t (b)| |φ * ℓ,ℓ ′ t (a) ∩ φ * ℓ,ℓ ′ t (b)|+|φ * ℓ,ℓ ′ t (a) \ φ * ℓ,ℓ ′ t (b)|+|φ * ℓ,ℓ ′ t (b) \ φ * ℓ,ℓ ′ t (a)| (4.8)
The overall similarity for the whole augmented classifications space is then defined as follows.

SimC * ℓ,ℓ ′ ∀t i ∈C * a,b (a, b) = t i ∈C * a,b SimC * ℓ,ℓ ′ t i (a, b) |C * a,b | (4.9)
As for properties, let the subset P r ⊆ P be the sub-space of properties that contains characterizing attributes of a resource r. We denote by Ω P i (r) (respectively, Ω ′ P i (r)) the function that returns all ingoing (respectively, outgoing) characterizing properties of a resource r in a particular space P i ∈ P r . Formally,

Ω P i (r) = {(?p,
Ψ P i (r) = Ω P i (r) ∪ Ω ′ P i (r) (4.12)
Following interlinked equivalent resources of r, we can also define as in equation 4.2 function Ψ * P i that returns the set of augmented properties describing r. The augmented space of properties P * r can then be obtained.

Definition 3 (SimP). Let P * a,b ⊆ P * a ∩ P * b be the space of shared augmented characterizing properties of two resources a and b, we define characterizing properties similarity SimP * P i (a, b) of a and b as:

SimP * P i (a, b) = µ(Ψ * P i (a) ∩ Ψ * P i (b)) µ(Ψ * P i (a) ∩ Ψ * P i (b)) + µ(Ψ * P i (a) \ Ψ * P i (b)) + µ(Ψ * P i (b) \ Ψ * P i (a)) (4. 13
)
where µ is the partial information content of characterizing properties [START_REF] Meymandpour | Enhancing recommender systems using linked open data-based semantic analysis of items[END_REF]. This function gives more importance to specific properties based on their occurrences in LOD datasets. Formally,

µ(Ψ * P i (r)) = ∀p∈Ψ * P i (r) -log F req(p) N (4.14)
where F req is a function that counts the occurrence frequency of the property p in the description of LOD resources, and N the total number of resources in the underlying dataset. The overall similarity of all properties space is defined as follows.

SimP * ∀P i ∈P * a,b (a, b) = P i ∈P * a,b SimP * P i (a, b) |P * a,b | (4.15)
Based on the previously defined sub-measures, we define our LOD-based similarity measure LODS as follows.

Definition 4 (LODS). Given a two resources a and b that are: (i) instantiated with concepts from augmented shared ontologies o i ∈ O * a,b , (ii) classified into categories from augmented shared classification schemata t i ∈ C * a,b , and (iii) characterized with a set of augmented shared space of properties P i ∈ P * a,b . We define the Linked Open Data Similarity (LODS ) measure between the resources a and b as follows. Considering functional and non-functional aspects, a service s can formally be represented as a triplet ⟨n s , F s , N F s ⟩, where: n s is the service name, F s = {f 1 , f 2 , . . . , f i } represents the functionalities of s, and N F s = {P 1,s , P 2,s , . . . , P n,s } represents its nonfunctional properties. Functionalities in F s can be annotated by a subset of resources A s ∈ LOD where:

LODS ℓ,ℓ ′ (a, b) = AV G(simI * ∀o i ∈O * a,b (a, b), simC * ℓ,ℓ ′ ∀t i ∈C * a,b
∀f i ∈ F, ∃r i ∈ A s |{⟨f i , α, r i ⟩}.
α being an annotation property that attaches a LOD resource to a service functionality.

Non-functional properties in N F s may be of diverse types. They are therefore generally organized in profiles, where each profile P i,s describes a specific context information domain. Properties inside profiles can be of two types: quantitative and qualitative. Quantitative properties have generally numerical values while qualitative properties have string type values that can be attached to LOD resources. This annotation is modeled as follows: for a property p with set of values {v 1 , v 2 , . . . , v i }, a set of resources r i ∈ LOD can be attached to them. Formally,

∃p = {v 1 , v 2 , . . . , v i } ∈ P i,s | ⟨v i , α, r i ⟩, r i ∈ LOD.
As an illustration example, let's consider an hotel service named n s ="Le Plantagenêt" with only one feature F s = {Hotel }. The annotation set of this service is A s = {dbp : Hotel}. It has one DBpedia resource3 attached to the functionality Hotel. This service has a profile that describes service preferences as non-functional properties: N F s = {P pref erences,s }, where P pref erences,s = {T otalCapacity = 33; Ranking = 3, Comf ortServices = dbr:Internet, SpokenLangues = {French,English}}.

Functional matching of services

The first step of contextual services discovery considers service functional annotation resources. Considering a user request defined as of a set of terms R = {t 1 , t 2 . . . t i } where each term can be attached to a subset of annotation resources A R ∈ LOD such that ∀t ∈ R, ∃r i ∈ A R |⟨t i , α, r i ⟩, the similarity between the request R, annotated by A R , and service s, which functionalities are annotated by A s is defined based on LODS measure as follows:

Sim F (R, s) = a∈A R b∈As LODS ℓ,ℓ ′ (a, b) |A R | × |A s | (4.17)
Sim F is a classical aggregation measure [START_REF] Harispe | Semantic measures based on RDF projections: Application to content-based recommendation systems[END_REF] that allows the comparison of two objects annotated with semantic concepts. It computes the scores obtained from applying LODS

Non-functional matching of services

At this second matchmaking stage, we first use semantic rules to eliminate services that do not satisfy mandatory user requirements. Then, a profile-based similarity measure is applied to the filtered services in order to measure their relevance to the user profile. Considering the variety of information that can be found in a contextual environment, each type of information is represented in a separate profile structure. For instance, we can find a profile for user preferences, a second for user device specifications, a third for information about surrounding environment, etc. These information can either be explicitly provided by the user/service-provider or implicitly leaned by the system. Formally, for a user u and a service s, the set of profiles describing user/service non-functional properties in a particular context situation is P 1,X , P 2,X , ...P n,X where X ∈ {u, s}. Each profile is described by a set of properties P i,X = {x 1 , x 2 , ..., x n }. We compute the non-functional similarity between u and s profiles as follows:

Sim N F (u, s) = λ 1 f (P 1,u , P 1,s ) + λ 2 f (P 2,u , P 2,s ) + ... + λ n f (P n,u , P n,s ) (4.18)
where λ i is the weight expressing the importance of the profile in this particular context. The function f computes the similarity between two profiles. It is based on measure defined in [START_REF] Belkhirat | A new similarity measure for the profiles management[END_REF]. We extend the latter to take into account the different types of data present in user/service profiles. We integrate our LODS similarity measure into the extended measure in order to evaluate the quantitative information present in profiles. Formally, consider P i,u = {x 1 , x 2 , ..., x n } and P i,s = {y 1 , y 2 , ..., y m } two profiles describing respectively a user u and a service s properties in a particular context situation, we define the similarity P i,u and P i,s as follows:

f (P i,u , P i,s ) = a i=N i=1 w i × ASim(x i , y i ) a i=a i=1 w i + b i=b i=1 w a+i + c i=c i=1 w a+b+i (4.19)
where, a is the number of common properties of X and Y , b is the number of properties belonging to X but not to Y , and c is the number of properties belonging to Y but not to X. Each property has a weight w i , where n i=1 w i = 1. The atomic measure ASim is calculated depending on the property types. It uses LODS for LOD properties and typical data type specific measures for other cases such as String, Numerical, intervals, and Sets properties. A more detailed formalization of ASim is given in [START_REF] Cheniki | Context-aware and linked open data based service discovery[END_REF].

The proposed LOD-based context-aware service recommendation approach was applied 4.4. LDS LIBRARY in the Tourism domain within the Smart Loire4 research project as described in Section 4.5.

LDS library

In order to go further than the LODS similarity measure, we propose LDS (Linked Data Similarity) Library as an open source Java software library of LOD-based semantic similarity measures. LDS is available at https://github.com/FouadKom/lds.git. LDS defines a generic, reusable, and extensible architecture that integrates the best-known existing LOD-based similarity measures and supports both developers and researchers who intend to use these implemented measures or develop their own new ones.

LDS development follows the following requirements: (i) Simple design to facilitate the reuse of the tool and provide developers the ability to extend and use it with their developed semantic measures; (ii) Efficient LOD querying, caching and indexing to ensure similarity calculation efficiency and scalability; and (iii) Extensibility to offers developers a way to implement rapidly their measures and incorporate the library with their work.

The LDS architecture shown in Figure 4.1 has 5 main components: (i) Similarity Engine which acts as the interaction interface of LDS with external programs. (ii) LOD-based Similarity which calculates the similarity values. (iii) Linked data Manager which retrieves data for similarity calculation. These two components act as plugability layer allowing to easily integrate new similarity measure as subclass of LOD-based Similarity and the corresponding subclass of Linked data Manager. (vi) Linked data Indexer implements a mechanism for data indexing and caching to allow scalability and efficiency of LDS. (v) Finally Linked data Benchmark is used for testing and measures evaluations. The full architecture of LDS with detailed description of its components is provided in [START_REF] Komeiha | LDS: java library for linked open data based similarity measures[END_REF].

In its current version the library implements the following LOD-based similarity measures: LODS and its sub-measures SimI, SimC, and SimP discussed earlier, Linked Data Semantic Distance (LDSD) [START_REF] Passant | Measuring semantic distance on linking data and using it for resources recommendations[END_REF] and its extensions [START_REF] Passant | Measuring semantic distance on linking data and using it for resources recommendations[END_REF][START_REF] Alfarhood | Exploiting Semantic Distance in Linked Open Data for Recommendation[END_REF], Resource Similarity (Resim) [START_REF] Piao | Computing the semantic similarity of resources in DBpedia for recommendation purposes[END_REF] and its extensions [START_REF] Alfarhood | Exploiting Semantic Distance in Linked Open Data for Recommendation[END_REF], and Partitioned Information Content Similarity (PICSS) [START_REF] Meymandpour | Enhancing recommender systems using linked open data-based semantic analysis of items[END_REF].

In addition, to evaluate the ease of usage and extensibility of LDS, we proposed a new LOD-based similarity measure, Extended Partitioned Information Content Similarity (EPICS), which extends PICSS by considering an additional set of features called similar features, which considers the similarity between resources based on shared properties and directions. The evaluation results not only highlighted the potential of EPICS but more importantly the effectiveness of LDS as a core library for composing, implementing, and testing new similarity measures.

IMPLEMENTATION AND EVALUATION

A more detailed presentation of LDS as well as detailed performance study are given in [START_REF] Komeiha | LDS: java library for linked open data based similarity measures[END_REF]. LDS served as underlying framework for similarity calculation in a Privacy-aware IoT Device Recommendation approach we propose and describe in [START_REF] Komeiha | Towards a privacy conserved and linked open data based device recommendation in iot[END_REF].

Implementation and Evaluation

This section will briefly describe the application of the LOD-based context-aware service recommendation approach in the Tourism domain and the performance study of LODS measure and LDS library. Detailed experiments can be respectively found in [START_REF] Cheniki | Context-aware and linked open data based service discovery[END_REF], [START_REF] Cheniki | LODS: A linked open data based similarity measure[END_REF], and [START_REF] Komeiha | LDS: java library for linked open data based similarity measures[END_REF].

LODS similarity measure evaluation

LODS similarity measure is implemented using Java and Jena framework 5 . We obtain required data directly from provided SPARQL endpoints as much as possible. Unreachable data via SPARQL endpoints or HTTP principles are downloaded and hosted on a local endpoint. We rely on DBpedia knowledge base (DBp) as a primary source of semantic linked data. We then use interlink relationships to navigate through and get more rich data from Wikidata The similarity measure is applied on three well-known benchmarks: MC-30 that contains 30 pairs of concepts [START_REF] Miller | Contextual correlates of semantic similarity[END_REF], RG-65 [START_REF] Rubenstein | Contextual correlates of synonymy[END_REF] that contains 65 pairs of concepts, and similarity gold-standard of WSIM-3536 collection. Results are given in Figure 4.2 and show high accuracy of LODS combined measure on LOD augmented data.

LOD-based context-aware service recommendation in the context of Smart Loire project

Smart Loire7 is a research project funded by the region Centre Val de Loire with the main objective of cultural tourism promotion in Loire Valley through the development of contextualized and personalized Trip planning framework. The work described in the current chapter is partly supported by the Smart Loire project. We therefore consider to evaluate the proposed approach on the project dataset. The dataset is provided by ADT37 (Agence Départementale de Tourisme d'Indre-et-Loire) through its platform Tourinsoft (http://www.tourinsoft.com/). The dataset contains 1632 services classified into different touristic offer categories and annotated with functional and non-functional properties. A selection of categories is given in Table 4.1 and an example of service description is given in Figure 4.3.

Following the proposed approach steps, we annotated each service with a set of LOD resources considering Classification properties as functional properties and the remaining ones, such as PrestationsEquipements, Location, and Payment Modes, as non functional properties. We then proposed to a total of 22 users to express queries about tourist services and collected the most common keywords in Table 4.2. We the consider these queries to run the functional service discovery algorithm implementing Equation 4.17. For each query we consider the 10 best ranked services. The precision average is 1 for the first 3 services for all the queries, between 0.8 and 0.97 for the 4th to the 7th services and higher than 0.68 for the remaining services. Thes rates show the accuracy of the proposed approach.

IMPLEMENTATION AND EVALUATION

Moving to the non functional step, we selected 5 users who were asked to define their profiles in terms of preferences over non-functional service properties and to specify as example of mandatory constraint the maximum geographic distance in which services are retrieved (2km, 5km, 10km, 20km, 60km). Other examples of non-functional properties are given in Table 4.3. We consider the same weight (w i ) for all the properties. We apply non-functional constraints, the algorithm implementing Equation 4.18, on the results in the previous step and measure the context precision as the number of remaining non filtered services divided by the number of services of the previous step. Context precision for each of the 5 users is shown in Figure 4.4 (Left). We also evaluate the overall quality of the discovery compared to user evaluation of the returned results.

Related work

In this section we briefly review the main approaches close to our contribution on LOD based similarity measure and its use to context-aware service discovery. A more detailed review of the state-of-the-art is given in [START_REF] Cheniki | LODS: A linked open data based similarity measure[END_REF], [START_REF] Cheniki | Context-aware and linked open data based service discovery[END_REF], and [START_REF] Komeiha | LDS: java library for linked open data based similarity measures[END_REF].

The emergence of LOD and its rapid expansion through continuous interconnection of new resources motivated the its use as underlying semantic and linked data source to tackle many challenges such as interoperability and recommendation. These challenges usually come to, or at least include, similarity measuring between distinct entities taking advantage of LOD.

In [START_REF] Passant | Measuring semantic distance on linking data and using it for resources recommendations[END_REF] the author proposed a Linked Data Semantic Distance (LDSD) which relies on direct and indirect relationships between two DBpedia resources in the context of music recommendation. LDSD applies on a cleaned dataset of DBpedia and considers relations between resources and concepts. This limits its accuracy compared to our approach as LDSD does not benefit from external interlinked datasets, it does not consider existing taxonomic structures and it ignores additional characterizing properties.

In [START_REF] Pirrò | Reword: Semantic relatedness in the web of data[END_REF] authors propose REW OrD, a measure based on a Predicate Frequency, Inverse Triple Frequency (PF/ITF ) model inspired from TF/IDF used to compute the informativeness of the paths that connect compared resources. It is also limited in terms of considered LOD dimensions compared to LODS.

Later on [START_REF] Meymandpour | Enhancing recommender systems using linked open data-based semantic analysis of items[END_REF] proposed Partitioned Information Content Semantic Similarity (PICSS), an information content (IC) based approach to compute the similarity between LOD resources. PICSS uses ingoing and outgoing edges as features and then compares resources based on Tversky model [START_REF] Tversky | Features of similarity[END_REF]. Although author report efficient performance evaluations, there is no formal presentation to allow generalizing the measure adoption, especially for the resource enriching process. In addition, PICSS has the same shortcomings as the two previously cited measures as it consider less features than LODS.

As for the use of semantic similarities for web services, in particular for context-aware service discovery, there are many proposed approaches following the emergence of ubiquitous computing research era. Going further than the simple use of locations, the proposed approaches model contextual profiles with additional properties related to user, to used devices, and to services [10] [62]. Compared to these works, our approach allows to integrate multiple types of context information requirements which improves the discovery effectiveness.

Context-aware services discovery approaches are usually defined as two steps corre-4.7. CONCLUSION sponding to functional and non-functional matchmaking as it is the case for our approach. This is the case for approaches in [START_REF] Toninelli | Semantic-based discovery to support mobile context-aware service access[END_REF], [START_REF] Najar | Service discovery mechanism for an intentional pervasive information system[END_REF], and [START_REF] Ruta | Semantic matchmaking for location-aware ubiquitous resource discovery[END_REF]. Most of these approaches, however, rely on single ontologies for semantic similarity, and usually for the functional matchmaking only. The non-functional matchmaking is reduced to rule-based verification of contextual constraints [START_REF] Chellouche | Context-aware multimedia services provisioning in future internet using ontology and rules[END_REF][START_REF] Fenza | Hybrid approach for context-aware service discovery in healthcare domain[END_REF].

Our approach goes further through the use of LOD instead of single ontologies for similarity measuring. The proposed LODS measure is then used in both functional and nonfunctional discovery steps. Only mandatory contextual constraints are modeled through rules. The remaining profile properties are considered using LODS.

Conclusion

Starting from the challenge of providing cross-domain semantically-enabled service recommendation discussed at the end of the previous chapter, we consider Linked Open Data instead of single ontologies as semantic support underlying service frameworks. We propose LODS, a LOD-based similarity measure that exploits (i) the taxonomic structure of ontological concepts, (ii) the classification categories of LOD resources, and (iii) their characterizing properties. Prior to computing the similarity, the approach performs a data augmentation process that takes advantage of LOD interlink relationships with external datasets to enrich data involved in computing similarity measure to reduce the problem of lack of information within a single dataset. We build on top of LODS a context-aware service recommendation approach applied to the tourism domain. Services are modeled through functional and non-functional properties. LOD based annotation process allows to match these properties with corresponding LOD resources. Then adapted matchmaking based on LODS is performed to select the most relevant services for user needs in a given context. In addition, the LODS measure is packaged within a LOD-based similarity library that also implements the best-known state-of-the-art measures to allow their use and integration in any framework. The three contributions were evaluated and prove efficient results.

LODS similarity measure will also be considered in the contribution detailed in next chapters (Chapter 5 and Chapter 7).

The work described in this chapter was conducted during the scientific stay of Nasreddine Cheniki at the University of Tours between 2016 and 2019 as part of his PhD [START_REF] Cheniki | Découverte des Web Services Mobiles[END_REF] and during the PhD of Fouad Komeiha to be defended in 2023. It is mainly published in the following conference papers: [START_REF] Cheniki | LODS: A linked open data based similarity measure[END_REF], [START_REF] Cheniki | Context-aware and linked open data based service discovery[END_REF], and [START_REF] Komeiha | LDS: java library for linked open data based similarity measures[END_REF].

Chapter 5

Configuration approach for personalized mashups This chapter describes our contribution regarding the challenge of contextualized usercentric service interaction discussed in Section 2.1.2. It provides a detailed view of the approach described in Section 2.2.2.1, which models personalized service mashup building as a configuration problem based on Configuration Theory [START_REF] Stein | Functional models in configuration systems[END_REF], then identifies the configuration solutions as relevant mashups. The approach relies also on a set of visual artifacts as Domain Specific Visual Language to allow end-user express preferences and constraints on the built Mashups. These artifacts are connected with a rule-based declarative language for consistent Mashup generation.

INTRODUCTION

Introduction

With the large adoption of Service-Oriented Architecture (SOA) and Cloud Computing, Web services, generally in the form of Web APIs, have grown rapidly both in quantity and diversity. Users are surrounded with these services supporting their lifestyles: services that track their activity through smartphones, enable efficient use of home monitoring, provide the weather forecast or traffic reports, etc. They have become the first-class citizens on the Web and the core functionality of any Web application. However, they can no more be considered as independent/isolated entities, i.e. used individually, but as a set of pairs characterised by relationships that favour the interconnection. Their connected usage has the potential to create new value-added services. This type of service is known as a mashup. In general, a mashup is the process of merging a huge amount of heterogeneous data from different sources providing a fragmented view of the information and transforming these islands of data into an integrated view to fulfill complex needs [START_REF] Daniel | Mashups[END_REF][START_REF] Casati | Developing mashup tools for end-users: on the importance of the application domain[END_REF]. Moreover, nowadays end-users occupy an important position in the development of content, it makes sense to involve them in the mashup creation process through transforming end-users to prosumers (producer + consumer). In fact, there is an increasing need by end-users to realise their own ideas and to express their own creativity [START_REF] Valderas | A social network for supporting end users in the composition of services: definition and proof of concept[END_REF]. So far, systems have been conceived as pre-packaged sets of data, functionality, and visualisations that somebody else (the software developer) builds for us which no longer meets this new need. In addition, mobile devices are considered as the universal gateway between services and end-users.

Nevertheless, services are developed using SOAP-based or REST-based technology, which is difficult to understand for non-technical end-users aiming to compose services based on their specific preferences and/or needs. For example, if a user wants to plan for a trip, she/he will search for a Point Of Interest to visit (POI), restaurants and hotels. She/he would have to interact separately with the different services, handling different URLs, comparing retrieved results, and then aggregate data to respond to a particular travel information need. Even, the recommender system seems to provide a solution to the trip planning problem, they are limited to a list of recommended POI and lack of personalization. The user still needs to guess how much time is needed to visit each single attraction, and to devise a smart strategy to schedule them in order to build a personalized itinerary. A Travel Mashup is an automated solution for this scenario, where travel relevant data is retrieved and aggregated from services considering users' travel information needs, which may be weighted further by their personal preferences, as well as user's context then presented as directly usable information [START_REF] Cano | Travel mashups[END_REF]. However, mashup tools require a programming background, so they are not suitable for end-users [START_REF] Ardito | From smart objects to smart experiences: An end-user development approach[END_REF]. The inherent complexity of service composition must be adequately abstracted to give end-users easy-to-use development environments that hide all the underlying technical details. Regarding this, we think

CONFIGURATION OF PERSONALIZED TRAVEL MASHUP OVERVIEW

that an ideal mashup platform should offer a lightweight development process promoting user-driven-innovation processes. It should support end-users by means of composition paradigms that abstract from technical details and fit with the particularities of the usage domain dealing with domain-specific paradigms to increase end-user innovation potential.

In this context, this chapter proposes a configuration-based approach for personalised mashup that provides end-users with a transparent service composition. A Domain Specific Visual Language (DSVL) that allows end-users to easily build mashup-based compositions is proposed. Then, the composition problem is modeled as a configuration problem to respond to the mashup query. In order to provide users with a personalised solutions, alternatives are generated by reconfiguration process. In addition, we propose a LODbased reconfiguration process to improve the recommendation accuracy.

The remainder of this chapter is organised as follows: Section 5.2 introduces an overview of configuration-based approach. Section 5.3 exposes the DSVL for mashup query definition. Section 5.5 presents the configuration problem. Section 5.6 details the reconfiguration process. Section 5.7 provides insights on the implementation and the conducted experiments. Section 5.8 presents the related work. Finally, Section 5.9 concludes the paper.

Configuration of Personalized Travel Mashup Overview

An overview of our personalized travel mashup framework is shown on Figure 5.1. The framework provides end-users with interactive environment to compose services for their trip planning corresponding to their situational needs through a three-layer architecture:

The Service Layer includes the services developed by professionals developers. Particularly, services are implemented based on SOAP or REST technology.

The Application Layer provides end-users with a Visual Mashup Environment composed of three editors: (i) the mashup editor allows user to compose services, (ii) the rule editor allows to create rules describing situations to adapt the travel mashup, and (iii) a presentation UI to show the execution of the travel mashup in form of itinerary recommendation. This layer interacts with a Mashup Schema to access high-level service representations used by end-users to compose services and create the mashup query.

The Component Layer offers the software artefacts to connect the Application Layer and the Service Layer. It implements the mashup configuration approach relying on the following components. The Mashup Schema allows to map service implementations and service high-level representation which hides service technological issues. It describes two facets of services: an invocation facet, used to invoke services; and a semantic facet, used by Visual Mashup Environment. Developers deploy the service to the mashup schema by defining invocation and semantic representation in order to make it available to the mashup 2. End-users interact with the visual environment to create the mashup query that includes the desired services.

3. The Mashup Visual Environment provides end-users with high-level service representation provided by the Mashup Schema through semantic service facet.

4. End-users complete the mashup by creating constraints and context-aware rules using the rule editor and then send it to the Invocation Module.

5. The Invocation Module requests the Mashup Schema to get service invocation data included in the mashup. Considering end-user rules and abstract mashup query, it generates a concrete query and sends it to the configuration module.

DSVL FOR MASHUP QUERY DEFINITION

6. The configuration module executes the mashup query and generates itinerary suggestions.

7. The Presentation UI displays the recommended itineraries on a map and as a timeline.

DSVL for Mashup Query Definition

In this section, we present the key concepts of the DSVL which offer to end-users the possibility to compose services using high-level description. More details are given in [START_REF] Boulakbech | Configuration approach for personalized travel mashup[END_REF].

An Activity A is a high level representation of a service which is developed by professionals and is registered in the Mashup Schema. A =< name, description, graphicalicon, P > where name, description and graphical icon hide the technological issues that are required to invoke the service for end-users, and P is the set of activity parameters. Each parameter p ∈ P has a name, a value and a source defining how the value should be provided.

We choose the term activity instead of service because it is closer to end-users' mental model. Thus, end-users have just to indicate the desired activities to perform in a mashup, such as get route from user position to an address, checking weather forecast, and so on. Furthermore, we use the term parameters to represent input and output without distinction to facilitate the mapping task for end-users.

Activities are connected through Operators such as AND, OR, NEXT. They can also be filtered through filter operators. Different metaphors were evaluated by end-users in order to determine intuitive and most adequate operators for components connection [START_REF] Danado | Puzzle: A mobile application development environment using a jigsaw metaphor[END_REF]. The puzzle and workflow metaphors were the two most ranked ones. We therefore considered the puzzle metaphors to create the graphical representation of a mashup, as shown in Figure 5.2. The contextual situation is described through a set of user-specified rules using graphical notations to adapt mashups according to user's situational needs. We structure the contextual rule in two parts: Conditions representing the situation for condition activation, 5.4. MASHUP SCHEMA and Actions to be executed. Typically, end-users interpret the "OR" operator as an "exclusive OR". Therefore, we propose a high-level rule description that hides this complexity based on ALL CONDITIONS connector and AT LEAST ONE CONDITION connector that refers respectively to AND and OR logic operator. Figure 5.3 shows the rule editor interface.

Mashup Schema

The mashup Schema acts as a gateway between end-users and service implementations, managing service data types from two facets: Semantic Facet and Invocation Facet.

Semantic Facet describes the goal of each service in order to be handled by end-users. Once developers register the service into the mashup schema by defining its invocation and semantic facets, it becomes available for end-users. The high-level service representation provided by the semantic facet and corresponding to the activity is used by end-users for mashup creation. It is represented with blue headers in Figure 5.4.

Invocation Facet provides the technological details of the service such as protocol, url, port, parameters, etc. This data is hidden to end-users at composition time. It is used only for service invocation at runtime. It is represented with green headers in Figure 5.4.

The mashup schema is implemented as a Java Web module, and expose a REST API to interact with it through the HTTP protocol based on JSON data format.

Configuration Problem

The service composition is seen as a configuration that consists to put together components following a logical description that respects user constraints to build a composite component responding to the user query. The mashup is designed using functionalbased aggregation. Formally, we define the service composition as a Configuration Problem CP = (m, R, CK) where m denotes the mashup query, R denotes the set of context-aware rules, and CK represents the Configuration Knowledge used to aggregate services that will be detailed in the following.

Configuration Knowledge

The configuration knowledge describes how to compose data (service instance) by mean of configuration operators and configuration rules that allow to generate a composition graph dependency. It relies on service functionalities, in the form of property-value pairs, to build composition called functional connections. Configuration operators specify how to aggregate services based on service functionalities (f i ∈ F ) to generate composite functionalities (q i ∈ Q). Formally, let (f, x) and (g, y) be two functionalities and let op(x, y) be a configuration operator. Then, the composite functionality q = ϕ((f, x), (g, y)) is defined as follows:

ϕ((f, x), (g, y)) = (f, op f (x, y)) if f = g (f,
x), (g, y) otherwise.

CONFIGURATION PROBLEM

The composite functionality is a set that contains either a single property if the functionalities are equal, or the two properties if they are not equal. Thus, if two services, which have some properties in common, are included in a set containing the configuration, then it is necessary to compute the values of these properties in some way. This computation is done by the configuration operator. If this operator is not defined for the given value constellation, then these two services cannot occur at the same time in the set of configuration.

Configuration solution

A configuration solution CS ∈ CSS(Conf igurationSolutionSet) to a configuration problem CP is defined as a pair CS = (I, Q) where:

• I: refers to the set of items in the form (n, s) expressing the fact that service s appears n times in the mashup to be configured.

• Q: is the set of mashup features (called quality) in the form of a pair (f, x) that defines the value of the feature f.

Given a set S of services, a configuration solution CS is built recursively as follows:

1. CS = (∅, ∅) is a configuration solution.

2. If CS = (I, Q) is a configuration solution and s ∈ S, then CS ′ = (I ′ , Q ′ ) is a configuration solution if the following conditions hold:

(i) For each (f, x) ∈ Q and for each (g, y) ∈ Q, the composite functionality ϕ((f, x), (g, y)) is defined or Q = ∅.

(ii)

I ′ = I\(k, c) ∪ (k + 1, c) if ∃(k, o) ∈ I I ∪ (1, c) otherwise.
(5.1)

(iii) Q ′ = Q ∪ (ϕ((f, x), (g, y))|(f, x) ∈ p c , (g, y) ∈ Q) if Q ̸ = ∅ p c otherwise. (5.2)
Condition (i) guarantees that service s ∈ S will be added to the configuration solution CS only if all the service properties can be combined with all CS qualities. Condition (ii) specifies how a new service can be added to the item set I. Condition (iii) specifies how a new set of qualities will be constructed when a new service is added to the configuration. Although qualities and functionalities are syntactically equal, we distinguish between them 5.5. CONFIGURATION PROBLEM since a functionality is the characteristic of a service, while a quality is the result of the combination of several services having the functionality f ∈ F . A configuration solution has the following characteristics: validity and coherence. Validity refers to user constraint satisfaction. Given a set V of non-negative values, an operator op : 2 V → R + and a budget threshold B, then ∀CS i ∈ CSS; i, j ∈ N, op(CS i .I j , CS i .I j+1 ) ≤ B. Budget can simply be the number of resources forming the configuration item solution. Coherence denotes context-aware solution.

For example, to deal with a travel mashup that includes a touristic activity, a restaurant activity, and an event activity for 1 day visit and 100€ as total budget, we define the following operator set overs services s i , s j ∈ S: OP = {op duration , op price } op price (s i , s j ) = s i .price + s j .price if s i .price + s j .price < B ⊥ otherwise.

(5.3) To generate the configuration solutions, we propose an incremental model that consists in creating compositions by pair patterns, two service instance are composed at the time, applying the configuration operators. An initial configuration solution CS 1 is generated and is extended to incorporate additional instances of candidates forming a new solution CS 2 . We call CS 2 partial configuration, as it does not yet satisfy the mashup query and must be completed by adding more instances. We repeat this step until reaching a final solution CS n . The proposed algorithm is detailed in [START_REF] Boulakbech | Configuration approach for personalized travel mashup[END_REF].

op duration (s i , s j ) = s i .d + s j .d if s i .d + s j .d + δt < D ⊥ otherwise. ( 5

RECONFIGURATION PROCESS

Reconfiguration Process

The reconfiguration process provides users with more alternatives to personalise the travel mashup using LODS similarity measure presented in the previous chapter. The DATAtourisme Enrichment module implements a lightweight integration process allowing to enrich the DATAtourisme1 dataset that aims to centralize, within a national French shared platform, travel information produced by different Tourism Committees. Such information is published as Linked Open Data to facilitate the creation of innovative travel applications. We propose to enrich it by collecting data from travel APIs such as Foursquare, Google Places, Sygic Travel, etc. and map the different pieces of data using the DATAtourisme ontology model. This ensures a unified data representation model and helps then to transform non-RDF data into semantic ones in order to complete the missing information in DATAtourisme dataset. Moreover, to model information that is not covered by this ontology, we can use Schema.org, tourism-domain ontologies or parts from Mio! ontology network [START_REF] Villalon | A context ontology for mobile environments[END_REF]. Furthermore, mapping the resulted unified semantic data to existing LOD datasets such as DBpedia 2 allows, in some cases, completing missing information that is not provided by API data sources. The mapping could then be exploited by LOD-based similarity measures such as LODS to propose similar touristic data. The final rich and semantically generated data is stored in a local RDF store. Generated mashup can be reconfigured by providing users the possibility to personalize their initial plan through adding or removing travel activities as well as adapting properties of a travel activity such as time activity for example. The reconfiguration process exploits 5.7. IMPLEMENTATION AND EVALUATION LODS, a LOD-based similarity measures, to produce similar travel activities as alternatives to the initial ones.

We illustrate in the Figure 5.6 a simplified example of data integration process. Tourism service information retrieved from two APIs (Google Places and Sygic Travel) are transformed (from XML and JSON respectively) into a semantic representation (RDF) before being integrated with DATAtourisme. New properties (rating and visit duration) have then been added to enrich the same service in DATAtourisme dataset.

Implementation and Evaluation

The proposed configuration approach for personalized travel mashup is implemented within a prototype called CART (Configured mAshup Recommender application for personalized Trip planning). CART architecture is structured into 3 layers following the architecture depicted in Figure 5.1. Technically, the service Layer is in charge of collecting travel data from Web APIs eg. Google Maps, Google Direction API, Google Places API,

IMPLEMENTATION AND EVALUATION

Forsquare and DATAtourisme. Based on JAXB API, the XML-data are serialized into POJO classes. The Mashup Layer implements the configuration approach as a SpringBoot App. The application layer is implemented as a client app consuming services from the mashup app. It includes UIs allowing users to build a query mashup for the trip plan indicating their preferences and constraints. In addition, CART provides end-users with interactive environment to define mashup query and visualizes visit plan recommendations for the Loire Valley region in France. The considered dataset includes more than 300 monuments, more than 30 remarkable gardens, 6 cities of art and history that crisscross the Loire Valley. Figure 5.7 shows the UIs of CART illustrating recommended itinerary. We evaluated the proposed approach by 15 end-users (9 male/6 female) with different programming knowledge levels. Our main idea was to propose to participants to explore the mashup environment in order to build the travel mashup and define context rules via the rule editor. Globally, most of the participants felt comfortable using the platform and they mention a good satisfaction level. Detailed scores are given in [START_REF] Boulakbech | Configuration approach for personalized travel mashup[END_REF].

The user were asket to answer a UEQ questionnaire which consists in describing two concepts with opposite meanings to be assessed on a Likert scale as shown in figure 5.8. The items constitute six different scales that are aimed at offering results categorized into attractiveness, perspicuity, efficiency, dependability, stimulation, and novelty [START_REF] Schrepp | Construction of a benchmark for the user experience questionnaire (ueq)[END_REF]. Based on this classification, we have extracted a short version of the questionnaire, more appropriate to our platform. We used UEQ to test if the Rule Editor system has sufficient user experience in its current implementation. As can be seen in Figure 5.8, and according to the UEQ methodology, all scales show a positive evaluation, i.e. they are greater than 0.8. In order to interpret these results, we have based on the benchmark graph built by [START_REF] Schrepp | Construction of a benchmark for the user experience questionnaire (ueq)[END_REF], illustrated by the Figure 5.8. We can note that all factors were given a value exceeding the average, which confirms a positive evaluation. The factor with the highest 5.8. RELATED WORK score is dependability reflecting a strong sense of control over the interaction with the system.

Related Work

Several mashup platforms: NaturalMash [START_REF] Aghaee | End-user development of mashups with naturalmash[END_REF]; ResEval [START_REF] Daniel | Mashups[END_REF]; MashupEditor [START_REF] Ghiani | An environment for end-user development of web mashups[END_REF]; Puzzle [START_REF] Danado | Puzzle: A mobile application development environment using a jigsaw metaphor[END_REF]; EUCalip [START_REF] Valderas | A mobile-based solution for supporting end-users in the composition of services[END_REF] [START_REF] Valderas | Supporting a hybrid composition of microservices. the eucaliptool platform[END_REF], have been proposed to allow end-users to visually compose data and services from different sources, so that they can satisfy their information needs.

For instance, Puzzle [START_REF] Danado | Puzzle: A mobile application development environment using a jigsaw metaphor[END_REF] is a framework that allows end-users to create mobile applications. It allows the composition of device, smart objects, and Web service functionality using jigsaw metaphor that provides users to put together services without handling technical issues. EUCalipTool [START_REF] Valderas | Supporting a hybrid composition of microservices. the eucaliptool platform[END_REF] offers an intuitive mobile environment that allows end-users to create service compositions based on a domain-specific language. Although theses approaches provide a domain-specific solution, they lack context-awareness.

Various applications for customizing the behaviour of existing applications in mobile devices or Web services have been introduced, such as IFTTT [START_REF] Ovadia | Automate the internet with "if this then that"(ifttt)[END_REF]. The idea is to describe the system behaviour based on if-then statements that specify how the system should behave regarding specific situations. They connect apps, devices and services to trigger one or more automation using abstract descriptions of services that mask technology details. EFESTO [START_REF] Ardito | From smart objects to smart experiences: An end-user development approach[END_REF] provides end-users with a smart interactive experience to synchronize the behaviour of smart objects. It implements a visual paradigm for rule creation to support users in smart visit definition for cultural heritage scenario. Block Composer [START_REF] Mattioli | A visual environment for end-user creation of iot customization rules with recommendation support[END_REF], a system for the end-user definition of trigger-action rules, uses the puzzle metaphor to support users in creating such rules. Creating rules is based on visual blocks, implementing a free composition style where users are supported by color and shape coherence of blocks, and integrated with recommendation techniques in order to provide intelligent support during rule creation.

The analysis of the related work illustrates that all the approaches provide high-level 5.9. CONCLUSION service representation to hide technology issues and support end-users in service composition. However, composing actions and conditions in rule definition for personalised mashup still difficult for end-user as using logic operators is not trivial for them. Therefore, abstract descriptions for rule definition is needed. No approach combines domain-specific, contextaware and propose high-level representation of services and rules to effectively support end-users in personalised service mashup. Our approach fills this gap.

Conclusion

In this chapter, we describe the configuration-based approach for personalised mashup which is a domain-specific and context-aware mashup approach helping end-users in Tourism domain. The proposed approach is based on three key pillars: (i) Interactive mashup environment that allows end-users to create compositions by means of a DSVL offering high-level service representation. A Mashup Schema plays the role of a gateway between end-users and service implementation. This aspect allows us to achieve the goal of keeping end-users unaware of technological issue related with services. In addition, descriptions of available services are totally decoupled from the end-user tool, facilitating its evolution and maintenance. (ii) Configuration Module that models composition problem using the configuration theory. It aggregates travel related data to generate configuration that matches user constraints and provides context-aware solutions in incremental way. (iii) Reconfiguration process which calculates alternative solutions based on LODS similarity measure.

The work described in this chapter was conducted during the PhD of Marwa Boulakbech defended on July 2020 [START_REF] Boulakbech | Mashup de services par configuration : application au domaine touristique[END_REF]. It is mainly published in the following journal and conference papers: [START_REF] Boulakbech | Smartloire: A web mashup based tool for personalized touristic plans construction[END_REF], [START_REF] Boulakbech | Iot mashups: From iot big data to iot big service[END_REF], [START_REF] Boulakbech | A smart mobiweb mashup trip planner tool[END_REF], [START_REF] Boulakbech | Visual configuration for restful mobile web mashups[END_REF], [START_REF] Boulakbech | Linked data graphs for semantic data integration in the CART system[END_REF], [START_REF] Boulakbech | Configuring restful web services for personalized trip planning[END_REF], [START_REF] Cheniki | A linked open data based approach for trip recommendation[END_REF], and [START_REF] Boulakbech | Configuration approach for personalized travel mashup[END_REF].

Chapter 6

User-centric device recommendation This chapter describes our contribution regarding the challenge of providing fluent userside service running management discussed in Section 2.1.2.2. It provides a detailed view of the approach described in Section 2.2.2.2, which consists in a user-centric architecture following Liquid Software principals to allow for smooth service migration from one device to another from the user-side. The proposed approach also defines semantic and rule-based migration context to ensure service interaction continuity while switching to new devices.

Introduction

Nowadays, multiple-device ownership is increasing more and more driven by the high availability of smart objects, their increasing performances and the progress of data management and transfer protocols. It is indeed expected that by 2025, more than 75 billion 6.1. INTRODUCTION smart devices will be in use, according to Statistica1 and Cisco2 . It is now common to use simultaneously or in sequence at least 2 smart devices by the same user to perform daily tasks. Especially with the paradigm of Everything-as-a-Service (XaaS), people can access different services anywhere, anytime and from almost any device. In this context, multiple-device ownership raises new challenges when users run services over their different devices. One of the very common challenges is to switch from one device to another while keeping interaction with the same service. Services are hosted and managed on Web servers or Cloud which usually allow for multiple device access. They however require the user to login each time a new device is used. Moreover, in most cases, users have to restart interaction sessions from scratch. Two typical scenarios can be considered to illustrate the need for alternative user-centric solution: a light-coupling scenario with email service and tight-coupling scenario with YouTube service. Considering server-side synchronization, starting email writing on a device and then moving to a second device requires the login on both devices and saving the written part of the email as a draft from the first device to avoid data loss and to continue from the second device. Similarly, for video streaming on YouTube, user should login from both devices and resume video from saved history session on YouTube.

The challenge of fluently moving services through devices in multiplatform environments was addressed through the Liquid Software paradigm [START_REF] Hartman | Liquid software: A new paradigm for networked systems[END_REF]. Achieving Liquid Software principals requires to build an entire infrastructure for dynamically moving functionality throughout a server-side or client-side network. Since then, almost all proposed Liquid Software approaches rely on server-side synchronization [START_REF] Da Silva | Diamond -A cube model proposal based on a centric architecture approach to enhance liquid software model approaches[END_REF] and still face data and time loss issues. Nevertheless, the shift from SOAP to REST services is a opportunity to achieve user-side liquid software frameworks. REST and RESTfull require services to follow some constraints as described in [START_REF] Pautasso | RESTful Web Services: Principles, Patterns, Emerging Technologies[END_REF], such as stateless interaction, hypermedia status, and addressability of resources. Following these specific constraints can help achieving interaction session sharing between devices regardless server synchronization. The study in [START_REF] Da Silva | Diamond -A cube model proposal based on a centric architecture approach to enhance liquid software model approaches[END_REF] shows, however, that initiatives in this direction are still missing.

Successful migration of service interaction requires to ensure that target device is suitable for hosting the interaction. Also, it has to capture the users preferences, timeline and other features related to security, reliability, compatibility of devices, constraints of the services, etc. This issue has also been widely covered from the cloud/server side, as part of cloud resource management [START_REF] Ma | Ontology-based resource management for cloud computing[END_REF] or in the context of IoT device management [START_REF] Komeiha | Towards a privacy conserved and linked open data based device recommendation in iot[END_REF]. From user-side however, efficient device recommendation modules are still to be defined. Such issue is more challenging as far as we consider the limited device computation performances and the lack of access to large semantic resources, such as Linked Open Data, for similarity

CUBE: APPROACH OVERVIEW AND FORMAL REPRESENTATION calculation.

In this chapter we present our approach to provide users with user-centric framework, CUBE, that allows to for smooth user-service interaction migration over multiple devices from user side. The approach relies on Liquid Software principals [START_REF] Hartman | Liquid software: A new paradigm for networked systems[END_REF] and REST/RESTful constraints [START_REF] Fielding | Principled design of the modern web architecture[END_REF], [START_REF] Pautasso | RESTful Web Services: Principles, Patterns, Emerging Technologies[END_REF]. We also define a semantic rule-based declarative module to ensure successful interaction continuity on the hist devices. The reminder of the chapter is organized as follows. Section 6.2 presents the CUBE principals and formalization. Section 6.3 presents the framework architecture and main components. Section 6.4 presents the semantic rule-based module to ensure user-service interaction continuity over devices. Section 6.5 provides insights on implemented prototypes and evaluation results. Section 6.6 reviews the main state-of-the-art approaches related to our contribution. Finally, Section 6.7 concludes the chapter.

CUBE: Approach overview and formal representation

As alternative to server-side synchronization that allows time and data saving, we propose the CUBE, a user-centric framework that follows Liquid Software principals and defines a layered architecture built upon REST and RESTful constraints to ensure smooth user-service interaction migration in multiple device contexts from the user-side. With CUBE, both tight-coupling and light-coupling scenarios introduced previously will be handled locally preserving data and session states without the need for multiple login. The user logs in from the first device then the session can be moved to a second device through the use of RESTful properties allowing to manage data status. The multiple-device user context is virtualized for the server which continues interaction as with the first device.

In its abstract representation, the CUBE is seen as a four component model geometrically represented as: a central point which represents the user, surrounded by a first cube, called INNER CUBE, representing the set of user devices, contained in turn in a second cube, called the OUTER CUBE, representing the set of services, and between the two cubes the POOL AREA hosting the user-service interactions through the devices. [START_REF] Hartman | Liquid software: A new paradigm for networked systems[END_REF]. The CUBE restricts the UCN definition to a single user instead of multiple users in UCN. In our first proposal of CUBE framework, the device discovery R d in the user context relies on graph representation and graph search algorithms as detailed in [START_REF] Da Silva | The CUBE: A User-Centric system-model architecture for Web service migration through multiple devices[END_REF]. Later on we enhance this module with semantic rules discussed in Section 6.4.

CUBE: Architecture and technical considerations

CUBE architecture

The framework general architecture is depicted in Figure 6 The content management system 101 will interact on two fronts, user device front, 100, and service front, 107. First, at user device front 100, the user specifies the first device in use, d p . Its choice is made from the available devices owned by the same user, following R d discovery results. d p is added to 102. Other user devices discovered through R d are also added to 102. Then, the user selects the service, s to interact with through service front 107. The service discovery process in out of scope of this work. s is added to 106. The CUBE will be able to manage interactions between d p and s through receiving and sending different types of requests made by the 100 through the conversation layer 105.

The INNER CUBE 102 interacts with the user's devices, allowing to switch between 6.3. CUBE: ARCHITECTURE AND TECHNICAL CONSIDERATIONS Figure 6.2: The CUBE architecture and its internal modules. them during the service execution. While services and devices change, all the information and sessions retrieved are stored at 104 via module 103. Thus, when any change of device is required, the user does not need to start from scratch in order to retrieve or fill in her/his information. The conversation layer, 105, is also an API built under RESTful principles and is responsible for changing information across the multi-OS environment. Moreover, this part of the module provides a secure connection for the user devices through a token created in the INNER CUBE 102 by the join of User ID from devices and services which are provided by the OUTER CUBE 106. This type of addressability through a resource identification allows the pool area to ensure a stateless interaction between services. Portion 107 relies on pool area to request external services.

CUBE layered representation and technical considerations

In order to achieve the expected functionalities of the CUBE framework, we follow a layered representation which holds a parallel with TCP/IP layers while proposing additional improvements on each layer to meet the interaction migration requirements. Figure 6.3 shows CUBE layers and their correspondence with TCP/IP. The layered CUBE architecture is made of five different layers: (i) Application, (ii) Request, (iii) Conversation, (iv) Data, and (v) Physical that we will briefly describe hereafter. More detailed descriptions and technical implementation details are provided [START_REF] Da Silva | The CUBE: A User-Centric system-model architecture for Web service migration through multiple devices[END_REF].

Our model is based on an innovative approach with a strong attention to REST/REST- ful principals and constraints [START_REF] Pautasso | RESTful Web Services: Principles, Patterns, Emerging Technologies[END_REF]. We therefore revisited the definition of the layers and propose separated layers for REST and RESTful approaches. The Application and Request layers work together to allow for the multiplatform, where a service can be started for example on an Android device and then moved to an iOS device. In order to achieve this kind of fluidity, we chose JavaScript (JS) as the language for the two firsts layers.

The Application Layer makes use of the Stormpath3 for user authentication and security management and respects the principals of the REST model. This layer will be only one of the model layers to appear to the user to allow verifying all the synchronized multi-devices on the user-centric network.

The Request Layer acts as a Middleware, allowing for a connection between Application and Conversation Layers through an oAuth Token method. Basically, this layer works by sending the HTTP responses across the model. It is implemented in Node.js.

The Conversation Layer is, in our perspective, the gap required for the Liquid Software approach working independently of the platform [START_REF] Montz | Joust: A platform for liquid software[END_REF][START_REF] Gallidabino | On the architecture of liquid software: Technology alternatives and design space[END_REF][START_REF] Mikkonen | Towards liquid web applications[END_REF], and in our model, it is the domain between the INNER and OUTER CUBES. The main challenge here is to change the data status, if required for any method, allowing for the content to be displayed correctly in the following device. Therefore, this layer is represented as RESTful.

The Data Layer can be modeled in two perspectives: a centralized model with a nodehost or a sharing environment without central-node based respectively on IP Multicasting and Peer-to-Peer principals.

The Physical Layer allows for fluidity over all types of connection. It uses the Ethernet header structure and encapsulate data over IP datagrams for sending and receiving.

SEMANTIC RULE-BASED DEVICE RECOMMENDATION FOR SERVICE-MIGRATION IN MULTIPLE DEVICE ENVIRONMENT

Semantic rule-based device recommendation for servicemigration in multiple device environment

A successful migration decision, whether it is done automatically or manually, requires to follow some criteria to know which target device is the most suitable for the service/application that will be migrated. Also, it has to capture the users preferences, timeline and other features related to security, reliability, compatibility of devices, constraints of the services, etc., in order to be able to suggest the right device. Although this issue has been widely covered from the cloud/server perspective as part of cloud resource management, efficient device recommendation is still a challenge from the user-side perspective. It is even more challenging as far as we consider the limited device computation performances and the lack of access to large semantic resources, such as Linked Open Data, for similarity calculation. To address this challenge, We enhance CUBE with a declarative module that relies on ontologies and semantic inference rules, discussed hereafter, to ensure device recommendation.

(i) OWL ontology core concepts: We conceptualize 4 main components: Device, Owner, Service, and Characteristic. Each of them contains specific sub-classes to handle service migration context diversity. We also define necessary properties to model the interactions and relationships between theses concepts. For example, the Owner class has two object properties with the device class: a device is ownedBy an owner, and the owner usesDevice. These two properties are different because a user can own several devices but only uses some of them at a time. Another property is: the user interactsWith the service. Furthermore, in order to define the relationship between the devices and their characteristics or the services with their requirement, we add two main properties. hasCharacteristics property: links between Device and Characteristic, while the requireCharacteristics property: links between Service and Characteristic. Figure 6.4 shows a screenshot of the concepts and properties on Protégé.

After designing the ontology classes and properties, we need to fill the instances with the users devices and context information. The optimal way to do this would be to get APIs do the job, as we should keep users intervention as minimal as possible to facilitate the process. For instance, Battery API can give us: the battery percentage of devices, whether it's charging or not, etc. Ontology-update-process starts either when the user manually triggers a migration request or when predefined callback methods are automatically triggered through specific events related to service or device life-cycle. Both methods can be used depending on the context and on the user preferences. However, APIs cannot get all the information needed; that is why we might need users to enter/complete them manually. Migration rules are usually a combination of other rules. For example R4 which requires R1, R2, and R3 is an example of migration rule expressing conditions to achieve a successful migration. R3: Device(?d) ∧ HasScreen(?d, ?c) ∧ W atchingService(?s) ∧ RequiresScreen(?s, ?c) → IsCompatiblewith(?d, ?s). R4: Device(?d1)∧Device(?d2)∧Service(?s)∧Alive(?d2, true)∧ InP roximity(?d1, ?d2)∧ IsCompatibleW ith(?d2, ?s) → M igrate(?s, ?d2).

These inference rules can be very flexible and they give us efficient semantic meanings to achieve relevant device recommendation for migration. They provide typical migration situation. More specific ones related to user context and situation for migration can be defined by the user in the same way.

Implementation and evaluation

The CUBE prototype is implemented as a hybrid application based on JavaScript, Node, JAVA, HTML, PHP, and Cordova. Were also considered SQL and NoSQL models 6.6. RELATED WORK to authentication and synchronization, which are deployed as a callback procedure for performance. Regarding the Internet connection, we manage a local sign up/log in, and allow synchronizing this authentication step when a connection is available. In addition, we get IMEI and MAC addresses of the device and associate them to the user login.

As a first feasibility tests we considered both light-coupling and tight-coupling scenarios for email and video session migration respectively. The email scenario was developed based on Gmail API [START_REF] Da Silva | Liquid mail -A client mail based on CUBE model[END_REF] and the video scenario on YouTube [START_REF] Da Silva | User-side service synchronization in multiple devices environment[END_REF]. Both scenario were successfully run while moving over multiple devices with different OS. A demo video is available for video session migration scenario (https://youtu.be/-TYPRXtC7Lw). In a more recent , the CUBE was extended to support migration of any stateless interaction and was tested for videoconference meeting migration [START_REF] Da Silva | Beyond traditional web technologies for locally webservices migration[END_REF].

The semantic rule-based device recommendation extension is implemented within an API outside the CUBE framework. The ontology is designed using Protégé and the SWRL rule-based reasoning is performed through Apache Jena. The API manages and stores the facts and rules (both defined in Apache Jena) to finally compute the recommendation results. Facts are very dynamic and change depending on the situation and the devices. They are stored in a ".n3" file. Some characteristics are automatically added by the app from device APIs (Battery, Connectivity, etc.) while others are filled in manually by the user. A set of basic common rules is provided by the app for each device. It can then be enriched by the user to handle specific migration scenarios. Evaluation of CUBE implementations was performed with the focus on time and data saving as well as user satisfaction and quality of experience. Selected users were provided a set of devices and asked to reproduce predefined interaction scenarios. Results are detailed in [START_REF] Da Silva | Liquid mail -A client mail based on CUBE model[END_REF], [START_REF] Da Silva | User-side service synchronization in multiple devices environment[END_REF], and [START_REF] Da Silva | Beyond traditional web technologies for locally webservices migration[END_REF]. They show interesting achievements regarding time and data saving as well as high satisfactory user quality of experience.

The semantic rule-based device recommendation API was also run over migration scenarios to measure the accuracy of the approach towards recommending devices that allow successful service running after migration. The results, detailed in [START_REF] Nouicer | Semantic rule-based device recommendation for service migration in multiple device contexts[END_REF] show also high accuracy as well as high user satisfaction.

Related work

Service interaction synchronization is widely covered by companies such as Apple for cloud services running iOS and Google for Google Docs and other services running on Android. In addition, other approaches have also been proposed in literature for crossdevice service synchronization such as [START_REF] Narayana | Extending android application programming framework for seamless cloud integration[END_REF] and [START_REF] Wolters | Cross-device integration of android apps[END_REF] for services running on Android devices. As discussed in the Introduction, these solutions do not allow for fluent service 6.7. CONCLUSION migration as each device has to connect aside to get synchronized service interaction. In the same category of server-side synchronization, [START_REF] Gallidabino | On the architecture of liquid software: Technology alternatives and design space[END_REF] propose the most advanced approach that realizes Liquid Software principals, called LiquidJS. More than service synchronization, LiquidJS allows for service migration over devices but again it handles the migration relying on a server through an API or a browser. The approach also does not meet multi-platform migration. A detailed discussion including a comparative study of the the best known proposed approaches is given in [START_REF] Da Silva | The CUBE: A User-Centric system-model architecture for Web service migration through multiple devices[END_REF] and [START_REF] Da Silva | User-side service synchronization in multiple devices environment[END_REF]. From user-side, to the best of our knowledge, the CUBE is the only approach that allows service migration in both multiple device and multiple OS.

As for semantic device recommendation, approaches exist form server perspective under the topic of cloud resource management and allocation. Among them we can cite the mOSAIC ontology [START_REF] Moscato | An analysis of mosaic ontology for cloud resources annotation[END_REF] for cloud resources annotation and management intended to ease multi-cloud oriented applications development and [START_REF] Ma | Ontology-based resource management for cloud computing[END_REF] which deals with job allocation in cloud systems using OWL ontology and SWRL rules. Both approaches use large ontologies defined to cover as much as possible the concepts related to cloud systems. In our work, we rather focus on a small ontology with few semantic rules that can be run by devices locally without need for high computing resources.

Conclusion

Despite all efforts, there is still a gap before achieving both a multi-device and services synchronization over multi-OS from user-side, described herein. In order to address this challenge, we have presented our CUBE Model under the principles of Liquid Software. Throughout a user-centric approach and combining principles of REST and RESTful models, our proposition, allows to move user-service interactions over multiple devices with heterogeneous environments. The CUBE realization applies the best practices of different technologies fulfilling their principals and constraints regarding the issues of security, stateless interactions and providing a uniform interface shared by all resources, across separated layers for the REST and RESTful applications. Evaluation over typical user-service interaction scenarios show satisfying results in terms of performances and quality of experience.

We also proposed a semantic rule based complementary module for recommending the most suitable device to migrate to. The module is also implemented and evaluated showing high recommendation accuracy.

The work described in this chapter was conducted during the PhD of Clay Palmeira da Silva defended on September 2019 [START_REF] Da Silva | The CUBE: A User-Centric system-model architecture for Web service migration through multiple devices[END_REF] and during the Master 2 Internship of Dimeth Nouicer defended on December 2020. It is published in the following conference papers [START_REF] Da Silva | Diamond -A cube model proposal based on a centric architecture approach to enhance liquid software model approaches[END_REF], [START_REF] Da Silva | CUBE system: A REST and restful based platform for liquid software approaches[END_REF], [START_REF] Da Silva | Liquid mail -A client mail based on CUBE model[END_REF], [START_REF] Da Silva | User-side service synchronization in multiple devices environment[END_REF], [START_REF] Nouicer | Semantic rule-based device recommendation for service migration in multiple device contexts[END_REF], and [START_REF] Da Silva | Beyond traditional web technologies for locally webservices migration[END_REF].

Chapter 7

Handling dynamic service evolution with LOD and ML This chapter details our first contribution, summarized in Section 2.2.3.1, towards handling dynamic evolution of service interactions discussed in Section 2.1.3.1. The proposed approach relies on a graph representation modeling a multi-relation network of services and Linked Open Data annotation and similarity measure introduced in Chapter 4 to propose a three-phase process for service continuous deployment and changes handling. Bootstraping phase for service annotation and matchmaking, Update phase for service network updating from interaction feedbacks, and Learning phase for LOD interlinks updating.

Introduction

Recent breakthroughs in service oriented computing have encouraged companies and organizations to export their functionalities as Web services to gain in visibility and market opportunities. Web services do not operate in silos; they usually interact through several 7.1. INTRODUCTION relationships such as Composition and Substitution. In dynamic environments, new Web services are continuously deployed. Moreover, existing Web services are updated regularly. Such updates are most of time associated with modifications to service description expressed in natural language. These updates affect operation results, and hence may lead to breach of contract between service providers and clients [START_REF] Fokaefs | An empirical study on web service evolution[END_REF]. Therefore, it is mandatory to handle Web service changes that occur at run-time and accurately communicate these changes to the concerned peers in the network. Handling Web service continuous deployment and updates offers several advantages: First, it avoids brutal contract violation between providers and customers. Second, it speeds-up the exposure of new functionalities in the network, helps them gain more visibility, and hence improves the overall availability of new services. Third, it helps setting new partnerships among Web services.

However, managing the evolution of Web services is challenging for the following reasons. When deployed or updated, Web service capabilities are described by means of keywords in natural language. What is needed is a semantic approach to match service capabilities by matching their describing keywords. Moreover, Web service provided description may not match with service real capabilities. What is also needed is a technique to update service relationships according to service interaction experience and user feedbacks. This rises the following research questions respectively: (1) How to bootstrap relationships for newly deployed/updated services and figure out the most suited relationship type to link two services ? (2) How to update service relationships and ascertain whether two Web services are interoperable in practice ? (3) And finally, How to take advantage of service interaction experience to help learning new links in LOD and in turn improve relationships recommendation accuracy with the newly learned links ?

In this chapter, we describe our approach based on Linked Open Data (LOD) and Machine Learning (ML) for handling Web services deployment and evolution. Service interactions are modeled as a social network of service through a multi-relation graph where nodes correspond to services and edges to interaction relationships. The approach follows a three-step process: LOD based service annotation and matchmaking, ML-based service network update using interaction feedbacks, and LOD links updates using service network relationships. These phases rely on efficient algorithms. The overall approach is implemented and evaluated on service interactions from ProgramableWeb between 2007 and 2017.

The remainder of this chapter is organized as follows. Section 7.2 provides an overview of the proposed approach and a general architecture highlighting the main components. Section 7.3 presents bootstrapping relationships for newly deployed and updated services. Section 7.4 introduces our technique to update relationships according to service interaction with each other and with user. Section 7.5 describes our technique to learn relationships in 7.2. APPROACH ARCHITECTURE AND OVERVIEW LOD according to service interactions and feedbacks. Section 7.6 discusses the experimental study. Section 4.6 reviews related works. Finally Section 7.8 concludes the chapter.

Approach architecture and overview

The overall architecture of the proposed approach is depicted in Figure 7.1. The approach runs a three-phase process to handle Web service deployment and evolution. The process is triggered when a service provider deploys the interface of his service, and provides a natural language description of service functionality and application domain. First, Bootstrapping Phase invokes the LOD-based Annotation module to associate a profile to the service: a set of keywords describing service inputs, outputs, functionality, and application domain. The keywords are annotated with LOD resources. After that, Bootstrapping Phase invokes LOD-based matchmaking module to match annotated service profiles and derive composition, substitution, and subscription relationships. This results in new weighted edges for newly deployed service and allows bootstrapping service relationships. This same process will also be run when a Web service undergoes an update. Annotation module will annotate service new features in interface and description with LOD resources. Matchmaking module will match service new features with existing network features. Second, Updating Phase updates service relationships according to service interactions with each other and with users. As services record successful interactions, they receive high rating scores, this increases the weight of their relationships. In the same way, weights are decreased for negative feedbacks. Third, Learning phase improves bootstrapping relationships accuracy by learning new relationships in LOD. When the Updating phase returns a higher weight than the Boostraping phase weight for the same relationship, this would mean new relationships should be added to LOD and viceversa. These phases will be formalized and detailed in the following sections. The formalization relies on multi-relation graph representation to model service network introduced in [START_REF] Labbaci | Follow the leader: A social network approach for service communities[END_REF]. Formally, a multi-relation network of Web services is a directed graph G = (V, R) where V is a set of services, and

R = k=3 k=1 R k is a set of edges, where R k = {(S u , S v ) ∈ V ×V } is the set
of edges of the k-th relationship. Major services interaction relationships are: substitution (R 1 ), composition (R 2 ), and subscription (R 3 ). An edge (S i , S j ) ∈ R 1 indicates that there is a relationship of type substitution between Web services S i and S j , precisely it indicates that S j is a substitute of S i and clients can substitute the invocation of S i by S j if S i is unavailable. Similarly, a composition edge (S i , S j ) ∈ R 2 indicates that S j can be composed with S i and clients can invoke S j and S i in the same composite application. A subscription edge (S i , S j ) ∈ R 3 indicates that S i can subscribe to the news feed of a collaborator/competitor S j to stay aware about its latest updates.

Bootstrapping Phase

LOD-based service annotation and matchmaking. This step relies on the contribution detailed in Chapter 4. It applies LOD-based annotation process on service features and uses LODS measure within the service matchmaking. Here, service profile is formally modeled as a pair (F, D) where F is a description in natural language of the service functionality and D is a list of keywords that describe the service application domain. Text in F is pre-processed to keep meaningful keywords describing service functionality. The LOD-based annotation maps these keywords to LOD resources. Then we apply service matchmaking. to infer potential composition and substitution relationships. Semantic matching is invoked in two cases: (a) When a Web service joins the network. (b) When a Web service gets updated. It matches Web service capabilities (either the initial or the updated ones) to recommend the most appropriate relationship to link with two services. It also predicts the probability value to interact through the recommended relationship.

Given two service features f eat u , f eat v described each with a set of keywords K u = {k u1 , k u2 . . . k ui } and K v = {k v1 , k v2 . . . k vj } respectively, where each keyword can be attached to a subset of annotation resources A R ∈ LOD, such that:

∀k i , k j ∈ K u × K v , ∃ r i , r j ∈ A u |⟨k i , r i ⟩ × A v |⟨k j , r j ⟩.
The similarity between features f eat u 7.3. BOOTSTRAPPING PHASE and f eat v , annotated by a set of LOD resources A u and A v respectively is computed in the same way as in Equation 4.17:

Sim LOD (f eat u , f eat v ) = a∈Au b∈Av LODS ℓ,ℓ ′ (a, b) |A u | • |A v | (7.1)
Bootstrapping Composition Relationship This phase assumes that two Web services S u and S v are composable and can be linked by a composition edge in the network if and only if: (i) S u and S v appear together in at least one mashup, and (ii) the similarity values between S u and S v functional descriptions and application domains are higher than the following thresholds α F and α D respectively.

Algorithm 1 evaluates how likely are two services S u and S v to be part of the same composition. The algorithm computes [START_REF] Abbasimehr | Improving time series forecasting using LSTM and attention models[END_REF] the similarity between their functional descriptions. And (2) the similarity between their application domains. If computed similarities are above given thresholds, then the algorithm computes a composability likelihood Comp between Web services S u and S v . If the composition relationship (S u , S v ) exists, the algorithm updates the composition likelihood as an average of the computed composition probability and the relationship current weight. Finally the algorithm adds a new composition edge (S u , S v ) to the network of services with the composition likelihood as weight.

Algorithm 1 Composition Matching Algorithm

Input: G(V, R) : Graph of services. S u , S v ∈ V .
α F , α D : similarity thresholds for functional descriptions and application domains Coef F , Coef D : coefficient values for similarities between functional descriptions, and application domains respectively.

Output: G(V, R) : Updated graph of services. Begin

1: Sim F ← Sim LOD (S u .F, S v .F ); 2: Sim D ← Sim LOD (S u .A, S v .A); 3: if (Sim F >= α F and Sim D >= α D ) then 4: Comp(S u , S v ) ← (Coef F * Sim F + Coef D * Sim D )/(Coef F + Coef D ); 5: if ((S u , S v ) ∈ R 1 ) then 6: Comp(S u , S v ) ← AV G(Comp(S u , S v ), W eight(S u , S v )) 7:
end if

8: R 1 ← R 1 ∪ (S u , S v , "W eight"=Comp(S u , S v )) 9: end if =0 7.4. UPDATING PHASE
Bootstrapping Substitution Relationship This phase assumes that two Web services S u and S v are candidates for substitution and can be linked through a substitution edge in the network if and only if: (i) they do not appear together as parts of the same mashup, and (ii) the similarities between S u and S u functional descriptions and application domains are higher than given thresholds α F and α D respectively. Substitution Algorithm differs from Algorithm 1 in that it uses specific threshold and coefficient values. For instance, functional description similarity threshold should be higher for substitution than it is for composition.

The current phase allows bootstrapping relationships for, newly deployed services and those undergoing updates, based on LOD similarity measure. However, relying only on service profile data may lead to inconsistencies between service real capabilities and described ones in profiles. The next section proposes to continuously update service relationships according to user feedbacks.

Updating Phase

Although semantic matching of service profiles allows building relevant business relationships, it relies however entirely on Web service profile data. Such an approach considers Web services as isolated components and underlooks their interactive behaviour. In reality, Web services interact through various relationships such as composition, substitution, and subscription. Bootstrapping Phase may suggest that two services are composable while they struggle to interoperate in practice. Their record of successful interactions may be weak. Users will then give bad rating scores. The reason may be QoS limitations of some services that make them incapable to interoperate with network services. This may also be due to an incoherent service description with service real capabilities that led to biased semantic matching results. Gathering and analyzing Web service interactions and their user feedbacks allow assessing the real value/relevance of bootstrapped relationships. The intuition is to update relationships weight values returned by semantic layer according to user rating scores. A relationship (S u , S v ) that keeps a high weight value after many service interactions means that S u and S v have collected a strong record of successful interactions. These interactions have been appreciated by users and consequently have been well rated. On the opposite, if a relationship will see its weight decreasing as services interact, this would mean that services struggle to interoperate with each other. The relation did not get high rating scores and so even after semantic matchmaking returned a high weight value. This section catches Web service interactions and their user ratings and updates relation weight values accordingly. This allows keeping the network updated and eases identifying interoperable services and computing service reputation scores.

LEARNING PHASE

We extend the measure proposed in [START_REF] Labbaci | A deep learning approach for web service interactions[END_REF] to leverage user comments for updating relationship weights as follows: The updated weight depends on the previous weight (i.e., bootstrapped weight) and on user feedbacks on the relationship. The higher will be positive user feedbacks on the relationship, the higher will get the updated weight. The weight will decrease on the contrary case.

W E t+δt (S u , S v ) ← AV G |positiveF eedbacks(S u , S v ) t+δt | |allF eedbacks(S u , S v ) t+δt | , W E t (S u , S v ) (7.

Learning Phase

This phase consists in proposing new links in LOD according to Web service interaction experience. Keeping LOD up to date allows running accurate semantic matching of Web service capabilities, hence accurately identifying potential business relationships among Web services. Updating LOD is triggered when the gap between the updated weight value and the bootstrapped weight value gets above a given threshold for the same relationship. If the updated weight is greater than the bootstrapped one, this means that Web services are interoperable (i.e., have a strong record of interactions) in practice, while bootstrapping phase has not recommended them as such. This proves the lack of information in LOD. Thus, new relationships among resources describing these interoperable Web services should be added to LOD. On the opposite, if the updated weight is the lowest, this means that Web services struggle to interact. The cause can be either (i) Web service description is inadequate with service real capabilities, or (ii) Web service suffer from QoS limitations. For the first case, LOD relationships among resources describing such services should be destroyed. For the second case, LOD ontology structure will be preserved.

Algorithm 2 details how to learn new LOD relationships or to break existing ones. It derives (LearnLOD) and breaks (BreakLOD) links among resources describing services according to a "Normal probability distribution". Such probability distribution is the most adequate to model phenomenon that consider the sum of many independent variables. In 7.6. EXPERIMENTAL STUDY our case, LOD similarity measure of two service features is computed as the summation of atomic similarities of their LOD resources. By analogy, we learn or destroy new LOD relationships according to a "Normal probability distribution". As it is hard to overwrite existing LOD, we save new learned and broken relationships in local database. Such learning will serve further bootstrapping relationships that relies mainly on semantic matching of service features. Hence, future relationship bootstrapping will be more accurate. This allows a fast exploitation of new functionalities in the network and enhances their overall availability.

Algorithm 2 Learning New Relationships in LOD

Input: G(V, R) t : Graph of services observed at t. G(V, R) t+δt : Graph of services observed at t + δt. S u , S v ∈ V , gap: Learning gap.

Output: Updated LOD Begin weightdif f ← weight(S u , S v ) t+δt -weight(S u , S v ) t ; 1: if (weightdif f -gap >0 ) then 2:
LearnLOD(S u .F, S v .F )

3:

LearnLOD(S u .A, S v .A)

4: else if (weightdif f -gap ≤ 0 ) then 5:
BreakLOD(S u .F, S v .F )

6:

BreakLOD(S u .A, S v .A)

7: end if =0

Experimental Study

We evaluate the proposed approach on a dataset 600 mashups of APIs and their attributes from ProgrammableWeb 1 . We used DBPediaSpotlight 2 for annotating Web service descriptions and categories. We study Web service evolution over several time periods [T i , T j ] where T i ≥ 2007, T j ≤ 2017, [T j -T j ] = 2 years. We first identify newly deployed services and those undergoing updates at T i , after which we run our relationships recommendation. Then we observe each recommended relationship [S u , S v ] interaction history during the time interval [T i , T j]. Each mashup containing (S u , S v ) that is deployed within [T i , T j] means a successful composition interaction feedback on the relation (S u , S v ). On the opposite, if no mashup containing S u and S v ) is deployed within [T i , T j], this is interpreted as a negative interaction feedback. Weight(S u , S v ) is updated according to col-7.7. RELATED WORK lected interaction feedbacks with the use of Google Sentiment Analysis API3 . We simulate interactions for substitution relationships. Precision, shown in Figure 7.2(b), checks the accuracy with which relationship are recommended for newly deployed and updated services. It compares the recommended relationship weights at T i with real relationship weight at T j . If the weight difference is less than a threshold value (0.2 in our case), the relationship is assumed to be precisely recommended. Our approach recommends relationships with up to 65% precision. The justification is that weight varies depending on service interaction feedbacks. As such, it gets challenging to predict with high accuracy future relationships weights.

Related Work

Our work is at the cross-road of three main research fields, namely the Web services social computing, the Web services functionalities evolution management, and linked open data semantic web. The new trend of the research community in service-computing is to exploit social technologies for a better discovery mechanism of services. In this trend, works in [START_REF] Maamar | Towards a method for engineering social web services[END_REF], [START_REF] Louati | Towards agent-based and trust-oriented service discovery approach in social networks[END_REF], [START_REF] Labbaci | Learning interactions from web service logs[END_REF] propose to build a network of Web services with the purpose of addressing issues like Web services discovery. Although these approaches handled social interactions of Web services, few efforts have been devoted however to manage Web service evolution that occurs and may affect Web service interaction. Works in [START_REF] Gao | Service recommendation from the evolution of composition patterns[END_REF], [START_REF] Zarras | Keep calm and wait for the spike! insights on the evolution of amazon services[END_REF], and [START_REF] Wang | Service evolution patterns[END_REF] aimed to address Web service functionality evolution. [START_REF] Zarras | Keep calm and wait for the spike! insights on the evolution of amazon services[END_REF] studied the evolution of Amazon Web services to support developers in their tasks of Web service selection and maintenance. [START_REF] Gao | Service recommendation from the evolution of composition patterns[END_REF] proposed an approach for managing services evolution by analyzing the co-occurences of their topics. A topic evolution graph is built according to the analysis of composition patterns in mashups. Resulting graph is used to recommend services for composition. [START_REF] Wang | Service evolution patterns[END_REF] proposed a service evolution model to identify the changes that a Web service is subject to. They classified them into two major categories: Changes that concern Web service Operations and changes that concern Web Service DataTypes.

In our work, we enrich service profiles with LOD-based annotation process which improves service matchmaking accuracy and consequently relationship recommendation accuracy. We also take advantage from user feedbacks to evaluate recommended relationships and reorganize LOD relationships.

Web services evolution has been also at the center of interest of related fields such as IoT and service-based business processes. [START_REF] Tran | Decom: A framework to support evolution of iot services[END_REF] proposed a framework to automatically capture and communicate services changes in IoT environment. The framework manages syntactic and semantic changes in IoT services capabilities described as RESTful services. In contrast to our work, ontologies have been used to add semantics to services definitions. Ontologies are generally domain-specific which limits management of services functional evolution. We rely instead on LOD that offers more resources to semantically annotated and matchmake services.

Conclusion

In this chapter, we proposed a LOD approach for managing service deployment and evolution. The proposed approach runs a three phase process. First phase recommends new relationships by matching service capabilities based on LOD. Second phase updates service relationships according to their interaction with each other and with users. Third phase increases recommendation accuracy by learning new relationships in LOD. Managing Web service evolution offers several advantages such as setting long-lasting relationships between service providers and users, and increasing the visibility of newly added functionalities. Experiments conducted on real data returned promising results.

The work described in this chapter was conducted during the scientific stay of Hamza Labbaci in the University of Tours 2018 and 2019 as part of his Phd defended in 2020 [START_REF] Labbaci | A Social Approach for Web Service Discovery and Community Detection[END_REF]. It is published in [START_REF] Labbaci | A linked open data approach for web service evolution[END_REF]. This chapter details our contribution, summarized in Section 2.2.3.2, towards the challenge of handling trustworthy service interactions in dynamic contexts, discussed in Section 2.1.3.2. We present the proposed threefold declarative approach for blockchain-based choreography executions which includes: (i) a transformation model for mashups into smartcontract choreographies executions, (ii) a flexible transactional business process model for smart-contract business process executions, and (iii) a change propagation model to handle dynamic evolution of business process choreographies.

INTRODUCTION

Introduction

Service-based business processes rely on Web services to implement their tasks. Business processes are designed to achieve business goal which usually involves the collaboration of many entities in decentralized environments. In such open environments, collaborating entities are also competing for their own business success which leads to untrusted behavior. This is the case for business process choreographies which are suitable for open collaboration as entities collaborate directly without intermediaries. They however still need to rely on well-defined collaboration rules and policies to trust each other. These issues have been widely addressed by state-of-the art approaches that usually rely on formal and transactional models to define collaboration rules and on formal verification to ensure execution soundness [START_REF] Van Der Aalst | Choreography conformance checking: An approach based on BPEL and petri nets[END_REF][START_REF] Bhiri | Ensuring customised transactional reliability of composite services[END_REF][START_REF] Hamel | Verifying composite service transactional behavior with EVENT-B[END_REF]. These approaches fail, however, to dispense with the need for independent third party to guarantee compliance with trust policies between engaged entities.

The emergence of Blockchain technologies for decentralized and transactional data sharing across a network of untrusted participants brought the right solution that fits well with the requirements of business process choreographies executions. It didn't take long for the Blockchain technologies to be adopted as infrastructure that handles trustful interactions between business entities without any need of any central authority [START_REF] Hull | Towards a shared ledger business collaboration language based on data-aware processes[END_REF][START_REF] Weber | Untrusted business process monitoring and execution using blockchain[END_REF][START_REF] Mendling | Blockchains for business process management -challenges and opportunities[END_REF][START_REF] Falazi | Blockchain-based collaborative development of application deployment models[END_REF][START_REF] Brahem | Blockchain's fame reaches the execution of personalized touristic itineraries[END_REF]. These approaches mostly rely on second generation blockchains which allow for complex task running through programs called Smart Contracts that enforce the terms of agreement between the untrusted parties. The proposed approaches focus on execution control flow of business processes while leaving transactional flow to the basic blockchain specification that follows standard ACID model which fails to capture advanced reliability requirements of complex business process executions. There is therefore need to define suitable models to handle the transactional flow of blockchain-based process executions.

Collaborating business entities evolve, on the other hand, in highly dynamic environments that appeal for continuous updates and improvements of their internal processes to keep high competition level. These dynamic changes may affect the collaborations in which the enterprise takes part. Changes may also directly concern the global collaboration due to new external business policies that should be taken into account. In both cases, changes must be notified and propagated to the involved partners. Change propagation in process choreographies has also been tackled prior to blockchain-based approaches [START_REF] Fdhila | Dealing with change in process choreographies: Design and implementation of propagation algorithms[END_REF]. In the blockchain-based ones, however, it is still challenging because of the non-mutable nature of shared data. There is therefore need to bring additional levels to cope with the change propagation within blockchain based choreographies execution frameworks.

In this Chapter, we will address the above listed challenges and propose a solution for first trustworthy execution of business process choreographies in Section 8.3. Then, in 8.2. BACKGROUND Section 8.4, we will extend the proposed approach with transactional mechanisms in order to bring reliability to the blockchain-based business process choreographies. Finally, in Section 8.5, we will render these choreographies adaptive to dynamic changes via proposing the needed change propagation mechanisms. We demonstrate the feasibility of the approach via implemented prototypes and evaluate it through a set of experiments. We use scenarios from the tourism domain with itineraries generated by the CART prototype described in Chapter 5.

Background

Business Process Choreographies

Business process management (BPM) includes methods, techniques, and tools to support the design, enactment, management, and analysis of operational business processes [START_REF] Hofstede | Business process management: A survey[END_REF]. BPM is ensured and automated by Business process management systems (BPMSs) especially at the intra-organizational level. This first case, mostly known as orchestration, faces several issues including central node congestion, additional fees, etc. The second case, known as choreography, is more suitable for open collaboration as entities collaborate directly without intermediaries. Choreographies are a distributed way for the composition and control of business processes in an inter-organizational level where the control is not enacted by one single entity and where many parties, that generally do not know neither trust each other, conduct each a certain piece of work and maintain an internal state. The global state of the choreography is obtained through the interactions and message exchanges between the different involved parties.

Transactional Business Processes

Transactional business processes present an evolution of "traditional" business processes to support large flow-based applications with complex control structure. [START_REF] Schuldt | Atomicity and isolation for transactional processes[END_REF][START_REF] Bhiri | Ensuring customised transactional reliability of composite services[END_REF]. The transactional approach initially emerged in the context of database management systems with ACID models. Transactional models permit to relax atomicity property to define instead the "failure atomicity" or partial failure of a process activity. In addition, they relax isolation property to allow high inter-process concurrency handling and compensation as backward recovery.

Blockchain and Smart contracts

A blockchain [START_REF] Underwood | Blockchain beyond Bitcoin[END_REF] is a distributed ledger where data is organized in sequence of blocks, the containers of transactions. The blockchain network is maintained by independent com-puters referred to as nodes or peers that do not know or trust each other but can connect and cooperate to validate transactions executed on the blockchain. After validation, peers record, share and synchronize transactions in their respective electronic ledgers. The first generation of blockchain allows only sending and receiving monetary values (e.g., Bitcoin). In the second generation, known as the Smart contracts blockchain (S.C. for short), meanwhile, a transaction allows more complex operations such as the creation of a S.C. and stores the results of function calls in S.C.. A S.C. can be defined as a program enforcing the terms of the agreement between untrusted parties about a valid care sale or a loan assessment or voting or health care tracking, etc. One could consider a contract as a class in object oriented concepts and each deployment of the contract could be considered as an instance of the object. A contract may be deployed to a network multiple times, and each instance would have a distinct address, a secure identifier used to interact with the smart contract.

Mashup to smart contract transformation model

The starting point of this work is to go a step further configuring service mashups in the tourism context discussed in Chapter 5 to propose a way for personalized trip realization. The deployment and execution of touristic itineraries usually involve many independent entities (tourist, museum, restaurants, hotels, transport, etc.) that cooperate and compete in untrusted distributed context. In order to ensure trust within cooperation and guarantee a successful execution of touristic itinerary, we propose a two-steps transformation model: (a) from data mashup itinerary to process choreography (BPMN) and then (b) from BPMN to smart contract. The CART trip planning outputs itineraries following an XML Schema Model with a root element containing a sequence of steps with or without PoIs and with or without payment. It also contains user constraints such as total duration and maximal budget. PoIs may also have additional attributes. Figure 8.1 shows the detailed structure of the itinerary generic model. The main transformation rules are given in Table 8.1. We first apply a set of transformation rules which associate: a choreography model for each itinerary instance (rule (a)). Within the choreography model we generate a participant pool for every PoI and for the user (rule (b)) as well as a choreography task for each step of the itinerary (rule (c)). Steps without PoI correspond to private tasks (rule (d)). Additional user constraints and PoI attributes are embedded in the model documentation and in the PoI process documentation respectively (rules (e) and (f)). The resulting choreography BPMN file is in turn used to generate corresponding Smart contracts in Solidity code using the second part of the transformation rules in Table 8.1. Only interaction activities are captured and included in the produced Smart contract which encodes only the public view (rule (a)). Each interaction activity, i.e., choreography task, consists of a send task, receive task and the corresponding message flows. This is encoded as two functions in the Smart contract (rule (c)). We consider Hyperledger Fabric which is a permissioned blockchain where only authorized organizations has the access to the network. In our case, authorized organizations are participant pools in the choreography model (rule (b)). Private tasks are left to participant private process and are therefore not included in the Smart contract (rule (d)). Additional constraints and attributes are encoded as global variables (rule (e)) and callbacks (rule (f)).

In the following, we give a scenario of application of the aforementioned approach. Listing 8.1 presents an excerpt of the XML instance corresponding to the scenario of a tourist, Alice, who wants to visit some attraction in Tours and have dinner in a French The transformation model is implemented on top of the Caterpillar tool [START_REF] López-Pintado | Caterpillar: A business process execution engine on the ethereum blockchain[END_REF]. The reader can find the detailed description of the approach in [START_REF] Brahem | Blockchain's fame reaches the execution of personalized touristic itineraries[END_REF].

Extending Smart contracts with transactional business process model

The generated interaction smart contract implements the business logic of interaction activities in the process choreography, that is the control flow. The transactional semantics of a smart contract follow ACID models and are therefore limited to support transactional requirements of business process executions [START_REF] Bhiri | Ensuring customised transactional reliability of composite services[END_REF]. In order to ensure execution reliability of the generated smart contracts we extend them with the Transactional Business Processes models [START_REF] Bhiri | Ensuring customised transactional reliability of composite services[END_REF][START_REF] Hadad | Tqos: Transactional and qos-aware selection algorithm for automatic web service composition[END_REF] which define the transactional flow on top of the control flow of the interaction activities. Precisely, the transactional flow follows the Flexible Transactional Model principles [START_REF] Schuldt | Atomicity and isolation for transactional processes[END_REF]. The Flexible Transactional Model define transactional properties of activities: pivot, compensatable, and retriable and the transactional mechanisms which include alternatives as forward recovery and compensation as backward recovery. Therefore, we first assign one or many transactional properties to each of input process model activities. Then, we enrich the life-cycle of a process activity, enabled → started → completed with four other possible termination states which are aborted, cancelled, failed and compensated which we call transactional termination states.

In this contribution we extend the transformation model introduced in the previous 8.4. EXTENDING SMART CONTRACTS WITH TRANSACTIONAL BUSINESS PROCESS MODEL section and generate both the control flow and the transactional flow as well as failure handling mechanisms. For each business process activity we also generate functions and variables in the smart contract as a transactional flow. Generated functions include life-cycle activities (ActivityName_start(), ActivityName(), ActivityName_complete(), and Activi-tyName_fail()) and transition activities (abort(), cancel(), complete(), fail(), and retry()) which allow the activity to move from one state to another. Variables include state vector StateVector_ActivityName to capture the activity state evolution for each activity.

Following a task failure and depending on the activity's transactional properties, the Solidity code generation templates produce the code of the corresponding functions. In Listing 8.3, we present an excerpt of the BPMN-to-Solidity template corresponding to the code generated in case of a pivot activity failure. The proposed approach is implemented on top of the Caterpillar tool [START_REF] López-Pintado | Caterpillar: A business process execution engine on the ethereum blockchain[END_REF]. Further details of the proposed approach can be found in [START_REF] Brahem | Running transactional business processes with blockchain's smart contracts[END_REF]. Collaborating business entities evolve in highly dynamic environments that appeal for continuous updates and improvements of their internal processes to keep high competition level. These dynamic changes may affect the collaborations in which the enterprise takes part. Changes may also directly concern the global collaboration due to new external business policies that should be taken into account. In both cases, changes must be notified and propagated to the involved partners. Thus, business process management systems should manage change propagation in a trustworthy fashion. Although change propagation in process choreographies has been tackled in general [START_REF] Fdhila | Dealing with change in process choreographies: Design and implementation of propagation algorithms[END_REF], it is however still challenging for blockchain-based choreographies because of the non-mutable nature of shared data.

In running choreography instances, a change may consist of a simple operation, AD-D/REMOVE/UPDATE activity, or a combination of operations. Handling such changes requires the underlying choreography model to be flexible. We therefore consider declarative choreographies modeled through Dynamic-Condition-Response (DCR) graphs [START_REF] Mukkamala | A formal model for declarative workflows: dynamic condition response graphs[END_REF][START_REF] Mukkamala | Towards trustworthy adaptive case management with dynamic condition response graphs[END_REF]. With a DCR graph G = (E, M, Rel), processes are modelled as a set of events E, corresponding to the activities in BPMN, linked together with relations Rel modeling linking constraints. Relations are of five types (condition, response, milestone, include, and exclude) [START_REF] Hildebrandt | Declarative choreographies and liveness[END_REF]. The graph runtime state is captured by a marking matrix M of the events through a triplet of binary values corresponding to (currently included, currently pending, previously executed ). In [START_REF] Henry | Trustworthy cross-organizational collaborations with hybrid on/off-chain declarative choreographies[END_REF], authors propose an approach for trustworthy execution of DCR choreographies. We briefly describe here our contribution which builds on and extends this work with the change management mechanism.

In [START_REF] Henry | Trustworthy cross-organizational collaborations with hybrid on/off-chain declarative choreographies[END_REF] a DCR choreography is defined as C(G, I, R) where G is a DCR graph, I is a set of interactions and R is a set of roles. An interaction i is a triple (e, r, r ′ ) in which the event e is initiated by the role r and received by the roles r ′ ⊂ R \ {r}. Each partner has a projection of the DCR choreography, called public DCR process, in addition to its private DCR process which refines the public process with local events of the partner. The shared events and interactions are managed through the choreography smart contract on the Blockchain.

We propose to extend this approach with change management through the choreography smart contract. We define the change element G Ref as a refinement of C which occurs on private DCR process and should be propagated to the public DCR process whenever the change impacts common interactions with other partners. G Ref can be either an atomic p3) is an internal event of the role Tourist, managed off-chain to preserve the privacy of Tourist. PurchasePass (e1) is a choreography interaction sent by Tourist and received by TouristOfficer. It is managed on-chain (c.f. [START_REF] Henry | Trustworthy cross-organizational collaborations with hybrid on/off-chain declarative choreographies[END_REF]). To execute the send event, Tourist triggers the SC from its private DCR process. Table 8.2 shows the choreography markings of Figure 8.3 during a run. Each column stands for the events of the choreography. Rows indicate markings changes as events on the left are triggered. For example, initially no event is executed nor pending and the event e1 is included. Thus, its marking is (1,0,0). Once Tourist executes e1, the marking becomes (1,0,1). Partners have control over the set of internal and choreography interactions they are involved in. This set of events, hereafter referred to as a partner private DCR process, is illustrated by the tourist's one in Figure 8.3(b). Table 8.2: Evolution of the markings (included, pending, executed) of the DCR choreography process in Figure 8.3 (before changes)

Markings e1 e2 e3 e4 (init) (1,0,0) (0,0,0) (0,0,0) (0,0,0) e1 (1,0,1) (1,1,0) (0,0,0) (0,0,0) e2 (1,0,1) (1,0,1) (1,1,0) (1,1,0)
Both choreography and private DCR processes in Here, the pass purchased by the Tourist in the event e1 undergoes a change: it will let the Tourist to have a dinner in NewRestaurant instead of having it in the Hotel. Hence, the TouristOfficer, who manages the pass and can add new participants, establishes a new convention with NewRestaurant. Consequently, the change operations to make are: (i) add the partner NewRestaurant, (ii) an UPDATE operation where the interaction e4 is replaced with the DCR fragment{e5,e6 }. PROCESS CHOREOGRAPHIES events emitted by the smart contract. Endorsing partners must send their decision request to the smart contract based on the Allowed /Denied changes rules. If the change once computed on the endorser's process respects all the rules, then the endorser approves the request. It is otherwise rejected. The smart contract collects all the decisions from the endorsers to lock (or not) the choreography instance and proceed (or not) with the change and update the change status to Approved or Declined. In case of approval the smart contract locks the instance for change propagation. As it manages the negotiation process, a tamper-proof record of the negotiation is accessible by all partners. This prevents conflicts and eases potential claim resolutions.

(iv) Change propagation. Change propagation after successful negotiation phase consists in (i) applying the change effect to the affected partners DCR public processes and (ii) propagating the change effect by each partner to its private DCR process. Algorithm 5 presents the function triggered by partners to confirm the projection to the smart contract. The smart contract receives all the local projection confirmations and notifies the change initiator (didP ropagate is filled with ones). The change initiator then retrieves the new DCR choreography that was saved into IPFS using h req and forwards it to the smart contract. The SC updates the relations and markings stored into the process instance and resets the change status of the workflow instance: a new change request can be processed.

RELATED WORK

update events and relations. The panel manager implements integrity rules presented in Table 8.3: the panel verifies the soundness of a desired change operation. Hence, we obtain a redesigned DCR graph that is correct-by-construction.

We evaluate the smart contract deployment cost as well as the transactions costs related to change negotiation and propagation operations. Table8.4 presents the gas usage induced by the execution of the SC during the negotiation and propagation stages. Regarding the negotiation phase, the transaction fees for placing the change request of an UPDATE operation are 0,00639582 ETH, and are the highest fees of the negotiation stage. Indeed, the fee to be paid to decline or accept a role is worth around 0.0015 ETH. Nonetheless, all fees are of the same order of magnitude (0.001 ETH). Regarding the propagation phase, many transactions fees have to be considered like for example the cost of sending notifications of the local update which is is worth 0,00201296 ETH and 0,0020115 ETH for both endorsers (around 5$ per local projection). We analyze the costs and find that propagation transaction fees are higher than the negotiation ones, given the fact that the propagation phase is longer and comprises many atomic transactions, mainly comprises the cost of the DCR choreography update. The reader can find further details of the proposed approach can be found in [START_REF] Brahem | A trustworthy decentralized change propagation mechanism for declarative choreographies[END_REF].

Related Work

Regarding the monitoring and execution of business process collaborations using the blockchain, authors in [START_REF] García-Bañuelos | Optimized execution of business processes on blockchain[END_REF][START_REF] Weber | Untrusted business process monitoring and execution using blockchain[END_REF], propose an approach translating a BPMN model to a minimized Petri-net and compiling the latter to a smart contract. A derived tool called Caterpillar implements this approach [START_REF] López-Pintado | Caterpillar: A business process execution engine on the ethereum blockchain[END_REF]. However, participant processes are modelled as lanes belonging to the same pool and not as process choreographies. In [START_REF] Prybila | Runtime verification for business processes utilizing the Bitcoin blockchain[END_REF], a runtime verification mechanism is developed on top of the Bitcoin blockchain to verify the correct execution of process choreography instances. In contrast, they make some assumptions. A 8.7. CONCLUSION particular participant called the process owner who initiates the business process execution hands over the control to a first suitable partner to have a specific process activity executed. Then, the selected partner passes the execution to another choreography participant to perform the next task and so on.

Transactional reliability has been tackled prior to blockchain-based approaches. Although they bring many opportunities to business process execution, transactional models have been applied to orchestration schemes only [START_REF] Bhiri | Ensuring customised transactional reliability of composite services[END_REF][START_REF] Hadad | Tqos: Transactional and qos-aware selection algorithm for automatic web service composition[END_REF]. They guarantee process execution reliability, that is, the process reaches its objectives and complete successfully or it properly undo all undesirable effects of partial execution. Such features can be used to add transactional reliability to smart contract related transactions, very close to ACID models. Looking to proposed approaches dealing with business process monitoring and execution using the blockchain technologies, they handle only the control flow execution of business processes without taking into consideration its transactional flow. Thus, they do not offer transactional reliability in case of task failures and subsequent behaviour of the business process in such cases.

Finally, in regards to approaches dealing with changes of business process collaborations when they evolve in dynamic environments, they have been also proposed prior to blockchain-based ones. In [START_REF] Fdhila | Dealing with change in process choreographies: Design and implementation of propagation algorithms[END_REF][START_REF] Indiono | Dynamic change propagation for process choreography instances[END_REF], authors propose change propagation algorithms across business process choreographies. However, authors do not propose any mechanism to ensure that all partners have trustfully applied the change, and no blockchain is used to deal with this problem. Change management has also been studied in DCR processes, but only in orchestrations schemes. In [START_REF] Mukkamala | Towards trustworthy adaptive case management with dynamic condition response graphs[END_REF], authors propose add/remove/update operations to DCR graphs relations and events. In [START_REF] Debois | Replication, refinement & reachability: complexity in dynamic condition-response graphs[END_REF], authors use a set of rules ensuring the correctness of new instances of DCR orchestrations by design. In [START_REF] López-Pintado | Controlled flexibility in blockchain-based collaborative business processes[END_REF], authors propose an approach that allows collaborative decisions in blockchain-enabled collaborations. Their approach offers flexibility operations such as: (1) late binding and un-binding of actors to roles in blockchain-based collaborative processes, (2) late binding of subprocesses, and (3) choosing a path after a complex gateway. Authors, though, do not consider evolutionary changes like we do. Moreover, their flexibility operations currently push the burden of checking the transitive effect of new changes onto the new parties. This checking, likely done in a manual way, which can lead to errors.

Conclusion

In this Chapter, first, we proposed a solution for trustworthy execution of business process choreographies modeled in BPMN. Process designers apply a set of transformation rules in order to transform business process choreographies into smart contracts. Then, a 8.7. CONCLUSION smart contract called Interaction SC monitors on-chain the execution of the shared view of the choreography.

We extended afterwards the Interaction SC with transactional mechanisms. These mechanisms include alternatives as forward recovery and compensation as backward recovery. This ensures that the process choreography execution ends in a consistent way even in case of activities failures.

Finally, we presented a protocol enabling adaptiveness to declarative business process choreographies modeled as DCR graphs. This protocol allows (i) partners to first negotiate the change on-chain, (ii) then to dynamically update the choreography process instance managed by the smart contract with the new process change information, and (iii) finally propagate this information across partners processes affected by the change. We demonstrate as well the correctness of the change propagation across participants processes. To do so, we proposed two correctness criteria: (i) the compatibility between the DCR public processes of the participants, and (ii) consistency between one partner's private and public process.

The work described in this chapter was conducted during the PhD of Amina Brahem to be defended in 2023. It is mainly published in the following conference papers: [START_REF] Brahem | Blockchain's fame reaches the execution of personalized touristic itineraries[END_REF], [START_REF] Brahem | Running transactional business processes with blockchain's smart contracts[END_REF], and [START_REF] Brahem | A trustworthy decentralized change propagation mechanism for declarative choreographies[END_REF]. This chapter wraps up the main matter of this document by presenting directions for my future research starting by the ongoing work as first step toward them. My future work shares the same general objectives as my previous activities namely semantically-enabled, context-aware, user-centric and trustworthy service interactions. My ongoing research activities mainly tackles the challenge of enhancing personalization and context-awareness in user-centric service recommendation through a combination of Attention Mechanism with Machine Learning and Deep Learning models. My future work extends my previous and current work into the following two research dimensions: Internet of Things services [START_REF] Casamayor-Pujol | Edge intelligence -research opportunities for distributed computing continuum systems[END_REF] and Distributed Computing Continuum Systems [START_REF] Bouguettaya | An internet of things service roadmap[END_REF]. 9.1. CONCLUSION

Chapter 9

Conclusion and perspectives

Conclusion

This dissertation draws the contributions I achieved with my colleagues and PhD/-Master students during the last ten years. Our main focus was to bring innovative and sound approaches to support service-based solutions ensuring successful interactions in service-service and user-service interactions within most general perspectives of Businessto-Business and Business-to-Customer contexts. We considered typical research issues related to service oriented computing with a specific focus on service discovery and recommendation. Our methodology consists in bringing successful advances in complementary topics such as semantic Web and Machine Learning as well as sound formal frameworks to tackle service interaction issues. We address service mismatch issue through the definition of semantic similarity measure first based on ontologies and then extended to Linked Open Data (Part 2: Chapter 3 and Chapter 4). We address context-aware service recommendation through a Configuration based approach together with LOD based semantic similarity (Part 3: Chapter 5). We tackle the issue of service migration in user-centric contexts through a review of Liquid Software and RESTful principals (Part 2: Chapter 6). We handle service evolutions through the use of Machine Learning models combined with LOD based similarity and Service Social Network graph modeling (Part 3: Chapter 7). And, finally, we address trustworthy dynamic service interactions through Blockchain and Smart contracts (Part 3: Chapter 8).

While our work is in line with current research issues in the field of Web services, it also responds to real needs expressed particularly in the tourism domain within the Smart Loire research project. Although the contributions described in this dissertation was achieved separately, they complement each other to provide a coherent solution for personalized trip recommendation and realisation to meet the Smart Loire project main objectives. The Smart Loire project allowed in turn to evaluate the proposed approaches on real-world datasets and by real users, in addition to publicly available test datasets and baselines.

Service interaction research topic is highly dynamic and continuously evolving. Our contributions described in this dissertation are therefore perfectible in several directions. Some of them are being investigated as ongoing and short-term perspectives. We give an insight in Section 9.2. Some others are longer term following visionary roadmap elements in service oriented computing. We describe our vision to tackle them in Section 9.3.

Ongoing research activities and short-term perspectives

Our most elaborated ongoing work tackles the challenge of enhancing service recommendation with Attention Mechanisms in order to achieve high level of personalization 9.2. ONGOING RESEARCH ACTIVITIES AND SHORT-TERM PERSPECTIVES and context-awareness. The following subsections give insights on the general idea of our undergoing contributions. We also address privacy concerns in user-centric IoT device recommendation.

Attentive knowledge based service recommendation

Attention Mechanisms (AM) [START_REF] Bahdanau | Neural machine translation by jointly learning to align and translate[END_REF] was first proposed as an optimisation technique for machine learning models to make them selectively focus on the most relevant parts of the input data when making a prediction, which helps achieving accurate predictions while running more efficiently. AM have then been quickly adopted and integrated in many AIbased service recommendation approaches which have to process an overwhelming number of available services [168] [104]. AM fit well more particularly context-aware recommendation approaches where the context helps defining important features relevant services should match [START_REF] Unger | Context-aware recommendations based on deep learning frameworks[END_REF].

However, the use of AM for AI-based context-aware service recommendation rises two major questions. First, which features should be considered as important within the attention mechanism and how to model and learn them ? And, second, how to combine important feature selection with the recommendation learning model ?

Attention Mechanisms and Knowledge Graphs

We try to answer the previous questions in the Tourism context and we rely on our previous work on LOD-based data augmentation applied on DataTourism ontology (Chapter 5, Section 5.6). We propose to model AM through Knowledge Graphs (KG). KG provide an efficient form of knowledge representation that captures the semantics of Web objects based on different entities and their relationships. In addition to AM support, KG allow for recommendation interpretation. Indeed, by reasoning over a KG in a node-by-node manner, the connectivity between entities can be discovered as paths that not only reveal the semantics of entities and relations, but also serve as an explanation reflected through a simulated decision-making process which provides explicit semantics for the explanations.

Starting from LOD-augmented DataTourism ontology, we construct first a travel-domain specific knowledge graph (TKG) gathering fine-granular attraction types that allows a deep convergence of all the data and full considerations of their semantic relations. We apply a path extraction process to extract the set of candidate paths. A travel path models a set of entities connected through semantic relationships. Each travel path corresponds a possible mashup of services corresponding to Point of Interest (PoI) entities in the path. Additional -non PoI-entities and semantic relationships will be considered for the mashup explainability. Then, we model the set of travel paths using a recurrent network based 9.2. ONGOING RESEARCH ACTIVITIES AND SHORT-TERM PERSPECTIVES on Gated Recurrent Unit (GRU) technique. User preferences are encored as a Map of weighted features as part of the attention mechanism which also includes the attention function. We consider as attention function the dot product applied to user preferences and travel paths to provide an attention score for each travel path. This allows to keep only the highly ranked paths as relevant recommendations. The first results of our work in this direction are interesting and have been published in [START_REF] Boulakbech | Attentive knowledge-aware path network for explainable travel mashup[END_REF].

Attention Mechanisms and Deep Learning

The previously discussed research direction is based on a unique layer that encodes AM based on user preferences and a single attention function applied as final selection step for mashup recommendation. As a second direction, we consider to spread the attention mechanism over multiple layers of a deep learning process for personalized service recommendation. The idea is apply attention mechanism at three different levels: (i) functional service feature mining, (ii) non-functional service feature mining, (iii) user preference mining, and (iv) overall attention aggregation. The idea is applied on programmableweb dataset and consists in the following steps. We first discover mashups with similar functionalities. Afterward, we build a composite service network that learns function-related features of services based on tags and description information. In parallel, based on user feedback, we learn the non function-related features of services. Then, the recommendation module uses attention aggregation to couple the two service representations and generate the final recommendation result. The first results of our work in this direction are interesting and have been published in [START_REF] Boulakbech | Deep learning model for personalized web service recommendations using attention mechanism[END_REF].

Attention Mechanisms and LSTM for Long-term Service QoS Forecasting

Our previous approach recommends accurately potential service collaborations. The proposed recommendation focused the matching/learning on the functional behaviour of web services. In practice, the success and longevity of such collaborations depends on the ability of the collaborating parties to deliver high Quality of Service (QoS) standards in the long-run. Indeed, web services with comparable functionalities maybe differentiated according to their QoS attribute values such as response-time and throughput. This can be attributed to the differences of their service providers, leading to variability in their functional behaviour. That is, besides accurately recommending functionally composable services, it is crucial to figure out services that are likely to deliver comparable QoS levels over time.

Ensuring long-term success of service interactions and long-run service interoperability 9.2. ONGOING RESEARCH ACTIVITIES AND SHORT-TERM PERSPECTIVES is still challenging. Furthermore, existing techniques predominantly focus on static QoS values observed during composition time. We believe that sequential Long Short Term Memory (LSTM) networks can bring reliable solutions for foreseeing long-term QoS fluctuation over time, hence enhancing the overall service composition. LSTM is a deep learning model adapted to sequential data [START_REF] Hochreiter | Long short-term memory[END_REF]. It allows to capture information dependency contained in sequential data for a long period of time and uses this information to enhance prediction accuracy. LSTM have been successfully combined with Attention Mechanisms on functional and contextual features for Web service recommendation in mashup creation [START_REF] Shi | Functional and contextual attention-based LSTM for service recommendation in mashup creation[END_REF]. Our aim is therefore to extend the LSTM networks predictive ability by integrating attention mechanisms for Long-term Service QoS Forecasting.

Handling attention for time series forecasting [START_REF] Abbasimehr | Improving time series forecasting using LSTM and attention models[END_REF] assigns different weightage to different parts of the input sequence while predicting each element of the output sequence, allowing the model to refer back to the most relevant parts of the input and weigh them more heavily. Attention mechanisms augment the ability of LSTM to manage long sequences, enabling the model to capture long-term dependencies more effectively by focusing on the most relevant parts of the input sequence. When it comes to Web services, multiple QoS attributes such as bandwidth, latency, throughput, availability, and response time are crucial, and each can have a significant influence on the overall quality of the service. Since these attributes can be interrelated, employing a multivariate LSTM model can be beneficial to capture the latent relationships and dependencies between different QoS attributes. The integration of attention mechanisms into LSTMs enables the model to dynamically allocate varying levels of importance to different time steps of each QoS attribute, depending on their relevance to the prediction task at hand. Then the model will be able to focus on crucial portions of the input sequences (i.e., historical data of QoS attributes like bandwidth) that are more indicative of future values, thus improving the forecast's precision.

Privacy-aware user centric IoT device recommendation

This perspective extends our research interest to the Internet of Things (IoT) related topics. IoT as a paradigm, aims to connect different pervasive devices and smart objects to the internet and provides means for data communication between them. Today, the IoT includes an unprecedented number of connections between things as well as between things and people [START_REF] Firouzi | Fusion of iot, ai, edge-fog-cloud, and blockchain: Challenges, solutions, and a case study in healthcare and medicine[END_REF]. According to Statistica 1 the number of connected IoT devices exceeds 15 billion in 2023 and could reach 30 billion by 2030. This rapid evolution is supported by the proliferation of devices of multitude of types, protocols, computing and storage capacities, etc. ranging from the basic sensors to the most sophisticated smartphones and virtual reality headsets. One of the fundamentals of IoT is the ability to create networks of devices 9.2. ONGOING RESEARCH ACTIVITIES AND SHORT-TERM PERSPECTIVES working together to accomplish certain goals in different domains such as smart-homes and healthcare. Ready-made solutions including complementary devices and dedicated management systems may exist for common use. However, when it comes to more personalized use or new goal, identifying relevant devices among the sea of existing ones is still challenging [START_REF] Khalil | Resource discovery techniques in the internet of things: A review[END_REF]. Moreover, usually acting as data generator, IoT devices naturally face privacy and trust challenges. These challenges are even accentuated regarding (i) the limited device capacity making it possible to hold and manage security mechanisms, (ii) the dynamic contexts in which devices evolve, (iii) and the heterogeneity of collaborating/interacting devices [START_REF] Bouguettaya | An internet of things service roadmap[END_REF].

We tackle both challenges from a user-centric perspective and following W3C recent recommendations towards a standardised and interoperable IoT, the Web of Things (WoT) 2and Social Linked Data (SOLID)3 architecture for privacy management. WoT intended to enhance IoT device interoperability by using existing Web standards such as HTTP and REST for data communication. It also includes Thing Description model for homogeneous description of devices and their capabilities. SOLID is a personal data management architecture intended to grant data owners full control over their personal data [START_REF] Mansour | A demonstration of the solid platform for social web applications[END_REF]. It is based on two main components: (1) the Personal Online Store (POD) server where data is being stored, semantically annotated and accessed by third parties according to the data owner's permissions and preferences, and (2) the SOLID application that allows users to register, add, view, and edit data on PODs.

Starting from these elements, we propose a privacy-aware user-centric architecture which relies on the following three main steps. (i) First, we extend LOD-based annotation and similarity calculation discussed in the previous chapters to apply on devices described following Thing Description model. (ii) Second, we implement SOLID architecture to allow for privacy management. (iii) And third, we propose a recommendation algorithm that considers the LOD-based similarity as well as a local user-user social relation network. A first achievement in this direction is presented in [START_REF] Komeiha | Towards a privacy conserved and linked open data based device recommendation in iot[END_REF]. However, there is still a lot of work to be done to achieve high level privacy and interoperability within such a framework. We consider to improve it in two directions. First through extending the privacy management SOLID architecture with a more dynamic permission manager. This will allow for dynamic and evolving privacy. Second the recommendation algorithm should consider permissions prior to recommending any device to ensure its usefulness. One more long-term perspective consists in considering IoT services [START_REF] Bouguettaya | An internet of things service roadmap[END_REF] as functional abstraction of devices within a more general user-centric architecture. We will discuss this idea with other interesting long-term perspectives in the next section. Transitioning from traditional web services to IoT service computing is fundamentally motivated by massive deployment of new devices for various domains, and how do such devices change the way services are provided and received. This crucial shift to IoT enables the delivery of more responsive and intelligent services, unveiling opportunities in various fields such as enhanced data gathering and analysis, real-time monitoring and adaptive user experiences. Such transition will open up key opportunities in various domains; particularly in trust, liquid software and federated learning.

IoT services defined as the transformation of IoT devices that should allow to address two major IoT challenges from the prism of service computing : communication with things and management of things [START_REF] Bouguettaya | An internet of things service roadmap[END_REF]. At first glance, such a transformation allows to benefit from advances in service computing for a straight transposition into IoT service frameworks. However, the reality of IoT as a cosmopolitan world of heterogeneous things makes the shift challenging at several levels including IoT service annotation and discovery, IoT service running and synchronisation, ensuring privacy and trust, etc. Next, we highlight our vision about directions to tackle these challenges while connecting them to our previous contributions.

A user centric architecture with locally managed IoT service interactions. IoT services abstract IoT devices that are usually deployed for contextualized use. Their interactions, with each other as well as with end-user, should allow for a near real-time response delay. A user-centric architecture is more likely to efficiently handle such interactions. IoT services can take part of IoT Mashups to achieve more global common goal. Successful architecture could rely on the concept of IoT Big Service we proposed in [START_REF] Boulakbech | Iot mashups: From iot big data to iot big service[END_REF] as a key point for IoT service composition. The proposed multi-rooted tree architecture allows for IoT services to be part of multiple IoT Big Services and any Big service can in turn take part to more general composition. Local and contextualized management of such services will allow to dynamically bring personalized solutions for end-user. Two technical considerations could be helpful to make such architecture feasible. First, the Web of Things (WoT) standardising initiative will make it easy to define LOD-based annotation and similarity calculation aver IoT services. This will allow to go further defining efficient discovery and recommendation techniques. Second, the use of REST/RESTful and HTTP for WoT device communication will allow extending Liquid Software principals for local management of IoT service interaction synchronisation.

A multi-layered architecture for multi-level privacy and trust management. IoT is one of the primary data generators [START_REF] Firouzi | Fusion of iot, ai, edge-fog-cloud, and blockchain: Challenges, solutions, and a case study in healthcare and medicine[END_REF], including personal data as well as sensible one. Besides, IoT device networks are by nature vulnerable [START_REF] Bouguettaya | An internet of things service roadmap[END_REF]. This emphasises the need for efficient and reliable privacy and trust management mechanisms. In the previously introduced user centric architecture, this could be achieved through a multi-layered architecture. SOLID-based privacy management can be extended with local privacy control nodes for the data generated locally and then combined with higher level privacy control nodes acting as integrators. The role of privacy control nodes can be affected to intermediary big service within a global IoT Mashup.

Similarly, highest level of trust could be achieved combining hybrid Blockchain application [START_REF] Yessenbayev | A Middleware for Hybrid Blockchain Applications: Towards Fast, Affordable, and Accountable Integration[END_REF] with on-chain/off-chain collaboration [START_REF] Falazi | Blockchain-based collaborative development of application deployment models[END_REF][START_REF] Falazi | Smart contract invocation protocol (SCIP): A protocol for the uniform integration of heterogeneous blockchain smart contracts[END_REF]. To this end, a trustworthy interaction scenario could consist in a locally managed smart contract for near-immediate transaction state managing, then relayer smart contracts propagate transactional full logs or simply final state commitments to higher level Blockchains. This collaboration model extends the two-level ones in literature [START_REF] Yessenbayev | A Middleware for Hybrid Blockchain Applications: Towards Fast, Affordable, and Accountable Integration[END_REF]. Achieving this is however challenging as it requires to think about light-weight Blockchains for the local and lower levels of the architecture.

Beyond conventional cloud computing: The rise of Distributed

Computing Continum (DCC)

Distributed Computing Continuum (DCC) [START_REF] Casamayor-Pujol | Edge intelligence -research opportunities for distributed computing continuum systems[END_REF] is a new emerging paradigm proposed to overcome both cloud and edge computing shortcomings by optimizing application-specific computational resources. Concurrently, the trend towards serverless computing in the cloud realm necessitates its adaptation at the edge to manage the heightened complexity, especially with AI/ML components. Edge computing presents unique challenges, categorized as core, specific, and derived characteristics, essential for developing a self-adaptive distributed system. Next, we go through main challenges that are still unsolved and their potential solutions in the realm of DCC.

First, the geographic distribution of available web resources may be problematic, indeed service and cloud computing models face issues related to data latency, especially when resources are scattered across vast geographic locations. By integrating resources from the edge to the cloud, DCC can optimize data processing closer to the data source, reducing latency and ensuring more efficient resource distribution. Second, scalability is a challenge in traditional cloud models, especially during peak demands, which can lead to service disruptions or degraded performance. DCC allows for dynamic scaling by leveraging resources across the computing spectrum (from edge devices to cloud centers) according to the demand, ensuring consistent performance. Last but not least, DCCs can provide a stan-9.3. MID-TERM AND LONG-TERM PERSPECTIVES dardized interface ensuring that all devices can cohesively interact with each other despite the heterogeneity of their manufacturing standards, hence achieving high interoperability standards.

We believe that user-centric multilayered architecture for IoT services previously discussed is a step in the right direction to meet DCC requirement at the application level. Managing resources locally and at the Edge level can take advantage of rule-based approaches [START_REF] Nouicer | Semantic rule-based device recommendation for service migration in multiple device contexts[END_REF], recent standards for resource state management such as GraphQL [START_REF] Da Silva | Beyond traditional web technologies for locally webservices migration[END_REF], and on-the-fly reasoning techniques [START_REF] Mebrek | A multi-agent based framework for RDF stream processing[END_REF].

Application to Healthcare recommendation in SQVALD research project: A fusion of technologies perspective

Major recent research advances in service computing are being achieved through the convergence with other emerging techniques and methods such as AI, Blockchain, IoT, and DCC. Despite the independent evolution of these technologies, they are becoming more intertwined [START_REF] Firouzi | Fusion of iot, ai, edge-fog-cloud, and blockchain: Challenges, solutions, and a case study in healthcare and medicine[END_REF] for two main reasons: First, the novelty brought in one technology quickly finds echo in the other ones. This is for example the case of recent advances in AI deep learning used to bring solutions for service interactions as well as for IoT data "understanding". Second, the combined usage of these technologies allows to propose multifacet solutions to reach new opportunities in several sensitive environments and domains such as Healthcare [START_REF] Firouzi | Fusion of iot, ai, edge-fog-cloud, and blockchain: Challenges, solutions, and a case study in healthcare and medicine[END_REF].

In healthcare, harnessing IoT/IoMT (Internet of Medical Things), AI, Edge Computing, and Blockchain effectively, to tackle challenges like patients privacy fragility, along with RGPD compliance, sensor data integration and monitoring, makes it necessary to propose approaches that leverage wisely all the previous technologies: IoT/IoMT will be in charge of collecting real-time data from various sources and devices, ingesting a rich and continuous flow of medical information within the healthcare framework. AI will take care of analyzing datasets that have been gathered previously to extract and interpret critical insights, thus making accurate predictions and proposing relevant recommendations to patient. In order to process data from IoT/IoMT devices, Edge Computing will run the processing close to the source, facilitating real-time analytics by AI, which is crucial for immediate response scenarios in healthcare, like critical care monitoring or danger recognition. Blockchain ensures the secure and immutable storage of the data generated by IoT/IoMT and analyzed by AI, providing a transparent and immutable ledger for transactions and interactions within the healthcare framework. It also ensures devices, users, and service providers authentication as well as their interactions within the framework [START_REF] Hu | Special issue on "toward intelligent internet of medical things and its covid-19 applications and beyond[END_REF].

In this context, we are running the SQVALD project with the main objective to assist patients during their recovery period after extensive therapeutic treatment for Cancer.

MID-TERM AND LONG-TERM PERSPECTIVES

The idea is not to focus on monitoring various types of sensors and wearable devices continuously measuring and communicating values to integration level which alerts when something goes wrong. We rather aim at helping patient feel and live better in spite of the disease through: (i) the recommendation of adapted complementary activities outside hospitals, (ii) the logistic assistance to schedule and execute/practice these activities, and (iii) the evaluation of the impacts/benefits of the recommended activities on the quality of life of the patient. To this end, SQVALD framework has to successfully integrate the following functions. First, it should securely manage patient data, locally generated as well as accessed on the medical register, through privacy preserving and trustworthy ways. Second, it should be able to "understand" the patient need and capture/learn her/his preferences. Third, it should be able to recommend relevant personalized and context-aware activities. Fourth, it should define and/or choose the best adapted interaction services for a better quality of experience for the patient, ensuring her/his active participation. Fifth, it should include quality of life evaluation metrics and help patient following the right direction.

In order to meet these challenging requirements, it will be necessary to follow a fusion of technologies perspective: IoT, AI, DCC/Edge-Cloud, and Blockchain [START_REF] Firouzi | Fusion of iot, ai, edge-fog-cloud, and blockchain: Challenges, solutions, and a case study in healthcare and medicine[END_REF], within a user-centric framework. The already achieved contributions as well as research directions discussed in this dissertation will be considered together towards a successful outcome for the SQVALD project.

8. 5 . 1

 51 Declarative choreography modeling and change definition . . . . . . 8.5.2 Approach description . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.3 Change propagation correctness . . . . . . . . . . . . . . . . . . . . . 8.5.4 Implementation and experimental evaluation . . . . . . . . . . . . . 8.6 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .V Conclusion and Perspectives9 Conclusion and perspectives 9.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2 Ongoing research activities and short-term perspectives . . . . . . . . . . . . 9.2.1 Attentive knowledge based service recommendation . . . . . . . . . . 9.2.2 Privacy-aware user centric IoT device recommendation . . . . . . . . 9.3 Mid-term and long-term perspectives . . . . . . . . . . . . . . . . . . . . . . 9.3.1 Handling IoT services: a user-side perspective for interactions, privacy, and trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.2 Beyond conventional cloud computing: The rise of Distributed Computing Continum (DCC) . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.3 Application to Healthcare recommendation in SQVALD research project: A fusion of technologies perspective . . . . . . . . . . . . . . . . . . .

2. 1

 1 XML to Solidity code transformation rules . . . . . . . . . . . . . . . . . . . 3.1 Simple DataType Groups Similarity([139]) . . . . . . . . . . . . . . . . . . . 3.2 An example of semantic Web services in the registry . . . . . . . . . . . . . 3.3 Service-Operation similarities . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Service-operation formal context for θ = 0.4 . . . . . . . . . . . . . . . . . . 3.5 Semantic Composability Matching . . . . . . . . . . . . . . . . . . . . . . . 3.6 Example of selected services for composability graph building . . . . . . . . 4.1 Selected touristic offers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 A selection of the 9 most frequent queries. . . . . . . . . . . . . . . . . . . . 4.3 Properties considered in non-functional evaluation . . . . . . . . . . . . . . 8.1 XML to Solidity code transformation rules . . . . . . . . . . . . . . . . . . . 8.2 Evolution of the markings (included, pending, executed) of the DCR choreography process in Figure 8.3 (before changes) . . . . . . . . . . . . . . . . . 8.3 Proposed allowed and denied changes for a DCR process . . . . . . . . . . . 8.4 SC change propagation gas costs and gas fees . . . . . . . . . . . . . . . . .List of Figures3.1 Overview of the IDECSE Framework . . . . . . . . . . . . . . . . . . . . . . 3.2 Service concept lattice corresponding to the formal context in Table 3.4 (Left) and with the requested service S R (Right) . . . . . . . . . . . . . . . 3.3 Composability graph generation steps . . . . . . . . . . . . . . . . . . . . . 3.4 (Left) Time to build IDECSE registry.(Right) Time to match a query. . . . 3.5 (Left) Time to generate composition plans. (Right) Performance comparison with PORSCE and 2P. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Overview of the Architecture of LDS. . . . . . . . . . . . . . . . . . . . . . . 4.2 Evaluation of LODS and sub-measures. . . . . . . . . . . . . . . . . . . . . . 4.3 Example of a touristic service description . . . . . . . . . . . . . . . . . . . 4.4 (Left) Evaluation of result precision. (Right) Comparing result quality without/without context-awareness of the approach with user evaluation . . . . 5.1 Travel Mashup Configuration Architecture . . . . . . . . . . . . . . . . . . . 5.2 (Left) Abstract Activity model. (Right) Example of domain-specific components for travel mashup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Rule editor interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Faceted Mashup Schema Data . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5 Reconfiguration Framework Overview . . . . . . . . . . . . . . . . . . . . . . 5.6 Example of tourism data integration . . . . . . . . . . . . . . . . . . . . . . 5.7 An example of visit itinerary generated by CART . . . . . . . . . . . . . . . 5.8 (a) UEQ questionnaire result (b) UEQ Benchmark reference . . . . . . . . . 6.1 CUBE abstract representation . . . . . . . . . . . . . . . . . . . . . . . . . .

Formally, we define

  the CUBE as C = {u, I c , O c , P a }. u denotes the user. I c denotes the INNER CUBE defined as I c = {d p , D u \ {d p }, R d } where d p is the device being used by u, D u is the set devices owned by u, and R d denotes the research mechanism to discover new devices in the user context. O c denotes the OUTER CUBE defined as O c = {s ∈ S such that ∃d ∈ D u and d ↔ s} where S is the set of services and d ↔ s means that there is an interaction between u and service s through device d. And finally, P a denotes the POOL AREA defined as P a = {d ↔ s such that d ∈ I c and s ∈ O c }.

Contents 3 . 1 52 3. 2 53 3. 3 54 3. 4 Flexible 56 3. 5 59 3. 5 . 2 59 3. 6 61 3. 7

 315225335445655952596617 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Semantic Web Service Composition Framework overview . . . Semantic similarity measure for Web services (Service Matching Engine) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Web service classification and discovery with FCA (Service Classification Engine) . . . . . . . . . . . . . . . . . . . Planning and graph-based composite service generation (Service Composition Engine) . . . . . . . . . . . . . . . . . . . . . . 58 3.5.1 Planning-based composite service generation . . . . . . . . . . . Semantic Similarity for Graph-based composite service generation Implementation and evaluation . . . . . . . . . . . . . . . . . . . Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3. 2 .

 2 SEMANTIC WEB SERVICE COMPOSITION FRAMEWORK OVERVIEW similarity measure for Web services. Section 3.4 details the FCA-based classification of Web services and the use of related structure for service discovery. Section 3.5 details the planning-based and the graph-based composite service generation. Section 3.6 provides insights on the framework implementation and the conducted experiments. Section 3.7 reviews related work. Finally Section 3.8 concludes the chapter.

Figure 3 . 1 :

 31 Figure 3.1: Overview of the IDECSE Framework

3. 4 .

 4 FLEXIBLE WEB SERVICE CLASSIFICATION AND DISCOVERY WITH FCA (SERVICE CLASSIFICATION ENGINE)

  Figure 3.4: (Left) Time to build IDECSE registry. (Right) Time to match a query.

Figure 3 .

 3 Figure 3.5: (Left) Time to generate composition plans. (Right) Performance comparison with PORSCE and 2P.

Contents

4. 1

 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.2 LODS: a Linked Open Data Similarity Measure . . . . . . . . . 67 4.2.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.2.2 Similarity measure for Linked Data Resources . . . . . . . . . . . 68 4.3 LOD-based context-aware service discovery . . . . . . . . . . . . 72 4.3.1 Context-aware service annotation model . . . . . . . . . . . . . . 72 4.3.2 Functional matching of services . . . . . . . . . . . . . . . . . . . 72 4.3.3 Non-functional matching of services . . . . . . . . . . . . . . . . 73 4.4 LDS library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.5 Implementation and Evaluation . . . . . . . . . . . . . . . . . . . 75 4.5.1 LODS similarity measure evaluation . . . . . . . . . . . . . . . . 75 4.5.2 LOD-based context-aware service recommendation in the context of Smart Loire project . . . . . . . . . . . . . . . . . . . . . . . . 76 4.6 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

r . Definition 1 (

 1 SimI). Let O * a,b ⊆ O * a ∩ O * b be the set of shared augmented ontologies between two resources a and b. The instantiation similarity SimI * o (a, b) of two resources described with concepts from an ontology o i ∈ O * a,b is computed based on the cardinalities of differential and common taxonomic features of compared resources as follows.

4. 2 .

 2 LODS: A LINKED OPEN DATA SIMILARITY MEASURE Formally, ∆ ℓ t (r) = {?c 1 , . . . , ?c ℓ ∈ t|(⟨r, ς, ?c 1 ⟩ ∧ ⟨?c 1 , δ, ?c 2 ⟩) ∨ ...⟨?c ℓ-1 , δ, ?c ℓ ⟩} (4.5)

r . Definition 2 (

 2 SimC). Let C * a,b ⊆ C * a ∩ C * b be the set of shared augmented classification schemata between two resources a and b. The classification similarity SimC * ℓ,ℓ ′ t (a, b) of two resources, described with categories from a classification schema t ∈ C *

  (a, b), simP * ∀P i ∈P (a, b)) (4.16) 4.3. LOD-BASED CONTEXT-AWARE SERVICE DISCOVERY 4.3 LOD-based context-aware service discovery 4.3.1 Context-aware service annotation model

4. 3 .

 3 LOD-BASED CONTEXT-AWARE SERVICE DISCOVERY measure on each combination of the Cartesian product of the two compared sets. Then, it divides the sum by the number of combinations to obtain a similarity value in [0,1].

Figure 4 . 1 :

 41 Figure 4.1: Overview of the Architecture of LDS.

  (W D), YAGO knowledge base (Y AGO), and three different DBpedia chapters. We consider most active chapters: Dutch (DBp de ), Italian (DBp it ), and French (DBp f r ). Therefore the considered LOD dataset is LOD = {DBp, W D, Y AGO, DBp de , DBp it , DBp f r }. The considered ontology space is O = {O dbo , 4.5. IMPLEMENTATION AND EVALUATION O yago , O schema , O umbel , O wd }. The classification schemata is C = {C DBp , C DBp_de , C DBp_it , C DBp_f r }. And, finally, the property set is P = {P DBp , P DBp_de , P DBp_it , P DBp_f r , P W D }.

Figure 4 . 2 :

 42 Figure 4.2: Evaluation of LODS and sub-measures.

Figure 4 . 4 (

 44 Right) shows that the context-aware service recommendation process quality is very close to user rating.

Figure 4 . 3 : 1 < service > 2 < 3 <m : properties > 4 <d: 5 < 16 # 20 # 21 <

 4312345162021 Figure 4.3: Example of a touristic service description

Figure 4 . 4 :

 44 Figure 4.4: (Left) Evaluation of result precision. (Right) Comparing result quality without/without context-awareness of the approach with user evaluation

Contents

5. 1

 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.2 Configuration of Personalized Travel Mashup Overview . . . . 85 5.3 DSVL for Mashup Query Definition . . . . . . . . . . . . . . . . 87 5.4 Mashup Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.5 Configuration Problem . . . . . . . . . . . . . . . . . . . . . . . . 89 5.5.1 Configuration Knowledge . . . . . . . . . . . . . . . . . . . . . . 89 5.5.2 Configuration solution . . . . . . . . . . . . . . . . . . . . . . . . 90 5.6 Reconfiguration Process . . . . . . . . . . . . . . . . . . . . . . . 92 5.7 Implementation and Evaluation . . . . . . . . . . . . . . . . . . . 93 5.8 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

5. 2 .

 2 CONFIGURATION OF PERSONALIZED TRAVEL MASHUP OVERVIEW environment. End-users communicate only with the high-level description offered by the semantic facet. The mashup query is analysed by the Invocation Module, which connects to the Mashup Schema to obtain the invocation facet of each service of the composition. Rule descriptions representing context-aware situation and user constraints are used by this module for mashup adaptation. Then, this concrete mashup query is executed by the Configuration Module to generate suggestions to end-users as itinerary recommendation displayed in the Presentation UI.

Figure 5 . 1 :

 51 Figure 5.1: Travel Mashup Configuration Architecture

Figure 5 . 2 :

 52 Figure 5.2: (Left) Abstract Activity model. (Right) Example of domain-specific components for travel mashup

Figure 5 . 3 :

 53 Figure 5.3: Rule editor interface

  Figure 5.4 describes the mashup schema composition for each facet by means of UML Diagram.

Figure 5 . 4 :

 54 Figure 5.4: Faceted Mashup Schema Data

. 4 )

 4 op price calculates the total cost of the visit by the progressive accumulation of service price property limited by the global budget B. Similarly op duration sums the duration of visit of the PoI and considers δt the transition duration to move from one PoI to the next. It keeps only solutions with feasable PoIs within the visit duration D, 1 day in this example. Using these operators and configuration rules, a configuration solution CS i ∈ CSS can be: CS i = {(I, Q)} where I = {(1, P OI) ; (1, Restaurant) ; (1, Event)} Q = {(cost, 80) ; (duration, 1)}

Figure 5 .

 5 5 illustrates an overview of the reconfiguration framework.

Figure 5 . 5 :

 55 Figure 5.5: Reconfiguration Framework Overview

Figure 5 . 6 :

 56 Figure 5.6: Example of tourism data integration

Figure 5 . 7 :

 57 Figure 5.7: An example of visit itinerary generated by CART

Figure 5 . 8 :

 58 Figure 5.8: (a) UEQ questionnaire result (b) UEQ Benchmark reference

Contents 6 . 1 103 6. 5 104 6. 6

 6110351046 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 6.2 CUBE: Approach overview and formal representation . . . . . 99 6.3 CUBE: Architecture and technical considerations . . . . . . . . 100 6.3.1 CUBE architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 100 6.3.2 CUBE layered representation and technical considerations . . . . 101 6.4 Semantic rule-based device recommendation for service-migration in multiple device environment . . . . . . . . . . . . . . . . . . . Implementation and evaluation . . . . . . . . . . . . . . . . . . . Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 6.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Figure 6 .

 6 1 shows a geometric representation of CUBE abstraction. Formally, we define the CUBE as C = {u, I c , O c , P a }. u denotes the user. I c denotes the INNER CUBE defined as I c = {d p , D u \ {d p }, R d } where d p is the device being used by u, D u is the set devices owned by u, and R d denotes the research mechanism to discover new devices in the user context. O c denotes the OUTER CUBE defined as O c = {s ∈ S such that ∃d ∈ D u and d ↔ s} where S is the set of services and d ↔ s means that there is an interaction between u and service s through device d. And finally, P a denotes the POOL AREA defined as P a = {d ↔ s such that d ∈ I c and s ∈ O c }.

6. 3 .

 3 Figure 6.1: CUBE abstract representation

. 2 .

 2 The content management system 101 includes two application portions 103 and 105, two application program interface (API) portions 102 and 106, and a database portion 104. 102 and 106 respectively correspond to the INNER CUBE, I c , and OUTER CUBE, O c . 103, 104, and 105 are part of the the POOL AREA P a .

6. 3 .Figure 6 . 3 :

 363 Figure 6.3: CUBE layers and main used technologies and protocols.

6. 5 .

 5 Figure 6.4: Core concepts and properties

Contents 7 . 1

 71 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 7.2 Approach architecture and overview . . . . . . . . . . . . . . . . 111 7.3 Bootstrapping Phase . . . . . . . . . . . . . . . . . . . . . . . . . 112 7.4 Updating Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 7.5 Learning Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 7.6 Experimental Study . . . . . . . . . . . . . . . . . . . . . . . . . . 116 7.7 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 7.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Figure 7 . 1 :

 71 Figure 7.1: Architecture of LOD Management of Service Deployment and Evolution

Figure 7 .

 7 Figure 7.2 shows the recall and precision rates of the relationship recommendation. Recall, shown in Fig 7.2(a), refers to the the percentage of relationships that are successfully recommended within [T i , T j].It is shown that up to 70% of service interactions are successfully recommended by the proposed approach, which is a good result. The justification is that proposed relationships recommendation leverages both service semantic and service interaction history. Leveraging service interaction history shed the light on some relationships that should exist between LOD resources and that do not exist on the original LOD version. Considering those new relationships improves the relationship bootstrapping.

Figure 7 . 2 :

 72 Figure 7.2: Recall and Precision

Figure 8 . 1 :

 81 Figure 8.1: A touristic itinerary XML schema

123 8. 3 .Figure 8 . 2 : 21 function

 12338221 Figure 8.2: Process choreography model of a touristic visit

1 // state vectors 2

 2 <% groupedIds = g e t W o r k I t e m s G r o u p B y P a r a m e t e r s ( false ) ;

3

  groupedIds . forEach ( idGroup = > { -% > 4 uint public StateVector_ <%= nodeName ( idGroup [0]) % > = 0 ; 5 <% }) -% > 6 ... 7 // for all pivot activities 8 <% groupedIds = g e t W o r k I t e m s G r o u p B y P a r a m e t e r s ( false ) ;

9 13 node

 13 groupedIds . forEach ( idGroup = > { 10 idGroup . forEach ( nodeId = > { 11 let node = nodeMap . get ( nodeId ) , 12 t r a n s a c t i o n a l P r o p e r t y = n o d e T r a n s a c t i o n a l P r o p e r t y ( nodeId ) , PreMar king = preMarking ( nodeId ) , 14 AllPivot = []; 15 if ( t r a n s a c t i o n a l P r o p e r t y == " pivot " ) { -% > 16 17 function <%= nodeName ( idGroup [0]) % > _fail ( uint elementIndex <%= c o n c a t P a r a m e t e r s ( idGroup [0] , false , true , true ) % >) external { 18 var ( tmpMarking , tmpS tateVe ctor ) = ( marking , StateVector_ <%= nodeName ( idGroup [0]) % >) ;

8 . 5 . 1

 851 40 for ( let i = nodeRealIndex ( nodeId ) ; i >= indice ; --i ) { 41 if ( n o d e T r a n s a c t i o n a l P r o p e r t y ( nodeList [ i ]) == " compensatable " ) { 8.5. CHANGE PROPAGATION IN BLOCKCHAIN-ENABLED BUSINESS PROCESS CHOREOGRAPHIES 8.5 Change propagation in Blockchain-enabled business process choreographies Declarative choreography modeling and change definition

8. 5 .

 5 CHANGE PROPAGATION IN BLOCKCHAIN-ENABLED BUSINESS PROCESS CHOREOGRAPHIESelement (an event or an interaction relation) or a DCR subgraph. When G Ref impacts common interactions, we manage a negotiation phase that leads either to a consensus in which case the public process is updated accordingly or to failure in which case the change is rejected. A change operation can be of three types respectively corresponding to ADD, REMOVE, and UPDATE:C ⊕ G Ref , C ⊖ G Ref , and C[G Ref → G ′ Ref ].Figure 8.3 presents the trip planning scenario that was initially presented in the introduction (c.f. Section 7.1) translated into DCR: Figure 8.3(a) presents the DCR choreography and Figure 8.3(b) presents the tourist private DCR process. The choreography process is managed in the different partners processes, namely Tourist, TouristOfficer, Hotel, and CastleAdmin, to ensure a separation of concerns. PayPass (

Figure 8 .

 8 3 are susceptible to changes. A change is composed of a set of change elements and a combination of change operations. We define in the following these two concepts. Change operations are presented in colors in Figure 8.3. An example of an UPDATE operation is change #1 in red in Figure 8.3.

9. 3 .

 3 MID-TERM AND LONG-TERM PERSPECTIVES 9.3 Mid-term and long-term perspectives 9.3.1 Handling IoT services: a user-side perspective for interactions, privacy, and trust

  Semantic similarity measure for Web services (Service Matching Engine) . . 3.4 Flexible Web service classification and discovery with FCA (Service Classification Engine) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Planning and graph-based composite service generation (Service Composition Engine) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Planning-based composite service generation . . . . . . . . . . . . . . 3.5.2 Semantic Similarity for Graph-based composite service generation . . CONTENTS 7.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.1 Business Process Choreographies . . . . . . . . . . . . . . . . . . . . 8.2.2 Transactional Business Processes . . . . . . . . . . . . . . . . . . . . 8.2.3 Blockchain and Smart contracts . . . . . . . . . . . . . . . . . . . . . 8.3 Mashup to smart contract transformation model . . . . . . . . . . . . . . .

	8 Trustworthy service interactions with Blockchain
	8.1
	3 Semantic Web Service Composition Using Semantic Similarities and For-
	mal Concept Analysis

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Semantic Web Service Composition Framework overview . . . . . . . . . . . CONTENTS 3.3 8.4 Extending Smart contracts with transactional business process model . . . . 8.5 Change propagation in Blockchain-enabled business process choreographies .

  CUBE layers and main used technologies and protocols. . . . . . . . . . . . 6.4 Core concepts and properties . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1 Architecture of LOD Management of Service Deployment and Evolution . .7.2 Recall and Precision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1 A touristic itinerary XML schema . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Process choreography model of a touristic visit . . . . . . . . . . . . . . . . 8.3 DCR choreography process and tourist private DCR process of the trip ebooking process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

	LIST OF FIGURES 1.2. GENERAL RESEARCH CONTEXT AND MOTIVATION
	6.3 Chapter 1
	Introduction
	1.1 Short biography

6.2

The CUBE architecture and its internal modules. . . . . . . . . . . . . . . .

  2.2. CONTRIBUTION SYNTHESIS Fail, Subsume, Plug-in, and Match which respectively correspond to composability values in [0 , 0.3[, [0.3 , 0.6[, [0.6 , 0.8[, and [0.8 , 1].

Table 2 .

 2 1: XML to Solidity code transformation rules

	Rule	XML element	Choreography	Solidity code
			element
	(a)	Root element:	Touristic_Visit	Touristic_Visit
		Touristic_Visit	choreography model	Interaction Smart
				Contract (TVISC)
	(b)	POI	participant (POI) pool	participant address
	(c)	Step containing POI	choreography task	functions in TVISC
			=send/receive tasks
			+messages flows
	(d)	Step with no POI	private task	-
	(e)	Tourist's constraints	embedded in	Global variable in the
		(budget, total visit	choreography model	TVISC
		duration, etc)	documentation
	(f)	POI attributes	embedded in the POI	Result of the callback
		(fees, opening hours,	process documentation	performed by
		etc)		Touristic_Visit oracle
				contract

contracts in Solidity code using the second part of the transformation rules in Table

8

.1.

Table 3 .

 3 1: Simple DataType Groups Similarity([START_REF] Plebani | URBE: Web service retrieval based on similarity evaluation[END_REF]) In 1 must be higher than u In 2 to focus on semantic similarity while keeping data-type similarity for checking the composition consistency. Conducted experiments confirmed that the combination u In 1 = 0.80 and u In 2 = 0.20 gave the highest accuracy.

		Int. Real Str. Date Bol.
	Int.	1.0	0.5	0.3	0.1	0.1
	Real	1.0	1.0	0.1	0.0	0.1
	Str.	0.7	0.7	1.0	0.8	0.3
	Date	0.1	0.0	0.1	1.0	0.0
	Bol.	0.1	0.0	0.1	0.0	0.1
	this intuition, the weight u

Table 3 . 2

 32

	3.4. FLEXIBLE WEB SERVICE CLASSIFICATION AND DISCOVERY WITH FCA
	(SERVICE CLASSIFICATION ENGINE)
	Service	S Id Operation	Op Id Input	Output
	Author_Finder	S 1	Author_Find(Book)	op 11	#Book	#Author
	Author_Price	S 2	Find_Author(Book)	op 21	#Book	#Author
	_Finder		Find_Price(Book)	op 22	#Book	#Price
	Search_Book	S 3	Search_Book(Author)	op 31	#Author #Book
	Hotel_Cost	S 4	Find_Hotel(Time,Place) op 41	#Date,	#Hotel,
					#Address #Price
	Book_Hotel	S 5	Book_Hotel(Date,Hotel) op 51	#Date	#Reservation
					#Hotel
	Hotel_Reservation S 6	Hotel_Reservation(Time op 61	#Date	#Reservation
			Hotel)		#Hotel
	IP_to_Country	S 7	IPtoCountry(IPaddress) op 71	#IP	#Country
	IP_Map	S 8	ExtractPlace(IPaddress) op 81	#IP	#Address

: An example of semantic Web services in the registry

Table 3 .

 3 3: Service-Operation similarities Serv. \ Op. op 11 op 21 op 22

	op 31	op 41	op 51	op 61	op 71	op 81

Table 3 .

 3 4: Service-operation formal context for θ = 0.4 Serv. \ Op. op 11 op 21 op 22 op 31 op 41 op 51 op 61 op 71

Table 3 .

 3

	5: Semantic Composability Matching
	Composability value [0, 0.3[ [0.3, 0.6[ [0.6, 0.8[ [0.8, 1]
	Logical Match Type	Fail	Subsume Plug-in Match

Table 3 . 6 :

 36 Example of selected services for composability graph building IMPLEMENTATION AND EVALUATIONinputs that present a valid degree of match with the set of requested Inputs S R In and O Comp is a set of outputs that present a valid degree of match with the set of requested Outputs S R Out . Then, service composition solutions are those corresponding to paths in the graph between S R In and S R Out . The graph search is enhanced by considering QoS constraints over services to fine-tune composition solutions ranking. In this example, in addition to S 2 as individual relevant answer to the requested service, the composition S 1 -S 3 -S 4 is returned as relevant composite answer. A more detailed formalization and illustration of the graph building and search algorithms is given[2].

	Services	S Id	Input	Output
	IP_City	S 1 IP_address	City
	IP_Restaurant	S 2 IP_address Restaurant
	Find_Restaurant	S 3	City	Restaurant
	Restaurant_Menu	S 4	Restaurant	Menu
	Requested_Service S

R1 IP_address Menu Figure 3.3: Composability graph generation steps We formalize satisfiable compositions as S comp ={I comp , O comp } where I comp is a set of 3.6.

Table 4 .

 4 1: Selected touristic offers

		Touristic Offer categories
		Hotels and restaurants
		Historic Sites and Monuments
		Parks and Gardens
		Museums
		Interpretation centers
		Collective accommodations
	Leisure and social service activities facilities
		Cultural and sporting activities
	Table 4.2: A selection of the 9 most frequent queries.
	Q	French keyword
	R 1	Hôtel
	R 2	Restaurant
	R 3 Hébergements locatifs/collectifs
	R 4	Chambres d'hôtes
	R 5	Auberges de jeunesse
	R 6	Auberge de campagne
	R 7	Gîte
	R 8	Site et monument historiques
	R 9	Château

Table 4 .

 4

	3: Properties considered in non-functional evaluation
	Property	Type	µ µ µ	Values Examples
	Spoken language	Set	AtLeast	French, English
	Payment method	Set	AtLeast	Blue Card, Cash
	Ranking	Number/Interval	-	3 stars, [2-4] stars
	Provided services	LOD	Max	dbr:Parking, dbr:Internet

  2)W E t (S u , S v ) and W E t+δt (S u , S v ) are the weights of the relation (S u , S v ) observed at t and t + δt respectively. positiveF eedbacks(S u , S v ) t+δt and allF eedbacks(S u , S v ) t+δt designate the number of positive comments and all comments respectively that have been commented on the relation (S u , S v ) in the time interval [t, t + δt]. We apply sentiment analysis to distinguish between positive comments and negative comments observed in a time interval [t, t + δt]

  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 8.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 8.2.1 Business Process Choreographies . . . . . . . . . . . . . . . . . . 121 8.2.2 Transactional Business Processes . . . . . . . . . . . . . . . . . . 121 8.2.3 Blockchain and Smart contracts . . . . . . . . . . . . . . . . . . . 121 8.3 Mashup to smart contract transformation model . . . . . . . . 122 8.4 Extending Smart contracts with transactional business process model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 8.5 Change propagation in Blockchain-enabled business process choreographies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 8.5.1 Declarative choreography modeling and change definition . . . . 128 8.5.2 Approach description . . . . . . . . . . . . . . . . . . . . . . . . 130 8.5.3 Change propagation correctness . . . . . . . . . . . . . . . . . . . 133 8.5.4 Implementation and experimental evaluation . . . . . . . . . . . 133 8.6 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 8.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

	Chapter 8
	Trustworthy service interactions with
	Blockchain
	Contents
	8.1

Table 8 .

 8 1: XML to Solidity code transformation rules

	Rule	XML element	Choreography	Solidity code
			element
	(a)	Root element:	Touristic_Visit	Touristic_Visit
		Touristic_Visit	choreography model	Interaction Smart
				Contract (TVISC)
	(b)	POI	participant (POI) pool	participant address
	(c)	Step containing POI	choreography task	functions in TVISC
			=send/receive tasks
			+messages flows
	(d)	Step with no POI	private task	-
	(e)	Tourist's constraints	embedded in	Global variable in the
		(budget, total visit	choreography model	TVISC
		duration, etc)	documentation
	(f)	POI attributes	embedded in the POI	Result of the callback
		(fees, opening hours,	process documentation	performed by
		etc)		Touristic_Visit oracle
				contract

  Algorithm 3 Request change smart contract function Data: changeRequests the list of change requests, E the list of endorser addresses, h curr the current ipfs workflow hash, h req the ipfs hash of requested change description, t1 the deadline timestamp for change endorsement, and t2 the deadline timestamp for change propagation Result: emits change request notifications to endorsers Function requestChange(h curr , h req ,E, t1, t2): require msg.sender belongs to the list of business partners if changeRequests[h curr ].status == Init then set changeRequests[h curr ].h req ← h req set changeRequests[h curr ].status ← "BeingP rocessed" set changeRequests[h curr ].initiator ← msg.sender set changeRequests[h curr ].endorsers ← E set changeRequests[h curr ].t1 ← t1 set changeRequests[h curr ].t2 ← t2 emit RequestChange(h curr , h req , E, msg.sender); Change request for public-related changes.The change request is sent to the choreography smart contract which stores the list of change requests assigned to process instances. Algorithm 3 presents the SC function registering a change request. Ongoing process instance changes are recorded with the identification hash of the current process instance. During the change request lifecycle, the request is assigned to a status: Init if no change request is ongoing, BeingProcessed during the negotiation stage, Approved or Declined once the change request is processed by all endorsers. The smart contract checks the identity of the change initiator which should belong to the list of partners, checks that no other change request is being processed, and then creates the change request and sends change request notification to the involved partners. The change initiator also sets two response deadlines t1 for change endorsement and t2 for change propagation to be checked by the smart contract. If one of the change endorsers does not reply before deadline t1 during endorsement or t2 during propagation, an alarm clock triggers a smart contract function cancelling the change request. The smart contract function sets the change request status to cancelled and emits an event notifying partners that the change has been cancelled. In this way we prevent any deadlock that could occur due to one of the partners not responding. Endorser decision management smart contract function Data: changeRequests the list of change requests, e s the endorser address, E the list of registered endorsers, h curr the hash of the current workflow, h req the hash of the desired workflow, rsp the endorser response ∈ {0, 1} Function endorserRSP(h curr , e s , rsp):

	else emit Error; // an ongoing change request is being processed end End Function PROCESS CHOREOGRAPHIES Algorithm 4 require(block.timestamp <= changeRequests[h curr ].t1) require(e s ∈ E) require(changeRequests[h curr ].changeEndorsement[e s ] != 1) require(changeRequests[h curr ].status == ("BeingP rocessed") if rsp == 1 then set changeRequests[h curr ].changeEndorsement[e s ] ←-1 emit AcceptChange(h req , e s ) lockInstanceChecker(h curr ) (ii) 8.5. CHANGE PROPAGATION IN BLOCKCHAIN-ENABLED BUSINESS else if rsp == 0 then

(iii) Change negotiation for public related changes. Algorithm 4 presents the SC function receiving one endorser's decision. All partners subscribe to the change request // declineapprovalOutcomes set changeRequests[h curr ].status ← "Declined" emit DeclineChange(h req , e s ) else emit Error(h req , e s ) end End Function

Table 8 .

 8 4: SC change propagation gas costs and gas fees

	Stage	Step	Partner	Gas	Cost(ETH) Cost($)
	Nego.	LaunchNego	NewRestaurant 213194	0,00639582	16,513
		Case Decline	TouristOfficer	46773	0,00140318	3,623
		Case Accept	TouristOfficer	78999	0,00157998	4,079
			Tourist	86428	0,00181256	4,68
	Propag.	Upd. projection	TouristOfficer	96448	0,00201296	5,197
		Upd. projection	Tourist	96375	0,0020115	5,193
		Upd. projection	NewRestaurant	87648	0,00175296	4,526
		Upd. SC instance NewRestaurant 1321496	0,02642992	68,238

  Contents 9.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 9.2 Ongoing research activities and short-term perspectives . . . . 140 9.2.1 Attentive knowledge based service recommendation . . . . . . . . 141 9.2.1.1 Attention Mechanisms and Knowledge Graphs . . . . . 141 9.2.1.2 Attention Mechanisms and Deep Learning . . . . . . . 142 9.2.1.3 Attention Mechanisms and LSTM for Long-term Service QoS Forecasting . .

. . . . . . . . . . . . . . . . . . . . 142 9.2.2 Privacy-aware user centric IoT device recommendation . . . . . . 143 9.3 Mid-term and long-term perspectives . . . . . . . . . . . . . . . 145 9.3.1 Handling IoT services: a user-side perspective for interactions, privacy, and trust . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 9.3.2 Beyond conventional cloud computing: The rise of Distributed Computing Continum (DCC) . . . . . . . . . . . . . . . . . . . . 146 9.3.3 Application to Healthcare recommendation in SQVALD research project: A fusion of technologies perspective . . . . . . . . . . . . 147

http://projects.semwebcentral.org/projects/sws-tc

https://jena.apache.org

http://docs.oracle.com/javase/tutorial/jaxp/

https://sourceforge.net/projects/conexp/

http://projects.semwebcentral.org/projects/sws-tc

http://www.w3.org/TR/sparql11-query/

http://lod-cloud.net/

dbp is a prefix that represents the URL https://dbpedia.org/resource/

https://smartloire.univ-tours.fr

https://jena.apache.org/

http://www.cs.cmu.edu/ mfaruqui/word-sim/EN-WS-353-SIM.txt

https://smartloire.univ-tours.fr

www.datatourisme.fr/ontologie

http://dbpedia.org/

https://www.statista.com/statistics/1101442/iot-number-of-connected-devices-worldwide/

https://www.cisco.com/c/en/us/solutions/internet-of-things/future-of-iot.html

https://github.com/stormpath/stormpath-sdk-php

www.ProgrammableWeb.com

DBPediaSpotlight

https://cloud.google.com/natural-language

PrevNodeList . push ( nodeList [ i ]) ; -% >

https://www.statista.com/statistics/1183457/iot-connected-devices-worldwide/

https://w3c.github.io/wot-architecture/

https://solidproject.org/

of the board of the Faculty of Science and Technology from 2018 to 2023. . He was awarded RIPEC bonus for the quality of his research and teaching at University of Tours.

Contents

For example, when a pivot activity fails, a function called ActivityName_fail() (line 17 in Listing. 8.3) is generated. This function: (i) updates the state vector of the current task to failed (line 21); (ii) updates the value of the marking variable; and (iii) calls the step function to execute the actions to take (line 22). The latter are:

• compensate the set of activities situated between the current and the precedent pivot (each activity between two pivots or before the first pivot must be compensatable) (lines 38-48 in Listing 8.3);

• start the next alternative (lines 51-52 in Listing. 8.3);

• else abort activities that are at the state initial when no alternative exists after the previous pivot (lines [START_REF] Da Silva | Towards runtime discovery, selection and composition of semantic services[END_REF][START_REF] Danado | Puzzle: A mobile application development environment using a jigsaw metaphor[END_REF][START_REF] Daniel | Mashups[END_REF][START_REF] Debois | Replication, refinement & reachability: complexity in dynamic condition-response graphs[END_REF].

Up to this level of the contributions, we use imperative paradigm (BPMN) to model and implement business process choreographies. In fact, imperative business process models are largely used in the scientific community. The principles of imperative models are aligned with the transactional approach we implemented. And, we consider only the shared view of the choreography. In the next Section, we migrate to declarative business process models called Dynamic-Condition-Response (DCR) graphs. Declarative models are more flexible and light-weight process descriptions than imperative models. Moreover, the declarative paradigm is aligned with the dynamic nature of business process choreographies and will be used to better model and execute adaptive business process choreographies.

Approach description

We describe hereafter the four-steps approach we propose to manage these changes.

(i) Change proposal. The role initiator defines the change of its private DCR process following the previously introduced possible change types and operations. We review a set of integrity rules [START_REF] Debois | Replication, refinement & reachability: complexity in dynamic condition-response graphs[END_REF] to ensure safety and liveness of the updated DCR graph to avoid cycles. Safety means that the DCR graph is deadlock free whereas liveness guarantees the ability of the DCR graph to completion. The integrity rules are of two types and enumerated in Table 8. [START_REF] Abid | Semantic similarity based web services composition framework[END_REF]

. Allowed change rules define what can be done on the graph while

Denied ones define what should be rejected. When the change proposal satisfies these rules the private DCR process is updated. In the case where the change also concerns the public DCR choreography we move to the next steps.

Change propagation correctness

To ensure the correctness of the change propagation, we introduce two correctness properties that check (i) the compatibility between the DCR public processes of the participants and (ii) the consistency between one partner's private and public process.

Compatibility between participants public processes. By relying on the rules in Table 8.3 and to ensure the compatibility between public processes, we introduce the following property where: c is a change, r, E are respectively change initiator and endorsers, G r , G r ′ are respectively the public DCR process of r and r ′ where r ′ ∈ E \ r, ef f ect(c) ∥ Gr the effect of the change c over r, and ef f ect(c) ∥ Gr :⇒ G r refers to computing the new state of the graph G r after applying the effect of c over r, then the proposed property stands as follows:

Consistency between participants public and private processes We define the private DCR process P r of a role r as a subclass of the public DCR process G r . This leads us to Property 2.: Property 2. ∀r ∈ E, P r = G r + N where N is the new behavior. P r is a subclass of the super class G r and G r = P r + τ ϵ (N ), i.e., P r and G r are behaviorally equivalent.

A detailed description including proofs of the previous properties is provided in [START_REF] Brahem | A trustworthy decentralized change propagation mechanism for declarative choreographies[END_REF].

Implementation and experimental evaluation

An implemented prototype of the aforementioned approach is realized . One smart contract is deployed per choreography process using Ganache testnet. Each partner can edit the running instance via the panel manager, a tool to update DCR graph descriptions. Users can add private and choreography interactions, as well as condition, response, include, exclude, and milestone relations. They can also use the panel manager to remove and Part V

Conclusion and Perspectives