Collaboration@RuralR-WP 2.1-D2.1.3.pdf · 2017-09-05 · IST-2006-034921 PUBLIC 2 / 70 Project information Project acronym: C@R Project full title: Collaboration@Rural Proposal/Contract

Co l labo ra t i on@Rura l

C @ R A N D O S O A D E S I G N

Document identifier: [email protected]

Date: 31/07/2008

Work package: 2.1

Partners: TID, WIRE, UPM, FIT, ARSL, SAP

WP Lead Partner: UPM

Document status Approved

Abstract: This document describes the underlying architectural concepts and software design methodologies forming the basis for the C@R OSOA architecture design. Furthermore it will serve as a developer guideline explaining the key architecture concepts in more detail and giving concrete use examples as well as common development tools.

Key Words: OSOA, Web service, Semantic web, Web 2.0, Data plane, Communication plane, CWE, CCS, OC, SCT, Development Tools

Date: 10/06/2008 C@R and OSOA design

Project: Collaboration@Rural

Doc. Identifier: [email protected]

IST-2006-034921 PUBLIC 2 / 70

Project information

Project acronym: C@R

Project full title: Collaboration@Rural

Proposal/Contract no.: IST-2006-034921

Project Officer: Olavi Luotonen

Address:

European Commission

DG Information Society and Media

Project Officer

DG INFSO/F4

J-54 2/48

1049 BRUSSELS

Phone: +(32) 2 2954132

Fax: +(32) 2 2969102

E-mail: [email protected]

Project Manager: Mariano Navarro de la Cruz

Address: C/ Julian Camarillo, 6b, 28037, Madrid, Spain

Phone: + 34 91 322 65 21

Fax: + 34 91 322 60 05

E-mail: [email protected]




IST-2006-034921 PUBLIC 3 / 70

CONTENT

1. INTRODUCTION..............................................................................................................................................6

1.1. OBJECTIVE AND CONTEXT OF THIS DOCUMENT..............................................................................................6

1.2. ORGANIZATION OF THIS DOCUMENT..............................................................................................................6 1.3. ACRONYMS AND ABBREVIATIONS......................................................................................................7

2. SOFTWARE DESIGN METHODOLOGY...................................................................................................10

2.1. PROCESSES RELATED TO REQUIREMENTS IDENTIFICATION .........................................................................10 2.2. PROCESSES RELATED TO DESIGN AND IMPLEMENTATION...........................................................................11 2.3. PROCESSES RELATED TO DEPLOYMENT AND OPERATION...........................................................................13 2.4. PROCESSES RELATED TO CCS AND SCT DESIGN AND DEVELOPMENT........................................................13

3. OSOA GENERAL DESIGN ...........................................................................................................................15

3.1. C@R CWE SYSTEM LEVEL SPECIFICATION.................................................................................................15

3.1.1. Control Plane vs. Data Plane..............................................................................................................16

3.1.2. CWE Domain Concept.........................................................................................................................17

3.1.3. Business Models ..................................................................................................................................17

3.1.4. Interactive Services .............................................................................................................................18

3.2. C@R CWE SW ARCHITECTURE LEVEL SPECIFICATION..............................................................................18 3.3. C@R CWE PRACTICAL IMPLEMENTATION LEVEL SPECIFICATION..............................................................20

4. WEB SERVICE DESIGN METHODOLOGY..............................................................................................21

4.1. INTRODUCTION OF C@R WEB SERVICE DESIGN METHODOLOGY..................................................................21 4.2. PROS AND CONS OF C@R WEB SERVICES ...............................................................................................21

4.3. SPECIFICATION OF C@R WEB SERVICE DESIGN METHODOLOGY..............................................22 4.4. EXAMPLE OF A PRACTICAL IMPLEMENTATION OF C@R WEB SERVICE DESIGN

METHODOLOGY ............................................................................................................................................23

4.4.1. Resource to be encapsulated (SMSC-CCS) .........................................................................................23

4.4.2. CCS specification (SMSC-CCS and SMS_Client-CCS).......................................................................24 4.4.3. Tasks to integrate SMSC-CCS and SMS-Client-CCS into the platform ..............................................24 4.4.4. CCS interactions (SMSC-CCS and SMS_Client-CCS) ........................................................................25

5. SEMANTIC WEB USAGE .............................................................................................................................27

5.1. WHY USING THE SEMANTIC WEB APPROACH IN C@R ..................................................................................27

5.2. STEP BY STEP TO THE SEMANTIC WEB..........................................................................................................28 5.2.1. Why using ontologies?.........................................................................................................................28

5.2.2. Existing and reusable ontologies?.......................................................................................................30

5.2.3. How to develop the ontology ...............................................................................................................30

5.2.4. Rules ....................................................................................................................................................34 5.2.5. Access ontologies and rules out of an application...............................................................................35

6. WEB 2.0 USAGE..............................................................................................................................................36

6.1. WEB 2.0 INTEGRATION.................................................................................................................................36 6.1.1. Collaborative Web 2.0 tools ................................................................................................................36

6.1.2. Web 2.0 backend functionality.............................................................................................................38

6.2. METHODOLOGY OF DESIGNING THE WEB 2.0 ...............................................................................................41

7. OPEN STANDARDS .......................................................................................................................................45

7.1. XML............................................................................................................................................................45 7.2. WEB SERVICES DESCRIPTION LANGUAGE (WSDL).....................................................................................46

7.2.1. Abstract interface definition ................................................................................................................46

7.3. SIMPLE OBJECT ACCESS PROTOCOL (SOAP)...............................................................................................46

7.3.1. SOAP messaging framework ...............................................................................................................48

7.3.2. SOAP message structure .....................................................................................................................48

7.4. UNIVERSAL DESCRIPTION, DISCOVERY, AND INTEGRATION (UDDI)...........................................................48




IST-2006-034921 PUBLIC 4 / 70

7.5. OGC STANDARDS........................................................................................................................................50

8. SCT DESIGN PRINCIPLES...........................................................................................................................51

8.1. SOFTWARE COLLABORATIVE TOOLS INTRODUCTION...................................................................................51

8.2. SCT RELATIONS ..........................................................................................................................................52

8.3. EXAMPLE IMPLEMENTATION OF AN SCT FOR THE COLLABORATIVE PROCUREMENT & LOGISTICS USE CASE

IN THE SOUTH AFRICAN LIVING LAB ...................................................................................................................54 8.4. MAIN PRINCIPLES OF DEVELOPMENT OF COLLABORATIVE COMPONENTS.....................................................57

9. DEVELOPMENT TOOLS..............................................................................................................................58

