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 gather context computational element that supports rapid, low-cost information from different sources such as sensors, and easy composition of loosely coupled and web services, databases, etc. the process of distributed software applications (Papazoglou, collecting context depends on context parameters 2003). The vision of service as a software nature and its sources. For instance, the user profile component allows combining several services, information is explicitly provided by the user and so providing a global value-added service, called they are characterized by an infrequent change. composite service. A context-aware composition of However, context parameters collected from sensors services (i.e., context-aware composite service) is a are subject to frequent changes. Its collection composition which is able to present different requires interaction with distributed and configurations according to the execution context heterogeneous software or hardware sensors. Also, named ContextView (Hafiddi et al., 2011) (see Fig.4) some context parameters may aggregate or use different context providers to be gathered. To abstract Context-Aware Applications developers from sensors and sensed data variety and complexity, we provide a context provider specification that abstracts application development stakeholders from sensors API details. In our specification (Hafiddi et al., 2011), as illustrated in figure 3, a context provider (i.e., collector of a given service execution context) aggregates a set of parameters providers (e.g., LocationProvider, WethearProvider, etc.) and entities providers (e.g., UserProvider, Figure 4: Core composite service adaptation to its various DeviceProvider, etc.). Both of entities providers and ContextViews.

247 ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

In our approach, a context-view composite service For a given context-view composition strategy presents the result of an adapted composite service and context view, a set of configuration to a given context view, and the various context- conditions (i.e., ConfigCondition) is deduced; view composite services for a given composite A configuration condition may involve a set of service forms the context-aware composite service. services configuration; Figure 5 illustrates our Context-Aware For a given context-view composition strategy Composite Service metamodel. This metamodel is and service, a configuration rule (i.e., based on the following specification: ConfigRule) is associated; Elementary Service, Context-Aware Service, A context-view composition strategy Composite Service, Context-View Composite aggregates a set of configuration conditions, Service (i.e., CVCompositeService) and configuration rules and services. Context-Aware Composite Service (i.e., CAComposite Service) are specific services; In our specification, a context-aware composite A context-aware service is able to adapt service is seen as a specific composite service with a dynamically its behaviour to its several number of ContextViews. For each one, we associate execution (i.e., use) contexts. In other words, a a context-view composition strategy (i.e., context-aware service possesses mechanisms CVCompostionStrategy) which indicates when (i.e., in purpose to exploit only relevant information ConfigCondition: classical condition expressed on of the execution context and adapt ContextView parameters) and how (i.e., ConfigRule: dynamically its behaviour (refer to (Hafiddi et defines how the configuration (i.e., the execution al., 2011) for more details about context- chronology and the types of dependencies) must be aware services specification); realized in the core composition) a set of services A context-aware composite service possesses (i.e., Service) cooperates in order to provide the a context-aware composition strategy (i.e., expected composition regarding the current CACompositionStrategy) which concerns a set execution context. The composition result forms the of context views; context view composite service (i.e., A context-view composite service possesses a CVCompositeService). So, for a given composite context-view composition strategy (i.e., service, the set of its CVCompositeServices CVCompositionStrategy) which concerns a (respectively CVCompositionStrategies) forms the given context view; CACompositeService (respectively A context-aware composition strategy CACompositionStrategy). aggregates a set of context-view composition As illustrated in figure 6, involved services in the strategies; tour planning composite service may change depending to the context parameters and their values.

Figure 5: Core CACS metamodel.

248 AMediatorArchitectureforContext-awareCompositioninSOA

