SATINE Deliverable 3.1.1 by liuhongmei

VIEWS: 7 PAGES: 96

									                                         IST-2104 STP

                                                  SATINE
            "A Semantic-based Interoperability Infrastructure for
             integrating Web Service Platforms to Peer-to-Peer
                                Networks"

         SPECIFIC TARGETED RESEARCH PROJECT

         PRIORITY 2.3.1.9
         Networked Businesses and Governments


Satine – M2 Satine Prototype Phase 1: Storyboard of
the First Prototype
                                                                                                   FINAL

       Due Date:                        May 1, 2005
       Actual Submission Date:
       Project Dates:                   Project Start Date: January 1, 2004
                                        Project End Date: June 30, 2006
                                        Project Duration: 30 months
       Leading Contractor               All Consurtium
       Organization:


   Project co-funded by the European Commission within the Sixth Framework Programme (2002-2006)
                                                  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)
Short Description: This document describes the functionalities of the SATINE Platform
after the completion of the SATINE Prototype Phase 1 (Milestone2) based on a scenario
where the detailed setup and execution information related with different components are
presented.

SATINE Consortium Contacts:

Organisation    Name               Phone               Fax                   E-Mail
METU-SRDC       Asuman Dogac       +90-312-2105598     +90(312)2101004       asuman@srdc.metu.edu.tr
Fraunhofer      Volker             +49 30 3463 7226    +49 30 3463 8000      Volker.tschammer@fokus.fraunh
FOKUS           Tschammer                                                    ofer.
ED              Nikitas Tsopelas   +30 210 8094 500    +30 210 8094 508      Nikitas.Tsopelas@eurodyn.com
Oxymel          Dominique Le       +33 1 39 43 00 65   +33 1 39 43 65 21     dleroux@oxymel.com
                Roux
INTRO           Onur Evren         ++90 312 4472514    +90 312 4469177       onur.evren@introsolutions.com
RMIT            Lin Padgham        ++61 3 9925 3214    +61 3 96621617        linpa@cs.rmit.edu.au



Document History:

Version      Date          Changes                                         From               Review

0.0          January 26, Document template is created                      METU-SRDC          All partners
             2005

0.1.1        February 3, METU input for main diagrams                      METU-SRDC          All partners
             2005

0.2          February 14, METU detailed input is completed                 METU-SRDC          All partners
             2005

0.3          February 16, The detailed substeps are integrated             Consurtium         All partners
             2005

0.4          February 23, Revision by METU                                 METU-SRDC          All partners
             2005




                                                                                        Page 2 of 96
Abstract
The SATINE project will develop a semantic-based interoperability framework for the tourism
industry. The framework will provide tools and mechanisms for publishing, discovering and
invoking Web services through their semantics in peer-to-peer networks, thus exploiting the
synergies between these two technologies. This document describes the functionalities of the
SATINE Platform after the completion of the SATINE Prototype Phase 1 (Milestone 2) based on
a scenario where the detailed setup and execution information related with different components
are presented.

The initial prototype which was implemented for the demonstration in the first review meeting
and based on the modules and interfaces described and detailed in deliverable D3.2.1
“Conceptual Design of SATINE” has been worked on to create the first SATINE prototype. The
main progresses achieved in this demonstration of the first SATINE Prototype over what is
demonstrated in the first review meeting are as follows:
    The integration of the components under the responsibility of different partners to gather
        the functionalities of SATINE Platform into one system
             o SATINE Portal developed by ED is integrated to the SATINE Platform. The
                 portal performs the authentication of the peers upon registration and monitors the
                 available network population so that the newly joined peer can select which
                 Super Peer and Trusted Peer it will connect.
             o P2P network facilities are enhanced by ED. The invocation of the Web services
                 are updated to be done over Super Peers and the required adjustments are
                 realized to enable the possible global to global mapping of the messages in the
                 SATINE Network.
             o Web Service creation tool which wraps the existing databases that serve tourism
                 information as Web services and Web Service Annotation tool which creates the
                 semantic definitions of the Web services using the available ontologies in the
                 system is developed by OXYMEL. These components are integrated to the
                 system where the functionalities of these components are shown in the
                 demonstration steps as detailed in this document.
             o The completed parts of the Web Service Composition tool being developed by
                 FOKUS are integrated to the current SATINE architecture. Using
                 WSComposition tool, complex workflows can be semantically composed and
                 related services can be located in the processes using the querying facilities of
                 SATINE Network.
             o METU developed the semantically enriched ebXML component and it is
                 integrated to the current system. This component facilitates the deployment of
                 ontologies to the ebXML registry and the services being published are related
                 with these semantic concepts by processing their semantic definitions. Finally,
                 this component enables the semantically querying of the ebXML registry.
             o The OWL mapping tool developed by METU is integrated to the system which
                 enhanced the semantic capability of the system. With the introduction of the
                 OWL mapping tool the message ontologies are redefined in OWL and the new
                 mapping definitions are created.
             o The possible looping of the messages among the Super Peers in the SATINE
                 Network are avoided by the efforts of METU in the integration phase.
    Providing security of the Web service invocation.
             o METU implemented and integrated a tool which guides the user to create a Web
                 Service Security Policy of a Web service. By the help of this tool the policy file


                                                                                     Page 3 of 96
            is created seemless to the user behind a graphical user interface where the user
            can specify which parts of the messages have to be encrypted.
       o The functionalities of the Trusted Peer is enhanced by METU. First of all, the
            secret key created by the Trusted Peer for each transaction and delivered to the
            peers taking place in the transaction are being sent to the related peers after being
            encrypted by the public keys of those peers according to the PKI infrastructure so
            that only the related peers are enabled to get the secret key using their private
            keys. The interface between Super Peers and the Trusted Peer is implemented
            since the invocation of the Web services are done through Super Peers (to enable
            semantic mediation) the Super Peers have to interact with the Trusted Peer to
            preserve the security of the invocation process.
       o Since the parties with different semantic knowledge are enabled to communicate
            through SATINE Network, it is required to interoperate the security policies of
            different tourism parties. The semantically mapping of security policy file is
            integrated to the system by METU.
   The facilities of the Monitoring Peer are upgraded by METU.
       o The performance of the monitoring peer is enhanced so that it consumes
            neglegible CPU cycles.
       o The messages displayed by the Monitoring Peer are enriched for Trusted Peers
            and the Super Peers.




                                                                                  Page 4 of 96
Table of contents
1      INTRODUCTION..................................................................................................... 9
    1.1      PURPOSE .............................................................................................................. 9
    1.2      SCOPE .................................................................................................................. 9
    1.3      OVERVIEW ......................................................................................................... 10
    1.4      DEFINITIONS AND NOTATION ............................................................................. 11
       1.4.1     Requirement Levels Indications ................................................................ 11
2      STORYBOARD ...................................................................................................... 12
    2.1      SCENARIO .......................................................................................................... 12
    2.2      PLAYERS & SERVICES ................................................................................. 13
       2.2.1     Service Providers ...................................................................................... 13
       2.2.2     Service User: Corporate Travel – A Travel Agency ................................. 15
    2.3      DEMONSTRATION DETAILS ................................................................................ 15
       2.3.1     Implementation Details ............................................................................. 17
    2.4      DEMONSTRATION STEPS .................................................................................. 17
       2.4.1     Monitoring Peer joins to the network ....................................................... 17
       2.4.2     Trusted Peer joins network ....................................................................... 19
       2.4.3     Super Peer1 (SP1) joins network .............................................................. 23
       2.4.4     Super Peer2 (SP2) joins network .............................................................. 24
       2.4.5     Super Peer3 (SP3) joins network .............................................................. 25
       2.4.6     Ontology Manager joins network ............................................................. 26
       2.4.7     Ontology Manager deploys Global Message and Functionality Ontologies
                 28
       2.4.8     Marco Polo joins network ......................................................................... 35
       2.4.9     Marco Polo selects Global Message Ontology and deploys it's Local
       Message Ontology and Mapping Definitions ........................................................... 35
       2.4.10    Marco Polo adds it's ebXML Registry to the system ................................ 40
       2.4.11    Marco Polo advertises Multi Properties Availability Search service to
       ebXML Registry ........................................................................................................ 43
       2.4.12    Fly To Europe joins network..................................................................... 45
       2.4.13    Fly To Europe deploys it's Ontologies and Mapping Definitions............. 45
       2.4.14    Fly To Europe adds it's UDDI Registry to the system .............................. 50
       2.4.15    Fly To Europe advertises Air Multi Availability service to UDDI Registry
                 53
       2.4.16    European Travel joins network ................................................................. 56
       2.4.17    European Travel creates it’s Local Message Ontology from database
       schema using Ontology Manager Tool ..................................................................... 56
       2.4.18    European Travel creates global2local and local2global mapping
       definitions using OWL2OWL Mapping Tool ............................................................ 59
       2.4.19    European Travel deploys it's Local Message Ontology and Mapping
       Definitions ................................................................................................................. 61
       2.4.20    European Travel wraps a Hotel Database to provide a Hotel Search and
       Availability web service using WSCreation tool ....................................................... 64



                                                                                                                    Page 5 of 96
       2.4.21    European Travel semantically annotates Hotel Search and Availability
       web service using WSAnnotation tool ....................................................................... 67
       2.4.22    European Travel creates the security policy file for the Hotel Search and
       Availability web service ............................................................................................ 70
       2.4.23    European Travel advertises Hotel Search and Availability to a "User
       Specified Location" (USL). ....................................................................................... 73
       2.4.24    Corporate Travel joins network ................................................................ 75
       2.4.25    Corporate Travel queries network for HotelAvailabilityServices ............ 76
       2.4.26    Corporate Travel invokes the service provided by European Travel ....... 80
       2.4.27    Corporate Travel Creates Complex Service ............................................. 89
3      APPENDIX .............................................................................................................. 95
    3.1      ONTOLOGIES ...................................................................................................... 95
       3.1.1    Functionality Ontology ............................................................................. 95
       3.1.2    OTA Air Message Ontology ...................................................................... 95
       3.1.3    Amadeus Air Message Ontology ............................................................... 95
       3.1.4    Galileo Air Message Ontology.................................................................. 95
       3.1.5    OTA Hotel Message Ontology .................................................................. 95
       3.1.6    Amadeus Hotel Message Ontology ........................................................... 95
       3.1.7    LocalDB Hotel Message Ontology ........................................................... 95
       3.1.8    OTA Car Message Ontology ..................................................................... 95
    3.2      OWL-S FILES .................................................................................................... 95
       3.2.1    Amadeus AirMultiAvailability Service ...................................................... 95
       3.2.2    Galileo AirMultiAvailability Service ........................................................ 95
       3.2.3    Amadeus HotelAvailability Service........................................................... 96
       3.2.4    LocalDB HotelAvailability Service ........................................................... 96
    3.3      WSDL FILES ..................................................................................................... 96
       3.3.1    Amadeus AirMultiAvailability Service ...................................................... 96
       3.3.2    Galileo AirMultiAvailability Service ........................................................ 96
       3.3.3    Amadeus HotelAvailability Service........................................................... 96
       3.3.4    LocalDB HotelAvailability Service ........................................................... 96




                                                                                                               Page 6 of 96
List of Figures
FIGURE 1 OVERALL VIEW OF THE PLAYERS IN THE PROTOTYPE SETTING .......................... 10
FIGURE 2 PEER VIEW OF DEMONSTRATION SETUP ............................................................. 16
FIGURE 3 MONITORING PEER REGISTRATION..................................................................... 18
FIGURE 4 MONITORING PEER CONFIGURATOR ................................................................... 18
FIGURE 5 MONITORING PEER PANEL ................................................................................. 19
FIGURE 6 TRUSTED PEER REGISTRATION ........................................................................... 20
FIGURE 7 PEER CONFIGURATION DIALOG “COMMON SETTINGS” ........................................ 21
FIGURE 8 PEER CONFIGURATION “SPECIFIC SETTINGS” ...................................................... 21
FIGURE 9 MONITORING PEER PANEL AFTER TRUSTED PEER REGISTRATION ..................... 22
FIGURE 10 SUPER PEER (SP1) REGISTRATION FLOW ........................................................... 23
FIGURE 11 SUPER PEER (SP2) REGISTRATION FLOW ........................................................... 24
FIGURE 12 SUPER PEER (SP3) REGISTRATION FLOW ........................................................... 25
FIGURE 13 ONTOLOGY MANAGER REGISTRATION FLOW .................................................... 26
FIGURE 14 PROCESS CONFIGURATION DIALOG “SPECIFIC SETTINGS” ................................. 27
FIGURE 15 PEER AUTHENTICATION MESSAGE..................................................................... 27
FIGURE 16 LIST OF AVAILABLE SUPER & TRUSTED PEERS .................................................. 28
FIGURE 17 SUPER & TRUSTED PEER SELECTION ................................................................. 28
FIGURE 18 FUNCTIONALITY ONTOLOGY DEPLOYMENT BY THE ONTOLOGY MANAGER .... 29
FIGURE 19 INITIAL ONTOLOGY DEPLOYMENT PANEL.......................................................... 31
FIGURE 20 DEPLOY GLOBAL ONTOLOGY ........................................................................... 31
FIGURE 21 GLOBAL ONTOLOGY DEPLOYED ...................................................................... 32
FIGURE 22 GLOBAL ONTOLOGY DEPLOYMENT ................................................................... 32
FIGURE 23 GLOBAL ONTOLOGY DEPLOYMENT WITH SENDING GO ON THE PORTAL ........... 33
FIGURE 24 GLOBAL MESSAGE ONTOLOGY DEPLOYMENT BY ONTOLOGY MANAGER ........ 34
FIGURE 25 MARCO POLO REGISTRATION FLOW................................................................. 35
FIGURE 26 MARCO POLO LOCAL MESSAGE ONTOLOGY AND MAPPING DEFINITIONS
    DEPLOYMENT ............................................................................................................ 36
FIGURE 27 SELECT GLOBAL MESSAGE ONTOLOGY ............................................................. 38
FIGURE 28 DEPLOY LOCAL AMADEUS AIR MESSAGE ONTOLOGY ....................................... 39
FIGURE 29 DEPLOY LOCAL2GLOBAL MAPPING DEFINITION ................................................ 39
FIGURE 30 DEPLOYED ONTOLOGIES AND MAPPINGS .......................................................... 40
FIGURE 31 EBXML REGISTRY ADDITION BY MARCO POLO ............................................... 40
FIGURE 32 ADD SERVICE REGISTRY PANEL ....................................................................... 41
FIGURE 33 FUNCTIONALITY ONTOLOGY IS CHOSEN ............................................................ 41
FIGURE 34 RESPONSE FROM THE REGISTRY ....................................................................... 42
FIGURE 35 MARCO POLO MULTI PROPERTIES AVAILABILITY SEARCH SERVICE
    ADVERTISEMENT TO EBXML REGISTRY .................................................................... 43
FIGURE 36 ADVERTISE PANEL ........................................................................................... 44
FIGURE 37 WS ADVERTISEMENT ....................................................................................... 45
FIGURE 38 FLY TO EUROPE REGISTRATION FLOW .............................................................. 45
FIGURE 39 FLY TO EUROPE LOCAL MESSAGE ONTOLOGY & MAPPING DEFINITIONS
    DEPLOYMENT ............................................................................................................ 46
FIGURE 40 DEPLOY LOCAL GALILEO AIR MESSAGE ONTOLOGY ......................................... 49
FIGURE 41 DEPLOY LOCAL2GLOBAL MAPPING DEFINITION ................................................ 49


                                                                                                            Page 7 of 96
FIGURE 42 DEPLOYED MESSAGE ONTOLOGIES AND MAPPING DEFINITIONS ........................ 50
FIGURE 43 FLY TO EUROPE UDDI REGISTRY ADDITION TO THE SYSTEM .......................... 50
FIGURE 44 PROVIDING REGISTRY INFORMATION ................................................................ 51
FIGURE 45 FUNCTIONALITY ONTOLOGY DEPLOYMENT TO THE REGISTRY ......................... 51
FIGURE 46 DEPLOY ONTOLOGY IN REGISTRY ..................................................................... 52
FIGURE 47 FLY TO EUROPE AIR MULTI AVAILABILITY SERVICE ADVERTISEMENT TO UDDI
    REGISTRY .................................................................................................................. 53
