Web Services - Travel Agency project - graded 10

looneyvillestaticΛογισμικό & κατασκευή λογ/κού

15 Αυγ 2012 (πριν από 5 χρόνια και 1 μήνα)

560 εμφανίσεις


Technical University of Denmark

Department of Informatics and Mathematical Modelling




02
158



Software Development of

Web Services




Project
:
Travel Good Agency






Group 16

Student’s number

Student’s name

Student’s Signature

s0
9
1834

Kacper
Kawecki


s0
311
59

Marek Lorentowicz


s053985

Maciej Luniewski


Date
01
.
12
.
2009

i


Abstract


The report presents an outcome of a project, purpose of which was to develop a Travel Agency Web
Service. The implementation comprised of creating and aggregating five cooperative services. The
project was accomplished by using mainly the Business Process
Execution Language, in which most of
Travel Agency functionality was made.
Additionally, there were used Java Web Applications which
provided necessary functions in order to reflect the real service behaviour.



iii


Table of Contents

Abstract

................................
................................
................................
................................
..........................

i

Table of Contents

................................
................................
................................
................................
.........

iii

Table of Figures

................................
................................
................................
................................
.............

v

1

Introduction

................................
................................
................................
................................
..........

1

1.1

Workload division

................................
................................
................................
.........................

2

1.2

Introduction to Web Services

................................
................................
................................
.......

2

2

Data structures used

................................
................................
................................
.............................

4

2.1

Da
ta structures related to Bank Service

................................
................................
.......................

4

2.2

Data structures related to Flight Agency

................................
................................
......................

4

2.3

Data structures related to Hotel Agency

................................
................................
......................

5

2.4

Data structures related to Travel Good Agency

................................
................................
...........

5

3

Services

................................
................................
................................
................................
.................

6

3.1

General remarks

................................
................................
................................
............................

6

3.2

Travel Good Agency

................................
................................
................................
......................

7

3.2.1

Travel Good Helper

................................
................................
................................
...............

7

3.2.2

TravelGoodAgency.wsdl file

................................
................................
................................
..

7

3.2.3

Planning a trip

................................
................................
................................
.......................

9

3.2.4

bookItinerary() operation

................................
................................
................................
...

11

3.2.5

cancelItinerary() operation

................................
................................
................................
.

14

3.3

Cheap Bird Flight Agency (Lame Duck)

................................
................................
.......................

16

3.3.1

Cheap Bird Helper

................................
................................
................................
...............

16

3.3.2

CheapBird.wsdl file

................................
................................
................................
.............

16

3.
3.3

getFlights() operation

................................
................................
................................
..........

17

3.3.4

bookFlight() operation

................................
................................
................................
........

18

3.3.5

cancelFlight() operation

................................
................................
................................
......

20

3.4

Nice View Hotel Agency

................................
................................
................................
..............

22

3.
4.1

Nice View Helper

................................
................................
................................
.................

22

3.4.2

NiceView.wsdl file

................................
................................
................................
...............

22

3.4.3

getHotels() operation

................................
................................
................................
..........

23

3.4.4

bookHotel() operation

................................
................................
................................
........

24

iv


3.4.5

cancelHotel() operation

................................
................................
................................
......

25

4

Web service discovery

................................
................................
................................
........................

26

5

Advanced Web Service technology

................................
................................
................................
.....

27

5.1

WS
-
Addressing

................................
................................
................................
............................

27

5.2

WS
-
ReliableMessaging

................................
................................
................................
................

27

5.3

WS
-
Policy

................................
................................
................................
................................
....

27

5.4

WS
-
Security

................................
................................
................................
................................
.

27

6

Conclusion
s

................................
................................
................................
................................
.........

28

Appendix


How to start the project in Net Beans 6.5.1.

................................
................................
...........

29


v


Table of Figures

Figure 1 Travel Agency overview diagram.

................................
................................
................................
...

1

Figure 2 Class diagram for Bank related data structures.

................................
................................
.............

4

Figure 3 Class diagram for Flight Agency related data structures.

................................
...............................

5

Figure 4 Class diagram for Hotel
Agency related data structures.

................................
...............................

5

Figure 5 Class diagram for Travel Good Agency related data structures.

................................
....................

6

Figure 6 Planning an itinerary

................................
................................
................................
.......................

9

Figure 7 State diagram for planning trip operation.

................................
................................
...................

10

Figure 8 BPEL implementation for planning trip process.

................................
................................
..........

11

Figure 9 Successful itinerary booking

................................
................................
................................
.........

12

Figure 10 Bank fault when booking hotels

................................
................................
................................
.

12

Figure 11 Bank fault when booking flights
................................
................................
................................
..

13

Figure 12 State diagram for booking trip operation.

................................
................................
..................

13

Figure 13 Cancelling an itinerary

