SEVENTH FRAMEWORK PROGRAMME COOPERATION – THEME 7 TRANSPORT (INCLUDING

AERONAUTICS) HORIZONTAL ACTIVITIES FOR IMPLEMENTATION OF THE TRANSPORT PROGRAMME

D1.1: Issue: 1.33

Document Ref: i-Travel Deliverable D1.1 “i-Travel State of the art” Volume 1

Project Acronym: i-Travel Project Instrument: Small-scale collaborative project Project full title: Service platform for the connected traveller Proposal / Contract no: 212785 Date of Issue: 09 September 2008

Start date of contract: 1 January 2008

Project co -funded by the European Commission within the Seventh Framework Programme (2007-2013) DISSEMINATION LEVEL PU Public X PP Restricted to other programme participants (including the Commission Services) RE Restricted to a group specified by the consortium (including the Commission Services) CO Confidential, only for members of the consortium (including the Commission Services)

i-Travel Deliverable D1.1 “i -Travel State of the art”

Table of contents 1 Introduction ...... 5 1.1 Purpose of this document ...... 5 1.2 Intended audience of this document ...... 5 1.3 Structure of the Document ...... 5 2 Executive Summary ...... 5 3 i-Travel project ...... 8 3.1 Project abstract ...... 8 3.2 Work package 1 State of the art and value chain analysis ...... 8 4 WP1 Methodology ...... 9 5 Technologies & Standards ...... 12 5.1 Structure of the chapter ...... 12 5.2 The traveller needs ...... 12 5.2.1 Task model ...... 12 5.2.2 Service model and related SWOT criteria ...... 13 5.3 Information Systems for traveller...... 15 5.3.1 At-stop Display ...... 15 5.3.2 Instant Messaging and Presence ...... 17 5.4 Service Oriented Architectures (SOA) ...... 18 5.5 Event Driven Frameworks & Languages ...... 21 5.5.1 Technologies ...... 22 5.5.2 Other queuing/messaging technologies ...... 28 5.5.3 Business Integration Software ...... 33 5.5.4 Publish Subscribe Systems...... 36 5.5.5 Web services Coordination ...... 40 5.5.6 BPEL ...... 41 5.5.7 Next Generation Telematics Protocol (NGTP) ...... 43 5.6 Summary of technical standards...... 44 5.6.1 Objectives...... 44 5.6.2 Methodology ...... 45 5.6.3 Main Results ...... 46 5.7 Analysis of technical standards ...... 47 5.7.1 Standardisation Bodies ...... 47 5.7.2 Domain Specific Standards ...... 48 5.7.3 Domain Independent Standards ...... 49 5.7.4 Analysis of Content Standards ...... 50 5.7.5 Analysis of Encoding Standards ...... 52 5.7.6 Analysis of Service Standards...... 53 5.7.7 Travel ontology’s ...... 55 5.8 Data Formats for Syndication...... 56 5.8.1 RSS/ATOM/XML ...... 57 5.8.2 Atom...... 57 5.8.3 RSS...... 58 5.8.4 Aggregators ...... 59 5.9 Data Synchronization and push mechanisms ...... 60 5.9.1 SyncML ...... 60 5.9.2 Oracle Database Lite ...... 60 5.9.3 IntelliSynch Mobile Suite (Nokia) ...... 61

2 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

5.9.4 Mobile Messaging with Exchange ActiveSync (Microsoft) ...... 61 5.9.5 RIM Blackberry Enterprise Server (BES) ...... 61 5.10 Communication & Distribution Channel Standards and Technologies ...... 62 5.10.1 Internet Communication Standards ...... 62 5.10.2 IMS...... 62 5.10.3 Wireless Communication Protocols ...... 62 5.10.4 Client distribution channels ...... 64 5.11 Software frameworks ...... 66 5.11.1 Linux embedded platforms ...... 66 5.11.2 Microsoft .NET compact framework ...... 67 5.11.3 Symbian ...... 67 5.11.4 J2ME ...... 67 5.11.5 Flash lite ...... 68 5.11.6 Android ...... 68 5.11.7 Brew ...... 68 5.11.8 OSGi...... 70 5.12 Relevant (XML-based) presentation formats ...... 73 5.12.1 XHTML ...... 74 5.12.2 SVG ...... 74 5.12.3 SMIL ...... 75 5.12.4 Data representation formats in Semantic Web ...... 75 5.13 Identity management and federated identity ...... 78 5.14 B2B payments ...... 80 5.14.1 ACH ...... 80 5.14.2 Mobile Payments...... 81 5.15 Agent-based platforms ...... 83 5.15.1 FIPA ...... 87 5.15.2 JADE ...... 87 5.15.3 Spyse ...... 87 5.15.4 Aglets ...... 87 5.15.5 ZEUS (BT) ...... 87 5.15.6 APRIL (Fujitsu) ...... 88 5.15.7 Grasshopper ...... 88 5.16 Context awareness and information ...... 90 5.16.1 Definition Context...... 90 5.16.2 Context-Generating Modules (CGM) ...... 90 5.16.3 Multi-Modal Location (MML) ...... 90 5.16.4 State of the art of Sensor Networks in Ubiquitous and Wearable Computing ...... 91 5.17 Conclusions...... 93

List of Figures Figure 1. WP1 Methodology ...... 9 Figure 2. Travel process ...... 12 Figure 3. Three time-based tracks ...... 12 Figure 4. i-Travel service model ...... 13 Figure 5. Reference model ...... 14 Figure 6. Telematic-based ICT-enhanced information systems ...... 15 Figure 7. Interaction with the display ...... 16 Figure 8. IMPS General architecture ...... 18 Figure 9. Minimal Service Oriented Architecture ...... 19 Figure 10. General Service Oriented Architecture Schema ...... 19 Figure 11. Gartner Magic Quadrant for New Service-Oriented Business Application Projects, 2Q07 ...... 20 3 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Figure 12. IPC through CORBA ...... 22 Figure 13. Example of a client/ server application implemented with web services ...... 23 Figure 14. Complete web service infrastructure, with service discovery through UDDI, automatic stub creation with WSDL and remote service access...... 25 Figure 15. Relationship between UDDI and Webservices ...... 25 Figure 16. A businessEntity template pointing to a tModel ...... 26 Figure 17. Conceptual overview of UDDI Registry affiliation...... 26 Figure 18. JSM main concepts: Queue ...... 27 Figure 19. JMS main concepts: Topic ...... 27 Figure 20. Microsoft Message Queuing ...... 28 Figure 21. Bea WebLogic Event Server ...... 29 Figure 22. Example of application of Oracle Streams for database replication ...... 29 Figure 23. XMPP federation: clients connect to their own server and end to end messages are always exchanged with server mediation...... 31 Figure 24. Use of connection managers in XMPP ...... 32 Figure 25. The Comet application model, modeled accordingly to the same principles of BOSH ...... 32 Figure 26. Gartner Magic quadrant for Application Infrastructure (2007) ...... 34 Figure 27. Publish subscribe in BizTalk ...... 35 Figure 28. Simplified Architecture of the Oracle Fusion Middleware ...... 36 Figure 29.General Publish/Subsribe system ...... 37 Figure 30. Example of a distribute application implemented with XMPP Publish/Subscribe support ...... 38 Figure 31. Publish/Subscribe browsing via an XMPP Client ...... 38 Figure 32. Publishing geolocation through Personal Eventing ...... 39 Figure 33. Receiving geolocation through Personal Eventing...... 39 Figure 34. Composition of web services with orchestration ...... 40 Figure 35. Composition of web services with choreography ...... 40 Figure 36. BPEL description of an Itinerary reservation process ...... 41 Figure 37. Graphical view of the flow in a Business Process ...... 42 Figure 38. NGPT Architecture ...... 44 Figure 39. Feeds ...... 59 Figure 40. NFC Forum technology architecture: Peer-to-Peer low level communication, data exchange and card emulation...... 64 Figure 41. OSGi Framework ...... 70 Figure 42. Gartner Magic Quadrant for User Provisioning, 2H07 ...... 74 Figure 43. The Semantic Web stack as presented by Tim Berners Lee in 2000 ...... 77 Figure 44. Spectrum of information sharing capabilities ...... 78 Figure 45. General Architecture of the SMART Money initiative ...... 81 Figure 46. Payment via Instant Messaging: user interaction ...... 82 Figure 47. Payment Infrastructure ...... 82 Figure 48. The Grasshopper Distributed Agent Environment ...... 89 Figure 49. The Porcupine wearable sensory ...... 92

4 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

1 Introduction

1.1 Purpose of this document The document presents the state of the art related to i-Travel services. This document describes relevant standards and technologies and shows existing services and the business model behind the services.

1.2 Intended audience of this document This i-Travel Deliverable D1.1 “i-Travel State of the art” is aimed at the following audiences and respectively at the achievements of the following objectives: European Commission: present the work developed and achieved results within the Work Package 1 “State of the art and value chain analysis” inside i-Travel Travel Consortium partners: provide input for further Work packages, namely WP 2, WP 3, WP4 and WP5.

1.3 Structure of the Document After this introduction, chapter 2 presents an executive summary of the document.

The i-Travel project is described in chapter 3.

The description of the methodology used in this work package can be found in chapter 4.

Chapter 5 presents the state of the art related to the technology and standards

Chapter 6 presents policy issues including the licensing, patents, and IPR related issues, which might be relevant to i-Travel services and the platform implementation.

Chapter 7 describes existing services & case studies, which are today available on the market.

The most important business models of existing services are described in chapter 8.

Based on existing business models, and exiting services as in chapter 8, chapter 9 describes the conceptual business models.

In Chapter 10 unique business model modules are determined based on the conceptual models of the existing services.

In Chapter 11 the business model validation method is described for successful future i-Travel services.

2 Executive Summary

The objective of WP1 is to review the state of the art in traveller service technologies and to create an overview of the environment in which i-Travel is expected to operate.

The methodology is based on two parts. The desk research and the value chain analysis. The desk research surveys the technologies available and their suitability, describing a “snapshot” of existing travel and transport services, technologies and stakeholders. The value chain analysis contains value modelling, business modelling and business validation.

The results of al WP1 subtasks are used in other subtasks and all finally ends into state of the art information regarding i-Travel. This state of the art information is input to the following work packages: • WP2 Use Cases, Traveller & supplier requirements • WP3 Processes and services • WP4 Architecture 5 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

• WP5 Content and service supplier community

A long list of existing technologies/standards in relevant to i-Travel services are described like: • Constraints and features of the development environments for nomadic devices and smart phones to which i-Travel services could be delivered to travellers (different input and visualization methods, different communication capabilities) • Frameworks for handling event driven systems and agent ecosystems that could be adopted by the i-Travel project • Overview of possible distribution channels and their management • Review of available technologies suitable for gathering and adapting data to the eMarketplace, with their possible development trends • A review of trends of "context aware" technologies that could be available in the future for better pinpointing information in certain critical infrastructures such as airports, railway stations, bus stops.

In this document we explored the licensing, patents, and IPR related issues which might be relevant to i- Travel services and the platform implementation. We explored policy issues - deals with the all needs that should be met by the i-Travel system.

Conclusions

Technology and standards To research and design the global services for the connected traveller, enabling their instantiation and the exploitation of the added value brought by the project’s outcomes, the need of the intelligent mix of many technologies is essential.

To reflect the main requirements of the global service it is clear that the iTravel should be implementing the first Internet of Things application, working at the worldwide level.

It is clear that the iTravel relies on the IP connectivity, which should be bi-directional, e.g. the GPRS/UMTS communication with the RF (DVB) feedback enabling the ensured and synchronised uni-cast, group-cast, or the broad-cast.

It is also clear that the mobile representing a traveller should gather the context-related information and the indoor positioning and the outdoor geo-referencing, which might be done using GPS localisation in outdoor context plus some specific indoor technologies. The context awareness might be achieved by multi-sensorial devices, including those wearable, or AAL ones. Moreover, the RFID/NFC technology might be used for the context characterisation.

The broker, intelligent agent might be implemented using the standard Agent technologies, while the extended cooperation among distributed entities would be needed to exploit the social networks in the abroad’s topologies embracing several travellers presenting similar social interests, wishes and aims. The intelligent dimension should be supported by the reasoning and travel’s ontology.

The way the knowledge will be elicited, data fused, and the reasoning performed, would be delegated to the implementation, however partial intelligence should be available locally on the mobile devices being impossible to keep the link with the central server alive during the flight for example, because of the rules forcing to switch off all mobile devices inside the aircraft. The re-appearance of the mobile device in a new location (in roaming) is the discontinuity of the state sequence, however the new state is known apriori being known the travelling plan in advance.

Policies On the level of Community law, the legal framework within which iTravel will operate its services appears to be significantly complete and coherent. We did not find any specific legal issue, which may be particularly relevant to iTravel, which is completely left to national law, while we think that it should be covered by Community law. There are however some legal barriers to the future smooth operation of iTravel. The most significant of such barriers appear to be connected to the fact that Community law typically does not provide for full, but only for minimum harmonization.

6 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Privacy As far as the protection of privacy is concerned, we recall that the national law that will apply to specific iTravel services is the law of the place were the ‘controller’ (i.e. the iTravel actor interested in processing personal data of end users) is established. More specifically, the national law will be the same irrespective of the fact that the personal data processed by any iTravel actor may refer to end users of different nationalities.

This provision will clearly favour the development and operation of Value Added Services (and more generally of all iTravel services) requiring the processing of personal data of end users of different nationalities.

We believe that iTravel service providers may face difficulties because of this distrust (especially when small of medium firms) to provide their services across different European countries.

For this reason, we argue that in the field of privacy protection a shift from minimum to full harmonization (as currently discussed for other fields of intervention of the EU) may facilitate the provision of iTravel services that requires to a relevant extent the processing or retention of personal data of end users.

Protection of end users as consumers As far as the contractual protection of iTravel end users as consumers is concerned, similar conclusions and recommendations as for the protection of privacy may be formulated. Currently iTravel service providers would need to use different contract models or standard forms with respect to end users/consumers of different Member States. All Directives dealing with consumer protection provides only for minimum harmonization. Moreover, it is often reported that European national laws have implemented these Directives very differently, providing for different levels and kinds of consumer protection. Therefore, iTravel service providers would today not be able to rely on one single body of law concerning the protection of consumers. The field of consumer protection in the EU is currently under discussion. One of the possible outcomes of this discussion is to replace the present different Directives on consumer protection with one Regulation that would be directly applicable in all Member States.

Business service model There are many different existing services with a different business models and different combinations of business models in the area of i-Travel today. The services that are in the scope of i-Travel can be described as Mobile Commerce. Mobile Commerce (also known as M-Commerce, mCommerce or U- Commerce, owing to the ubiquitous nature of its services). Choosing the right business model for the services related to i-Travel is crucial. Even the most brilliant service will not be commercially successful for the provider if the chosen business model is not appropriate for the service. Therefore it is of high importance to define generic business models and criteria for the evaluation to be able to choose the right business model for the service. This document contains a validation model for future successful i-Travel services and business models.

7 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

3 i-Travel project

3.1 Project abstract

While a growing number of online services for travellers are available, these are mostly poorly integrated and not personalised. Furthermore, almost all are inaccessible to the traveller during the journey itself. None of these services detect and proactively inform the user of disruptive events relevant to the traveller’s specific journey, let alone propose appropriate trip options.

Content providers have difficulty to reach out to more than a small number of potential end users, while ensuring that their commercial and licensing terms are enforced. Service providers need to find and negotiate separately with a huge number of potential content providers in order to offer a comprehensive end-to-end service towards travellers.

“i-Travel” is an original concept for “the connected traveller” that combines three key innovations:

1. a “virtual travel assistant” service that accompanies a traveller before and throughout each journey, providing personalised, context-aware information and support whenever, wherever and however needed, based on: 2. the integration of e-commerce and internet technologies to create the first B2B “eMarketplace” in the traffic and travel information services sector, through which: 3. a wide-ranging community of content and service suppliers connects to customers through i-Travel to serve new markets of travellers needing instant delivery of content and trip support.

For the travellers, i-Travel puts the right information and the right services in the travellers’ hand, just when they need it. For the suppliers, being a member of the i-Travel community gives direct access to the one and only secure, dynamic marketplace where agents representing all the world’s “connected travellers” gather to buy real-time content and value-added travel services on behalf of their customers.

The i-Travel project is organised into the following work packages • WP 1 State of the art and value chain analysis • WP 2 Use cases, traveller and supplier requirements • WP 3 Processes and services • WP 4 Architecture • WP 5 Content and Service Suppliers Community • WP 6 Feasibility and development roadmap • WP 7 Virtual demonstrator and demonstration strategy • WP 8 Project coordination and dissemination

The consortium partners of the current i-Travel project (phase 1) are: Altea, CERTH - Centre for Research and Technology Hellas, DLR – German Aerospace Center, Ertico, ISMB – Istituto Superiore Mario Boella, LogicaCMG, Mizar Automazione SpA, Navteq, Oracle, PTV Planung Transport und Verkehr AG, Tele Atlas, TNO, Vialis, Flemish Government - Department Mobility & Public Works and Ygomi Europe Kft. The consortium leader is Ertico.

3.2 Work package 1 State of the art and value chain analysis

The objective of WP1 is to review the state of the art in traveller service technologies and to create an overview of the environment in which i-Travel is expected to operate. This assessment will include technical and non technical aspects.

The objective of WP1 is to identify success factors of i-Travel by lessons learned from previous research activities, projects and initiatives. WP1 shows existing services and the business model behind the services.

8 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

4 WP1 Methodology

The used WP1 methodology is showed in figure below.

