A Mediator Architecture for Context-Aware Composition in SOA

A Mediator Architecture for Context-aware Composition in SOA Hicham Baidouri, Hatim Hafiddi, Mahmoud Nassar and Abdelaziz Kriouile IMS Team, SIME Laboratory, ENSIAS, Rabat, Morocco Keywords: Context, Ubiquitous Computing, Context-aware Service, Context-aware Composite Service, Aspect Paradigm, Context-Aware Composition, Model Driven Engineering. Abstract: The emergence of wireless technologies, intelligent mobile devices and service oriented architectures has enabled the development of the context-aware service oriented systems. This evolution has put the light on a challenging problem: how to dynamically compose services in SOA based systems to perform more complicated functionalities and provide richer user experience? As observed from the literature, several researches focus mainly on context-aware service design and modelling, but few studies have worked on the composition of this new kind of service to provide more complicated features. In this paper, we aim to present our proposal of adapting service composition by the integration of context during the composition process. This dynamic context-aware composition of services is realized through our Mediator Architecture for Context-Aware Composition (MACAC). 1 INTRODUCTION aware composition computing emphasizes more open-endedness in terms of analysis, design and Over the last few years, adaptive service implementation phases. composition has emerged as one of the most desired CACS development can profit from existing features that allow the integration and cooperation paradigms and technologies such as process between pre-existing services to bring out new orchestration language (e.g., BPEL (OASIS, 2007)) features. This process, known as contextual service and Model Driven Engineering (MDE (Favre, composition, requires from the composite services to 2004)). Process orchestration languages are very consider information from the user’s context – such developed tool that enable the transparency and ease as location, profile, age, etc – by performing several of use of the creation of composed service aiming at adaptations on service behaviour in first stage and extending application functionalities. In our composition technique in second stage. The main approach, BPEL descriptions of CACS are challenge is to operate the most suitable service dynamically generated, through our MACAC tool, combination in order to respond to user expectation to provide the most suitable service composition and improve the end-user experience. This regarding the current user context. MDE is a model obligation has involved the introduction of a new centric approach for software development, in which type of composite services named Context-Aware models are used to drive software development life Composite Services (CACS). In order to be context- cycle. In our approach, CACS artefacts meta-models aware, composite services need to follow some are provided to guide the design of CACS models, requirements in order to resolve the challenges then, the implementation can be generated brought by the context-awareness paradigm. First, automatically by performing a series of model to the composition technique of the existing service model transformations. should be platform-agnostic, so the used approach The rest of this paper is organized as follows. We could be projected on any technologies and present in next section a scenario that concerns an E- implementation tools. Second, the composed service tourism system and highlight the context-awareness should be built in dynamic way depending on the challenges. In Sect. 3, we present our context and context of use, i.e., the expected service must be context provider metamodels for context generated at the execution stage. Compared to management. Sect. 4 presents our CACS traditional service composition approaches, context specification and metamodel. We present, in Sect. 5, Baidouri H., Haﬁddi H., Nassar M. and Kriouile A.. 245 A Mediator Architecture for Context-aware Composition in SOA. DOI: 10.5220/0003992502450251 In Proceedings of the 14th International Conference on Enterprise Information Systems (ICEIS-2012), pages 245-251 ISBN: 978-989-8565-11-2 Copyright c 2012 SCITEPRESS (Science and Technology Publications, Lda.) ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems our MACAC mediator for context-aware fundamental challenges for the development of composition of services. Sect. 6 briefly compares context-aware composition of services in context- related work. Finally, we conclude the paper in Sect. aware systems. First, context definition (i.e., which 7 with plans for future work. context information are relevant for an adequate composition of services) and acquisition is not an evident process. Second, the composition process 2 e-TOURISM SCENARIO must be realized in a dynamic way depending on the execution context. By way of illustration, the previous scenario highlights the two following The following motivating scenario relates to a context-aware e-tourism system. It aims to help the dynamic compositions, of the tour planning service, out-of-towners who need some guidance (i.e. tour depending on the user context: planning) on how they will spend their free time in a Suppose that the tourist is visiting the city in foreign city (see Fig. 1). summer, the system should compose the tour starting with beach in the morning (using a partner e-tourism service), then propose the suited restaurant for lunch, program a monument visit at the evening, and according to user preference, append a party animation at the night to the program; Assume that another tourist is visiting the city in spring, the system should propose natural landscapes instead of beach, and the rest of the tour could change depending on the user needs, weather and city transport infrastructure. 3 CONTEXT MANAGEMENT Figure 1: Involved services in the “Tourism Tour scenario”. 3.1 Context Let’s say that a tourist wants to discover the Context is the information that characterizes the history, culture, monuments, landscapes and interactions between humans, applications, and the gastronomy of a foreign city. So, he accesses a environment (Brezillon, 2003). Several context context-aware e-tourism system, offered by a local definitions were proposed in the literature (e.g., provider, using his mobile device (e.g., PDA, (Salber, Dey and Abowd, 1999), (Schmidt, Beigl Smartphone, Tablet, etc.). This system will suggest a and Gellersen, 1999), (Schilit and Theimer, 1994), complete tour of the city for an entire day or just for (Brown, 1996), (Schmidt et al., 1999), etc.) serving a specific period of the day (e.g., morning, evening, various domains, however the context definition etc.) depending on the tourist free time. given by Dey and Abowd remains the most referred. Furthermore, the tour sent back to the tourist will In fact, these authors have defined context as “any take into account other context information such as information that can be used to characterize the time and weather parameters (e.g., in summer, the situation of an entity. An entity is a person, place or system will favour beaches over monuments), user object that is considered relevant to the interaction profile (e.g., probably append a party at the end of between a user and an application, including the the tour if the user has mentioned it in his user and applications themselves” (Dey and Abowd, preferences) and the used mobile device (e.g., 1999). configuration, CPU, resolution, etc.) in order to In our approach we choose to use the context improve the user experience and sent the most suited metamodel developed in (Hafiddi et al., 2011) for response. Likewise, the system will propose the different reasons. Rather than giving a domain transport (i.e., GIS service) between each places of specific formalization of context this metamodel is the proposed tour and display all the possible domain and platform independent, and can be alternatives (e.g., subway, bus, taxi, etc.) depending extended, if needed, to support various domains. on the distance, the weather and the tourist needs. This core context metamodel (see Fig. 2) specify a This e-tourism scenario highlights the context as a set of parameters (e.g., language, 246 AMediatorArchitectureforContext-awareCompositioninSOA localization, battery, connection mode, etc.) and entities (e.g., user, device, etc.) that can be structured on sub contexts. Sub contexts can also be recursively decomposed into categories. Context may be constituted of simple parameters (e.g., language), derived parameters (i.e., computed from other parameters; for example a distance parameter can be computed from two GPS positions) and complex parameters (e.g., GPS) which have representations (e.g., DMS (Degrees, Minutes, and Seconds) and DD (Decimal, Degrees) representation for the localization parameter). Figure 3: Core context provider metamodel. parameters providers may dispose of an interface that specify whether the provider is remote (e.g., a web service that provides weather) or local (e.g., GPS sensor in a mobile device) and what mode of requests is supported (i.e., query-based or notification-based). A provider may use or derive from a set of providers. For example, a weather provider uses the localization provider to get the weather information. 4 CONTEXT-AWARE Figure 2: Core context metamodel. COMPOSITE SERVICE 3.2 Context Providers In Service Oriented Computing (SOC), a service is defined as self-describing and platform-agnostic The role of context providers is to

Load more