................................
................................
................................
................

14

Figure 14 BPEL implementation for trip cancellation process.

................................
................................
...

15

Figure 15 Cheap Bird Helper class
diagram.

................................
................................
...............................

16

Figure 16 getFlights operation

................................
................................
................................
....................

18

Figure 17 getFlight BPEL implementation

................................
................................
................................
...

18

Figure 18 Successful flight booking

................................
................................
................................
.............

19

Figure 19 Flight booking failure

................................
................................
................................
..................

19

Figure 20 bookFlight BPEL implementation

................................
................................
................................

20

Figure 21 Succesful flight cancelation

................................
................................
................................
.........

21

Figure 22 Flight cancelation failed

................................
................................
................................
..............

21

Figure 23 cancelFlight BPEL implementation

................................
................................
..............................

21

Figure 24 Nice View Helper class diagram.

................................
................................
................................
.

22

Figure 25 getHotels operation

................................
................................
................................
....................

23

Figure 26 Implemntation of getHotels in BPEL

................................
................................
...........................

23

Figure 27 Successful hotel booking

................................
................................
................................
.............

24

Figure 28 Hotel booking failure

................................
................................
................................
..................

25

Figure 29 bookHotel BPEL implementation

................................
................................
................................

25

Figure 30 Successful flight cancelation

................................
................................
................................
.......

26

Figure 31 cancelHotel BPEL implementation

................................
................................
..............................

26

1


1

Introduction

Written by: Marek Lorentowicz

The goal of this project was to implement a Web based

travel agency application. The users of the
agency should be able to lookup the available flights and hotels for their trip. After the travel has been
planned, the user should be able to book the chosen flights and hotel and use the credit card to pay for

them. Afterwards, the confirmation should be sent back to the user. Should any part of the transaction
go wrong, the user must also be informed and the money


get back to the account. If the traveler
changes his mind and wants to cancel the trip, it shou
ld also be a viable option.

The system is implemented using Web Services, where two
airlin
e reservation agencies


LameDuck and
CheapBird


are represented by their corresponding service. Another part of the system is a hotel
reservation agency called Nice
View. The money transfers for the transactions are handled by a banking
service called FastMoney. The agency responsible for joining all this functionality by communicating with
the responsible services is called TravelGood


a travel agency. Since the Web

Services cannot
communicate directly with one another, a set of BPEL processes is responsible for the operations in the
system. The system overview is presented in
Figure
1
.


Figure
1

Travel Agency

overview diagram.

The developed solution provides has been tested for various usage scenarios. From these tests it can be
concluded that the system satisfies the requirements specified by the
project requirements. The specific
tests and their results are presented later in the report.

When making the project we became acquainted with the great possibilities brought by the Web Service
technology, but also with the challenges that came from using

the NetBeans development system.

Cheap Bird Flight Agency
-
get flights list
-
book flight
-
cancel flight
Lame Duck Flight Agency
-
get flights list
-
book flight
-
cancel flight
Travel Good Agency
-
plan trip
-
book trip
-
cancel trip
Nice View Hotel Agency
-
get hotels list
-
book hotel
-
cancel hotel
Fast Money Bank Service
-
charge credit card
-
validate credit card
-
refund credit card
Client
Money transactions
Money transactions
Money transactions
Flights operations
Flights operations
Hotels operations
2


1.1

Workload division

Maciej Luniewski:

Cheap Bird Service

Travel Good BPEL processes

Kacper Kawecki:

Nice View Service

Travel Good BPEL processes

Marek Lorentowicz:

Lame Duck Service

Travel Good BPEL processes


The methodology if implementation of Travel Good BPEL processes was Extreme Programing. We have
all sat together and were
creating BPEL models.

1.2

Introduction to Web Services

Written by: Marek Lorentowicz

This chapter introduces some important concepts relat
ed to Web Services in order to draw a bigger
picture and visualize what this is all about. The first concept that needs to be discussed is the SOA.
Service
-
Oriented Architecture is a design paradigm consisting of design principles. The result of applying
t
hese principles is service
-
oriented solution logic. The purpose of the paradigm is creation of services. In
order to reach the goal of creating the service, multiple technologies, products, APIs and other parts are
combined together.

The principles on whic
h the SOA is based are:



Loose coupling, meaning that the parts of the architecture are self
-
standing units and each can
be reused by multiple architecture



Discoverability


it should be possible to find the parts in some registry



Abstract service descripti
on


describe the interface, not the internal workings



Encapsulation


each part is autonomous



Compositionality


the parts should be able to cooperate with each other

The SOA set of principles has been applied within OSGi services, Grid services as well a
s Web Services.
Since this project concentrates on the latter, more detailed description of Web Services follows.

The Web services provide a standardized way of interoperation between various software applications,
possibly running on different platforms.
The interoperability has been achieved thanks to the use of
XML. Simple services can interact with each other to provide complex service functions.