FIGURE 48 PUBLISH SERVICE IN REGISTRY ......................................................................... 55
FIGURE 49 EUROPEAN TRAVEL REGISTRATION FLOW ........................................................ 56
FIGURE 50 LOCAL MESSAGE ONTOLOGY CREATION FROM DATABASE SCHEMA ................ 57
FIGURE 51 ONTOLOGY MANAGEMENT PANEL ................................................................... 58
FIGURE 52 ONTOLOGY CREATION CONFIRMATION DIALOG ............................................... 58
FIGURE 53 OWL2OWL MAPPING ........................................................................................ 59
FIGURE 54 ONTOLOGY MANAGEMENT PANEL ................................................................... 60
FIGURE 55 OWLMT MAPPING TOOL ................................................................................ 60
FIGURE 56 SPECIFYING TARGET AND SOURCE ONTOLOGIES .............................................. 61
FIGURE 57 DESIGN OF MAPPING DEFINITIONS ................................................................... 61
FIGURE 58 EUROPEAN TRAVEL LOCAL MESSAGE ONTOLOGY AND MAPPING DEFINITIONS
    DEPLOYMENT ............................................................................................................ 62
FIGURE 59 WSCREATION .................................................................................................. 65
FIGURE 60 GENERATE WEB SERVICE (WSCREATOR) ........................................................ 67
FIGURE 61 WEB SERVICE ANNOTATION ............................................................................ 68
FIGURE 62 ANNOTATE WEB SERVICE (WSANNOTATOR) .................................................. 70
FIGURE 63 SECURITY POLICY FILE CREATION FOR WS ..................................................... 71
FIGURE 64 SELECTING THE ENCRYPTION PARTS ................................................................ 71
FIGURE 65 CREATE SECURITY POLICY PANEL ................................................................... 72
FIGURE 66 CREATED SECURITY POLICY FILE .................................................................... 72
FIGURE 67 WS ADVERTISEMENT TO USL .......................................................................... 73
FIGURE 68 PUBLISH&ADVERTISE PANEL........................................................................... 74
FIGURE 69 MONITORING PANEL FOR ADVERTISING SERVICES........................................... 74
FIGURE 70 CORPORATE TRAVEL REGISTRATION FLOW ...................................................... 75
FIGURE 71 QUERYING SERVICES IN SATINE NETWORK ................................................... 76
FIGURE 72 LOOKUP SERVICE PANEL .................................................................................. 77
FIGURE 73 MONITORING QUERY MESSAGES ..................................................................... 79
FIGURE 74 QUERY RESULTS .............................................................................................. 79
FIGURE 75 ROUTING FOR INVOCATION MESSAGE .............................................................. 80
FIGURE 76 INVOKE SERVICE INTERFACE ............................................................................ 81
FIGURE 77 MONITORING INVOCATION ROUTING ............................................................... 84
FIGURE 78 ROUTE FOR SERVICE RESULT ........................................................................... 85
FIGURE 79 RESULT OF SERVICE ......................................................................................... 87
FIGURE 80 RESULT OF SERVICE ......................................................................................... 87
FIGURE 81 RESULT OF SERVICE ......................................................................................... 87
FIGURE 82 RESULT OF SERVICE ......................................................................................... 88
FIGURE 83 RESULT OF SERVICE AS HTML .......................................................................... 88
FIGURE 84 COMPOSITION AND DEPLOYMENT OF COMPLEX SERVICE................................. 89
FIGURE 85 VISUAL MODELING TOOL ................................................................................. 91
FIGURE 86 EXECUTION OF COMPLEX SERVICE ................................................................... 92



                                                                                                               Page 8 of 96
1 Introduction
1.1 PURPOSE
This document describes the first SATINE prototype which is developed with the completion of
Milestone 2 "SATINE Prototype Phase 1". The functionalities of the system are presented based
on a pre-defined scenario. Each component of the system which are developed by different
partners and integrated within the scope of SATINE Prototype Phase 1, is detailed with related
figures and diagrams.

The first Prototype of SATINE is developed with the evolution of the initial prototype
implementation which is conformant to the deliverable D.3.2.1 “Conceptual Design of SATINE”
and demonstrated in the first review meeting of the project. The first prototype will be further
improved in the period that will be covered for the SATINE Prototype Phase 2.


1.2 SCOPE
The SATINE project will develop a semantic-based interoperability framework for the tourism
industry. The framework will provide tools and mechanisms for publishing, discovering and
invoking Web services through their semantics in peer-to-peer networks, thus exploiting the
synergies between these two technologies. By means of the SATINE tools and infrastructure
tourism companies, such as hotel chains, car rental agencies and airline companies, will be able to
     wrap their applications with Web services,
     enrich those services with semantic descriptions,
     publish them on the P2P network.

Service requestors, such as travel agencies or ordinary people, will be able to
     discover services based on their semantics,
     invoke them,
     combine simple travel services to complex ones.

In order to be compliant with industry standards, the Open Travel Alliance (OTA) specifications
are considered for the messages exchanged between the trading partners. However, OTA
compliance is not a mandatory requirement. SATINE architecture allows the trading partners to
use their existing message structures. In this demonstration the Web Service Providers are
Amadeus GDS compliant hence they developed local ontologies based on Amadeus message
structures. On the other hand, the requestors are OTA compliant. The SATINE architecture
performs the necessary mapping between these different message structures of providers and
requestors.




                                                                                     Page 9 of 96
1.3 OVERVIEW
In the demonstration of the first prototype of SATINE, we consider several travel industry related
companies that are connected to the SATINE based Travel Network, which provides services
related with Air, Hotel and Car-Rental travel products. The service user is a Travel Agency which
provides trip organization service to large corporations. This company resells travel products
found in the SATINE Travel Network, benefiting from the rich set of alternatives with special
prices. The application deployed at this company is connected to the SATINE network hence,
based on the requests obtained from the end users, the queries, bookings and other operations on
the travel services are realized through the web services published by the service providers
connected to the network.
Through the set of interfaces, the agent at the service user company, i.e. the reselling Travel
Agency, will be able to search for web services providing a certain travel service from the
functionality ontology. Later on, she can invoke the web service with appropriate inputs to check
for availability and pricing, to get detailed information on the travel product, and finally make
corresponding reservations and booking.
Note that, there are two consecutive stages for searching a travel product that suits with the user‟s
request. The first stage is to determine the service instances that are of the given service type,
such as locating services which provide Flight Availability functionality. The second stage in
searching a suitable travel product is to check the dynamic information bound to the service, such
as availability and the pricing, through executing the corresponding service, e.g. Flight
Availability, with appropriate arguments.


                                                                             Allotment / Pricing
                                                                             Managed Locally
                                                         European Travel -
                                       Fly to Europe –
                                                          Travel Agency
                GDS                    Travel Agency
             Connectivity




                                   SATINE
                            Travel Network
                                   Network

         Through SATINE
        enabled Interfaces

                                                                                              On-line connectivity
                                                                                                       to
                               Corporate Travel -                                              Amadeus GDS
  Agent UI                       Service User
                                                                    Marco Polo CRS


                             Figure 1 Overall View of the Players in the Prototype Setting




                                                                                               Page 10 of 96
Figure 1, presents an overall view of the players in the setting and scenario described in this
document, comprising the data management scheme and list of services provided at each end.
Each player is connected to the SATINE Travel Network, via its dedicated peer application. The
service users has several different characteristics, including
     Resource Management, e.g. travel products are provided through GDS which is
        communicated via proprietary protocol, or managed within a local database
     Language for Communication, e.g. XML Schema validated XML interface, or SQL
        based querying
     Business Rules, e.g. special-prices for certain travel products
The services of these providers will be made available to the SATINE platform, either through
XML based messaging or through the Semantic Wrapper module, both comprising semantics
based on local ontologies, in order to facilitate interoperability by mapping to and from global
travel ontology.
The P2P structure of the SATINE network will facilitate the search for available services
published in the network.

1.4 DEFINITIONS AND NOTATION

1.4.1                    Requirement Levels Indications
Occasionally in the text certain imperatives and adjectives will appear in uppercase. These words
indicate a specific level of requirement as presented by RFC 21191. A quick summary of these
definitions are as follows:

MUST, REQUIRED or SHALL: the definition is an absolute requirement of the specification.

MUST NOT or SHALL NOT: the definition is an absolute prohibition of the requirement.

SHOULD or RECOMMENDED: there may exist valid reasons in particular circumstances to
ignore the said definition, but the full implications should be understood and the case carefully
weighed before omitting any behavior described by this label.

SHOULD NOT or NOT RECOMMENDED: there may exist valid reasons in particular
circumstances to accept the said definition, but the full implications should be understood and the
case carefully weighed before implementing any behaviors described by this label.

MAY or OPTIONAL: means that the definition is truly optional, and can be included or omitted
from the implementation at the discretion of the implementer.




1
    RFC 2119, S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, March 1999


                                                                                        Page 11 of 96
2 Storyboard
2.1 SCENARIO
One of the clients of Corporate Travel requested an organization of a business trip in Europe.
One of the agents in Corporate Travel is assigned to organize the requested itinerary. The agent
logs into the SATINE Client Application, in order to reserve or book travel services to construct
the trip. The requested travel itinerary is as follows:
        One of the associate directors of the company will attend a conference in Rome,
        Italy. The conference will continue for three days, and the associate director
        arranged a few additional business meetings for possible collaboration with
        Italian companies, during that time. In this respect, a flight from London, U.K. to
        Rome, Italy is requested, in addition to a 4 day hotel reservation for the duration
        of the stay. The associate director has visited Rome a few times in the past hence
        he is confident with the general directions within the city. In this regard, a car-
        rental service will be reserved to enable transportation within the city. The
        company has also indicated that, a first class trip is not necessary, i.e. the flight
        will be booked from the economy class, and the hotel does not need to be
        luxurious.
The agent, first, books the necessary flight from London to Rome. SATINE Travel
Network is queried for Flight Availability services, and the system returns the list of
alternative services found in the network. The agent selects the service from Fly to
Europe, provides the date parameters and indicates that an economy class flight is
requested. Once the service is invoked, the system returns the available flights with the
given properties, on the selected date. The agent receives additional information about the
flight, via the associated Flight Information service, and later on does the booking for the
name of the client, i.e. the associate director.
The next operation is the reservation of the hotel room. Again, the agent queries the
system and receives two alternative services for Hotel Availability, from Marco Polo
CRS and from European Travel. The agent chooses the service provided by the Marco
Polo CRS, provides the necessary input, comprising the date of stay, the relative location
of the hotel (she knows that the conference will be held on the north region of Rome, and
tries to locate a hotel in the corresponding vicinity), and the hotel rating (both first class
and luxury, since she will select the most appropriate one later on).
In response to that invocation Marco Polo CRS provides a list of hotels, from the
Amadeus GDS. The agent examines the information and gets more detailed description
about the hotels, through additional Hotel Information queries. She identifies two



                                                                                      Page 12 of 96
alternatives suitable for the associate director nevertheless the prices seem to be a little
higher than expected. For this reason, she decides to try the other company found in the
SATINE Travel Network, European Travel.
The Hotel Availability service of European Travel is also invoked with the appropriate
parameters. She sees that one of the hotels that she had identified has agreements with
European Travel for special prices. She gets the hotel ID of that property, submits
consecutive Hotel Information queries, and checks the room availability and price. The
prices advertised are cheaper than that of Marco Polo CRS hence the agent reserves the
hotel through European Travel.
The final service is Car-Rental. The agent queries the system for Car-Rental services and
sees that Marco Polo CRS provides the requested functionality. She interacts with the
corresponding Car-Rental Availability service, and locates a car-rental agency at the
airport has availability for the duration of the stay. The agent makes the reservation, with
the corresponding attributes; comprising the date of arrival and departure, as well as the
pick up and drop off locations for the car.
As soon as the car-rental reservation is made, the business trip of the associate director is
ready.


2.2 PLAYERS & SERVICES
              2.2.1 Service Providers
There are several types of service providers considered for the setting of the SATINE prototype.
Each has individual characteristics, i.e. provides different set of services, comprises different
technologies and has separate input/output structures.

2.2.1.1 European Travel – A Small Travel Agency
European Travel is a small-scale travel agency which provides custom travel services such as
holiday tour packages.
The travel agency has made special agreements with several hotels around Europe and has
negotiated for special-priced rooms in the corresponding properties. The hotels allocate a certain
room quota for the European Travel, and the travel agency sells rooms from its allocated quota.
In time, the travel agency constructed a simple database that keeps information about the hotels,
e.g. amenities in the hotels and addresses, and daily prices and allocation for the hotel rooms.
European Travel participates in the SATINE Travel Network, in order to expand its customer
base. Henceforth, the travel agencies and tour operators that have joined the travel network will
locate European Travel, and book hotel rooms directly from its quota, with special prices. As a
result, European Travel will not need to invest its effort for finding customers but expanding its
business, via finding new hotel properties for collaboration.
The Semantic Database Wrapper module of SATINE will be utilized to deploy the information
within the hotel management database of European Travel in the form of SATINE compliant web
services.




                                                                                     Page 13 of 96
Through the special RDBMS Wrapper, European Travel will provide the following atomic
services related hotel reservation.
    1. Search and Availability:
        This function provides room availability information, fulfilling several properties:
        location at a certain city, including the corresponding room type information and
        associated rates.
    2. Detailed Hotel Information
        Presents detailed information about a given property, including but not limited to hotel
        and facility information, area and transportation information, as well as the hotel and
        room amenities.
    3. Reservation
        This function enables the reservation of hotel rooms for a given date period. The service
        users also indicate the requested room type as well as the traveler information for whom,
        the reservation is made.

2.2.1.2 Marco Polo - Central Reservation System
Central Reservation Systems provide a one-point of access to different travel resources and their
respective services. Through its connectivity to Amadeus GDS, Marco Polo CRS provides on-line
services in several travel categories, i.e. Air, Hotel and Car-Rental products.
Marco Polo CRS has several web services with well-defined input and output structures
exchanging messages in XML format, and respective XML Schemas defining these messages.
The mapping tool and other related utilities of SATINE will be utilized to generate a mapping
between the Marco Polo CRS and the global travel ontology of SATINE.
Marco Polo CRS provides several travel related services, through its connectivity to Amadeus
GDS. The enabled services are categorized as air, hotel and car-rental.
    1. Air Services
           a. Multi Availability
              This function provides the flight availability between two locations (city or
              airports) on a specific date.
           b. Detailed Flight Information
              Presents detailed information about a given flight, including equipment, meal and
              duration information for each segment
           c. Flight Booking
              Enables booking of a specific air service itinerary; specific flight(s), seat type and
              passenger information.
    2. Hotel Services
           a. Multi Properties Availability Search
              Lists the available properties located at a given city, with minimum and
              maximum room rates.
           b. Single Property Availability Search
              Provides detailed room availability of a specific property, including the
              corresponding room information and rates
           c. Detailed Hotel Information




                                                                                    Page 14 of 96
              Presents detailed information about a given property, including but not limited to
              hotel and facility information, policies, area and transportation information
          d. Room Reservation
              This function enables the reservation of hotel rooms of given type for a specific
              date period.
    3. Car Services
          a. Car-Rental Availability with Rates
               Availability search on rental facilities at a given location, along with information
               about provided vehicle types and their respective rates
            b. Car Rental - Reservation
                Single reservation based on the location and identification of the rental facility,
                date period and times (pick-up and return) and vehicle type

2.2.1.3 Fly to Europe – Travel Agency
This travel agency has a special application that provides connectivity to Galileo Global
Distribution System. It publishes Air Services, which are maintained by the Galileo in the
backend, to the SATINE travel network.
Fly to Europe provides several services regarding flight reservation, to the companies
participating in the SATINE Travel Network.
    1. Multi Availability
        This function provides the flight availability between two locations (city or airports) on a
        specific date (with/out a return flight).
    2. Flight Information
        Presents additional information about a given flight segment, including equipment, meal
        and duration information.
    3. Flight Booking
        Enables booking of a specific air service itinerary; specific flight(s) with given
        seat type and passenger information.

              2.2.2 Service User: Corporate Travel – A Travel Agency