Technologies, Standards, Patents & WP2 Policies Use Cases, Traveller & Desk supplier Research Existing services & requirements Case studies (36#)

Workbook Existing business Template models (13#) WP3 Processes and services Conceptual business models (13#) Value Description of existing

Modeling Template e3 Value business model (9#) WP4 Architecture State of State the art

Business model building blocks Business (~13#) Business Model Ontology Modeling Template

WP5 Content and service supplier community Workbook / Information request Information / Workbook business Business Validation model Template Validation Analysis CF

Figure 1. WP1 Methodology

The methodology consists of two major parts: the desk research and the value chain analysis. The desk research surveys the technologies, standards, patents and policies available and their suitability, describing a “snapshot” of existing travel and transport services, technologies and stakeholders. The value chain analysis contains value modelling, business modelling and business validation.

The coordination of the results is done by workbooks describing the work what has to be done and what information has to be delivered. Templates are created for formating and structuring the information.

The results of all subtasks are used in other subtasks and all finally ends into state of the art. This state of the art is input to the following work packages:

WP2 Use Cases, Traveller & supplier requirements • WP1 provides input for the stakeholders definition • WP1 provided input for supportive classification structure for different traveller types • WP1 provides input for scenarios and use cases • WP1 provides input for classification of supplier types • Based on the value chain analysis from WP1, a framework and methodology for identifying drivers and barriers for users and for developing the user needs and use cases will be created in WP2.

WP3 Processes and services • Based on the business models of existing services from WP1 and the experiences and goals of the relevant partners, WP3 will provide a clear, harmonised and unambiguous picture of the required business processes currently in place for the provision of traveller information services.

WP4 Architecture 9 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

• WP1 provide different state of the art system technology options & trade-offs WP5 Content and service supplier community • WP1 provide value chain analyzes input used for identifying different types of stakeholders and identified relevant business models that are attractive for them. Input for convincing partners to join the community.

Below the WP1 steps are described in detail.

Technologies & standards The objective of this subtask is presenting the state of the art related to the technology with some considerations about the adoption of the technologies for the i-Travel platform implementation.

Input: Workbook desk research Output: This subtask explores existing technologies/standards in aspects such as: • Constraints and features of the development environments for nomadic devices and smart phones to which i-Travel services could be delivered to travellers (different input and visualization methods, different communication capabilities) • Frameworks for handling event driven systems and agent ecosystems that could be adopted by the i-Travel project • Overview of possible distribution channels and their management • Review of available technologies suitable for gathering and adapting data to the eMarketplace, with their possible development trends • A review of trends of "context aware" technologies that could be available in the future for better pinpointing information in certain critical infrastructures such as airports, railway stations, bus stops.

Existing Services & Case studies The objective of this subtask is to identify lessons learned from previous and today services, research activities, projects and initiatives.

Input: Workbook desk research Output: This subtask describes a number of specific existing services and case studies derived from i-Travel partners’ own experience, based on real locations.

Existing Business Models The objective of this subtask is to understand the trends and lessons from market evolution and provide a base for the commercial business model for i-Travel.

Input: Workbook desk research, Existing Services Output: This subtask generates an overview of possible distribution channels and their management.

Policies, IP & Patents The objective of this subtask is to consider the main European policies relevant to the eMarketplace with specific emphasis on electronic data exchange, privacy and Digital Rights Management for content. In relation to standards, the activity will consider patents, de jure and industry consortia standards.

Input: Workbook desk research Output: Policies, IP & Patents issues related to i-Travel. 10 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Value engineering template document In this step the value model template will be designed based on the value engineering methodology e3Value. This value analysis describes which stakeholder delivers output to another and who is paying whom for which output. The values engineering has to show the business model for the systems/market place. Input: Workbook value chain analysis Output: Conceptual business model template

Conceptual Business Models The objective of this subtask is to create conceptual models of existing business models. These conceptual business models make it able for analyzing the business models in detail and find uniform business model modules. In this step conceptual business models are developed per existing business model from the desk research and recorded in the value engineering template.

Input: Workbook value chain analysis, Existing business models from the desk research, Conceptual business model template Output: Conceptual business models.

Description of business models In this step conceptual business models are described in detail. Detailed information needed for analyzing the models is added.

Input: Workbook value chain analysis, Conceptual business models. Output: Descriptions of the conceptual business models.

Business model modules In this step based on the conceptual business models unique business model modules identified and developed. Each business model module could be a part of a successful i-Travel business case.

Input: Workbook value chain analysis, Conceptual business models. Output: Business model modules

Business validation model The objective of this step is to create a validation model for future successful i-Travel services. The business validation model will deal with cost structures, profit structures, cash flow profiles and business indicators like break even point and payback time.

Input: Workbook value chain analysis, Business model modules Output: Business validation model

11 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

5 Technologies & Standards

5.1 Structure of the chapter

The chapter is structured as white paper presenting the state of the art related to the technology with some considerations about the adoption of the technologies for the i-Travel platform implementation. The chapter starts from the traveller needs, to depict the possible structure of the technological solution supporting the service model to satisfy such needs. The document speaks about the information systems for traveller and the related service-oriented architectures. It introduces the “intermittent” state requiring the event-driven architecture, so describing frameworks and languages related. It presents data formats, data synchronisation, distribution channels, and relevant SW frameworks. Finally it speaks about B2B, agents and context awareness. It contains also the Annex I showing patents, licensing and other IPR issues, which might be relevant to the i-Travel project.

5.2 The traveller needs

5.2.1 Task model

The results of the panel of travellers show that travel is a dynamic process within which the user has to realise different tasks: planning, tracking and assessment.

Figure 2. Travel process First of all, the user is preparing his/her future travel, and the planning step defines how the tasks must be performed to attain the travel’s goals, and each user has different task criteria concerning his personal context and reasons for travelling. During the trip, the results highlight that the main task carried out by the traveller is 'tracking' which includes two sub-topics: orientation and decision making. The last results show that the user acquires experiences from his travels and applies the new knowledge to future trips. A feed-back loop assesses tasks to influence the planning and the tracking tasks. The defined travel process sequence consists of three time-based tracks:

Figure 3. Three time-based tracks The travel process (travel sequence) as decided consists of three time-based contexts:

12 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Types of information Types of information Types of information trip -planning ticket localisation and orientatio n localisation ordering/reservation and checking orientation payment anticipation real time pre-checking information (disturbances, traffic/weather conditions, etc.) Recommended functions Recommended functions Recommended functions planning trip re -conception orienting checking signing signing warning overlapping customising

Types of system Types of system Types of system Home terminals on -board collective/individual interactive map terminals portables public Interactive Terminals bus stop displays,etc.

The classification of i-Travel service. Error! Reference source not found.

5.2.2 Service model and related SWOT criteria

Travelling nowadays is a nomadic activity, performed in a border-less context, characterized by the interaction with several stakeholders and several national operators offering the underlying IP connectivity. The service context hence is nomadic, ubiquitous, and hectic. The service context is not invariant, it is rapidly and frequently changing, it is not the same in different countries being visited during the trip, because of the national economies, roaming and other factors. The i-Travel service model might be conceptualised to be the one-stop-shop for services offered in a seamless way through the eMarketplace layer. The added value is generated through the ubiquitous service availability, the proactivity and context sensitiveness, and the brokerage. The graphical representation follows:

Figure 4. i-Travel service model The i-Travel service strength would be: the ubiquity, to serve the connected traveller during the trip, the context awareness and the data fusion capacity, to deliver proactvie and meaningful service,

13 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

the capacity to manage the intermittent state of the object representing the traveller (mobile device) notably presenting the online-offline-online sequence of states the capacity to deliver some reasoning (decision making) in terms of the possible service selection

All above-said findings are in line with the new paradigm of the Internet of Services (in the context of the Internet of Things), which should be applied to the i-Travel business.

Actually the main weakness of the available services is the lack of the globality and the lack of a holistic approach. There are some examples of global services for travellers (e.g. Expedia), however those are mediated by the vendor-dependant stakeholder. Most of the available services are fragmented, not integrated, and limited by countries’ borders. A further weakness is the gap between the Internet of Things and the Internet of Services. There are no standardised solutions in terms of the extended middleware/firmware to manage the intermitted nature of the things’ state. The envisaged global service for the connected traveller, in terms of SWOT analysis, should assess the following business dimensions: • the cost of the IP connectivity in roaming impacting on the fixed costs to keep alive the global link with the i-Travel service center • the capacity to keep the session (to commit the pending distributed transactions), to restore the lost transactions, and to elaborate the change state • the global services available for the inclusion in the e-Marketplace and their costs; to understand the margin available for the broker to set up the new business on top of the existing one • the stability and the standardisation of the interfaces (APIs) to ensure the service interoperability, being i-Travel integrating several national services in a supra-national value chain • the dynamic service composition reflecting the context.

A possible reference model is graphically represented al follows:

Front end Traveller accessing travel services through fixed or mobile terminal

Human Machine Interface (mobile terminal) Traveller- related Online/offline and data synchronisation engine events

T-Event manager I-Event Personal Travel Agent Authentication Workflow manager management

Logic rules User Model

eMarketPlace SP1 Independent SP2 Independent SPm Independent events events events Mobility Air travel Accomodation

Maps Traff info Flights A Flights B Hotels Restaur. . . .

Figure 5. Reference model

14 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

5.3 Information Systems for traveller

Information sources/systems for traveller are typically: • Published on paper books (traditional content) • E-Publications (pull or push approach to retrieve the eContent) • Guidance and Advertisement solutions (passive or proactive ones) • Personal Navigation systems • Mobile assistants interacting with the environment and • Context-aware ubiquitous systems • Social networking instruments, comprising collaboration and messaging tools • … This section provides a short overall view of telematic-based ICT-enhanced information systems (including public transport ones) currently in operation or in the process of being implemented. System families that have been evaluated are:

Figure 6. Telematic-based ICT-enhanced information systems

5.3.1 At-stop Display

Visual information appears extremely useful for the travellers. Currently the delivery of the information and the commercial ADs is done using auto-synchronised digital radio displays. Frequently such devices can interact with personal smart phones sending them a copy of the displayed data. At-stop and street displays appears important for connected traveller because they could be considered the contact point between the service operator and the end-user in the global context. Traveller might wish to capture some data from the screen, and it is typically doing this using photo camera integrated in the Smartphone. The capacity of such advanced devices (displays) to interact with the mobile terminals wireless delivering some data for the delayed sub-sequent fruition appears important for improving the context-sensitiveness of the services. It seems reasonable to propose the possibility to capture data, for instance using the mobile device: a portion of what is shown or what was shown on the display might be “inherited” from the above- mentioned displays. This interaction with the display would deliver also some feedback to the operator.

15 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Figure 7. Interaction with the display

This chapter would be relevant for the implementation of the Global connected traveller-related solution.

There are at least 170 telematic-based public transport information systems currently in use in Europe Error! Reference source not found. . The number of public transport Web sites in the European Union is around 600. However, this number is constantly growing. Current systems with main characters of information services and ergonomic features are listed in tables. There is a table for each system family. Information on the systems was collected by sending inventory forms to contact persons for the relevant systems (INFOPOLIS project).

Web Sites were studied by browsing the Internet.

All telematic-based PT information systems complement the conventional media (timetables, network maps, etc) by providing data which are likely to be more reliable (near real-time data). The general trends are as follows: • to make real time information available to the user, • to extend information to multimodal solutions, • to make information available by a great variety of means • to provide personalized data via interactive systems. Underlying technologies (AVL, mobile communications and Internet) are critical for these requirements. New services are emerging on the market (PT Web sites, portable systems, In Car terminals,..), and interactive PT terminals are now widespread throughout Europe.

Over sixty systems were analysed. Route number, destination of the arriving vehicle and waiting time are available on all systems while information on network disturbance is only available on half of them. Regarding ergonomic features, we can indicate that LCD and LED are similarly widespread. Also, 25% of analysed systems take into account disabled people's needs. Finally, an increase of 5 or 6% of patronage on the lines equipped has been noticed in Brussels and Liverpool.

Real time at-stop information is probably the one which best meets user expectations. At-stop displays usually display waiting times. Also, the location of the arriving vehicle can be shown. The knowledge of waiting time greatly improves the conditions of the trip in two main ways: 1. by removing uncertainty (When will the bus arrive? Has the bus already passed?) 2. by minimising waiting time (passenger is enabled to do shopping, etc).

5.3.1.1 Main Systems

INFODYN (Brussels) PHOEBUS Extension INFOPLUS (Brussels) HELMI (Finland) PHOEBUS (Brussels) Project 423 (Helsinki FI) ELMI (FI) PIU (SAE) (Barcelona) HELSINKI METRO PLATFORM DISPLAYS SAE Vallodolid (SP) INFO TUB (Douai FR) BUSLINK (UK) INFO TAN (Nantes FR) TIMECHECKER (UK) ALTAIR (Paris FR) QUEST (Sheffield UK) VIDEOBUS (Le Havre FR) INFRAVOICE (UK) MOBILE (SP) KomFram:LED display (SW) PARLIN (SP) KomFram:Electromechanical display COUNTDOWN (London UK) KomFram :Post display (LCD) CENTRO (Birmingham UK) KomFram: monitors SUPEROUTE 66 BUSNET (UK) Umea displays (SW) BUSTIME (Glasgow UK) Eskilstuna displays (SW) STOPWATCH (UK) ELFI (Trier Ge) TIMETRAVEL (UK) Osnabrück displays (Ge) BUS STOP DISPLAY BOLOGNA (IT) Zugziellanzeiger Dortmund (Ge) PALINE INTELLIGENTI (Genoa IT) Berlin U-bahn display

16 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

VIA (Tu rin IT) Bielefeld Display (Ge) PIDS (Hong-Kong) Led-matrix (Düsseldorf Ge) METRO-NORTH RAILROAD (New-York USA) Hamburg metro display (Ge) CHICAGO TRANSIT AUTHORITY (USA) Matrix (Schwerin Ge) ASEAG (Aachen Ge) DFI (Stuttgart Ge) FGI (Wiesbaden Ge) LYON at-stop displays (FR) FGI (Lüdenscheid Ge) Charleroi Displays (BE)

5.3.1.2 Review of information services

Most of the real time info points for users are street and bus stop displays. In addition, there were some metro platform and train station display systems surveyed, but the conclusions mostly concentrate on bus stop displays. Existing at-stop displays provide real-time information on the arrival of the next vehicles. The content of the given information is usually the same: route number, destination of the arriving vehicle and waiting time. Some displays show the location of the arriving vehicle on a linear map. About half the systems give information on service disruptions. The Metro platform displays in Helsinki give information about the vehicle: they use a symbol to display the length of the train. The most common additional information is current time, some displays can give free text messages.

We conclude anticipating the possible use of well synchronised urban information delivery channels (including those for real-time delivery) as above-described for the fruition of related and connected services, after data fusion and knowledge elicitation processes to be performed by global services. For instance the contextualised portion (extract) of the events or the timetable might be used by the traveller to schedule the optimised route and planning for an evening.

5.3.2 Instant Messaging and Presence

The battle of instant messaging in 3G world seems to involve these three (3) standards: 1. IETF’s SIP/SIMPLE - In the spirit of all IETF protocols, this is another clean and simple protocol on top of the immensely popular voice-over-IP protocol, SIP. Gaim even has a client plugin that supports SIP/SIMPLE (sponsored by Google’s Summer of Code program). 2. IETF/Jabber’s XMPP - This is currently the most popular of the three (3) mentioned here. This is also the protocol that Google talk is using for its instant messaging service. It was originally designed by the Jabber community and has been recently accepted by the IETF. 3. OMA/Wireless Village IMPS - This protocol was initially developed as the original standardized solution for mobile instant messaging. However, it does not have as wide a community support as the others. Also this is designed as a walled garden approach which is favoured by the Telcos.

5.3.2.1 SIP/SIMPLE

In computing, SIMPLE, Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (Wiki http://en.wikipedia.org/wiki/SIMPLE) is an instant messaging (IM) and presence protocol suite based on Session Initiation Protocol (SIP). Like XMPP, and in contrast to the vast majority of IM and presence protocols used by software deployed today, SIMPLE is an open standard. Both are IETF standards or proposed standards. [1] Despite its name, SIMPLE is defined by about 30 documents or more than 1000 pages (7 times more than HTTP 1.1, 15 times more than SMTP and IRC). Some parts have been standardized, e.g. RFC 3428. Other parts, in particular IM sessions, are still under discussion. However, several implementations are already available, including the Microsoft Windows Messenger. SIMPLE applies SIP to the problems of: • Registering for presence information and receiving notifications when such events occur, for example when a user logs-in or comes back from lunch. • Sending short messages, analogous to SMS or two-way paging. • Managing a session of real-time messages between two or more participants.

5.3.2.2 Instant Messaging and Presence Service (IMPS)

Instant Messaging and Presence Service, Wiki http://en.wikipedia.org/wiki/IMPS , is an OMA (Open Mobile Alliance) enabler for Instant Messaging and Presence. The Wireless Village consortium developed the first 17 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

cut of the specifications. After Wireless Village was merged with OMA, its specs became OMA IMPS 1.0 specifications. IMPS is widely deployed but not necessarily marketed. Interworking between several operators IMPS platforms is being performed under a GSMA initiative that encourages interworking and deployment of Instant Messaging. The general architecture of IMPS is described in the picture below: IMPS clients connect to Service Access Points using different protocol bearers (Mobile IP, HTTP, SMS) Service Access Points implement different Service Elements for Presence, IM, Group Management Proprietary protocols and servers may be accessed via gateways

Figure 8. IMPS General architecture

Protocols such as IMPS can be used by the i-Travel platform for communicating with user terminals, both for pushing data to phones and for collecting user context data. The main advantage is its availability in most of the high end mobiles on the market, and the fact it is a protocol endorsed by most mobile operators, though not well supported at the moment (rolling out of services is rather slow). A main disadvantage, instead, is the lack of customization at client side (it’s difficult to build custom applications based on IMPS) and the difficulty to access IMPS server.

Availability IMPS is implemented in most Nokia, Sony, Motorola, though the service is usually tied to the mobile operator. On the server side there are few IMPS vendors such as Colibra, OZ Communication, Neustar, Wireless ZT that may use either the official client already installed on the phone or other clients that may be downloaded. There aren’t however free implementations and client libraries are difficult to find.

Error! Reference source not found.

5.4 Service Oriented Architectures (SOA)

SOA (defined also on Wiki website and wikipedia.org/wiki/Service-oriented_architecture) is an architectural style of building software applications that promotes loose coupling between components so that developers can reuse them or build complex services by aggregating simple services taken from a distributed network of suppliers. Thus, it's a new way of building applications with the following characteristics: Services are software components that have published contracts/interfaces; these contracts are platform- , language-, and operating-system-independent. XML and the Simple Object Access Protocol (SOAP) are the enabling technologies for SOA, since they're platform-independent standards. Consumers can dynamically discover services supplied by third parties using directories (e.g. with UDDI) Services are interoperable, and they are designed in order to be used by third parties as well within the organization; therefore SOA is not just an architecture of services seen from a technology perspective, but the policies, practices, and frameworks by which it is ensured the right services are provided and consumed. The basic building block of SOA is the service. A service is a self-contained software module that performs a predetermined task: "verify a customer's credit history," for example. Services are software components that don't require developers to use a specific underlying technology.

18 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

In the simplest scenario as in the following picture the SOA approach is composed by: • A “service provider” (the business logic implementation) and a software module exporting the service through the network (the “service”) • A consumer accessing the remote service as a “client” • An optional service broker or directory where services are published by suppliers and browsed by consumers

Figure 9. Minimal Service Oriented Architecture

More complex architectures are possible, as shown in the next figure. Service providers may be structured in layers tackling different aspects of the complexities related to remotization, such as: • Access to local resources (internal services, static resources, databases) • Handling business logic (i.e. service state and workflow) • Communication layer (service interface definition and transport binding) • Additional vertical layers for enforcing security, applying policies and managing the system

Figure 10. General Service Oriented Architecture Schema

The common interaction paradigm is based on the REQUEST / RESPONSE paradigm, similar to a remote procedure call where the service is the piece of code performing a task or a calculation and the client is the one utilizing it. According to this paradigm, the interaction is mainly synchronous, i.e. the client must start the action and it blocks waiting for the result. However the typical i-Travel tasks are event driven and interactions should usually be started by producers (services) and consumers (clients) should be automatically triggered when some interesting event happens. Nevertheless more complex interaction paradigms such as event driven or publish subscribe frameworks are available. Some are integrated in 19 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

general purpose SOA architectures as optional messaging channels typical of the large commercial SOA platforms; others offer asynchronous messaging as standalone communication channels, such as JMS, or they are naturally supported by protocols like XMPP, SIP and OMA’s IMPS. In the next paragraphs these approaches will be analysed in depth in order to have a better picture of the technologies present on the market suitable for building the i- Travel platform.

5.4.1.1 Trends The SOA market is in continuous evolution with new features continuously added to the commercial suites present on the market. The Gartner Magic Quadrant below shows that the number of companies in the “visionary” half of the quadrant is high, and therefore the forecasted innovation in the sector is high, though there are three major players well positioned in the “leaders” quadrant. Moreover there are new trends that could accelerate the innovation process:

Connection with mobile clients , which have a number of issues that should be tackled with ad hoc solutions. Mobile clients in fact require ad hoc protocols for synchronizing resources with the backend optimizing bandwidth and for adding reliability and security to the communication channel. Moreover services and applications must be designed for being effective and usable with restricted and limited execution environments.

Integration with Web 2.0 applications, with collaboration features (human role becomes prominent in service). Web 2.0 refers to a "second generation" of web sites, primarily distinguished by the ability of visitors to contribute information for collaboration and sharing. Web 2.0 applications use Web services and may include Ajax, Flash, or JavaFX user interfaces, Web syndication, blogs, and wikis. While there are no set standards for Web 2.0, it is characterised by building on the existing web server architecture and using services. Web 2.0 can therefore be regarded as displaying some SOA characteristics.

Mashups are also regarded by some as Web 2.0 applications. The term "enterprise mashup" has been coined to describe Web applications that combine content from more than one source into an integrated experience, which share many of the characteristics of service-oriented business applications (SOBAs), which are applications composed of services in a declarative manner. There is ongoing debate about "the collision of Web 2.0, mashups, and SOA", with some stating that Web 2.0 applications are a realisation of SOA composite and business applications.

These trends will make SOA platforms even more suitable to the i-Travel scenario in future, since they already match some of the problems currently address by the i-Travel project, such as real time connections and synchronisation with mobile clients, multimodal access, mashup of services.

Figure 11. Gartner Magic Quadrant for New Service-Oriented Business Application Projects, 2Q07 20 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Error! Reference source not found. -Error! Reference source not found.

5.5 Event Driven Frameworks & Languages

Event-based systems are those in which information provided by producers is distributed in a timely manner to interested consumers. Event-systems can be considered on the middle-ware level or on application level. Event-based applications are often found in streaming systems, surveillance and monitoring systems, or continuous query systems. Event-based systems can be used to integrate a wide range of components into a loosely-coupled distributed system: for example, event producers can be application components, post-commit triggers in a database, sensors, or system monitors; event consumers can be application components, device controllers, databases, workflow queues, etc. These systems are seeing increasingly widespread use, in applications ranging from time-critical systems, system management and control, to e-commerce. Event-based systems are rapidly gaining importance in many application domains ranging from real time monitoring systems in production, logistics and networking to complex event processing in finance and security. The event based paradigm has gathered momentum as witnessed by current efforts in areas including event-driven architectures, complex event processing, business process management and modelling, Grid computing, Web services notifications, information dissemination, event stream processing, and message-oriented middleware.

A common service interface provided by event-based systems is the publish-subscribe paradigm: producers and consumers can be mutually anonymous, producers deliver events to topics, each consumer specifies interest by means of a "subscription", and later receives events of interest via event notifications; the event-based system is responsible for consolidating subscriptions and propagating events. Queuing and hybrids of publish-subscribe and queuing are also popular. Event-based systems are seeing increasingly widespread use, in applications ranging from time-critical systems, system management and control, to e- commerce. Publish-subscribe services have been incorporated into standards such as CORBA, JMS and XMPP and into commercial systems, such as offerings of Microsoft, Oracle, IBM and TIBCO. Event based systems are of particular interest in the iTravel platform, since they allow to easily integrate heterogenous services without tight coupling and their patters are more alike the typical iTravel patterns. iTravel agents, in fact, should be able to react in near real time to events generated in remote systems. Polling or closed agreements are not scalable solutions and they may seriously hinder the growth of the iTravel market place. Unfortunately there aren’t widespread and universally accepted standards for event based systems, however there are several applications based on common communication patterns. Usually event driven middleware may be classified accordingly to the following criteria (all relevant to the different iTravel components):

Distributed Active Systems (DAS) support building applications that must monitor and react to changes in the environment, information of interest or process status. The publish/subscribe interaction paradigm is at the heart of DAS. DAS describes with a good approximation the iTravel backend, which will be likely based on the interaction of heterogeneous services exploiting this type of interaction patterns

Ubiquitous and Mobile Systems (UMS) cover applications characterized by the heterogeneity of systems and devices, as well as the (spontaneous) patterns of interconnection. Moreover, contrary to traditional distributed problem solving, there is not only one global problem to be solved but, due to the user-centric nature, a number of local problems. Relevant issues are naming, service trading, context- and location awareness. UMS describes the complex interactions between the iTravel backend and the user terminals.

Message Oriented Middleware (MOM) is a specific class of middleware that supports the exchange of general-purpose messages in a distributed application environment. There is a wide spectrum of MOM encompassing publish/subscribe based systems and message queuing systems. MOM supports data exchange and request/reply style interaction by publishing messages and/or message queuing in a synchronous and asynchronous (connectionless) manner. The MOM system ensures message delivery by using reliable (and persistent) queues or reliable multicast and provides directory, security, and administrative services.

21 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Due to the nature of the applications within the iTravel platform, most of the data exchanges will be based on the exchange of messages, with particular attention to the QoS in message timing and the reliability of the delivery channel

Error! Reference source not found. - Error! Reference source not found.

5.5.1 Technologies

5.5.1.1 Corba The Common Object Request Broker Architecture (CORBA) is a standard defined by the Object Management Group (OMG) that enables software components written in multiple computer languages and running on multiple computers to work together. Definition is available on Wiki http://en.wikipedia.org/wiki/CORBA. CORBA uses an interface description language (IDL) to specify the interfaces that objects will present to the outside world. CORBA then specifies a “mapping” from IDL to a specific implementation language like C++ or Java. Standard mappings exist for Ada, C, C++, Lisp, Smalltalk, Java, COBOL, PL/I and Python. There are also non-standard mappings for Perl, Visual Basic, Ruby, Erlang, and Tcl implemented by object request brokers (ORBs) written for those languages. The CORBA specification dictates that there shall be an ORB through which the application interacts with other objects. In practice, the application simply initializes the ORB, and accesses an internal Object Adapter which maintains such issues as reference counting, object (& reference) instantiation policies, object lifetime policies, etc.

Figure 12. IPC through CORBA The main limitation of CORBA in the i-Travel context is the scope of the specifications: while CORBA is a viable way for distributed interprocess communication using request/response interrogation patterns (i.e. remote procedure calls), all the issues related to asynchronous communications and distributed event handling is left out from the specifications. Other non i-Travel specific issues related to CORBA that have limited its application in history:

Commercial CORBA implementations typically cost several thousand dollars per development seat, plus, in many cases, runtime royalties for each deployed copy of an application. This limited broader acceptance of the platform—for many potential customers, CORBA was simply too expensive. The platform had a steep learning curve and was complex and hard to use correctly, leading to long development times and high defect rates. Early implementations also were often riddled with bugs and suffered from a lack of quality documentation. Companies found it difficult to find the expert CORBA programmers they needed. Microsoft never embraced CORBA and instead chose to push its own DCOM (Distributed Component Object Model). This kept much of the market either sitting on the fence or using DCOM instead, but DCOM could not win the middleware battle either, because it worked only on Windows.

Error! Reference source not found. , Error! Reference source not found.

22 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

5.5.1.2 Web services Web services provide a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks. Web services are characterized by their great interoperability and extensibility, as well as their machine-processable descriptions thanks to the use of XML. They can be combined in a loosely coupled way in order to achieve complex operations. Programs providing simple services can interact with each other in order to deliver sophisticated added-value services.

Figure 13. Example of a client/ server application implemented with web services

In the above figure there is an example of a simple distributed application based on web services. The main features are: • web services are based on the exchange of messages encoded in XML • standard existing Internet protocols are used in order to transport the messages • mainly HTTP, but SMTP and XMPP are common alternatives • reuse of existing Internet infrastructure • easy firewall traversing • web services usually follow the client/server pattern, but any type of message flow can be used, provided the correct transport is used (e.g. not all the protocols support push for example) • most application servers provide modules supporting web services • the range of application is wide, ranging from simple remote DB access, to complex tasks such as real time messaging in financial transactions • web services can be implemented using a wide set of protocols, most common are SOAP (W3C standardized) and XML-RPC (independently standardized)

Historically XML-RPC has been the first approach to web services, but it has a very limited scope since it tries to simply solve the problem of interoperability in remote procedure calls with simple basic data types. SOAP is a more general protocol, allowing any type of message exchange patterns and it can carry any complex data structure. Moreover SOAP has a quite large set of standard extensions allowing composition, orchestration, description, security, definition of policies, etc, making it a general purpose framework for building remote applications. The main standardization process about SOAP and web services is carried on inside W3C with a set of dedicated working groups:

XML Protocol Working Group Main set of standards defining encoding, message format, message exchange patterns, transport bindings and set of possible optimizations (binary encoding). Therefore this set of standards defines the basic rules (the grammar) for exchanging XML messages used of inter-process communications in distributed environments.

Web Services Description Working Group 23 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Mainly focused on the Web Services Description Language (WSDL), which is a XML based language and a set of rules whose aim is describing the interface of web services. Through WSDL clients applications can discover the format of any input and output message supported by a service, the name of the supported operations (names ports), and the supported bindings (the actual transports used for exchanging the messages). No semantics is associated to WSDL descriptions, the only purpose is to give a machine processable and language and platform independent description of the web services in order to allow the automatic creation of local stubs and simplify the development of clients.

Web Services Addressing Working Group Web Services Addressing provides transport-neutral mechanisms to address Web services and messages. Web Services Addressing 1.0 - Core defines a set of abstract properties and an XML Infoset (XML Information Set) representation thereof to reference Web services and to facilitate end-to-end addressing of endpoints in messages. This specification enables messaging systems to support message transmission through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner

Semantic Annotations for WSDL Working Group A set of extension attributes for the Web Services Description Language and XML Schema definition language that allows description of additional semantics of WSDL components. The specification defines how semantic annotation is accomplished using references to semantic models, e.g. ontologies. Semantic Annotations for WSDL and XML Schema (SAWSDL) does not specify a language for representing the semantic models. Instead it provides mechanisms by which concepts from the semantic models, typically defined outside the WSDL document, can be referenced from within WSDL and XML Schema components using annotations. A “modelReference” can be used to annotate interface elements, to categorize them according to some model, to specify behavioural aspects or other semantic definitions. A modelReference on a WSDL interface element provides a reference to a concept or concepts in a semantic model that describe the Interface. The taxonomies supported by Universal Description, Discovery and Integration (UDDI) can be used in order to categorize an interface (this allows automatic, but controlled, categorization of services once inserted in the i-Travel platform)

Web Services Policy Working Group Web Services Policy Framework defines a base set of constructs that can be used and extended by other Web services specifications to describe a broad range of service requirements and capabilities. Policies refer to domain-specific capabilities, requirements, and general characteristics of entities in a Web services-based system. Some policy assertions specify traditional requirements and capabilities that will manifest themselves in the messages exchanged (e.g., authentication scheme, transport protocol selection). Other policy assertions have no wire manifestation in the messages exchanged, yet are relevant to service selection and usage (e.g., privacy policy, QoS characteristics). Web Services Policy 1.5 - Framework provides a single policy language to allow both kinds of assertions to be expressed and evaluated in a consistent manner. In the i-Travel scenario the ability of expressing policies about used web services is of paramount importance. In fact the required level of trust and reliability of the travel agent can be reached only if some properties of the used web services can be automatically verified and enforced, task for which simple SLAs cannot be sufficient.

The following figure illustrates a more complex, but still typical, scenario of a distributed application based on web services. The deployment cycle can be described as it follows:

• The service provider writes the objects handing the supported operations and it places them in a web service container (usually a web container) • The service provider exports the services, by publishing the automatically generated service description (WSDL) via web • Optionally the service provider can register the service in a UDDI service broker, which is a public registry of web services that can be queried in order to find the required functionalities • The service requester queries the service broker (based on UDDI) in order to find the providers of the needed services

24 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

• The requester downloads the description (WSDL) of the selected services, which contain the format of the exchanged messages, the name of the supported operations and the transport bindings • The local stubs for accessing the remote services are generated and integrated in the client application • The client may start using the remote service via SOAP

Figure 14. Complete web service infrastructure, with service discovery through UDDI, automatic stub creation with WSDL and remote service access. Availability The acceptance of SOAP is so wide that almost all free/commercial web containers have modules supporting web services, and any language has SOAP libraries. They mainly differentiate in the supported features and extensions: while basic SOAP and WSDL are universally available, other specifications such as policy definition are implemented by few containers and their interoperability must be verified. Listing and analysing all the available SOAP libraries is out of the scope of this document (see http://www.soapware.org/directory/4/implementations for a comprehensive list). In the i-Travel context we simply highlight the availability of SOAP implementations for small footprint devices, such kSOAP for J2ME, making it a possible communication mechanism with the supported user terminals too.

Error! Reference source not found. -Error! Reference source not found.

5.5.1.3 Universal Description Discovery and Integration (UDDI) Universal Description, Discovery and Integration (UDDI) is a platform-independent, XML-based registry for businesses worldwide to list themselves on the Internet. UDDI is an open industry initiative, sponsored by OASIS, enabling businesses to publish service listings and discover each other and define how the services or software applications interact over the Internet. A UDDI business registration consists of three components, which allows different types of categorization and search: • White Pages: address, contact, and known identifiers; • Yellow Pages: industrial categorizations based on standard taxonomies; • Green Pages: technical information about services exposed by the business.

Examples of category/area codes that may be used for classifying services: • UNSPSC: United Nations Standard Products and Services Code, GS-1 managed international registry for product codes (search by product type) • NAICS: North American Industry Classification System (search by product type) • ISO 3166: standard for county codes and dependent areas (geographic search)

Figure 15. Relationship between UDDI and Webservices UDDI enables applications at being able to programmatically search a directory of published services, in order to identify the needed “sources” for completing a given operation. For this purpose UDDI exposes its

25 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

data through a set of operations known as the inquiry API. UDDI also exposes the publishing API which can be used to register businesses and services with UDDI. Service references are stored in the UDDI database by the mean of data structures named businessEntity. A businessEntity is an XML document which is used to represent a business or, more generally, a service provider. Each businessEntity may contain services represented by businessService structures that describe what the service provides (either programmatically with taxonomies or with a human readable description). A businessService contains also binding Templates which describe how to connect with the service and it points to a tModel structure, which defines the supported interfaces (e.g. a WSDL document). Businesses might be related (e.g. a parent-child business relation) using publisherAssertion structure.

Figure 16. A businessEntity template pointing to a tModel Another interesting feature of UDDI for the i-Travel scenario is the capability of supporting arbitrary complex distributed service publishing and propagating schemes. UDDI in fact handles private registries, shared non public registries (institutions mutually exchange service announcements accordingly to a given SLA), and public registries where anybody can publish or search for services. The following picture shows a conceptual UDDI network with different types of affiliations among the different registrars.

Figure 17. Conceptual overview of UDDI Registry affiliation

Availability UDDI clients are available for most programming languages and development platforms (examples: uddi4j for java, uddi4py for python, uddi4r for ruby, UDDI.NET for .NET, UDDI:Lite:: for perl) Servers are numerous as well: Apache, Microsoft, Oracle, IBM, HP, Tibco, BEA, SAP and many others have implementations available. Instead there is stagnation in the area of public registries (e.g. Microsoft and IBM have discontinued their public UDDI servers), but there is no evidence that highly specialized registries such as a possible i-Travel UDDI registry won’t have success (the problem may be related to generic services without community support, than to the technology itself)

Error! Reference source not found. -Error! Reference source not found.

5.5.1.4 Java Message System (JMS)

26 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

The Java Message Service (tutorial on http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JMS3.html) is a Java API that allows applications to create, send, receive, and read messages. Designed by Sun and several partner companies, the JMS API defines a common set of interfaces and associated semantics that allow programs written in the Java programming language to communicate with other messaging implementations. JSM is content neutral, that to say that it acts as a transport for messages, and therefore it can be used in order to transport application data arbitrary formatted such as SOAP messages A JMS application is composed of the following parts. A JMS provider is a messaging system that implements the JMS interfaces and provides administrative and control features, and it behaves as rendez-vous between the different clients JMS clients are the programs or components, written in the Java programming language, that produce and consume messages. Messages are the objects that communicate information between JMS clients. Administered objects are preconfigured JMS objects created by an administrator for the use of clients JMS supports two message models:

1. Point-to-Point Messaging A point-to-point (PTP) product or application is built around the concept of message queues, senders, and receivers. Each message is addressed to a specific queue, and receiving clients extract messages from the queue(s) established to hold their messages. Queues retain all messages sent to them until the messages are consumed or until the messages expire 2. Publish/Subscribe Messaging In a publish/subscribe (pub/sub) product or application, clients address messages to a topic. Publishers and subscribers are generally anonymous and may dynamically publish or subscribe to the content hierarchy. The system takes care of distributing the messages arriving from a topic's multiple publishers to its multiple subscribers. Topics retain messages only as long as it takes to distribute them to current subscribers

Figure 18. JSM main concepts: Queue

Figure 19. JMS main concepts: Topic Messaging products are inherently asynchronous in that no fundamental timing dependency exists between the production and the consumption of a message. However, the JMS Specification uses this term in a more precise sense. Messages can be consumed in either of two ways: Synchronously. A subscriber or a receiver explicitly fetches the message from the destination by calling the receive method. The receive method can block until a message arrives or can time out if a message does not arrive within a specified time limit. Asynchronously. A client can register a message listener with a consumer. A message listener is similar to an event listener. Whenever a message arrives at the destination, the JMS provider delivers the message by calling the listener's onMessage method, which acts on the contents of the message. In the i-Travel scenario JMS could be used in order to transport messages between the different services providers and consumers in the i-Travel market places, since most of the needed interaction can be modelled using asynchronous queues and topics. The main issues could be the following ones: 27 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

JMS is a Java technology, and though there are bindings for other languages the portability of the solution is poor JMS uses its own transport for messages, making difficult to pass firewalls and connect services across the boundaries of institutions The JMS model does not support the federation of different services, setting limits to scalability and the feasibility of internet wide messaging system based on this technology (all names must belong to a single, huge namespace) Especially the latter could be blocking for the adoption of JMS as standard distribution channel in the iTravel platform.

Availability Most of the commercial and open application servers support also JMS, and several standalone JMS implementations are available, e.g. ActiveMQ http://activemq.codehaus.org/ Joram http://joram.objectweb.org/ JBossMq http://www.jboss.org/wiki/Wiki.jsp?page=JBossMQ

5.5.2 Other queuing/messaging technologies

Microsoft Message Queuing MSMQ is a messaging protocol that allows applications running on disparate servers to communicate in a failsafe manner by the means of queues. A queue is a temporary storage location from which messages can be sent when conditions permit. This enables communication across heterogeneous networks and between computers which may not always be connected. By contrast sockets and other network protocols assume that direct connections always exist. Therefore MSMQ covers only the first model of JMS messaging, the point-to-point scenario, and it has the same limitations in terms of scalability, language and platform support (limited to Microsoft technologies), deployment in federated environments such as the i-Travel market place.

Figure 20. Microsoft Message Queuing Amazon Simple Queue Service (SQS) Amazon SQS can be described as commoditization of the messaging service, and it supports programmatic sending of messages by computer programs as a way to communicate over the web. In some sense it could be compared with an instant messaging service for software, with fee-based central server delivery messages. In the i-Travel market place the service is of particular interest for the proposed business model, since most of the traffic between the service providers and consumers will be message based. Therefore in the market place there could be some company specialized in offering reliable and scalable messaging as commodity. Price, as of 2008, was $0.01 USD per 10,000 messages sent plus bandwidth surcharge if bandwidth usage is significant. However, as of 2007, Amazon SQS did NOT guarantee reception of messages by the recipient in the order they were sent by the sender.

Bea WebLogic Event Server WebLogic Event Server is a Java application server purpose-built for event-driven applications. It is a light- weight container designed for high volume, low latency, event processing. Bea WebLogic claims it can scale in the order of millions of events per second and it comes with an integrated CEP (Complex Event Processing) engine. 28 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

The Event Server supports: Event processing constructs like event source, event sink, event stream, and provides event processing services like scheduling and synchronization. Time critical event streaming and provides stream management. Deployment of a network of event processing applications, called Event Processing Network (EPN), which can be spread across server instances for further scalability. Adapters for a number of different event sources. Foundational services like security, logging, user management, and reliability.

Figure 21. Bea WebLogic Event Server Though the Event Servers seems matching some of the requirements for the i-Travel platform in terms of the capability of handling a large number of events in realtime, as other event drive platforms its capability of federating different event sources across domains must be verified Licence costs: the costs of the Event Platform are 80000$ per CPU, with average entry costs of the order of 300000-400000$

Oracle Streams Oracle Streams, a built-in feature of the Oracle database, is a critical data replication and integration feature. It provides a flexible infrastructure that meets a wide variety of information sharing needs. Oracle Streams enables the propagation of data, transactions and events in a data stream either within a database, or from one database to another. Oracle Streams offers typical event driven platform features: • Message queuing • Bidirectional event flows • 1-N and N-1 configurable distribution patters • Filtering rules • Declarative event routing In relation to the i-Travel project the main limitation seems the fact that Oracle Streams are deeply integrated with the Oracle database platform and the adaptation for handling multi-source distributed events seems not a trivial task

Figure 22. Example of application of Oracle Streams for database replication

Error! Reference source not found. , Error! Reference source not found.

29 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

5.5.2.1 XMPP

Although XMPP might be classified potentially as the IMS, however we present it in this chapter separately because of the event-driven aspects. The Extensible Messaging and Presence Protocol (XMPP, formerly known as Jabber) is an open Extensible Markup Language XML protocol for near-real-time messaging, presence, and request-response services. The basic syntax and semantics were developed originally within the Jabber open-source community, mainly in 1999. In 2002, the XMPP WG was chartered with developing an adaptation of the Jabber protocol that would be suitable as an IETF instant messaging (IM) and presence technology. As a result of work by the XMPP WG, two main RFC were produced:

1. RFC 3920 XMPP Core, defining XML streams, SASL, TLS, stringprep profiles, stanza semantics 2. RFC 3921 XMPP IM, defining XMPP extensions for basic instant messaging and presence

RFC 3920 is more relevant to the i-Travel platform for the backend and the communication of the travel agent with the different information and event sources. RFC 3921, in the other side, is relevant to the communication with the i-Travel end users and for communicating data to and from the mobile terminals. RFC 3920 defines a technology for stream XML packets (named stanzas) and for arbitrarily routing them between different domains. More specifically the RFC describes the following aspect of the protocol:

The generalized architecture implemented via a client-server architecture wherein a client utilizing XMPP accesses a server over a TCP connection, and servers also communicate with each other over TCP connections The addressing scheme, where any entity capable of communicating via XMPP is identified with an URI, also name JID; URI are similar to email addresses and have the form [email protected]/resource , where the resource part is an opaque string allowing multiple connection associated to the same user XML Streams, which are open ended XML documents allowing the streaming of XML chunks (stanzas) as first children Stanza semantics. There are three basic stanzas with different semantics asynchronous on way stanzas that don’t need response, used for text messaging and for transporting events synchronous request / response stanzas (like HTTP requests), used for making queries to remote services broadcast stanzas sent to all the contacts of en entity, used for delivering presence and context information. Server to server communications, with the mechanism of dialback aimed at avoiding rogue servers on the XMPP network Authentication and security mechanisms, with the mandatory use of SASL for secure and pluggable authentication methods XMPP is gaining a lot of momentum, and it is becoming the most accepted standard for messaging application supporting interoperability and operation. Currently about 50000 XMPP server deployments are estimated, wherein the major commercial players adopting XMPP are Google Talk, Nokia, HP, Tivo, Gizmo Project, Sapo, Oracle. Main features of XMPP are:

• XML based protocol with a well defined extension mechanism allowing the transport of arbitrary data • Handling of asynchronous events • Push to mobile clients and behind firewalls or NATs • Federated network, working without a central server (as many IM services are forced to do), thus allowing scalability and distributed cooperation • User identity enforcement done by servers, providing a sort of distributed system for user management • Suitable to both M2M and H2M communication beyond simple IM • Rich set of extensions (e.g. publish/subscribe, XML-RPC and SOAP transport, transaction management) for supporting the requirements of modern SOA platforms 30 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

• Availability of a large number of free and commercial server implementations, as well libraries for any platform, language and licence scheme.

In the i-Travel platform scenario, perhaps the most notable feature is the federated nature of the protocol, which allows easy integration of services and identity systems (i.e. authorization associated to users) distributed across different domains as displayed in the following figure.

Figure 23. XMPP federation: clients connect to their own server and end to end messages are always exchanged with server mediation. Availability The major server implementations are: • Jabber Inc. XCP: commercial server implemented in C/C++ with high scalability and a rich set of features (Url: http://www.jabber.com/CE/JabberXCP ) • Ejabberd: open source server (GPL) written in erlang and with commercial support provided by Process One ( http://www.process-one.net/en/ ) • Openfire: dual licensing (GPL / commercial) by Jive Software ( http://www.igniterealtime.org/ )

Most of the available code libraries are listed at http://www.jabber.org/libraries Most client are listed http://www.jabber.org/clients

Error! Reference source not found.-Error! Reference source not found.

5.5.2.2 Mobile XMPP

Though there aren’t official initiatives labelled as “Mobile XMPP” many companies are starting rolling out mobile services, libraries and clients based on XMPP and they have connection managers specialized for mobile clients. Connection managers are front end for XMPP servers that mainly perform two tasks: • more scalability, distributing the load of handling tens of thousands of concurrent connections across multiple hosts • adapting the protocol to the requirements of the communication channel (e.g. mobile connection demand additional layers for compression and reliability) The following figure shows a possible XMPP deployment where connection managers are placed between the XMPP server and the possible clients.

31 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Figure 24. Use of connection managers in XMPP Among the possible connection manages, BOSH (Bidirectional-streams Over Synchronous HTTP) is of particular interest for mobile connections. BOSH is connection manager which allows XMPP clients to connect using an HTTP channel and receive push notifications, by pipelining requests as for Ajax Comet applications (server push to web browsers). The below pictures shows how Comet works (Comet and BOSH where independently developed, but followed the same pattern): the client continuously keeps a channel open with the server by issuing and “empty” HTTP request the server does not respond until some event occurs (e.g. a message for the client), thus exploiting the pending HTTP request for immediately delivering the data the client may send data to the server in any instant by issuing a second HTTP request

Figure 25. The Comet application model, modeled accordingly to the same principles of BOSH The main advantages of BOSH for mobile connections: • implicit transaction for each message, making the channel reliable also in presence of connections that may break • possibility of interrupting and resuming the connection without losing the session and having to restart the authentication process (more reactivity and bandwidth savings) • the connection manager may compress the traffic with a binary ad hoc protocol (bandwidth savings and improved computation times extending battery life) • the connection manager may filter unnecessary packets (XMPP presence can be optimized) without requiring any server modification

Availability There are few XMPP client implementation available, covering most mobile platforms: • Bombus (J2ME, GPL, only support in Russian): http://bombus-im.org/ • Lampiro (J2ME and Symbian and .NET client is in the roadmap, Free/Commercial license, separate library available as LGPL, supporting both raw TCP sockets and HTTP): http://lampiro.bluendo.com • Talkonaut (J2ME and Symbian, Freeware) http://www.talkonaut.com/

32 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

• Smartjab (.NET Compact framework, freeware and commercial): http://www.ag- software.de/index.php?page=smartjab • Telepath non Nokia N810 (Linux based Internet tablets, supporting Voip and video streams) http://telepathy.freedesktop.org/wiki/

The principal open XMPP servers (Openfire and ejabberd) have built-in standard BOSH support, though often partial; more there are standalone implementations that have full BOSH support and that can be used with any open server (also Google Talk); they can also be customized and extend for supporting mobile applications; examples are: • Punjab (implemented in python/twisted matrix) http://www.butterfat.net/wiki/Projects/PunJab • Araneo (derived from Pubjab, otpimized for mobiles and handling session disconnection) http://blog.bluendo.com/ff/bosh-connection-manager-update • JabberHTTPBind (Java based) http://zeank.in-berlin.de/jhb/

Error! Reference source not found. -Error! Reference source not found.

5.5.3 Business Integration Software

Business Integration Software is a general term labelling a wide set of varied platforms whose aim is the integration of business processes across a complex supply chain. Usually these platforms offer the following set of features: • Integration of different data sources and different message passing standards • Handling of events • Monitoring of events and their composition in a distributed scenario • Integration with databases and application services • Federation with third party services • Based on SOA architecture

The scenario is quite complex, since one of the biggest historical changes in the software market was the emergence of a market for middleware products, which sat between the operating system (OS) and the application software. Until recently, middleware products were specialized and performed distinct roles. During the past five years, a combination of the increasing reach of new business applications, with product development by middleware suppliers, and acquisitions has resulted in those distinct products evolving into suites. During the past two years, this convergence has accelerated, fuelled by acquisitions across the sector.

The combination of product evolution and convergence has resulted in overlapping capabilities in what were considered separate product categories. The separation of development tools and runtime middleware has also blurred. It is, therefore, appropriate to recognize the emergence of a new category of software, which we call "application infrastructure."

Application infrastructure includes the majority of runtime middleware, as well as AD and management tools that support the new generation of application styles based on service-oriented architecture (SOA), event-driven architecture and business process management (BPM) technology.

33 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Figure 26. Gartner Magic quadrant for Application Infrastructure (2007) Since the application scenario of the iTravel market place is not different from the supply chain of large companies having a multiplicity of suppliers and of products, we will take in exam few of the main Business Integration platforms of the main vendors, in order to extract common patterns and architecture traits.

Error! Reference source not found.

5.5.3.1 Microsoft BizTalk

Microsoft BizTalk Server, often referred to as simply "BizTalk", is a business process management (BPM) server. Through the use of "adapters" which are tailored to communicate with different software systems used in a large enterprise, it enables companies to automate and integrate business processes. Offered by Microsoft, it provides the following functions: • Business Process Automation • Business Process Modelling • Business-to-business Communication, • Enterprise Application Integration and Message broker

The BizTalk Server runtime is built on a publish/subscribe architecture, called "content-based publish/subscribe". In a content-based publish/subscribe model, subscribers specify the messages they want to receive using a set of criteria about the message. The message is evaluated at the time it is published, and all of the active subscribers with matching subscriptions (indicated by filter expressions), receive the message. As it applies to BizTalk Server, content-based is a bit of a misnomer, however, because the criteria used to build subscriptions do not have to come from the message content, and may include contextual information about the message as well (e.g. the place where it is published)

34 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Figure 27. Publish subscribe in BizTalk

Biztalk uses adapters for communications with different protocols, and specific software products such as Sharepoint. Some of the adapters that were included in Server 2006 product included the Base EDI (Covast), File, HTTP, FTP, SMTP, POP3, SOAP, SQL, MSMQT, Web Services Enhancements (WSE) 2.0, and the Windows SharePoint Service (WSS) adapters. Some are available through third parties Relevance to i-Travel: BizTalk offer orchestration, messaging and event driven primitives, as need by the i-Travel platform, however the applicability to a distributed and federated environment must be proven.

Error! Reference source not found. , Error! Reference source not found.

5.5.3.2 Oracle Fusion Middleware

Oracle Fusion Middleware (OFM) is a set of software products, produced by Oracle that spans multiple services, including J2EE and developer tools, integration services, business intelligence, collaboration, and content management. OFM is based on open standards such as BPEL, SOAP, XML and JMS. The middleware is designed to support development, deployment, and management of Service-Oriented Architecture. It includes what Oracle calls "Hot-Pluggable" architecture, which allows users to leverage existing investments in applications and systems from other software vendors such as IBM, Microsoft, and SAP AG. The picture below summarizes the components forming the Fusion middleware, whose main areas cover: • Enterprise Application Server: hosting business logic and supplying an container for web services • Integration and Process Management: service orchestration and monitoring, with support for standard orchestration protocols such as BPEL • Development Tools: libraries and development environments helping in writing and testing services • Business intelligence: tools for analysing data and activities, and for creating reports • System management: monitoring and configuration of deployed web services • User interaction: collaboration suite based on XMPP and providing portal like tools for real time collaboration • Identity management : Oracle Identity and Access Manager • Grid Infrastructure: registering services and secure integration

35 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Figure 28. Simplified Architecture of the Oracle Fusion Middleware From the iTravel perspective the Fusion middleware is one of the possible solutions the single institutions could adopt for implementing the services and the interfaces that will be specified by within the project, since it provides most of the technologies that most presumably will be used for the purpose. To be verified is its capacity of handling distributed event driven applications, since JMS is more suitable for inter-domain applications and XMPP is mainly used for internal collaboration. Error! Reference source not found.

5.5.3.3 TIBCO

Tibco offers a set of software platforms which have functionalities comparable to the Oracle Fusion middleware. The main areas covered by the Tibco platform are: • Data integration • Enterprise service bus • Service Oriented Architectures • Business Processing Management • Messaging In particular in the messaging area Tibco offers JMS implementations and a technology named “SmartSockets” providing publish/subscribe mechanisms and real time messaging, with multicast capabilities. From the i-Travel point of view it is worthy investigating whether these technologies are openly available and can be used in a federated environment. Error! Reference source not found.

5.5.4 Publish Subscribe Systems

Publish/subscribe (PubSub) is a notifications system whose main trait is the decoupling of event producers and consumers. Producers publish events to a server, usually to a well know address, while consumers subscribe to the same server in order to receive certain types of events. Accordingly to this scheme producers don’t need to know the actual consumers of the data they produce, allowing dynamic reconfiguration of the information flow acting on single point of distribution. PubSub notification systems may have also other interesting features allowing scalability and better management of complex event distribution systems (some features may be present in only some implementations): • Traffic optimization since producers need to send only one message per event, also when the potential consumers may be thousands or millions • Simplification of producers and consumers, since there is a specialized component queuing and distributing events to all the consumers as soon as they are available (however some PubSub systems allow distribution to online nodes only, without buffering) • High scalability with distributed or federated systems where there is no central server

36 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

• Content neutrality, many PubSub systems allow publishing any type of events or content, becoming a general purpose publishing system • Subscription authorization: some PubSub systems allow only central configuration of access rules, others allow publishers to accept or reject subscriptions, others both • Content based delivery: some PubSub systems allow subscribing to events accordingly to queries on event content (usually less efficient) • Topic based delivery: other PubSub systems allow subscriptions accordingly to topics, i.e. well know publishing points (usually extremely efficient). Some of these systems allow browsing a hierarchy of topics and subscribing to whole branches • Type based delivery: publishers tag messages with a type and subscribers can select messages accordingly to those tags

Figure 29.General Publish/Subsribe system Architecture models: • multicast: based on multicast capabilities of the underlying network levels o easy to implement o little scalability and availability • Broker level: application level of brokers (notification services) collecting events and distributing the using standard protocols • Dedicated servers are required o Hard to push data to mobile nodes o Difficult firewall trespassing o Lack of real time behaviour if subscribers poll data • Peer to peer overlay network: a p2p overlay network is used for routing messages between nodes o True push to subscribers, and ease of firewall trespassing o Massive scalability o Fault tolerance

Besides the availability commercial and open source applications, academic research is still active on the subject: • SIENA: distributed content based publish subscribe system, based on application level network with dedicated routers (University of Colorado and University of Lugano) • HERMES: type based system, implemented over a p2p overlay network (University of Cambridge) • GRYPHON: both topic and content based with SQL like queries, implemented over an application level network (IBM Research) • SCRIBE: topic based subscription and p2p architecture (Microsoft Research)

5.5.4.1 XMPP Publish Subscribe

XMPP Publish/Subscribe is a large specification endorsed by the XMPP Software Foundation for implementing publish/subscribe like services at the top of the XMPP protocol. The status of the protocol is “Draft Standard”, meaning that it has reached stability but still minor changes can be made until the final version. A XMPP pubsub service is a XMPP entity where other entities can create and configure nodes (i.e. pubsub topics) and manage subscriptions through regular XMPP messages. Publishing to nodes and notifications are carried on with standard XMPP messages as well. The main advantage of XMPP pubsub over other similar systems like JMS is that it relies on a asynchronous protocol supporting Internet wide scalability and federation. It becomes therefore possible for each

37 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

institution in the i-Travel market place to run its own messaging server and pubsub entity for publishing data, keeping direct control over who can subscribe or not, and, at the same time, it’s possible to use different event sources with just one distributed messaging infrastructure. Moreover XMPP pubsub defines a sophisticated mechanism of handling affiliations to nodes; entities may be node: • Owner: may publish and administer the node • Publisher: may publish items • Member: may retrieve published items • None: may subscribe • Outcast: banned entity Node (topic) organization can follow two strategies and they may be used together: flat namespace, with no hierarchical structure (leaf nodes); node names are just opaque strings identifying a given topic hierarchic namespaces, using a combination of “collection” and “leaf” nodes; collection nodes may contain either other collection nodes or leaf nodes, while items may be published only to leaf nodes. XMPP entities can subscribe either to leaf nodes or to collection node, thus receiving the whole event stream of the items published in the subscribed branch. This leads to high flexibility in filtering events with the correct granularity for any applications. Another useful features of XMPP pubsub is that event delivery can be driven by presence; therefore it’s possible to use the same infrastructure for supporting push of events to mobile user terminals, which are the main target of the i-Travel platform. Using presence for message delivery allows choosing the most appropriate channel for contacting the user and delivering events in a timely manner independently from their location and the terminal they are logged in. The following two figures show the XMPP pubsub system at work. In the first figure the pubsub system is used by a broadcaster in order to push music to distributed clients, that can subscribe to topics accordingly to their preferences. The broadcaster needs only to send data to the appropriate topics, all the complexities related to publishing to distributed clients is left to the underlying XMPP and pubsub systems.

Figure 30. Example of a distribute application implemented with XMPP Publish/Subscribe support The second figure shows how standard XMPP clients can discover pubsub topics. The publish subscribe system is listed among the available services supplied by a server.

Figure 31. Publish/Subscribe browsing via an XMPP Client

38 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Personal Eventing via Pubsub (PEP) For i-Travel an extremely interesting variation of XMPP pubsub is an extension named Personal Eventing via Pubsub (PEP). It is a simplified version of pubsub in which each XMPP entity has an associated node (topic) to which it can publish events and all entities already present in the list of contacts of the publisher are automatically subscribed. As a consequence each XMPP entity can start publishing events better describing its current status and distribute it to a set of interested parties without having to do complex node configuration and administration (a sort of plug & play for distributing events in closed and already established networks of relationships). From the i-Travel this extension is of particular interest, since it can be exploited for distributing geolocation information and other contextual information to the travel agent and to all the other services that may be interested in receiving it. The advantage of this approach is that the user and developers don’t need to configure anything on the client for adding new subscribers or sending new context information, while the users still keep control of their privacy since the authorization is related to presence subscriptions, which are explicitly handled by end users. The following to pictures show how geolocation is distributed and displayed in regular XMPP clients, however the process may be automatic and geolocation taken from GPS or CellID data and consumers can be software agents.

Figure 32. Publishing geolocation through Personal Eventing

Figure 33. Receiving geolocation through Personal Eventing

Availability Most open source and commercial XMPP server implementations have Publish/Subscribe support, usually implemented as a “server component”. i.e. as an extension plug-in having its own fully qualified name. Examples of open source servers supporting pusub: • JIVE Openfire (Java based + SQL server, open source and commercial) • Ejabberd (Erlang based, internal high performance Mnesia DB is used)

39 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

In addition there is also standalone pubsub implementations which can be used independently from any XMPP server. The most notable is Idavoll, implemented at the top of the high performance asynchronous Python framework Twisted Matrix. The main features are: • the most complete XEP-0060 implementation so far • modular backend with pluggable storages (SQL dbs, in memory, etc) • independence from server implementations

Publish/subscribe specific client libraries aren’t available at the moment (but Wokkel, which is part of Idavoll and that can be used with any pubsub server), however this is not a particular problem, since any general purpose XMPP library can be used in order to build pubsub applications with little effort (all messages are regular XMPP messages built with standard extension rules)

Error! Reference source not found. -Error! Reference source not found.

5.5.5 Web services Coordination

In this chapter we describe the main concept. Web services usually expose operations of services and applications to third party developers, in order to build large applications form existing distributed building blocks. When the application becomes complex and it involves many remote actors, some sort of coordination is required for combining the used web service. The main strategies are:

Orchestration In orchestration which is usually used in private business processes, a central process (which can be another Web service) takes control of the involved Web services and coordinates the execution of different operations on the Web services involved in the operation. The involved Web services do not "know" (and do not need to know) that they are involved in a composition process and that they are taking part in a higher-level business process. Only the central coordinator of the orchestration is aware of this goal, so the orchestration is centralized with explicit definitions of operations and the order of invocation of Web services.

Figure 34. Composition of web services with orchestration

Choreography Choreography, in contrast, does not rely on a central coordinator. Rather, each Web service involved in the choreography knows exactly when to execute its operations and with whom to interact. Choreography is a collaborative effort focusing on the exchange of messages in public business processes. All participants in the choreography need to be aware of the business process, operations to execute, messages to exchange, and the timing of message exchanges

Figure 35. Composition of web services with choreography 40 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

From the perspective of the i-Travel project Orchestration is a far more flexible approach, since the single services do not need to cooperate in order to fulfil the tasks required by the Travel Agent. Therefore using orchestration it becomes possible to: • offer travel related services and content in the eMarket place without knowing in advance all the possible applications (loose coupling of service providers and consumers) • build each travel agent as an instance of a given orchestrator (flexibility in devising new travel agents and possibility for the system to gradually grow from simple services to more complex applications)

5.5.6 BPEL

Business Process Execution Language (BPEL) is an OASIS standard (WS-BEL 2.0) which defines a notation for specifying business process behaviour based on Web Services. Business processes can be described in two ways: 1. Executable business processes model actual behaviour of a participant in a business interaction. 2. Business protocols, in contrast, use process descriptions that specify the mutually visible message exchange behaviour of each of the parties involved in the protocol, without revealing their internal behaviour. The process descriptions for business protocols are called abstract processes.

BPEL is used to model the behaviour of both executable and abstract processes. The scope includes: • Sequencing of process activities, especially Web Service interactions • Correlation of messages and process instances • Recovery behaviour in case of failures and exceptional conditions • Bilateral Web Service based relationships between process roles

Basically BPEL is an orchestration language, which means that it actively describes the ways in which individual services can be composed to implement a more complex service. BPEL can integrate external services (partner links) as well as human interactions, so that typical business processes can be easily mapped to BPEL descriptions. In most cases, users have a tool for designing and validating business processes, and another one for executing these processes.

Figure 36. BPEL description of an Itinerary reservation process BPEL therefore has interesting traits that can be useful in the i-Travel context:

BPEL processes are executed, i.e. they specify activities that are actually started by either external events or some internal process; these properties are particularly useful for modelling the behaviour of the i-Travel agent, since the application controlling the “travel process” must handle both external events (alarms, change of conditions) and internal checkpoints. BPEL is effective for modelling long running transaction; in the original intents this property is used for handling human interactions in complex processes, which may take days or weeks, however as a side effect it turns to be suitable for handling processes spanning long times such as travels.

41 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

In order to handle this type of processes BPEL engines allow storing persistently the state of each single process BPEL engines allow describing processes as flow charts (see example above), putting together complex scenarios with few basic building blocks. The visual approach can be exploited for tuning the behaviour and for monitoring the travel agent. Since basic services are web services (i.e. they are used via a common syntax) and they are described in terms of their interfaces (inputs and outputs), they can be easily changed with similar services without compromising the whole process; it becomes therefore easy to handle the heterogeneous offer of the i- Travel e-Market place without disrupting the behaviour of the i-Travel agent

5.5.6.1 Anatomy of a BPEL Business Process

Typically BPEL processes wait for incoming messages from partners, which start the execution of the business processes. The definition of these relationships is performed through an XML document which contains: • the name of the business process and the used namespaces (the dictionaries of the supported operations, in a travel scenario they could be the modules “of hotel booking”, “airline schedule”, etc) • the links of the partners and their roles, i.e. the actual reference to the partners providing the required services (e.g. the supplier of the hotel reservation package) and the type of relationship they have with the orchestration service (e.g. request/response, pull etc…) • variables, which are used to store, reformat, and transform messages; variables must have a type, defined using WSDL or XML schemas • process main body, listing the operations that should be done with a given message; for example a received message could be stored, rerouted to other services, transformed, cause the execution of other business processes (in the i-Travel scenario the message announcing the cancelation of a flight could cause the invocation of the module responsible of changing hotel reservations).

Usually this XML document describing the business processes is performed with the help of graphical tools or web interfaces, and the execution monitored with them as well. In the following figure an example is shown

Figure 37. Graphical view of the flow in a Business Process

Availability

ActiveBPEL Designer / EngineFree, Eclipse-based BPEL authoring environment with rich functionality for BPEL process design, debugging, and simulation. Includes a built-in BPEL engine for desktop testing and deployments.

Orchestra (Object Web Consortium) Orchestra is an Open Source (LPGPL) complete solution to handle long-running business processes orchestration. It is based on the OASIS standard BPEL (Business Process 42 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Execution Language). It includes a BPEL Engine and all the related graphical tools to design, administrate and monitor Business Processes. Business model: Orchestra supplies professional support

Oracle BPEL Process Manager Complete BPEL implementation with server, designer, administration tools and profiling (performance monitor) Part of the Fusion Middleware Free download of the Process Manager with implementation for JBOSS, WebSphere and BEA Weblogic

Error! Reference source not found. -Error! Reference source not found.

5.5.7 Next Generation Telematics Protocol (NGTP)

Actors: • BMW • Connexis • WirelessCar

NGTP is a new approach for delivering over-the-air services to in-vehicle devices and hand sets alike, with the focus on open interfaces across the entire service delivery chain. NGTP’s developers set the following six objectives: 1. Provide a technology-neutral protocol and consistent user interface for telematics services; 2. Reduce barriers to collaboration and implementation; 3. Enable adoption of new technologies as they come online; 4. Support legacy systems for connectivity throughout the service life of a vehicle; 5. Gain wide acceptance and encourage innovation through an open approach; 6. Increase the value proposition for vehicle manufacturers, service providers, content providers, and motorists.

More details on http://www.ngtp.org/ .

5.5.7.1 NGPT Architecture

The protocol has three main segments. The key component is a technology-neutral intermediary called the dispatcher, which connects the vehicle’s telematics unit (TU) to telematics service providers (TSPs) Telematic Unit Dispatcher Telematic Service Provider

43 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Figure 38. NGPT Architecture

Reference [543]

5.5.7.2 NGPT Business case The NGTP approach is based on basic business principles: • Because NGTP will be open source, more providers will enter the market and customers will have more choice • Because customers will have more choice, the price of services will be reduced • Because the price of services will be reduced, the market will be motivated to become more competitive • Because the market will become more competitive, OEMs will have more flexibility to exchange providers • Because OEMs will have more flexibility exchanging providers, new differentiated services will be faster to market • Because an increased level of standardization, TSPs will have greater means to deliver services at lower costs due to economy of scale

5.6 Summary of technical standards

5.6.1 Objectives

Technical Standard Specification deals with all aspects of the implementation, and an example of the possible reference implementation reflecting above-mentioned consideration might be found in the eMOTION (EU co-financed project) system. The eMotion system specification provides an open architecture, which enables the step-by-step integration of all existing information services. The design of the architecture focuses on interoperability on the basis of ISO/TC 211 and OGC (Open Geospatial Consortium) standards. These are also the basis of 44 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Spatial Data Infrastructures (SDIs), which are currently emerging on all levels, from regional to European and world wide scale. The most prominent European SDI endeavour is INSPIRE, see http://www.ec- gis.org/inspire/ . The analysis part primarily deals with existing standards regarding to the reference implementation system. The goal of the analysis was to find out which of the existing standards have the potential to form the foundation of the reference implementation Technical Standard Specification, and which are important because they underlie existing information sources

Following paragraphs are extracted from D5 of eMotion: System – Analysis of Technical Standards – June 2007. Details on all the described standards can be found in the eMotion D5: System-analysis of technical standards – appendix 1.

Particularly, to create a uniform application schema and a model of useful service interfaces the analysis has to take a very close and detailed look at the available standards.

The importance of the agent technologies is reflected by the cnapter 15. More references about the related IEEE standards might be found for instance in “Intelligent Agent Technology, IEEE/WIC/ACM International Conference on”.

5.6.2 Methodology

All relevant standards are detected and evaluated on their meaning and impact. The word “standard” was actually interpreted quite loosely. Of course, international standards were given precedence, however, if there was a national standard or even a project with a specified output, which was deemed suited to contribute to the model, it has been included in the survey. The main document gives an outline of the collected standards and specifications and evaluates them regarding their relevance. Existing ITS standards and in-use specifications are very diverse, some describe data models, from very abstract to very concrete and from simple to complex, some (the more modern ones) form a uniform package of data models or exchange format specifications with an integrated service interface. Today’s standards usually describe data exchange encodings in XML. As a matter of course we investigate general IT standards (besides ITS standards), if they appear usable for the reference implementation purposes. This particularly applies to the family of standards, which is employed for setting up Spatial Data Infrastructures. This concerns the standards from ISO/TC 211, from Open Geospatial Consortium (OGC), and from OASIS. In order to be able to effectively compare these very different standards from various domains, it was necessary to dissect the consideration of the standards into small particular facets. Of course, many standards contribute to more than one of these facets, which has to be accommodated. The primary criteria for the decomposition were chosen as follows: • Content • Encodings • Services • Network and Communication The “Content” chapter views the various standards according to the following technical domains: • Road Network Data • Public Transport Network Data • Inter-modal Transport Network Data • Location Referencing • Traffic Flow Data • Traffic Messages • Parking • Public Transport Service Data • POI and Other Directories • Data for Routing • Data for Public Transport Journey Planning • Data for Inter-modal Journey Planning • Data for Freight Traffic • General Metadata The criteria analysed in all these domains for all standards were:

45 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

• “Feature Catalogue ”, which was carried out as elucidated UML diagrams and constitutes the main results of the analysis, XML defined specifications (stripped from their purely service related parts) were backwards-engineered to UML, • “Encoding ”, which were usually not elaborated in depth, • “Portrayal Catalogue ”, which was aimed at detecting mapping standards (but gave no results), • “Service Reference ”, which was to document the use of the content in a service context. • The chapter “Encodings” logically belongs to chapter “Services”. It accommodates the analysis of a few important encodings, which will or may play a role in the reference implementation specification. The chapter is in no way complete, because most encodings have been deemed part of the services they are using them and were described alongside with these.

The following categories of “Services” have been dealt with: • Application Service • Data Service • Mapping Service • Routing Service • Public Transport Journey Planning Service • Positioning Service • Directory service • Geocoding Service • Coordinate Transformation Service • Registry / Catalogue Service • Event Notification Service • Digital Rights Management and Security • Pricing and Ordering • Payment and Billing • Workflow Support • Network Management • Natural Language Translation The standards treated in the “Communication and Network” chapter do not overlap with the road and traffic oriented domains. The analysis has used the following structure: • Internet Communication Standards • Public Wireless Networks • IMS • WiMAX • Wireless Communication Protocols • Hand-Held Devices and User Terminals

5.6.3 Main Results

One of the first striking results of the content analysis is that no standards or specifications regarding visualisation, symbolisation or styling of maps have been found. Admittedly, there appear to be some quite different national conventions in place, and it can be expected that emerging Europe-wide and international information systems will be defining new de-facto international conventions. Since evidently the creation of maps on the basis of ITS data is not currently an issue with an observable quest for harmonisation, the specification of mapping styles can be done without interfering with any established conventions. Another field, where virtually no specifications were found, is metadata. There is currently no established way to “talk” about ITS data, for example to explain its provenance, coverage, quality, etc. Therefore, the choice of an appropriate metadata model is left to the discretion. In order to publish data in registries, reference implementation can choose, for example, ISO 19115 or any model, which appears appropriate. Concerning content, it seems obvious that the reference implementation cannot be based on a unique network model. This is true, though there is GDF (ISO 14825) being an international and widespread standard with an extensive, high quality database offered by two commercial vendors, which is the basis of nearly all navigation applications worldwide. The observation is also made by projects like EuroRoadS: At the same time there exist a multitude of diverse road database solutions in the different countries, from national down to the local domain, which 46 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

carry significant data from public administrations, like traffic messages from Traffic Information Centres, road works planning or parking information in cities, etc. Often these data are not even network referenced, but only specified by street addresses or other means of referencing. The reference implementation should therefore do without choosing a specific network model as the basis of its specifications. The specification should rather carry out the referencing of ITS features and properties to arbitrary networks by means of a flexible Location Referencing model. At the most, an abstract graph as for example described by the EuroRoadS project might be appropriate, in case abstract references to specific network nodes or edges are needed. The necessary conversion (projection) between the references to different network models can be accomplished by services, which in this case encapsulate the access to the network data. Location Referencing can be done by various means, where modern developments like AGORA-C also have to be allowed for. The results of the comparison of content standards regarding the domain of individual traffic (traffic data, traffic messages, parking) appear quite obvious. It appears that most of the harmonisation work in this domain has already been carried out by the DATEX 2 specification, which can therefore be employed as the basis for modelling of traffic data. Incidentally, DATEX 2 also uses a variable Location Referencing scheme, which in this case comprises RDS-TMC location codes, TPEG-loc, and the use of coordinates. The world of public transport looks much more complex. Indeed, there is a CEN standard, named Transmodel (EN12896), which, being a reference model, appears to be the basis of most of the many public transport standards. However, Transmodel is a very complex and very abstract standard – it is a comprehensive reference model fitting all needs in the public transport domain. Moreover, it is not always obvious, in which way the claim to be based on Transmodel is actually justified for some standards of the domain. IFOPT may be the initial point for the fixed objects, the public transport network model. The fixed objects should use the Location Referencing definitions to express locations on the earth. Another possible initial point which was discussed among the experts was SIRI, especially regarding schedule data and real- time data. Road Weather has turned out to be an isolated area, where only little harmonization effort needs to be spent. Surprisingly, the DATEX 2 model of the weather domain will need only few amendments to cover the necessary data. Services already geared towards the service standards employed in Spatial Data Infrastructures. Naturally suggests to use these service standards (from ISO/TC 211 and OGC) to make available content according to the content model. Which of these services have to be employed still has to be checked. Standards which come into question are the OGC Web Feature Service (WFS) definition as the basic and data source, Web Map Server (WMS) for the generation of scalable maps and OpenLS for Location Based Services and Routing/ Journey Planning. WFS and WMS are also the basis of large scale SDI endeavours like INSPIRE.

5.7 Analysis of technical standards

5.7.1 Standardisation Bodies In a first step, the large international standardisation bodies which are responsible for most of the described standards are characterised. The standardisation body to name first in this context is ISO (International organisation for Standardisation), which accounts for many of the standards The Technical Committee (TC) at ISO, responsible for ITS is TC 204. Most of the traffic related standards have their origin in ISO/TC 204 , examples of which are GDF, TPEG, and ALERT-C. Also ISO/TC 211 plays an important role, because it is responsible for the ISO 19100 series of standards, which cover geo-information in general. These standards are the basis of Spatial Data Infrastructures (SDIs) is planned to be an SDI for traffic and transport information. CEN , the European Committee for Standardisation is contributing technical standards to the objectives of the European Union and European Economic Area. Only few of the standards in this document are listed as CEN standards – one example is TRANSMODEL. The W3C (World Wide Web Consortium) is an international consortium where Member organisations, a full- time staff, and the public work together to develop Web standards. Since 1994, W3C has produced more than ninety Web standards, called "W3C Recommendations." A W3C Recommendation is the equivalent of a standard. OASIS (organization for the Advancement of Structured Information Standards) is an international consortium that drives the development, convergence, and adoption of e-business standards. The consortium produces more Web services standards than any other organization along with standards for

47 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

security, e-business, along with standardisation efforts in the public sector and for application-specific markets. Closely related to ISO/TC 211 standards are the standards of OGC (Open Geospatial Consortium). OGC is an international consortium of over 340 companies, government agencies and universities participating in a consensus process to develop publicly available interface specifications. Many of the OGC standards are concrete implementation standards of abstract ISO/TC 211 standards. OGC specifications support interoperable solutions that "geo-enable" the Web, wireless and location-based services, and mainstream IT. There is also a relevant standardisation effort by ETSI, IEEE, ITU, OMA and some other stakeholders (see further sections).

5.7.2 Domain Specific Standards

In the compilation of standards in the document, the standards associated with the technical domains are treated first. The following domains had to be analysed, they form the primary technical domains: Private traffic information • Public transportation information • Weather data • Location based services • Routing/navigation and public transport journey planning

Private Traffic Information Important standards visited in the Private Traffic Information domain are: • RDS-TMC – ISO 14819 • TPEG standards – ISO 18234 / ISO 24530 • DATEX2

Public Transportation Information Many more standards have been analysed to greater depth for the Public Transportation Information domain. EN12896 – Transmodel is the reference model of most other public transport standards. Other standards examined in depth are: • RailML ® • Rail Journey Information System (RJIS) • NaPTAN / NPTG • IFOPT • SIRI

Weather Data The Weather Data domain contains only a few relevant standards, though standards centered in other domains, like DATEX 2 or RDS-TMC, also cover weather.

The most important standards here seem to be: • TLS • BUFR and CREX

Location Based Services There are ISO/TC 211 and associated standards (which also include routing/navigation as part of the LBS topic), namely: • ISO 19133 – Location Based Services – Tracking and Navigation • ISO 19134 – Location Based Services – Multimodal Routing and Navigation • OGC OpenLS and several standards/ in-use definitions concentrating on the directory and POI aspect, like • OASIS DSML • POIX • Tourism Markup Language (TourXML)

48 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Routing/Navigation and Public Transport Journey Planning The routing and navigation domain is the realm of GDF – ISO 14852, though this common standard has a lot of extensions into other domains, like LBS, public transport information, etc. The emerging Location Referencing standard AGORA-C ISO/CD 17572-3 has been also collected under routing/navigation, due to its association to GDF. The ISO 19133, 19134 and OGC OpenLS standards might as well have been treated under this heading because they are also standards for routing. Actually, routing is considered a part of LBS. Other standards and definitions from the public transport domain which fall more clearly under the heading are: • DELFI • JourneyWeb • OTA Standard (Group Air) • Ferry XML

5.7.3 Domain Independent Standards

In a second step standards and definitions are gathered which are not associated with ITS or Location Based Services objectives. However, these standards will be needed for a working information infrastructure:

Spatial Data Infrastructure Standards This mostly comprises the general purpose “geo-standards” which are established as the basis of Spatial Data Infrastructures (SDIs). SDIs are currently emerging on all levels and for many domains. The endeavour on the European level is named INSPIRE. These standards provide web services for the general provision of data and maps over the Internet. They stem from the Open Geospatial Consortium and are in most cases also ISO TC 211 standards.

Registry Standards Registries are services, which allow useful information to be published in a central place, in order to give possible users the chance to retrieve and find this information and to use it directly or as an information (meta information) of how to use some resource (known as the publish–find–bind pattern). Registries are mainstream IT services and are not restricted to SDIs, where they are of course also employed. In a spatially enabled infrastructure, registries will need special capabilities. They will, for example also have to deal with spatial queries and store spatial metadata. OASIS and OGC have registry standards. Additionally the TC 211 metadata standard ISO 19115 can be considered.

Authentication, Authorisation, Digital Rights Management These are also mainstream IT standards which provide the necessary security in accessing services. Authentication makes sure, that the user of a service is indeed the person/entity he/she claims to be. Authorisation checks if a user, once authenticated is allowed the actions he/she is requesting. Digital Rights Management (DRM) sets this into a more extensive context, where license documents define the rights of a user and functionality interpreting these licences decide, what actions an authenticated user may perform. Mainly relevant standards are from OASIS and W3C. There is also a special demand for geo- enabled DRM, which includes spatial criteria in defining the rights of a user.

eCommerce eCommerce standards are mainstream IT standards, which deal with offering, selling, delivering and payment of data or service resources. These standards, especially about payments.

Communication Standards Communication standards deal with all specifications of the network infrastructure, which effect and support the exchange of information between computational entities in that network.

Data gathering and integration will primarily use the Internet, and hence the mobile Internet as a communication platform.

49 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Other Standards

Natural language translation: Being the reference implementation a design for an ITS data infrastructure in Europe clearly is in need for multi-lingual presentation of data for end-users. The problem is in the data sources, from where often only clear-text material is delivered. This has to be translated into the target language of applications, and natural language services can do this. Sadly, there are virtually no usable standards, however there are existing service offerings (SYSTRANLinks) which might be used.

Process chaining and workflow support: See OASIS standard: WS BPEL

Network management Another need is the necessity that some management will be necessary to keep the network of services going. There is an IETF standard available (SNMP) which helps in achieving the required quality of service.

5.7.4 Analysis of Content Standards

The “Content” chapter views the various standards according to a spectrum of semantic domains. For each of the domains the applicable cut-out of the associated standards and specifications is analysed, with a focus on the object model contained within. This “feature catalogue” is carried out in UML. Additionally, but with less emphasis, existing “encodings” for the content were analysed. The other criteria applied have been pointed out above in section 5.6.2 Methodology.

Road Network Data The specifications analysed are GDF (ISO 14825), the network definition from ISO 19133 (Location Based Services, Tracking and Navigation) and the network definition of the EuroRoadS project, which aimed at the definition of common specifications for the quality assured provision and exchange of road data in Europe and was built on ISO 191xx standards. The survey of Road Network Data ignored the multitude of road database standards and specifications, which are in use on national and regional levels. This is justified because EuroRoadS provides us with an abstract model comprising all these and the relevant parts of GDF. Moreover, EuroRoadS is built on ISO 191xx including ISO 19133. These considerations are source for the decision about a “network- independent” specification relying on location referencing alone, as was already pointed out above.

Public Transport Network Data The following specifications have been analysed: GDF (which contains a public transport extension based on Transmodel and optionally referencing to the road network), Transmodel, RailML, Rail Journey Information System (RJIS), NaPTAN, and IFOPT. As it turns out, GDF, NaPTAN and IFOPT use the Transmodel Node (=Point) and Link model, special Points being Stop Points where travellers gain access to the network. IFOPT owns a very refined model of Stop Points. All models (including the railway specifications) assign geographic position to stop points.

Inter-modal Transport Network Data This chapter presents the method defined in ISO 19133 and ISO 19134 to construct a multi-modal (inter- modal) network out of a series of separately defined single-mode networks. This is contrasted to the way Transmodel and Transmodel derived standards model the transfers between different modes.

Location Referencing The Location Referencing chapter collects a list of different methods from different standards to describe locations in a network or otherwise on the surface of the earth. Locations can take the form of points, lines or areas. • DATEX 2 owns a flexible location referencing, which can accommodate ALERT-C (RDS-TMC), TPEG- LOC, and coordinate location referencing. • Alert-C relies on pre-coded locations.

50 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

• ISO 19133 linear referencing defines point-like locations by referencing linear network elements of a specific network and specifying the arc length from the a reference point on the linear geometry, where the referenced location is situated. Additionally a lateral offset may be given. • OGC OpenLS allows description of locations as Addresses, POIs or generalised geometric Positions. • TPEG-Loc supports all the common methods mentioned in ISO LRM 17572. It can provide not only a point position and expansion, but also the language aware textual descriptions of the area. • AGORA-C, designed for dynamic location referencing between client and service map databases from different suppliers. It has the ability to describe Points, Linear locations, Implicit Areas and Explicit Areas.

Traffic Flow Data In the area of traffic data there is only DATEX 2 as international standardisation available. DATEX 2 covers all relevant data that are needed by traffic information services. The Journey Time Database is a standardisation from the UK and covers only a subset of traffic data that also is covered by DATEX 2.

Traffic Messages The international standards analysed are DATEX 2, RDS-TMC (ALERT-C) and TPEG-RTM. Additionally, SRW (Scheduled Road Works) was investigated, which is a national U.K. specification. DATEX 2 is based on RDS- TMC (ALERT-C), as is TPEG-RTM. The data contained in SRW is also contained in many of the international standards analysed. Therefore, also in this domain DATEX 2 is subsuming the other standards considered.

Parking In the area of parking information there are three standardisations DATEX 2, TPEG-PKI and UTMC have been compared. The latter is a national specification from U.K. DATEX 2 contains some of the dynamic part of parking data, but none of the static parts like fees and opening time. TPEG-PKI will have to be considered once its standardisation is completed. Currently the UTMC standard from the UK provides the most comprehensive data modeling for static and dynamic parking data.

Public Transport Service Data The following standards and specifications have been analysed for the domain of public transport service data: • Transmodel • SIRI • TransXChange • RailML • Rail Journey Information System • TPEG-PTI • OTA and FerryXML Most specifications (all except TPEG-PTI) contain Time Tables, at least static ones, though following different approaches. Some standards model fares, though no existing model of fares is expected to be sufficiently comprehensive enough to deal with all situations. TPEG-PTI concentrates on messages regarding events concerning public transport systems.

POI and Other Directories The following specifications have been considered: GDF (Theme “Service”), OGC OpenLS POI schema, OASIS Directory Service Standards, POIX, Tourism Markup Language (TourML), IFOPT and NPTG. The collection of standards is rather diverse and ranges from semantic descriptions of “classical” POIs to very general standards, which encode arbitrary directory information. Hierarchical structures, being the basis of gazetteer specifications are also covered.

Road Weather The standards considered: TLS Standard, Environmental Data (FG3), BUFR and CREX for traffic weather data, road weather related ALERT-C codes, DATEX 2. TLS and BUFR/CREX describe raw “sensor-data” communication standards which are used as inputs for content operators. There is no elaborated data or added value information contained. ALERT-C in the framework of RDS-TMC standard covers solely elaborated data and also value added information between content operators and service providers. 51 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

DATEX 2 can be used for exchange of elaborated data and information as well as for measured data. It should therefore be the starting point of modelling.

Data for Routing Two standards, ISO 19133 and OGC OpenLS Route Service, have been analysed regarding the structures they offer for representing the results of routing or navigation requests, i.e. for the representation of routes . As it turns out, both models are quite similar, though the OGC OpenLS model does not list ISO 19133 as a contributing input reference. The OGC definition is better suited for transporting the information over a web service environment and should be used as a starting point.

Data for Public Transport Journey Planning The Data for Public Transport Journey Planning chapter shall investigate those parts of the specifications which define specific data needed for public transport journey planning. This comprises the representation of transport plans, all data additionally necessary to access the network at origin and destination, and the data necessary to allow distributed journey planning. The following specifications have been considered: Transmodel, IFOPT, NPTG.

Data for Inter-modal Journey Planning Only the representation of inter-modal routes by ISO 19134 has been considered.

Data for Freight Traffic There are no specific standards in the area of freight traffic relevant for the project.

General Metadata Since no ITS-domain specific metadata has been detected, a general metadata standard has been analysed. The ISO 19115 metadata standard has been chosen, because it fits well into the modelling framework.

5.7.5 Analysis of Encoding Standards

The chapter “Encodings” logically belongs to chapter “Services”. It accommodates the analysis of a few important encodings.

Content Encodings The encoding standard for data modelled in the framework of ISO/TC211 (the ISO 191xx standards) is ISO 19136, also known as Geography Markup Language, GML. The analysis focuses on this single content encoding standard due to its significance in the context of Spatial Data Infrastructures. Geography Markup Language (GML) is an XML encoding for the transport and storage of geographic information, including both the spatial and non-spatial properties of geographic features.

Presentation Encodings Presentation encoding standards are an important building block in serving the task of making content available to people. HTML is a typical presentation encoding which is not described in this place, because it is so well known a standard. The following presentation standards are treated: • SMIL is an authoring language for interactive audiovisual presentations and constitutes a good way to represent multimedia content for example for POIs. • VoiceXML is designed for creating audio dialogs that feature synthesized speech, digitised audio, recognition of spoken and DTMF key input, recording of spoken input, telephony, and mixed initiative conversations. • The Speech Synthesis Markup Language (SSML) is designed to provide a rich, XML-based markup language for assisting the generation of synthetic speech in Web and other applications. • SAMPA, Speech Assessment Methods Phonetic Alphabet and X-SAMPA are computer-readable phonetic scripts based on the International Phonetic Alphabet (IPA). • The Pronunciation Lexicon Specification (PLS) is designed to enable interoperable specification of pronunciation information for both Automatic Speech Recognition (ASR) and Text-To-Speech (TTS) engines within voice browsing applications.

52 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

5.7.6 Analysis of Service Standards

The following categories of “Services” have been analysed. For each of the services the criteria “Functionality ”, pointing out the overall range of functions the service under considerations performs, and “ Interface ”, describing the way the service can be invoked have been documented. See also section 5.6.2 Methodology.

Data Service The analysis comprises the OGC specifications Web Feature Service and Web Coverage Service as well as the services of the DATEX 2 and SIRI definition. The latter two services are basically data services, however, also show some additional functionality like “event service”, because they can register clients and can call them back, in time intervals, or if the data base is changed. Particularly, the OGC Web Feature Service may be the basic service definition for data delivery.

Mapping Service Considered are the OGC specifications Web Map Server and Web Map Server with Styled Layer Descriptor . Both are suitable specifications for the delivery of maps from data over the Internet. The Styled Layer variant allows for controlling the styling of the map from the side of the client.

Routing Service The services described are the ISO 19133 Navigation Service and the OGC OpenLS Route Service . Especially the OGC Route Service might be a candidate for an associated service definition. The interface can also treat public transport journey planning requests and even inter-modal requests.

Public Transport Journey Planning Service The following standards and specifications are considered: Journey Web, DELFI, OTA Standard (Air), Ferry XML. JourneyWeb is an extensible protocol for dynamic data exchange over the Internet between multimodal public transport journey planners. It is also an extensive interface against public transport information in general, which means it is also a Data Service. DELFI is comparable to JourneyWeb. It defines an interface and an implementation which allow other Journey Planning interfaces to be integrated. OTA and FerryXML own booking operations, which by their very nature are more complex than the Journey Planning interface proper.

Positioning Service A Positioning Service provides location information to the user of the service. The only service definition considered is the OGC OpenLS Gateway Service . The Gateway Service is a network-accessible service that provides the location of one or more mobile terminals.

Directory Service A Directory Service provides access to an online directory (e.g. Yellow Pages) to find the location of either a specific directory content or one which is closest to a given position. Two directory service definitions are considered, the OASIS Directory Service and the OGC OpenLS Directory Service . Both are possible candidates for the delivery of POI information, however a data service like the WFS might also be used.

Geocoding Service Geocoding services translate different forms of geo-referencing into each other, mainly street addresses into coordinates. The reverse process is often called reverse geocoding. Analysed were the OGC OpenLS Location Utility Service (including both a geocode and reverse geocode) and the OGC Gazetteer Service Profile of the Web Feature Service. Both standards may be employed, however a more general model of location translation than is provided by these two specifications would be advisable.

Coordinate Transformation Service Coordinate Transformation Services provide an interface to coordinate systems metadata and perform transformations between different coordinate systems. Just the OGC Web Coordinate Transformation Service has been found in this domain. It can be employed to transform between any coordinate reference system.

53 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Registry / Catalogue Service Registry Services (Catalogue Services) cover the interactions of publishing and finding service and data offerings. They allow publication (registration) and retrieval of metadata like service descriptions, data descriptions, data specifications, application schemas, code lists, thesauri, coordinate reference systems, portrayal rules, symbolism and contractual information. The following service specifications have been documented: • OASIS ebXML Registry Service and Protocol • OGC Catalogue Service Specification (CSW) • OGC Catalogue Service – ebRIM Profile of CSW • OGC Catalogue Service – ISO 19115/19119 Profile of CSW

Event Notification Service Event Notification services are required to realise PUSH-type services. They notify a user or trigger a remote service as soon as some condition occurs. The user or service has to subscribe to such a service and is called back on arrival of the condition. For calling back a user a variety of channels have to be utilised, like email, SMS, telephone, etc. This is because end users are usually not generally web accessible. Two service definitions have been collected, the OASIS Web Services Notification and OGC Web Notification Service. Which of the definitions seems appropriate has to be decided.

Digital Rights Management and Security Under Digital Rights Management (DRM) Services we understand services suited and needed to control all aspects of the use of services and data based on rights and licensing information. The GeoDRM RM defines the framework for web service mechanisms and rights languages to articulate, manage and protect the rights of all participants in the geographic information marketplace, including the owners of intellectual property and the users who wish to use it. The eXtensible Access Control Markup Language (XACML) centres around an encoding for expressing security policies regarding any possible resources. There is also an extension to XACML by OGC, called GeoXACML , which adds spatial restrictions to XACML. Security Assertion Markup Language (SAML) is an XML standard for exchanging Authentication and Authorization data between Security Domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions).

Pricing and Ordering For openly accessible Web Services registering, retrieving and finding openly accessible web resources (usually by means of a Registry Service), there is also demand for a Web Service which makes an automated pricing, ordering and delivery workflow possible. The OGC Web Pricing and Ordering Service specification describes a web service which covers all standard geo-eBusiness processes like pricing, ordering and online delivery for spatial products.

Payment and Billing Two specifications are presented, the Austrian standard eps and SEPA . Actually, SEPA does not exist yet, so the interface cannot be described. eps (Electronic Payment System) is a simple, safe and free of charge standard of Austrian Banks for e- Commerce and e-Government payments. The Single Euro Payments Area (SEPA) will be created to give citizens, companies and other economic actors the opportunity to make and receive payments within Europe.

Workflow Support When a series of automated service invocations has to be combined to accomplish the flow of business processing, Workflow Support Engines may be employed. The OASIS Web Services Business Process Execution Language (WS-BPEL) specifies the common concepts for a business process execution language, if it is needed.

Network Management As is the case with all distributed services infrastructures, the framework is susceptible to the possibility that parts of the network fail or malfunction in unperceived ways.

54 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

One standard candidate for support of Network Management is the IETF specification Simple Network Management Protocol (SNMP) .

Natural Language Translation A service infrastructure for traffic information in Europe has necessarily to deal with the issue of multilinguality. There are several solutions to this problem, each of which does not solve the problem entirely. The main problem is the provision of clear text in the original data source. This can only be solved by on-the-fly natural language translation. Two specifications are considered: The OASIS Translation Web Service , which is a standard to automate the translation and localization process as a Web service, and a proprietary solution offered by SYSTRAN, the SYSTRANLinks translation service.

5.7.7 Travel ontology’s

Many organisations today possess increasingly large information repositories and they share common problems in managing their information and reusing it for other applications. Lonely Planet is an example of such an organisation with regards to its information on travel. Knowledge Technologies and Knowledge Engineering (KT) deal with reasoning about models of the world using an abstraction, known as “ontology”. Ontologies can help to manage such information as they provide a machine processable and sharable model of information for various applications. It is especially useful if ontology is already available and suitable, as building one is time consuming. The ontology is usually defined as an explicit specification of conceptualization [main definitions are available from T.Gruber and N.Guarino]. In general, ontology refers to the description of the concepts and relationships that can exist for an agent or a community of agents. The defined ontology is usually in some formal and preferably machine-readable manner. Since the ontology could be re-used, so it could save more time and cost for the development. Building and implementing a travel ontology at Lonely Planet involved modelling world information such as geographic locations, places of interest, cultural information and cuisines of the world. They found that some information that needed to be modelled often did not have a clearly defined boundary. For example, information about some regions that were required to be modelled were loosely associated with neighbouring places. This made it difficult to classify information in a strict hierarchy. This reflects the requirement for flexibility in classifying items as discussed earlier. Existing ontologies may already be available. In such cases they could be reused, rather than building an ontology by hand. In the geographic domain, there are existing off-the-shelf ontologies available such as ESRI (http://www.esri.com), and Getty (http://www.getty.edu/research/conducting research/vocabularies/tgn) as well as GIS street level ontologies used by local authorities. However, it was found that these ontologies either had too much or too little detail. The off-the-shelf ontologies that were considered by Lonely Planet did not suit the application requirements. In iTravel project the class or concept of the ontology is “Travel”. The top class would be the Travel, and Accommodation, Activity, Food and Transportation might be selected as the upper class entries. An example of the First Order Logic relation between classes in Accommodation taxonomy, where a Hotel is a subclass of Accommodation.

In general, a class is a collection of elements with similar properties. Classes constitute a taxonomic hierarchy (a subclass-super class hierarchy). A class hierarchy is usually an IS-A hierarchy. For example, Trip_To_China IS-A subclass of Travel (super class). Typically, Protégé, an ontology editor, is used nowadays to create the ontology. We have to define an upper-level travel ontology which expressed in OWL (Web Ontology Language). OWL is a semantic markup language for publishing and sharing ontologies on the World Wide Web. As the first step in the direction of being able to utilize a travel ontology, we have researched the existing available ontologies. While the largest general ontology building projects, such as: • the Cye project Error! Reference source not found. • WordNet Error! Reference source not found. , • Suggested Upper Merged Ontology (SUMO) Error! Reference source not found. and • SENSUS Error! Reference source not found. do not provide us with an "ontology of travel", there exist a number of smaller scale attempts at defining such an ontology. 55 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Mondeca's Error! Reference source not found. tourism ontology defines tourism concepts based on the WTO thesaurus. The Travel Agent Game in Agentcities (TAGA) is an agent framework for simulating the global travel market on the Web. Its purpose is to demonstrate Agentcities and Semantic Web technologies Error! Reference source not found. . In addition to the FIPA content language ontology, TAGA defines (a) basic travel concepts such as itineraries, customers, travel services, and service reservations, and (b) different types of auctions, roles participants play in them, and protocols used. Harmonize is an attempt at ontology-mediated integration of tourism systems following different standards Error! Reference source not found. . Its goal is to allow organizations to exchange information without changing data structures. The Harmonize project also involves sub-domains that are only partially related to the world of travel: geographical and geo-spatial concepts, means of transportation, political, temporal, activity/interest, gastronomy etc. These sub-domain concepts can be used within the travel system (directly, as needed) or incorporated into the ontology constructed for the system. It is claimed that the next generation of "eTourism" will be powered by the Semantic Web technology (resulting in an eTourism Semantic Web portal which will connect the customers and virtual travel agents from anywhere at anytime). Goes with out saying that this is a very interesting project, however, air travels are not included in the current version of Harmonize ontology.

The Schemaweb Ontology is presented on http://www.schemaweb.info/schema/SchemaDetails.aspx?id=236 . This Ontology contains three subdomains in travel domain, such as flight, hotel and car. It also provides domain independant ontology besides domain ontology, so you can use it to represent your own travel services. Some concepts come from OTA specification, in order to make the Ontology accepted more widely Finally, a number of "minimalist" travel ontologies can be found within the DAML language portal Error! Reference source not found. . For instance, the Itinerary-ont is an ontology for representing travel itineraries. It reuses the airport codes ontology and involves definitions of terms like Aircraft, Class, Flight etc. Another example is the Trip Report Ontology that defines Airfare, Amount, Date, etc., and models on-line sale. The complete list of pros and cons for ontologies listed above may be found in Error! Reference source not found. . There, results of in-depth analysis of the possibility to utilize any of them in air travels are reported. A number of location aware tourist guide systems have been developed. The main objective of these systems is to select or filter the relevant information to the users based on user’s preference and location. However, the existing applications not fully utilized the Knowledge Technologies. Overall, none of them had a fully developed air travel part and that could also interface with an actual GDS, and therefore it might be suggested to develop the new one, possibly based on the Open Travel Alliance messaging system. To further improve the functionality, we propose a mobile location-aware agent-based system for tourist guiding and context-aware travel assistance.

Error! Reference source not found. -Error! Reference source not found. Error! Reference source not found. -Error! Reference source not found.

5.8 Data Formats for Syndication

The content of web sites is often made available through machine readable files (as opposed to HTML, which is more suitable to presentation), usually based on XML standards such as RSS or Atom. The main purpose of these files is building feeds for syndicating content between different organizations. Though originally related to only the blog posts, their availability is now so pervasive that almost all web based frameworks are capable of exporting their contents through these formats, thus becoming the de facto standard for any type of syndication. Content syndication formats usually have flat format, being made of a collection of “items” characterized by at least: • an URI referencing the real resource; • a title; • a short description;

56 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Items may have also other fields such as an UUID and a time permanent URI, Dublin Core style metadata and full item content as payload. The capability of publishing arbitrary XML data in the item payload make syndication format interesting for the i-Travel platform, since one of the goals is the seamless integration of heterogenous information sources.

Syndication is based on the following mechanism: • a web site publishes a syndication feed to a known address; the feed contains all the new created or modified items; • subscribers poll the feed at regular intervals downloading the file via HTTP, check if there are new items and download them

Though this syndication mechanism is straightforward and fairly simple, it presents several problems: • scalability: polling is the least efficient way for distributing information, and with a large number of subscribers the load may become too high • realtimeness: with polling it is impossible to have real time notifications; delivery time is bound by the polling frequency which can’t be increased without hurting the performance of the server • possible data loss: since the publisher cannot know when all the consumers have downloaded the data, it is impossible to assure the persistence of the produced items for the required time

Therefore for a high throughput real time syndication system, as required for most of the i-Travel data sources, it would be more efficient to base item distribution on a real time publish/subscribe system.

5.8.1 RSS/ATOM/XML

RSS is defined on Wiki web site http://en.wikipedia.org/wiki/RSS_(file_format) . RSS/XML/Atom are technologies and syndication is a process. RSS and Atom are two flavours of what is more or less the same thing: a ‘ feed ’ which is a wrapper for pieces of regularly and sequentially-updated content, be they news articles, weblog posts, a series of photographs, and more. For the purposes of this article, consider the terms interchangeable. XML is the base technology both are built on.

5.8.2 Atom

The name Atom applies to a pair of related standards. The Atom Syndication Format (http://en.wikipedia.org/wiki/Atom_(standard)) is an xml language used for web feeds, while the Atom Publishing Protocol (shortRSS/ATOM/XML AtomPub or APP) is a simple HTTP-based protocol for creating and updating web resources. A feed contains entries, which may be headlines, full-text articles, excerpts, summaries, and/or links to content on a web site, along with various metadata. The Atom format was developed as an alternative to RSS. One of the drivers of the Atom development was the incompatibility between some of the versions of the RSS syndication format, and the fact that XML- RPC-based publishing protocols were not sufficiently interoperable. The main motivation for the development of Atom was therefore dissatisfaction with RSS. Among other things, there are multiple incompatible and widely adopted versions of RSS. The intention was to ease the difficulty of developing applications with web syndication feeds Proponents of the new format formed the IETF Atom Publishing Format and Protocol Workgroup. The Atom syndication format was published as an IETF "proposed standard" in RFC 4287, and the Atom Publishing Protocol was published as RFC 5023. The main differences and improvements between RSS and ATOM are the following : • content model: RSS may contain either plain text or escaped HTML as a payload, with no way to indicate which of two is provided. Atom, on the other hand, provides a mechanism to explicitly and unambiguously label the type of content being provided by the entry, and allows for a broad variety of payload types including plain text, escaped HTML, XHTML, XML, Base64-encoded binary, and references to external content such as documents, video, audio streams, and so forth. • internationalization: while the RSS vocabulary has a mechanism to indicate a language for the feed, there is no means by which a language for individual items or text elements can be specified. Atom, on the other hand, uses the standardized xml: lang attribute to make it possible to specify a language context for every piece of human readable content in the feed. Atom also differs from RSS in that it supports the use of Internationalized Resource Identifiers,

57 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

which allow links to resources and unique identifiers to contain characters outside the US ASCII character set. • modularity: the elements of the RSS vocabulary are not generally reusable in other XML vocabularies. The Atom syntax was specifically designed to allow elements to be reused outside the context of an Atom feed document. For instance, it is not uncommon to find atom: link elements being used within RSS feed.

ATOM feed file example:

A subtitle. 2008-01-13T18:30:02Z author [email protected] urn:uuid:60a76c80-d399-11d9-b91C-0003939e0af6

urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 2008-01-13T18:30:02Z

Some text.

5.8.3 RSS

The initials "RSS" are used to refer to the following formats: Really Simple Syndication (RSS 2.0) RDF Site Summary (RSS 1.0 and RSS 0.90) Rich Site Summary (RSS 0.91).

Like ATOM, RSS formats are specified using XML. There are several different versions of RSS, falling into two major branches (RDF and 2.*).

The RDF, or RSS 1.* branch includes the following versions: • RSS 0.90 was the original Netscape RSS version. This RSS was called RDF Site Summary, but was based on an early working draft of the RDF standard, and was not compatible with the final RDF Recommendation. • RSS 1.0 is an open format by the RSS-DEV Working Group again standing for RDF Site Summary. RSS 1.0 is an RDF format like RSS 0.90, but not fully compatible with it, since 1.0 is based on the final RDF 1.0 Recommendation. • RSS 1.1 is also an open format and is intended to update and replace RSS 1.0. The specification is an independent draft not supported or endorsed in any way by the RSS-Dev Working Group or any other organization. • The RSS 2.* branch includes the following versions: • RSS 0.91 is the simplified RSS version released by Netscape, and also the version number of the simplified version championed by Dave Winer from Userland Software. The Netscape version was

58 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

now called Rich Site Summary; this was no longer an RDF format, but was relatively easy to use. It remains the most common RSS variant. • RSS 0.92 through 0.94 are expansions of the RSS 0.91 format, which are mostly compatible with each other and with Winer's version of RSS 0.91, but are not compatible with RSS 0.90. In all Userland RSS 0.9x specifications, RSS was no longer an acronym. • RSS 2.0.1 has the internal version number 2.0. RSS 2.0.1 was proclaimed to be "frozen", but still updated shortly after release without changing the version number. RSS now stood for Really Simple Syndication. The major change in this version is an explicit extension mechanism using XML Namespaces.

RSS 2.0 feed file example:

http://example.com/ Description en-us Tue, 10 Jan 2008 04:00:00 GMT Tue, 10 Jan 2008 09:41:01 GMT http://blogs.example.com Weblog Editor 2.0 [email protected] [email protected] 5

http://example.com/item Item description Tue, 03 Jan 2008 09:39:21 GMT http://example.com/2008/01/03.html#item1

5.8.4 Aggregators

A feed aggregator, also known as a feed reader, news reader or simply as an aggregator, is client software or a Web application which aggregates syndicated web content such as news headlines, blogs, podcasts, and blogs in a single location for easy viewing. It goes beyond simple updates though — the news reader works by pulling in the feeds of your various bookmarks. As we covered above, a feed is a wrapper for content items, so on top of notification, a feed delivers the content that has been updated itself. You may choose to read the new content in the news reader, or you may choose to leave the reader and visit the site. Some authors will only provide summaries of the content, forcing you to visit anyway.

59 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Figure 39. Feeds

Aggregators reduce the time and effort needed to regularly check websites for updates, creating a unique information space or "personal newspaper." Once subscribed to a feed, an aggregator is able to check for new content at user-determined intervals and retrieve the update. The content is sometimes described as being "pulled" to the subscriber, as opposed to "pushed" with email or IM. Unlike recipients of some "pushed" information, the aggregator user can easily unsubscribe from a feed. The syndicated content an aggregator will retrieve and interpret is usually supplied in the form of RSS or other XML-formatted data, such as RDF/XML or Atom. The variety of software applications and components that are available to collect, format, translate, and republish XML feeds is a testament to the flexibility of the format and has shown the usefulness of presentation-independent data: • Web-based: Web-based aggregators are applications that reside on remote servers and are typically available as Web applications. • Client software: client software aggregators are installed applications designed to collect Web feed subscriptions and group them together using a user-friendly interface. • Client libraries. A news reader, or aggregator as they’re also known, is a program or a web site that automatically checks your list of bookmarks (which you only have to set up once) and lets you know what’s new on each site in your list.

5.9 Data Synchronization and push mechanisms

5.9.1 SyncML

SyncML, Synchronization Markup Language (http://en.wikipedia.org/wiki/SyncML) is the former name (currently referred to as: Open Mobile Alliance Data Synchronization and Device Management) for a platform-independent information synchronization standard. Existing synchronization solutions have mostly been somewhat vendor-, application- or operating system specific. The purpose of SyncML is to change this by offering an open standard as a replacement. Several major companies such as Motorola, Nokia, Sony Ericsson, LG, IBM and Siemens AG already support SyncML in their products. SyncML is most commonly thought of as a method to synchronize contact and calendar information (Personal Information Manager) between some type of handheld device and a computer (personal, or network-based service), such as between a mobile phone and a personal computer. The new version of the specification includes support for push email, providing a standard protocol alternative to proprietary solutions like BlackBerry. Some products are now using SyncML for more general information synchronization purposes, such as to synchronize project task information across a distributed group of team members. SyncML can also be used as a base for backup solutions. SyncML clients/servers: • SyncEvolution • Funambol • Synthesis • Syncje • IceWarp • Toffa • Synchronic

5.9.2 Oracle Database Lite

Oracle Database Lite allows mobile offline applications to synchronize local data changes with an enterprise database. In addition to supporting manual synchronization, which allows users to explicitly invoke synchronization and supports application-initiated synchronization through synchronization APIs, Oracle Database Lite supports rule-based automatic synchronization. Automatic synchronization (autosync) removes the need for user or application initiated synchronization and automatically invokes a synchronization session in the background when a rule is satisfied, without interrupting the user. Oracle Database Lite automatic synchronization relies on a sync agent on the mobile device to monitor changing device conditions and other important device, data or network events. Both the application and 60 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

user can control automatic synchronization runtime behavior. The APIs also enable applications to be notified of status and synchronization related events from the sync agent

5.9.3 IntelliSynch Mobile Suite (Nokia)

Intellisync Mobile Suite from Nokia enables mobile access and synchronization to email, calendar, contacts, corporate directories and other applications. Intellisync Mobile Suite allows files synchronization on mobile devices, as well as the ability to configure, backup, and restore them remotely. Device management provides easy-to-use tools needed to control a mobile deployment.

5.9.4 Mobile Messaging with Exchange ActiveSync (Microsoft)

The mobile messaging software is embedded as part of Microsoft Exchange Server. Microsoft has licensed the Windows Mobile operating syActiveSstem and the Exchange ActiveSync protocol to a wide range of mobile device manufacturers. The Exchange Server mobile messaging features are implemented using the Exchange ActiveSync (EAS) protocol, which consists of two separate components. The EAS server component and the EAS client component which may be included with the operating system on a mobile device or it may be made available as a separate download from the device manufacturer, the mobile network operator, or a third- party independent software vendor. Scheduled Synchronization: the original version of EAS included the ability to perform manual and scheduled synchronizations Always-Up-To-Date (AUTD): the Always-Up-To-Date (AUTD) feature of EAS notifies the device of updates by sending a specially formatted Short Message Service (SMS) message to the device; upon receipt, the device initiates a synchronization to pull new data items to the device. Direct Push: the mobile device creates a connection and keeps it open for a duration known as the heartbeat interval, sending an initial synchronization request when the connection is opened. The server will then take several actions:

When the device makes an initial connection, it may send the heartbeat interval and a list of subscribed folders to the server. If the server receives these items, it stores them in an XML file in the user’s mailbox; if it doesn’t receive them, it retrieves them from the mailbox. The server will ask the mailbox server for notification of changes to items in the list of subscribed folders from the device. If there are unsynchronized changes on the server, the server immediately returns a status code that tells the client that changes are available; the client will then initiate synchronization and pull the new changes. When the heartbeat interval expires, the server sends a notification to the client, which can then re-establish the connection.

Most packet-based mobile networks allow an unused data connection to go dormant, at which point the client radio can stop transmitting over its data channel to save power; when activity occurs, the device is signalled to re-establish the connection. Because the server doesn’t return a response until either the heartbeat interval has expired or a new item has arrived, the device is free to let the persistent HTTP connection go dormant while waiting for new items to arrive. This reduces battery usage and bandwidth consumption because the device radio only needs to be fully active during synchronizations.

5.9.5 RIM Blackberry Enterprise Server (BES)

The BlackBerry Enterprise Server consists of services and components. The BlackBerry services are designed to provide productivity tools—such as email, instant messaging, and organizer functionality—and data from enterprise applications to mobile users. The BlackBerry components are designed to monitor BlackBerry services; process, route, compress, and encrypt data; and communicate with the wireless network. The BlackBerry Messaging Agent is designed to integrate with existing corporate email accounts and enable push e-mail. The BlackBerry Synchronization Service is designed to synchronize organizer data such as tasks, memos, and contacts over the wireless network so that the entries on the BlackBerry device and in the desktop email program are consistent.

61 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

The BlackBerry MDS Services connect mobile users to enterprise applications. Enterprise applications typically use one of three types of interfaces: thin client/portal, thick client/server (push data), or web service.

5.10 Communication & Distribution Channel Standards and Technologies

The most important aspect of iTravel is the context-awareness, which implies to know what the user – represented by the nomadic mobile device (like smartphone) - is using to optimise the information/service delivery baased on the bearer’s capacities. Being already discussed about the needs, information sources and systems, services and service architectures, frameworks and languages, it’s the turn to discuss about the distribution channels and related technologies supporting the ubiquitous service delivery anywhere, at anytime e.g. at the right moment to the right user.

5.10.1 Internet Communication Standards

The Internet protocol suite is a collection of network protocols implementing the stack that constitutes the basic “building blocks” for the Internet. The following standards are outlined in brief in the D5 Emotion deliverable: HTTP, HTTPS, SSL/TLS, SSH, DNS, SMTP/POP3/IMAP, FTP, TCP, UDP, IPv4/IPv6/Ipsec, SOAP.

5.10.2 IMS

IP Multimedia Subsystem is a system consisting of a telecommunication IP network with an innovative call/session control layer. A general description and the architecture of the system are presented. Aspects of Quality of Service are discussed along with Security and Cost Charging. Additionally possible applications are discussed.

5.10.3 Wireless Communication Protocols

5.10.3.1 Cellular Networks: 3G/UMTS GSM/GPRS and WLAN interoperability

At the air interface level, UMTS itself is incompatible with GSM. UMTS phones and UMTS data cards sold in Europe, the United States, much of Asia, and South Africa, are UMTS/GSM dual-mode devices, hence they are backwards compatible with regular GSM networks. If a UMTS customer travels to an area without UMTS coverage, a UMTS phone will automatically switch to GSM (roaming charges may apply). If the customer travels outside of UMTS coverage during a call, the call will be transparently handed off to available GSM coverage. Regular GSM phones cannot be used on the UMTS networks. Some companies launched a SIM authentication platform creating a secure and easy-to-use wireless system for hotspot users to access the Internet. International WLAN utilization is charged per minute and can be included on end users monthly telephone bills. This negates the requirement for accessing via pre-paid vouchers and entering insecure user names and passwords. Utilising the EAP-SIM standard, GSM Operators have the ability to authenticate users via a SIM card into the operator infrastructure, using a secure IP tunnel. For communication between the wireless ISP partner and the authentication platform, access is provided utilising the RADIUS protocol, used by all WISPs as a standard for billing purposes, thus seamlessly marrying together the Radius and SIM based world. This is in reaction to the emergence of customer requirements to integrate multiple access technologies (WLAN,GPRS,UMTS & DSL) into a single converged management application.

5.10.3.2 WiFi

Wi-Fi, http://en.wikipedia.org/wiki/Wi-Fi, is a wireless-technology brand owned by the Wi-Fi Alliance. The Alliance promotes standards with the aim of improving the interoperability of wireless local area network products based on the IEEE 802.11 standards. A Wi-Fi enabled device can connect to the Internet when within range of a wireless network connected to the Internet. The coverage of one or more interconnected access points — called a hotspot — can

62 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

comprise an area as small as a single room with wireless-opaque walls or as large as many square miles covered by overlapping access points. In addition to restricted use in homes and offices, Wi-Fi can make access publicly available at Wi-Fi hotspots provided either free of charge or to subscribers to various providers. Organizations and businesses such as airports, hotels and restaurants often provide free hotspots to attract or assist clients. Enthusiasts or authorities who wish to provide services or even to promote business in a given area sometimes provide free Wi-Fi access. Wi-Fi also allows connectivity in peer-to-peer (wireless ad-hoc network) mode, which enables devices to connect directly with each other. This connectivity mode can prove useful in consumer electronics and gaming applications.

5.10.3.3 WiMAX

WiMAX, the Worldwide Interoperability for Microwave Access, is a telecommunications technology aimed at providing wireless data over long distances in a variety of ways, from point-to-point links to full mobile cellular type access. It is based on the IEEE 802.16 standard, which is also called WirelessMAN. The name WiMAX was created by the WiMAX Forum, which was formed in June 2001 to promote conformance and interoperability of the standard. The forum describes WiMAX as a standards-based technology enabling the delivery of last mile wireless broadband access as an alternative to cable and DSL.

5.10.3.4 WiMAX and WiFi interoperability

Although both WiMAX and WiFi provide wireless broadband connectivity, they have been optimized for different usage models: • WiFi for very high-speed WLAN connectivity • WiMAX for high-speed Wireless WMAN connectivity

By combining WiMAX and WiFi technologies, service providers can offer a more complete suite of wireless broadband services. A WiMAX to WiFi seamless mobility approach has been adopted in IEEE 802.21. The inter-working capabilities between WiMAX and WiFi enable service providers to deliver consistent, transparent, and user-friendly broadband services to their subscribers. Achieving this transparency requires two key elements: • Multi-mode subscriber devices that can communicate on both WiMAX and WiFi networks. • The ability to provide service across WiMAX and WiFi networks when users move between them. This is generally implemented through a controlling Access Service Network Gateway (ASN GW) and common Authentication, Authorization, and Accounting (AAA) service functionality located in the service provider network.

5.10.3.5 NFC

Near Field Communication (NFC) is a new, short-range wireless connectivity technology that evolved from a combination of existing contactless identification and interconnection technologies. NFC will dramatically simplify the way consumer devices interact with one another, helping people speed connections, receive and share information and even make fast and secure payments with just one touch. Although it might be considered together with RFID technology, because of the communication aspects, we treat the argument here separately simply because of the identification capabilities, important for the Internet of Things. NFC devices operates at 13.56 MHz and they may transfer data at up 424 kbits/second. NFC is both a “read” and “write” technology. Communication between two NFC-compatible devices occurs when they are brought within four centimeters of one another: a simple wave or touch can establish an NFC connection, which is then compatible with other known wireless technologies such as Bluetooth or Wi-Fi. NFC standardization is carried on within the NFC Forum, whose mission is advancing the use of Near Field Communication technology by developing specifications, ensuring interoperability among devices and services, and educating the market about NFC technology). The underlying layers of NFC technology follow universally implemented standards provided by ISO, ECMA, and ETSI. Several other industry association are related to the NFC Forum such as the Java Card Forum, the Open Mobile Alliance, and the Smart card Alliance. NFC Forum claims that because the transmission range is so short, NFC-enabled transactions are inherently secure, though the statement has been questioned by several researchers.

63 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

NFC can be used with a variety of devices, from mobile phones that enable payment or transfer information to kiosks or “hot” zones in transit areas (thus the interest for the i-Travel platform). NFC specifications are publicly available for download an they cover: • NFC Data Exchange Format (NDEF): it specifies a common data format for NFC Forum-compliant devices and NFC Forum-compliant tags • NFC Record Type Definition (RTD): the RTD specification provides a way to efficiently define record formats for new applications and gives users the opportunity to create their own applications based on NFC Forum specifications

Basic record types are: Text / URI / Smart Poster NFC Forum Tag Type Four tag types based in ISO 14443A/B and FeliCa standards The following figure summarizes the general capabilities of NFC systems. NFC standards allow generalizing the communication between NFC enabled devices and tags, thus providing: • A P2P low level layer enabling the exchange of data between two NFC devices • A higher level communication layer allowing the exchange of records with know data types, thus simplifying tag recognition and the start of the appropriate application for handling data • Tag emulation, which allows NFC devices to behave as RFID tags with a programmable memory

Figure 40. NFC Forum technology architecture: Peer-to-Peer low level communication, data exchange and card emulation Availability The first non-prototype NFC phone is the Nokia 6131. Samsung too has an NFC prototype phone. NFC compatible tags on the other hand are widely available, notable examples are NXP Mifare Tagas, Topaz and FeliCa tags. Accordingly to NXP research at the end of 2007 30-50 million cards were distributed, and some NFC Forum analysis states that by 2010/11 the 40% of sold phones will support NFC Error! Reference source not found. -Error! Reference source not found.

5.10.4 Client distribution channels

5.10.4.1 Hand-Held Devices and User Terminals

This section gives an overview over J2ME and SyncML. Java 2 Platform Micro Edition (J2ME) constitutes a collection of Java APIs for the development of software on PDAs, cell phones and other consumer appliances. Synchronisation Markup Language (SyncML) is an open platform-independent information synchronisation standard for wireless devices. 64 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

5.10.4.2 DVB-H

DVB-H, Digital Video Broadcasting – Handheld (definition also on Wiki web site http://en.wikipedia.org/wiki/DVB-H) is one of three prevalent mobile TV formats. In other words, it is a technical specification for bringing broadcast services to mobile handsets. DVB-H is officially endorsed by the European Union. The major competitor of this technology is Digital Multimedia Broadcasting (DMB). DVB-SH (Satellite services to Handhelds) now and DVB-H2 in the future are possible enhancements to this technology, providing improved spectral efficiency and better modulation flexibility. DVB-H technology is a superset of the very successful DVB-T (Digital Video Broadcasting - Terrestrial) system for digital terrestrial television, with additional features to meet the specific requirements of handheld, battery-powered receivers. DVB-H can offer a downstream channel at high data rates which can be used as standalone or as an enhancement of mobile telecommunication networks which many typical handheld terminals are able to access anyway. DVB-H service launches: Finland, India, Italy, Singapore, Philippines, United States, Vietnam, Ireland, Kenya. France, Spain and South Africa nationwide service launch is planned for 2008 or 2009, in Austria, Germany and Switzerland for 2009. However, the unavailability of the UHF frequencies keeps on delaying services launches. DVB-SH in S-band is seen as a alternative in Europe. Recent field trials and studies showed better performance in radio than DVB-H standard that would lead to much cheaper costs for network deployments. In China service launch is expected before the 2008 Beijing Olympics. However, in this country, S-timi seems to be the standard the most deployed in 2008. In Malaysia the availability of a mobile broadcast TV service based on DVB-H technology is expected before the end of 2007.

5.10.4.3 DVB-SH

DVB-SH (http://en.wikipedia.org/wiki/DVB-SH) is the newest answer to the communication needs. DVB- SH, Digital Video Broadcasting - Satellite services to Handhelds, standardised by ETSI, is a physical layer standard for delivering IP based media content and data to handheld terminals such as mobile phones or PDAs, based on a hybrid satellite/terrestrial downlink and for example a GPRS uplink. The DVB Project published the DVB-SH standard in February 2007. The DVB-SH system was designed for frequencies below 3 GHz, supporting UHF band, L Band or S-band. It complements and improves the existing DVB-H physical layer standard. Like its sister specification (DVB-H), it is based on DVB IP Datacast (IPDC) delivery, electronic service guides and service purchase and protection standards. DVB-SH specifies two operational modes: 1. SH-A: specifies the use of COFDM modulation on both satellite and terrestrial links with the possibility of running both links in SFN mode. 2. SH-B: uses Time-Division Multiplexing (TDM) on the satellite link and COFDM on the terrestrial link.

DVB-H/SH trials are now underway in many cities and countries. Recent field trials and studies showed better performance in radio than DVB-H standard that would lead to much cheaper costs for network deployments.

In France, SFR and Alcatel-Lucent teamed up to deploy a DVB-SH trial. The results confirmed the theorical assumptions on the superiority of the DVB-SH to DVB-H, being the natural evolution of this legacy one.

Alcatel-Lucent’s technical test of DVB-SH in S-Band (2.2GHz) use the operational 3G mobile infrastructure of mobile network operator. The pilot uses pre-commercial low-power terrestrial repeaters for the broadcast part, co-localized with several 3G operational sites. The broadcast signal from a satellite is emulated by a transmitter located in a high-altitude helicopter perceived as a fixed point. The mobile terminals used will be pre-commercial terminals provided by Sagem and Samsung Electronics offering an improved reception quality thanks to the antenna diversity related to the use of the S-Band (2.2GHz). The pilot evaluates the capability of DVB-SH to make available to a large audience high-quality mobile TV channels, in various usage conditions such as inside and outside buildings, as well as while moving onboard a vehicle. Several innovative technical characteristics related to DVB-SH will be evaluated during this pilot, either separately or in a combination.

65 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

The key difference is the capacity to distribute live TV channels to mobile devices. Once operational the DVB-SH mux will be able to deal with between ten and fifteen simultaneous streams. It’s also powerful enough to require no dish in order to broadcast. The new TV system will be capable of providing live and stored TV in handsets and moving vehicles, interactive navigation and other two-way services. The DVB-SH advantage over existing mobile media technologies (such as DVB-H and MediaFLO) is its nationwide coverage: the new bird hanging over the United States, Puerto Rico and the US Virgin Islands, and the Eutelsat’s one over the whole EU - and improved building penetration. The first DVB-SH system to be launched in the US, however there are currently no compatible devices. This should be changed by the 2009 launch probably.

5.11 Software frameworks

5.11.1 Linux embedded platforms

5.11.1.1 OpenMoko

OpenMoko is a project in the early stages of development to create a software platform for smartphones, using free software. The aim is to create a general-purpose Linux distribution for mobile phones. Unlike most other mobile phone platforms, OpenMoko is designed to provide end users with the ability to modify the operating system and software stack. OpenMoko uses the Linux kernel, together with a graphical user environment built using the X.Org Server, GTK+ toolkit and the Matchbox window manager. The OpenEmbedded build framework and ipkg package system are used to create and maintain software packages. Native applications can be developed and compiled using the C or C++ languages The Taiwanese FIC company is manufacturing the first OpenMoko phone, the Neo1973 released on July 9, 2007.

5.11.1.2 Maemo

Maemo is a Debian-based development platform for handheld devices. It is used by the Nokia 770 Internet Tablet, and its successors, the Nokia N800 and N810. The GUI is derived from the earlier Series 90 UI for the Symbian OS, as used on the Nokia 7700 and Nokia 7710 smartphones. As well as Nokia's Internet tablets, Hildon will be the GUI for the forthcoming Mobile and Embedded Edition of Ubuntu Linux. The free and open source components are well-known desktop Linux libraries to make application porting trivial. Development for Maemo is done with the Scratchbox cross-compilation toolkit.

5.11.1.3 Access Linux

The Access Linux Platform, sometime referred to as a "next-generation version of the Palm OS" is an open source-based operating system for mobile devices developed and marketed by Access Co., of Tokyo, Japan. The platform includes execution environments for Java, classic Palm OS, and GTK+-based native Linux applications. The Access Linux Platform was first announced in February 2006. The initial versions of the platform and software development kits for the Access Linux Platform were officially released in February 2007. As of November 2007, the Access Linux Platform has yet to ship on devices, however development kits exists and public demonstrations have been showcased. Similarly to Maemo, ALP is based on components drawn from the GNOME project, including the GTK+ and GStreamer frameworks. As a fairly standard Linux/open source-based system, the Access Linux Platform presents standard APIs for most common operations. Applications for ALP can be developed as Linux-native code in C or C++, as legacy Palm OS appplications (which run in the Garnet VM emulation environment), or in Java

5.11.1.4 Qtopia

Qtopia is Trolltech's application platform for Embedded Linux-based PDAs, mobile phones, web pads, and other mobile computing devices. Qtopia main features: • Windowing system • Development environment 66 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

• Games and multimedia • PIM applications • Java integration As of 2006, there were 11 different models of mobile phone, and 30 other devices, with several million devices running this software. Qtopia also runs on the OpenMoko open phone, the FIC Neo 1973. Native applications can be developed and compiled using the C or C++ languages. Managed applications can be developed in Java.

5.11.2 Microsoft .NET compact framework

The Microsoft .NET Compact Framework (.NET CF) is a version of the .NET Framework that is designed to run on Windows CE based mobile/embedded devices such as PDAs, mobile phones, factory controllers, set- top boxes, etc. Programs written for the .NET Framework execute in a software environment that manages the program's runtime requirements. This runtime environment, which is also a part of the .NET Framework, is known as the Common Language Runtime (CLR). The CLR provides the appearance of an application virtual machine. The .NET Compact Framework uses some of the same class libraries as the full .NET Framework and also a few libraries designed specifically for mobile devices such as Windows CE InputPanel. It is possible to develop applications which use the .NET Compact Framework in Visual Studio.NET 2003, in Visual Studio 2005 and in Visual Studio 2008, in C# or Visual Basic.NET. The resulting applications are designed to run on a special, mobile-device, high performance JIT compiler. To be able to run applications powered by the .NET Compact Framework, the platform must support the Microsoft .NET Compact Framework runtime. Some operating systems which do include .NET CF are Windows CE 4.1, Microsoft Pocket PC, Microsoft Pocket PC 2002 and Smartphone 2003.

5.11.3 Symbian

Symbian OS, http://en.wikipedia.org/wiki/Symbian_OS, is a proprietary operating system, designed for mobile devices, with associated libraries, user interface frameworks and reference implementations of common tools, produced by Symbian Ltd. It is a descendant of Psion's EPOC and runs exclusively on ARM processors. Symbian is currently owned by Nokia, Ericsson, Sony Ericsson, Panasonic, Siemens AG and Samsung. Symbian OS is the leading OS in the 'smart mobile device' market. The native language of the Symbian OS is C++, although it is not a standard implementation. There are multiple platforms based upon Symbian OS that provide an SDK for application developers wishing to target a Symbian OS device. Individual phone products, or families, often have SDKs or SDK extensions downloadable from the manufacturer's website too. The SDKs contain documentation, the header files and library files required to build Symbian OS software. Unfortunately, Symbian C++ programming has a steep learning curve, as Symbian requires the use of special techniques such as descriptors and the cleanup stack. Symbian is not Open Source software. However, phone manufacturers and other partners are provided with parts of its source code. The APIs are publicly documented.

5.11.4 J2ME

Java Platform, Micro Edition (previously known as Java 2 Platform, Micro Edition or J2ME) is a specification of a subset of the Java platform aimed at providing a certified collection of Java APIs for the development of software for small, resource-constrained devices such as cell phones, PDAs and set-top boxes. Java ME was designed by Sun Microsystems. Sun provides a reference implementation of the specification, but has tended not to provide free binary implementations of its Java ME runtime environment for mobile devices, rather relying on third parties to provide their own. Java ME devices implement a profile. The most common of these are the Mobile Information Device Profile (MIDP) aimed at mobile devices, such as cell phones, and the Personal Profile aimed at consumer products and embedded devices like Set-top boxes and PDAs. Profiles are subsets of configurations, of which there are currently two: the Connected Limited Device Configuration (CLDC) and the Connected Device Configuration (CDC). The Connected Limited Device Configuration (CLDC) contains a strict subset of the Java class libraries, and is the minimal needed for a

67 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Java virtual machine to operate. CLDC is basically used to classify myriad devices into a fixed configuration. Mobile Information Device Profile (MIDP) boasts GUI API, and MIDP 2.0 includes a basic 2D gaming API. Applications written for this profile are called MIDlets. Almost all new cell phones come with a MIDP implementation, and it is now the de facto standard for downloadable cell phone games. However, many cell phones can run only those MIDlets that have been approved by the carrier.

5.11.5 Flash lite

Adobe Flash Lite is a lightweight version of Adobe Flash Player optimized for mobile phones and other non- phone, portable electronic devices. Flash Lite is considered a client-side, or user interface (UI) layer, development technology. Flash Lite content may be viewed on handsets installed with the Flash Lite player in the same way J2ME content may be viewed on phones with a J2ME interpreter. Both of these technologies may be present on the same handset and do not compete directly. Applications, games and other content may be developed in either technology.

5.11.6 Android

Android is a software platform and operating system for mobile devices based on the Linux operating system and developed by Google and the Open Handset Alliance. It allows developers to write managed code in a Java-like language that utilizes Google-developed Java libraries, but does not support programs developed in native code. The unveiling of the Android platform on 5 November 2007 was announced with the founding of the Open Handset Alliance, a consortium of 34 hardware, software and telecom companies devoted to advancing open standards for mobile devices. When released in 2008, most of the Android platform will be made available under the Apache free-software and open-source license. Current features and specifications are: • Handset layouts. The platform is adaptable to both larger, VGA, 2D graphics library, 3D graphics library based on OpenGL ES 1.0 specifications, traditional smartphone layouts. • Storage. SQLite for structured data storage • Connectivity. Android supports a wide variety of connectivity technologies including GSM, CDMA, Bluetooth, EDGE, EV-DO, 3G, and Wi-Fi. • Messaging. SMS, MMS, and XMPP are available forms of messaging including threaded text messaging. • Web browser. Main article: WebKit. The web browser available in Android is based on the open- source WebKit application framework. • Java virtual machine. Software written in Java can be compiled into Dalvik bytecodes and executed in the Dalvik virtual machine, which is a specialized VM implementation designed for mobile device use, although not technically a standard Java Virtual Machine. • Media support. Android will support advanced audio/video/still media formats such as MPEG-4, H.264, MP3, and AAC, AMR, JPEG, PNG, GIF. • Additional hardware support. Android is fully capable of utilizing video/still cameras, touchscreens, GPS, compasses, accelerometers, and accelerated 3D graphics. • Development environment. Includes a device emulator, tools for debugging, memory and performance profiling, a plugin for the Eclipse IDE.

Availability code.google.com/android/

5.11.7 Brew

BREW (Binary Runtime Environment for Wireless), defined also on WIki web site on http://en.wikipedia.org/wiki/BREW , is an application development platform created by Qualcomm for mobile phones. It was originally developed for CDMA handsets, but has since been ported to other air interfaces including GSM/GPRS. BREW is a software platform that can download and run small programs for playing games, sending messages, sharing photos, etc. The main advantage of BREW platforms is that the application developers can easily port their applications between all Qualcomm devices. BREW runs between the application and the wireless device's chip operating system so as to enable a programmer to

68 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

develop applications without needing to code for system interface or understand wireless applications. It debuted in September 2001. For software developers, it is a complete set of APIs that enables software development and applications in C, C++ and Java and is supported (platform) by an ASIC. It has a footprint of about 15900 K. BREW is also known as the pseudo OS and it runs on BREW RTOS. Software for the BREW-enabled handsets can be developed in C or C++ using the freely downloadable BREW SDK. The SDK includes a BREW Emulator, or starting with BREW Version 3.15 and above, the BREW Simulator, for testing during the development process. Unlike the Java ME platform, where any developer can upload and execute software on any supported handset, BREW applications must be digitally signed. Because BREW gives complete control over the handset hardware, only content providers or authenticated BREW developers have the tools necessary to create a digital signature. Furthermore, developer-signed applications can only execute on test-enabled handsets (BREW version 3.1 and newer devices are already "test-enabled") . Once the application has been developed and internally tested, it must be submitted to NSTL for TRUE BREW Testing. After the application passes all tests, it may be offered to a mobile operator (content provider) to be accessible for download to general handsets. The application is then signed by the content provider, to allow its execution on any supported BREW handset. The BREW Emulator (currently called BREW Simulator) does not emulate handset's hardware. Instead, the BREW application is compiled to native code and linked with a x86-compatible BREW runtime library. Because of this, obscure platform bugs related to memory alignment and various firmware related glitches make debugging applications without a BREW handset difficult. Developers must test their applications on real BREW-enabled handsets. To do that, the handset must be enabled for BREW testing (qualcomm's development labs can do the service). Starting from BREW 3.1, test-enable bit functionality was removed, and now all that is needed is a developer's digital signature. For testing purpose, BREW applications can be transferred using a USB or serial cable to any BREW- compatible handset using BREW AppLoader from qualcomm. A BREW application contains several components which must be present, otherwise it will be automatically deleted on reboot. This includes a name.mif file which describes the application, the features it uses and permissions requested, a name.mod file which is the actual compiled binary, name.bar which contains string and image resources if required, and a name.sig which is the application digital signature. Applications which do not have, or have an invalid or expired digital signature, are automatically deleted on reboot. BREW Applications may be unloaded from a consumer handset to save handset memory space. This is referred to as "Disable/Restore", and is a requirement of the TRUE BREW Test Cycle. Saved files are kept intact using Disable/Restore, and it is possible to re-load the application without paying for it again. In a "Disable" situation, all .bar, .mod, and .sig files are deleted from the handset, while any other files remain in their original place. During the "Restore" operation, the .bar, .mod, and.sig files are downloaded from the carrier's mobile store, and the previously disabled application will have full functionality remaining. The Disable/Restore process is only available to consumer users once the handset's memory is completely full. Once the application passes testing, it's available to carriers, but this does not guarantee that any carrier will make it available to end users. Carriers have to be persuaded to offer the application to end users.

Disadvantages of BREW compared to J2ME In J2ME, the entire source file and resources are compressed by default. To compress resources with BREW, you have to roll your own solution. The same is true of BREW code, it can only be compressed if you devise your own method or buy a commercial solution. However, this may be of little concern since BREW devices lack the tight memory restrictions imposed by J2ME. Commercial profilers for C/C++ are expensive, whereas the J2ME environment comes with a profiler. However, free open source C/C++ profilers for Linux are readily available. The BREW developer community is fairly small and limited to qualcomm's boards and web sites. There are not many books available either. Time to market can take longer with BREW than with J2ME because of BREW's rigorous certification requirements. This certification process may be perceived as an advantage by established software developers because the difficulties associated with testing and development costs create a high cost of entry to developers with low budgets and little time, resulting in less market dilution. Specifically, developers of casual games run less risk of having to compete with freeware workalikes developed and self-published by hobbyists. After an application is written it takes two weeks per iteration of True BREW testing (each time the application fails the test). Next, negotiations with carrier(s) commence. Then, (if successful) the carrier will spend time retesting the application with their own tests on their network. Finally, rolling out a new version means starting the process over again. 69 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Currently, most developers choose to support both J2ME and BREW, or only J2ME. J2ME may offer a lower cost to market because most carriers allow non-certified J2ME applications to run on their phones. J2ME is widely used in Europe, while BREW is primarily used in the U.S. and Japan. Even in the U.S., J2ME phones have a larger market share than BREW enabled phones. One of the initial advantages of BREW was that Verizon made it easy to purchase applications from the phone, while most J2ME carriers did not. However, most carriers of J2ME phones now offer easy-to-access purchasing portals. There are now commercial technologies to fully automate porting from J2ME to BREW. This reduces the entry barrier to produce BREW applications by eliminating the need to develop two versions of the same application in both Java and C/C++. Availability http://blue-edge.bg/downloads/BREW_Framework_Demo_Kit_1.0.7.zip

5.11.8 OSGi

OSGi technology ( http://www.osgi.org/About/Technology :: OSGi Alliance | About / OSGi Technology) is the dynamic module system for Java™. The OSGi Service Platform provides functionality to Java that makes Java the premier environment for software integration and thus for development. Java provides the portability that is required to support products on many different platforms. The OSGi technology provides the standardized primitives that allow applications to be constructed from small, reusable and collaborative components. These components can be composed into an application and deployed. The OSGi Service Platform provides the functions to change the composition dynamically on the device of a variety of networks, without requiring restarts. To minimize the coupling, as well as make these couplings managed, the OSGi technology provides a service-oriented architecture that enables these components to dynamically discover each other for collaboration. The OSGi Alliance has developed many standard component interfaces for common functions like HTTP servers, configuration, logging, security, user administration, XML and many more. Plug-compatible implementations of these components can be obtained from different vendors with different optimizations and costs. However, service interfaces can also be developed on a proprietary basis. OSGi technology adopters benefit from improved time-to-market and reduced development costs because OSGi technology provides for the integration of pre-built and pre-tested component subsystems. The technology also reduces maintenance costs and enables unique new aftermarket opportunities because components can be dynamically delivered to devices in the field.

5.11.8.1 THE FRAMEWORK

Figure 41. OSGi Framework

The core component of the OSGi Specifications is the OSGi Framework. The Framework provides a standardized environment to applications (called bundles). The Framework is divided in a number of layers. • L0: Execution Environment • L1: Modules • L2: Life Cycle Management • L3: Service Registry A ubiquitous security system is deeply intertwined with all the layers.

70 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

The L0 Execution environment is the specification of the Java environment. Java 2 Configurations and Profiles, like J2SE, CDC, CLDC, MIDP etc. are all valid execution environments. The OSGi platform has also standardized an execution environment based on Foundation Profile and a smaller variation that specifies the minimum requirements on an execution environment to be useful for OSGi bundles.

The L1 Modules layer defines the class loading policies. The OSGi Framework is a powerful and rigidly specified class-loading model. It is based on top of Java but adds modularization. In Java, there is normally a single classpath that contains all the classes and resources. The OSGi Modules layer adds private classes for a module as well as controlled linking between modules. The module layer is fully integrated with the security architecture, enabling the option to deploy closed systems, walled gardens, or completely user managed systems at the discretion of the manufacturer.

The L2 Life Cycle layer adds bundles that can be dynamically installed, started, stopped, updated and uninstalled. Bundles rely on the module layer for class loading but add an API to manage the modules in run time. The lifecycle layer introduces dynamics that are normally not part of an application. Extensive dependency mechanisms are used to assure the correct operation of the environment. Life cycle operations are fully protected with the security architecture, making it virtually impossible to be attacked by viruses.

The L3 layer adds a Service Registry. The service registry provides a cooperation model for bundles that takes the dynamics into account. Bundles can cooperate via traditional class sharing but class sharing is not very compatible with dynamically installing and uninstalling code. The service registry provides a comprehensive model to share objects between bundles. A number of events are defined to handle the coming and going of services. Services are just Java objects that can represent anything. Many services are server-like objects, like an HTTP server, while other services represent an object in the real world, for example a Bluetooth phone that is nearby. The service model is fully security instrumented. The service security model provides an elegant way to secure the communication between bundles passes.

5.11.8.2 UBIQUITOUS SECURITY

Security is based on Java and the Java 2 security model. The language by design limits many possible constructs. For example, buffer overflows used in viruses are impossible. Access modifiers in the language restrict the visibility of the code to other programmers. The OSGi platform extends this model by allowing private classes, a mechanism that is not available in a standard way in Java. The Java 2 security model provides a comprehensive model to check access by code to resources. The OSGi platform adds full dynamic management of the permissions, simplifying the life of operators and system administrators.

5.11.8.3 STANDARD SERVICES

On top of the Framework, the OSGi Alliance has specified many services. Services are specified by a Java interface. Bundles can implement this interface and register the service with the Service Registry. Clients of the service can find it in the registry, or react to it when it appears or disappears. This is similar to the service-oriented architecture made popular with web services. The key difference between web services and OSGi services is that web services always require some transport layer, which makes it thousands times slower than OSGi services that use direct method invocations. Also, OSGi components can directly react on the appearance and disappearance of services.

71 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

The following sections give a short overview of the OSGi Release 4 services. More information can be found in the OSGi Service Platform Release 4 book or PDF download. Note that each service is defined abstractly and is independently implemented by different vendors.

5.11.8.4 FRAMEWORK SERVICES

The OSGi Framework provides a Permission Admin Service, a Package Admin Service and a Start Level Service. These services are (an optional) part and direct the operation of the Framework. Framework services are the following: • (Conditional) Permission Admin – The permissions of current or future bundles can be manipulated through this service. Permissions are activated immediately once they are set. • Package Admin – Bundles share packages with classes and resources. The update of bundles might require the system to re-calculate the dependencies. This Package Admin service provides information about the actual package sharing state of the system and can also refresh shared packages. I.e. break the dependencies and recalculate the dependencies. • Start Level – Start Levels are a set of bundles that should run together or should be initialized before others are started. The Start Level Service sets the current start level, assigns a bundle to a start level and interrogates the current settings. • URL Handler – The Java environment supports a provider model for URL handlers. However, this is a singleton making it impossible to use this in a collaborative environment like OSGi that potentially has many different providers. This service specification enables any component to provide additional URL handlers.

5.11.8.5 SYSTEM SERVICES

System Services provide horizontal functions that are necessary in virtually every system. The Log Service, Configuration Admin Service, Device Access Service, User Admin Service, IO Connector Service and Preferences Service are examples of system services. Log Service – The logging of information, warnings, debug information or errors is handled through the Log Service. It receives log entries and then dispatches these entries to other bundles that subscribed to this information. Configuration Admin Service – This service provides a flexible and dynamic model to set and get configuration information. Device Access Service – Device Access is the OSGi mechanism to match a driver to a new device and automatically download a bundle implementing this driver. This is used for Plug and Play scenarios. User Admin Service – This service uses a database with user information (private and public) for authentication and authorization purposes. IO Connector Service – The IO Connector Service implements the CDC/ CLDC javax. microedition.io package as a service. This service allows bundles to provide new and alternative protocol schemes. Preferences Service – This service provides access to hierarchical database of properties, similar to the Windows Registry or the Java Preferences class. Component Runtime – The dynamic nature of services -- they can come and go at any time -- makes writing software harder. The Component Runtime specification can simplify handling these dynamic aspects by providing an XML based declaration of the dependencies. Deployment Admin – The primary deployment format for OSGi is the bundle, which is a JAR/ZIP file. The Deployment Admin provides a secondary format: the deployment package. Deployment Packages can combine bundles with arbitrary resources into a single deliverable that can be installed and uninstalled. A comprehensive model of resource processors allows user code to extend the resource types. Event Admin – Many OSGi events have specific typed interfaces, making it hard to receive and filter events generically. The Event Admin provides such a generic, topic-based event mechanism. The specification includes mapping for all existing framework and service events. Application Admin – The OSGi bundle model is different from the typical desktop or mobile phone application model that relies on starting and stopping applications. The Application Admin prescribes such a traditional application model and its required management infrastructure.

5.11.8.6 PROTOCOL SERVICES

The OSGi Alliance has defined a number of services that map an external protocol to an OSGi service.

72 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Http Service – The Http Service is, among other things, a servlet runner. Bundles can provide servlets, which becomes available over the Http protocol. The dynamic update facility of the OSGi Service Platform makes the Http Service a very attractive web server that can be updated with new servlets, remotely if necessary, without requiring a restart. UPnP Service – Universal Plug and Play (UPnP) is an emerging standard for consumer electronics. The OSGi UPnP Service maps devices on a UPnP network to the Service Registry. Alternatively, it can map OSGi services to the UPnP network. This is a recommended Release 3 specification. DMT Admin – The Open Mobile Alliance (OMA) provides a comprehensive specification for mobile device management on the concept of a Device Management Tree (DMT). The DMT Admin service defines how this tree can be accessed and/or extended in an OSGi Service Platform.

5.11.8.7 MISCELLANEOUS SERVICES

The services are: • Wire Admin Service – Normally bundles establish the rules to find services that they want to work with. However, in many cases this should be a deployment decision. The Wire Admin service therefore connects different services together as defined in a configuration file. The Wire Admin service uses the concept of a Consumer and Producer service that interchange objects over a wire. • XML Parser Service – The XML Parser service allows a bundle to locate a parser with desired properties and compatibility with JAXP. • Initial Provisioning • Foreign Application Access

5.11.8.8 CONCLUSION

The OSGi specifications are so widely applicable because the platform is a small layer that allows multiple Java™ based components to efficiently cooperate in a single Java Virtual Machine (JVM). It provides an extensive security model so that components can run in a shielded environment. However, with the proper permissions, components can reuse and cooperate, unlike other Java application environments. The OSGi Framework provides an extensive array of mechanisms to make this cooperation possible and secure. The presence of OSGi technology-based middleware in many different industries creates a large software market for OSGi software components. The rigid definition of the OSGi Service Platform enables components that can run on a variety of devices, from very small to very big. Adoption of the OSGi specifications can therefore reduce software development costs as well as provide new business opportunities.

5.12 Relevant (XML-based) presentation formats

This is the overview with Gartner Magic Quadrant for User Provisioning, 2H07.

73 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Figure 42. Gartner Magic Quadrant for User Provisioning, 2H07

5.12.1 XHTML

The Extensible HyperText Markup Language, or XHTML, http://en.wikipedia.org/wiki/XHTML , is a markup language that has the same depth of expression as HTML, but also conforms to XML syntax. Because they need to be well-formed, true XHTML documents allow for automated processing to be performed using standard XML tools—unlike HTML, which requires a relatively complex, and generally custom parser. XHTML can be thought of as the intersection of HTML and XML in many respects, since it is a reformulation of HTML in XML. Browser support for XHTML remains incomplete. For example, Internet Explorer by Microsoft (MSIE) has had XML parsing capabilities since version 5.0 in 1999, but even in mid-2007, the current version (IE7) still does not support XHTML documents served as XML, nor does IE 8 beta 1; it only renders them correctly when they are served as HTML and are authored in accordance with the HTML compatibility guidelines. Most other browsers now have mature support for all of the possible XHTML MIME types. Early implementations (such as Mozilla 0.7 and Opera 6.0, both released in 2001) do not incrementally render XHTML as it is received over the network, giving a degraded user experience compared to that of regular HTML. Later browsers such as Opera 9.0, Safari 3.0 and Firefox 3.0 gained incremental rendering to resolve the issue. Obstacles from browser vendors have slowed the effective rate of the adoption. Without broader browser support, XHTML documents must continue to be served as HTML, and therefore some of the advantages of XML — namespaces, faster parsing and smaller-footprint browsers — remain elusive on a wide scale.

5.12.2 SVG

Scalable Vector Graphics (SVG), aka "savage," is an XML specification and file format for describing two- dimensional vector graphics, both static and animated. SVG can be purely declarative or may include scripting. Images can contain hyperlinks. Some more details on http://en.wikipedia.org/wiki/Scalable_Vector_Graphics. Because of industry demand, two mobile profiles were introduced with SVG 1.1: SVG Tiny (SVGT) and SVG Basic (SVGB). These are subsets of the full SVG standard, mainly intended for user agents with limited capabilities. In particular, SVG Tiny was defined for highly restricted mobile devices such as cell phones, and SVG Basic was defined for higher-level mobile devices, such as PDAs.

74 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

The use of SVG on the web is in its infancy; there is a great deal of inertia due to the long-time use of pure raster formats and other formats like Adobe Flash or Java applets, and browser support for SVG is still uneven. Native support: there are several advantages to native support, among which are no need for the installation of a plug-in, the ability to freely mix SVG with other formats in a single document, and rendering scripting between different document formats considerably more reliable. At this time all major browsers have committed to some level of SVG support except for Internet Explorer, yet the implementations are lacking in consistency and completeness.

The Opera web browser (since 8.0) has support for the SVG 1.1 Tiny specification while Opera 9 includes SVG 1.1 Basic support and some of SVG 1.1 Full. Since 9.5 alpha 1 Opera has partial SVG Tiny 1.2 support. Browsers based on the Gecko layout engine version 1.8 (such as Firefox, Netscape, Camino, SeaMonkey and Epiphany), all have incomplete support for the SVG 1.1 Full specification. The Mozilla site has an overview of the modules which are supported in Firefox 1.5. KDE's Konqueror has a SVG plug-in called KSVG Apple's Safari browser ported KSVG2 into WebKit, initiating work on incorporating native support of SVG into Safari. The version of Safari included with Mac OS X v10.5 and Mac OS X v10.4.11 includes SVG support. The Omni Group's OmniWeb 5.5 browser, which is based on a later version of Apple's WebKit than that used in the current public release of Safari, has partial support for SVG. Amaya has partial SVG support. Plug-in support: as of 2008, Internet Explorer requires a plug-in to view SVG content. The most widely available SVG plug-in on the desktop is from Adobe Systems. However, Adobe will discontinue support for Adobe SVG Viewer on January 1, 2009. For Safari, the Adobe plug-in supports only the PowerPC platform. For Safari on Intel machines, Safari must run under Rosetta for the Adobe plug-in to work. Another plug-in, called the Renesis Player, exists for Internet Explorer and the Win32 platform. Renesis aims to support full SVG 1.2, as well as JavaScript interactivity capabilities. The Renesis version 0.7 is available as of July 4, 2007. The SVG Map Consortium released a plug-in on September 6, 2007 that runs in Internet Explorer for Windows.

5.12.3 SMIL

The Synchronized Multimedia Integration Language (SMIL), is an XML markup language for describing multimedia presentations. It defines markup for timing, layout, animations, visual transitions, and media embedding, among other things. Some of the things that SMIL is used for are to create slide-show presentations and the SMIL technology has the ability to display multiple file types like text, video, and audio. SMIL is similar to an HTML-like language that is written in XML and has options like containing links to other SMIL presentations and buttons such as stop, start and next. SMIL was developed in 1997 and can display presentations from multiple web servers. SMIL is being implemented on handheld and mobile devices and has also spawned the subset known as Multimedia Messaging Service (MMS) which is a video and picture equivalent of SMS. SMIL is also one of the underlying technologies used by HD DVD for advanced interactivity.

5.12.4 Data representation formats in Semantic Web

The connected travel concept suggests the global, ubiquitous Travel Recommendation System, which might inherit benefits from the advanced interaction with the infopoints made available by infrastructures, the sources of data available from remote but connected repositories, the always on connectivity, the availability of smart nomadic devices and/or smartphones, and Semantic Web Services, obviously based on Ontology. We might keep in mind a Personal Assistant exploiting a Recommendation System using Travel Ontology based on Semantic Web Service, requiring the Service oriented architecture’s use. The personalisation is achievable knowing the user profile, needs and wants, plus obtaining the geo-referencing and context- awareness because enabling the proactive, timely and relevant assistance delivery. The Semantic Web Service is the combination of Semantic Web with Web Service. The Web Service is a software system designed to support interoperable machine-to-machine interaction over a network. The Standards and protocols used to implement a web service are considered as a protocol stack. All data to

75 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

be exchanged is formatted with XML tags. The encoded message may conform to a messaging protocol such as SOAP, or XML-RPC. Data can be transported between applications using common protocols such as HTTP, FTP, SMTP and XMPP. The Information Repository doesn't necessarily need OWL-S, however to combine it with the use of Ontology would improve dramatically the value of the system. In the Web Service, OWL-S (Semantic Markup for Web Service) and WSDL can be combined, but OWL cannot. OWL-S is an ontology of services that makes these functionalities possible and describes the overall structure of the ontology and its three main parts: the service profile for advertising and discovering services; the process model, which gives a detailed description of a service's operation; and the grounding, which provides details on how to interoperate with a service, via messages

Semantic technologies include software standards and methodologies that are aimed at providing more explicit meaning for the information that's at our disposal. This takes different forms depending on where in the information cycle the semantic technology is applied and which area of the problem it is addressing. The term “Semantic Web” was initially conceived by Tim Berners-Lee who realized that the limit to the effectiveness of the World Wide Web would be that while billions of documents could be linked and indexed, they relied on human interpretation to do anything with them. Therefore he introduced a new initiative aiming at devising a set of technologies for embedding machine processable “semantic” structure to web resources. The relevant concepts are organised and structured in taxonomies with links. Instances are stored typically in the knowledge repositories, while respective classes of objects are managed through the Ontology (servers). Thus the Semantic Web uses following data representation formats.

RDF A metadata model which is general method of modelling information. The basic idea is making statements about resources in the form of subject-predicate-object expressions, called triples in RDF terminology. The subject denotes the resource, and the predicate denotes traits or aspects of the resource and expresses a relationship between the subject and the object. Example of the definition of metadata about a Wikipedia article:

Tony Benn Wikipedia

RDFS RDF Schema (RDFS) is an extensible knowledge representation language, providing basic elements for the description of ontologies, otherwise called RDF vocabularies, intended to structure RDF resources. Basic language primitives are: • rdfs:Class allows to declare a resource as a class for other resources • rdfs:subClassOf allows to declare hierarchies of classes • rdfs:domain of an rdf:property declares the class of the subject in a triple using this property as predicate • rdfs:range of an rdf:property declares the class or data type of the object in a triple using this property as predicate. OWL The Web Ontology Language (OWL) is a family of knowledge representation languages for authoring ontologies, i.e. by defining set of "individuals" and a set of "property assertions" which relate these individuals to each other.

76 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Figure 43. The Semantic Web stack as presented by Tim Berners Lee in 2000 Though the first reactions to Semantic Web initiative have enthusiastic, with a large research academic community and financed projects, the concepts proposed by Berners-Lee are still far from being available for developers in real life commercial applications. The state of Semantic Web technologies are a set almost stable specifications for describing resources and adding metadata, and some visionaries creating the first tools for using them in real life. However the highest levels of the infrastructure shown in the above picture (Logic, Proof and Trust) won’t be available for the years coming, and the technology is not ready yet for allowing the wholly automatic discovery and use of the required resources for completing a given task. Despite this apparent lack of success, semantic technologies have become central to a broad range of research and development initiatives with a steady growing acceptance: • networking (e.g., semantic web, grid & p2p) • content (e.g., knowledge extraction, semantic enhancement, executable content, semantic search) • services (e.g., composite applications, semantic web services) • cognition (e.g. semantic UI, knowledge computing, intelligent agents). The main reason behind this growth is that the real value of semantic technologies goes beyond “reasoning”, since they offer a framework which is beneficial for better resource description, categorization and identification. The picture below illustrates the growing benefits that may derive from a progressive adoption of semantic technologies, summarized in three levels of interoperability: • Syntactic : this is the level where most applications are today, where the level of interoperability is given only by a shared language for defining interfaces (e.g. IDL or WSDL for web services) • Structural : at this level it becomes possible to identify services and compose applications by browsing taxonomies or searching for specific interfaces (e.g. via UDDI); human intervention is still needed, but automatic tools are available (e.g. BPEL engines) • Semantic : at this level agents are able to “understand” tasks through precise semantic descriptions of processes and resources suitable for their fulfilment, and they autonomously build solutions. The present scenario in semantic applications is of transition between syntactic and structural interoperability, and the present semantic tools available on the market could help in better organizing the eMarket place in the i-Travel platform.

77 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Figure 44. Spectrum of information sharing capabilities

Error! Reference source not found. -Error! Reference source not found.

5.13 Identity management and federated identity

Identity management (http://en.wikipedia.org/wiki/Identity_management) involves the management of the identity life cycle of entities (subjects or objects) during which the system:

Establishes the identity Links a name (or number) with the subject or object; Re-establishes the identity (i.e. links a new or additional name, or number, with the subject or object); Describes the identity: Optionally assigns one or more attributes applicable to the particular subject or object to the identity; Re-describes the identity (i.e. changes one or more attributes applicable to the particular subject or object); Destroys the identity

In the real-world context of engineering online systems, identity management can involve three perspectives: 1. The pure identity paradigm: creation, management and deletion of identities without regard to access or entitlements; 2. The user access (log-on) paradigm: for example: a smart card and its associated data used by a customer to log on to a service or services (a traditional view); 3. The service paradigm: a system that delivers personalized, role-based, online, on-demand, multimedia (content), presence-based services to users and their devices. In the service paradigm perspective, where organizations evolve their systems to the world of converged services, the scope of identity management becomes much larger, and its application more critical. The scope of identity management includes all the resources of the company deployed to deliver online services. These may include devices, network equipment, servers, portals, content, applications and/or products as well as a user credentials, address books, preferences, entitlements and telephone numbers. Therefore, IdM applies to the products and services of an organization, such as media, insurance, travel and government services. It is also applicable to means by which these products and services are provisioned and assigned to (or removed from) "entitled" users.

Federated identity (definition also on Wiki web site on http://en.wikipedia.org/wiki/Federated_identity ) has two general meanings:

78 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

The virtual reunion, or assembled identity, of a person's user information (or principal), stored across multiple distinct identity management systems. Data is joined together by use of the common token, usually the user name. The process of a user's authentication across multiple IT systems or even organizations.

For example, a traveller could be a flight passenger as well as a hotel guest. If the airline and the hotel use a federated identity management system, this means that they have a contracted mutual trust in each other's authentication of the user. The traveller could identify him/herself once as a customer for booking the flight and this identity can be carried over to be used for the reservation of a hotel room. Federated identity, or the ‘federation’ of identity, describes the technologies, standards and use-cases which serve to enable the portability of identity information across otherwise autonomous security domains. The ultimate goal of identity federation is to enable users of one domain to securely access data or systems of another domain seamlessly, and without the need for completely redundant user administration. Identity federation comes in many flavors, including ‘user-controlled’ or ‘user-centric’ scenarios, as well as enterprise controlled or B2B scenarios.

Federation is enabled through the use of open industry standards and/or openly published specifications, such that multiple parties can achieve interoperability for common use cases. Typical use-cases involve things such as cross-domain, web-based single sign-on, cross-domain user account provisioning, cross- domain entitlement management and cross-domain user attribute exchange. Use of identity federation standards can reduce cost by eliminating the need to scale one-off or proprietary solutions. It can increase security and lower risk by enabling an organization to identify and authenticate a user once, and then use that identity information across multiple systems, including external partner websites. It can improve privacy compliance by allowing the user to control what information is shared, or by limiting the amount of information shared. And lastly, it can drastically improve the end-user experience by eliminating the need for new account registration through automatic ‘federated provisioning’ or the need to redundantly login through cross-domain single sign-on. Leading enterprises around the world have deployed identity federation to get closer with partners, improve customer service, accelerate execution of business partnerships and alliances, cut cost and complexity of integrating outsourced services, and free themselves from vendor lock-in. End-users and consumer focused web sites are now beginning to engage in identity federation through the adoption of OpenID, which is an open source specification for enabling federation use-cases. The notion of identity federation is extremely broad, and also evolving. It could involve user-to-user, user- to-application as well as application-to-application use-case scenarios at both the browser tier as well as the web services or SOA (service-oriented architecture) tier. It can involve high-trust, high-security scenarios as well as low-trust, low security scenarios. It can involve user-centric use-cases, as well as enterprise-centric use-cases. The term ‘identity federation’ is by design, a generic term, and is not bound to any one specific protocol, technology, implementation or company. One thing that is consistent, however, is the fact that ‘federation’ does describe methods of identity portability which are achieved in an open, often standards-based manner – meaning anyone adhering to the open specification or standard can achieve the full spectrum of use-cases and interoperability. Identity federation can be accomplished any number of ways, some of which involve the use of formal Internet standards, such as the OASIS SAML specification, and some of which may involve open source technologies and/or other openly published specifications, (e.g. Information Cards, i-card, OpenID, the Higgins trust framework or Novell’s Bandit project).

Information Cards are visual representations of personal digital identities that people can use online. Each Information Card has a card-shaped picture and a card name associated with it that enable people to organize their digital identities and to easily select one they want to use for any given interaction. An implementation of the Information Card metaphor is used by Windows CardSpace. Using Information Cards, users can authenticate without needing a username and password for every web site; instead, at sites accepting them, they can log in with an Information Card, which may be used at multiple sites. Each Information Card utilizes a distinct pair-wise digital key for every realm where a key is requested i-card: an i-card is a rectangular icon displayed in the user interface of an Identity Selector (formerly also known as identity agent) that represents a digital identity--a set of claims about some entity (typically a person, but it could also be an organization, application, service, digital object, etc.). The i-card metaphor is based on familiar physical identity credentials like business cards, credit cards, library cards, association cards, driver's licenses, badges, etc. However, just as computer file folders are similar to but more powerful than real-world file folders, i-cards are similar to but more powerful than real-world 79 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

identification cards. The i-card metaphor is identical to the Information Card metaphor used in numerous Identity Selectors. OpenID: OpenID is a single sign-on system, which allows internet users to log on to many different web sites using a single digital identity, eliminating the need for a different user name and password for each site. OpenID is a decentralized, free and open standard that lets users control the amount of personal information they provide. Using OpenID-enabled sites, web users do not need to remember traditional authentication tokens such as username and password. Instead, they only need to be registered with any OpenID "identity provider" (IdP). Since OpenID is decentralized, any website can use OpenID as a way for users to sign in; OpenID does not require a centralized authority to confirm a user's digital identity. OpenID is increasingly gaining adoption among large sites, with organizations like AOL, Google, IBM, Microsoft, Orange, Verisign, Yandex and Yahoo acting as providers. In addition, integrated OpenID support has been made a high priority in Firefox and OpenID can be used with Windows CardSpace. The method of authentication may vary, but typically, an OpenID identity provider prompts the user for an Information Card, then asks whether the user trusts the relying party web site to receive her credentials and identity details. Higgins project: Higgins is an open source framework that enables users and other systems to integrate identity, profile, and relationship information across multiple heterogeneous systems. Higgins unifies all identity interactions (regardless of protocol/format) under the common user interface metaphor called i- cards. Higgins enables developers to write to a common API for Identity management, rather than needing to support multiple identity management systems individually. Software applications written to Higgins will allow people to store their digital identities and profile information in places of their choice and to share the stored information with companies and other parties in a controlled fashion. Bandit project: Bandit project is an open source collection of loosely-coupled components to provide consistent identity services. It implements open standard protocols and specifications such that identity services can be constructed, accessed, and integrated from multiple identity sources. Portions of the identity services are an implementation of the Higgins trust framework.

5.14 B2B payments

The EU financed project GST has worked on GST-S-pay solution. Service Payment (S-PAY) Based on an intensive review of all aspects of the European payment and billing situation (including typical use cases), the main objective of Service Payment is to recommend a proven and tested payment and billing architecture that meets current and future telematics service requirements, is transparent, flexible and accepted by the whole chain of actors involved in telematics. A transparent, standardised and cost- effective payment and billing system is a pre-requisite for charging telematics services at acceptable costs and therefore represents the basis for any business case deployment. S-Pay has introduced the following elements in GST (http://www.gstproject.org/spay/): • Billing Agent • Biling Centre • Payment Agent • Pricing Module • Trustable Running Environment There are some other relevant initiatives.

5.14.1 ACH

Automated Clearing House (ACH) is the name of an electronic network for financial transactions in the United States. ACH processes large volumes of both credit and debit transactions which are originated in batches. Rules and regulations governing the ACH network are established by NACHA-The Electronic Payments Association, formerly the National Automated Clearing House Association, and the Federal Reserve. Uses of the ACH Payment System • Direct Deposit of payroll, Social security and other government benefits, and tax refunds • Direct Payment of consumer bills such as mortgages, loans, utility bills, and insurance premiums, rents, and any other regular payment. • Business-to-business (B2B) payments • E-check • E-commerce payments 80 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

• Federal, state, and local tax payments A Pan-European Automated Clearing House (PE-ACH) is an ACH that is able to settle credit transfers and direct debits across the Eurozone. At present there is only one PE-ACH in operation which was established by the Euro Banking Association in April 2003. It is thought that some domestic ACHs will position themeselves as PE-ACHs as Single Euro Payments Area (SEPA) is implemented.

5.14.2 Mobile Payments

The first stage in the work of the GSM Alliance in the area of micropayments was a joint report from infoDev, and the International Finance Corporation (IFC). The paper investigates the application of mobile-enabled commerce (m-commerce) in developing markets. It aimed to identify the opportunities provided to mobile networks in offering an m-Commerce service, as well as establishing the drivers for successful implementation. Some of the findings (also relevant to the i-Travel scenario) are: • For users - an opportunity to facilitate and reduce the costs of remittances, and to enable financial transactions without the costs and risks associated with the use of cash, including theft and travel to pay in person • For banks - an increase in their customer reach, the opportunity to migrate customers upward in the use of banking services and the added cash float available to the bank • For networks - an increase in text messaging revenues, reduction in churn rates, greater appeal to the market and hence an increase in the uptake of mobile services; • For service industries and utilities - the ability to get payments electronically from a significant portion of the overall population without the need to establish franchised agents in remote locations.

Pay Buy Mobile initiative The 'Pay-Buy Mobile' initiative is the following of the GSMA's program to define a common global approach to enabling Near Field Communications (NFC). By embedding mobile contactless services, such as credit and debit payments, in the SIM card the mobile industry will try to extend the role of mobile phones in electronic wallets that could be used for every day purchases. Fourteen mobile operators are participating in the 'Pay-Buy Mobile' initiative, which seeks to define a common global experience for mobile phone payments, on which seamlessly interoperable services will be provided. The fourteen operators, represent more than 900 million mobile users, and are Cingular Wireless, now part of the new AT&T; China Mobile; KALL; KTF; MCI; MTN; NTT DoCoMo; Rogers Wireless; Smart Communications; Telenor, TeliaSonera; Telecom Italia; Turkcell, and Vimpelcom.

SMART Money Smart Money was introduced in December 2000 to both post- and pre-paid subscribers by SMART Communications Inc, which is the leading mobile operator in the Philippines. A partnership with MasterCard, the company calls Smart Money "the world’s first electronic cash card linked to a mobile phone." Smart Money enables users to transfer money from a bank account to a Smart Money account. Subscribers can then use a Smart Money card like a debit card to pay for a variety of goods and services at a network of retail stores and restaurants. Another element of the service allows users to transfer cash from one Smart Money card to another via short message system (SMS). The service being restricted to customers with a bank account, it could be characterized as more of a "top of the pyramid" service. Fees for transactions are: • 0.05 – 0.15€ for money withdrawal, accordingly to the used bank • SMS costs for transfers based on text messages

Figure 45. General Architecture of the SMART Money initiative 81 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Secure Mobile Payment Services (SEMOPS) SEMOPS is an e-TEN project and it was initiated with the aim of effectively addressing most of the challenges bundled with a mobile payment service, and developing an open, cross-border secure approach. The service is built on the credit push concept and is based on the cooperation between banks and mobile network operators (MNO). An innovative business model that allows revenue sharing is combined with state of the art mobile technology with the goal of developing a real time, user-friendly mobile payment service, for virtual and real points of sale (POS), as well as for person-to-person transactions. The solution establishes new ways of interaction between the mobile commerce players, thereby relying on the already established traditional trust relationships between customers/merchants and their existing home bank or MNO. The aim is to combine the new payment solution with various forms of proven and state-of-the-art mobile and wireless technology in order to achieve a high level of security, availability, user friendliness and interoperability. The service can be used by any types of mobile phones, in any network environment, using practically any communication channels and a number of different transport layers. This feature allows the users to always select the most adequate method for communication (IrDA, Bluetooth, RFID, GSM, GPRS, 3G) based on the handset specifics, available transaction channel and the transaction type. The communication can be SMS based, data communication or even instant messaging. The following figures shows: • an example of mobile payments via the SEMOPS platform • the general architecture of the SEMOPS platform

Figure 46. Payment via Instant Messaging: user interaction

Figure 47. Payment Infrastructure

82 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Error! Reference source not found. -Error! Reference source not found.

5.15 Agent-based platforms

The Agent Technology in Europe is presented on web through the Cordis dedicated web site: http://cordis.europa.eu/infowin/acts/analysys/products/thematic/agents/toc.htm There is the list of recent EU research initiatives and trials supported by EC funding: • CLIMATE Cluster • ABROSE: A Co-operative Multi-Agent Based Framework for Electronic Marketplace • AMASE: Agent-based Mobile Access to Information Services • CAMELEON: Communication Agents for Mobility Enhancements in a Logical Environment of Open Networks • DICEMAN: Distributed Internet Content Exchange with MPEG-7 and Agent Negotiations • MARINER: Multi-Agent Architecture for Distributed-IN Load Control and Overload Protection • MIAMI: Mobile Intelligent Agents for Managing the Information Infrastructure • MONTAGE: Mobile Intelligent Agents Supporting and Charging for Service Provisioning to Mobile Users Following is a list of major publicly available implementations of agent platforms which conform to the FIPA Specifications: • Agent Development Kit • April Agent Platform • Comtec Agent Platform • FIPA-OS • Grasshopper • JACK Intelligent Agents • JADE • JAS (Java Agent Services API) • LEAP • ZEUS

Name Agent Development Kit Authors Tryllian BV Description Tryllian introduces the latest release of the Agent Develo pment Kit (ADK), a mobile component-based development platform that allows you to build reliable and scalable industrial strength applications. The ADK features dynamic tasking, JXTA-based P2P architecture with XML message-based communication that supports FIPA and SOAP, JNDI directory services, using a reliable, lightweight runtime environment based on Java. These allow Java Developers to easily build, deploy and manage secure, large-scale distributed solutions that operate regardless of location, environm ent or protocol, enabling an adaptive, dynamic response to changes. Access (open Commercial license. Free research license available for selected source license) projects. Environment, The ADK runs on any environment supporting Jav a 2 Standard minimal Edition version 1.3.1. A subset of its functionality is available for configuration J2ME MIDP. Contact/URL http://www.tryllian.com/

Name April Agent Platform Authors Jonathan Dale ( [email protected] ) and Johnny Knottenbelt ( [email protected] ) Description The April Agent Platform (AAP) is a FIPA -compliant agent platform that is designed to be a lightweigh t and powerful solution for

83 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

developing agent -based systems. It is written using the April programming language and the InterAgent Communication System (IMC), and provides many features to accelerate the development and deployment of agents and agent platforms. Access (open GPL source license) Environment, The AAP requires the April programming language and the ICM to minimal be installed, and runs either on Linux, Unix or Windows. configuration Contact/URL http://sf.us.agentcities.net/aap/index.html

Name Comtec Agent Platform Authors Information -Technology Promotion Agency, Japan and Communication Technologies Description Comtec Agent Platform is an open -source, free implementation of FIPA a gent communication, agent management, agent message transport and some of the applications. Unique to the Comtec Platform is the implementation of FIPA Ontology Service and Agent/Software Integration, which require SL2 as the content language. Access (op en GPL source license) Environment, JDK 1.2 or higher. minimal configuration Contact/URL http://ias.comtec.co.jp/ap/

Name FIPA -OS Authors Emorphia and Contributors Description FIPA -OS was the first Open Source implementation of the FIPA standard and has now recorded thousands of downloads. Dedicated developers from around the world have contributed to numerous bug fixes and upgrades, leading to over 10 formal new releases. FIPA-OS now supports most of the FIPA experimental specifications currently under development. With the new in depth developers guides, it is an ideal starting point for any agent developer wishing to benefit from FIPA technology. FIPA-OS 2 is a component-based toolkit implemented in 100% pure Java. One of the most significant contributions received is a small- footprint version of FIPA-OS (µFIPA-OS), aimed at PDA’s and smart mobile phones, which has been developed by the U niversity of Helsinki as part of the IST project Crumpet. Access (open The license is EPL, details of which can be found at source license) http://www.emorphia.com/EPL/ Environment, Java virtual machine minimal configuration Contact/URL http://fipa -os.sourceforge.net/

Name Grasshopper Authors Description Grasshopper is an open 100% Java -based mobile intelligent agent platform, which is compliant to both a vailable international agent standards, namely the OMG MASIF and FIPA specifications. Grasshopper includes two optional open source extensions 84 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

providing the OMG MASIF and FIPA standad interfaces for agent/platform interoperability. Access (open source license) Environment, Java Virtual Machine minimal configuration Contact/URL http://www.grasshopper.de/

Name JACK Intelligent Agents Authors Description Access (open source license) Environment, minimal configuration Contact/URL http://www.agent -software.com/

Name JADE Authors TILAB (fromerly CSELT) Description JADE simplifies the development of multi -agent applications, which comply with the lat est FIPA 2000 specifications. While appearing as a single entity to the outside world, a JADE agent platform can be distributed over several hosts. Agents can also migrate or clone themselves to other hosts of the platform, regardless of the OS. The life cycle of agents can be remotely controlled via a GUI, which also allows debugging tools to be started. The communication architecture tries to offer (agent transparent) flexible and efficient messaging by choosing, on an as needed basis, the best of the FIPA-compliant Message Transport Protocols (MTP) that are activated at platform run time. JADE is implemented in version 1.2 of JAVA and has no further dependency on third-party software. Access (open LGPL source license) Environment, Java Virtual Machine (1.2 minimum) minimal configuration Contact/URL http://jade.cselt.it/

Name Java Agent Services API (JAS) Authors Fujitsu, Sun, IBM, HP, Spawar, InterX, Institute of Human and Machine Cogtnition, Comtec, Verizon. Description The Java Agent Services (JAS) project defines an industry standard specification and API for the deployment of agent platform- service infrastructures. It is an implementation of the FIPA Abstract Architecture within the Java Community Process [www.jcp.org ] initiative and is intended to form the basis for creating commercial grade applications based on FIPA specifications. Specifically, the project consists of a Java API (in the javax.agent namespace) for deploying open platform architectures that support the plug-in of third-party platform service technology. The API provides interfaces for message creation, message encoding, message transport, directory and 85 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

naming. This design is intended to ensure that a JAS based system deployment remain transparent to shifts in underlying technology without causing interruption to service delivery and therefore the business process. The project also delivers a Reference Implementation of the API, including sample services for RMI, LDAP and HTTP. The forthcoming Technology Compatibility Kit will ensure compliance of all JAS based implementations. Access (open Open Specification License v0.4 source license) http://www.java-agent.org/Documents/OSLFLAvo.4.htm Common Public License v0.5

http://www.opensource.org/licenses/cpl.html Environment, Java Virtual Mach ine (1.1 minimum) minimal configuration Contact/URL http://www.java -agent.org/

Name LEAP Authors Description LEAP (Lightweight Extensible Agent Platform (IST -1999 -10211)) is a development and run-time environment for Intelligen t Agents, is the precursor of the second generation of FIPA compliant platforms. It represents a major technical challenge - it aims to become the first integrated agent development environment capable of generating agent applications in the ZEUS environ ment and executing them on run-time environments derived from JADE, implemented over a large family of devices (computers, PDA and mobile phones…) and communication mechanisms (TCP/IP, WAP…). In this way LEAP benefits from the advanced design-time features of Zeus and the lightweight and extensible properties of JADE. Access (open source license) Environment, Java Virtual Machine minimal configuration Contact/URL http://leap.crm -paris.com/

Name ZEUS Autho rs Description ZEUS is an Open Source agent system entirely implemented in Java, developed by BT Labs and can be considered a toolkit for constructing collaborative multi-agent applications. Zeus provides support for generic agent functionality and has sophisticated support for the planning and scheduling of an agent's actins. Moreover, Zeus provides facilities for supporting agent communications using FIPA ACL as the message transport and TCP/IP sockets as the delivery mechanism. Zeus also provides facilities for building agents in a visual environment and support for redirecting agent behavior. The Zeus approach to planning and scheduling involves representing goals and actions using descriptions that include the resources they require and the pre- conditions they need to be met in order to function. This allows goals to be represented using a chain of actions that have to b fulfilled before the goal can be met. This action chain is built up

86 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

using a process of backwards chaining. Access (open source license) Environment, As ZEUS uses the latest Swing GUI components it will run on any minimal platform that has had a JDK1.2 (aka JDK2) virtual machine configuration installed. Each host machine should also be capable of TCP/IP communication, but ther e is no need for any middleware services to be installed. So far ZEUS has been successfully tested on Windows 95/98/NT4 and Solaris platforms. Contact/URL http://193.113.209.147/projects/agents/ zeus/

5.15.1 FIPA

Foundation for Intelligent Physical Agents (FIPA, http://en.wikipedia.org/wiki/FIPA) is a body for developing and setting computer software standards for heterogeneous and interacting agents and agent- based systems. FIPA was founded as a Swiss not-for-profit organization in 1996 with the ambitious goal of defining a full set of standards for both implementing systems within which agents could execute (agent platforms) and specifying how agents themselves should communicate and interact. Within its lifetime the organization's mfembership included several academic institutions and a large number of companies including Hewlett Packard, IBM, BT (formerly British Telecom), Sun Microsystems, Fujitsu and many more. A number of standards were proposed, however, despite several agent platforms adopting the "FIPA standard" for agent communication it never succeeded in gaining the commercial support which was originally envisaged. The Swiss organization was dissolved in 2005 and an IEEE standards committee was set up in its place. The most widely adopted of the FIPA standards are the Agent Management and Agent Communication Language (FIPA-ACL) specifications. The name FIPA is somewhat of a misnomer as the "agents" with which the body is concerned exist solely in software (and hence have no physical aspect).

5.15.2 JADE

The Java Agent Development (JADE) Framework is a software Framework fully implemented in Java language. It simplifies the implementation of multi-agent systems through a middle-ware that complies with the FIPA specifications and through a set of graphical tools that supports the debugging and deployment phases. The agent platform can be distributed across machines (which not even need to share the same OS) and the configuration can be controlled via a remote GUI. The configuration can be even changed at run-time by moving agents from one machine to another one, as and when required. JADE is completely implemented in Java language.

5.15.3 Spyse

Spyse is a software framework for building multi-agent systems. It allows Python developers to build distributed intelligent systems of multiple cooperative agents based on FIPA.

5.15.4 Aglets

Aglets is a java based mobile agent platform and library for building mobile agents based applications. An aglet is a Java agent which can autonomously and spontaneously move from one host to another carrying a piece of code with it. It can be programmed to execute at a remote host and show different behaviours at different hosts. Java based security implementations take care of authorised access to local resources at the remote hosts. Aglets is completely written in Java, thus allowing a high portability of both the agents and the platform. Aglets includes both a complete Java mobile agent platform, with a stand-alone server called Tahiti, and a library that allows developers to build mobile agents and to embed the Aglets technology in their applications.

5.15.5 ZEUS (BT)

87 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Zeus is an open source agent development tool kit that was created as part of the Midas and Agentcities research projects at BT in the late 1990's and early 2000's. Zeus won a BCS Gold medal for its technical innovation, and has been successfully used in many experimental projects within BT and in the rest of the world. Zeus is written in Java and features facilities to implement BDI style (not quite BDI) agents, agents with reactive rule bases, agents with intelligent message handling functionality and DAML-S service descriptions. The reasoners in Zeus include a Rete style rule engine which uses CLIPS type rule definitions that can be extended and plugged in Java, a simple distributed planner and graph style agent rationality (you can build graphs to describe the problem solving behavior of the agent that you want). A simple ontology is used to integrate the concepts in the agent between the different sub systems. There are visualisation, scripting and monitoring tools as well as a simple agent building environment. Availability: A version of Zeus is available under an open source license from http://sourceforge.net/projects/zeusagent . Documentation that further explains how what Zeus is and how to use it is also available at http://labs.bt.com/projects/agents/zeus/

5.15.6 APRIL (Fujitsu)

April Agent Platform is proposed by Jonathan Dale ([email protected]) and Johnny Knottenbelt ( [email protected] ). The April Agent Platform (AAP) is a FIPA-compliant agent platform that is designed to be a lightweight and powerful solution for developing agent-based systems. It is written using the April programming language and the InterAgent Communication System (IMC), and provides many features to accelerate the development and deployment of agents and agent platforms. Access (open source license): GPL Environment, minimal configuration: The AAP requires the April programming language and the ICM to be installed, and runs either on Linux, Unix or Windows. Availability: the framework is available from URL http://sf.us.agentcities.net/aap/index.html

5.15.7 Grasshopper

Grasshopper (a detailed presentation is available on Cordis http://cordis.europa.eu/infowin/acts/analysys/products/thematic/agents) is an open 100% Java-based mobile intelligent agent platform, which is compliant to both available international agent standards, namely the OMG MASIF and FIPA specifications. Grasshopper includes two optional open source extensions providing the OMG MASIF and FIPA standad interfaces for agent/platform interoperability. The Grasshopper agent platform developed by GMD FOKUS and IKV++, which is the first OMG MASIF and FIPA 97-conformant agent platform. In fact, Grasshopper is in principle a MASIF-conformant mobile agent platform, which has been enhanced recently with a FIPA add on in order to give the application developer total flexibility. This evolution of the platform is witnessing the fact that the traditional separation of mobile agents and intelligent agents is going to fade away smoothly, as the corresponding standards bodies, i.e., OMG (namely the Agent SIG) and FIPA, are aiming to develop compatible standards. So Grasshopper enables its users to develop a broad range of agents, ranging from small simple mobile agents roaming the network nodes up to static multi-agent systems talking via an Agent Communication Language (ACL) for distributed problem solving. Today, Grasshopper is the agent platform of choice in multiple international research projects within the European CLIMATE (Cluster for Intelligent Mobile Agents for Telecommunication Environments). A common aspect of most of these projects is to explore the usage of agent-based middleware in particular application domains, such as service control in fixed and mobile networks, telecommunications management, electronic commerce, multimedia applications, etc. In principle, Grasshopper realises a Distributed Agent Environment (DAE). The DAE is composed of regions, places, agencies and different types of agents. A place provides a logical grouping of functionality inside of an agency. The region concept facilitates the management of the distributed components (agencies, places, and agents) in the Grasshopper environment. Agencies as well as their places can be associated with a specific region by registering them within the accompanying region registry. All agents that are currently hosted by those agencies will also be automatically registered by the region registry. If an agent moves to another location, the corresponding registry information is automatically updated. Figure 1 depicts an abstract view of these entities.

88 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Figure 48. The Grasshopper Distributed Agent Environment Two types of agents are distinguished in Grasshopper: • mobile agents • stationary agents. The actual runtime environment for both mobile and stationary agents is an agency; on each host at least one agency has to run to support the execution of agents. A Grasshopper agency consists of two parts: the core agency and one or more places. Core Agencies represent the minimal functionality required by an agency in order to support the execution of agents. The following services are provided by a Grasshopper core agency: Communication Service : This service is responsible for all remote interactions that take place between the distributed components of Grasshopper, such as location-transparent inter-agent communication, agent transport, and the localisation of agents by means of the region registry. All interactions can be performed via CORBA IIOP, Java RMI, or plain socket connections. Optionally, RMI and plain socket connections can be protected by means of the Secure Socket Layer (SSL) which is the de-facto standard Internet security protocol. The communication service supports synchronous and asynchronous communication, multicast communication, as well as dynamic method invocation. As an alternative to the communication service, Grasshopper can use its OMG MASIF-compliant CORBA interfaces for remote interactions. For this purpose, each agency provides the interface MAFAgentSystem, and the region registries provide the interface MAFFinder Error! Reference source not found. Registration Service : Each agency must be able to know about all agents and places currently hosted, on the one hand for external management purposes and on the other hand in order to deliver information about registered entities to hosted agents. Furthermore, the registration service of each agency is connected to the region registry which maintains information of agents, agencies and places in the scope of a whole region. Management Service: The management services allow the monitoring and control of agents and places of an agency by (human) users. It is possible, amongst other things, to create, remove, suspend and resume agents, services, and places, in order to get information about specific agents and services, to list all agents residing in a specific place, and to list all places of an agency. Security Service: Grasshopper supports two security mechanisms: external and internal security. • External security protects remote interactions between the distributed Grasshopper components, i.e. between agencies and region registries. X.509 certificates and the Secure Socket Layer (SSL) are used for this purpose. SSL is an industry standard protocol that makes substantial use of both symmetric and asymmetric cryptography. SSL provides confidentiality, data integrity, and mutual authentication of both communication partners. • Internal security protects agency resources from unauthorised access by agents. It is also used to protect agents from each other, and this is achieved by authenticating and authorising the user on whose behalf an agent is executed. Access control policies are activated according to the outcome of authentication and authorisation. The internal security capabilities of Grasshopper are mainly based on Java security mechanisms. Persistence Service: The Grasshopper persistence service enables the storage of agents and places (the internal information maintained inside these components) on a persistent medium. In this way, it is possible to recover agents or places when needed, e.g. when an agency is restarted after a system crash. 89 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

The communication facilities of Grasshopper are realised by the Communication Service (CS), which is an essential part of each core agency. Communication service allows location-transparent interactions between agents, agencies, and non-agent-based entities. As an alternative to the communication service, Grasshopper can use its OMG MASIF-compliant CORBA interfaces for remote interactions. For this purpose, each agency provides the interface MAFAgentSystem, and the region registries provide the interface MAFFinder. Those interfaces are defined in the MASIF standard. Note that the following sections only describe the Grasshopper communication service. Detailed information about MASIF can be found in the standard itself.

The Grasshopper agent platform is the enabling technology for many European agent projects. A comparison of Grasshopper with other MA platforms, such as IBM Aglets Workbench, Concordia, Odyssey, and Voyager is given in Error! Reference source not found. . The first Grasshopper version was released in summer 1998. In February 1999, Grasshopper Release 1.2 has become available, which offers a simplified user interface for the security configuration. Besides, the communication protocols are realised via a defined plug-in mechanism that enables the easy integration of additional communication protocols. Release 2.0 of Grasshopper (available autumn 1999) offers the following new features: • complete support of the Java 2 Platform (formerly JDK 1.2); • provision of an alternative mechanism as an optional substitute for the region registry, based on JNDI; • optional Grasshopper runtime environment as a Java applet; • provision of beans extensions for the major classes of the Grasshopper platform to enable the easy integration into beans supporting IDEs (Integrated Development Environments). The Grasshopper FIPA Add On (available autumn 1999) works with both versions 1.2 and 2.0. Future application domains for Grasshopper will be the ongoing integration of voice and data networks, unified messaging, and active networking. Furthermore, major emphasis will be placed on using Grasshopper for electronic commerce applications, e.g., financial services, and the implementation of distributed internet search engines, where the integration of existing web information is of pivotal importance. For more papers related to this subject please look at the download/paper section of the IKV web site Error! Reference source not found. . A free demo version of Grasshopper, in order to experiment with this new technology, is available. Error! Reference source not found. -Error! Reference source not found.

5.16 Context awareness and information

5.16.1 Definition Context

Is a description of a real world situation on an abstract level that is derived from available cues. A cue is an abstraction of logical and physical sensors and may represent a context itself, generating a recursive definition of context. Sensor data, cues and context descriptions should be defined in a framework of uncertainty. We are turn now towards a working definition of attention, in order to prepare for a description of the interaction between context and attention as the underlying motivation for the Attentive Interface.

5.16.2 Context-Generating Modules (CGM)

The Context Generating Modules derive context information from their input data. Such information may for example be the object id from an object detected in the input image or an estimate for the user’s location. All Context-Generating Modules additionally return a confidence value for their processing result, which is used for integrating the partial context information into a whole context information within the Context Interpreter Component.

5.16.3 Multi-Modal Location (MML)

The Multi-Modal Location Component (MML) fuses raw sensor data from GPS, WiFi, GSM, to an integrated location estimate. It is located on the client, therefore only the preprocessed sensor data is sent to the server via the Internet. The function of a MML is to calculate location estimate from raw sensor data. The input raw data is from sensors: GPS, WiFi, GSM, Bluetooth. The output is the estimation of the location coordinates + confidence value.

90 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

5.16.3.1 Multi-Modal Activity (MMA)

The Multi-Modal Activity Component (MMA) calculates the user’s activity (sitting, juggling, climbing stairs,..) and mode of transportation (walking, driving car, bus, cycling,..) on the basis of inertial and pose sensors. Its function is to calculate user activity and mode of transportation from raw sensor data. The input raw data comes from inertial and pose sensors and the output gives the user activity, mode of transport + confidence value for both.

5.16.3.2 Multi-Modal Localization (MMLS)

The Multi-Modal Localization Component (MMLS) integrates location estimates from the MML, LV and GEO components. In comparison to MML it uses the estimate from LV, GEO and MML. Its function is to calculate integrated location estimate. They can have various inputs: input A: location estimate from MML (stored in Geo-MM database), input B: location estimate from LV (stored in CONTEXT database, passed via Context Node) and input C: location estimate from GEO (pass mode of transport and estimated position). The output is a location estimate + confidence value

5.16.3.3 Localization from Vision (LV)

The Localization from Vision Component (LV) recovers the user’s position and orientation relative to a map on the basis of a still image. Its function is to calculate user’s position and orientation from a still image. The input is a still image (stored in Geo-MM database) and a rough estimate of location (from CI). The output are map coordinates and camera’s orientation (+ confidence value).

5.16.3.4 Context from Vision (VC)

The Context from Vision Component generates a context confidence maps to enable the concept of context awareness for object recognition for a given object class. The purpose is to reduce the search space for subsequent recognition tasks. Its function is to calculate context confidence scores. The input is a still image (stored in Geo-MM database, 1500x1000 pixel resolution is sufficient) and an ID of object class. The output image contains context confidence scores.

5.16.3.5 Reference

Specification of Attentive Interface” MOBVIS FP6-511051 - Deliverable Report D6, Vision Technologies and Intelligent Maps for Mobile Attentive Interfaces in Urban Scenarios, Project co-funded by the European Commission Sixth Framework Programme (2002-2006)

5.16.4 State of the art of Sensor Networks in Ubiquitous and Wearable Computing

Interaction with computers can happen in different ways, on different levels of user-involvement, and with different applications in mind. This section will introduce two fields with strong ties to research in human-computer interaction, and an emerging culture of involving sensors in these views.

5.16.4.1 The Ubiquitous Vision

The term ubiquitous computing is originally dubbed by Mark Weiser, who used it to name the third wave of computing. His website clarifies: “First were mainframes, each shared by lots of people. Now we are in the personal computing era, person and machine staring uneasily at each other across the desktop. Next comes ubiquitous computing, or the age of calm technology, when technology recedes into the background of our lives. Alan Kay of Apple calls this ‘Third Paradigm’ computing“. Ubiquitous computing is in Weiser’s work positioned as an opposite of virtual reality, where computers are integrated in the real world (instead of putting people in computer-generated environments). Ubiquitous Computing could be seen as an approach to human-computer interaction, but is also about distributing computation in the environment, as opposed to keeping it bottled in a desktop-bound personal computer.

5.16.4.2 The Wearable Vision

91 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

Wearable computing is closely related to ubiquitous computing, but restricts itself to the computer as a worn, personal technology that makes information instantly available to the wearer. The research was initially aimed at handheld-sized, hip-worn devices with micro-optical displays integrated in spectacles, but has gradually shifted to one or more computing elements actually embedded in clothing. The fuzzy definition of a wearable computer is that it's a computer that is always with the wearer, is comfortable and easy to keep and use, and is as unobtrusive as clothing. However, this ‘smart clothing’ definition is unsatisfactory when pushed in the details. A more specific definition is that wearable computers have many of the following characteristics: Portable while operational, possible to use hands- free, using sensors, attention-getting, and always in on-mode.

5.16.4.3 Ubiquitous Sensors

The sensor is an additional element that is making its way into both the ubiquitous computing and wearable computing fields. It has the potential to give the computer system information without any user- interaction (a light sensor regulating the brightness of a display for instance), or augment the user’s senses (e.g. a thermometer giving the precise temperature). Many sensors can also be combined with the advances made in wireless ad-hoc networks (and development of protocols such as Bluetooth or Wave LAN), to give clearer, more precise readings.

An example of a ubiquitous sensor is the porcupine. It is a small wearable sensory unit for logging motion data and doing low-level activity recognition. It is designed to: • be worn 24/7, without changing or recharging batteries in between • sense the physical actions of the user: what is the wearer doing? • record what it senses non-stop for weeks, with a minimum of user interaction

Figure 49. The Porcupine wearable sensory Android & Iphone are 2 new platforms are available and devices in general are having more sensors integrated.(esp. GPS, WiFi & Acc) Most research uses Smart/PDA-Phones etc. with build in sensors (or connected to them, like the MSR research we saw from Nuria or MSP). Besides this only domain specific (standalone) gadgets like Nike Shoesensors, GPS Trackers, Photo Geocoding solutions exists.

Error! Reference source not found. -Error! Reference source not found.

92 | P a g e

i-Travel Deliverable D1.1 “i -Travel State of the art”

5.17 Conclusions

The qualitative overview (assessment) of technologies and service related aspects was undertaken to delimit the sphere of iTravel services. To research and design the global services for the connected traveller, enabling their instantiation and the exploitation of the added value brought by the project’s outcomes, the need of the intelligent mix of many technologies is essential.

To reflect the main requirements of the global service it is clear that the iTravel should be implementing the first Internet of Things application, working at the worldwide level.

The full implementation of the iTravel platform would be an Integrated project, while the proof of the concept should put together the minimal number of the candidates technologies above described.

It is clear that the iTravel relies on the IP connectivity, which should be bi-directional, e.g. the GPRS/UMTS communication with the RF (DVB) feedback enabling the ensured and synchronised uni-cast, group-cast, or the broad-cast. It is also clear that the mobile representing a traveller should gather the context-related information and the indoor positioning and the outdoor geo-referencing, which might be done using GPS localisation in outdoor context plus some specific indoor technologies. The context awareness might be achieved by multi-sensorial devices, including those wearable, or AAL ones. Moreover, the RFID/NFC technology might be used for the context characterisation.

The intermittent state might be managed using the Internet of Things enabled extended middleware; a reference implementation is missing, but the prototype is available from ISMB (Italy).

The broker, intelligent agent might be implemented using the standard Agent technologies, while the extended cooperation among distributed entities would be needed to exploit the social networks in the abroad’s topologies embracing several travellers presenting similar social interests, wishes and aims. The intelligent dimension should be supported by the reasoning and travel’s ontology.

The way the knowledge will be elicited, data fused, and the reasoning performed, would be delegated to the implementation, however partial intelligence should be available locally on the mobile devices being impossible to keep the link with the central server alive during the flight for example, because of the rules forcing to switch off all mobile devices inside the aircraft. The re-appearance of the mobile device in a new location (in roaming) is the discontinuity of the state sequence, however the new state is known apriori being known the travelling plan in advance.

The choice of the options would be done under the architecture-related chapter, consequently we conclude saying that the overview of the technologies was executed in a way to deliver key elements for the decision making about the optimal mix of the technologies.

93 | P a g e