3


The Web Services exchange messages in XML based SOAP using standard telecommunications protocols
like HTTP.
Thanks to this, the Web Services can traverse the firewalls without requiring additional
configuration. Furthermore, the SOAP messages can be created and received by applications written in
any programming language and on any operating system.

The SOAP doe
s not provide any standardized data types or structures. For this reason XML Schemata
have been utilized. Using an XML Schema, any complex data type can be defined and shared by Web
Services. This feature further extends the usability of the services in di
fferent software environments.

The XML schemata must be exchanged between the cooperating services to make the communication
possible. Web Service Description Language copes with this task by providing an interface for a Web
Service. It describes what oper
ations the service is capable of and what data types each of the
operations can accept and return. Furthermore, the interface part of a WSDL groups operations into
port types, defines messages including XML Schemata describing complex data types. The other



implementation


part of a WSDL file defines bindings between the message and transport layers. It also
defines the ports where the service can be found.

Behind each operation of a Web Service some service logic should be implemented. It can vary from
s
imple operations, like multiplication or calculating money exchange, to more complex ones, like
contacting other services for more processing. Coupling multiple services can result in a system as
complex as ordering a custom assembled computer, where the u
ser chooses all parts, then the service
verifies whether the parts can work together, checks which shops have the parts, orders the parts in
multiple shops to one warehouse, charges the user’s credit card, and after assembly of the computer,
arranges the d
elivery to the customer. Making the same operation without using a Web Service would
require involvement of many people, thus increasing time and cost of the operation.

In order for the very loosely coupled Web Services, as described in the example above,
to successfully
cooperate, they have to be able to discover each other’s existence and operation. The Web Service
provider can publish Web Service Description Language documents in order to facilitate the discovery.
Such document lists groups of Web Servic
es using XML format. Another way to make service discovery
possible is to use UDDI (
Universal Description Discovery and Integration
). This solution is used mostly by
corporate users to provide access to the WSDL files describing their Web Services. The UDD
I is a central
solution while WSIL is distributed.

Complex Web Services are typically created by cooperation of multiple simpler services. This
cooperation can be organized in two general ways:



Composition
, where a control point decides about the operation

of the whole complex service.
It is also called Orchestration, analogous to an orchestra where the conductor decides who
should do what and when exactly.



Coordination, where each of services is more autonomous, the set of cooperating services is not
contr
olled by a single control point. This approach is also called Choreography, as an analogy to
dancers that dance separately, but somehow together their effort makes sense.

4


Both ways of cooperation of services have their strong and weak sides. The
composition is more suitable
for synchronous services, where typically an operation of a single system element does not take long
time and it is possible to control all operations centrally. The central point of control gives better way of
handling the com
plex service. On the other hand, coordination makes more sense when some of the
cooperating services take hours or days to process a request. Then, each of them should take initiative
so the whole system can perform better.

2

Data structures used

Written by:

Maciej Luniewski

In our project implementation there are used several different data structures
, which are either used for
a specific service only or are common for a few services throughout the whole Travel Good Agency
entities.

2.1

Data structures related t
o Bank Service

Based on the Schema available in a Bank Service, there are following data structures used throughout
the whole Travel Good Agency:


Figure
2

Class diagram for Bank related data structures.

2.2

Data structures related to

Flight Agency

Following data structures are initially used in Cheap Bird and Lame Duck Services. However, Travel Good
Agency uses the same
data
classes

for its variables.

Schema defined in file AirlineServiceSchema.xsd.

5



Figure
3

Class diagram for Flight Agency related data structures
.

2.3

Data structures related to Hotel Agency

Following data are initially used in Nice View Service and later is adopted by Travel Good Agency.

Schema defined in HotelServiceSchema.xsd.


Figure
4

Class diagram for
Hotel Agency

related data structures
.

2.4

Data structures related to Travel Good Agency

Below are presented classes, which are used in Travel Good Agency. In comparison to the
flightType

from Flight Agency (and
hotelType

in Hotel Agency) there was added an optional
bookingStatus

attribute, which keeps status of particular entry in the
it
e
neraryType
.

IteneraryType

is a class that may
hold two lists; one of
flightTypes
, and second of
hotelTypes
.

Schema defined in f
ile
TravelGoodSchema.xsd.

6



Figure
5

Class diagram for
Travel Good Agency

related data structures
.

3

Services

Written by: Maciej Luniewski

During the project implementation there has been implemented four different Web Services. Thre
e of
them work independently: Cheap Bird, Lame Duck and Nice View. Fourth one implements Travel
Agency’s functionality which uses services provided by distributed Flight and Hotel agencies.

In this chapter there will be at first presented general remarks t
o all projects. Afterwards, each service is
presented in details.