Corporate Travel has made business agreements with travel companies and SATINE, in order to
be able to use their available services with special prices. SATINE has provided them with a set
of applications to search for services, check the availability and gather detailed information, and
finally make reservations and bookings. The generic user interfaces supplied by SATINE, enable
the invocation of services related with different travel service categories, such as Air, Hotel and
Car-rental.


2.3 DEMONSTRATION DETAILS
Throughout the demonstration, the main emphasis will be on the functionalities of the
components. Hence, the scenario which is based on only lookup and invocation facilities of
SATINE Platform will not be fully covered due to time constraints. However, each component
will be presented in detail focusing their functionality in the integrated system. The steps that will
be followed in the demonstration are as follows:



                                                                                      Page 15 of 96
                                                                                       HotelAvailability
                   Fly To Europe                                                          Services
                                                                 Europen Travel
      UDDI


AirAvailability
   Service                                         SP2                            Monitoring
                                   SP3                                              Peer



                                                                 Ontology
                  Trusted                                        Manager
                   Peer                    SP1


                                                             Marco Polo             ebXML
                   Corporate Travel

                                                                              HotelAvailability
                                                                                 Services




                              Figure 2 Peer View of Demonstration Setup
1.    Monitoring Peer joins network
2.    Trusted Peer joins network
3.    Super Peer1 (SP1) joins network
4.    Super Peer2 (SP2) joins network
5.    Super Peer3 (SP3) joins network
6.    Ontology Manager joins network
7.    Ontology Manager deploys Global Message and Functionality Ontologies
8.    Marco Polo joins network
9.    Marco Polo deploys it's Local Message Ontology and Mapping Definitions
10.   Marco Polo adds it's ebXML Registry to the system
11.   Marco Polo advertises Multi Properties Availability Search service to ebXML Registry
12.   Fly To Europe joins network
13.   Fly To Europe deploys it's Local Message Ontology and Mapping Definitions
14.   Fly To Europe adds it's UDDI Registry to the system
15.   Fly To Europe advertises Air Multi Availability service to UDDI Registry
16.   European Travel joins network
17.   European Travel creates it‟s Local Message Ontology from database schema using
      Ontology Manager Tool
18.   European Travel creates global2local and local2global mapping definitions using
      OWL2OWL Mapping Tool
19.   European Travel deploys it's Local Message Ontology and Mapping Definitions
20.   European Travel wraps a Hotel Database to provide a Hotel Search and Availability web
      service using WSCreation tool
21.   European Travel semantically annotates Hotel Search and Availability web service using
      WSAnnotation tool
22.   European Travel creates the security policy file for the Hotel Search and Availability web
      service
23.   European Travel advertises Hotel Search and Availability to a "User Specified Location"
      (USL).
24.   Corporate Travel joins network


                                                                                   Page 16 of 96
   25. Corporate Travel queries network for HotelAvailabilityServices
   26. Corporate Travel invokes the service provided by European Travel
   27. Web Service Composition
The peer view of the network is as presented in Figure 2. Each step will be detailed with the
underlying actions being taken in the system in Section 2.4.

              2.3.1 Implementation Details
The following tools and libraries are used in the demonstration:
   1- Java as the programming language.
   2- JXTA v2.3 for peer management: JXTA technology is a set of open protocols that allow
        any connected device on the network ranging from cell phones and wireless PDAs to PCs
        and servers to communicate and collaborate in a P2P manner. JXTA peers create a
        virtual network where any peer can interact with other peers and resources directly even
        when some of the peers and resources are behind firewalls and NATs or are on different
        network transports.
   3- UDDI v2.0 compliant registry: Java Web Service Developer Pack 1.3 includes a built-in
        UDDI registry and this registry is used in the demonstration.
   4- ebXML v2.5 complaint registry: freebXML 2.1 implementation has been modified to
        fulfill the requirements of the SATINE System.
   5- Protégé for ontology creation: Protégé is an open-source ontology management
        infrastructure targeted for business applications. It includes a comprehensive tool suite
        allowing easy ontology creation and management and provides a framework for building
        ontology-based applications.
   6- Jena for OWL/RDF parsing.
   7- Xerces for XML parsing.
   8- Apache Ant for compiling and running the demo.
   9- Axis for SOAP communication between peers and portal (for authentication, registration,
        uploading global ontologies and g2g mapping definitions)


2.4 DEMONSTRATION STEPS
              2.4.1 Monitoring Peer joins to the network
Monitoring Peer is used to monitor the message flow between the actors of Satine. It does not
need to connect to a Super Peer which is the main difference of Monitoring Peer from other peers.
When a peer connects to the Satine, a notification message is sent to the Monitoring Peer. By this
notification, Monitoring Peer shows the peers in its own user interface as joined peers. In addition
to this, messages between the peers are also demonstrated at the Monitoring Peer panel to ease
the following of the system execution. Within the scope of the integration phase the Monitoring
Peer is updated considering the performance issues and the trusted peer interface is added. This
section explains the details of registration of monitoring peer to system that initiates the
monitoring peer to listen to other peers and message traffic. Main flow for the registration is
illustrated at Figure 3.




                                                                                    Page 17 of 96
                 1- Start Monitoring Peer         4- Configuration is saved




                 2- Configuration Dialog            5- Continue start-up




                      3- Data Entry



               Monitoring Peer
                                 Figure 3 Monitoring Peer Registration
1- Start Monitoring Peer
Monitoring Peer is started by the ant run.MP command.
2- Configuration Dialog
If the monitoring peer is joined to Satine for the first time a configuration panel appears.
Configuration Panel has some parts that are Basic, Advanced and Rendezvous/Relays. „Basic‟ tab
includes only name of the peer. „Advanced‟ tab enables user to configure TCP settings and select
the trace level as seen from the Figure 4.




                                Figure 4 Monitoring Peer Configurator




                                                                                 Page 18 of 96
3- Data Entry
User specifies his configuration for the monitoring peer.
4- Configuration is Saved
Configuration is saved for the future entrance to the system. For the next entrance this
configuration is used if it is not deleted.
5- Continue Start-up
Figure 5 shows the monitoring tool panel that is appeared at the end of start-up. This panel shows
the peers in three categories as seen from the figure. When a peer joins to network it appears on
the panel according to its type.




                                     Figure 5 Monitoring Peer Panel

              2.4.2 Trusted Peer joins network
This section presents the details of actions in the system when a trusted peer joins to the system.
Trusted Peer is used as a provider for the shared secret keys for invocation transactions. Also it
stores the public keys of peers in the system in order to response to the requests of peers for these
public keys. The role of the Trusted Peer in the system is detailed more at section 2.4.26
“Invocation of web services”. Like all other peers, Trusted Peer also needs some configuration
before joining to Satine. Details for the process and configurations are illustrated in the Figure 6.




                                                                                     Page 19 of 96
                                        TRUSTED
                                          PEER
       1- Start Trusted Peer         2- Configuration dialog           3- Data Entry


                                      4- Save configuration


                                      5- Continue start-up


                                    6- Portal & Network Reg


                                   7- Send Notification To All
                                         Super Peers


                                      9- Save Public Keys




  8.1- Send Public key             8.2- Send Public Key              8.3- Send Public Key



        SP1                              SP2                           SP3
                                  Figure 6 Trusted Peer Registration
1- Start Trusted Peer
Trusted peer is started by „ant run.TP‟ command.
2- Configuration Dialog
After starting trusted peer, a configuration dialog appears. Dialog includes some information
about authentication, HTTP and TCP ports, portal url etc. Dialogs are illustrated in Figure 7 and
Figure 8. The „Monitoring Peer ID‟ part of the configuration panel shown on Figure 8 is used to
give the system the monitoring peer id that will monitor the trusted peer.




                                                                                  Page 20 of 96
Figure 7 Peer configuration dialog “Common settings”




   Figure 8 Peer configuration “Specific settings”


                                                       Page 21 of 96
3- Data Entry
User enters the information that is needed and presses „OK ‟ button. If the data entered by user
happens to be invalid, configuration panel reappears to enable user for editing the configuration.
This action is repeated until the configuration is correct.
4- Save Configuration
Configuration is saved for the trusted peer and used for later entrances.
5- Continue Start-up
Trusted peer continues with the joining to Satine network with the saved configuration. Figure 9
shows the „Monitoring Tool Panel‟ after Trusted Peer joins to the network.




                   Figure 9 Monitoring Peer Panel After Trusted Peer Registration
6- Registering Information about the Existence of the Trusted Peer on the SATINE Portal
Upon finished configuration, trusted peer informs the portal, about its presence, by sending a
SOAP request containing basic peer information.
7- Send Notification to All Super Peers
Trusted Peer sends notification to super peers that currently exist in the system to get the public
keys of the super peers.
8- Send Public Key
Super peers send their public key to trusted peer after they get the notification message. Public
keys of super peers are created when they first join to the Satine.
9- Save Public Keys
Trusted Peer saves the public keys that it obtains from the super peers to a hashtable by using the
super peer ids . Saved public keys are used when edge peers request the public key of their super
peers.




                                                                                   Page 22 of 96
             2.4.3 Super Peer1 (SP1) joins network
Super Peer1 is a part of the Super Peer network of SATINE Platform where the global knowledge
is shared and the semantic mediation between different tourism parties are established. Super
Peer1 has three Edge Peers that will be connecting to it within the scope of the demonstration.
These peers are Corporate Travel, Marco Polo and Ontology Manager.

                    1- Send RegisterSP                    2- Process RegisterSP
                      query message                          query message


                  4.1-Process RegisterSP
                                                          3- Prepare super-peer
                    response message
                                                              routing indices


                  4.2-Super peer routing
                     indices updated                       4- Send RegisterSP
                                                           response message



                                                           5- Prepare GO/G2G
                       6.1-Process                             MD indices
                     G2GDeployment
                    response message

                                                                 6- Send
                                                             G2GDeployment
                     6.2-GO/G2G MD
                                                            response message
                     indices updated


                        SP1                                    SP2
                                         Asynchronous


                            Figure 10 Super peer (SP1) registration flow
1- Send RegisterSP Query Message
Super-peer, requestor, prepares RegisterSP query message in order to inform network about its
presence.
2- Process RegisterSP Query Message
Upon receiving the RegisterSP message, super-peer, receiver, extracts necessary information
from the message.
3- Prepare Super-Peer Route Indices
Super-peer, receiver takes super-peer indices from its routing indices cache.
4- Send RegisterSP Response Message
Super-peer, receiver, prepares RegisterSP response message containing super-peer routing
indices.
   4.1- Process RegisterSP Response Message
   Super-peer, requestor, extracts super-peer indices from the response message
   4.2- Super Peer Routing Indices Updated
   Super-peer updates routing indices with ones, obtained from the previous step, for every
existing SATINE super-peer
5- Prepare GO/G2G MD Indices
Super-peer, receiver takes GO/G2G MD indices from its GO cache
6- Send G2G Deployment Response Message
Super-peer, receiver, prepares G2GMappingDeployment response message containing GO/G2G
MD indices
   6.1- Process G2G Deployment Response Message


                                                                                  Page 23 of 96
   Super-peer, requestor, extracts GO/G2G MD indices from the response message
   6.2- GO/G2G MD Indices Updated
Super-peer updates GO/G2G MD indices with ones, obtained from the previous step, for every
existing SATINE super-peer. Additionally, corresponding files are created on the local file
system, pointing on global ontology and global-to-global mapping definition files.
7- Create Public&Private key pair
SP1 creates public/private key pair by using RSA key generator.
8- Send Public Key to All Trusted Peers
Public key is sent to all trusted peers.

             2.4.4 Super Peer2 (SP2) joins network
Super Peer2 is a part of the Super Peer network of SATINE Platform where the global knowledge
is shared and the semantic mediation between different tourism parties are established. Super
Peer2 has one Edge Peer, namely European Travel, that will be connecting to it within the scope
of the demonstration.

                      1- Send RegisterSP                    2- Process RegisterSP
                        query message                          query message


                    4.1-Process RegisterSP
                                                            3- Prepare super-peer
                      response message
                                                                routing indices


                    4.2-Super peer routing
                       indices updated                       4- Send RegisterSP
                                                             response message



                                                             5- Prepare GO/G2G
                         6.1-Process                             MD indices
                       G2GDeployment
                      response message

                                                                   6- Send
                                                               G2GDeployment
                       6.2-GO/G2G MD
                                                              response message
                       indices updated


                          SP2                                    SP3
                                           Asynchronous


                            Figure 11 Super peer (SP2) registration flow
SP2 joins the SATINE Network flowing the same steps detailed in Section 2.4.3 “Super Peer1
(SP1) joins network”.




                                                                                    Page 24 of 96
              2.4.5 Super Peer3 (SP3) joins network
Super Peer3 is a part of the Super Peer network of SATINE Platform where the global knowledge
is shared and the semantic mediation between different tourism parties are established. Super
Peer2 has one Edge Peer, namely Fly To Europe, that will be connecting to it within the scope of
the demonstration.

                      1- Send RegisterSP                     2- Process RegisterSP
                        query message                           query message


                    4.1-Process RegisterSP
                                                            3- Prepare super-peer
                      response message
                                                                routing indices


                    4.2-Super peer routing
                       indices updated                        4- Send RegisterSP
                                                              response message



                                                              5- Prepare GO/G2G
                         6.1-Process                              MD indices
                       G2GDeployment
                      response message

                                                                   6- Send
                                                               G2GDeployment
                       6.2-GO/G2G MD
                                                              response message
                       indices updated


                          SP3                                     SP2
                                           Asynchronous

                            Figure 12 Super peer (SP3) registration flow
SP3 joins the SATINE Network flowing the same steps detailed in Section 2.4.3 “Super Peer1
(SP1) joins network”.




                                                                                     Page 25 of 96
              2.4.6 Ontology Manager joins network
The common denominator for the semantic interoperability is the global message and
functionality ontologies. The control of the global semantic knowledge will be established by
only authorized peers "Ontology Managers". The global ontologies deployed by the Ontology
Manager will be distributed among the SATINE Network by the Super Peers. Within the scope of
the demonstration there will be one Ontology Manager who will deploy the Air and Hotel global
message ontologies and global functionality ontology to the system.

                      1- Peer Configuration




                      2- Send authentication                     3- Authenticate peer
                             request


                         5- Display list of                       4- Send the list of
                          available peers                          available peers



                      6- Peers are selected



                      7- Peer is connected
                      to the selected super
                               peer

                            WSP/OM                                    Portal

                         Figure 13 Ontology Manager registration flow
1- Peer configuration
If the peer is not configured previously, then configuration dialog appears.
Among common settings, peer has to provide peer specific data, including role.
Ontology manager selects Otology Manager role.
2- Send Authentication Request
When application is started, authentication request, containing user registration data, is sent to the
portal in order to verify user‟s credentials.
3- Authenticate Peer
Portal authenticates the peer.
4- Send the List of Available Peers
As a response, the portal sends the list of available super and trusted peers
5- Display List of Available Peers
In case of positive authentication, list of available super & trusted peers is shown to the user.
Otherwise, an error message is shown.
6- Peers are Selected
User selects one super and one trusted peer.
7- Peer is Connected On the Selected Super Peer
Selected super-peer is set in the JXTA configuration file. The application continues working.
JXTA configuration mechanism reads the updated configuration file and uses the IP of the
selected super-peer to make connection between this super-peer and ordinary peer. If connection
is possible, the ordinary peers is connected on selected super-peer.




                                                                                        Page 26 of 96
Figure 14 Process configuration dialog “Specific settings”




  Figure 15 Peer authentication message




                                                        Page 27 of 96
                       Figure 16 List of available super & trusted peers




                        Figure 17 Super & trusted peer selection

             2.4.7 Ontology Manager deploys Global Message and
                   Functionality Ontologies