9.1. REQUIREMENTS MODELING AND SOFTWARE DESIGN DEVELOPMENT...........................................................58 9.1.1. Si*tool (http://sesa.dit.unitn.it/sistar_tool).........................................................................................58

9.2. APPLICATION AND PROCESS DEVELOPMENT.................................................................................................58

9.2.1. Netbeans IDE (http://www.netbeans.org)............................................................................................58

9.2.2. Eclipse IDE (http://www.eclipse.org/).................................................................................................58

9.2.3. Intalio Designer (http://www.intalio.com/products/designer/)............................................................58 9.3. SEMANTIC DEVELOPMENT ...........................................................................................................................59

9.3.1. Overview of available semantic web development tools......................................................................59 9.3.2. Protégé (http://protege.stanford.edu/).................................................................................................59

10. CONCLUSIONS ............................................................................................................................................60

11. REFERENCES...............................................................................................................................................63

12. ANNEX A: OGC STANDARDS REVIEW .................................................................................................64

12.1. OPENGIS® CATALOGUE SERVICE (CAT) IMPLEMENTATION SPECIFICATION ...........................................64

12.2. OPENGIS® GML IN JPEG 2000 FOR GEOGRAPHIC IMAGERY ENCODING SPECIFICATION.........................64 12.3. OPENGIS® FILTER ENCODING IMPLEMENTATION SPECIFICATION............................................................64 12.4. OPENGIS® GEOGRAPHY MARKUS LANGUAGE (GML) ENCODING STANDARD.........................................65

12.5. OPENGIS® SENSOR MODEL LANGUAGE (SENSORML) ENCODING STANDARD.........................................65

12.6. OPENGIS® SENSOR PLANNING SERVICE (SPS) IMPLEMENTATION SPECIFICATION...................................65

12.7. OPENGIS® STYLED LAYER DESCRIPTION (SLD) PROFILE OF THE WEB MAP SERVICE IMPLEMENTATION

SPECIFICATION...................................................................................................................................................66

12.8. OPENGIS® SYMBOLOGY ENCONDING IMPLEMENTATION SPECIFICATION (SYMBOL) ...............................67

12.9. OPENGIS® TRANSDUCER MARKUP LANGUAGE (TML) ENCODING SPECIFICATION.................................67

12.10. OPENGIS® WEB COVERAGE SERVICE (WCS) IMPLEMENTATION SPECIFICATION..................................67

12.11. OPENGIS® WEB FEATURE SERVICE (WFS) IMPLEMENTATION SPECIFICATION......................................68

12.12. OPENGIS® WEB MAP CONTEXT (WMC) IMPLEMENTATION SPECIFICATION..........................................69

12.13. OPENGIS® WEB MAP SERVICE (WMS) IMPLEMENTATION SPECIFICATION............................................69

12.14. OPENGIS® WEB SERVICE COMMON (WSC) IMPLEMENTATION SPECIFICATION.....................................70




IST-2006-034921 PUBLIC 5 / 70

LIST OF FIGURES

Figure 1: C@R architecture................................................................................................................... 16

Figure 2: CWE domain concept ............................................................................................................ 17

Figure 3: C@R data plane ..................................................................................................................... 19

Figure 4: C@R control plane................................................................................................................. 19

Figure 5: Cudillero living lab example implementation........................................................................ 20

Figure 6: SMSC used for testing at TID................................................................................................ 23

Figure 7: Interactions between SMS CCS client and the bus................................................................ 26

Figure 8: Semantic web stack................................................................................................................ 34

Figure 9: GIS application used in the Sekhukhune RLL....................................................................... 38

Figure 10: Classic web model compared with the AJAS model ........................................................... 39

Figure 11: AJAX frameworks ............................................................................................................... 40

Figure 12: Components of an adaptive hypermedia system.................................................................. 42

Figure 13: AHS use case ....................................................................................................................... 43

Figure 14: Dojo offline toolkit .............................................................................................................. 44

Figure 15: WSDL documents representing Web services to applications ............................................ 46

Figure 16: SOAP establishes two primary standard message formats .................................................. 47

Figure 17: The symbol used to represent a SOAP message with a document-centric payload............. 47

Figure 18: The symbol used to represent a SOAP message with an RPC-centric payload................... 48

Figure 19: The symbol used to represent a SOAP message delivering its data as an attachment......... 48

Figure 20: Service descriptions centralized in a private UDDI registry................................................ 49

Figure 21: C@R OSOA design ............................................................................................................. 51

Figure 22: SCTs interaction................................................................................................................... 53

Figure 23: SCTs communication........................................................................................................... 54

Figure 24: Collaboration of C@R architecture components within the Collaborative Procurement & Logistics use case .................................................................................................................................. 56

Figure 25: RMF CCS component communication................................................................................ 56




IST-2006-034921 PUBLIC 6 / 70

1. INTRODUCTION

1.1. OBJECTIVE AND CONTEXT OF THIS DOCUMENT

The objective of task T2.1.4 was to identify software design methodologies to create the OSOA taking into account the requirements identified in task T2.1.1. The architecture requirements described in deliverable D2.1.1 [2] form the basic concepts used in the C@R OSOA architecture. This deliverable will explain the usage of these concepts and provide a guideline for developers how to realize the C@R architecture implementation.

The following chapters describe the architecture models and methodologies used to create the C@R OSOA architecture. This document explains the unique concept of the C@R software architecture which is not only created by software developers but an open system supporting collaborative working environments with all participating actors spanning from the software- and service providers, CWE system designers and stakeholders up to the users as well as the equipment to host these platform on the hardware level. The combination of all the different concepts caused by the invocation of different parties leads to a new way of architecture design.

This deliverable also serves as input and developer guideline for the work in WP2.5 OSOA creation since the described concepts will be deployed in WP2.5.

1.2. ORGANIZATION OF THIS DOCUMENT

The document describes the entire process of developing the C@R OSOA architecture approach. Starting point is the description of the general software design methodology utilized in the C@R project to ensure the quality of developed concepts and software. With this knowledge and the outcomes of the well defined process of general software design methodology the individual living labs are able to go on with the conceptualization of the C@R OSOA architecture. Therefore this document provides the general concepts of the OSOA design. Following the OSOA design principles during development leads to a high quality result that is in line with the C@R architecture concepts.

After the general definition of the C@R OSOA concepts the real implementation will take place using web services. To support this development the document provides information of how to implement web services conform to the C@R OSOA approach to keep them in line with the required standards to enable the interoperability with the C@R architecture.

More advanced end user applications will use up to date technologies like “semantic web” and “web 2.0” to improve the applications behavior and to overcome the specific problems (e.g. infrastructural impediments, low end devices, less computer literacy of end users) we face in rural environments. Possible use cases and implementation possibilities are described in this document to simplify the usage of these advanced technologies.

Since the C@R OSOA architecture will be used in a broad community and among different living labs it is absolutely necessary to build the architecture upon well defined standards and to avoid proprietary concepts. The most important standards used in the C@R OSOA are described in this document to improve the quality of developed software and thus to ensure the interoperability, maintainability and reusability of the C@R OSOA architecture components.

A central piece of the C@R OSOA is the concept of Software Collaboration Tools (SCT). Since they combine the lower level components to provide the functionality to the upper layer via a web service interface this concept will be described in this document to ensure the awareness of the current definition. To realize the concept of SCTs in a C@R OSOA compliant manner it is necessary to be aware of the previously chapters of this document.

For the real implementation of the C@R OSOA concepts the document provides information about currently used development tools to simplify the development work.




IST-2006-034921 PUBLIC 7 / 70

The individual chapters of the document are organized as follows.

Chapter 1 is the document introduction summarizing the document content and explaining the context of the document.

Chapter 2 describes a common way how to determine the innovation strategy of a Living Lab. This contains the description of the following processes: Requirements identification, design and implementation, deployment and operation as well as CCS and SCT design and development. This chapter forms the basic knowledge to be able to design high quality C@R OSOA compliant concepts.

Chapter 3 addresses the OSOA architecture concepts, explains the system- and architecture level and provides a real example. This general description is built upon the general concepts described in chapter 2 and also is the basic knowledge to understand the advanced concepts described in the following chapters.

Chapter 4 describes why using web services in C@R and how to implement them to make them applicable in the C@R OSOA architecture communicating with the bus. This chapter is an important information source to clearly state the benefits of web services in the C@R OSOA.

Chapter 5 provides details on why and how to integrate the semantic layer into the C@R architecture and depicts the benefits of this layer. Most of the semantic knowledge is already described in deliverable D2.1.2 [13].

Chapter 6 explains the usage and development of Web 2.0 components. Such as in chapter 5 the Web 2.0 concepts are already explained in detail in deliverable D2.1.2 [13].

Chapter 7 provides a summary of open standards used in the C@R OSOA design to be in line with all current standards. This chapter ensures that the developed concepts are interoperable, maintainable and reusable across the individual living lab boarders.

Chapter 8 addresses the SCT design principles as a major C@R OSOA architecture pice and gives more details on the SCT development and definition.

Chapter 9 provides an overview of common development tools used for the C@R OSOA creation.

1.3. ACRONYMS AND ABBREVIATIONS

AHS: Adaptive Hypermedia System

API : An Application Programming Interface (API) is a source code interface that a computer application, operating system or library provides to support requests for services to be made of it by a computer program.

C@R: Collaboration At Rural.

CCS: Collaborative Core Services.

CWE: Common Working Environment.

DAML : Darpa Agent Mark-up Language.

DL : Description Logics. A language for knowledge expression.

DOM : The Document Object Model (DOM) is a platform- and language-independent standard object model for representing HTML or XML and related formats.

DSL: Domain Specific Languages.

GIS: A Geographic Information System (GIS) is a system for capturing, storing, analyzing and managing data and associated attributes which are spatially referenced to the earth.

GML : The Geography Mark-up Language (GML) is the XML grammar defined by the Open Geospatial Consortium (OGC) to express geographical features. GML serves as a modelling language for geographic systems as well as an open interchange format for geographic transactions on the Internet.




IST-2006-034921 PUBLIC 8 / 70

GPRS: General Packet Radio Service (GPRS) is a Mobile Data Service available to users of Global System for Mobile Communications (GSM) and IS-136 mobile phones.

GUI : A graphical user interface (GUI) is a type of user interface which allows people to interact with a computer and computer-controlled devices which employ graphical icons, visual indicators or special graphical elements called "widgets", along with text, labels or text navigation to represent the information and actions available to a user. The actions are usually performed through direct manipulation of the graphical elements.

HTML : HTML, short for Hypertext Mark-up Language, is the predominant programming language for web pages.

HTTP : Hypertext Transfer Protocol (HTTP) is a communications protocol used to transfer or convey information on the World Wide Web. Its original purpose was to provide a way to publish and retrieve HTML hypertext pages.

IP: An IP address (Internet Protocol address) is a unique address that certain electronic devices use in order to identify and communicate with each other on a computer network utilizing the Internet Protocol standard (IP)—in simpler terms, a computer address. Any participating network device—including routers, computers, time-servers, printers, Internet fax machines, and some telephones—can have their own unique address.

ISO: International Organization for Standardization.

LL : Living Lab.

OC: Orchestration Capability.

OGC: The Open Geospatial Consortium (OGC) is an international voluntary consensus standards organization.

OSOA: Open Services Oriented Architecture.

OWL : Web Ontology Language.

Pellet: Java based API for reasoning on OWL DL documents.

Protégé: Java based open source ontology editor and knowledge-base framework. Protégé provides a plug-in to support OWL editing.

RDF: Short for Resource Description Framework. RDF is a general framework for describing a Web site's metadata or the information about the information on the site.

RDFS: RDF Schema.

RLL : Rural Living Lab

ROI : Return On Investment

SAWSDL: Semantic Annotations for WSDL is a continuation of the W3C member submission WSDL-S that aims at providing a lightweight approach to add semantics to Web Services.

SAWSDL4J and Woden4SAWSDL: These tools provide an object model for SAWSDL by developing a java API.

SCT: Software Collaborative Tool.

SMME : Small Medium and Micro Enterprises.

SMTP: Simple Mail Transfer Protocol (SMTP) is the de facto standard for e-mail transmissions across the Internet.

SOAP: SOAP originally stood for Simple Object Access Protocol, and lately also Service Oriented Architecture Protocol, but is now simply SOAP. SOAP is a protocol for exchanging XML-based messages over computer networks, normally using HTTP/HTTPS. SOAP forms the foundation layer of the Web services stack, providing a basic messaging framework that more abstract layers can build on.




IST-2006-034921 PUBLIC 9 / 70

SQL: Commonly expanded as Structured Query Language, is a computer language designed for the retrieval and management of data in relational database management systems, database schema creation and modification, and database object access control management.

SWRL: Semantic Web Rule Language is a proposal for a Semantic Web rules-language, combining sublanguages of the OWL Web Ontology Language (OWL DL and Lite) with those of the Rule Mark-up Language (Unary/Binary Datalog).

SWS: Semantic Web Services.

TCO: Total Cost of Ownership

UDDI : Universal Description, Discovery and Integration (UDDI) is a platform-independent, XML-based registry for businesses worldwide to list themselves on the Internet.

UI : The user interface (or Human Machine Interface) is the aggregate of means by which people (the users) interact with a particular machine, device, computer program or other complex tool (the system).

UML : In the field of software engineering, the Unified Modelling Language (UML) is a standardized specification language for object modelling. UML is a general-purpose modelling language that includes a graphical notation used to create an abstract model of a system, referred to as a UML model.

URI : A Uniform Resource Identifier (URI), is a compact string of characters used to identify or name a resource. The main purpose of this identification is to enable interaction with representations of the resource over a network, typically the World Wide Web, using specific protocols. URIs is defined in schemes defining a specific syntax and associated protocols.

URL : Uniform Resource Locator (URL) formerly known as Universal Resource Locator, is a technical, Web-related term used in two distinct meanings:

W3C: World Wide Web Consortium.

WFS: Web Feature Server

WS-BPEL: Business Process Execution Language is a business process modelling language that is executable. The origins of BPEL can be traced to WSFL and XLANG. It is serialized in XML and aims to enable programming in the large. The concepts of programming in the large and programming in the small distinguish between two aspects of writing the type of long-running asynchronous processes that one typically sees in business processes.

WSDL: The Web Services Description Language is an XML-based language that provides a model for describing Web services. WSDL is an XML-based service description on how to communicate using web services. The WSDL defines services as collections of network endpoints, or ports. WSDL specification provides an XML format for documents for this purpose.

WSML : defines the formal language for WSMO and is comparably with OWL.

WSMX : is the runtime environment and reference implementation of WSMO.

WSMO: WSMO or Web Service Modelling Ontology is an ontology currently developed to support the deployment and interoperability of Semantic Web Services. Originally was called the Web Service Modelling Framework (WSMF). It includes the sub components WSML and WSMX. WSMO tries to cope with the deficiencies of OWL-S.

XML : Short for Extensible Mark-up Language, a specification developed by the W3C. XML is a pared-down version of SGML, designed especially for Web documents. It allows designers to create their own customized tags, enabling the definition, transmission, validation, and interpretation of data between applications and between organizations.




IST-2006-034921 PUBLIC 10 / 70

2. SOFTWARE DESIGN METHODOLOGY

C@R is dealing with the problems of introducing innovations based on ICT Collaborative Services in Rural Areas. Rural living is characterized by widely-distributed activities of work and life. Successfully integrating these activities and multiple roles requires that solutions design is driven by human-centric innovation principles, adapted to the rural requirements.

The deliverable D3.1.1 "Living Labs Common Methodology Framework" [1] presents the methodology for all the different tasks to be performed to create and maintain effectively a Living Lab. It proposes a common way to determine the innovation strategy of a Living Lab, define the services to be provided in the scope of a Living Lab, manage the Living Lab investments, risks and technological infrastructure, develop the requirements of the software tools to be provided, to deploy the platforms, to develop the applications, to perform the user roll out, to provide the corresponding training, to compile relevant information to evaluate and assess the Living Lab performance and to elaborate the business models to assure the Living Lab sustainability beyond C@R lifetime. The software design methodology followed by Block 2 (Software collaborative tools) for developing OSOA is compliant whit the proposal of D3.1.1 [1].

The key principles of development of Rural Living Labs that guided the software design methodological are the following:

• Living Labs as context for human-centric innovation. The Rural Living Labs methodological framework has as main goal to provide guidance to human-centric systemic innovation for knowledge society services, businesses and technologies in rural settings.

• Boosting service, technology and business development. Rural living is characterized by widely-distributed activities of work and life. Successfully integrating these activities and multiple roles requires that solutions design is driven by human-centric innovation principles, adapted to the rural requirements.

• Sustainable and durable over the time. Rural Living Labs have the potential to grow wide innovation environments that serve as a true catalyst for rural development. The methodological framework must provide lessons learned to find the right balance in the myriad of public and private goals, and establish sustainable business models for these innovation platforms.

The OSOA design and creation relate to Living Labs Technical solutions development, and is an enabler for Living Lab Technological infrastructure Planning and Living Lab Service definition.

This section presents the guidelines for the software design methodology followed by Block 2 (Software collaborative tools) for developing OSOA architecture and components, which is compliant whit the proposal of D3.1.1 [1].

These guidelines are grouped around the main processes: requirements identification; design and implementation; deployment and operation and CCS and SCT design and development we describe in details below.

2.1. PROCESSES RELATED TO REQUIREMENTS IDENTIFICATI ON

C@R follows a user centric approach (see [email protected],"Requirements capture for CWE in Rural Areas and Software design and Architecture for Software Collaborative Tools") [2] for building and delivering an OSOA for collaborative services to boost the introduction of CWEs as key enablers on rural environments. Technical requirements should be identified by BL1 and BL2 in order to define the OSOA and suitable SCTs. The identifications of requirements should be accomplished closely with the technical responsible of each RLL.




IST-2006-034921 PUBLIC 11 / 70

RLLs are organised as multidisciplinary research environments where different actors (including not only people, but also animals and plants which are ubiquitous in rural areas, at least in traditional activities) will interact with technologies that will be introduced in a progressive way.

One of the main challenges of designing ICT services in rural environments is involving the users in eliciting user requirements. To capture user requirements effectively, the context and situation in which we would like to develop the service system is first described. The context description addresses dynamics, effective or missing links that might have an effect on the service system.

A key determining aspect of LL Labs is the high degree of user/stakeholder participation: therefore, the actual goal of the process in user involvement/elicitation methods is co-creating technological applications and including service and business development.

Considering that the elicitation exercise may be carried out in environments in which rural life has not focused on technological and social change, stakeholders/users may have little insight into the services they can use and into entrepreneurial activities with economically viable solutions. It is important to create iterative processes between the evaluating service needs as identified by experts and needs as envisioned by the potential users of the services. A core principle for an effective requirements elicitation process is to include relevant stakeholders, as co-creative users, in the exercise early and if possible often: The requirements are expected to change as the LL evolves: short interaction cycles with the users will allow the flexible development of products that will adapt to those changes. The developers will need to develop a system of requirements management, a living text that will document the evolution of requirements and the users’ feedback.

2.2. PROCESSES RELATED TO DESIGN AND IMPLEMENTATION

The overall design of the C@R CWE platform is driven by several factors:

• Providing easy to use, end to end simplified, locally relevant solutions. End-Users must be able to identify applications and tools as important for their daily life. Usage appropriate for rural conditions together with low burden of maintenance and operation will make provided solutions acceptable and successful.

• Embedded solutions comprising informal and formal aspects of collaboration. Collaboration tools must support formal business transactions and workflows that enable rural people to participate in a global economy in a standardized way. At the same time informal, straightforward ways of collaboration (Web 2.0 style) are predestined to overcome social exclusion and to provide most valuable knowledge sharing.

• Highest flexibility to adapt and customize solutions to the context of local RLLs. Following a Service Oriented Architecture approach will enable reusability of services and components in different contexts. Orchestration capabilities to rearrange and rapidly adapt to changing business requirements will not only cope with continuous innovation but drive it.

• Compliance to Open Standards. Open standards ensure the interoperability and reusability of components and services between heterogeneous platforms.

• Supporting a variety of infrastructures. Whereas the Turku and Hungary RLL are very good examples that broadband network connections can be established in a ubiquitous way in rural areas, other RLL regions suffer from lack of communication infrastructure (Cudillero), low bandwidth (Soria, South Africa) electric power failures (South Africa) or lack of available hardware (Soria, South Africa).

• Lowered TCO and immediate ROI. Limited investment capabilities of rural players require a low Total Cost of Ownership. Immediate Return On Investment must be visible and is key to encourage ICT solutions and services to rural communities.

Very important are the interoperability capabilities of the design, and the integration of external initiatives (e.g. Frascati, VOICE, GIS platform).




IST-2006-034921 PUBLIC 12 / 70

The diversity of partnerships in the RLLs also requires support for different deployment and operation models of the CWE platform that affect the design approach of OSOA:

• CWE managed by an open community (Spontaneous CWE)

• CWE provided to a specific group of users (Public infrastructure)

• CWE operated by a third party provider (Service Aggregator)

Implementation should be based on Open Standards and integration of components into the architecture will e supported by the Reference Laboratory (RL) (see C@R D2.6.1, “Deployment of the Testing environment Infrastructure”) [3].

Due to the nature of Living Labs neither all components nor the overall architecture is completely defined. Therefore the LLs input on these templates provide not the final picture but will continuously be refined for the remaining time of the project. As with this deliverable and with the RL itself, iterative work will be done until we can get the whole picture.

The RL is in charge of testing the components that are going to be deployed in each Living Lab. In this sense, as a central infrastructure, it will support the developers to verify that their components comply with the C@R architecture.

The RL is not intended to test all the components, but to give a supporting environment where all of them can be integrated to work together.

The situation of the LLs is diverse: some of them start from the scratch and other have already developed some working tools. The development process is at different levels in each LL, so the component integration should take into account this variety. As the RL is the central testing platform, it will receive deliveries from the developers and, even more, these deliveries will be available in different versions.

All these factors make us aware of the need of a methodology based on software engineering techniques. Each local development will have its own methodology, but the overall methodology of the C@R architecture needs to control and organize all these local developments to achieve the general objective. The V-model and waterfall lifecycle models represent the idealized model of software development to be applied for local developments. To accomplish the integration process of the C@R components, we have the RL will provide a test plan so as to coordinate the whole process.

The short topics from the standard regarding the test plan are the following:

1. Test Plan Identifier (TPI).

2. References: List all documents that support this test plan, such as System Requirements specifications (this document), Methodology, etc.

3. Introduction: Identify the objective of the plan or scope of the plan.

4. Test Items: These are the things RL intends to test within the scope of this test plan.

5. Software Risk Issues: Identify what software is to be tested and what the critical areas are, such as Delivery of a third party product, new version of interfacing software, etc.

6. Features to be tested: This is a listing of what is to be tested: This is a listing of what is 'not' to be tested.

7. Features not to be tested: This is a listing of what is 'not' to be tested.

8. Approach: This is the overall test strategy for this test plan. Overall rules and processes should be identified, such as any special tools to be used, metrics to be collected and their level, hardware, software…

9. Item Pass/Fail Criteria: Specify the criteria to be used to determine whether each test item has passed or failed.




IST-2006-034921 PUBLIC 13 / 70

10. Entry & Exit Criteria: Specify the criteria to be used to start testing and how you know when to stop the testing process.

11. Suspension Criteria and Resumption Requirements: Suspension criteria specify the criteria to be used to suspend all or a portion of the testing activities while resumption criteria specifies when testing can resume after it has been suspended.

12. Test Deliverables: List documents, reports, charts, that will be presented to stakeholders on a regular basis during testing and when testing has been completed.

13. Remaining Test Tasks: To avoid the testing of features that has not been released yet.

14. Environmental Needs: Are there any special requirements for this test plan, such as Special hardware (simulators, static generators, etc), Specific versions of other supporting software, How much testing will be done on each component of a multi-part feature, etc.

15. Staffing and Training Needs: This should be avoided if the developers provide the scenarios to test their components.

16. Responsibilities: The person/team that is in charge. As several stakeholders are involved in the testing process, there will be different responsibles depending on the component distribution.

17. Planning Risks and Contingencies: This should be address that the RL cannot provide the whole infrastructure to test the components. An open architecture to connect to the RL from the outside is part of this topic.

18. Approvals: The test responsible validates whether the component is accepted or rejected.

The test plan does not have to exactly follow these topics, but we consider these relevant for the testing process itself.

2.3. PROCESSES RELATED TO DEPLOYMENT AND OPERATION

The purpose of Deployment and Operation is to assemble the product from the Collaboration Components, ensure that the product, as integrated, functions properly, and deliver the final collaboration product, which should be work correctly during the live cycle of the service.

Deployment support should provide support guidelines for service adaptation at each LL that should be supported by RL. In order to deal with different RLL characteristics, the general guidelines should be adapted to be local developer and stakeholders to each LL based on local development methodology. The Deployment will be based on the instantiation process.

Operation will be based entirely on local methodologies but feedback should be provided to the RLL in order to identify a best practices portfolio to be used for further RLL in the selection and application of local methodologies.

2.4. PROCESSES RELATED TO CCS AND SCT DESIGN AND DE VELOPMENT

The purpose of Design and Development of CCS and SCT is to design, develop, and implement solutions to requirements specified by end-users. Solutions, designs, and implementations encompass ICT Tools, collaboration components, and other products related.

The process area focuses on the following:

- Evaluating and selecting solutions (sometimes referred to as “design approaches,” “design concepts,” or “preliminary designs”) that potentially satisfy an appropriate set of allocated requirements




IST-2006-034921 PUBLIC 14 / 70

- Developing detailed designs for the selected solutions (detailed in the context of containing all the information needed to manufacture, code, or otherwise implement the design as a product or product component)

- Implementing the designs as a collaboration component

Alternative solutions need to be identified and analyzed to enable the selection of a balanced solution across the life of the product in terms of cost, schedule, and performance.

Design consists of two broad phases that may overlap in execution: preliminary and detailed design. Preliminary design establishes component capabilities including product partitions, product component identifications, system states and modes, major intercomponent interfaces, and external product interfaces. Detailed design fully defines the structure and capabilities of the collaboration components.

Once the design has been completed, it is implemented as a collaboration component. The characteristics of that implementation depend on the type of collaboration component.

Finally, perform verification and/or unit testing of the collaboration component as appropriate. Further integration into the OSOA should be performed by the RL




IST-2006-034921 PUBLIC 15 / 70

3. OSOA GENERAL DESIGN

There currently exist many different 'flavors' and interpretations of service-oriented architecture (SOA), which are being promoted by different organizations.

One of the most popular and active SOA developers group is the “Open SOA (OSOA) Collaboration” (http://www.osoa.org), which represents an informal group of industry leaders that share a common interest: defining a language-neutral programming model that meets the needs of enterprise developers who are developing software that exploits Service Oriented Architecture characteristics and benefits.

This “OSOA Collaboration group” is not a Standards Body; it is a set of vendors who wish to innovate rapidly in the development of this programming model and to deliver Specifications to the community for implementation. These specifications are made available to the community on a Royalty Free basis for the creation of compatible implementations. When mature, the intent is to hand these specifications over to a suitable Standards Body for future shepherding.

The different SOA initiatives have been usually criticized for the lack of interoperability and therefore the “OSOA Collaboration Group”, being a group of several key vendors, is expected to be in a unique position to create the necessary critical mass to reach a universal SOA solution. The main critic made to this group is the absence of “Microsoft” although a degree of interoperation has been provided.

The C@R CWE System is certainly a different and wider concept than the “OSOA Collaboration Group” proposal and other SOA implementations approach, as it is not just considering software developers agreeing on a software architecture providing user services, but as a whole Open System to enable a CWE considering all available actors: users, equipment, service providers, software providers, CWE system designers and stakeholders [28].

Therefore, C@R CWE cannot be only described with just a single common Software Architecture diagram, but needs to be defined at three different levels:

1. C@R CWE System Level, which –following the Telecoms/Service providers model- divides the problem in two dimensions: “Control Plane” and “Data (Communication) Plane”.

2. C@R CWE SW Architecture Level, which identifies the main software components, their functionalities and expected interactions.

3. C@R CWE Practical Implementation, which shows an actual implementation considering a specific real scenario or Living Lab. While the previous levels are implementation-independent and therefore a single specification works for all LLs, this one must be LL-specific.

However, despite of C@R CWE and common SOA approach differences, some influence and learnt lessons from OSOA might be useful and valuable at the “C@R CWE SW Architecture Level”.

The following sections aim to show the actual research conclusions on the first two implementation-independent layers specifications and, in the present document; the third level will be described taking the example of the Cudillero Fishery LL in the north of Spain.

3.1. C@R CWE SYSTEM LEVEL SPECIFICATION




IST-2006-034921 PUBLIC 16 / 70

C@R CWE System Level specification describes C@R concept of a “CWE domain” and the system architecture to enable Telecoms/Service providers to offer “CWE Services” in a Living Lab.

The main specific concepts and definitions which really make a difference compared to other common SW Architectures are the following:

• Control Plane vs. Data Plane.

• CWE Domain concept.

• Business Models.

• Interactive Services.

3.1.1. Control Plane vs. Data Plane

In order to face the complexity of managing the interoperability of different resources, a well-know approach in the Telecoms/Service providers domain consist on dividing the problem in two different planes:

• Control Plane: where signaling information about resources management is exchanged.

• Data Plane: where the service traffic is routed according to the negotiations in the control plane.

Figure 1: C@R architecture

The main control element of C@R CWE (see Figure 1) is the “BUS” which keeps information about registered resources (Registrar BUS component) and the connections among resources (Connector BUS component).




IST-2006-034921 PUBLIC 17 / 70

While signaling traffic is routed though a central element, the BUS, data traffic will be exchanged in a P2P (peer-to-peer) mode and thus C@R takes benefit from both centralized and peer-to-peer architectures.

The resources to interconnect thanks to the BUS are:

• CCS Components: at the lowest layer of the architecture encapsulation hardware and software resources which might go from simple devices or applications to entirely SW platforms. As a particular CCS type, CCS-applications include a user interface and a service-framework main thread.

• OCs: which implement functions, data structures and tools to support “Collaborative Situations” or “Collaborative Distributed Workspaces”. The OCs are “Distributed Workspaces”, “Context awareness” and “Advanced services”.

• SCTs: which implement the BPEL scripts in charge of launching a specific service-framework and updating them thanks to the instantiation concept/process.

The Semantic Technologies and WEB 2.0 layers are expected to add semantic processing and web 2.0 capabilities as described in D2.1.4 [26].

3.1.2. CWE Domain Concept

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 (BUS+other components) is deployed a new CWE domain is launched.

Thanks to the BUS component named “BUS Internetworking” – depicted in the previous section- some information might optionally flow among CWE domain borders and thus allowing to share monitoring data, resources, information, etc (see Figure 2). This communication will be always optional and managed by the CWE Domain administrator.

Aditionally, a CWE Domain can be divided into several sub-domains to afford service-frameworks, use-cases or even users access scalability. In this case, each sub-domain is identified by a C@R BUS (plus additional minimum components) and all the BUSes in a domain work in close cooperation, sharing all data and information thanks to the “BUS Internetworking” BUS component.

Figure 2: CWE domain concept

3.1.3. Business Models




IST-2006-034921 PUBLIC 18 / 70

Thanks to the introduction of the control and data planes and the domain concept, C@R will easily address different business models in a more natural way compared to other SW platforms or service architectures:

• Spontaneous CWE or CWE managed by an open community, where a group of users can deploy some infrastructure and equipment installing a C@R platform (BUS+minimum set of components+ needed resources for that specific scenario) and manage their own CWE administrative domain.

• Public Infrastructure or 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 CWE operated by a third party provider, where a service provider can take over a successful CWE admin domain (Spontaneous or Public) and operate it as users find it enough useful to pay the services operation and evolution.

Rural Living Labs are expected to create sustainable infrastructures starting from spontaneous of public models. However, their evolution to a service aggregator model in some of them would show a clear signal of success of the Living Lab concept and methodology.

3.1.4. Interactive Services

The control and data plane division plays a key role to solve interoperability problems and afford system scalability and, at the same time, provides the best way to integrate such a platform with a Telecom or Service Provider service infrastructure.

Moreover, C@R architecture model is suited to enable real-time interactive services based on the SIP/IMS service infrastructures, which is expected to play a main role in the ALL-IP service providers model.

In the C@R architecture model, SIP/IMS functions and data structures supporting specific collaborative situations or collaborative distributed frameworks will be implemented in the “Advanced Services” OC (orchestration capabilities) as describe in the sections above.

3.2. C@R CWE SW ARCHITECTURE LEVEL SPECIFICATION

The model presented in the previous chapter is describing the general architecture helping concepts and functions to be defined. However, software developers need yet another architecture model describing software boxes and their interfaces. In order to fulfill this need, there is a second level of the architecture definition describing the software implementation of C@R CWE platform.

This architecture level specification is common to all C@R implementations in the Living Labs and, for better understanding is depicted with two different formats:

• Including only the interactions in the data plane:




IST-2006-034921 PUBLIC 19 / 70

Figure 3: C@R data plane

• Including both data an control plane interactions:

Figure 4: C@R control plane




IST-2006-034921 PUBLIC 20 / 70

3.3. C@R CWE PRACTICAL IMPLEMENTATION LEVEL SPECIFI CATION

Besides the two previous models, which describe the common architecture conceptual level and the software architecture model, a third description model specific for each real implementation or Rural Living Lab is still needed. In this third level, the practical implementation of CWE admin domains and sub-domains and the exact location of software components and existing interactions is described.

Therefore, Living Labs are expected to work in the practical implementation model of C@R CWE according to their specific requirements and use-cases or service-frameworks already defined.

In order to provide an example, the C@R Vertical Group has already provided a first draft of a practical implementation model for Cudillero Living Lab in Spain (see Figure 5).

Figure 5: Cudillero living lab example implementation




IST-2006-034921 PUBLIC 21 / 70

4. WEB SERVICE DESIGN METHODOLOGY

4.1. INTRODUCTION OF C@R WEB SERVICE DESIGN METHODOLOGY

As it is mentioned in D2.1.1 [2], the Bus is a key piece of the C@R architecture, and it should act as a resource broker, enabling the system to search for resources (Collaborative Core Services and Orchestration Capabilities) and managing their interconnection.

From the point of view of implementation, the Bus requires the establishment of information channels with the resources that it pretends to manage and interconnect.

After studying different interconnection methodologies, a design based on the web services (WS) technology had been concluded and, therefore, say that C@R implements a “Web Service design methodology” in the SW development of its CWE platform.

4.2. PROS AND CONS OF C@R WEB SERVICES

A Webservice is a process intercommunication method based on XML files exchange over HTTP channels. Therefore, Webservices include both data transportation and channel standards. Besides, a Webservice server is able to provide all necessary information (WSDL file) to enable the creation of clients, and thus fostering the development of completely new applications based on that resource.

Given the above definition, it seems quite straight Webservices mean an ideal mechanism to enable the intercommunication of C@R distributed SW processes (resources and control elements) related to the Control Plane as it was explained in D1.1.2 [27].

The main two advantages of using Webservices for C@R resources (CCS) and control elements (BUS) communication are the following:

• Webservices define an agnostic method with regard to Operating Systems, Programming Languages and transport layer.

• As Webservices are widely used nowadays by Internet based services, by using this methodology C@R ensures easy access to external resources and a standard way for C@R resources to be accessed to build new applications.

More advantages of using Webservices in C@R SW processes communication are:

• XML are human readable files or streams and hence easing debugging process.

• Encapsulation of resources within a Webservice allows the provider to publish the WDSL file and therefore all needed specifications to build new applications. As WSDL include the high level service specification (functions, arguments and data structures), developers do not need a specific and deep knowledge.

Some disadvantages of using Webservices are:

• Heavy protocol for light devices.

• A Webservice is designed as a “stateless machine” meaning that some kind of storage is needed to save the results of operations/changes performed by it.

As a conclusion, Webservices have been selected as the standard communication method of C@R platform resource management or signalling traffic.




IST-2006-034921 PUBLIC 22 / 70

On the other hand, for the resources data communication developers will be free to use other specific data pipes selecting suitable communication methods (TCP/IP, UDP/IP, HTTP, WebServices, raw IP sockets, RTP, raw multimedia streams, etc).

4.3. SPECIFICATION OF C@R WEB SERVICE DESIGN METHODOLOGY

C@R SW Processes to be interconnected with Webservices can be classified in:

• CCS: will encapsulate available resources to be shared in a CWE domain.

• Control Elements: grouped in the C@R BUS concept. The two main ones, as specified in the current architecture release, are the following:

• Registrar: is responsible for keeping a database of all components (CCS and OC) connected to the system. Furthermore it will implement search functionality, allowing any element to look for other elements (CCS, OC) connected to the platform.

• Connector: is responsible of the interconnection of components, managing the establishment, release and monitoring of connections among them.

As a result, the following steps of the platform methodology development have been proposed and completed:

1. Identification of control (BUS) elements –Connector and Registrar– and their specific management functionalities (functions, arguments, state diagrams, etc).

2. Specification of the Registrar and Connector engines including their Webservices to interface with CCS.

3. Identification and specification of CCS management API to enable C@R platform to register and track&support CCS interconnections. Specification of the necessary Webservices to be provided by the CCS.

4. Selection of a suitable tool to develop the Webservices: The BUS Webservices have been developed using AXIS2 Java version tool. CCS developers will use AXIS2 or any other tool, such as GSOAP, AXIS2 C version, .NET or .jsr172 specification for J2ME for Webservices development.

5. To ease the process of encapsulating resources in CCS, the platform development team have also provided a “CCS Generic Skeleton or Interface” implementing the necessary Webservices for control purposes. This way, developers can be focussed on the resource functionalities and the provided interface will dramatically reduce the integration learning curve.

6. Develop the BUS (control) components and “CCS Generic Skeleton”.

7. Encapsulate an example-resource as CCS and integrate it with the current BUS release.

8. Provide the necessary BUS and CCS APIs, CCS Skeleton/Interface and CCS resource-examples to allow C@R developers to encapsulate and integrate resources into C@R OSOA platform.

In order to continue the platform development, the following steps have been proposed:

1. Identify the functionalities that have to be embedded into the CCS’ Webservices, by reading the CCS API and the CCS’ Webservices’ Skeletons and the examples provided, and implement and deploy them by filling the TODO sections existing in the templates.




IST-2006-034921 PUBLIC 23 / 70

2. Identify the functionalities that have to be embedded into de CCS own code, by reading the CCS API and the CCS Skeleton/Interface and the examples provided, and implement them.

4.4. EXAMPLE OF A PRACTICAL IMPLEMENTATION OF C@R W EB SERVICE DESIGN METHODOLOGY

As practical demonstration of this paradigm, a SMS service had been implanted - in this case two CCSs (see Figure 6). The first CCS is a SMSC (Short Message Service Centre), and the second is a client capable of send SMS thorough the SMSC CCS.

It is important to have in mind that the SMSC is a true SMS centre managed by a mobile operator, the SMCC IS NOT IMPLEMENTED inside the CCS code.

The mission of the SMCC-CCS is not to deliver SMS but to act as a broker that informs and tracks to SMS-CCS clients about all information necessary to reach and use the SMSC.

C@R SMS-C

Parlay-X

SMPPProxy

MovilforumSMCC

SMCCSimulator

ExteriorWorld

Bluetooth link

IP li

nk

SMPP messages

Mobile network

Figure 6: SMSC used for testing at TID

4.4.1. Resource to be encapsulated (SMSC-CCS)

The following two resources have been encapsulated to build the SMS-C example.

• SMCC-CCS

Knowing that the SMSC is an external service provided by a mobile operator, the CCS will follow the “local tool” premises for integration of third party resources in C@R. In other words, this CCS only encapsulates the information needed to reach the SMCC.

• SMS-CCS




IST-2006-034921 PUBLIC 24 / 70

This CCS encapsulates a Parlay-X based SMS witch implements a SendSmsService client.

4.4.2. CCS specification (SMSC-CCS and SMS_Client-C CS)

4.4.2.1. CCSs ROLES

First to all, the roll of both CCS must be defined, the SMCC-CCS is a server CCS and OFFERS one or more services, the SMS_Client-CCS DEMANDS a service.

The CCS-Server role is responsible to provide information to the bus about itself, and its behavior is usually passive, this setup must be done configuring the data properties at the Registrar code of the CCS, (In this case the service is SMS, and the data channel is “ParlayX.SendSmsService”)

The CCS-Client role is active, is not merely a data table filling, and is running code performing actions of search and selection of protocols and data channels. These actions are enclosed at the connection section of the CCS.

Finally, the client CCS will demand a connection with the SERVER CCS, and the server CCS will accept or not the query, and will provide to the client side the necessary data to reach the SMCC.

4.4.2.2. SMCC-CCS SERVER FUNCTIONALITIES

The SMCC-CCS server has been configured to provide the following functionality:

• Provides a Webservice client to the Registrar interface to the bus

• Provides a Webservice interface to accept Connections request from the bus.

• Provides a Webservice interface to accept Specific-Services settings from the bus, (these settings are specific for the service configuration, a xml file witch contain only haves sense for the CCSs aware of a specific data channel protocol, for example, ip addresses, ports, keys, data api to use, etc. Note that the specific service settings are out of the bus scope).

• This CCS also contains and provide information of how to reach a SMSC center that provides two differents data protocols to send SMSs, one is Webservices based (OSA/Parlay-X) and the other is a binary based protocol to send SMSs over TCP (SMPP)

4.4.2.3. SMS-CCS CLIENT FUNCTIONALITIES

The SMCC-CCS has been configured to provide the following functionality:

• Provides a Webservice client to the Registrar interface to the bus

• Provides a Webservice client to request Connections to the bus.

• Provides a Webservice interface to accept Connections request from the bus.

• Haves a data channel client to access the Parlay-X interface of the SMCC.

4.4.3. Tasks to integrate SMSC-CCS and SMS-Client-C CS into the platform

This chapter will explain the necessary steps to integrate the two example components into the C@R platform.




IST-2006-034921 PUBLIC 25 / 70

4.4.3.1. SMCC-CCS

1. The first step was the recollection of information required from the SMS service centre provider (The explanation following parameters are specific for standard SMS protocols and are out of the scope of C@R documentation, please consult Parlay-X and SMPP protocols specifications from OSA/Parlay-X and GSM organizations):

• Parlay-X interface: URL for Parlay-X SendSmsService WS

• SMPP interface: IP and port for SMPP server, R_TON, R_NPI, O_TON, O_NPI, originator address, user and password.

2. With the above information a xml file was generated for specific CCS options and installed in the SpecificOptions Webservice at the CCS WS server side. (One file for Parlay-X and other for SMPP)

3. The CCS skeleton code was modified to provide Registration information, stating:

• The service provided by this CCS: “SMS”

• The data channels (or protocols provided): “SMPP,Parlay-X.SendSmsService”

4. Compiled and installed

That’s all, note that the CCS doesn’t implement SMCC functions at, only provides information to the system. This is because has been implemented using the “local tools” premises, the SMCC is not conscious about that it is now a CCS.

4.4.3.2. SMCC-CLIENT

In order to test the SMS, a simple Parlay-X client CCS has been implemented.

1. The CCS skeleton code has been modified to provide Registration information and a search criteria for ask to the bus for a Parlay-X SMS service:

• Ask the bus for candidates for SMS service: “SMS”

• Select one with a Parlay-X interface: “Parlay-X.SendSmsService”

2. A simple Parlay-X client has been implemented

3. A simple CLI to operate the SMS has been implemented

In this case, the CCS have, not only a informational role, also contains true working functions, (the Parlay-X client).

4.4.4. CCS interactions (SMSC-CCS and SMS_Client-CC S)

Figure 7 depicts the interactions taking place between the SMS CCS client and the bus:

1. The SMCC-CCS launch a registration request and goes to sleep until its services are required.

2. This CCS, after registration will ask the bus for a CCS capable to send SMS.

3. The bus will return a list of registered SMCC-CCS candidates, and then the CCS will search into the list, for one that haves a Parlay-X interface.

4. If the search succeeds, the CCS will ask the bus for connect with the candidate. After that the CCS will ask to the SMCC-CCS for specific connections setting.




IST-2006-034921 PUBLIC 26 / 70

Data flow (CCS SMS-CLIENT)RegistrarRegistration

CCS_ID: NAVASLABS_SMS_CLIENT_V0100 CCS_ID:NAVASLABS_SMS_CLIENT_V0100

registered

Query

Ack

tryConnectionfor

SMS CCS erverQuery

Ack

Connection ID = X

Parlay-X at URI =

http…

Suitable CCS encountered

CCS informed of Parlay-X URI,Ready to accept and

deliver SMSs

CCS MEDIA BUS

Figure 7: Interactions between SMS CCS client and the bus




IST-2006-034921 PUBLIC 27 / 70

5. SEMANTIC WEB USAGE

The main component of the Semantic Web [24] is the information itself and the transfer of this information between different systems. Web applications contain content like images or simple text. Human beings are able to understand the meaning of the text because they are able to read and interpret the words. However a computer couldn’t understand the meaning of a text or an image yet. To enrich the computer by the ability to understand the meaning of texts or images too the Semantic Web introduced semantic technologies like ontologies and taxonomies. These technologies try to structure the web and the comprising content to make it machine-understandable. One can say that the Semantic Web enriches the “old” web by the ability to understand itself to enable a knowledge-based web that provides a new level of services (see Delivarable “D2.1.2 Ontologies for rural activities” [13]).

The Semantic Web provides a common framework that allows data to be shared and reused across application, enterprise, and community (living lab) boundaries. It is a web of data. The benefit of using the semantic web within the C@R project is the ability to share and reuse data amongst different living labs. Currently each living lab produces, collects and processes data within their living lab specific applications. The problem is that this data is controlled by those applications, and each application keeps it to itself. The result is that the data is only available and useful within the individual living lab boundaries – no reusability possible.

The Semantic Web is about two things. It is about common formats for integration and combination of data drawn from diverse sources, where on the original Web mainly concentrated on the interchange of documents. It is also about language for recording how the data relates to real world objects. That allows a person, or a machine, to start off in one database, and then move through an unending set of databases which are connected not by wires but by being about the same thing [19].

The meaning, architecture and usage of the semantic web in the three C@R layers has been described in detail in the deliverable D2.1.2 [13]. Each RLL in the C@R architecture profits from the semantic layer in individual ways. After the theoretical basics and examples the real implementation in the living labs is the next step towards the real applications. This chapter will describe a possible step by step guideline of how to develop the semantic web layer in the individual RLL.

A big difference of the usage of the semantic web layer in the C@R architecture compared with other research projects is that we don’t use every possible technical solution to build a big and complex semantic layer. C@R concentrates on the least possible solution. That leads to a small and easy to implement but still effective additional layer in the C@R architecture. C@R implements the semantic web because of it’s benefits and not mainly to research on new complex semantic web components.

With this simplistic approach in mind the development of the semantic layer leads to an immediately advantage with less efforts. Since the hardware and infrastructure in rural areas is really low this approach also copes with these limitations by only using as less as necessary components in the applications. A complete semantic layer with all features wouldn’t be effective in the rural environments and thus doesn’t fit into the C@R approach of an architecture for rural areas.

5.1. WHY USING THE SEMANTIC WEB APPROACH IN C@R

The semantic web extends the principles of the web from the web of documents to a web of data. This will allow to fulfill more of the web’s potential. It will allow data to be shared effectively by the different living labs and to be processed automatically by tools as well as manually. The semantic web allows two things:

• It allows data to be surfaced in the form of real data, so that a program doesn’t have to strip the formatting and pictures and ads off a Web page and guess where the data on it is.




IST-2006-034921 PUBLIC 28 / 70

• It allows people to write (or generate) files which explain - to a machine - the relationship between different sets of data. For example, one is able to make a “semantic link” between a database with a “zip-code” column and a form with a “zip” field that they actually mean the same – they are the same abstract concept. This allows machines to follow links and hence automatically integrate data from many different sources.

Some examples of the usage of semantic web technologies are in the area of:

• Data integration: Data in various locations (individual living labs) and various formats (living lab specific format) can be integrated in one, seamless application.

• Resource discovery and classification: To provide better, domain specific search engine capabilities. The living labs can use this functionality to provide the end user a powerful search engine.

• Cataloging: Describing the content and the content relationships available at a particular web site, page or digital library by intelligent software agents to facilitate knowledge sharing and exchange in the living lab and between different living labs.

• Content rating: Describing collections of pages that represent a single logical “document”

The examples draw clear benefits using the semantic web approach in the C@R project since C@R is going to build collaborative working environments. The semantic web supports this task by providing a framework to realize the collaborative usage of existing information in the individual living labs.

5.2. STEP BY STEP TO THE SEMANTIC WEB

There are some steps that need to be discussed on the way towards the semantic web development. The first and most important step is to ask why to use the semantic web. This question was discussed in D2.1.2 [13] in a general way. The following chapter will discuss this question in more detail especially regarding ontology usage.

5.2.1. Why using ontologies?

This question should be the first one before starting developing the ontologies. This question is not always asked because ontologies have become common on the World-Wide Web. The ontologies in the web range from really large taxonomies categorizing websites (e.g. Yahoo!) to categorizations of products for sale and their features (e.g. Amazon). Using ontologies seems to be a normal process when developing a new application, especially in the context of a research project. But ontologies are not always the best way to solve a problem. Ontologies are often used because it’s an exciting new buzzword like Web 2.0.

The C@R project concentrates on the above mentioned simplistic approach and has to solve this question before starting development in an area that is not really necessary to create the user centric applications for rural areas.

Why using/develop an ontology? Some of the reasons are:

Ontologies define the concepts and relationships used to describe and represent an area of knowledge. Ontologies are used to classify the terms used in a particular application, characterize possible relationships, and define possible constraints on using those relationships. In practice, ontologies can be very complex (with several thousands of terms) or very simple (describing one or two concepts only).

An example for the role of ontologies or rules on the Semantic Web is to help data integration when, for example, ambiguities may exist on the terms used in the different data sets, or when a bit of extra knowledge may lead to the discovery of new relationships.




IST-2006-034921 PUBLIC 29 / 70

A general example may help. A bookseller may want to integrate data coming from different publishers. The data can be imported into a common RDF model, e.g., by using converters to the publishers’ databases. However, one database may use the term “author”, whereas the other may use the term “creator”. To make the integration complete, and extra “glue” should be added to the RDF data, describing the fact that the relationship described as “author” is the same as “creator”. This extra piece of information is, in fact, an ontology, albeit an extremely simple one.

Languages like RDF Schemas and various variants of OWL provide languages to express ontologies in the Semantic Web context. These are stable specifications, published in 2004.

The following information is based on the documentation available at: http://protege.stanford.edu/publications/ontology_development/ontology101-noy-mcguinness.html

Share common understanding of the structure of information among the different RLLs

For example, suppose several different RLLs contain location information or make use of a product catalogue. If these RLLs share and publish the same underlying ontology of the terms they all use, then computer agents can extract and aggregate information from these different RLLs. The agents can use this aggregated information to answer user queries or use it as input data to other applications.

Enable reuse of domain knowledge

For example, models for many different domains (different RLLs) need to represent the notion of time. This representation includes the notions of time intervals, points in time, relative measures of time, and so on. If one group of researchers develops such an ontology in detail, others can simply reuse it for their domains. Additionally, if we need to build a large ontology, we can integrate several existing ontologies describing portions of the large domain. We can also reuse a general ontology, such as the UNSPSC ontology, and extend it to describe our domain of interest.

Make domain assumptions explicit

Making explicit domain assumptions underlying an implementation makes it possible to change these assumptions easily if the knowledge about the domain changes. Hard-coded assumptions using programming-language code makes these assumptions not only hard to find and understand but also hard to change, in particular for someone without programming expertise. In addition, explicit specifications of domain knowledge are useful for new users who must learn what terms in the domain mean.

Separating the domain knowledge from the operational knowledge

For example, we can describe a task of configuring a product from its components according to a required specification and implement a program that does this configuration independent of the products and components themselves. Then an ontology could be developed that contains PC-components and characteristics and applies an algorithm to configure made-to-order PCs. The same algorithm then can be used to configure cars just by “feeding” a car component ontology to it.

Analyzing domain knowledge

This is possible once a declarative specification of the terms is available. Formal analysis of terms is extremely valuable when both attempting to reuse existing ontologies and extending them.

An ontology defines a common vocabulary for researchers who need to share information in a domain. It includes machine-interpretable definitions of basic concepts in the domain and relations among them. If this is what is needed in the to be developed application and if the above mentioned reasons make sense in the context of the specific development, then an ontology makes sense.

An ontology of a domain often is not a goal in itself. Developing an ontology is similar to defining a set of data and their structure for other programs to use. Problem-solving methods, domain-independent applications, and software agents use ontologies and knowledge bases built from ontologies as data.




IST-2006-034921 PUBLIC 30 / 70

5.2.2. Existing and reusable ontologies?

Before developing own ontologies one should search for existing ones. There are several portals that enable search for existing ontologies. One good example is SchemaWeb [20]. Another one is PingTheSemanticWeb [21], which collects information about new RDF documents on the web using pings sent by applications generating data and on RDF autodiscovery links found by people browsing the Web. There is also a search engine available – Swoogle [22] – which is specialized on searching semantic web documents.

Important communities developing ontologies that are broadly accepted and used are:

• FOAF [23]: a project to describe information about people and their social relations

• SIOC [24]: a project to describe information about online community sites (blogs, bulletin boards, …) and use this information to connect these sites together

• Linking open data on the semantic web [25]: is project whose goal is to make various open data sources available on the Web as RDF and to set RDF links between data items from different data sources

These are examples of ontologies that can support the collaborative working environments in the C@R living labs. They help to connect the individual information available in the living labs to all other C@R living labs. They enable the reusability of existing information across living lab borders.

5.2.3. How to develop the ontology

See http://protege.stanford.edu/publications/ontology_development/ontology101-noy-mcguinness.html

An ontology could be developed in many different ways. There is no one correct way or methodology to do that. This chapter will discuss general issues to consider and offer one possible step by step process for developing an ontology.

Some basic rules in ontology design will arise all the time during the development process:

• There is no one correct way to model a domain. There are always a lot of different approaches to do that. The best solution almost always depends on the later application that makes use of the ontology and which extensions will be added to the ontology.

• The ontology development is an iterative process. Starting with a rough ontology and refine the evolving ontology and fill in the details.

• The concepts described in the ontology should be close to the physical or logical objects and relationships in the domain of interest.

In the beginning it is important to know what the ontology is going to be used for and how detailed or general the ontology will be. That will guide many of the modeling decisions during the ontology development. Also important is to keep in mind which ontology structure will work better for the specific task, be more intuitive, more extensible and more maintainable. The ontology also needs to be a model of reality of the world and the concepts in the ontology must reflect this reality.

After the definition of a first version of the ontology, it should be evaluated in example applications and tested by domain experts. This will lead to a revision of the ontology. This process of iterative design will likely continue through the entire lifecycle of the ontology.

The following seven steps are just an example approach of how to develop an ontology.

Step 1 - Determine the domain and scope of the ontology

In the beginning of the ontology development several questions should be answered.




IST-2006-034921 PUBLIC 31 / 70

• What is the domain the ontology will cover?

• For what will the ontology be used?

• What are the questions the information in the ontology should provide answers?

• Who will use and maintain the ontology?

The answers given to this questions my change during the development process of the ontology but they might help to limit the scope of the model.

If for example the ontology would be a product catalogue ontology it will represent any kind of products (food, clothing, accommodations, …). This ontology will be used for applications that allow a customer to browse and order products. If the ontology should be used for natural-language search it also should include synonyms for concepts in the ontology. If it should be possible to fill the ontology with values using another structure to describe the products a mapping between the languages should be provided.

A good way to determine the scope of the ontology is to sketch a list of questions that a knowledge base based on the ontology should be able to answer. These questions later also could be used to test the ontology. In the product catalogue ontology the following questions might be answered:

• Which shop provides a product in a specific size/color/made/…?

• Which shop provides the cheapest product?

• How much does a specific product cost?

• What are alternative products?

• What else products are provided by this shop?

• Where is the next shop in my nearby area?

• Who is the owner of the shop? (might be better in a separate ontology)

• Where is the location of the shop? (might be better in a separate ontology)

Based on this list of questions the necessary information that should be in the ontology could be determined.

Step 2 - Consider reusing existing ontologies

Before developing a new ontology regarding a specific issue it is almost always worth considering what someone else has done and checking if existing sources can be refined and extended for the particular domain and task. Reusing existing ontologies may be a requirement if our system needs to interact with other applications that have already committed to particular ontologies or controlled vocabularies. Many ontologies regarding a lot of different issues are already available in electronic form. These ontologies can be imported, or if necessary first translated into the appropriate format, into the knowledge-representation system (e.g. Protégé). There are libraries of reusable ontologies on the Web and in the literature. For example, we can use the Ontolingua ontology library (http://www.ksl.stanford.edu/software/ontolingua/) or the DAML ontology library (http://www.daml.org/ontologies/). There are also a number of publicly available commercial ontologies (e.g., UNSPSC (www.unspsc.org), RosettaNet (www.rosettanet.org), DMOZ (www.dmoz.org)).

Step 3 - Enumerate important terms in the ontology

To get an overview of what the ontology will be about it is useful to write down a list of all terms that should be used to make statements about or to explain to a user. What are the terms we would like to talk about? What properties do those terms have? What would we like to say about those terms?

For example, product related terms in the case of clothing will include price, size, color, brand; in the case of food will include price, brand, quantity; in the case of an accommodation will include




IST-2006-034921 PUBLIC 32 / 70

price, location, rooms, beds, breakfast and so on. In the beginning it is important to get a comprehensive list of terms without worrying about overlap between concepts they represent, relations among the terms, or any properties that the concepts may have, or whether the concepts are classes or slots.

The following two steps, developing the class hierarchy and defining properties of concepts (slots), are closely intertwined. There is no one correct way of doing one of them first and then doing the other. A typical approach is to create a few definitions of the concepts in the hierarchy and then continue by describing properties of these concepts and so on. These two steps are the most important steps in the ontology-design process.

Step 4 - Define the classes and the class hierarchy

There are several possible approaches in developing a class hierarchy [4]:

• A top-down development process starts with the definition of the most general concepts in the domain and subsequent specialization of the concepts. For example, starting with creating classes for the general concepts of products and then specialize the product class by creating some of its subclasses: nourishment, clothing, accommodation, taxi. These subclasses than could be further categorized. For example the clothing subclass could be categorized into shirt, trousers, pullover, shoes, socks, and so on.

• A bottom-up development process starts with the definition of the most specific classes, the leaves of the hierarchy, with subsequent grouping of these classes into more general concepts. For example, starting with defining classes for Cola and Salt. The next step then is to create a common superclass – nourishment.

• A combination development process is a combination of the top-down and bottom-up approaches: We define the more salient concepts first and then generalize and specialize them appropriately. For example starting with a few top-level concepts such as nourishment and a few specific concepts, such as Cola and Milk. These concepts than could be related to a middle-level concept such as beverage.

It depends on the developer which of these three methods is the better choice. If a developer has a systematic top-down view of the domain, then it may be easier to use the top-down approach. The combination approach is often the easiest for many ontology developers, since the concepts “in the middle” tend to be the more descriptive concepts in the domain.

Regardless which approach will be used, it begins with the definition of classes. Based on the list created in step 3 development begins with selecting the terms that describe objects having independent existence rather than terms that describe these objects. These terms will be classes in the ontology and will become anchors in the class hierarchy. The classes will be organized into a hierarchical taxonomy by asking if by being an instance of one class, the object will necessarily (i.e., by definition) be an instance of some other class.

If a class A is a superclass of class B, then every instance of B is also an instance of A. In other words, the class B represents a concept that is a “kind of” A. For example, every bottle of Cola is necessarily a beverage. Therefore the Cola class is a subclass of the beverage class.

Step 5 - Define the properties of classes (slots)

The classes alone will not provide enough information to answer the competency questions from Step 1. Once there have been defined some of the classes, the internal structure of concepts needs to be described. On the basis of the list created in step 3 in step 4 the classes have been created. Most of the remaining term of the list created in step 3 are likely to be properties of these classes. These terms include for example, price, quantity and availability of a Cola.




IST-2006-034921 PUBLIC 33 / 70

Each property must be assigned to a class that should be described by it. The properties become slots attached to classes. Thus, the beverage class will have the following slots: price, quantity and availability.

In general, there are several types of object properties that can become slots in an ontology:

• “intrinsic” properties such as the likeability of a shoe;

• “extrinsic” properties such as a shoe’s name and what brand it is;

• relationships to other individuals; these are the relationships between individual members of the class and other items (e.g., the manufacturer of a shoe, representing a relationship between a shoe and the manufacturer.)

All subclasses of a class inherit the slot of that class. For example, all the slots of the class shoe will be inherited to all subclasses of shoe, including sport shoes and worker shoes.

A slot should be attached at the most general class that can have that property. For instance, size and price of a shoe should be attached at the class clothing, since it is the most general class whose instances will have price and size.

Step 6 - Define the facets of the slots

Slots can have different facets describing the value type, allowed values, the number of the values (cardinality), and other features of the values the slot can take. For example, the value of a name slot (as in “the name of a shoe”) is one string. That is, name is a slot with value type String. A slot produces (as in “shoe manufacturer produces shoes”) can have multiple values and the values are instances of the class shoe. That is, produces is a slot with value type Instance with shoe as allowed class.

When defining a slot several things need to be taken into account:

• Slot cardinality defines how many values a slot can have. Some systems distinguish only between single cardinality (allowing at most one value) and multiple cardinality (allowing any number of values). A size of a shoe will be a single cardinality slot (a shoe can have only one size). Shoes produced by a particular shoe manufacturer fill in a multiple-cardinality slot produces for a Manufacturer class. Some systems allow specification of a minimum and maximum cardinality to describe the number of slot values more precisely. Minimum cardinality of N means that a slot must have at least N values.

• Slot-value type describes what types of values can fill in the slot. Here is a list of the more common value types:

o String is the simplest value type which is used for slots such as name: the value is a simple string

o Number (sometimes more specific value types of Float and Integer are used) describes slots with numeric values. For example, a price of a shoe can have a value type Float

o Boolean slots are simple yes–no flags.

o Enumerated slots specify a list of specific allowed values for the slot.

o Instance-type slots allow definition of relationships between individuals. Slots with value type Instance must also define a list of allowed classes from which the instances can come.

• Domain and range of a slot. Allowed classes for slots of type Instance are often called a range of a slot. The classes to which a slot is attached or classes which property a slot describes, are called the domain of the slot. In the systems where we attach slots to classes, the classes to which the slot is attached usually constitute the domain of that slot. There is no need to specify the domain separately.




IST-2006-034921 PUBLIC 34 / 70

Step 7 - Create instances

The last step in the ontology development process is creating individual instances of the classes in the hierarchy. This process can be divided into the following steps:

1. Choosing a class

2. Creating an individual instance of that class

3. Filling in the slot values.

5.2.4. Rules

Rules reside on top of the Semantic Web stack (see Figure 8) and offer users the ability to express certain logical relationships in a form suitable for machine processing. Within the C@R project rules may be used to process the information recorded and stored in the ontologies. Rules are already explained in more detail in deliverable D2.1.2 [13].

Unicode URI

XML + XML Namespaces + XML Schema

RDF + RDF Schema

OWL

Rules

Figure 8: Semantic web stack

The term “rules” in the context of the Semantic Web refers to elements of logic programming and rule based systems bound to semantic web data. Rules offer a way to express, e.g., constraints on relationships defined by RDF, or might be used to discover new, implicit relationships.

Various rule systems (production rules, Prolog-like systems, etc) are very different from one another, and it is not possible to define one rule language to encompass them all. However, it is possible to define a “core” that is essentially understood by all rule systems. This core is based on restricted kind of rule, called a “Horn” rule, which (like most rules) has the form “if conditions then consequence”, but it places certain restrictions on the kinds of conditions and consequences that can be used.

A simple example might help to explain the rules usage. During the integration of data coming from different sources, the data may include references to persons, their name, addresses, email, homepage, etc. However, the data does not say when two persons should be considered as identical, although this is very important for a full integration. This could be expressed by an extra condition stating that “if two persons have the same name, homepage, and email, then they are identical”. Such conditions can be expressed with rules.

The benefit of using rules on top of ontologies is that the information stored in the ontologies could be processed in an easy to understand way. Easy means compared with the program-language alternative of programming rules as if-else statements.




IST-2006-034921 PUBLIC 35 / 70

Developing is the next step after the ontologies have been finished. On basis of the information stored in the ontologies the rules are used to define how to react on specific situations in which way. For example, if a user is browsing the product catalogue ontology and wants to order new shoes rules might be executed to:

• Check if user has a valid credit card

• Check if the user has the access rights to order

• Check if product is available

• Find the nearest shop that provides the shoes

• and so on

These rules can be modelled with the same tools as the ontologies have been developed (e.g. Protégé). In the same way as in the case of ontologies it makes sense first to check if others already developed rules regarding a specific issue before developing them from scratch.

After the ontologies and rules have been developed the next step is to establish a connection between the ontologies and rules and the accessing application that processes these information.

5.2.5. Access ontologies and rules out of an applic ation

If developing an application that is going to use the information stored in ontologies and that should process the information using the rules this application needs an interface to access the semantic components. One prominent example is the Jena (http://jena.sourceforge.net/) semantic web framework for Java. Jena could be used to access the information in the ontologies and also alter the ontology. Jena provides a programmatic environment for RDF, RDFS and OWL, SPARQL and includes a rule-based inference engine. The rules developed (e.g. with Protégé) can be processed using Jena. SWRL rules are ultimately represented as OWL individuals contained in OWL ontologies, which are typically saved as OWL/RDF files. Third party software can work directly with the rules described in these files. One minor caveat is that Protege-OWL uses the Jena parser library to generate these files, so parsing can be difficult - though not impossible - with normal XML parsers. Jena can always be used, however, to parse these files in Java applications. There are a lot of other tools to work with RDF and OWL data (see http://esw.w3.org/topic/SemanticWebTools).




IST-2006-034921 PUBLIC 36 / 70

6. WEB 2.0 USAGE

In spring 2004 the term Web 2.0 was born and initiated a new generation of the web. However Web 2.0 isn’t neither a new kind of software nor a technological change of the hardware of the web. The term Web 2.0 rather stands for a collection of new methodologies of human-computer interaction. It describes the passage from the formerly static web sites to dynamic, human centric interacting applications. There are a lot of different opinions on what Web 2.0 exactly means depending on the view. The one is that Web 2.0 stands for a new kind of collaborative applications that allow users to contribute to a common knowledge base. These applications inspire the user to interact with the system and to collaborate with others to build a network of common interest and knowledge. In C@R that means that for example different groups of distributed users collaborate regarding a specific issue – Farmers could help each other by providing information that is also interesting for the others.

Another point of view on Web 2.0 is the more technical backend functionality like UI capabilities and asynchronous calls. With regards to the UI capabilities Web 2.0 is the basis for enhanced user centric UIs. That means that the technology enables the realization of easy to understand and to use UIs which is an important factor in rural areas with users having almost no IT experience. The communication capabilities of Web 2.0 provide functionalities to minimize client-server communication which is also important regarding the bandwidth limitation in rural areas. Web 2.0 also provides functionalities to cope with the problem of occasionally disconnection.

6.1. WEB 2.0 INTEGRATION

This chapter will address the usage of Web 2.0 in the C@R architecture and provides some example applications that might be used in the RLL applications.

6.1.1. Collaborative Web 2.0 tools

Examples for collaborative tools with regards to Web 2.0 are Podcasts, RSS feeds, Mashups, Weblogs, Wikis as well as social networks like XING and applications that are collecting information regarding a specific issue like flick (images) or delicious (bookmarks). Each of these applications enables the connection of different users into a collective system that collects and provides information. Each user could provide information to the collective as well as filter the existing information regarding his needs. Because of the strong linkage between the different applications a huge collective arises that builds a common knowledge base. In the following possible usage of Web 2.0 tools will be discussed.

Wiki

Ths collaborative tool might be used in C@R to build a common knowledge base regarding specific issues like for example:

• Farmers using a common Wiki to provide information about weather, crop, pricing and other important information in this area. Each farmer could contribute to the system and profit from the contributions from other farmers.

• Infopreneurs and Spaza shop owners could use a common Wiki to inform each other about pricing, stock issues, road condition or common practices. Especially the common practices and problem solving would be important for the infopreneurs to be able to solve problems on their own.

The concept of the above mentioned two examples could be mapped onto many other use cases. Wikis are a very effective Web 2.0 tool to connect people together and profit from their knowledge. To find the most appropriate Wiki for a specific usage the following two pages might help to decide




IST-2006-034921 PUBLIC 37 / 70

• http://www.wikimatrix.org

• http://moinmoin.wikiwikiweb.de/WikiEngineComparison

Podcast

In rural areas with illiterate users Podcasts could be utilized. Regardless the illiteracy the user still could provide and exchange information with the community. In the Sekhukhune living lab for example Podcasts might be an appropriate communication and knowledge sharing channel everybody (also illiterate users) could use and understand. A Podcast is a media file (audio or video) that could be consumed regardless a broadcasting time – Audio/Video on demand. A video Podcast could be used to explain a complex process much easier that a text document. The easiest way to create a simple Podcast is to create an mp3 audio file of the content you want to provide and writing an xml file that indicates things like the author, content, copyright and so on. Putting these two things on a server enables other users to play your Podcast by using a RSS-reader or an already RSS enabled browser. A more comfortable way to create Podcasts is using a producer tool (Podcast Producer). Two example tools are:

• CastBlaster – http://www.castblaster.com (Windows)

• Podcastmaker - http://www.potionfactory.com (Mac)

Mashup

From a technological point of view a mashup is a web application combining data and applications from more than one source into a single integrated tool. One of the most prominent examples of a mashup is google maps. It combines cartographic data with location information. Google maps itself could also be used as one part of a mashup. In C@R mashups might be used for example:

• Using one of the above mentioned wiki engines to build a wiki page for a specific user group – e.g. Infopreneurs. The wiki then for example could contain all participating Infopreneurs and Spaza shop owners. Including google maps into this wiki and connect it with the location information of Infopreneurs and Spaza shop owners enables the graphical representation of the participants in a map. Another mashup that could integrate into this example would be the integration of a chat application to enable a immediate conversation to the participants.

Mashups are mainly based on existing applications which means that it enables a easy and very fast design of a collaborative tool by combining existing tools into one tool.

C@R collaboration tools

In the C@R project tools will be developed that also enable collaboration in the sense of Web 2.0. An example is the GIS application used in the Sekhukhune RLL to combine information from different data sources into one integrated tool (see Figure 9). It combines cartographic information coming from aerial photos, GPS information from end user devices and business data from order system. All these different data sources are combined into one tool that simplifies the handling of the complex data. Other data sources or tools could be added to this tool to enhance the functionality. For example integrate a messaging or chat application to enable communication by clicking on a spaza shop in the map. Another mashup might be the integration of a route planner to calculate the optimal route between two spaza shops on the map.

The data that is utilized to form the collaborative tools in C@R is created and maintained by different RLLs. The GIS application for example might also integrate geospatial data from the Czech RLL to display agricultural information. Information from the fishery use case from Cudillero might be used to display fish occurrence on the map to support the fisher. Since the C@R applications are build on open standards data from the different RLLs could be easily used and integrated.




IST-2006-034921 PUBLIC 38 / 70

Figure 9: GIS application used in the Sekhukhune RLL

The benefit of using Web 2.0 collaborative tools is that only the relevant information is stored and used in these tools. Since the end user is the person who adds the information he knows exactly his needs and what information might be of interest for the others. This concept of the interactive user also decreases the maintenance effort to add the information into the application. No additional person is necessary to do that work, it’s done by the users itself. Another benefit is that incorrect information is detected and corrected immediately by the users because they have the editing rights. An example for this is wikipedia. Web 2.0 provides a perfect concept for the usage in RLLs to connect the participants together and to build a collaborative/collective knowledge base to support the end user in their daily work.

6.1.2. Web 2.0 backend functionality

This chapter will discuss the backend functionality of Web 2.0. Like mentioned earlier Web 2.0 is not just a concept for a collaborative internet. The definition also contains specific technologies that are important and useful to solve several problems RLLs face in rural areas. In chapter 6.2 some examples will be given how Web 2.0 and specifically AJAX helps to cope with RLL specific problems like erratic connectivity, offline workers or low bandwidth. The main technology behind Web 2.0 is AJAX (Asynchronous JavaScript and XML). AJAX describes a method for asynchronous data transfer between client and server. Like Web 2.0 AJAX is also not a new technology but a collection of well known technologies. The term AJAX was formed by Jesse James Garrett in the article [5] :

„AJAX isn´t a technology. It´s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:




IST-2006-034921 PUBLIC 39 / 70

o standards-based presentation usin XHTML and CSS; o dynamic display and interaction using the Document Object Model; o data interchange and manipulation using XML and XSLT; o asynchronous data retrieval using XMLHttpRequest; o and JavaScript binding everything together.

AJAX enables the asynchronous transport of XML- and text-documents between client and server. Static HTML-pages need to refresh the entire page if something changes. With AJAX only that part of a web page needs to be refreshed if it changes. That reduces the client-server communication a lot and accelerates the application. The technical realization of that concept is based on the XMLHttpRequest object. This object offers additional HTTP-functionality for data transfer between client and server. Figure 10 depicts the difference between the static model of web page design and the AJAX model. In the AJAX web application model a AJAX engine acts as a intermediate on client side. The AJAX engine handles the requests and creates the response in the appropriate format. The AJAX engine works asynchronous. Classic web applications are blocked as long as all requested data arrived on client side. In the AJAX model the application is independent to the data acquisition and thus is never blocked.

Figure 10: Classic web model compared with the AJAS model

The XMLHttpRequest object exists since Internet Explorer 5.0 as an ActiveX-object. Today all current browsers support the XMLHttpRequest object but sometimes interpreted in slightly different way what leads to a browser dependent implementation. To cope with the implementation problems and to create maintainable and efficient applications several AJAX frameworks are available.




IST-2006-034921 PUBLIC 40 / 70

AJAX frameworks

The advantage of using AJAX frameworks is that the code is maintainable, efficient, well documented, reusable and based on standards. If necessary AJAX applications could also be build from scratch but with the loss of the knowledge and know-how contained in the AJAX framework.

There are a lot of different AJAX-frameworks available regarding the individual use case. The first decision is if it should be a client-, server- or combi-framework. Figure 11 depicts the different types of AJAX frameworks.

Figure 11: AJAX frameworks

Client Framework: Can be distinguished into basic- and application frameworks.

Basic Framework: Contains just rudimentary AJAX functionality like the asynchronous communication and XML handling. The most prominent basic framework is prototype [6]. Prototype is the basis AJAX implementation for a lot of more complex frameworks.

Application Framework: Build on the basic framework the application framework (sometimes also called Toolkit) provides additional functionality to support the AJAX development. An important part of this additional functionality are UI elements, so called widgets. One of the most prominent application frameworks is Script.aculo.us [7]. It also builds upon prototype and includes a lot of visual effects and widgets. Other application frameworks are Moo.FX [8], MochiKit [9], Dojo [10] and Google Web Toolkit [11].

Server Framework: Enable the access to existing functionality via AJAX. They act as a interface between the server side programming language chosen by the developer and the AJAX implementation on client side realized with JavaScript.

For example: Existing functionality implemented with PHP or Java on server side can be asynchronously called via AJAX using a server framework.

Server frameworks are available for almost every programming language today (see http://ajaxpatterns.org/Ajax_Frameworks).

Combi framework: A Combi framework is the combination of client framework and server framework. The advantage of a combi framework is the interoperability and perfect working communication between client and server implementation. The most prominent combi framework is Atlas [12]. On client side several JavaScript modules provide their AJAX functionality. Atlas




IST-2006-034921 PUBLIC 41 / 70

applications can be developed completely with “Visual Studio” which is a big advantage. Having a common development environment for client and server side simplifies development.

6.2. METHODOLOGY OF DESIGNING THE WEB 2.0

This chapter will focus on the technological side of Web 2.0. Especially in rural areas there are a lot of infrastructural impediments the applications need to cope with. Problems like less computer literacy, low bandwidth and erratic connectivity need to be solved before the collaborative tools could be utilized. Web 2.0 has the capabilities to design the applications in a way that they can handle all these problems in a way that wasn’t possible without Web 2.0 technologies. In the following some of the problems RLLs face in the rural areas will be discussed and possible solutions will be proposed.

Less computer literacy - Enhance UI with visual effects and easy to use/understand design

The end users in rural areas mostly have less or no computer experience. To build the applications in a user centric way they need to be easy to understand and easy to use. Web 2.0 offers visual effects that can be used to create a UI that is as easy to use as a desktop application. Visual effects like drag&drop are much more intuitive than mark an element and pressing delete button. A lot of this UI behavior is already included in the AJAX frameworks mentioned above. Integrating the Web 2.0 functionality into a web page is really easy done by including the AJAX framework (including a JavaScript library in the header of the HTML page) and annotating the involved UI elements. An example what is possible using Web 2.0 could be tested at http://demo.eyeos.org/ and http://script.aculo.us/.

Because of the simplified UI the user will accept the application and will use it. If the UI is too complex and not easy to use, the user wouldn’t use it regardless the functionality. The visual effects will still run on low end machines and there is no client-server communication necessary to realize them.

Less computer literacy – Adaptive application

Another way to cope with the less computer literacy of users is to support them during the application usage. That could be realized by the help of an adaptive hypermedia system (AHS). An AHS reacts on the user behaviour by adapting itself to each user individual. An AHS creates a user model that is permanently adapted regarding the user behaviour to adapt for example the navigation or page content to the user knowledge and aims. AHSs enable a web that tries to adapt itself as good as possible to the user needs. That means the evolution of the web leads away from the “one-size-fits-all” methodology (static web that provides the same UI to each user) towards an adaptive user centric web.

The following list shows possible adaptations realized by the AHS:

• Sort, group, hide, annotate, highlight links

• Create new links on the basis of previously visited pages

• Create new links which connect often visited links

• Hide, shift, change size of layout elements

• Change, hide, highlight content

• Different levels of detail: e.g. replace technical terms within a text if the user isn’t familiar with the topic

An AHS consists of four main components: the presentation layer, an adaption model, a user model and a domain model (see Figure 12).




IST-2006-034921 PUBLIC 42 / 70

Adaption Model

Presentation Layer

DomainModel

UserModel

Figure 12: Components of an adaptive hypermedia system

• Presentation Layer: adaptive user interface

• Adaption Model: adaptation rules represented as semantic rules (ontology)

• Domain Model: the domain represented as concepts (ontology)

• User Model: user data represented as concepts (ontology)

The Domain Model represents the application domain (e.g. website) as concepts. The appropriate representation would be an ontology. Each element within the domain (images, texts, links, forms…) will be represented as a owl-concept within the ontology. That means that the domain model ontology is the semantic representation of the domain. The ontology enables a hierarchical structure of the elements and they can be referenced to each other.

The User Model represents the individual user in an ontology. Information about the user like skills, interests, aims and motivation will be stored in the user model ontology. The user model ontology links the individual physical user with the domain model ontology. Example usage: Each user interaction is recorded within the user model ontology. That allows to determine which links (described as a concept within the domain model ontology) have been already visited by the user and thus to check the interests of the user.

The Adaption Model describes the rules which set how the AHS will realize the adaption. The rules are realized as semantic rules within an ontology. The adaption model ontology ties together the domain and user model ontology. An example usage of the adaption model could be: If the user clicks a specific link show a help field. This could be formalized as a rule. The adaption model than processes this rule and comes to conclusions that triggers the adaptation of the user interface by showing the help field.

An example for the real implementation of an AHS is depicted in Figure 13. This example shows how the workflow begins at the JavaScript events triggered by the user clicking on some links on client-side. These events then are recorded within the server-side user model ontology. To access and process the ontologies on server-side the AHS engine is necessary. The AHS engine might be implemented as Java Servlets to access the ontologies using the appropriate APIs. A good Java framework for building Semantic Web applications and for ontology management is the open source framework Jena. It supports RDF, RDFS, OWL and SPARQL and includes a Java based inference engine.




IST-2006-034921 PUBLIC 43 / 70

DomainModel

Ontology

UserModel

Ontology

AdaptionModel

Ontology

JavaScriptEvent

HandlerAHS Engine

HTTP

Figure 13: AHS use case

After storing the recorded information within the user model ontology the AHS engine executes the rules described within the adaption model ontology. This ontology contains the rules for example described with SWRL. The conclusions found during this processing than is realized as a concrete action that can influence the UI or the web service orchestration. In Figure 13 the reaction is realized as a UI adaptation by showing a help field. This UI adaptation might be realized by one of the above mentioned AJAX frameworks to avoid an entire page reload.

Using this concept helps the user during the application usage to simplify and optimize his work. Especially inexperienced users will profit from this concept. The application tries to understand the needs of the user and tries to adapt itself regarding these needs.

Low bandwidth - Reduce and accelerate client-server communication

A big problem in rural areas is the low bandwidth. To cope with this problem Web 2.0 provides the AJAX backend functionality which allows asynchronous client-server communication. To realize this concept one of the above mentioned AJAX frameworks could be used. The implementation effort to reduce client-server communication is really little and the benefit it huge.

Example: In the Sekhukhune RLL the infopreneur needs to pay his internet connection by data transfer amount. He could afford an amount of 20 MB per month. If for example an infopreneur tries to access the IBM website already 400kb are gone. And if he navigates through the page he easily downloads about 2 MB just browsing one website. To reduce this amount of data the website needs to be as thin as possible and should use the asynchronous data transfer to only load as less data as necessary.

Another positive side effect is that the application behavior accelerates. Since less data needs to be transferred between client and server the application round trip time minimizes.

Erratic connectivity – Use Web 2.0 offline capabilities

In rural areas the connectivity often is erratic and thus no stable connection could be assumed. To cope with this problem frameworks like Dojo offline are available. Dojo offline is a Web 2.0 toolkit that supports the development of offline web applications. It is build on top of Google Gears (Google plugin that extends web browsers with new functionality) and makes working with Google Gears easier. Dojo offline provides a higher level API than Google Gears provides and exposes developer productivity features. Dojo offline provides the following features:

• Offline widget that you can easily embed in your web page with just a few lines of code, automatically providing the user with network feedback, sync messages, offline instructions, and more.




IST-2006-034921 PUBLIC 44 / 70

• A sync framework to help you store actions done while offline and sync them with a server once back on the network

• Automatic network and application-availability detection to determine when your application is on- or off-line so that you can take appropriate action

• A slurp() method that automatically scans the page and figures out all the resources that you need offline, including images, stylesheets, scripts, etc.; this is much easier than having to manually maintain which resources should be available offline, especially during development.

• Dojo Storage, an easy to use hashtable abstraction for storing offline data for when you don't need the heaviness of Google Gear's SQL abstraction; under the covers Dojo Storage saves its data into Google Gears

• Dojo SQL, an easy to use SQL layer that executes SQL statements and returns them as ordinary JavaScript objects

• New ENCRYPT() and DECRYPT() SQL keywords that you can mix in when using Dojo SQL, to get transparent cryptography for columns of data. Cryptography is done on a Google Worker Pool thread, so that the browser UI is responsive.

• Integration with the rest of Dojo, such as the Dojo Event system

Dojo offline provides widgets (see Figure 14) that determine if the connection is available or not. If not the toolkit switches into offline mode. When the connection is available again the toolkit switches into online mode.

Figure 14: Dojo offline toolkit

A toolkit like Dojo offline enables to use an application regardless the connectivity. No data during a process will be lost if the connection disappears since it is stored in the Dojo storage. If the connection appears the process will be synchronize without any user interaction.




IST-2006-034921 PUBLIC 45 / 70

7. OPEN STANDARDS

This chapter provides an overview of current standards in the field of web services. A detailed overview of standards in the field of OGC (OpenGeoSpatial consortium) is attached in Annex A.

7.1. XML

Though you can isolate the XML language as a technology, it rarely ventures out into the real world unaccompanied. A closer look at any serious XML architecture will reveal a variety of supplemental technologies occupying key positions wherein they perform specialized processing of XML formatted data.

As the core family of XML specifications grows, so too does the complexity of the technology that implements it. Supplemental specifications add consistent functional dimensions to an architecture.

Though these core specifications deepen an application’s control over XML data, they also increase potential dependencies. It is therefore important to understand how XML technologies relate to your environment and to each other. Here are the specifications for the core XML technology set.

Extensible Markup Language (XML)

XML supplements Web content with “meta information,” self-descriptive labels for each piece of text that goes wherever the document goes. This turns each Web document into a self-contained, mini-repository, and positions the XML specification as the most fundamental standard and building block for XML and Web services technology platforms.

XML 1.0 (Fourth edition)

Status: Recommendation

Date: August, 2006

Specifications: W3C (html)

XML 1.1 (Second Edition)


Date: August, 2006


Namespaces in XML 1.0 (Second Edition)


Date: August, 2006


Namespaces in XML 1.1 (Second Edition)


Date: August, 2006




IST-2006-034921 PUBLIC 46 / 70


7.2. WEB SERVICES DESCRIPTION LANGUAGE (WSDL)

Web services need to be defined in a consistent manner so that they can be discovered by and interfaced with other services and applications. The Web Services Description Language is a W3C specification providing the foremost language for the description of Web service definitions.

The integration layer introduced by the Web services framework establishes a standard, universally recognized and supported programmatic interface. WSDL enables communication between these layers by providing standardized endpoint descriptions.

Figure 15: WSDL documents representing Web services to applications

The best way to understand how a Web service is defined and expressed by a WSDL document is to step through each of the constructs that collectively represent this definition. Let's begin with the root definitions element, which acts as the container for the entire service definition.

7.2.1. Abstract interface definition

Individual Web service interfaces are represented by WSDL interface elements. These constructs contain a group of logically related operations. In a component-based architecture, a WSDL interface is comparable to a component interface. An operation is therefore the equivalent of a component method, as it represents a single action or function.

A typical operation element consists of a group of related input and output messages. The execution of an operation requires the transmission or exchange of these messages between the service requestor and the service provider. Operation messages are represented by message constructs that are declared separately under the definitions element. The message names then are referenced in the operation's input or output child elements.

7.3. SIMPLE OBJECT ACCESS PROTOCOL (SOAP)

Although originally conceived as a technology to bridge the gap between disparate RPC-based communication platforms, SOAP has evolved into the most widely supported messaging format and




IST-2006-034921 PUBLIC 47 / 70

protocol for use with XML Web services. Hence the SOAP acronym is frequently referred to as the Service-Oriented Architecture (or Application) Protocol, instead of the Simple Object Access Protocol.

The SOAP specification establishes a standard message format that consists of an XML document capable of hosting RPC and document-centric data. This facilitates synchronous (request and response) as well as asynchronous (process-driven) data exchange models. With WSDL establishing a standard endpoint description format for applications, the document-centric message format is much more common.

Figure 16: SOAP establishes two primary standard message formats

The architectures we explore throughout this section make reference to both types of message formats using the standard diagram symbols provided in next figures.

Figure 17: The symbol used to represent a SOAP message with a document-centric payload




IST-2006-034921 PUBLIC 48 / 70

Figure 18: The symbol used to represent a SOAP message with an RPC-centric payload

SOAP messages containing attachments are represented with the symbol shown in Figure 19.

Figure 19: The symbol used to represent a SOAP message delivering its data as an attachment

7.3.1. SOAP messaging framework

SOAP institutes a method of communication based on a processing model that is in relative alignment with the overall Web services framework described at the beginning of this chapter. It differs only in that it introduces terms and concepts that relate specifically to the manner in which SOAP messages need to be handled (within a technical implementation of this framework).

Note that the diagram symbols used to identify SOAP nodes in the following sections are not displayed in other chapters. Their existence is implied in subsequent architectural diagrams that include Web services.

7.3.2. SOAP message structure

The container of SOAP message information is referred to as a SOAP envelope. Let's open it and take a brief look at the underlying structure of a typical SOAP message.

The root Envelope element that frames the message document consists of a mandatory body section and an optional header area.

7.4. UNIVERSAL DESCRIPTION, DISCOVERY, AND INTEGRAT ION (UDDI)




IST-2006-034921 PUBLIC 49 / 70

One of the fundamental components of a service-oriented architecture is a mechanism for Web service descriptions to be discovered by potential requestors. To establish this part of a Web services framework, a central directory to host service descriptions is required. Such a directory can become an integral part of an organization or an Internet community, so much so, it is considered an extension to infrastructure.

This is why the Universal Description, Discovery, and Integration specification has become increasingly important. A key part of UDDI is the standardization of profile records stored within such a directory, also known as a registry. Depending on who the registry is intended for, different implementations can be created.

A public business registry is a global directory of international business service descriptions. Instances of this registry are hosted by large corporations (also referred to as node operators) on a series of dedicated UDDI servers. UDDI records are replicated automatically between repository instances. Some companies also act as UDDI registrars, allowing others to add and edit their Web service description profiles. The public business registry is complemented by a number of service marketplaces offering generic Web services for sale or lease.

Private registries are service description repositories hosted within an organization. Those authorized to access this directory may include select external business partners. A registry restricted to internal users only can be referred to as an internal registry.

Figure 20: Service descriptions centralized in a private UDDI registry

The discovery process can occur in various situations depending on why service information is required. For instance:

· An organization seeking to establish new business relationships for online transactions can search for (and compare) suitable business partners using a public business registry.

· When building an inter-enterprise integration channel, the architect working for an organization's business partner will need to learn about the organization's external contact points. Service interfaces and the logic they express will form the basis for the Web services designed by the business partner. Access to the organization's private registry allows the architect to efficiently gather this information.

· An architect designing a new e-Business application may first want to research the availability of generic programming logic within an organization. By reading through existing service descriptions, opportunities for reuse may be discovered. Centralizing service descriptions in an internal registry provides a convenient resource repository for public endpoint descriptions within an enterprise.




IST-2006-034921 PUBLIC 50 / 70

· That same architect may also want to shop for a third-party Web service providing pre-built application logic that could be incorporated (locally or remotely) within the e-Business application. Service marketplaces offer venues to purchase or lease third-party Web services.

· A developer building new services will need to access interface definitions for existing services. The internal registry spares the developer from having to worry about whether the service interfaces being incorporated are current.

UDDI registries organize registry entries using six primary types of data:

· business entities

· business services

· specification pointers

· service types

· business relationships

· subscriptions

Business entity data, as represented by the businessEntity element, provides profile information about the registered business, including its name, a description, and a unique identifier.

When I registered XMLTC Consulting Inc. it was given a unique identifier of e9355d51-32ca-49cf-8eb4-1ce59afbf4a7, which was then assigned to the businessKey attribute of the businessEntity parent element. Since Microsoft acted as the node operator providing an instance of the UDDI registry, its name is displayed in the businessEntity element's operator attribute.

The discoveryURL element identifies the address used to locate this XML document.

Although this brief overview has discussed the fundamentals of UDDI (with a focus on the structure of business entities), it has not delved into the heart of a UDDI registry: the tModel. This important construct provides access to the technical details required for requestors to interface and interact with available Web services.

7.5. OGC STANDARDS

The OpenGeoSpatial consortium (OGC, formerly known as OpenGIS consortium) is well known to be a non profit standards organization, a union of (not only) the global players in the geospatial community. Together with ISO/TC211, the Technical Committee 211 it formulates Geomatic Standards. All information regarding their standards work can be found at http://www.geospatial.org

OGC does not only publish approved standards but also serves as a communication- and discussion platform within the geospatial community. OGC’s “technical baseline document” holds links to more than 140 documents describing Implementation specifications, Discussion papers, Abstract specifications, Recommendation papers etc.

Therefore and due the highly dynamic process of publishing standards we do not only focus on approved well known standards like for instance the Web Map Service but also on Services currently in discussion and not yet approved as standards.

OpenGIS® Specifications are technical documents that detail interfaces or encodings. Software developers use these documents to build support for the interfaces or encodings into their products and services. These specifications are the main "products" of the Open Geospatial Consortium and have been developed by the membership to address specific interoperability challenges. Ideally, when specifications are implemented by two different software engineers working independently, the resulting components plug and play, that is they work together without further debugging.

Details and list of the OGC standards is described in Annex A of this document.




IST-2006-034921 PUBLIC 51 / 70

8. SCT DESIGN PRINCIPLES

8.1. SOFTWARE COLLABORATIVE TOOLS INTRODUCTION

Collaborative Working Environments have to combine existing and future advanced components into an extensible, open and dynamic architecture that integrates the underlying layer components in a smooth upper layer middleware which will allow to take the underlying layer information accessible to the user in a transparent manner. To achieve this orchestration capabilities are key: integrating and harmonizing lower layer capabilities for creating advanced collaboration functions (e.g., context awareness & contextualization, distributed workspace, access to advanced services, etc.) and tools.

The Open Service Oriented Architecture (OSOA) will integrate collaborative service components defined by Layer 1, and software tools defined and developed by Layer 2. The C@RA, OSOA and Software Collaboration Tools will be prototyped and validated into the RLL to ensure compliance with end user requirements. The design of C@RA will comply with three goals:

• to define an open service oriented architecture (OSOA),

• to develop a uniforming layer for integration and interoperability - BUS

• to adapt the services provided by Core Collaborative Services (CCS) to interoperable standards

Figure 21: C@R OSOA design




IST-2006-034921 PUBLIC 52 / 70

The Figure 21 shows the structure of C-Rural OSOA. Main components of the architecture:

• The BUS: It provides support for integrating C@R and external Collaborating Core Services (CCS) offering a uniform interface to the SCT.

• The Orchestration Capabilities: which provides basic functionalities of OSOA for integration and orchestration into a single model of all the capabilities offered by the uniforming layer and the software tools in order to create Software Collaboration Tools to be instantiated for each RLL offering simple and customized interfaces. There have been identified three orchestration capabilities (Context awareness & contextualization, distributed workspace and access to advanced services) but others may be included into OSOA if required.

• Core Collaborative Services (CCS) - encapsulates a resource and its functionality in a reusable software component.

• The Software Collaborative tools (SCTs): which includes scripts, programs and intelligent agent to incorporate end-user level advanced features and functionalities.

What are Software Collaborative Tools?

Collaborative software is software designed to help people involved in a common task achieve their goals. The collaboration is provided on collaboration platforms - unified electronic platforms that support synchronous and asynchronous communication through a variety of devices and channels. Collaboration platforms offer a set of software components and software services that enable individuals to find each other and the information they need and to be able to communicate and work together to achieve common business goals.

Collaborative Tools can be divided into three main categories depending on the level of collaboration:

- Communication and conferencing tools - electronic communication tools send messages, files, data, or documents between people and hence facilitate the sharing of information (e-mail, fax, voice mail, web publishing, on-line chat, internet forum, video conference, application sharing)

- Collaborative management tools - collaborative management tools facilitate and manage group activities (project management systems, knowledge systems, on-line spreadsheet, electronic calendars)

- Data/Application sharing – tools enable access to shared documents or applications simultaneously in real time

Software collaborative tools, with respect C@R project, are sets of functionalities, which provide communication between final application, CCS and the BUS. SCTs can be implemented into final application, but should be in such a degree of independence to be usable for various applications. Simple SCT will provide only one CCS, but more sophisticated SCTs could integrate more CCS together. Sometimes, simple applications or parts of applications may be regarded as special SCT.

The SCT will be instantiated, using the corresponding software tools, to be used at each RLL, taking into account activities, user preferences and environmental conditions of each RLL.

8.2. SCT RELATIONS

In the Living Labs, the application development is currently focused on collaboration aspect. There exist several collaborative tools in Living Labs, but not each of them has full collaborative functionality – there are relatively independent each to other, but the communication interfaces are not




IST-2006-034921 PUBLIC 53 / 70

sufficiently described. These tools should be used for new Living Lab application, but only with deeper cooperation with the author of this tool and with several changes.

When the Rural Living Lab applications are designed, the architecture of the application is analyzed together with definition of available data sources, services and existing components. For existing components analysis focused on the implementation possibility and needs of adjustment of the tool is provided.

The variations of usage of the tools and services:

- one SCT is able to use and publish only one service

- several services should be integrated into one SCT

- a service can be used directly by the application

- a service can be available through non- service collaborative tool

These variations can be in developed tools combined; one service can be used by several SCTs or directly by developed application

Figure 22: SCTs interaction

For the development of RLL application, the SCTs can be used in different forms:

- direct connection

- implementation of instances

- publication of a new service




IST-2006-034921 PUBLIC 54 / 70

Figure 23: SCTs communication

If the C-Rural application needs to use one of CCS, usually SCT is called at first. SCT send the request for the functionality to the BUS and the BUS registries the requirement (including authorization). The BUS finds relevant service (CCS) and sends the connection parameters to SCT. SCT connects to the specified service and uses it for calculation of result. This process can be repeated with different CCS depend on functionality of SCT and origin request from application). When the SCT finish his task, send a result to the C-Rural application.

As mentioned above, SCTs can be developed as independent components or can be integrated into RLL application. Development of independent SCTs for their The main idea of C-Rural consist in development of independent components which can be used in all RLL without necessity of repetitive creation.

8.3. EXAMPLE IMPLEMENTATION OF AN SCT FOR THE COLLA BORATIVE PROCUREMENT & LOGISTICS USE CASE IN THE SOUTH AFRIC AN LIVING LAB

The collaborative procurement & logistics use case 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. It 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.




IST-2006-034921 PUBLIC 55 / 70

The initial starting point for this subtask is a builder who orders building material for his building site. During the order process the order application collects context information (e.g. delivery address, user address, delivery date, hardware and software used) that will be stored in the user profile to adapt the application appropriate to the current status. This kind of context dependent adaption is the so called “context- awareness” component in the C@R architecture. In this example the user profile contains the information that the building material, which is stored in a warehouse (Figure 24 – Route Point A), should not be delivered to the builders home (Figure 24 – Route Point B) but to the building site (Figure 24 – Route Point C). After the order has been placed by the builder the infopreneur now is responsible to manage the physical stock delivery. To optimize the stock delivery the infopreneur makes use of the RMF to discover the most appropriate logistic partner for the stock delivery and to plan the optimal stock delivery route. In the following chapter the data communication between the C@R architecture components will be described on the basis of the “calculate optimal stock delivery route” process (see Figure 24). The GIS application (RLL) provides the graphical user interface to the infopreneur and utilizes the backend functionality provided by the RMF SCT. The process is triggered by the infopreneur clicking on the “calculate route” button within the GIS application. Now the following process steps will be executed: • An XML document with the geographical information about the current map is sent from the RLL

GIS application to the RMF SCT and triggers the business process “calculate optimal stock delivery route” which is described within the RMF SCT (e.g. as BPMN process model). The SCT itself is build by a BPEL script which is responsible to involve the necessary architecture components (CCSs, OCs) and to establish the connections between them.

• 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. With the help of this additional context information a complete picture of all involved resources and their current status is created.

• 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 tree (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 route is fetched by the invocation of the “Context Awareness OC”. With this information the “Optimization CCS” 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. Again the “Context Awareness OC” is used to adapt the result appropriate to the used hard- and software (e.g. Laptop or PDA, screen size, bandwidth …). The result sent back to the GIS application depends on the current context and could be an image (JPEG, PNG, GIF, …), Flash movie or whatever format fits best to the current context.




IST-2006-034921 PUBLIC 56 / 70

Figure 24: Collaboration of C@R architecture components within the Collaborative Procurement & Logistics use case

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 is an XML document that is conform to the RMF SCT interface specification. Figure 25 depicts a more detailed view on the involved CCS components in the “calculate optimal stock delivery route” business process. Each CCS component is responsible to fulfil a well defined task in the business process. With this clear separation of tasks it is easy to replace or change a CCS component to adapt the business process to new requirements. Since the communication with CCS components is realized via web services the interfaces are well defined and available to the public. That enables an easy integration of additional process steps. If for example an additional step between the “Resource CCS” and “GIS boxing CCS” should be integrated the CCS component could be easily developed by being align with the in and output parameters of the former and following CCS component.

Figure 25: RMF CCS component communication




IST-2006-034921 PUBLIC 57 / 70

8.4. MAIN PRINCIPLES OF DEVELOPMENT OF COLLABORATIV E COMPONENTS

Development principles of new collaborative components within the framework of LL:

- a developmental independence – during the SW development each LL must not be limited of strictly defined developmental platform, applied technique and resolutely specification for technologies and developmental process

- an independence of component – each component should form an independent part, which is applicable to different RLL applications

- open interface – communication of various tools with others must be provided per open interface – knowledge of component interior is not necessary, but should be known how to communicate with existing component and how to utilize it

- user involvement – collection of impulses and submission from individual users, their suggestions

- multilevel testing

o testing of individual applications on programmer level

o testing of individual application by potential users

o testing of communication between various components

o user testing of whole application

o technical management of project – nomination of one person, who will have a complete view of stadium and researching process of several project parts and their coordination

- documentation

o component functionality documentation - metadata

o component interface documentation - UML

- compatibility with the architecture system specification

- metadata implementation

o catalogue client for determination of available services

o metadata client for new services description and registration




IST-2006-034921 PUBLIC 58 / 70

9. DEVELOPMENT TOOLS

In this chapter several open source tools will be proposed that might be useful during the development process of the different architecture components. However these are just suggestions of possible and helpful development tools. There is no obligation to use one of these tools.

9.1. REQUIREMENTS MODELING AND SOFTWARE DESIGN DEVE LOPMENT

This chapter provides information about tools that might be used to support the software design methodology.

9.1.1. Si*tool ( http://sesa.dit.unitn.it/sistar_tool)

Graphical tool for drawing Secure Tropos models and to perform the effective formal analysis of Secure Tropos specifications. Secure Tropos is an extension of Tropos. The tool is provided as an Eclipse plug-in and uses a XML document format. Formal analysis is based on logic programming. Si* tool allows to different systems based on Datalog to analyze Secure Tropos specification. A detailed description of the software design methodology is available at [14]. The methodology can be applied not only to the design of agent-oriented software but also to the design of web services. [15, 16, 17]

9.2. APPLICATION AND PROCESS DEVELOPMENT

This chapter will provide information about tools that support the application development. That contains web services and web applications.

9.2.1. Netbeans IDE ( http://www.netbeans.org)

The Netbeans IDE is a complete development environment to simplify the development of web services, web applications (JSP, JSF, Struts, EJB, AJAX, CSS) and mobile applications (Java ME). It supports Java, JSP, XML, C/C++ and code refactoring as well as UML and BPEL development.

9.2.2. Eclipse IDE (http://www.eclipse.org/)

Eclipse is an open source community developing tools for deploying and managing software across the lifecycle. The Eclipse IDE supports many different programming languages (similar to Netbeans IDE). Additional funtionalities can be included via plug-ins.

9.2.3. Intalio Designer ( http://www.intalio.com/products/designer/ )

Intalio|Designer is an Eclipse-based integrated development environment for BPMN business processes. The web services involved in the BPMN process can be included into the model. The entire business process then could be transformed into an executable BPEL script. This allows a high level BPM modeling with an executable BPEL process in the end.




IST-2006-034921 PUBLIC 59 / 70

The Intalio Designer works perfect together with the Intalio BPMS server which is a bundled Apache Geronimo with Axis2 and Apache ODE built in. Using this combination allows a “one-click” deployment of the BPMN model to the server.

9.3. SEMANTIC DEVELOPMENT

9.3.1. Overview of available semantic web developme nt tools

http://esw.w3.org/topic/SemanticWebTools

Contains the information on RDF and OWL tools that used to be listed on the home pages of the RDF and OWL Working Groups at W3C.

9.3.2. Protégé ( http://protege.stanford.edu/ )

Protégé is an open source ontology editor and knowledge-base framework. Protégé supports RDF(S), OWL and XML Schema and provides a plug-and-play environment for rapid prototyping and application development.




IST-2006-034921 PUBLIC 60 / 70

10. CONCLUSIONS

C@R is dealing with the problems of introducing innovations based on ICT Collaborative Services in Rural Areas. Rural living is characterized by widely-distributed activities of work and life. Successfully integrating these activities and multiple roles requires that solutions design is driven by human-centric innovation principles, adapted to the rural requirements.

Three key principles of development of Rural Living Labs for guiding the software development are: living labs as a context for human-centric innovation; boosting service technology and business development and sustainable and durable over the time. This deliverable summarised the works performed in Block in order to define the OSOA for supporting collaboration at rural environments. C@R follows a user-centric approach based on Living Labs. This work is in line with overall principles described in D3.1.1 [1] which presents the methodology for all the different tasks to be performed to create and maintain effectively a Living Lab. It proposes a common way to determine the innovation strategy of a Living Lab, define the services to be provided in the scope of a Living Lab, manage the Living Lab investments, risks and technological infrastructure, develop the requirements of the software tools to be provided, to deploy the platforms, to develop the applications, to perform the user roll out, to provide the corresponding training, to compile relevant information to evaluate and assess the Living Lab performance and to elaborate the business models to assure the Living Lab sustainability beyond C@R lifetime.

OSOA design follows general guidelines identified at Block 2 for the software design, which involve the design of the architecture but also components and end-user services integrated into the Architecture. These guidelines are grouped around main process: requirements identification; design and implementation; deployment and operation and CCS and SCT design and development.

The overall design of the C@R CWE platform is driven by several factors: providing easy to use, end to end simplified, locally relevant solutions; embedded solutions comprising informal and formal aspects of collaboration. Collaboration tools must support formal business transactions and workflows that enable rural people to participate in a global economy in a standardized way; highest flexibility to adapt and customize solutions to the context of local RLLs; compliance to Open Standards; supporting a variety of infrastructures; and lowered TCO and immediate ROI.

Very important are the interoperability capabilities of the design, and the integration of external initiatives (e.g. Frascati, VOICE, GIS platform). The initial design of OSOA of C@R has being analysed in the context of all the Project Living Labs and with Legacy and foreseen end-user applications. This in advance evaluation provided feedback in order to evaluate the suitability of current design according to Living Labs stakeholder expectations.

This Deliverable also analyse process related to deployment and operation of the architecture, CCS and SCT design and Development. The purpose of Deployment and Operation is to assemble the product from the Collaboration Components, ensure that the product, as integrated, functions properly, and deliver the final collaboration product, which should be work correctly during the live cycle of the service. The purpose of Design and Development of CCS and SCT is to design, develop, and implement solutions to requirements specified by end-users. Solutions, designs, and implementations encompass ICT Tools, collaboration components, and other products related.

Once design principles are defined, the overall OSOA architecture is defined. After studying different interconnection methodologies, a design based on the Webservices (WS) technology had been concluded and, therefore, say that C@R implements a “Web Service design methodology” in the SW development of its CWE platform. This architecture incorporated a Bus as the master piece acting as a resource broker, enabling the system to search for resources and managing their interconnections. From the point of view of implementation, Bus requires the establishment of information channels with the resources that it pretends to manage and interconnect.




IST-2006-034921 PUBLIC 61 / 70

The main two advantages of using Webservices for C@R resources (CCS) and control elements (BUS) communication has being identified: webservices define an agnostic method with regard to Operating Systems, Programming Languages and transport layer; and as Webservices are widely used nowadays by Internet based services, by using this methodology C@R ensures easy access to external resources and a standard way for C@R resources to be accessed to build new applications.

Some disadvantages have being also taken into account such as heavy protocol for light devices and that a Webservice is designed as a “stateless machine” meaning that some kind of storage is needed to save the results of operations/changes performed by it.

C@R CWE System Level specification describes C@R concept of a “CWE domain” and the system architecture to enable Telecoms/Service providers to offer “CWE Services” in a Living Lab.

The main specific concepts and definitions which really make a difference compared to other common SW Architectures are the following: Control Plane vs. Data Plane; CWE Domain concept; Business Models; and Interactive Services.

A very important aspect of the OSOA of C@R is the definition of a semantic web layer. C@R proposal concentrates on the least possible solution. That leads to a small and easy to implement but still effective additional layer in the C@R architecture. C@R implements the semantic web because of its benefits and not mainly to research on new complex semantic web components. The meaning, architecture and usage in the three C@R layers of the semantic web has been described in detail in the deliverable D2.1.2 [13], whereas examples of how to use and profit from the semantic web have been described in the deliverable D2.3.1 [18].

The definition of OSOA of C@R is strongly based on Open standards, so we provided in this deliverable a complete overview of main technologies used. This includes XML, WSDL, SOAP, UDDI and OGC. Apart from those technologies, special attention is paid to Web 2.0 usage, addressing the usage of Web 2.0 in the C@R architecture and provides some example applications that might be used in the RLL applications: Collaborative Web 2.0 tools and Web 2.0 backend functionality, focusing on the technological side of Web 2.0. Especially in rural areas there are a lot of infrastructural impediments the applications need to cope with. Problems like less computer literacy, low bandwidth and erratic connectivity need to be solved before the collaborative tools could be utilized. Web 2.0 has the capabilities to design the applications in a way that they can handle all these problems in a way that wasn’t possible without Web 2.0 technologies. In the following some of the problems RLLs face in the rural areas will be discussed and possible solutions will be proposed

Rural Living Labs are one of the cornerstones of C@R. They are organized as multidisciplinary research environments where different actors (including not only people, but also animals and plants which are ubiquitous in rural areas, at least in traditional activities) will interact with technologies that will be introduced in a progressive way. An evolution model will be followed: technologies for collaborativeness will be left “alone” in the rural settings and interaction with users and the environment will serve to accept or discard those that fulfils the established criteria of usability, friendliness, affordability, profitability and technical viability, that is to define the technologies that “survive” in the Living Lab.

End user applications developed using OSOA of C@R will be called SCT. In the Living Labs, the application development is currently focused on collaboration aspect. There exist several collaborative tools in Living Labs, but not each of them has full collaborative functionality – there are relatively independent each to other, but the communication interfaces are not sufficiently described. These tools should be used for new Living Lab application, but only with deeper cooperation with the author of this tool and with several changes.

- Existing and new Collaboration Applications and services may be integrated into OSOA of C@R. All of them will be integrated using the same interface with the BUS, allowing different coupling degrees and not imposing any restriction to the functionalities, size or interfaces of CCS. Nevertheless some development principles of new collaborative components within the framework of LL as being defined: developmental independence, an independence of




IST-2006-034921 PUBLIC 62 / 70

component, open interface, user involvement, enabling multilevel testing, documentation, compatibility with the architecture system specification and metadata implementation.

The SCT, defining the complete end use application, will be defined as the combination of CCS and OCs. Thus the OSOA of C@R will allow the deployment of SCTs instantiated for each LL according to local requirements and conditions. Finally in chapter 9 we analyzed several open source tools that may be useful during the development process of the different architecture components.

OSOA of C@R is being implemented and practical validation are going to be deployed in different Living Labs in order to get early feedback about the design.




IST-2006-034921 PUBLIC 63 / 70

11. REFERENCES

[1] C@R D3.1.1, “Living labs common Methodology framework”, July 2007.

[2] C@R D2.1.1, “Requirements capture for CWE in Rural areas and Software design and architecture for software collaborative Tools”, March 2007.

[3] C@R D2.6.1, “Deployment of the Testing environment Infrastructure”, November 2007

[4] Uschold and M. Grüninger: Ontologies: Principles, methods and applications. Knowledge Engineering Review, 11(2), 1996.

[5] Jesse James Garret: Ajax: A New Approach to Web Applications. Adaptivepath, 2004, http://www.adaptivepath.com/publications/essays/archives/000385.php at 26.02.2008

[6] Prototype http://www.prototypejs.org

[7] Script.acuol.us http://script.aculo.us

[8] Moo.fx http://moofx.mad4milk.net

[9] MockiKit http://mochikit.com

[10] Dojo toolkit http://dojotoolkit.org

[11] Google Web Toolkit http://code.google.com/webtoolkit

[12] ASP.NET AJAX http://atlas.asp.net

[13] C@R D2.1.2, “Ontologies for rural activities”, September 2007

[14] Paolo Bresciani, Anna Perini, Paolo Giorgini, Fausto Giunchiglia, John Myloploulos: Tropos: An Agent-Oriented Software Development Methodology. Autonomous Agents and Multi-Agent Sytems, 8, 203–236, 2004

[15] D. Lau and J. Mylopoulos. Designing Web Services with Tropos. In Proceedings of IEEE International Conference on Web Services, San Diego, USA, July 6-9 2004.

[16] L. Penserini, A. Perini, A. Susi, and J. Mylopoulos. From Stakeholder Needs to Service Requirements. In Proceeding of International Workshop on Service-Oriented Computing: Consequences for Engineering Requirements, Minneapolis, Minnesota, USA, September 12 2006.

[17] G. Frankova, F. Massacci, and M. Seguran. From Early Requirements Analysis towards Secure Workflows. Proceedings of the joint iTrust and PST Conferences on Privacy, Trust Management and Security, Moncton, New Brunswick, Canada, July-August 2007

[18] C@R D2.3.1, “Design of Context awareness information model and identification of components to be developed”, October 2007

[19] W3C Semantic Web Activity. http://www.w3.org/2001/sw/

[20] SchemaWeb. Available at: http://www.schemaweb.info/

[21] Ping the Semantic Web. Available at: http://pingthesemanticweb.com/

[22] Swoogle. Available at: http://swoogle.umbc.edu/

[23] FOAF. Available at: http://xmlns.com/foaf/0.1/

[24] SIOC. Available at: http://sioc-project.org/

[25] Linking open data. Available at: http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/LinkingOpenData

[26] C@R D2.1.4, “Semantic_Compatibility_for_Rural_Activities”, Februar 2008

[27] C@R D1.1.2, “Architecture Requirements of CCS Components”, November 2007

[28] J. Dörflinger, G. Frankova, A. Lucientes, R. de Louw, M. Navarro, C. Peña, C. Ralli, T. Robles. Enhancing an Open Service Oriented Architecture with Collaborative Functions for Rural Areas, In Proceeding of ICE2008, Lisbon, June 2008




IST-2006-034921 PUBLIC 64 / 70

12. ANNEX A: OGC STANDARDS REVIEW

12.1. OPENGIS® CATALOGUE SERVICE (CAT) IMPLEMENTATI ON SPECIFICATION

Date: 2 / 2007

Version: 2.0.2

Reference: http://portal.opengeospatial.org/files/?artifact_id=20555

This document specifies the interfaces between clients and catalogue services, through the presentation of abstract and implementation-specific models. Catalogue services support the ability to publish and search collections of descriptive information (metadata) for data, services, and related information objects. Metadata in catalogues represent resource characteristics that can be queried and presented for evaluation and further processing by both humans and software. Catalogue services are required to support the discovery and binding to registered information resources within an information community.

12.2. OPENGIS® GML IN JPEG 2000 FOR GEOGRAPHIC IMAG ERY ENCODING SPECIFICATION

Date: 1 / 2006

Version: 1.0.0


The OpenGIS Geography Markup Language (GML) standard http://www.opengeospatial.org/standards/gml) is an XML grammar for the encoding of geographic information including geographic features, coverages, observations, topology, geometry, coordinate reference systems, units of measure, time, and value objects.

The ISO JPEG 2000 standard (http://www.jpeg.org/jpeg2000) is a wavelet based encoding for imagery that provides the ability to include XML data for description of the image within the JPEG 2000 data file.

This specification defines the means by which GML is to be used within JPEG 2000 images for geographic imagery. This includes the following:

· Specification of the uses of GML within JPEG 2000 data files.

· Packaging mechanisms for including GML within JPEG 2000 data files.

· Specific GML application schemas to support the encoding of OGC coverages within JPEG 2000 data files.

12.3. OPENGIS® FILTER ENCODING IMPLEMENTATION SPECI FICATION

Date: 5 / 2005

Version: 1.1.0


The OpenGIS® Filter Encoding Implementation Specification defines an XML encoding for filter expressions. A filter expression constrains property values to create a subset of a group of objects. The goal, typically, is to operate on just those objects by, for example, rendering them in a different color or saving them to another format.

XML representations can be easily validated, parsed and then transformed into whatever target language is required to retrieve or modify objects. For example, an XML encoded filter could be




IST-2006-034921 PUBLIC 65 / 70

transformed into a WHERE clause for a SQL SELECT statement to fetch data stored in a SQL-based relational database. Similarly, an XML encoded filter expression could be transformed into an XPath or XPointer expression for fetching data from XML documents.

The filter encoding specified in this document is a common component that can be used by a number of OGC Web Services. Any service that requires the ability to query objects from a Web-accessible repository can make use of the XML filter encoding described in this document. For example, a Web feature service may use the XML filter encoding in a GetFeature operation to define query constraints.

12.4. OPENGIS® GEOGRAPHY MARKUS LANGUAGE (GML) ENCO DING STANDARD

Date: 8 / 2007

Version: 3.2.1


The Geography Markup Language (GML) is an XML encoding in compliance with ISO 19118 for the transport and storage of geographic information modelled in accordance with the conceptual modelling framework used in the ISO 19100 series of International Standards and including both the spatial and non-spatial properties of geographic features.

This International Standard defines the XML Schema syntax, mechanisms and conventions that:

· provide an open, vendor-neutral framework for the description of geospatial application schemas for the transport and storage of geographic information in XML;

· allow profiles that support proper subsets of GML framework descriptive capabilities;

· support the description of geospatial application schemas for specialized domains and information communities;

· enable the creation and maintenance of linked geographic application schemas and datasets;

· support the storage and transport of application schemas and datasets;

· increase the ability of organizations to share geographic application schemas and the information they describe.

Implementers may decide to store geographic application schemas and information in GML, or they may decide to convert from some other storage format on demand and use GML only for schema and data transport.

12.5. OPENGIS® SENSOR MODEL LANGUAGE (SENSORML) ENC ODING STANDARD

Date: 10 / 2007

Version: 1.0.1


The primary focus of SensorML is to define processes and processing components associated with the measurement and post-measurement transformation of observations. The SensorML document also defines the SWE Common data types used throughout the SWE encodings and services.

For additional information on SensorML, go to http://vast.uah.edu/SensorML

12.6. OPENGIS® SENSOR PLANNING SERVICE (SPS) IMPLEM ENTATION SPECIFICATION

Date: 8 / 2007

Version: 1.0




IST-2006-034921 PUBLIC 66 / 70


The Sensor Planning Service (SPS) provides a standard interface to collection assets (i.e., sensors, and other information gathering assets) and to the support systems that surround them. Not only must different kinds of assets with differing capabilities be supported, but also different kinds of request processing systems, which may or may not provide access to the different stages of planning, scheduling, tasking, collection, processing, archiving, and distribution of requests and the resulting observation data and information that is the result of the requests. The SPS is designed to be flexible enough to handle such a wide variety of configurations.

12.7. OPENGIS® STYLED LAYER DESCRIPTION (SLD) PROFI LE OF THE WEB MAP SERVICE IMPLEMENTATION SPECIFICATION

Date: 6 / 2007

Version: 1.1.0 (revision 4)


The importance of the visual portrayal of geographic data cannot be overemphasized. The skill that goes into portraying data (whether it be geographic or tabular) is what transforms raw information into an explanatory or decision-support tool. From USGS' topographic map series to NOAA and NIMA's nautical charts to AAA's Triptik, fine-grained control of the graphical representation of data is a fundamental requirement for any professional mapping community.

The current OGC Web Map Service (WMS) specification supports the ability for an information provider to specify very basic styling options by advertising a preset collection of visual portrayals for each available data set. However, while a WMS currently can provide the user with a choice of style options, the WMS can only tell the user the name of each style. It cannot tell the user what portrayal will look like on the map. More importantly, the user has no way of defining their own styling rules. The ability for a human or machine client to define these rules requires a styling language that the client and server can both understand. Defining this language, called the Symbology Encoding (SE) is done in a companion document of this specification. This language can be used to portray the output of Web Map Servers, Web Feature Servers and Web Coverage Servers. This document defines how Symbology Encoding can be used in conjunction with Web Map Services. In many cases, however, the client needs some information about the data residing on the remote server before he, she or it can make a sensible request. This led to the definition of new operations for the OGC services (see Clauses 8 and 9) in addition to the definition of the styling language.

There are two basic ways to style a data set. The simplest one is to color all features the same way. For example, one can imagine a layer advertised by a WMS as “hydrography” consisting of lines (rivers and streams) and polygons (lakes, ponds, oceans, etc.). A user might want to tell the server to color the insides of all polygons in a light blue, and color the boundaries of all polygons and all lines in a darker blue. This type of styling requires no knowledge of the attributes or “feature types” of the underlying data, only a language with which to describe these styles. This requirement is addressed by the FeatureTypeStyle element in the SE document.

A more complicated requirement is to style features of the data differently depending on some attribute. For example, in a roads data set, style highways with a three-pixel red line; style four-lane roads in a two-pixel black line; and style two-lane roads in a one-pixel black line. Accomplishing this requires the user to be able to find out what attribute of the data set represents the road type. SLD profile of WMS defines the operation that fulfils this need, called DescribeLayer. This operation returns the feature types of the layer or layers specified in the request, and the attributes can be discovered with the DescribeFeatureType operation of a WFS interface or the DescribeCoverageType of a WCS interface.




IST-2006-034921 PUBLIC 67 / 70

12.8. OPENGIS® SYMBOLOGY ENCONDING IMPLEMENTATION S PECIFICATION (SYMBOL)

Date: 7 / 2006

Version: 1.1.0 (revision 4)


The importance of the visual portrayal of geographic data cannot be overemphasized. The skill that goes into portraying data (whether it be geographic or tabular) is what transforms raw information into an explanatory or decision-support tool. From USGS' topographic map series to NOAA and NIMA's nautical charts to AAA's Triptik, fine-grained control of the graphical representation of data is a fundamental requirement for any professional mapping community.

The current OGC Web Map Service (WMS) specification supports the ability for an information provider to specify very basic styling options by advertising a preset collection of visual portrayals for each available data set. However, while a WMS currently can provide the user with a choice of style options, the WMS can only tell the user the name of each style. It cannot tell the user what portrayal will look like on the map. More importantly, the user has no way of defining their own styling rules. The ability for a human or machine client to define these rules requires a styling language that the client and server can both understand. Defining this language, called the Symbology Encoding (SE) is the focus of this specification. This language can be used to portray the output of Web Map Servers, Web Feature Servers and Web Coverage Servers.

12.9. OPENGIS® TRANSDUCER MARKUP LANGUAGE (TML) ENC ODING SPECIFICATION

Date: 2007

Version: 1.0.0


TML defines:

· a set of models describing the response characteristics of a transducer

· an efficient method for transporting sensor data and preparing it for fusion through spatial and temporal associations

Sensor data is often an artifact of the sensor’s internal processing rather than a true record of phenomena state. The effects of this processing on sensed phenomena can be characterized as functions.

TML response models are formalized XML descriptions of these known hardware behaviors. The models can be used to reverse distorting effects and return artifact values to the phenomena realm. TML provides models for a transducer’s latency and integration times, noise figure, spatial and temporal geometries, frequency response, steady-state response and impulse response.

Traditional XML wraps each data element in a semantically meaningful tag. The rich semantic capability of XML is in general better suited to data exchange rather than live delivery where variable bandwidth is a factor. TML addresses the live scenario by using a terse XML envelope designed for efficient transport of live sensor data in groupings known as TML clusters. It also provides a mechanism for temporal correlation to other transducer data.

12.10. OPENGIS® WEB COVERAGE SERVICE (WCS) IMPLEMEN TATION SPECIFICATION

Date: 10 / 2006

Version: 1.1.0




IST-2006-034921 PUBLIC 68 / 70

Reference: https://portal.opengeospatial.org/files/?artifact_id=18153

The Web Coverage Service (WCS) supports electronic retrieval of geospatial data as "coverages" – that is, digital geospatial information representing space-varying phenomena.

A WCS provides access to potentially detailed and rich sets of geospatial information, in forms that are useful for client-side rendering, multi-valued coverages, and input into scientific models and other clients. The WCS may be compared to the OGC Web Map Service (WMS) and the Web Feature Service (WFS); like them it allows clients to choose portions of a server's information holdings based on spatial constraints and other criteria.

Unlike the WMS [OGC 04-024], which portrays spatial data to return static maps (rendered as pictures by the server), the Web Coverage Service provides available data together with their detailed descriptions; defines a rich syntax for requests against these data; and returns data with its original semantics (instead of pictures) which may be interpreted, extrapolated, etc. – and not just portrayed.

Unlike WFS [OGC 02-058], which returns discrete geospatial features, the Web Coverage Service returns coverages representing space-varying phenomena that relate a spatio-temporal domain to a (possibly multidimensional) range of properties. The Web Coverage Service provides three operations: GetCapabilities, DescribeCoverage, and GetCoverage. The GetCapabilities operation returns an XML document describing the service and brief descriptions of the coverages that clients may request. Clients would generally run the GetCapabilities operation and cache its result for use throughout a session, or reuse it for multiple sessions. When the GetCapabilities operation does not return such descriptions, then equivalent information must be available from a separate source, such as an image catalog.

The DescribeCoverage operation lets clients request a full description of one or more coverages served by a particular WCS server. The server responds with an XML document that fully describes the identified coverages.

The GetCoverage operation is normally run after GetCapabilities and DescribeCoverage operation responses have shown what requests are allowed and what data are available. The GetCoverage operation returns a coverage (that is, values or properties of a set of geographic locations), encoded in a well-known coverage format. Its syntax and semantics bear some resemblance to the WMS GetMap and WFS GetFeature requests, but several extensions support the retrieval of coverages rather than static maps or discrete features.

12.11. OPENGIS® WEB FEATURE SERVICE (WFS) IMPLEMENT ATION SPECIFICATION

Date: 5 / 2005

Version: 1.1.0


The Open Geospatial Consortium (OGC) has developed a member consensus that when software vendors implement their products in compliance with open geospatial web service interface and data encoding specifications, end-users benefit from a larger pool of interoperable web based tools for geodata access and related geoprocessing services.

The Web Map Server products that have been developed to implement the OGC Web Map Service Implementation Specification [1] are prime examples of such tools. The GetCapabilities and GetMap interfaces defined in that specification give users on the web an interoperable way to combine and view map images from different sources. And the GetFeatureInfo interface gives those users a way to obtain attribute information about geographic features displayed in a map with a simple mouse click.

The OGC Geography Markup Language (GML) Implementation Specification [2] describes an encoding specification for geodata in XML that enables the storage, transport, processing, and transformation of geographic information.




IST-2006-034921 PUBLIC 69 / 70

This document, the OGC Web Feature Service (WFS) Implementation Specification, takes the next logical step of by defining interfaces for data access and manipulation operations on geographic features using HTTP as the distributed computing platform. Via these interfaces, a web user or service can combine, use and manage geodata

-- the feature information behind a map image -- from different sources

by invoking the following WFS operations on geographic features and elements:

· Create a new feature instance

· Delete a feature instance

· Update a feature instance

· Lock a feature instance

· Get or query features based on spatial and non-spatial constraints

12.12. OPENGIS® WEB MAP CONTEXT (WMC) IMPLEMENTATIO N SPECIFICATION

Date: 1 / 2005

Version: 1.1.0


The OpenGIS® Web Map Context (WMC) Implementation Specification is a companion to the OpenGIS® Web Map Service. It describes how to save a map view comprised of many different layers from different Web Map Servers. A 'context' can be encoded and saved so that Web maps created by users can be automatically reconstructed and augmented by the authoring user or other users in the future.

Currently, context documents are primarily designed for WMS bindings. However, extension is planned for binding to other services.

A Context document is structured using eXtensible Markup Language (XML). Potential uses for context documents include: creating default initial views for Web maps in significant demand by user communities, saving the state of a user's work on a viewer client to preserve information such as how geospatial layers are added or modified, and saving the state of a client session for sharing with other users. Also, context documents can be cataloged and discovered for reuse by others.

12.13. OPENGIS® WEB MAP SERVICE (WMS) IMPLEMENTATIO N SPECIFICATION

Date: 3 / 2006

Version: 1.3.0


A Web Map Service (WMS) produces maps of spatially referenced data dynamically from geographic information. This International Standard defines a “map” to be a portrayal of geographic information as a digital image file suitable for display on a computer screen. A map is not the data itself. WMS-produced maps are generally rendered in a pictorial format such as PNG, GIF or JPEG, or occasionally as vector-based graphical elements in Scalable Vector Graphics (SVG) or Web Computer Graphics Metafile (WebCGM) formats.

This International Standard defines three operations: one returns service-level metadata; another returns a map whose geographic and dimensional parameters are well-defined; and an optional third operation returns information about particular features shown on a map. Web Map Service operations can be invoked using a standard web browser by submitting requests in the form of Uniform Resource Locators (URLs). The content of such URLs depends on which operation is requested. In particular, when requesting a map the URL indicates what information is to be shown on the map, what portion




IST-2006-034921 PUBLIC 70 / 70

of the Earth is to be mapped, the desired coordinate reference system, and the output image width and height. When two or more maps are produced with the same geographic parameters and output size, the results can be accurately overlaid to produce a composite map. The use of image formats that support transparent backgrounds (e.g. GIF or PNG) allows underlying maps to be visible. Furthermore, individual maps can be requested from different servers. The Web Map Service thus enables the creation of a network of distributed map servers from which clients can build customized maps. Illustrative examples of map request URLs and their resulting maps are shown in Annex G.

This International Standard applies to a Web Map Service instance that publishes its ability to produce maps rather than its ability to access specific data holdings. A basic WMS classifies its geographic information holdings into “Layers” and offers a finite number of predefined “Styles” in which to display those layers. This International Standard supports only named Layers and Styles, and does not include a mechanism for user-defined symbolization of feature data.

12.14. OPENGIS® WEB SERVICE COMMON (WSC) IMPLEMENTA TION SPECIFICATION

Date: 2 / 2007

Version 1.1.0 with Corrigendum 1


This document specifies many of the aspects that are, or should be, common to all or multiple OGC Web Service (OWS) interface Implementation Specifications. These common aspects are primarily some of the parameters and data structures used in operation requests and responses. Of course, each such Implementation Specification must specify the additional aspects of that interface, including specifying all additional parameters and data structures needed in all operation requests and responses.

Each existing OGC-approved and draft OWS interface Implementation Specification should consider this document to be a formal change request to modify that specification in its next revision to agree with all the relevant material specified herein. Each such specification is also requested to normatively reference each relevant part of this document, instead of repeating the same material in each such Implementation Specification. Such normative references can take the form of stating “This TBD shall include TBD as specified in Subclause TBD of OGC document TBD.” Such normative references are expected to:

a) Reduce the work needed to edit and read each such Implementation Specification

b) Reduce the length of each such Implementation Specification

c) Increase interoperability among such Implementation Specifications by increasing commonality and discouraging non-essential differences

d) Reduce the work needed to program OWS clients and servers

Documents

Collaboration@RuralR-WP 2.1-D2.1.3.pdf · 2017-09-05 · IST-2006-034921 PUBLIC 2 / 70 Project information Project acronym: C@R Project full title: Collaboration@Rural Proposal/Contract