3.1

General remarks



Bindings
-

during the project the group has decided to use RPC/literal binding types. The reason
for this choice was that the group found this method less problematic than
Document/literal.
What is more in RPC, it is possible to pass more than one parameter in a single SOAP message.



Schemes



In the whole project there were used for different schemes. One for each
Service
type: Bank, Flight Agency, Hotel Agency and Travel Ag
ency. If one scheme was required in
another service, there was used option
import
.



Exceptions/Faults


current version of implementation has faults implemented. They are usually
implemented using
Catch All

function, which does not distinguish faults types.



Helper

services


each implemented service has its own, small Web Application service which is
used for providing basic functionality of a service; e.g. has hard coded flights and hotel lists, or
maintains sessions Ids in Travel Good Agency.



Implementatio
n


every operation in services is implemented in BPEL.

7




Empty list


in our implementation we have
encountered

problems with passing empty lists in
BPEL. Therefore, wherever list is empty we are injecting one entry with booking number set to

empty

. After
wards, in T
r
avel Good Agency, we are detecting empty lists by checking booking
numbers.

3.2

Travel Good Agency

The TravelGood part of the system is responsible for
coordinating the other Web Services in order to
provide the complex travel agency service. It is

capable of performing three operations:

-

planning a trip,

-

o
rdering the
flights and hotels for the trip,

-

cancelling the trip.

This chapter will introduce the event sequences for each of these operations both in case when the
operation is successful and in
cases when something goes wrong. After each operation

its
implementation will be presented
.

3.2.1

Travel Good Helper

Helper application
was implemented in order to provide

a
sessionI
D
. The information is kept in file so
the application always continues from the
value it finished before.

3.2.2

TravelGoodAgency.wsdl file

In the WSDL file of Travel Good there are described all operations that the service may perform. Below is
detailed description of WSDL file:

Namespace:

http://j2ee.netbeans.org/wsdl/TravelGoodAgency

Messages:



startPlanningTARequest

o

part1


xsd:boolean


required for two way operation



startPlanningTAResponse

o

part1


xsd:int


sessionID



getFlightsTARequest

o

part1


getFlightsType defined in Airli
neServiceSchema.xsd

o

part2


xsd:int
-

sessionID



getFlightsTAResponse

o

part3


getFlightsResponseType defined in AirlineServiceSchema.xsd



getHotelsTARequest

o

travelInfo


getHotelRequest defined in HotelServiceSchema.xsd

o

sessionID


xsd:int



getHotelsTARespons
e

o

hotelList


getHotelsResponseType defined in HotelServiceSchema.xsd



addFlightToIteneraryTARequest

8


o

flight


addFlightToIteneraryType defined in TravelAgencySchema.xsd

o

sessionId


xsd:int



addFlightToIteneraryTAResponse

o

part1


xsd:boolean



addHotelToIteneraryTARequest

o

hotel


addHotelToIteneraryType defined in TravelAgencySchema.xsd

o

sessionId


xsd:int



addHotelToIteneraryTAResponse

o

part1


xsd:int



getIteneraryTARequest

o

sessionID


xsd:int



getIteneraryTAResponse

o

itinerary


getIteneraryRespon
seType defined in TravelAgencySchema.xsd



bookIteneraryTARequest

o

part1


getIteneraryResponseType defined in TravelAgencySchema.xsd

o

part2


creditCardInfoType defined in Bank

schema



bookIteneraryTAResponse

o

part1


xsd:boolean



bookIteneraryTAFault

o

part1


cr
editCardFault defined in Bank schema



cancelIteneraryTARequest

o

itinerary


iteneraryType

o

creditCard
-

creditCardInfoType defined in Bank schema



cancelIteneraryTAResponse

o

result


xsd:boolean



cancelIteneraryTAFault

o

fault


creditCardFault defined in Bank
schema

Port types
, ports and partner links
:

There are define
d three

different port types, ports and partner links in order to be able to generate
different BPEL processes in separate files. There is one port type, port and partner link per each
operation:
planTrip
,
bookItenerary

and

cancel
Itenerary
.

Property and property aliases
:

In order to be able to perform asynchronous actions, there are implemented correlations. There has
been defined one property


sessionID, which was later pointed by property
aliases to the part of a
message.



9


3.2.3

Planning a trip

Written by: Kacper Kawecki