Ontology manager will deploy the global functionality ontology which will be used to facilitate
the discovery of the peers and the global message ontologies which will be used to mediate the
messages to interoperate tourism applications provided by different tourism parties.
2.4.7.1 Ontology Manager (OM) deploys Functionality Ontology




                                                                                Page 28 of 96
        1- Start Ontology
        Deployment Tool              7.1- GO stored on portal


    2- Press the "Add" button                                              10.1-Update GO
                                                                               indices

     3- Launch "Adding New             8-GO processed; GO
       Ontology" dialogue                 index created
                                                                          10.2-Cache GO file

        4- Provide URL of
      functionality ontology

                                         9-Cache GO file                 10.3Inform connected
     5- Select "Functionality                                                    peers
      Ontology" and "Global
     Ontology" radio buttons

                                                                            Other SP
   6- Press "Deploy Ontology"         10-Inform other super
             button                           peers


   7- If ontology URL points to
    local file then ontology is
        uploaded to portal.
   Ontology info is sent to SP.
                                    11-Inform connected peers
    13- Store ontology info in
         peer repository

                                                                          11.1/10.4-Update
      14- Update “Deployed           12-Send GO deployment               List of Available GOs
      Ontologies” list in GUI              notification




  Ontology Manager                         SP1                            Other Peers

              Figure 18 Functionality Ontology Deployment by The Ontology Manager
1- Start Ontology Deployment Tool
The ontology manager launches the ontology deployment tool of the SATINE client (see Figure
19).
2- Press the „Add‟ Button
The ontology manager presses the "Add" button in order to deploy a new ontology.
3- Launch „Adding New Ontology‟ Dialogue
The dialogue for adding new ontologies opens. The panel "Ontology deployment" is selected (see
Figure 20).
4- Provide URL of Functionality Ontology
The ontology manager provides the URL of the functionality ontology.
5- Select „Functionality Ontology‟ and „Global Ontology‟ Radio Buttons
The ontology manager selects the "Functionality Ontology" and "Global Ontology" radio buttons.
6- Press „Deploy‟ Button
The ontology manager presses the "Deploy" button.


                                                                               Page 29 of 96
7- If Ontology URL points to local file then Ontology is uploaded to Portal.
Ontology             info         is        sent          to         the        Super          Peer.
The portal acts as a central ontology repository. Therefore ontologies that are taken from the local
filesystem         are      being       automatically        uploaded       to      the      portal.
In any case the ontology information is dispatched to the SP that the OM is connected to.
8- GO information is processed by the SP
Using OntologyDeploymenHandler, GO is sent to the super-peer. Super-peer extracts necessary
information from the OntologyDeployment request message.
9- The SP is caching GO information
The SP creates/updates GO indices and stores the GO file on its local file system in order to
make, possible, G2G mapping faster.
10- Inform Other Super Peers
When local processing of GO is finished, other super-peers must be informed about GO
deployment. Also, all connected ordinary peers must be informed about new GO, in order to
make new GO for selection.
          10.1- Update GO Indices and Cache GO File (Other super-peers)
          The step 9 is repeated.
          10.2- Inform Connected Peers
          Every super-peer is responsible for informing connected ordinary peers, by        sending
GO response message
                  10.2.1- Update List of Available GOs
                  Ordinary peer updates its list of available global ontology by adding new GO in
the list.
11- Inform Connected Peers
Same step as 10.2
          11.1-Update List of Available GOs
          Same step as 10.2.1.
12- Send GO Deployment Notification
Upon completion of all steps, super-peer sends the notification about the deployment status.
13- Store Ontology Info in Peer Repository
Ontology information is stored in the local peer repository.
14- Update „Deployed Ontologies‟ List in GUI (FOCUS)
The global functionality ontology now appears in the list of "deployed ontologies" in the ontology
deployment tool (see Figure 21).




                                                                                    Page 30 of 96
Figure 19 Initial ontology deployment panel




    Figure 20 Deploy Global Ontology




                                              Page 31 of 96
Figure 21 Global Ontology Deployed




Figure 22 Global ontology deployment




                                       Page 32 of 96
                                               Sending GO
                                               on the portal




Figure 23 Global ontology deployment with sending GO on the portal




                                                               Page 33 of 96
2.4.7.2 Ontology Manager deploys Global Message Ontology

        1- Start Ontology             GO stored on portal
        Deployment Tool
                                                                           10.1-Update GO
                                                                               indices
    2- Press the "Add" button


     3- Launch "Adding New         8-GO processed; GO index               10.2-Cache GO file
       Ontology" dialogue                  created


     4- Provide URL of global
   (OTA) air message ontology                                           10.3-Inform connected
                                                                                 peers
                                        9-Cache GO file
       5- Select "Message
      Ontology" and "Global
     Ontology" radio buttons


   6- Press "Deploy Ontology"        10-Inform other super                 Other SP
             button                          peers


   7- If ontology URL points to
    local file then ontology is
        uploaded to portal.        11-Inform connected peers
   Ontology info is sent to SP.



    13- Store ontology info in                                           11.1/10.4-Update
         peer repository                                                List of Available GOs
                                    12-Send GO deployment
                                          notification
     14 – Update “Deployed
     Ontologies” list in GUI




                                           SP1                             Other Peers
  Ontology Manager
               Figure 24 Global Message Ontology Deployment by Ontology Manager
1-3 These steps are the same as steps 1-3 in section Error! Reference source not found.Error!
Reference source not found.
4- Provide URL of Global (OTA) Air Message Ontology
The ontology manager enters the URL of the global air message ontology.
5- Select „Message Ontology‟ and „Global Ontology‟ Radio Buttons
The ontology manager selects the "Message Ontology" and "Global Ontology" radio buttons
6-14 These steps are the same as steps 6-14 in section Error! Reference source not
found.Error! Reference source not found.
The same workflow applies to the deployment of the global hotel and car message ontologies.




                                                                              Page 34 of 96
              2.4.8 Marco Polo joins network
Marco Polo joins the SATINE Network folowing the same steps detailed in Section 2.4.6
“Ontology Manager joins network”. The user selects Provider role. Marco Polo will be providing
Amadeus air, hotel and car services. During the demonstration the advertisement of the Amadeus
hotel availability service will be presented. This service will be published to an ebXML registry
and it's discovery will be based on semantically querying the ebXML registry.

             1- Peer configuration




            2- Send authentication                      3- Authenticate peer
                   request



               5- Display list of                        4- Send the list of
                available peers                           available peers



             6- Peers are selected




             7- Peer is connected
             to the selected super
                      peer

                  WSP/OM                                     Portal


                                    Figure 25 Marco Polo Registration Flow

2.4.9 Marco Polo selects Global Message Ontology and deploys
      it's Local Message Ontology and Mapping Definitions
In order to be able communicate with other peers in SATINE Network, Marco Polo deploys its
message ontologies and the mapping definitions between the local and global message ontologies.

1- Launch Ontology Deployment Tool
The user launches the ontology deployment tool of the SATINE client.
2- Press the „Add‟ Button; "Adding New Ontology" dialogue is launched
The users presses the "Add" button in order to add an ontology. The "Adding New Ontology"
window appears.
3- Go to the "Choose Global Ontology" panel
The user activates the "Choose Global Ontology" panel.
4- Select ontology from the list of global ontologies
The list of available global ontologies is displayed to the user. The user selects the global
message ontology (OTA air message ontology) to be used (see Figure 27).
5- Press "OK" button
6- Notify super peer about global ontology selection
The super peer is being informed about the selection of the user.
7- Store the global ontology selection of the peer
The super peer stores the global ontology selection of the peer.



                                                                                  Page 35 of 96
1- Launch Ontology Deployment Tool


     2- Press the "Add" button
 "Adding New Ontology" dialogue is
             launchend
                                                                  7- Store the global ontology
                                                                      selection of the peer

3- Go to the "Choose Global Ontology"
                panel

                                                                      8- Confirm selection
 4- Select OTA air message ontology
   from the list of global ontologies


        5- Press "OK" button


  6- Notify super peer about global
          ontology selection


 9- Store global ontology info in peer
              repository

                                                       SP1
10- Update "Deployed Ontologies" list
              in GUI



                                            18- Press the "Add" button              25- Press the "Add" button

    11- Press the "Add" button
                                         19- Launch "Adding New Ontology"       26- Launch "Adding New Ontology"
                                                     dialogue.                              dialogue.
12- Launch "Adding New Ontology"           Go to the "Mapping Definition          Go to the "Mapping Definition
             dialogue.                          Deployment" panel                      Deployment" panel
 Go to the "Ontology Deployment"
               panel
                                         20- Provide URL of AmadeusAir-to-        27- Provide URL of OTAAir-to-
                                                OTAAir mapping def                  AmadeusAir mapping def
  13- Provide URL of Amadeus Air
         message ontology

                                            21- Analyze mapping def and            28- Analyze mapping def and
                                         display type of mapping as well as     display type of mapping as well as
14- Select "Message Ontology" and        source and destination ontologies      source and destination ontologies
  "Local Ontology" radio buttons


                                         22- Press "Deploy Mapping" button      29- Press "Deploy Mapping" button
15- Press "Deploy Ontology" button


                                          23- Store mapping info in peer          30- Store mapping info in peer
  16- Store ontology info in peer                   repository                              repository
            repository


                                         24- Update “Deployed Ontologies"       31- "Update Deployed Ontologies"
 17- "Update Deployed Ontologies"                   list in GUI                            list in GUI
            list in GUI

                                    Marco Polo
                   Figure 26 Marco Polo Local Message Ontology and Mapping Definitions
                                               Deployment




                                                                                             Page 36 of 96
8- Confirm selection
The super peer confirms the selection to the peer.
9- Store global ontology info in peer repository
The peer stores the global ontology info in the local peer repository.
10- Update "Deployed Ontologies" list in GUI
The "Deployed Ontologies" list in the GUI is updated with the global ontology just that just has
been deployed.
11- Press the "Add" button
The user presses the "Add" button in order to deploy a local message ontology.
12- Launch "Adding new Ontology" dialogue; Go to the "Ontology Deployment" panel.
When the "Adding new Ontology" window opens the user activates the "Ontology Deployment"
panel.
13- Provide URL of Amadeus Air Message Ontology
The user enters the URL of the local message ontology to be deployed (Amadeus air message
ontology).
14- Select „Message Ontology‟ and „Local Ontology‟ Radio Button
Since the ontology to be deployed is a local message ontology the corresponding radion buttons
are selected (see Figure 28).
15- Press „Deploy Ontology Button‟
The user presses the "Deploy Ontology Button" in order to start the deployment process.
16- Store Ontology Info in Peer Repository
The ontology infos are stored in the local peer repository.
17- Update Deployed Ontologies List in GUI
The "Deployed Ontologies List" of the GUI is updated with the local message ontology that just
has been deployed.
18- Press the „Add‟ button
The user presses the "Add" button in order to deploy a mapping definition.
19- Launch „Adding New Ontology‟ dialogue; Go to the "Mapping Definition Deployment"
panel
When the "Adding New Ontology" window opens the user goes to the "Mapping Definition
Deployment" panel.
20- Provide URL of AmadeusAir-to-OTAAir Mapping Definition
The user enters the URL of the mapping definition (AmadeusAir-to-OTAAir mapping definition)
(see Figure 29).
21- Analyze Mapping Definiton
The mapping definition is being analyzed in order to check whether the ontologies to which the
mapping refers to are being deployed.
22- Press „Deploy Mapping‟ Button
The users presses the "Deploy Mapping" button.
23- Store             Mapping              Info             in         Peer          Repository
The mapping information is stored in the local repository of the peer.
24- Update „Deployed Ontologies‟ List in GUI
The "Deployed Ontologies" list in the GUI is updated with the mapping definition that just has
been deployed.
25- Press the „Add‟ Button
The user presses the "Add" button in order to deploy another mapping definition.
26- Launch „Adding New Ontology‟ Dialogue; Go to the "Mapping Definition Deployment"
panel
When the "Adding New Ontology" window opens the user goes to the "Mapping Definition
Deployment" panel.
27- Provide URL of OTAAir-to-AmadeusAir Mapping Definition


                                                                                 Page 37 of 96
The user enters the URL of the mapping definition (AmadeusAir-to-OTAAir mapping definition).
28- Analyze Mapping Definition
The mapping definition is being analyzed in order to check whether the ontologies to which the
mapping refers to are being deployed.
29- Press „Deploy Mapping‟ Button
The users presses the "Deploy Mapping" button.
30- Store Mapping Info in Peer Repository
The mapping information is stored in the local repository of the peer.
31- Update „Deployed Ontologies‟ List in GUI
The "Deployed Ontologies" list in the GUI is updated with the mapping definition that just has
been deployed (see Figure 30).

The same workflow applies to the deployment of the local hotel and car message ontologies as
well as for the corresponding mapping definitions.




                              Figure 27 Select global message ontology




                                                                               Page 38 of 96
Figure 28 Deploy local Amadeus air message ontology




  Figure 29 Deploy local2global mapping definition




                                                      Page 39 of 96
                              Figure 30 Deployed ontologies and mappings

              2.4.10 Marco Polo adds it's ebXML Registry to the
                    system
This section introduces the details of adding ebXML Registry to the system. User from Marco
Polo (registry peer) provides the necessary information, add the ebXML registry to the system
and load the functionality ontology „TravelFunctionalityOntology‟ to the registry. Before starting,
user must have a running tomcat for the ebXML registry. The main phases for the process of the
scneario are illustrated at Figure 31.


              1- Provide Home Directory                     5- Prepare ebXML/Submit Object
                                                                        Request



                2- Provide Tomcat URL                     6- Load ontology to ebXML Registry



                                                                  7- Show Response
                  3- Initiate Registry




         4- Privide Functionality Ontology URL

                                                                          Marco Polo
                           Figure 31 ebXML Registry addition by Marco Polo
1- Provide Home Directory


                                                                                   Page 40 of 96
The user provides the home directory for the property file of the ebXML Registry in the “add
Service Registry Panel” shown in Figure 28.
2- Provide Tomcat URL
The user provides the Tomcat URL that will be used for ebXML Registry.
3- Initiate Registry
User initiate the registry by pressing „OK‟ button after selecting the „ebXML‟ radio button and
providing the URLs. After pressing the button, the ebXML property file is created in the home
directory of the user and the registry peer is informed with the new ebXML registry (with the
URL of the registry)
4- Provide Functionality Ontoligy URL
After initiating the registry, user provides „TravelFunctionalityOntology‟ URL as functionality
ontology which will be deployed to the ebXML registry. Figure 32 shows the panel after these
steps. After pressing the „LOAD‟ button the system continues with the next phase.




                                Figure 32 Add Service Registry Panel




                             Figure 33 Functionality ontology is chosen




                                                                                Page 41 of 96
5- Prepare ebXML/Submit Request
The ebXML SubmitObjectRequest SOAP Message has been prepared from the given OWL
ontology and the SOAP Message has been sent to the registry within a secure environment.
6- Load Ontology to ebXML Registry
The message is processed and ontology is loaded to ebXML Registry.
7- Show Response
The user is informed with the result of the Ontology Deployement process. The response is saved
to the satine peer directory and shown to the user as „response.xml‟ as demonstrated at Figure 34.
If there happens an error in the system while the process, system will show an alert message to
notify the user for the error.




                                Figure 34 Response from the Registry




                                                                                  Page 42 of 96
               2.4.11 Marco Polo advertises Multi Properties
                     Availability Search service to ebXML Registry
The activities that take place while advertising services to ebXML registry are depicted in Figure
35. In this scenario, Marco Polo will side advertises „Multi Properties Availability Search‟ service
to the ebXML registry that is added to system before. The details are illustrated with the
screenshots from the Satine GUI.


       1- Provide Web Service
            Semantic Info                     8- Process OWLS file



       2- Provide Web Service                9- Extract the semantic
            Technical Info                         information                 13.1- Update Super Peer
                                                                                       Indices


       3- Provide Web Service
            Security Info                  10- Create semantic routing
                                                      index


     4- Initiate Publishing Process                                                               SP2
                                           11- Update Peer and Super
                                                  Peer Indices
        5- Publish Travel Web
        Service to the ebXML
               Registry

                                             12- Send Distributed
                                           Message to All Super Peers

          6- Show Response

                                                                               13.2- Update Super Peer
                                                                                       Indices
     7- Forward Advertisement to
             Super Peer


               Marco Polo                                      SP1                              SP3