The next step is to check whether the type of the requested service is elementary or composite using the ServiceExaminator entity: In the case of an elementary service, the generation process of the context aware service is similar to the generation mechanism performed by the A2W tool already described in (Hafiddi et al., 2011). The ESHandler plays the same role as the RequestNotifier of the A2W tool. In the case of a composite service, the Figure 6: Succinct CACS model for the Tourism Tour CSHandler receives the request (service id Service. and context data) that will be passed to the CompositionDecisionMaker responsible of CSCompositionStrategy recuperation from the 5 CONTEXT-AWARE current ContextView. After that, the COMPOSITION MECHANISM CompositionBuilder analyzes each CSCompositionStrategy and evaluate 5.1 Mediator Architecture eventually the corresponding conditions in order to extract the best composition combination of services. Note that, the Today, it is very clear that classical approaches for CompositionBuilder could invoke the context-aware composition development present ESHandler or/and CSHandler to build the several limitations. Indeed, designing composite necessary elementary or/and composite service variant for each context-view or introducing context-aware service for the global service all composition scenarios in the same composite is, generation. deeply, a software engineering anti-pattern (e.g., high-cost of maintenance). So, to rationalize the development and maintenance of context-aware 5.2 Tools and Frameworks Support composite services, we have to resort to a strategy pattern that allows dynamic composition without To develop our Context-Aware Composition Builder any duplication or regression risks. Our strategy tool, we used the Eclipse EDI with the following reposes on a NDC (Notify, Decide and Configure) frameworks that respond to a specific technical and pattern which is implemented by the MACAC architectural purpose in our platform: mediator. Spring 2.5 (SpringSource, 2007) was used as Figure 7 presents the core components of our IoC (Inversion of Control) container to link all MACAC tool. As an entry point, the RequestNotifier the components of our framework, also, takes care of each request coming to the platform. transaction is managed by this framework;

Figure 7: MACAC architecture.

249 ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

Hibernate 3.3 (Red Hat, 2011) is the services exist. Context information is mainly utilized framework used in the persistence layer of the at the service discovery step in order to perform the application to map the business model classes; expected composite service. CXF 2.2 (Apache CXF, 2011) is the soap Other context aware composition studies use the middleware that manage all the middleware programming paradigm; the expected communication purposes in our application composite service is twisted from unitary service using the web services technology. and/or composite service. The MySIM (Ibrahim, Le Configuration files written used XML Mouël and FreÏnot, 2009) is one of these technology is parsed using the JAXB2 OXM middlewares that integrate services in a transparent standard (Oracle, 2006); way using the OSGi/Felix platform. It uses the We used Apache ODE (Apache ODE, 2011) reflexive techniques to do the syntactic interface as the BPEL engine in order to generate the matching and ontology online reasoner for the expected composition service. This tool semantic matching. The technique is interesting but allows the execution of one or more business solutions need to be found to make the spontaneous web services expressed using the Web service integration scalable to large environments. Services Business Process Execution Another platform similar to MySIM is the PERSE Language (WS-BPEL). It principally project (Ben Mokhtar, 2007). Four modules present communications with services by sending and the main essence of this project; however the receiving messages, manipulating data and Evaluator module responsible of computing the handling exceptions as defined by any given suited composition combination is the most process. Also, the engine supports the HTTP developed component of the project. The efficiency WSDL for binding, allowing invocation of of PERSE has been tested and proved in the cost REST-style web services. evaluation in terms of service matching, service composition and processing time for service composition. Most of the middleware context-aware 6 RELATED WORK composition approach presents only two granularities of services unitary (or classic) service In this section, we will deal with a representative and component service to generate the expected behaviour. The re-use of the context aware subset of existing studies that work on context-aware composition mechanisms to emphasize the composite service at the composition level is not similarities and differences with our approach. taken in charge. In concerns with the above mentioned approaches all the development stages Context aware service composition process is entangled with several complex features such as (analysis, design and implementation) of the system context modelling, context retrieving, service take care of context in dynamic way. Additionally, context modelling, retrieving and handling phases adaptation and orchestration. The composition mechanism can happen in different time of the are independents from the base application development process, some existing works consider functionality. Focus is given only to the service functional design and application flow that indicates the composition logic at the deployment time like the order in which services are invoked regarding the context aware tool CADeComp (Ayed et al., the context state. 2006). The metamodel used in this project is based on OMG D&C specifications (OMG, 2003), and follows MDA specifications. The CADeComp project describes context aware assemblies of 7 CONCLUSIONS components and produces target deployment plan. At the deployment time, a set of adaptation rules is In this paper, we aimed to propose a specification executed based on the corresponding context for context-aware composition system. So, we adaptation. Likewise, PLASTIC project (Autili et al., started by presenting our motivating scenario 2006) presents similar concept to CADeComp relative to an e-tourism context-aware system, which providing several tools and methodologies to consist of providing a tour guide based on existing develop service-based context aware applications. In services. Then we presented a generic approach for this work, authors introduced a new metamodel modelling and collecting context information, which based on two levels of software description: service presents the basis for the elementary and composite composition as an abstract layer and component context-aware service in terms of design and compositions as a concrete layer where deployed development.

250 AMediatorArchitectureforContext-awareCompositioninSOA