In this operation, first the client sends to the TravelGood a request to start planning. The TravelGood
replies with the session number for this transaction. Next, the client sp
ecifies what kind of flights it is
interested in by sending getFlights request. This request is asynchronously forwarded to both CheapBird
and LameDuck. The flight agencies get 5 seconds to reply with the lists of available flights satisfying the
requireme
nts. Afterwards, TravelGood sends the concatenated lists to the Client. The Client picks the
flights he is interested in and sends to the TravelGood a request to add them to itinerary. The
TravelGood confirms when the flights have been added. Then the Clie
nt requests from the TravelGood a
list of hotels satisfying requirements. The TravelGood forwards this request to NiceView, which
responds with the list of available hotels satisfying the requirements. The list is forwarded to the Client.
He then chooses t
he hotels he wants and asks TravelGood to add them to the itinerary. The TravelGood
confirms the hotels have been added. Finally, the Client requests the itinerary and receives it from the
TravelGood.

If none of flight agencies replies with a flight list w
ithin the 5 seconds from the request sent, TravelGood
replies to the Client with an empty list of flights. The situation is analogous with the NiceView hotel
agency.


Figure
6

Planning an itinerary

10


Implementation

The operation of
planning trip was implemented in BPEL. The state diagram is presented
Figure
7
.


Figure
7

State diagram for planning trip operation.

Once the client triggers a
startPlaning

function, the planning process enters a
while

loop. The service
then waits for one of five operations:
getFlights, getHotels, addFlight
ToItenerary
, addHotel
ToItenerary

or

getItenerary
. The process will not finish until user chooses
getItenerary

option. Because flights and
hotels are kept in separate list in the
itenerary
, the order of operations does not matter.

During performing operation
getFlights

or
getHotels
, the process sends req
uest asynchronously to the
agencies. In the request, there is passed additionally
sessionId
, which is used for correlation purposes.
Otherwise, BPEL process could not recognize which responses are intended for which processes. As a
result there had to be a
dded correlations to all parts of the process which deal with asynchronous
invokes or receive
s

(on Message)
actions
.

The complete BPEL process for planning trip is presented in the following

Figure
8
:

11



Figure
8

BPEL implementation for planning trip process.

3.2.4

book
Itinerary
() operation

Written by: Maciej Luniewski

In order to order the itinerary, the Client sends bookItinerary request, which inclu
des the chosen flights
and hotels, to TravelGood. Then, TravelGood contacts NiceView to book the hotels. NiceView can
validate the credit card if necessary and if everything is fine, returns true


the hotels have been booked.
Next, TravelGood contacts the

flight agencies to book the flights. The flight agency contacts the
12


FastMoney bank to charge the credit card. If transaction OK, the bank returns true. Then TravelGood
receives true from the flight agency. The bookItinerary request has been successful


T
ravelGood
returns true to the Client.


Figure
9

Successful

itinerary booking

It is also possible that the credit card validation will go wrong


there may not be enough money on the
account or some data concerning the credit card
is inaccurate. It can happen in two different scenarios.
The first one is that the fault is returned when the NiceView tries to validate the card. In such case, the
hotel will simply not be booked and the fault will be forwarded to the Client.


Figure
10

Bank fault when booking hotels

Slightly more complex situation occurs when the hotel has already been booked and then the bank
returns a fault when a flight agency tries to charge the credit card. In such case the flight booking is

unsuccessful and the TravelGood receives the bank fault forwarded by the flight agency (CheapBird or
LameDuck). In such case, the TravelGood must request hotel cancellation from NiceView. Next the bank
faultResponse is forwarded to the Client.

13



Figure
11

Bank fault when booking flights

Implementation

The booking process is implemented in BPEL and the following state machine presents its work
principle:


Figure
12

State diagram for booking trip operation.

Basically, the process starts with booking hotels and later continues with booking flights. In case
anything goes wrong, the performed operations need to be reversed. This means that all previously
successful bookings have to be cancelled.

The process star
ts with hotels,
because
in case of failure in
14


hotel booking, there is less changes needed than in case, where flights are booked before hotels.

Cancellation of hotel booking does not require Bank transactions, while flights need to be refunded.

3.2.5

c
ancel
Itine
rary
() operation

Written by: Marek Lorentowicz

When the Client wants to cancel the trip, cancelItinerary message is sent to TravelGood. Then
TravelGood sends cancelFlight message to flight agencies. They in turn send returnMoney messages t
the FastMoney ba
nk. The bank returns true for successful operations. Next the cancelHotel message is
sent by TravelGood to NiceView. Again, true is replied. When all flights and hotels have been cancelled,
TravelGood returns true to the Client.


Figure
13

Cancelling an itinerary

Should anything go wrong when cancelling the itinerary, the faults are caught and forwarded to the
Client with a message to contact the travel agency for support.

Implementation

15




Figure
14

BPEL implementation for
trip cancellation
process
.

16


3.3

Cheap Bird Flight Agency (Lame Duck)

Written by: Maciej Luniewski

Cheap Bird and Lame Duck are providing the same services, both of which were implemented in exactly
the same way.
Therefore, there will be
only Cheap Bird presented in this report.

3.3.1

Cheap Bird Helper

Cheap Bird Helper was implemented as a Web Application and the
class diagram is presented in
Figure
15
.