Figure 35 Marco Polo Multi Properties Availability Search service advertisement to ebXML
                                       Registry
1- Provide Web Service Semantic Info
User from Marco Polo provides the WSDL file (technical info) of the Web Service.
2- Provide Web Service Technical Info
User provides the OWL-S file (semantic info) of the Web Service.
3- Provide Web Service Security Policy Info
User provides the Security Policy file (security info) of the Web Service. All the inputs that is
provided by the user is demonstrated at the Figure 36.




                                                                                    Page 43 of 96
                                       Figure 36 Advertise Panel
4- Initiate Publishing Process
When user initiates the process with pressing „Advertise‟ button, the ebXML Web Service
publishment query has been prepared with the provided Web Service Info. In addition to this,
attachments of the Web Service Info files are prepared.
5- Publish Travel Web Service to the ebXML Registry
The query and the attachments are sent to the ebXML Registry within a secure environement.
6- Show Response
The user is informed with the result of the Web Service Publishment process.
7- Forward Advertisement to Super Peer
After publishing the service service descriptor file is sent to the super-peer on which peer is
connected to.(SP1)
8- Process OWL-S file
The descriptor file(OWL-S) is processed to get semantic information from the file.
9- Extract the Semantic Information
After processing, semantic information is extracted from the message and saved for processing
them and doing updates according to them.
10- Create Semantic Routing Index
By using the semantic information , SP1 create a new routing index to add it to the indices.
11- Update Peer&SuperPeer Indices
Super peer processes the file and updates its peer and super peer indices. The distributed message
that includes these updates must be send to other super peers to inform them about the changes in
indices.
12- Send Distributed Message toAll Super Peers
Super peer informs other super peers about changes in indices by sending the distributed message
to all other super peers.
13- Update Super Peer Indices
Other super peers update their indices as SP1 does when they got the message.




                                                                                  Page 44 of 96
                                      Figure 37 WS Advertisement

              2.4.12 Fly To Europe joins network
Fly To Europe joins the SATINE Network folowing the same steps detailed in Section 2.4.6
“Ontology Manager joins network”. The user selects Provider role. Fly To Europe will be
providing Galileo air services. During the demonstration the advertisement of the Galileo air
multi availability service will be presented. This service will be published to a UDDI registry and
it's discovery will be based on semantically querying the UDDI registry.

              1- Peer configuration




             2- Send authentication                    3- Authenticate peer
                    request



                5- Display list of                      4- Send the list of
                 available peers                         available peers



             6- Peers are selected




             7- Peer is connected
             to the selected super
                      peer

                   WSP/OM                                   Portal
                            Figure 38 Fly To Europe registration flow

              2.4.13 Fly To Europe deploys it's Ontologies and
                    Mapping Definitions
In order to be able communicate with other peers in SATINE Network, Fly To Europe deploys its
message ontologies and the mapping definitions between the local and global message ontologies.



                                                                                   Page 45 of 96
1- Launch Ontology Deployment Tool


     2- Press the "Add" button
 "Adding New Ontology" dialogue is
             launchend
                                                                  7- Store the global ontology
                                                                      selection of the peer

3- Go to the "Choose Global Ontology"
                panel

                                                                      8- Confirm selection
 4- Select OTA air message ontology
   from the list of global ontologies


        5- Press "OK" button


  6- Notify super peer about global
          ontology selection


 9- Store global ontology info in peer
              repository

                                                       SP 3
10- Update "Deployed Ontologies" list
              in GUI



                                            18- Press the "Add" button              25- Press the "Add" button

    11- Press the "Add" button
                                         19- Launch "Adding New Ontology"       26- Launch "Adding New Ontology"
                                                     dialogue.                              dialogue.
12- Launch "Adding New Ontology"           Go to the "Mapping Definition          Go to the "Mapping Definition
             dialogue.                          Deployment" panel                      Deployment" panel
 Go to the "Ontology Deployment"
               panel
                                          20- Provide URL of GalileoAir-to-       27- Provide URL of OTAAir-to-
                                                OTAAir mapping def                   GalileoAir mapping def
   13- Provide URL of Galileo Air
         message ontology

                                            21- Analyze mapping def and            28- Analyze mapping def and
                                         display type of mapping as well as     display type of mapping as well as
14- Select "Message Ontology" and        source and destination ontologies      source and destination ontologies
  "Local Ontology" radio buttons


                                         22- Press "Deploy Mapping" button      29- Press "Deploy Mapping" button
15- Press "Deploy Ontology" button


                                          23- Store mapping info in peer          30- Store mapping info in peer
  16- Store ontology info in peer                   repository                              repository
            repository


                                         24- Update “Deployed Ontologies"       31- "Update Deployed Ontologies"
 17- "Update Deployed Ontologies"                   list in GUI                            list in GUI
            list in GUI

                             Fly to Europe
                             Polo
                     Figure 39 Fly To Europe Local Message Ontology & Mapping Definitions
                                                  Deployment



                                                                                             Page 46 of 96
1- Launch Ontology Deployment Tool
The user launches the ontology deployment tool of the SATINE client.
2- Press the „Add‟ Button; "Adding New Ontology" dialogue is launched
The users presses the "Add" button in order to add an ontology. The "Adding New Ontology"
window appears.
3- Go to the "Choose Global Ontology" panel
The user activates the "Choose Global Ontology" panel.
4- Select ontology from the list of global ontologies
The list of available global ontologies is displayed to the user. The user selects the global
message ontology (OTA air message ontology) to be used.
5- Press "OK" button
6- Notify super peer about global ontology selection
The super peer is being informed about the selection of the user.
7- Store the global ontology selection of the peer
The super peer stores the global ontology selection of the peer.
8- Confirm selection
The super peer confirms the selection to the peer.
9- Store global ontology info in peer repository
The peer stores the global ontology info in the local peer repository.
10- Update "Deployed Ontologies" list in GUI
The "Deployed Ontologies" list in the GUI is updated with the global ontology just that just has
been deployed.
11- Press the "Add" button
The user presses the "Add" button in order to deploy a local message ontology.
12- Launch "Adding new Ontology" dialogue; Go to the "Ontology Deployment" panel.
When the "Adding new Ontology" window opens the user activates the "Ontology Deployment"
panel.
13- Provide URL of Galileo Air Message Ontology
The user enters the URL of the local message ontology to be deployed (Galileo air message
ontology).
14- Select „Message Ontology‟ and „Local Ontology‟ Radio Button
Since the ontology to be deployed is a local message ontology the corresponding radion buttons
are selected (see Figure 40).
15- Press „Deploy Ontology Button‟
The user presses the "Deploy Ontology Button" in order to start the deployment process.
16- Store Ontology Info in Peer Repository
The ontology infos are stored in the local peer repository.
17- Update Deployed Ontologies List in GUI
The "Deployed Ontologies List" of the GUI is updated with the local message ontology that just
has been deployed.
18- Press the „Add‟ button
The user presses the "Add" button in order to deploy a mapping definition.
19- Launch „Adding New Ontology‟ dialogue; Go to the "Mapping Definition Deployment"
panel
When the "Adding New Ontology" window opens the user goes to the "Mapping Definition
Deployment" panel.
20- Provide URL of GalileoAir-to-OTAAir Mapping Definition
The user enters the URL of the mapping definition (GalileoAir-to-OTAAir mapping definition)
(see Figure 41).
21- Analyze Mapping Definiton



                                                                                 Page 47 of 96
The mapping definition is being analyzed in order to check whether the ontologies to which the
mapping refers to are being deployed.
22- Press „Deploy Mapping‟ Button
The users presses the "Deploy Mapping" button.
23- Store Mapping Info in Peer Repository
The mapping information is stored in the local repository of the peer.
24- Update „Deployed Ontologies‟ List in GUI
The "Deployed Ontologies" list in the GUI is updated with the mapping definition that just has
been deployed.
25- Press the „Add‟ Button
The user presses the "Add" button in order to deploy another mapping definition.
26- Launch „Adding New Ontology‟ Dialogue; Go to the "Mapping Definition Deployment"
panel
When the "Adding New Ontology" window opens the user goes to the "Mapping Definition
Deployment" panel.
27- Provide URL of OTAAir-to-GalileoAir Mapping Definition
The user enters the URL of the mapping definition (GalileoAir-to-OTAAir mapping definition).
28- Analyze Mapping Definition
The mapping definition is being analyzed in order to check whether the ontologies to which the
mapping refers to are being deployed.
29- Press „Deploy Mapping‟ Button
The users presses the "Deploy Mapping" button.
30- Store Mapping Info in Peer Repository
The mapping information is stored in the local repository of the peer.
31- Update „Deployed Ontologies‟ List in GUI
The "Deployed Ontologies" list in the GUI is updated with the mapping definition that just has
been deployed (see Figure 42).




                                                                               Page 48 of 96
Figure 40 Deploy local Galileo air message ontology




 Figure 41 Deploy local2global mapping definition


                                                      Page 49 of 96
        Figure 42 Deployed message ontologies and mapping definitions

              2.4.14 Fly To Europe adds it's UDDI Registry to the
                    system
Fly To Europe deploys its services to a UDDI registry which is semantically enabled with the
related SATINE facilities. Thus, it adds its registry and enriches it with a functionality ontology.
2.4.14.1        Add UDDI registry



                                 1- Launch "Add Service Registry"
                                              Panel



                               2- Enter registry inquiry URL, publish
                                 URL, login, password and type of
                                              registry




                                3- Registry information is stored in
                                          peer repository



                                    Fly To Europe
               Figure 43 Fly To Europe UDDI Registry addition to the system


                                                                                    Page 50 of 96
1- Launch „Add service Registry‟ Panel
The user launches the "Add Service Registry" panel of the SATINE client GUI
2- Enter registry inquiry URL, publish URL, login, password and type of registry
The user enters the technical information that is needed to access the registry (registry inquiry
URL, publish URL, login, password and type of registry (UDDI)) (see Figure 44)
3- Registry Information is Stored in Peer Repository




                                 Figure 44 Providing registry information
2.4.14.2        Deploy functionality ontology in registry


           1- Launch Ontology Deployment Tool

                                                      7- Prepare "Save tModel" messages

              2- Select the travel functionality
           ontology in the "Deployed Ontologies"      8- Issue "Save tModel" messages at
                            panel                            the UDDI publish API


           3- Press "Deploy in Registry" button       9- Store tModel/concept mappings in
                                                                 mapping table

                    4- Initiate registry
                                                     10- Modify ontology in information in
                                                     peer repository in order to reflect that
                                                      the ontology has been deployed in
              5- Parse functionality ontology                  the UDDI registry

              6- Extract travel service classes
                                                                Fly To Europe
                     Figure 45 Functionality Ontology deployment to the Registry



                                                                                      Page 51 of 96
1- Launch Ontology deployment Tool
The user launches the ontology deployment panel of the SATINE client GUI.
2- Select the Travel Functionality Ontology in „Deployed Ontologies Panel‟
The user selects the global travel functionality ontology from the "Deployed Ontologies Panel".
3- Press „Deploy in Registry‟ Button
The users presses the "Deploy in Registry" button in order to initiate the deployment process (see
Figure 46).
4- Initiate Registry
The UDDI deployment wrapper connects to the registry.
5- Parse Functionality Ontology
The functionality ontology is being parsed by the deployment wrapper.
6- Extract Travel Service Classes
Each travel service class is extracted from the ontology.
7- Prepare „Save tModel‟ messages
A "Save tModel" message is prepared. The message contains a tModel for each service class
extracted from the ontology.
8- Issue „Save tModel‟ messages at the UDDI Publish API
The UDDI deployment wrapper issues the message at the UDDI publish API.
9- Store tModel/Concept Mappings in Mapping Table
The keys of the newly created tModels are associated with the ontology concepts in a local
mapping table.
10- Modify Ontology Information in Peer Repository
The information about the ontology is modified in order to reflect that the ontology has been
deployed in the UDDI registry.




                                 Figure 46 Deploy ontology in registry




                                                                                  Page 52 of 96
              2.4.15 Fly To Europe advertises Air Multi Availability
                    service to UDDI Registry
The activities that take place while advertising services to UDDI registry are depicted in Figure
47. In this scenario, Fly To Europe will advertise a Galileo „Air availability‟ service to the UDDI
registry that is added to system before. The details are illustrated with the screenshots from the
Satine GUI.



     1- Go to "Publish&Advertise"
                panel


       2- Provide Web Service
            Semantic Info
                                                                              16.a- Update Super Peer
                                                                                      Indices
       3- Provide Web Service
            Technical Info


       4- Provide Web Service
            Security Info                    14- Update Super Peer
                                                    Indices
                                                                                                 SP2
      5- Initiate publish process

                                             15- Send Distributed
     6- Create "businessService"           Message to All Super Peers
              structure


     7- Lookup tModels of service
        class and subclasses in
             mapping table


     8- Enrich "businessService"                                              16.b- Update Super Peer
        structure with tModels                                                        Indices


        9- Retrieve UDDI access
     information from peer repos.


      10- Prepare "save_service"
               message
                                                                                               SP1
      11- Issue "save_service"
     message at UDDI publish API


         12- Show response


     13- Forward Advertisement
           to Super Peer


        Fly to Europe

           Figure 47 Fly To Europe Air Multi Availability service advertisement to UDDI
                                            Registry
1- Go to „Publish&Advertise‟ Panel



                                                                                   Page 53 of 96
The user selects the "Publish&Advertise" panel of the SATINE client GUI (see Figure 48).
2- Provide Web Service Semantic Info
The user enters the URL of the semantic description (OWL file) of the Web service.
3- Provide Web Service Technical Info
The user enters the URL of the technical description (WSDL file) of the Web service.
4- Provide Web Service Security Info
The user enters the location of the Web service security policy file.
5- Initiate Publish Process
6- Create „businessService‟ structure
The UDDI publish wrapper creates a business service structure for the service.
7- Lookup tModels of Service Class and Subclasses
The tModels that correspond to the class of the service and to its subclasses are being retrieved
from the mapping table that has been created during ontology deployment to the registry.
8- Enrich „businessService‟ structure with tModels
The category bag of business service structure is being enriched with the tModel keys.
9- Retrieve UDDI access Information from Peer Repository
The acess information of the UDDI registry is retrieved from the peer repository.
10- Prepare „save_service‟ Message
A "save_service" message containing the created business service structure us being created.
11- Issue „save_service‟ Message at UDDI Publish API
The message is issued at the UDDI publish API. The service is being registered.
12- Show Response
13- Forward Advertisement to Super Peer
The service is being advertised to the super peer.
14- Update Super Peer Indices
The super peer updates its routine indices.
15- Send Distributed Message to All Super Peers
The super peer sends messages regarding the service advertisement to associated super peers.
16- Update Super Peer Indices
The super peers are updating their own indices.




                                                                                  Page 54 of 96
Figure 48 Publish service in registry




                                        Page 55 of 96
              2.4.16 European Travel joins network
European Travel joins the SATINE Network folowing the same steps detailed in Section 2.4.6
“Ontology Manager joins network”. The user selects Provider role. European Travel will be
providing hotel services that are created by wrapping a local database as Web services using the
Web Service Creator tool provided by SATINE platform. During the demonstration the
advertisement of the hotel availability service will be presented. This service will be published to
a user specified location and its discovery will be facilitated using Peer Repository.


              1- Peer configuration




             2- Send authentication                    3- Authenticate peer
                    request



                5- Display list of                       4- Send the list of
                 available peers                          available peers



              6- Peers are selected




              7- Peer is connected
              to the selected super
                       peer

                   WSP/OM                                    Portal

                                Figure 49 European Travel registration flow

              2.4.17 European Travel creates it’s Local Message
                    Ontology from database schema using Ontology
                    Manager Tool
European Travel creates its local message ontology using the schema of its hotel database using
the tools provided by SATINE platform. As a result of this process the local ontology of
European Travel will be extracted in OWL form XSD file defined for its hotel database.




                                                                                    Page 56 of 96
                                1- Provide XSD’s of the Services



                                2- Provide output OWL file URL



                                3- Normalize XSD



                                4- Save OWL file



                                5- Save XSD-Ontology Relation


                                  European Travel
                 Figure 50 Local Message Ontology creation from database schema