Furthermore, we focused on proposing a meta- Information Systems (ICEIS'11), Beijing, China, June model for designing context-aware composite 2011. services, this meta-model was defined to enable the Hafiddi, H., Baidouri, H., Nassar, M., El Asri, B. and reuse of all the following type of services: Kriouile, A. (2011). A Model Driven Approach for Context-Aware Services Development. In the 2nd elementary service, elementary composite service, International Conference on Multimedia Computing context-aware service and context-aware composite and Systems (ICMCS'11), Ouarzazate, Morocco. IEEE service. Finally, we advanced our MACAC tool Computer Society. based on BPEL technology responsible of the Ibrahim, N., Le Mouël, F. and FreÏnot, S. (2009). ìMySIM: dynamic generation of the expected composite a Spontaneous Service Integration Middleware for service. In our future work, we project to include our Pervasive Environments. In ACM International meta-model in the Eclipse Modelling Framework Conference on Pervasive Services (ICPS'2009), (EMF). Then use the Graphical Modelling London, UK. Framework (GMF) to build a graphical editor that OASIS (2007). Business Process Execution Language (BPEL) 2.0. Available at: http://docs.oasisopen. will allow designers to model context-aware org/wsbpel/2.0/wsbpel-v2.0.html. composite services. Finally, we will implement Object Management Group (2003). Deployment and transformations using Query/View/Transformation Configuration of Component-based Distributed (QVT) in order to transform from CACS technology Applications. Draft Adopted Specification (ptc/03-07- independent models to the specific models, and use 02). MOF script for generating executable code. Oracle (2006). http://jaxb.java.net/. Papazoglou, M., P. (2003). Service Oriented Computing: Concepts, Characteristics and Directions. In WISE'03, the 4th International Conference on Web REFERENCES Information Systems Engineering. IEEE Computer Society, 3-12. Apache CXF (2011). http://cxf.apache.org/. Red Hat (2011). http://hibernate.org/. Apache ODE (2011). http://ode.apache.org/. Salber, D., Dey, A., K. and Abowd, G., D. (1999). The Autili, M., Cortellessa, V., Marco, A., D. and Inverardi, P. Context Toolkit: Aiding the Development of Context- (2006). A conceptual model for adaptable context- Enabled Applications. In CHI’99 Conference on aware services. In Proceedings of international Human Factors in Computing Systems. Pittsburgh, Workshop on Web Services Modeling and Testing Pennsylvania, USA. (WS-MaTe2006), pp. 15-33, Palermo, Sicily, Italy. Schilit, B. and Theimer, M. (1994). Disseminating Active Ayed, D., Taconet, C., Bernard, G. and Berbers, Y. Map Information to Mobile Hosts. IEEE Network, (2006). An adaptation methodology for the deployment 8(5), 22–32. of mobile component-based applications. In IEEE Schmidt, A., Aidoo, K., A., Takaluoma, A., Tuomela, U., International Conference on Pervasive Services Laerhoven K., V., and Velde, W., V. (1999). (ICPS’06), pp. 193-202, Lyon, France. Advanced Interaction in Context. In HUC’99: Ben Mokhtar, S. (2007). Semantic Middleware for Proceedings of the 1st international symposium on Service-Oriented Pervasive Computing. In Ph.D. Handheld and Ubiquitous Computing, pp. 89-101, thesis, University of Paris 6, Paris, France. London, UK. Brezillon, P. (2003). Focusing on context in human- Schmidt, A., Beigl, M. and Gellersen, H., W. (1999). centered computing. IEEE Intelligent Systems, 18(3), There is more to context than location. Computers and 62-66. Graphics Journal, 23(6), 893–902. Brown, P., J. (1996). The stick-e document: a framework SpringSource (2007). http://springsource.org/. for creating context-aware applications. In Proceedings of the Electronic Publishing, Palo Alto, pp. 259-272. Dey, A., K. and Abowd, G., D. (1999). Towards a Better Understanding of Context and Context-Awareness. In Technical Report GIT-GVU-99-22, GVU Center, Georgia Institute of Technology. Favre, J., M. (2004). Towards a Basic Theory to Model Driven Engineering. In Workshop in Software Model Engineering (WISME 2004). Hafiddi, H., Nassar, M., Baidouri, H., El Asri, B. and Kriouile, A. (2011). A Context-Aware Service Centric Approach for Service Oriented Architectures. In the 13th International Conference on Enterprise

251