Figure
15

Cheap Bird Helper class diagram.

In the Helper there are implemented only crucial functions which are necessary

for emulation of Flight
Agency.

All of them are running on the same port type: CheapBirdHelperPortType.

flights



attribute used for
flightList

initialization


hard coded.

account



account number of Cheap Bird Agency

getFlights()

-

gets flight details and returns the list of flights corresponding to given criteria.

getPriceAndAccount()



returns price for
given booking number and
account
.

bookFlight()



function emulates

booking procedure in Flight Agency. In our implementation it returns
true
, except for booking number
134BBB
, when it returns
false
.

cancelFlight()

-

function emulates booking procedure in Flight Agency. In our implementation it is one
way operation.

3.3.2

CheapBird.wsdl file

In the WSDL file of Cheap Bird there are described all operations that the service may perform. Below is
detailed description of WSD
L file:

Namespace:

http://j2ee.netbeans.org/wsdl/CheapBird

Messages:



getFlightsRequest

o

flightDetails


getFlightsType

defined in
AirlineServiceSchema.xsd

o

sessionId


xsd:int
-

passed in order to make
a correlation for asynchronous operations
in Travel Good Agency.



flightListResponse

17


o

flightList


getFlightsResponseType defined in AirlineServiceSchema.xsd

o

sessionID


xsd:int



bookFlightRequest

o

bookingInfo


bookFlightType defined in AirlineServiceSchema.x
sd

o

creditCardInfo


creditCardInfoType defined in Bank schema.



bookFlightResponse

o

bookingResult


bookFlight
R
esponseType defined in AirlineServiceSchema.xsd



bookFlightfault

o

fault


bookFlightFault defined in AirlineServiceSchema.xsd



cancelFlightRequest

o

cancelInfo


cancelFlightType defined in AirlineServiceSchema.xsd

o

halfPrice


xsd:Boolean

o

creditCardInfo


creditCardInfoType defined in Bank schema.



cancelFlightResponse

o

cancelResult


cancelFlightResponseType defined in AirlineServiceSchema.xsd



cancelFli
ghtFault

o

fault


cancelFlightFaultType defined in AirlineServiceSchema.xsd



flightList

o

part1


getFlightsResponseType defined in AirlineServiceSchema.xsd

o

sessionId


xsd:int

Port types
, ports and partner links
:

There are defined four different port types, p
orts and partner links in order to be able to generate
different BPEL processes in separate files. There is one port type, port and partner link per each
operation: getFlights, bookFlight, cancelFlight and flig
h
tList.

3.3.3

getFlight
s
() operation

Written by:
Maciej Luniewski

The getFlight request
is received from the TravelGood by the CheapBird
.
It contains the characteristics
of the desired flights


the airports of origin and destination and the date of the flight. CheapBird
forwards the request to the Cheap
BirdHelper service, which returns a list of flights satisfying the
requirements. This list is then forwarded by the CheapBird to TravelGood.

18



Figure
16

getFlight
s

operation


Figure
17

getFlight BPEL implementation

Operation is asynchronous so it ends on invoke to Travel Good services. Operation doesn’t need fault
handler, because on error process just should stop.

3.3.4

bookFlight() operation

Written by: Marek Lorentowicz

CheapBird receives
bookFlight request from TravelGood. The request for booking number and price of
the flight is forwarded to the CheapBirdHelper. It then returns the requested information. Next,
CheapBird sends a message to the FastMoney bank service to charge the credit ca
rd. The bank returns
true after successful operation. When CheapBird receives this confirmation, it sends bookFlight request
to the CheapBirdHelper. It also returns true when the operation is successful. CheapBird replies true to
TravelGood meaning that th
e flight has been booked and the credit card


charged.

19



Figure
18

Successful flight booking

In case the chargeCreditCard is not successful for some reason, like insufficient funds for example, the
bank service returns a fault. Th
is faultResponse message is then forwarded by CheapBird to TravelGood,
which will then deal with it.


Figure
19

Flight booking failure

20



Figure
20

bookFlight BPEL implementation

3.3.5

cancelFlight() operation

Written by: Maciej Luniewski

When the customer decides to resign from the booked trip or some failure occurred during booking an
itinerary, the booked flight must be cancelled. Depending on the reason for the cancellation, different
amount of money is refu
nded. If the cancellation occurs because of the booking failure, full ticket price
is refunded, while in the other case only half of the price. Under these circumstances, the cancelFlight
operation must distinguish between these two situations. For this re
ason, when the CheapBird receives
the cancelFlight message, it asks CheapBirdHelper for the correct amount of money that should be
refunded. After getting this information, CheapBird contacts the FastMoney bank service to refund the
credit card. If the ban
k returns true after successful operation, CheapBird again contacts the
CheapBirdHelper requesting booking cancellation. When true is received back, it is forwarded to
TravelGood