1- Provide XSD‟s of the Services
Ontology Management panel shown at Figure 51 guides the user for the creation of an local
message ontology from an XML schema. First of all, the user provides the XSD file that will be
used to derive a local message ontology is provided by the user.
2- Provide Output OWL File URL
In the same panel the output file where the created OWL ontology will be saved is browsed and
specified by the user. The panel looks like the one in Figure 52 af ter these steps.
3- Normalize XSD
After prviding the required inputs, the user presses the “Create Ontology From XSD” button.
With this action, the normalization tool creates the related OWL constructs for the elements in the
XSD.
4- Save OWL File
The created OWL definition is saved to the file specified and a confirmation dialog is displayed
for the user to provide information about the success of the process as depicted in Figure 52.
5- Save XSD-Ontology Relation
The relation of which ontology is created from which XSD is stored in the Peer Repository. This
information will be used in the translations of “OWL2XML” and “XML2OWL” when executing
the web service which exchanges XML files based on a XML schema.




                                                                                   Page 57 of 96
    Figure 51 Ontology Management Panel




Figure 52 Ontology Creation Confirmation dialog




                                                  Page 58 of 96
              2.4.18 European Travel creates global2local and
                    local2global mapping definitions using
                    OWL2OWL Mapping Tool
After creating its local message ontology the mappings between local ontology and global
ontology have to be defined. This section demonstrates the details of creating mapping definitions
by OWL2OWL mapping tool developed within the scope of SATINE project. The main phases of
the procedure is illustrated at Figure 53.


                                     1- Open OWL Mapping
                                          tool OWLMT


                                     2- Provide Source and
                                        Target Ontology


                                       3- Design Mapping



                                      4- Save Mapping File


                                        European
                                         Travel

                                 Figure 53 Owl2Owl Mapping
1- Open OWL Mapping Tool (OWLMT)
User can open the Mapping Tool from the „Ontology Management‟ panel „Map Ontology‟ button
as shown at Figure 54. After opening the tool, user opens a new mapping by pressing the „new‟
button as illustrated at Figure 55.




                                                                                  Page 59 of 96
                            Figure 54 Ontology Management Panel




                              Figure 55 OWLMT Mapping Tool

2- Provide Source and Target Ontology
After opening a new mapping, user must specify the target and source ontologies for the
mapping. Figure 56 shows the example target and source ontologies for the mapping.




                                                                         Page 60 of 96
                         Figure 56 Specifying Target and Source Ontologies
3- Design Mapping
Figure 57 shows the designed mapping between the „HotelDBMessageOntology‟ and
„OTAHotelMessageOntology‟. As demonstrated from the figure, tool shows the source and target
ontology details at the two side and the target mapping in the middle. By using the tool user can
define similarities and edit them to define the mapping.




                               Figure 57 Design of Mapping Definitions
4- Save Mapping File
After designing the mapping, user saves the mapping definition file to destination that he
specifies.

              2.4.19 European Travel deploys it's Local Message
                    Ontology and Mapping Definitions
In order to be able communicate with other peers in SATINE Network, European Travel deploys
its message ontologies and the mapping definitions between the local and global message
ontologies.



                                                                                  Page 61 of 96
1- Launch Ontology Deployment Tool


     2- Press the "Add" button
 "Adding New Ontology" dialogue is
             launchend
                                                                7- Store the global ontology
                                                                    selection of the peer

    3- Go to the "Choose Global
          Ontology" panel

                                                                    8- Confirm selection
    4- Select OTA hotel message
   ontology from the list of global
              ontologies
        5- Press "OK" button


  6- Notify super peer about global
          ontology selection


9- Store global ontology info in peer
             repository

                                                      SP 2
10- Update "Deployed Ontologies" list
              in GUI



                                           18- Press the "Add" button             25- Press the "Add" button

    11- Press the "Add" button
                                        19- Launch "Adding New Ontology"     26- Launch "Adding New Ontology"
                                                    dialogue.                            dialogue.
12- Launch "Adding New Ontology"          Go to the "Mapping Definition        Go to the "Mapping Definition
             dialogue.                         Deployment" panel                    Deployment" panel
 Go to the "Ontology Deployment"
               panel
                                        20- Provide URL of LocalHotelOnt-      27- Provide URL of OTAHotel-to-
                                            to-OTAHotel mapping def              LocalHotelOnt mapping def
  13- Provide URL of Local Hotel
        message ontology

                                           21- Analyze mapping def and           28- Analyze mapping def and
                                        display type of mapping as well as    display type of mapping as well as
14- Select "Message Ontology" and       source and destination ontologies     source and destination ontologies
  "Local Ontology" radio buttons


                                        22- Press "Deploy Mapping" button     29- Press "Deploy Mapping" button
15- Press "Deploy Ontology" button


                                         23- Store mapping info in peer         30- Store mapping info in peer
  16- Store ontology info in peer                  repository                             repository
            repository


                                        24- Update “Deployed Ontologies"      31- "Update Deployed Ontologies"
17- "Update Deployed Ontologies"                   list in GUI                           list in GUI
           list in GUI

                            European Travel
               Figure 58 European Travel Local Message Ontology and Mapping Definitions
                                             Deployment
   1- Launch Ontology Deployment Tool
   The user launches the ontology deployment tool of the SATINE client.


                                                                                           Page 62 of 96
2- Press the „Add‟ Button; "Adding New Ontology" dialogue is launched
The users presses the "Add" button in order to add an ontology. The "Adding New Ontology"
window appears.
3- Go to the "Choose Global Ontology" panel
The user activates the "Choose Global Ontology" panel.
4- Select ontology from the list of global ontologies
The list of available global ontologies is displayed to the user. The user selects the global
message ontology (OTA hotel message ontology) to be used.
5- Press "OK" button
6- Notify super peer about global ontology selection
The super peer is being informed about the selection of the user.
7- Store the global ontology selection of the peer
The super peer stores the global ontology selection of the peer.
8- Confirm selection
The super peer confirms the selection to the peer.
9- Store global ontology info in peer repository
The peer stores the global ontology info in the local peer repository.
10- Update "Deployed Ontologies" list in GUI
The "Deployed Ontologies" list in the GUI is updated with the global ontology just that just has
been deployed.
11- Press the "Add" button
The user presses the "Add" button in order to deploy a local message ontology.
12- Launch "Adding new Ontology" dialogue; Go to the "Ontology Deployment" panel.
When the "Adding new Ontology" window opens the user activates the "Ontology Deployment"
panel.
13- Provide URL of Local Hotel Message Ontology
The user enters the URL of the local message ontology to be deployed (local hotel message
ontology).
14- Select „Message Ontology‟ and „Local Ontology‟ Radio Button
Since the ontology to be deployed is a local message ontology the corresponding radion buttons
are selected.
15- Press „Deploy Ontology Button‟
The user presses the "Deploy Ontology Button" in order to start the deployment process.
16- Store Ontology Info in Peer Repository
The ontology infos are stored in the local peer repository.
17- Update Deployed Ontologies List in GUI
The "Deployed Ontologies List" of the GUI is updated with the local message ontology that just
has been deployed.
18- Press the „Add‟ button
The user presses the "Add" button in order to deploy a mapping definition.
19- Launch „Adding New Ontology‟ dialogue; Go to the "Mapping Definition
Deployment"                                                                               panel
When the "Adding New Ontology" window opens the user goes to the "Mapping Definition
Deployment" panel.
20- Provide URL of LocalHotel-to-OTAHotel Mapping Definition
The user enters the URL of the mapping definition (LocalHotel-to-OTAHotel mapping
definition).
21- Analyze Mapping Definiton
The mapping definition is being analyzed in order to check whether the ontologies to which the
mapping refers to are being deployed.
22- Press „Deploy Mapping‟ Button


                                                                                 Page 63 of 96
The users presses the "Deploy Mapping" button.
23- Store Mapping Info in Peer Repository
The mapping information is stored in the local repository of the peer.
24- Update „Deployed Ontologies‟ List in GUI
The "Deployed Ontologies" list in the GUI is updated with the mapping definition that just has
been deployed.
25- Press the „Add‟ Button
The user presses the "Add" button in order to deploy another mapping definition.
26- Launch „Adding New Ontology‟ Dialogue; Go to the "Mapping Definition
Deployment"                                                                              panel
When the "Adding New Ontology" window opens the user goes to the "Mapping Definition
Deployment" panel.
27- Provide URL of OTAHotel-to-LocalHotel Mapping Definition
The user enters the URL of the mapping definition (LocalHotel-to-OTAHotelmapping
definition).
28- Analyze Mapping Definition
The mapping definition is being analyzed in order to check whether the ontologies to which the
mapping refers to are being deployed.
29- Press „Deploy Mapping‟ Button
The users presses the "Deploy Mapping" button.
30- Store Mapping Info in Peer Repository
The mapping information is stored in the local repository of the peer.
31- Update „Deployed Ontologies‟ List in GUI
The "Deployed Ontologies" list in the GUI is updated with the mapping definition that just has
been deployed.

              2.4.20 European Travel wraps a Hotel Database to
                    provide a Hotel Search and Availability web
                    service using WSCreation tool
SATINE platform enables the small tourism entities like European Travel to create Web services
which will give them the opportunity to provide their tourism applications to a wider range of
requestors. This is facilitated by a Web service creation tool which wrapps existing databases as
Web services. European Travel will create and deploy a hotel availability service using
WSCreation tool as detailed in this section.




                                                                                  Page 64 of 96
        1- Launch WSCreator Tool

                                                            13- Press the "Add Parameter"
                                                            button
        2- Define the Web Service Name


                                                            14- Define Parameter Name
        3- Select the Metadata file



        4- Select the Connection file                       15- Select Parameter Type



        5- Select the XSD Schema file
                                                           16- Select the Kind of Function


        6- Press "Save WebService" button
                                                           17- Define the Function Body


        7- Press the "Add Module" button
                                                            18- Press the "Save Parameter"
                                                            button

        8- Define the Module Name

                                                            19- Define a value for each
                                                            parameter

        9- Press "Save Module" button

                                                           20- Press the "Execute" button


        10- Press the "Add Function" button
                                                            21- Press the "Generate Web
                                                            Service" button

        11- Define the "Function" Name

                                                            22- Define the URL of the Web
                                                            Service
        12- Select the type of the Function
        result

                                                            23- Press the "Generate WSDL”
                                                            button

       European Travel
                                              Figure 59 WSCreation
The LocalDB Hotel Availability Service is defined by three modules:
       A main module defines the endpoints of the Service, the endpoints are specified by
PL/XQuery fuction,
       An XLive module encloses all Xqueries, defined in XLive functions, to access to the
LocalDB database
       A “temporary” SQL module, implemented by a Java class, encloses the Database
modifications in “External” functions.

1- Launch WSCreator Tool
2- Define the Web Service Name



                                                                                          Page 65 of 96
3- Select The Metadata file from a directory
The Metadata file defines the database structure, it will be obtained by a tool which
automatically defines the metadata from the schema of the database
4- Select the Connection file from a directory
The Connection file defines how to access to the database, it is an XML file which defines the
name and the kind of the database, the jdbc drivers and the name of the users and their
5- Select the XSD Schema file from a directory
The XSD file defines the XSD type of the input and output messages and the XSD type of the
variable managed by the Web Service
6- Press “Save WebService” button
The Web Service is registered at the WSCreator tool level

For each module of the Web Service 
        “HotelService”, “XLiveHotelService”, “MySqlHotelService”
7- Press the “Add Module” button
8- Define the module name
9- Press “Save Module” button
Register the Module at the WSCreator tool level

For each function of each module
10- Press the “Add Function” button
11- Define the “Function” Name
12- Select the type of the function result from the list
The list of types is automatically built from the HotelMessages.xsd file by the WSCreator tool.

For each parameter of the function
13- Press the “Add Parameter” button
14- Define Parameter name
15- Select Parameter type from the list (see 12)
16- Select the kind of function
Internal, endpoint (WebService), xlive, external
17- Define the function body
         No body is given for External Functions
         A PL/Xquery is provide for internal and Web Services functions
         A FWR Xquery is provided for XLive functions
18- Press the “Save Function” button
The function is analized and registered in the WSCreation tool

For several execution tests
Currently, only available for XLive functions, the can be dynamically tested
19- Define a value for each parameter
20- Press the “Execute” button
The results are displayed in the text area of the tool
21- Press the “Generate Web Service” button
A Java class implementing each module (without external functions) is generated
22- Define the URL of the Web Service
It defines the location of the Web Service
23- Press the “Generate WSDL” button
The WSDL file is generated from the Web Service description, The WSDL file and the xsd
schema file are registered in the “Satine Network”




                                                                                   Page 66 of 96
                           Figure 60 Generate Web Service (WSCreator)

             2.4.21 European Travel semantically annotates Hotel
                   Search and Availability web service using
                   WSAnnotation tool
After creating the Web services using WSCreation tool the technical information of the service
which is WSDL file is generated and saved in the system. However, the semantic definition of the
service has to be created too to enable its semantic discovery and semantically mediation of
messages it exchanges. WSAnnotation tool will guide the European Travel in semantically
annotating the hotel availability service to create its OWL-S definition.




                                                                                 Page 67 of 96
1- Launch WSAnnotator Tool               5- Press "Get Functionality                14- Select a process type from the
                                         Ontologies" button                         list


2- Define the Web Service Name
                                         6- Select a functionality Ontology         15- Press "Get Local Ontologies"
                                         from the list                              button

3- Define the Web Service
Description
                                         7- Press the "Functionality                16- Press the "Generate Template"
                                         Services" button                           button

4- Define the Provider of the Web
Service
                                         8- Select a functionality Service          17- Press "Local Ontologies" button
                                         from the list


                                                                                     18- Select a class from the list
                                         9- Select a service from the list



                                                                                   19- Press the "Generate Template"
                                          10- Select a service property from       button
                                                        the list



        11- Select a value for service     12- Select a class from the list         20- Press the "Add Process" button
        property from the list



                                           13- Define a value for the class




        21- Press the "Add Service                                                  22- Press the "Generate
        Parameter" button                                                           Annotation" button



                                                                                                        Mandary
                                                                                                        Both
                                                                                                        Optionnal
                European Travel
                                              Figure 61 Web Service Annotation
            1- Launch WSAnnotator Tool
            2- Define the WebService Name
            Setting the name of the service that is being offred.
            3- Define the WebService Description
            Setting a brief description of the service (what the service offers, what the service requires to
            work).
            4- Define the provider of the WebService
            Setting the provider of the service
            5- Press “Get Functionality Ontologies” Button
            When Button “Get Functionality Ontologies” is pressed, all the functionality ontologies deployed
            in Satine network will be populated in the list „Functionality ontology”



                                                                                               Page 68 of 96
6- Select a functionality ontology from the list
At this step we have to choose one of the functionality ontologies deployed in the Satine network
7- Press the “Functionality Services” button
When the “Functionality Services” button is pressed, the functionality ontology choosed before,
will be parsed, then the system extract from it the functionality services and put them into the list
“Functionality Services”
8- Select a functionality service from the list
The system will populate the list of services according to the functionality service choosed from
the list
9- Select a service from the list
The system will populate the list of properties according to the service choosed from the list
10- Select a service property from the list
When a service property is choosed there is two issues to continue (new elements will be
displayed after choosing a service property)
The system will populate the list inviduals or class name according to the selected service
property

From 10 we have two issues; 11 or 12,13
          - First issue
11- Select a value for service property from the list
At this step we have to choose one of the service property values

          - Second issue
12- Select a class from the list
At this step we have to choose one of the service property classes
13- Define a value for the class
Setting a value for the class choosed before

