Template for the Preparation of an Electronic Manuscript for ICE 2003 by wulinqing

VIEWS: 10 PAGES: 10

									         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, joerg.doerflinger@sap.com
  2
      ArsLogica s.p.a., Viale Trento 117, 38017 Mezzolombardo (TN), Italy, ganna.frankova@arslogica.it
       3
          DISI, University of Trento, Povo, Via Sommarive 14, 38050 Trento, Italy, frankova@disi.unitn.it
             4
                 Telefonica I+D, C/Emilio Vargas 6, 28027, Madrid, Spain alcega, ralli, alr87@tid.es
      5
       SAP Research, Persequor TechnoPark, Pro Park Building 3, 29 de Havilland Crescent, Scientia,
                           Pretoria 0001, South Africa, rudi.de.louw@sap.com
                 6
                 Tragsa Group, C/Julián Camarillo 6B PL 4, 28037 Madrid, Spain, mnc@tragsatec.es
                          7
                          ETSI Telecomunicación, 28028 Madrid, Spain, trobles@dit.upm.es

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.

								
To top