cancel operation was successful and the money has been refunded.

21



Figure
21

Succesful flight cancelation

If for any reason the bank service replies with a faultResponse message, it is forwarded by CheapBird to
TravelGood. The cancelFlight operation did not succeed.


Figure
22

Fl
ight cancelation failed


Figure
23

cancelFlight BPEL implementation

22


3.4

Nice View Hotel Agency

Written by: Kacper Kawecki

3.4.1

Nice View Helper

Nice View Helper was implemented as a Web Application and the class diagram is presented in
Figure
15
.


Figure
24

Nice View Helper class diagram.

In the Helper there are implemented only crucial functions which are necessary for
emulation of Hotel
Agency. All of them are running on the same port type: NiceViewHelperPortType.

get
Hotels
()

-

gets flight details and returns the list of flights corresponding to given criteria.

getInfo
()



returns price for given booking number and
acco
unt
.

book
Hotel
()



function emulates booking procedure in
Hotel

Agency. In our implementation it returns
true
, except for booking number
v14a4
, when it returns
false
.

cancelHotel
()

-

function emulates booking procedure in
Hotel

Agency. In our implementatio
n it is one
way operation.

3.4.2

NiceView
.wsdl file

In the WSDL file of
Nice View

there are described all operations that the service may perform. Below is
detailed description of WSDL file:

Namespace:

http:
//j2ee.netbeans.org/wsdl/NiceView

Messages:



get
Hotels
Request

o

info


get
Hotel
Type defined in
Hotel
ServiceSchema.xsd

o

sessionId


xsd:int
-

passed in order to make a correlation for asynchronous operations
in Travel Good Agency.



listHotelRequest

o

l
ist


get
Hot
el
ResponseType defined in
HotelServiceSchema.xsd

o

sessionID


xsd:int



book
HotelR
equest

o

part1



bookHotelType defined in HotelServiceSchema.xsd

o

part2



creditCardInfoType defined in Bank schema.



book
Hotel
Response

o

part1


xsd:Boolean



book
HotelF
ault

23


o

fault


creditCardFaultType defined in Bank schema.



cancel
Hotel
Request

o

part1
-

bookHotelType defined in HotelServiceSchema.xsd



cancel
Hotel
Response

o

part1


xsd:boolean

Port types
, ports and partner links
:

There are defined four different port types, ports and partn
er links in order to be able to generate
different BPEL processes in separate files. There is one port type, port and partner link per each
operation: get
Hotels
, book
Hotel
, cancel
Hotel

and
listHotel
.

3.4.3

getHotel
s()

operation

The get
Hotel

request
is received f
rom the TravelGood by the NiveView
.
It contains the characteristics of
the desired hotels


locations and dates of stay. NiceView forwards the request to the NiceViewHelper
service, which returns a list of Hotels satisfying the requirements. This list is t
hen forwarded by the
NiceView to TravelGood.


Figure
25

getHotels

operation


Figure
26

Implemntation of getHotels in BPEL

24


Operation is asynchronous so it ends on invoke to Travel Good services. Operation
doesn’t need fault
handler, because on error process just should stop.

3.4.4

bookHotel() operation

NiceView receives bookHotel request from TravelGood. The request for prices and whether validation is
necessary is forwarded to the NiceViewHelper. It then returns

the requested information. Next,
NiceView sends a message to the FastMoney bank service to validate the credit card, if necessary. The
bank returns true if the card is validated. When NiceView receives this confirmation, it sends bookHotel
request to the
NiceViewHelper. It also returns true when the operation is successful. NiceView replies
true to TravelGood meaning that the hotel has been booked and the credit card


validated.


Figure
27

Successful

hotel

booking

In case the
validateCreditCard is not successful for some reason, like insufficient funds for example, the
bank service returns a fault. This faultResponse message is then forwarded by NiceView to TravelGood,
which will then deal with it. The hotel is not booked.

25



Fi
gure
28

Hotel

booking failure



Figure
29

bookHotel BPEL implementation


3.4.5

cancelHotel() operation

Since the hotel is not paid for at booking, it is not necessary to refund the credit card when the booking
i
s cancelled. For this reason, hotel cancellation operation is less complex compared to flight cancellation.

26



Figure
30

Successful flight cancelation



Figure
31

cancelHotel BPEL implementation

We assumed

that function return true always when cancelation is done. Even when function received
not existing booking info return true, because we consider that such booking does not exists any more.
Function return false only when there will be connection failure
between Nice View and Nice View
Helper services.

4

Web service discovery

Written by: Kacper Kawecki

Web services discovery is written in
Web Services Inspection Language
. Each service (Lame Duck, Cheap
Bird, Travel Good, Nice View) has its own description. T
here is one main file called
inspection.wsil