At the Step forteen begin the setting of the service model of OWL-S description
14- Select a process type from the list
At the step we have to choose the type of the process Input or Output
15- Press “Get local Ontologies” button
When Button “Get local Ontologies” is pressed, all the local ontologies deployed in Satine
network will be populated in the list „local ontology”
16- Select a local ontology from the list
At this step we have to choose one of the local ontologies deployed in the Satine network
17- Press “Local Ontologies” button
When the “Local Ontologies” button is pressed, the local ontology choosed before, will be
parsed, then the system extract from it the classes and put them into the list “Local Ontology”
18- Select a class from the list
At the step we have to choose one of the classes listed.
19- Press the “Generate template” button
When “Generate Template Button” is pressed new button will be enabled(add service parameter,
add process and generate annotation)

At this point we can go to the step 6 or 14 or 22
- 6 for adding another parmeter
- 14 for adding another process
- 22 for generating the annotation without adding process or parameter

- If we choose to go to the step 14 we have to do the steps 15,16,17 and 18
20- Press the “Add Process” button



                                                                                     Page 69 of 96
When the “Add Process” button is pressed the new process is added to the template

-       If we choose to go to the step 6 we have to do the steps 7,8,9,10 and 11 or 7,8,9,10,11
and 12
21- Press the “Add Service Parameter” button
When the “Add Service Parameter” button is pressed the new parmater is added to the template
22- Press the “Generate Annotation” button
When the “Generate Annotation” button is pressed the OWL-S file of the annotation is generated
and stored on the hard disk




                           Figure 62 Annotate Web Service (WSAnnotator)

              2.4.22 European Travel creates the security policy file
                    for the Hotel Search and Availability web service
This part presents the details of creation of a security policy file for the „Hotel Search and
Availability‟ web service provided by European Travel. Phases are shown in the Figure 63.
Security policy file is used for the encryption and signation phases in Invocation of web service.
Policy file defines the parts that will be encrypted. For creating such a policy file, system needs a
message ontology which includes the parts of the message that „Hotel Search and Availability‟
web service exchange.




                                                                                     Page 70 of 96
                       1- Choose local             2- Choose the parts to
                      message ontology                 be encrypted



                    4- Provide Destination          3- Construct Security
                             URI                            File



                   5- Write to Destination            European
                                                       Travel

                    Figure 63 Security Policy File Creation for WS
1- Choose local message ontology
User can select the ontology for the security policy from the ontology list combo box as seen
from the Figure 64. In this scenario user selects the „HotelSearchAvailabilityOntology‟ ontology
from the list.
2- Choose the parts to be encrypted
The user selects the classes that will be encrypted from the message ontology parsed as shown in
Figure 64




                           Figure 64 Selecting the Encryption Parts
3- Construct Security File
When user presses the „Create Policy‟ button, system constructs the security file information
according to the user selections.



                                                                                 Page 71 of 96
4- Provide Destination URI
After pressing the button, „Save‟ dialog appears. User specifies the destination URI and file
name for the security policy file from the panel and presses „Save‟ button to create the policy file.
5- Write to Destination
Securtiy policy file is written to destination URI that is specified before. After file is written to
destination, a message that is shown at Figure 65 appears. The created policy file is presented in
Figure 66.




                                 Figure 65 Create Security Policy Panel




                                 Figure 66 Created Security Policy File




                                                                                     Page 72 of 96
              2.4.23 European Travel advertises Hotel Search and
                    Availability to a "User Specified Location" (USL).
In this part European Travel advertises „Hotel Search and Availability‟ service to USL. The
main phases are illustrated in the Figure 67. Below are the explanation of procedure phases when
user advertises the service.


        1- Advertise service                                                       5.a- Update
                                           3- Update Super Peer                    Super Peer
                                                 Indices                             Indices



     2- Send Advertise Message
           To Super Peer




                                           4- Send Distributed
                                        Message to All Super Peers
                                                                                                   SP1




                                                                                     5.b- Update
                                                                                     Super Peer
                                                                                       Indices
       EUROPEAN
        TRAVEL                                              SP2                                  SP3
                               Figure 67 WS Advertisement to USL
1- Advertise Service
The below figure shows the „Publish&Advertise‟ panel that user can provide the urls of the
semantic, technical and security files of the service. After selecting the „User Specified Location‟
button when user presses the „Advertise‟ button, the peer(EuropeanTravel) prepares an
advertisement message to be sent it to its super peer.




                                                                                    Page 73 of 96
                                 Figure 68 Publish&Advertise Panel
2- Send Advertise Message to Super Peer
European Travel sends the prepared message to its super peer SP2 as seen from the „Monitoring
Peer Panel‟ in Figure 69. This advertisement message includes descriptive file(OWL-S) of the
service that will be used to present for querying requests.




                        Figure 69 Monitoring Panel for Advertising Services
3- Update Super Peer Indices
Super peer SP2 gets the advertisement message, processes the file and updates, if necessary, its
peer and super peer indices (See 2.4.11 8,11). „Add Routing Index‟ corresponds to these updates
as seen from the Figure 69. After finishing the updates, SP2 sends Acknowledge message to
European Travel.
4- Send Distributed Message to All Super Peers
Super peer informs other super peers about changes in indices by sending a message that includes
udated indices.
5- Update Super Peer Indices



                                                                                 Page 74 of 96
Other super peers in the system update their indices as SP2 does.

              2.4.24 Corporate Travel joins network
Corporate Travel joins the SATINE Network folowing the same steps detailed in Section 2.4.6
“Ontology Manager joins network”. The user selects Requestor role.


             1- Peer configuration




             2- Send authentication                    3- Authenticate peer
                    request



                5- Display list of                      4- Send the list of
                 available peers                         available peers



             6- Peers are selected




             7- Peer is connected
             to the selected super
                      peer

                   WSP/OM                                   Portal


                               Figure 70 Corporate Travel registration flow




                                                                              Page 75 of 96
2.4.25 Corporate Travel queries network for HotelAvailabilityServices
    1- Create Query Message                                        6.1- Search Indices
                                 3- Extract semantic                                       6.3- Process semantic
                                 routing query from                                                query
                               Request query message

         2- Send Query                                                                      6.4- Map Semantic
                                                                 6.2- Forward semantic           Definition
                              4- Apply Semantic Routing         query to connected peers
                              query on peer & SP indices

                                                                                             6.5- Send WSInfo
 1- Join SATINE               5- Forward semantic query           6.6- Forward WSInfo
                                   on found super &                                          European
     9- List Found
       Services
                                   connected peers
                                                                    SP2                       Travel


                                                                  7.1- Query Registry

                                    8- Forward WSInfo

                                                                  7.2- Execute Query



                                                                  7.3- Map Semantic
                                                                       Definition




                                                                   7.4- Send WSInfo

        Corporate                                                                                 SP3
         Travel                                                  MARCO POLO
                                        SP1
                                     Figure 71 Querying Services in SATINE Network
As scenario suggests, user from Corporate Travel queries the Satine network for finding an
available hotel that meets with his needs. Ouery results with a list of available hotels. For our
scenario, the list will include two Hotel Service one provided by „European Travel‟ and one from
Marco Polo. The routing of the query message and system execution is demonstrated in Figure
71. As seen from the figure, SP1 the super peer of „Corporate Travel‟ finds one service directly
by Marco Polo and other by the other super peer SP2.
1- Create Query Message
Corporate Travel creates the query which will find all HotelAvailibiltyServices that is selected
from the „Lookup Service‟ panel Figure 72.




                                    Figure 72 Lookup Service Panel
2- Send Query
The query is sended to super peer of Corporate Travel(SP1) as seen from the Figure 71.
3- Extract Semantic Routing Query from Request Query Message
SP1 extracts the routing query from Request query message for specifying the route of message.
4- Apply Semantic Routing query on peer & SP indices
Using semantic routing query, Super Peer queries its peer and Super Peer indices to find a service
with the functionality „HotelAvailabilityServices‟.
5- Forward Semantic Query
The SP1 finds that there exists two service, one advertised from SP2 side and one advertise from
one of its indices Marco Polo. Thus, SP1 forwards the same query to SP2 and Marco Polo as
presented in Figure 71.
6- Route for SP2
        6.1-Search Indices
       When SP2 gets the forwarded query, it searches the indices it has. Then, it finds out that
       European Travel one of the peers connected to it, has advertised a service with the
       functionality "HotelAvailabilityServices".
       6.2-Forward Semantic Query
       SP2 forwards the query to the European Travel where the required service is located.
       6.3-Process Semantic Query
       When European Travel gets the query, it executes the query on the semantic definitions
       of the services it has advertised. Then, it determines which service is required.
       6.4-Map Semantic Definition
       Since the semantic definition of the found service is in terms of local ontology, it maps
       the OWL-S file of the service to the global ontology. This mapping is required since the
       semantic definitions of the found services are sent to the SATINE Network in terms of
       the global ontology.
       6.5-Send WSInfo
       European Travel sends the web service info of the found services to it's super peer SP2.
       6.6-Forward WSInfo
       SP2 forwards the WSInfo which is sent from European Travel to SP1.
7-Route for Marco Polo
       7.1-Query Registry
       When European Travel gets the query, The functionality ontology node that the query
       includes is extracted and the required SOAP message is prepared to be sent to the
       registry. The registry is queried only according to the functionality of the services.
       7.2-Execute Query
       The query is executed on the semantic definitions of the services retrieved from the
       registry.
       7.3-Map Semantic Definition
       Since the semantic definition of the found service is in terms of local ontology, Marco
       Polo maps the OWL-S file of the service to the global ontology. This mapping is required
       since the semantic definitions of the found services are sent to the SATINE Network in
       terms of the global ontology.
       7.4-Send WSInfo
       Marco Polo sends the web service info of the found services to it's super peer SP1.
8-Forward WSInfo
SP1 sends the web services info to the requestor Peer namely Corporate Travel which it obtains
from Marco Polo and the super peer SP2. Figure 73 shows the exact routing of messages between
peers while querying.




Storyboard of the First Prototype-v0.0                                            Page 78 of 96
                               Figure 73 Monitoring Query Messages
9-List Found Services
The web services and info is displayed as a list of web services as shown at Figure 74. User can
select one of them to pass the invocation procedure.




                                       Figure 74 Query Results



Storyboard of the First Prototype-v0.0                                           Page 79 of 96
                2.4.26 Corporate Travel invokes the service provided by European Travel
2.4.26.1          Execute service
 1- Request Secret Key      2- Generate Secret Key        TRUSTED PEER                            25- Send Public Key           24- Request Super Peer
                                                                                                                                      Public Key

                           3- Encrypt Secret Key with
                            the Requester Public key                                     28- Decrypt Secret Key by Provider      26- Verify The Message
                                                                                                     Public key
                                                                                                                                 27- Request Secret Key
                                                                                          29- Send Encrypted Secret Key
  5- Decrypt the Secret    4- Send Encrypted Secret
  Key with Own Private               Key                                                                                        30- Decrypt Secret Key by
          Key                                                                                                                       Own Private Key
                                                          13- Send Public           16- Encypt Secret Key by
                                                               Key                    Super Peer Public key
   6- Save Secret Key
                                                                                                                    17- Send
                                                                                                                   Encrypted      31- Decrypt Message
                                                                                                                   Secret Key
   7- Encrypt Invoke
Message with Secret Key
                                                                            14- Verify            15-Request                        32- Map Message
                                                                             Message              Secret Key                         Global To Local
                             10- Extract invocation
8- Sign the Message with     route from Invocation
                                                                                                  18- Decrypt Secret Key by
    Own Private Key             query message
                                                                                                       Own Private Key
                                                        12-Request Public
                                                        Key of Requester                                                              33- Normalize
                                                                                                  19- Decrypt the Message             (OWL to XML)
 9- Send Invoke Message
      to Super Peer          11- Forward Message                                                      20- Map Message
                                                                                                       Global to Global

                                                                                               21- Encrypt Message by Secret       34- Invoke Service
                                                                                                            Key

                                                                                                 22- Sign by Own Private Key
    Corporate                                                                                                                        European
     Travel                                                                                                                           Travel
                                                                                                    23- Forward Message
                            SP1                          SP2
                                                            Figure 75 Routing for Invocation Message
In this part the execution steps of a general invoke procedure for a web service is detailed. The
below figure shows the GUI and example input from user when user selects a web service from
available services list at the end of the look up services procedure. Figure 77 is as snapshot from
the Monitoring Peer that shows the routing of invocation.




                               Figure 76 Invoke Service Interface
1- Request Secret Key
For security reasons the invoke and result messages must be encrypted before sending to the
destination. For encryption, peers must have a common secret key. In our case, Corporation
Travel requests a secret key from trusted peer to encrypt its invoke message so it sends a message
that involves both requester and provider peer ids to trusted peer.
2- Generate Secret Key
Trusted Peer generates the secret key and save it for the two edge peers. The storage is located for
requester primarily and put the secret key for the provider peer id.
3- Encrypt Secret Key with Requester Public Key
Trusted peer encrypts the secret key with the Corporation Travel‟s public key which is obtained
before when peers first join to Satine.
4- Send Encrypted Secret Key
Trusted Peer sends the encypted secret key to Corporation Travel.
5- Decrypt Secret Key with Own Private Key
Corporation Travel decrypts the encrypted secret key with its own private key and obtained the
real secret key.
6- Save the Secret Key
Corporation Travel saves this secret key since it will be used later when the result message is
received.
7- Encrypt Invoke Message with Secret Key
Corporation Travel encrypts the Invoke Message which is obtained from input parameters by the
secret key. This encryption is done according to the security policy file that comes from query
result.
8- Sign the Message with Own Private Key
Corporation Travel signs the message with its private key to assure the receiver of the message
that the message is come from the source. This process is also done according to the security file.
9- Send Invoke Message to Super Peer
The end product of the message that is encrypted and signed is sended to requester‟s Super Peer
SP1.
10- Extract invocation route from Invocation query message
SP1 extract the destination peer and its super peer ids from the message to decide the route for the
invocation query.
11- Forward Message
SP1 the super peer of requester side, forwards the message to the destination peer‟s (European
Travel) Super Peer(in our case SP2).
12- Request Public Key of Requester
The super peer SP2 needs the public key of the message source to verify the message so SP2
requests the public key from Trusted Peer by sending a message that includes Corporate Travel
peer id.
13- Send Public Key
Trusted Peer sends the public key to SP2.
14- Verify Message
SP2 gets the public key and verify the message by this key to be sure that it comes from real
source.
15- Request Secret Key
SP2 needs the real message to make the global mappings so it must decrypt the message before
mapping. To decrypt the message, super peer requests the secret key between the peers from
trusted peer by sending message that includes both peer ids.
16- Encrypt Secret Key by Super Peer Public Key
Trusted Peer encrypts the secret key by SP2‟s public key.
17- Send Encrypted Secret Key
Trusted Peer sends the encrypted secret key to super peer SP2.
18- Decrypt Secret Key by Own Private Key
SP2 decrypts the secret key by its own private key and obtains the real secret key.
19- Decrypt the Message
SP2 decrypts the Invoke Message by the secret key it gets from trusted peer and obtains the
original message.
20- Map Message Global to Global
Message is mapped from one global ontology to another.(Names will be added later)
21- Encrypt Message by Secret Key
Super peer encrypts the message by secret key again according to the security policy obtained
from the message.
22- Sign by Own Private Key
Then message is signed by using the private key of super peer SP2.
23- Forward Message
Message is sent to destination peer European Travel that the web service is located.
24- Request Super Peer Public Key
European Travel needs its super peer‟s public key to verify the message comes from the super
peer.
25- Send Public Key
Trusted Peer sends the public key of the SP2 to the European Travel.
26- Verify the Message

Storyboard of the First Prototype-v0.0                                              Page 82 of 96
European Travel verify the message by the public key that it comes from its super peer SP2.
27- Request Secret Key
European Travel requests secret key for the message from Trusted Peer.
28- Encrypt the Secret Key by Provider Public Key
Trusted Peer encrypts the secret key by the public key of European Travel.
29- Send Encrypted Secret Key
The encrypted secret key is send to European Travel by Trusted Peer.
30- Decrypt Secret Key with Own private Key
The secret key sended from trusted peer is decrypred by Eurpean Travel‟s private key to get the
real secret key.
31- Decrypt Secret Key
The Invoke Message is decrypted by using the secret key.
32- Map Message Global To Local
European Travel map the message to its local ontology from global ontology.
33- Normalize(OWL to XML)
Then message is translated from OWL to XML instance.
34- Invoke Service
European Travel invokes the service by this xml.




