VIEWS: 10 PAGES: 10 POSTED ON: 10/20/2011
Enhancing an Open Service Oriented Architecture with Collaborative Functions for Rural Areas Jörg Dörflinger 1, Ganna Frankova 2,3, Antonio Lucientes 4, Rudi de Louw 5, Mariano Navarro 6, Cristina Peña 4, Carlos Ralli 4, Tomás Robles 7 1 SAP Research, Vincenz-Prießnitz-Strasse 1, 76131 Karlsruhe, Germany, email@example.com 2 ArsLogica s.p.a., Viale Trento 117, 38017 Mezzolombardo (TN), Italy, firstname.lastname@example.org 3 DISI, University of Trento, Povo, Via Sommarive 14, 38050 Trento, Italy, email@example.com 4 Telefonica I+D, C/Emilio Vargas 6, 28027, Madrid, Spain alcega, ralli, firstname.lastname@example.org 5 SAP Research, Persequor TechnoPark, Pro Park Building 3, 29 de Havilland Crescent, Scientia, Pretoria 0001, South Africa, email@example.com 6 Tragsa Group, C/Julián Camarillo 6B PL 4, 28037 Madrid, Spain, firstname.lastname@example.org 7 ETSI Telecomunicación, 28028 Madrid, Spain, email@example.com Abstract Development in rural European areas face many barriers. The Collaboration@Rural (C@R) EU project aims to remove these barriers through Collaborative Technologies adopted among Rural Living Labs across Europe, and to substantially contribute to the definition of a user-centric Open Collaborative Architecture. The paper presents the threefold C@R Open Service Oriented Architecture approach in System, Software Architecture and Practical Implementation levels. We show that collaborative functions can be orchestrated and instantiated in a tailored process using a service broker that can register and manage them. By introducing control and data planes and a domain concept, the C@R architecture easily addresses different business models in a more natural way compared to other software platforms or service architectures. We also illustrate how the Software Architecture principles and specific components discussed are instantiated in the Spanish and South African Rural Living Labs. Keywords Open Service Oriented Architecture, Rural Living Lab, Collaborative Working Environment, Collaborative Core Services, Software Collaborative Tools. 1 Introduction “Rural” in Europe accounts for 80% of European area and 22% of European inhabitants. Rural development is not only about a competitive European agriculture, but also about meeting the expectations of citizens in rural areas, aiming for a deeper integration into today’s society and promoting economic development. There are however many barriers that hinder rural development, and the more severe ones include the lack of telecom infrastructures, hard environmental conditions, usability restrictions, lack of ICT literacy, difficulties with introducing new work methods and technology acceptance, long implantation times and the lack of common frameworks and opportunities for collaboration. Barriers are also related to heterogeneity of policies, cultural aspects, and working methodologies. C@R: “A Collaboration Platform for working and living in rural areas” is an EU project with reference FP6-2005-IST-5-03492 that aims to remove these barriers in order to improve rural development in an effective and harmonised way through Collaborative Technologies adopted among Rural Living Labs across Europe. This approach is addressing the following objectives: To provide a collaborative platform for rural communities, defined in cooperation with other Collaborative Working Environment (CWE) communities. To demonstrate the use of the same platform, integrating a variety of tools for various rural user communities. To promote the user-centric Open Collaborative Architecture in new opportunities for the businesses and emerging rural sectors, demonstrating its affordability and usability. To develop a few specialised examples of Rural Living Labs based on a common methodology and assessing benefits of results. To involve Policy Makers in analyzing how to best support innovation and rural development (EU) policies. The C@R technical approach considers three layers explained below: RLL – Rural Living Labs, the layer that introduces RLLs as innovative research instruments for sensing, prototyping, testing, piloting, validating and refining complex solutions in multiple and evolving real-life contexts involving rural users. SCT – Software Collaborative Tools, the upper-layer C@R Service Architecture, that hosts “more complete” services, often already customised to meet specific RLL user requirements. These services are based on orchestration of more elementary (core) services hosted by the CCS layer. CCS – Collaborative Core Services, the layer that hosts the base services and resources (networks, sensors, devices, software modules, localization sources, etc.). The adopted RLL user-oriented methodology and development approach aims to meet the highly specific but dynamic rural users’ expectations and requirements. C@R’s architecture will be highly customizable to adopt to “changing” and new requirements over time. This approach allows C@R to substantially contribute to the definition of a user-centric Open Collaborative Architecture. Furthermore, C@R will deepen the evaluation of collaborative technologies in the rural economic and social backbones, proposing a structured methodology to assess the impact of the technologies developed on the indicators of rural development and supporting policy responses at national, European, and global levels. The paper is organized as follows: In Section 2 we present the threefold C@R Open Service Oriented Architecture approach in System, Software Architecture and Practical Implementation levels. Section 3 shows that collaborative functions can be orchestrated and/or instantiated in a tailoring process using the BUS as a service broker that can register and manage them. Section 4 illustrates Software Architecture principles and how specific components are instantiated in the Spanish and South African Living Labs. Concluding remarks are summarized in Section 5. 2 Open Service Oriented Architecture Design The C@R CWE System is a whole Open System to enable a CWE considering all available actors: users, equipment, service providers, software providers, CWE system designers and stakeholders. The C@R CWE system does not just consider software developers agreeing on a common software architecture providing user services. It is a wider concept than other SOA implementation approaches, such as the “OSOA Collaboration Group” proposal [OSOA]. Therefore, the C@R CWE cannot be described with only a single common Software Architecture diagram, but needs to be defined at three different levels, namely: C@R CWE System Level, which divides the problem in two dimensions: “Control Plane” and “Data (Communication) Plane”. C@R CWE Software Architecture Level, which identifies the main software components, their functionalities and expected interactions. C@R CWE Practical Implementation, which shows actual implementations considering specific real scenarios or Living Labs. While the previous levels are implementation-independent and therefore a single specification works for all LLs, this one must be LL-specific. Below we describe the two first levels in more detail. 2.1 C@R System Level Specification The C@R System specification is based on two principles: the definition of CWE domains and the decision of distinguishing between control and data planes. A CWE domain is defined as the virtual space where a set of users share a specific CWE environment providing a set of service-frameworks or use-cases. From the architecture standpoint, wherever a CWE platform is deployed a new CWE domain is launched. The C@R System is enabled to exchange information among CWE domain borders and thus allowing shared monitoring data, resources, information, etc. This communication is optional and managed by the CWE Domain administrator. Additionally, a CWE Domain can be divided into several sub-domains to afford service-frameworks, use-cases or even user access scalability. In order to face the complexity of managing the interoperability of different resources, a well- known approach among Telecoms/Service providers consists of dividing the problem in two different planes: The Control Plane: where signaling information about resource management is exchanged. The Data Plane: where service traffic is routed according to negotiations in the control plane. Additionally, after analyzing the requirements imposed by the end users of the Rural Living Labs, four Collaborative Distributed Situations (CDS) have been indentified (cf. Table 1). A Collaborative Situation is an event spread in space, and perhaps in time, where a group of people agree to jointly carry out (i.e., collaborate in) a task in order to obtain a specific result. CDS Name Description of the collaborative framework Emergency Team Coordinates rescue actions, sends context information to rescue teams, Management warns other users, etc. Voting Boards To plan a task, schedule and help decision making. e-Auction Site Distributed management of auctions for any type of resource. Multimedia/Data To create, store and exchange information and data created dynamically Collaboration Room by users or machines. Table 1: C@R Collaborative Situations (CDS). Thanks to the introduction of control and data planes and the domain concept, C@R will easily address different business models in a more natural way compared to other software platforms or service architectures: Spontaneous CWE or a CWE managed by an open community, where a group of users can deploy some infrastructure and equipment by installing a C@R platform and managing their own CWE administrative domain. Public Infrastructure or a CWE provided to a specific group of users, where an organization can set up and operate a CWE admin domain providing the services to final users in a rural area. Service Aggregator or a CWE operated by a third party provider, where a service provider can take over a successful CWE administrative domain (Spontaneous or Public) and operate it as users find it useful enough to pay the services operation and evolution. Rural Living Labs are expected to create sustainable infrastructures starting from spontaneous or public models. The evolution to a service aggregator model in some of them would show a clear signal of success of the Living Labs concept and methodology. 2.2 C@R Software Architecture Level The model presented until now is describing the general architecture, helping concepts and functions to be defined. However, software developers need another architecture model describing software boxes and their interfaces, i.e., an operational architecture to be defined. In order to fulfill this need, there is a second level of the architecture definition describing the software implementation of the C@R CWE system (cf. Figure 1). Figure 1: C@R Software Architecture. To define this architecture, each use case is modeled as a Service-Framework. A Service Framework is composed of basic services, collaborative situations, instantiation and orchestration processes, a main thread and a user interface. Functions providing basic services (e.g., 3G connectivity, VoIP, SMS delivery, etc.) are encapsulated as Collaborative Core Services (CCSs). Four categories of CCS have been identified: communications, sensors, user interface support and data storage. CCSs plug into the C@R BUS. Every CCS provides a public API, implemented as a web service. When a standard exists, the CCS developed in C@R project should adopt that standard API (or at least the part of that API to implements the functionality needed in the RLL). Besides the API for interfacing with the upper levels of the C@R architecture, the CCS components implement any software primitive, data object and interoperation protocol necessary to deal with the resource in a transparent and seamless manner. Control functions are encapsulated in the BUS. The BUS acts as a resource broker, enabling the system to search for resources, managing their interconnection and enabling collaboration among different CWE domains. This key piece of C@R architecture consists of five modules: Bus maintenance. This module is responsible for keeping the logs of all the BUS activities, and for all tasks related to the management of the BUS itself. Furthermore, the module will offer configuration files and interfaces for the administrators to control the behaviour of the BUS. Registrar. This module is responsible for keeping a database of all components (CCS and Orchestration Capability) connected to the system. Furthermore it will implement search functionality, allowing any element to look for other elements (CCS, Orchestration Capability) connected to the platform. Connector. This module is responsible for the interconnection of components, and managing the establishment, release and monitoring of connections among them. Bus Inter-working. This module is responsible for negotiating the communication with other C@R platform BUSes, or even control layers of other platforms. Instantiation management. This module serves to support the instantiation process. Control Communications are centralized by the BUS and use web services as transport technology, while Data Communications are P2P and may use any kind of transport technology. Functions enabling Collaborative Distributed Situations (CDSs) are packaged into dynamic libraries known as Orchestration Capabilities (OCs). The core of each OC is a set of atomic functions (i.e., concrete services that could not be divided into smaller ones) such as VoIP, Messages Broadcasting, Shared Display, wiki and forum creation, Videoconference systems, etc. which are categorized as follows: Context Awareness, Distributed Workspaces, and Advanced Services. Functions implementing the general instantiation process and providing the system with adaptability to face different events are known as Software Collaborative Tools (SCTs). 3 Collaborative Functions The ability to compose, extend and tailor is key aspect of systems that support groups of interacting people. Component-based design is a means to achieve these requirements in groupware systems. The C@R architecture described above allows the composition of basic collaboration services, combined with Orchestration Capabilities, in order to define end user services, i.e., SCTs. This architecture is extensible, because it allows the easy integration of new basic capabilities using the BUS. Lastly, it also supports tailoring, because the instantiation process allows adapting of parametric generic SCTs to specific user and environment conditions when deploying end-user services. After analysing collaboration activities in C@R Living Labs we identified an intermediate level called Collaboration Frameworks. A Collaboration Framework is defined as a set of collaborative actions performed by a group of people in order to complete a simple collaboration task. In order to complete this simple (or atomic) collaboration task, several services provided by CCSs are usually required. This simple collaboration task may be repeated and combined with other simple collaboration tasks in order to fulfil complex collaboration tasks. Collaboration frameworks directly link to the OCs we introduced in the C@R project as follows. Orchestration Capabilities (OCs) define components for providing common services for all the SCTs. Each orchestration capability harmonises and integrates into a single model all the information related to providing to the SCTs a uniform and transparent way for using this information. Orchestration Capabilities provide collaborative functions and libraries that will be used by executable scripts that define the composition of SCTs. We identified three orchestration capabilities, namely: (1) Context Awareness, (2) Distributed Workspace and (3) Advanced Services. A key point we have to take into account is that Collaboration Frameworks may involve Components from different OCs. In C@R we identified the following Collaboration Frameworks: Videoconference, Task & Decision Management, e-Voting, e-Auction and Information Centre. This list offers just a first approach for identifying complex collaboration interactions composed by basic collaboration components, which can be used for creating complete and complex end user applications. This list is analysed in the context of the Living Labs involved in C@R in order to polish and complete it. In order to show how the Collaboration Frameworks are being defined and analysed, we show here the analysis performed for Videoconference Collaboration Framework: Description: A group of co-workers have a real time collaboration session with multimedia support. They need audio and video, but may also require combining it with other real time applications. Context: Real time collaboration involving human users and videoconferencing tools are usually proprietary solutions, so the same software/equipment is required for all the end-points. Videoconferencing systems perform best when combined with document repositories, calendars, presence and e-voting systems. Collaboration Components required: A Videoconference Client (CCS client) and Videoconference Server (CCS Server) are required for Client-Server applications. Peer Components (CCS peers) are required for P2P solutions. Users involved: Any group of users, together with a manager who plans and manages the audio conference. 4 Software Architecture principles The C@R Architecture Reference Model is composed of three layers (as described in Section 2). The C@R architecture is supported by several key concepts: CCS, SCT and OC. Figure 2 shows the Data Communication Plane for the software architecture of C@R. This Data Communications Plane supports the integration of different component over the BUS. Figure 2: Software Architecture (Data Communication Plane). The Data Communications Plane includes those elements of the C@R architecture required for creating end-user applications combining CCS and OCs. The Data Communication Plane includes the following sequence of actions: SCTs Creation: Application developers should write the SCT once they identify the collaborative functionalities and OCs required by the application. SCTs have to be written in a standard language defining Components composition. SCTs Loading: Whatever location you are, and using a user terminal, you are able to contact the C@R platform. With suitable authorisations, you may upload the SCT into the Platform, so the components can be located, selected, combined and started for creating the end-user application defined by the SCT. Dynamic Service Composition: When the SCT is uploaded, a key component of the C@R platform is in charge of the major actions: of the composition engine. The Composition Engine uses information provided by the loaded SCT in order to locate and select CCSs and OCs, and finally to combine CCSs and OCs in a suitable order. If any component can not be located, the process halts. Execution of the end-user application: Once all the required components are available and composed with other components, they are started in order to offer the planned service to the end-user. 4.1 Communication Data Flow on the Collaborative Fishing Use Case of the Cudillero Living Lab Following a user-centric approach in Cudillero, the first step was to identify the Collaboration actions performed by the rural workers. In a second step, several SCTs where identified as clear candidates for deploying end-user services. Figure 3 shows the Fishery Tool designed. CCS SCT CCSApp OC Local Tool Fishing boat subdomain SRS CDSApp MDLS Fishery subdomain FISApp AAAS MQS MDLS DMS SMS_S Fishing boat subdomain DSS EM_S SRS CDSApp MDLS MQS Figure 3: Use case for fishing in Cudillero’s Living Lab. This Tool was prototyped and the suitable SCT created in parallel . With the CCS component defined for the Cudillero LL and the required OC provided by the architecture itself, the complete system will be integrated into the C@R Reference Lab in order to get an early validation of the end-user application. Then the system will be moved to the real-world environment at Cudillero for testing. 4.2 Communication Data Flow on the Collaborative Procurement & Logistics Use Case of the South African Living Lab The collaborative procurement & logistics use case [Friedland 2008] in the South African Living Lab provides functionalities to support and improve the procurement process in rural areas. The use case spans the entire business process from order placement via mobile phone (SMS/GPRS) up to the stock delivery using a GIS (Geospatial Information System) application that includes additional business metadata. The Resource Management Framework (RMF) SCT is part of the set of functionalities provided by the GIS application, and is used to manage resources (e.g., trucks, manpower, accommodations) and to optimize the usage of these resources (e.g., optimize capacity, optimize route). To describe the communication data flow between different C@R architecture components a subtask of the entire collaborative procurement & logistics use case will be explained in more detail. Figure 4 describes the overall structure of Collaboration Components in the South African Living Lab. Figure 4: Collaboration of C@R architecture components within the Collaborative Procurement & Logistics use case. The GIS application provides the graphical user interface to the end-user and utilizes the backend functionality provided by the RMF SCT. The process is triggered by the end-user clicking on the “calculate route” button within the GIS application. The following process steps are executed: An XML document with the geographical information about the current map is sent from the GIS application to the RMF SCT and triggers the business process “calculate optimal stock delivery route” described within the RMF SCT (e.g., as BPMN [BPMN] process model). The first step of the business process (get resources) is executed. This action involves the Resource CCS to collect relevant information about the involved resources (e.g., GPS coordinates of point A, B and C). The Resource CCS involves the Context Awareness OC to get context information like the user profile. In step two (get vectors) the collected information is transformed by the GIS boxing CCS from a GIS conform structure into a mathematical representation (vectors and matrix). In step three (calculate route) the mathematical representation of the involved resources is used as input for the Optimization CCS. Additional information like the current status of roads (e.g., blocked, traffic jam) on the possible delivery routes is fetched by the Context Awareness OC, which calculates the optimal route and provides the result as a mathematical model (vector, matrix). In step four (get GPS coordinates) the GIS boxing component transforms the mathematical result into a GIS compatible structure (e.g., GPS coordinates of waypoints). In step five (get map) the GIS manipulation CCS prepares the result to be displayed in the GIS application. Using the Context Awareness OC to adapt the result appropriately to the user’s hard- and software, the result are sent back to the GIS application. Since the RMF SCT and its underlying CCS and OC components are completely decoupled from the RLL GIS application, the RMF SCT could be used by any application as long as the input conforms to the RMF SCT interface specification. 5 Concluding Remarks In this paper, we have addressed the following beneficial points: Using Collaborative Technologies, adopted among several Rural Living Labs across Europe, the C@R project aims to remove the barriers facing rural development in Europe. A substantial contribution is made to the definition of a user-centric Open Collaborative Architecture The adopted RLL user-oriented methodology and development approach aims to meet the highly specific but dynamic rural users’ expectations and requirements. The threefold C@R Open Service Oriented Architecture approach in System, Software Architecture and Practical Implementation levels addresses a wider concept than other SOA implementation approaches. We show that collaborative functions can be orchestrated and instantiated in a tailored process using a service broker (the BUS) that can register and manage them. Thanks to the introduction of control and data planes and the domain concept, the C@R architecture easily addresses different business models in a more natural way compared to other software platforms or service architectures. We illustrated how the Software Architecture principles and specific components discussed are instantiated in the Spanish and South African Living Labs to address a large variety of rural development scenarios and problems. Acknowledgement This work has been partly funded by the European Commission through IST Project Collaboration@Rural: a collaborative platform for working and living in rural areas (No. FP6-2005-IST-5-03492). The authors acknowledge the Commission for their support. We also acknowledge our gratitude and appreciation to all the C@R project partners for their contribution during the development of various ideas and concepts presented in this paper. References OSOA: Open Service Oriented Architecture Group. WWW page.http://www.osoa.org/, accessed 11.3.2008. Carsten Friedland, Christian Merz, Johan van Rensburg: Networked Micro-Enterprises: the Added Value of Collaborative Procurement in Rural South Africa. In Proceedings of the IST Africa 2008, Windhoek, Namibia, 14th to 16th May 2008. Stephen A. White: Business Process Modeling Notation (BPMN) Version 1.0, May 3, 2004.
"Template for the Preparation of an Electronic Manuscript for ICE 2003"