pointing to other files *.wsil. This file should be placed in root folder of server where services are
deployed. All links refer to localhost because all development was made on local machine.

27


5

Advanced Web Servi
ce technology

Written by: Marek Lorentowicz

This chapter describes how the advanced WS standards could be utilized in our system. It does not
however describe the workings of the standards.

5.1

WS
-
Addressing

WS
-
Addressing supports the use of asynchronous

interactions between services. For this reason, the
getFlights and getHotels could benefit from utilizing WS
-
Addressing. This way, the CheapBird and
NiceView could use the wsa:ReplyTo containing the address of TravelGood.

5.2

WS
-
ReliableMessaging

The WS
R
eli
able
M
essaging could be used in the project to make sure some messages do not get lost.
For example, when the TravelGood asks CheapBird to book a flight, the flight agency should charge the
credit card, book the flight and return true. If the confirmation
message gets lost, the TravelGood will be
convinced that the transaction did not take place. However, the credit card will be charged. Even worst
situation would occur if confirmation message for bookItinerary operation got lost. Then, possibly, many
fligh
ts would be paid for and the customer would think the flights were not booked. In order to avoid
these situations, AtLeastOnce type of WS
-
ReliableMessaging should be applied. This way the system will
not ‘forget’ about a transaction that has taken place. T
he more challenging to implement ExactlyOnce
type will not be necessary since session ID will guarantee that the TravelGood does not assume the
itinerary was booked more than once.

Furthermore, the ExactlyOnce type should be applied to any communication wi
th the bank service, to
avoid simple replay
-
attack. This way it will not be possible to eavesdrop and resend the same
refundCreditCard message twenty times and get a lot of money from the bank.

5.3

WS
-
Policy

This standard could also be utilized for flight book
ing. It should be able to guarantee that the flight is
booked only if the credit card has been charged but also that the credit card is charged only if the flight
is booked.

Another use for this standard would be to guarantee that either all flights and ho
tels in the itinerary are
booked or none of the bookings are performed. This functionality however has been implemented in the
project without using the WS
-
Policy.

The WS
-
Policy would also be useful for the cancellation of the itinerary


this way all flig
hts and hotels
would be guaranteed to be cancelled and all the money refunded accordingly.

5.4

WS
-
Security

WS
-
Security should be applied to any communication containing the information about the user’s credit
card to guarantee confidentiality. Any messages tha
t result in money operations should be signed by the
requesting services so that it is not possible to pretend to be for example NiceView and refund some
28


money to a credit card. For these two reasons, all messages sent to and from the bank should be
compli
ant with WS
-
security.

Another possibility to attack the system if the communication with the bank was not secured would be
to simply catch a fault message when a card is invalid and send true instead. This way the attacker
would be able to travel for free
.

In order to avoid unauthorized booking, all the booking requests should also be signed using WS
-
Security.

6

Conclusion
s

The goal of the project was to implement a travel agency as a complex Web Service. The agency deals
with two flight agencies, one hotel
agency and a bank.

The solution includes three Web Services representing the agencies, each having a helper service. They
are coordinated by the TravelGood agency by means of BPEL processes. The user of the service can
perform three operations


plan a tri
p, book the planned trip and cancel it. Implementation of these
operations resulted in three complicated BPEL processes.

The developed system has been tested with some sample inputs and the test results were compliant
with the system requirements. This do
es not mean that the system is bulletproof and could be
commercialized; however the proposed solution works properly and provides all necessary functionality.
Testing of the system was performed under NetBeans version 6.5.1.

When working on the project, we

have learned how service
-
oriented architecture works in practice, how
to create and connect multiple services to provide a more complex service. We have also learned how to
create and analyze messages exchanged between the services. We have trained the ab
ility to create the
Web Service descriptions and implement the services accordingly. We also became familiar with the
data structures used for communication between the parts of a complex system.

We found it challenging to work in the NetBeans environment
, and it took a lot of time and effort to
overcome the difficulties. Many errors returned by NetBeans were not understandable, so we had to
guess what could have possibly gone wrong. On the other hand, it became clear how useful the web
services can be in
distributed business applications.

To improve the project, the advanced web technologies could be applied to the communication in the
system. This would improve the security of the system and would be necessary if the system was
supposed to be commercializ
ed.


29


Appendix


How to start the project in Net Beans 6.5.1.

The order of deployment and undeployment of the projects should be as follows:

1)

Deploy all Web Applications


all Helpers.

2)

Deploy CheapBird, LameDuck and NiceView Composite
Applications.

3)

Deploy TravelGood

Composite Application.

4)

Undeploy and deploy CheapBird Composite Application.

5)

Undeploy and deploy LameDuck

Composite Application.

6)

Undeploy and deploy NiceView

Composite Application.

7)

Enjoy!