Storyboard of the First Prototype-v0.0                                          Page 83 of 96
                            Figure 77 Monitoring Invocation Routing




Storyboard of the First Prototype-v0.0                                Page 84 of 96
2.4.26.2       Return invocation result
      54- Request Super Peer
            Public Key
                                  55- Send Public Key
                                                                      TRUSTED PEER
                                                                                                                          35- Normalize Result
                                                                                                                                Message
                                                                                                                             (XML to OWL)
        56- Verify Message


                                                                                                                        36- Map result Message
                                                                                                                            Local to Golobal

      57- Decrypt Message by
            Secret Key

                                46- Send Encrypted        45- Encrypt Secret Key by        42- Send                        37- Encrypt Result
                                    Secret key              Super Peer PublicKey           Public key                    Message by Secret Key


      58- Display the Result

                               47- Decrypt Secret Key by Own
                                        Private Key                                                                     38- Sign Message by Own
                                                                                                                               Private Key
                                                                      44-Request           41-Request
                                  48- Decrypt the Message             Secret Key          Public Key of
                                                                                            Provider

                                                                                                                           39- Forward Result
                                 49- Extract invocation route
                                                                      43- Verify                                                Message
                                  from Invocation response
                                                                       Message
                                          message


                               50- Check GO indices for target and source peer, perform                   40- Forward
                                                   G2G mapping;                                            Message
                                                          57
                                51- Encrypt Message by Secret
                                             Key
       Corporate
        Travel                   52- Sign by Own Private Key

                                                                                                                                European
                                    53- Forward Message
                                                                                           SP1                 SP2               Travel
                                                                Figure 78 Route for Service Result
This subsection introduces the details of routing for the Response Message of Invocation. Phases
are illustrated at Figure 78.
35- Normalize Result Message(XML to OWL)
The result message obtained from web service invocation is in XML format and normalized to
OWL for mappings.
36- Map Result Message Local to Global
European Travel maps the message from its local ontology to global ontology for the super peer.
37- Encrypt Message by Secret Key
European Travel encrypts the message by the secret key it obtains before(while decrypting the
Invoke Message).
38- Sign Message by Own Private Key
The message is signed by using the private key of European Travel.
39- Forward Result Message
After encrypting and signing, Europena Travel sends the message to its super peer SP2.
40- Forward Message
SP2 forward the message to SP1(the super peer of web service requester).
41- Request Public Key of Provider
SP1 requests public key of the European Travel from Trusted Peer to verify the message.
42- Send Public Key
Trusted peer sends this public key to SP1.
43- Verify the Message
SP1 verifies that the message is coming from European Travel by using the public key of
European Travel.
44- Request Secret Key
SP1 requires the secret key for decryption so it requests from Trusted Peer.
45- Encrypt Secret Key by Super Peer Public Key
Trusted Peer encrypts the secret key with the public key of super peer SP1 to send the key
securely.
46- Send Encrypted Secret Key
Trusted Peer sends the encrypted secret key to SP1.
47- Decrypt Secret Key by Own Private Key
SP1 decrypts the encrypted secret key by own private key and get the real secret key.
48- Decrypt the Message
SP1 decrypts the message by the secret key it obtains from trusted peer.
49-Extract the Invocation Route from Invocation Response Message
SP1 extract the service requester peer id to send the response message.
50- Check GO Indices/G2G Mapping
Before the result is forwarded to the target peer, the SP1 checks its GO indices, in order to verify
which global ontologies are used by the target (requestor) and source (provider) peers. In case of
different GOs, super peer performs the appropriate G2G mappings.
51- Encrypt Message by Secret Key
The message is reencrypted by the secret key to send it securely.
52- Sign by Own Private Key
SP1 signs the message by its private key.
53- Forward Message
SP1 forward the message to Corporate Travel the owner of the invocation.
54- Request Super Peer Public Key
Corporate Travel requests its super peer‟s public key to verify the message.
55- Send Public Key
Trusted Peer sends the public key to Corporate Travel.
56- Verify Message
Corporate Travel verifies that message is come from its super peer SP1.
57- Decrypt Message by Secret Key
Corporate Travel decrypts the message by secret key that it saves while encrypting the Invoke
Message.
58- Display the Result
Corporate Travel shows the obtained result to user who invokes the service. The below Figures
show the result of the invoked service. User can view the figures 79-82 by pressing „next‟ and
„previous‟ buttons. In addition to these result panels user can see the html view of the result as
illustrated at Figure 83 by pressing „View in HTML Form‟ button.




                                      Figure 79 Result of Service




                                      Figure 80 Result of Service




                                      Figure 81 Result of Service




Storyboard of the First Prototype-v0.0                                            Page 87 of 96
                                   Figure 82 Result of Service




                               Figure 83 Result of Service as Html




Storyboard of the First Prototype-v0.0                               Page 88 of 96
              2.4.27 Corporate Travel Creates Complex Service
2.4.27.1    Composition and Deployment of Complex Service
        LowestRateCarReservation
The Corporate Travel agency very often has to perform a standard business process when
arranging a trip, namely the reservation of a rental car with the lowest rate for a specific time and
location. For this matter Corporate Travel decides to design a complex service that matter that
automatically performs the necessary steps.


                     1- Start visual modeling
                                tool


                                                          8- Model data flow (in
                                                         particular assign selected
                      2- Create new process                vendor to according
                      "CheapCarReservation"               property in VehResRQ)



                       3- Create Sequence
                                                             9- Save Process



                    4- Add "VehicleAvailability"
                          activity to flow              10- Configure Process (set
                                                          constraints on service
                                                               properties)
                         5- Add data filter

                                                          11- Deploy process in
                                                         BPEL workflow engine as
                                                          complex Web service
                         6- Configure filter
                      (select VehVendorAvail
                     object with lowest price)



                              7- Add
                       "VehicleReservation"
                          activity to flow




                                              CORPORATE
                                                TRAVEL

                      Figure 84 Composition and Deployment of Complex Service
    1- Start Visual Modeling Tool
       The user intends to model a complex service and thus starts the visual modeling tool (see
       Figure 85).
    2- Create New Process „LowestRateCarReservation‟
       The user creates a new process called "LowestRateCarReservation"
    3- Create Sequence
       The user creates a sequence by adding the sequence control construct to the flow.
   4- Add „VehicleAvailability‟ activity to Flow
       In a first step for a certain location the availability of rental cars will be checked.
       Therefore the user selects the corresponding activity from the list of available activities
       and adds it as the first step of the sequence.
   5- Add Data Filter
       The "VehicleAvailability" activity is derived from a semantic Web service description
       that uses the OTA car message ontology. The output of the activity contains multiple
       instances of availability data from which one has to be selected. Therefore a filter activity
       is added to the flow.
   6- Configure Filter
       The idea of the filter activity is to provide a comfortable means for the very frequent case
       that an element from a list of elements should be selected according to a certain criteria.
       The filter is being configured in order to select the offer with the lowest price.
   7- Add „VehicleReservation‟ Activity to Flow
       In a next step a reservation for the vehicle with the lowest price shall be made. Therefore
       the "VehicleReservation" activity is added to the flow.
   8- Model Data Flow
       The user models the data flow. For example the vendor code of the vendor providing the
       lowest rate (coming as an output from the filter activity) is assigned to the vendor
       preference input of the reservation activity. The same applies to the vehicle category.
   9- Save Process
       The user saves the process.
   10- Configure Process
       The process is configured. This includes the configuration of constraints on the properties
       defined in the functionality ontology. A configuration tool will be developed in a later
       stage of the project.
   11- Deploy process in BPEL Workflow Engine
       The process is deployed to a BPEL workflow engine. A deployment tool will be
       developed in a later stage of the project.




Storyboard of the First Prototype-v0.0                                              Page 90 of 96
                                   Figure 85 Visual Modeling Tool
2.4.27.2        Execution of Complex Service CheapCarReservation

1- Set Input Parameters
The user collects the necessary input parameters for the service (location, pickup time, return
time, given name and surname).
2- Invoke Complex Service „LowestRateCarReservation‟
The complex Web service is invoked. The workflow engine starts to execute the process.
3- Invoke Activity Component „VehicleAvailability‟
First the VehicleAvailability activity component is invoked. According to the composition
approach developed in the project this is a local component that acts as a service proxy and that
takes XSD datatypes as input.
4- Create Query Message Reflecting Service Class „VehicleAvailabilty‟
The vehicle availability component constructs a SATINE query message that requests services of
the vehicle availability service class in the functionality ontology.
5- Send Query
The query is issues at the Satine query interface.
6- Lookup Services
The query is forwarded and appropriate service are being looked up in the Satine network (as
described in section 2.4.25)




Storyboard of the First Prototype-v0.0                                            Page 91 of 96
 1- Set input parameters
  (location, pickup time,
     return time etc.)


                                3- Invoke activity
2- Invoke complex service          component
 "CheapCarReservation"         "VehicleAvailability"



4- Create query message
 reflecting service class        5- Send query                        6- Lookup services
"VehicleAvailability" and                                      (This step corresponds to steps
  configured properties                                          3 to 8 from section 2.4.25)



 9- Select best matching
   service according to        8- Analyze service                  7- Forward
    service properties            descriptions                       WSInfo



   10- Invoke selected                               11- Secure service execution
   "VehicleAvailability"             (This step corresponds to steps 1 to 34 in section 2.4.26.1)
         service
                                                    12- Return invocation result
                                    (This step corresponds to step 35 to 57 in section 2.4.26.2)


   13- Apply data filter       14- Invoke activity
 (select VehVendorAvail            component
    with lowest price)        "VehicleReservation"



15- Create query message                                             17- Lookup Services
  reflecting service class                                     (This step corresponds to steps
 "VehicleReservation" and        16- Send query                  3 to 8 from section 2.4.25)
   configured properties



    20- Select service         19- Analyze service                18- Forward
                                   descriptions                     WSInfo




  21- Invoke selected                               22- Secure service execution
  "VehicleReservation"             (This step corresponds to steps 1 to 34 from section 2.4.26.1)
         service

                                                    23- Return invocation result
                                   (This step corresponds to step 35 to 57 from section 2.4.26.2)



 24- Assemble outputs of        25- Return result
     complex service
 "CheapCarReservation"


                      CORPORATE                                                      Marco
                        TRAVEL                                               SP1     Polo

                                Figure 86 Execution of Complex service


   Storyboard of the First Prototype-v0.0                                               Page 92 of 96
7- Forward WSInfo
The information regarding candidate Web services is returned and received by the
VehicleAvailability activity component.
8- Analyze Service Descriptions
The component analyzes the service descriptions.
9- Select Best Matching Service According to Service Properties
The best matching service according to the configured properties is selected.
10- Invoke Selected „VehicleAvailability‟ service (this step will be finished and
demonstrated            in       a          later        stage        of        the       project)
The selected service is invoked. Since the invocation message is an OWL message and the
component is implemented in Java (getting Java datatypes as input) the transformation framework
developed for service composition will be used to generate the OWL message.
11- Secure Service Execution (this step will be finished and demonstrated in a later stage of the
project)
The service is executed (corresponds to steps 1-34 in section 2.4.26.1).
12- Return Invocation result (this step will be finished and demonstrated in a later stage of the
project)
The invocation result is returned to the activity component (corresponds to steps 35-57 in section
2.4.26.2).
13- Apply Data Filter
The data filter activity component is invoked in order to select from the availability data the
element with the lowest price.
14- Invoke Activity Component „VehicleReservation‟
Having found and selected the cheapest offer the activity component "VehicleReservation" is
invoked by the workflow engine.
15- Create Query Message Reflecting Service Class „VehicleReservation‟
The vehicle reservation component constructs a SATINE query message that requests services of
the vehicle reservation service class in the functionality ontology.
16- Send Query
The query is issued at the Satine query interface.
17- Lookup Services
The query is forwarded and appropriate service are being looked up in the Satine network (as
described in section 2.4.25).
18- Forward WSInfo
The information regarding candidate Web services is returned and received by the
VehicleReservation activity component.
19- Analyze Service Descriptions
The component analyzes the service descriptions.
20- Select Service
A matching vehicle reservation service is selected.
21- Invoke Selected „VehicleReservation‟ Service (this step will be finished and demonstrated in
a later stage of the project)
The selected service is invoked. Since the invocation message is an OWL message and the
component is implemented in Java (getting Java datatypes as input) the transformation framework
developed for service composition will be used to generate the OWL message.
22- Secure service Execution (this step will be finished and demonstrated in a later stage of the
project)
The service is executed (corresponds to steps 1-34 in section 2.4.26.1).
23- Return Invocation result (this step will be finished and demonstrated in a later stage of the
project)
The invocation result is returned to the activity component (corresponds to steps 35-57 in section
2.4.26.2).

Storyboard of the First Prototype-v0.0                                            Page 93 of 96
24- Assemble Output of Complex Service „LowestRatecarReservation‟
The output of the complex service is assembled.
25- Return Result
The result is returned to the client of the complex service.




Storyboard of the First Prototype-v0.0                              Page 94 of 96
3 Appendix
3.1 ONTOLOGIES

              3.1.1 Functionality Ontology
http://bostanci.srdc.metu.edu.tr:8080/downloadedOntologies/TravelMessageOntology.owl

              3.1.2 OTA Air Message Ontology
http://bostanci.srdc.metu.edu.tr:8080/ontology/owl/OTAAirMessageOntology.owl

              3.1.3 Amadeus Air Message Ontology
http://bostanci.srdc.metu.edu.tr:8080/ontology/owl/AmadeusAirMessageOntology.owl

              3.1.4 Galileo Air Message Ontology
http://bostanci.srdc.metu.edu.tr:8080/ontology/owl/GalileoAirMessageOntology.owl

              3.1.5 OTA Hotel Message Ontology
http://bostanci.srdc.metu.edu.tr:8080/ontology/owl/OTAHotelMessageOntology.owl

              3.1.6 Amadeus Hotel Message Ontology
http://bostanci.srdc.metu.edu.tr:8080/ontology/owl/AmadeusHotelMessageOntology.owl

              3.1.7 LocalDB Hotel Message Ontology
http://bostanci.srdc.metu.edu.tr:8080/ontology/owl/HotelDBMessageOntology.owl

              3.1.8 OTA Car Message Ontology
http://bostanci.srdc.metu.edu.tr:8080/ontology/owl/OTACarMessageOntology_.owl


3.2 OWL-S FILES

              3.2.1 Amadeus AirMultiAvailability Service
http://bostanci.srdc.metu.edu.tr:8080/ontology/owl/AmadeusAirMultiAvailabilityServicesNew.o
wl

              3.2.2 Galileo AirMultiAvailability Service
http://bostanci.srdc.metu.edu.tr:8080/ontology/owl/owls/air/GalileoAir_MultiAvailability.owl




Storyboard of the First Prototype-v0.0                                           Page 95 of 96
             3.2.3 Amadeus HotelAvailability Service
http://bostanci.srdc.metu.edu.tr:8080/ontology/owl/owls/hotel/AmadeusPoweredHotel_Availabili
tyMultiProperties.owl

             3.2.4 LocalDB HotelAvailability Service
http://bostanci.srdc.metu.edu.tr:8080/ontology/owl/owls/hotel/HotelSearch_Availability.owl


3.3 WSDL FILES
             3.3.1 Amadeus AirMultiAvailability Service
http://bostanci.srdc.metu.edu.tr:8080/newWSDL/amadeusAir1.wsdl

             3.3.2 Galileo AirMultiAvailability Service
http://bostanci.srdc.metu.edu.tr:8080/newWSDL/GalileoAirAvailability.wsdl

             3.3.3 Amadeus HotelAvailability Service
http://bostanci.srdc.metu.edu.tr:8080/newWSDL/Amadeus_getAvailabilityMultiProperties.wsdl

             3.3.4 LocalDB HotelAvailability Service
http://bostanci.srdc.metu.edu.tr:8080/newWSDL/HotelSearch.wsdl




Storyboard of the First Prototype-v0.0                                          Page 96 of 96

								
To top