Experiences Developing A Collaborative Travel Planning .
White, P. and Grundy, J.C. Experiences Developing a Collaborative Travel Planning Application with .NET Web Services, In Proceedings of the2003 International Conference on Web Services, Las Vegas, June 23-26 2003, CSREA Press.Experiences Developing a Collaborative Travel Planning Application with.NET Web ServicesPhilip White1 and John Grundy1, 21Department of Computer Science and 2Department of Electrical and Electronic Engineering,University of Auckland, Private Bag 92019, Auckland, New Zealandjohn-g@cs.auckland.ac.nzAbstractWeb services have the potential to provide much moreseamless, dynamic and open distributed applications thanearlier technologies. We describe our experiencesdeveloping an integrated, collaborative travel planningapplication using .NET, C# and web services. Thisapplication provides a unified portal for customers andtravel agents to plan, revise and book travel itineraries,with interaction with a wide range of travel providersystems (airlines, hotels, rental cars, trains etc). Wedescribe the web services-based architecture of ourprototype solution and discuss some of the key issues ofusing a web service-based approach for this applicationdomain, outlining key areas for future research anddevelopment.1. IntroductionWeb services [18, 16, 10] provide an open, platformand language independent technology for buildingdistributed systems. Such systems can be dynamic withthe run-time discovery and integration of various serviceswithin an architecture. Many potential benefits of using aweb service-based approach to building systems exist: asingle integration technology is used to integrate allsystems; systems can be dynamically discovered andintegrated within an architecture; third-party remoteservices can be added or removed seamlessly; andmultiple complementary services can be found and usedto provide best overall system functionality, performanceand reliability.In previous work [4, 5, 12] we developed anarchitecture and several prototypes of collaborative travelplanning applications. These used distributed componentsconnected by TCP, CORBA or COM interfaces, adaptiveuser interfaces and architectures, multiple device userinterfaces, and collaborative work-supporting services andinfrastructures. While these prototype systems provideduseful travel planning applications, a number ofdisadvantages existed: different architectures forintegration and presentation components of the systemhad to be used; the architectures and integrationtechnologies used were generally difficult to design andbuild; heterogeneous integration approaches andtechnologies had to be supported; and dynamic discoveryand integration of remote travel planning providersystems was very difficult. These are all similar toproblems found in similar systems using similartechnological approaches [19, 17, 3, 8].In this paper describe a new web services-based travelplanning application prototype, built using the C#programming language and Microsoft .NET implemented web services. We firstly motivate this workwith an overview of a desired travel planning applicationand some key issues developers must face whenconstructing such a system. We then outline our webservices-based architectural solution and describeinteresting aspects of our prototype application’s designand implementation. We then summarise key experiencesgained when developing and evaluating this prototype,outline the advantages and disadvantages of our webservices-based solution, and discuss key areas for futureresearch in developing web services-based applications.2. Problem DomainA collaborative travel planning application is one thatsupports customers (intending travellers) and travel agentsin sketching, revising, specifying, booking and using atravel itinerary [4, 5]. Figure 1 (a) shows a summary ofsome of the important use cases that this system shouldsupport. This includes customer profile management;travel itinerary creation and maintenance; travel providersearches; travel booking (which may include multiplelong transaction interactions with providers to book andpay for items); and itinerary usage during travel. Thetravel planner application must communicate with avariety of travel providers: airline, hotel, rental car etc.systems as well as third-party travel agents and electronicpayment services. These may use a wide variety ofdifferent data formats, remote services and businessprocesses.
1Create/Modify ItineraryCustomerSearch for Item2ChatAnnotationTravel AgentReview Itinerary3Provide Travel ItemsBook ItineraryMake BookingsRemote ProvidersConfirm BookingsFigure 1. (a) Travel planner use cases; and (b) examples of travel planner user interfaces.Figure 1 (b) shows some of the user interfaces thatcustomers and/or travel agents may require to performthese tasks. View (1) shows a thick-client(VisualBasic.NET-implemented) travel planner that maybe used by agents and some clients to search, builditineraries and book travel.View (2) shows a web-basedinterface for itinerary management, for customer usageduring travel or thin-client interface usingtravelagencies. View (3) shows a mobile phone-hosted WAPinterface for customer itinerary modification and itineraryviewing during travel.A travel planning example application is often used bythose describing web services technologies, but ourexample application also includes collaboration facilities(collaborative editing, chat, annotation and co-ordinationfacilities) and more stringent performance and reliabilityrequirements. Unlike many exemplar travel planningapplications used by others we aim to provide customersand agents the ability to use the system even if someremote provider systems are down, and to not greatlyconstrain the performance of the system when manyremote systems must be interacted with.Some of the key issues when developing such anapplication will include: Supporting communication between the travelplanner and multiple remote travel provider systems that use different data formats, remote serviceinterfaces, transactions and business processesSupporting dynamic location and integration to thirdparty travel provider systemsProviding good travel planner performance andreliability for customers and travel agents whencommunication with several remote, highlydistributed systems is requiredIdeally providing a common, consistent infrastructurefor both remote system integration and multiple ture for the travel planning application3. ArchitectureWe have developed an architecture for ourcollaborative travel planner prototype that uses webservices as the key integration and architecturalinfrastructure. This architecture is quite different fromprevious travel planner prototypes we have developed [4,5] in terms of its use of a homogeneous communicationstechnology framework; its use of standardised dynamicdiscovery and integration support; its incorporation offlexible adaptors to support integration; and its use of datareplication and long running business transactions toprovide performance, reliability and scalability.
Advertising available web servicesusing UDDI registriesHTTP/WAP/SOAP tomultiple devicesUDDIWeb service-implementingtravel provider applicationsSOAP(fire walls)SQLDatabaseserverSOAP call(s) to remote web service(s)[Get travel data; make booking etc]Travel planner server –SOAP to external/internalsystemsFigure 2. Architecture of our web-services based travel planner.Figure 2 provides an outline of this architecture. Thetravel planner is comprised of an application server,database server (which can potentially be run on the samehost machine if desired) and various thick- and thin-clientinterface devices (PCs, laptops, PDAs, WAP phones etc).The thick-client travel planner can directly communicatewith the database via SQL or if preferred via a 3-tierarchitecture using SOAP messages to the travel plannerserver. The thin-client devices can also communicate withthis server using SOAP (if supported), or alternatively theserver can provide web servers providing HTTP, HTTPSand/or WAP services.The travel planner application provides customerprofile management, travel itinerary management,maintains a copy of available provider travel services,items (flights, cars, hotel rooms etc) and package dealinformation, and travel bookings made. Remote travelprovider systems are located using UDDI registries whichprovide a description of the remote web services theyprovide. The travel planner application servercommunicates via SOAP messages with located providerweb services via interface adaptors to obtain copies oftheir travel items, to place bookings and to confirmbookings. Remote providers can send messages back tothe travel planner asynchronously e.g. quote about toexpire, requested booking not longer available etc.One of the key features of the interaction mechanismof our travel planner with the remote travel providers isthe use of data replication and long running businesstransactions to achieve high performance, availability andscalability, a common issue with web service-basedsystems [10]. Figure 3 outlines how the travel plannerlocates, communicates with and supports long runningtransactions across remote provider systems.The provider e.g. an airline advertises its availableweb services with a UDDI registry. The travel plannerlocates these and either using an existing adaptor e.g.ebXML adaptor to communicate with the provider orbuilds or configures one to translate its web service dataand messages to/from the travel planner’s. The travelplanner then obtains a summary of flight informationprovided e.g. dates/times/destinations of flights available,caching it locally.When a flight search is made this local cache is used.An optional asynchronous check may be made with theprovider to check seat(s) are available for date requestedand a tentative commitment to hold the seat(s) made bythe provider. When a travel itinerary is booked, the travelplanner server asks the provider for a final commitmentfor the seat(s). Subsequently, the provider may howeverinform the travel planner of e.g. flight change, seat nolonger available, cost change (if not committed earlier).This approach to integration of the travel planner andremote providers supports a range of desiredcharacteristics from the previous section. The use of webservice adaptors allows separation of travel planner serverdata formats and business logic from web service SOAPmessages and different data/message formats and businessprocesses in remote travel provider systems. The cachingof summary information from providers allows customersand travel agents to make and change bookings withasynchronous communication with providers, supportinghigh response time and reliability of the travel plannerfunctions. Even if a provider is down, users can modifyitineraries and have the modifications attempted on theremote provider systems when they next becomeavailable. A “three-phase” long transaction with providers(asynchronously check desired item availability after find;commitment to item during booking; and subsequentasynchronous confirm/reject item after booking) provideshigh flexibility in interaction with provider systems, alongwith a scalable architecture and integration process.
of itinerary and travel planning functionality for webbrowsers (HTTP/HTTPS) and wireless (WAP) devices.Key features of the design of the travel plannerprototype include the use of UDDI and WSDL todescribe, register and look-up the remote web serviceinterfaces of travel providers. SOAP web servicemessages are then used to communicate with thesesystems via an adaptor architecture which separates thetravel planner business logic and data management fromthe details of the web service messages being exchanged.Adaptors may be fixed for a particular SOAP message setof business transactions of the provider, or may beconfigurable and able to translate several differentprovider message sets into the travel planner dialect.4. ImplementationWe have built a prototype travel planning applicationand some example travel provider systems to validate thearchitecture design from the previous section. We took NET and extended this by the use of C#implemented .NET web service interfaces to support thecommunication, data replication, remote data update andlong running business transactions with remote travelprovider prototypes.We implemented the remote provider systems usingC# and .NET technologies, along with MS Access andSQL Server databases. The travel planner applicationserver provides ASP.NET thin-client interfaces to a subsetTravel PlannerServerAdaptor forProvider #1Travel PlannerDatabaseUDDI RegistryProvider #1 (e.g.airline) Serverregister web serviceslook up travel provider web serviceslocate/build adatorsObtain fligjt infoGet flightsCache flight info summaries in databaseFind flightscheck availableasynchronous availability check.confirm/deny availableBook flightbook flight via web serviceconfirm/deny booking(s)notify change e.g. flight now unavailable/details changednotify servertake action e.g. another flightFigure 3. Data replication and remote update in the travel planner application.
Configuration can be manual or automated byexamining WSDL descriptions of located provider webservices. Message and data mapping are supported byvalue mappers, for simple data value mapping, and XSLTtransformations for complex message and data translation.Data synchronisation with remote travel providers isused to periodically refresh cached data and can supportpulled data and pushed data (via asynchronous SOAPmessages) data updates. A form of the BusinessTransaction Protocol (BTP) [14] is used to co-ordinatelong transactions across the travel planner and multipleproviders, as outlined in the previous section. Travelitems can be asynchronously checked and commitmentrequested during either itinerary creation or duringitinerary booking processes. Compensation transactionsvia web service calls can be run to un-commit bookeditems and notifications to change of status of bookeditems are supported.Figure 4 shows some examples of the travel plannerprototype in use. Views 1-3 are from the thick-client userinterface where a travel agent is reviewing a travel planand making a tentative hotel booking for a client. Thecustomer (or travel agent) first selects the kind of travelitem they wish to add or an existing travel item to modify(1). For example, they may choose to add a new hotelbooking (2), and they specify date, time, room details etc(3). The date and customer information can be defaultedfrom the travel itinerary under construction and theinteraction of the user with the travel plan (in view 1).View 4 shows a customer booking of an airline seatvia a thin-client, web browser-based interface. Thisinterface provides the same functions as the thick-clientinterface, but uses a standard browser-based infrastructureand HTML-encoded screen. This has the advantage of notrequiring any downloading nor installing of the travelplanner application, as required if using the thick-clientinterface. The three views in 5 are an equivalent WAPdevice implemented user interfaces for modifying anitinerary or viewing an itinerary during travel. Theseinterfaces allow a customer who is on the move, or evenhas started their trip, to access and modify their travelitinerary information.We have also added some collaborative work facilitiessimilar to those in our previous work (chat, itemannotation, collaborative editing, item locking and changenotification) can all be provided via the travel plannerserver with appropriate interface extensions [5]. All of theinterfaces – the thick-client, web browser-based andWAP-based, have a web services-based infrastructure.View 6 shows manual addition and configuration of atravel provider’s web services via our UDDI registryclient. This is used to update the travel planner UDDIregistry with new or modified remote travel planningservices e.g. to add a new hotel, airline, etc.123456Figure 4. Examples of the travel planner in use.
We found .NET web services to provide a goodinfrastructure and technology for building these facilities.The existing thick-client travel planner had its databasesynchronised with remote systems via a .NET server,which used web services to communicate with the remotesystems. We used a simple infrastructure to translateremote SOAP protocol messages to and from our server’sprotocol. We used UDDI registry entries to locateappropriate travel planning service providers and WSDLdescriptions of these services to construct adaptors tocommunicate with them.We developed a simple adaptor mechanism whichallows properties of travel itinerary items (flights, hotelrooms, rental cars, train and bus rides, customerinformation and provider information) to be accessed andupdated, with a set of design patterns used to implementsimple property-based mappings between differentformats for this data. In future XSLT-style messagetransformations would be necessary to implementcomplex mappings but we found this unnecessary for ourtravel planner prototype.We have built simple web and WAP-based userinterfaces in previous work [5] and used our infrastructureto integrate these with our web services-based travelplanner architecture. As in previous work where wegenerally hard-coded these interfaces to work on aparticular platform [12]. However, we plan to investigatethe use of our new Adaptive User Interface Technology []to build a single version of these thin-client user interfacesand with run-time adaptation to different display devicesand users [6]. This would allow us to design and specify asingle interface for e.g. booking hotel rooms, and providean adaptation mechanism to support multiple devicedisplay of the interface and multiple user/task adaptatione.g. extra facilities for travel agency staff vs. ordinarycustomer users.5. DiscussionA wide range of technologies and architectures havebeen developed for building systems such as the onedescribed here. Commonly used technologies includeCORBA and COM [15, 19], EDI and XML messaging [3,11, 16], and data and message integration tools [8, 3, 2].Recently various business process integration-basedsystems have been developed to support both thedevelopment and integration of heterogeneous systems [2,1, 9].The main disadvantages with all of these approachesinclude the difficultly in building and adapting interfaces(CORBA, EDI); the complexity of translating data andmessage sets or agreeing on standards for messages(XML, EDI and ebXML); and the need to supportheterogeneous integration technologies and wide rangesof different business processes (BPM).We have carried out a combination of usability,performance and flexibility evaluations of our travelplanner prototype. Test users have indicated that thecross-organisational business process embodied by thetravel planner are appropriate to the travel planning tasksthey wish to undertake. Performance evaluations haveindicated that the travel planner prototype providesconsistently high performance and availability even undervery high loading (both travel planner users and remoteapplication users). We have integrated several differenttravel provider systems with the travel planner, each usingquite different travel item data formats, SOAP messageformats and embodying different business processes(some immediate commit to requested items; somedeferred commitment; some immediate payment andothers invoiced payment).The main limitations to date with our travel planningapplication prototype have related to issues ofgeneralising the adaptors so that programming is seldomrequired to integrate new systems, suitably identifyingadvertised travel provider web services, and plementations in the travel planner itself. Generalisingand providing automatically generated web serviceadaptors is important to support flexible integrationinfrastructure and more dynamic remote systeminteroperation. This will require improved advertising offunctional and non-functional characteristics of webservices, and improved cross-web service businesstransaction description than currently provided by WSDL,UDDI and BPEL4WS solutions [13].We are currently looking at two further areas ofresearch and development relating to the travel planner –improved web service design, characterisation anddynamic discovery and integration, and using webservices to build adaptive, multi-device user interface andcollaborative work support infrastructure. We iques to the problem of designing, identifying andadapting to web services, and using a messagetransformation server architecture to address the problemof supporting adaptive user interfaces and collaborativework support with web services infrastructure. We arealso working on developing a generic integration systemusing the data replication/data update/long runningtransaction model used in this work [7]. This will be usedto provide not only a web services-based integrationinfrastructure but also to support seamless integrationwith non-web services legacy systems in the future.6. SummaryWe have designed a web service-based architecturefor a collaborative travel planning application. This uses
web services as an integration infrastructure with remotetravel provider systems and is being extended to use webservices to provide multi-device interface andcollaborative work infrastructure. A key feature of ourprototype is its use of data replication, caching, remoteupdate and long running business transactions withasynchronous messaging to support a high performance,reliable and scalable solution. We have developed aprototype travel planner with C# and .NET-based webservices to realise this Alvarez, M., Pan, A., Raposo, J., Cacheda, F., Vina, A.FINDER: a mediator system for structured and semistructured data integration, InProceedings 13thInternational Workshop on Database and Expert SystemsApplications, IEEE. CS Press, 2002, pp.847-851.eXcelon Corp, eXcelon B2B Integration Server WhitePaper, www.exceloncorp.com.Goulde, M.A. Microsoft's BizTalk Framework addsmessaging to XML. E-Business Strategies & Solutions,Sept. 1999, 10-14.Grundy, J.C., and Hosking, J.G. Developing AdaptableUser Interfaces for Component-based Systems, Interactingwith Computers, Elsevier, May 2002.Grundy, J.C. and Jin, W. Experiences developing a thinclient, multi-device travel planning application, InProceedings of the 2002 New Zealand Conference onHuman-Computer Interaction, , July 12-13, Hamilton, NewZealand.Grundy, J.C. and Zou, W. An architecture for buildingmulti-device thin-client web user interfaces, In Proceedingsof the 14th Conference on Advanced Information SystemsEngineering, Toronto, Canada, May 29-31 2002, LectureNotes in Computer Science.Grundy, J.C., Bai, J., Blackham, J., Hosking, J.G. andAmor, R. An architecture for efficient, flexible enterprisesystem integration, In Proceedings of the 2003International Conference on Internet Computing, LasVagas, June 23-26 2003, CSREA Press.Gupta, A. Harinarayan, V. Rajaraman, A. Virtual databasetechnology, Proceedings of the 1998 14th InternationalConference on Data Engineering, 23-27 Feb 1998, 297 –301.13.14.15.16.17.18.19.Hanson, J.E., Nandi, P., Kumaran, S. Conversation supportfor business process integration. In Proceedings SixthInternational Enterprise Distributed Object ComputingConference, IEEE. CS Press, 2002, pp.65-74.Litoiu, M. Migrating to Web services - latency andscalability. In Proceedings Fourth International Workshopon Web Site Evolution, IEEE CS Press, 2002, pp.13-20.McGarr, M.S., Transforming business processes with EDI.Electronic Commerce World, vol.12, no.4, May 2002,pp.22-29.Petrovski, A. and Grundy, J. Web-enabling an integratedhealth informatics system, In Proceedings of the 7thConference on Object-oriented Information Systems,Calgary, Canada, August 27-30 2001, Springer LNCS, pp.477-486.Piccinelli, G., Emmerich, W., Zirpins, C., Schutt, K. Webservice interfaces for inter-organisational businessprocesses an infrastructure for automated reconciliation. InProceedings Sixth International Enterprise DistributedObject Computing Conference, IEEE CS Press, 2002,pp.285-292.Oasis Group, OASIS Business Transaction Protocol,Committee Specification 1.0, June 2002, www.oasisopen.org.Sessions, R. COM and DCOM: Microsoft's vision fordistributed objects, John Wiley & Sons 1998.Sonh, E.J., Lee, H.S., Kwon, T.G. Design andimplementation of a message service handler for ebXML.In Proceedings of the Fourth International Conference onEnterprise Information Systems, vol 2, ICEIS Press,pp.1064-1069.Swatman, P.M.C., Swatman, P.A., Fowler, D.C. A modelof EDI integration and strategic business reengineering.Journal of Strategic Information Systems, vol.3, no.1, 1994,pp.41-60.Wiedemann, M. Web Services and collaborativecommerce. Information Management & Consulting, vol.17,no.3, Aug. 2002, pp.57-60.Wu, E. A CORBA-based architecture for integratingdistributed and heterogeneous databases, In ProceedingsFifth IEEE International Conference on Engineering ofComplex Computer Systems, IEEE CS Press, 1999, pp.143152.
interface for itinerary management, for customer usage during travel or thin-client interface using travel agencies. View (3) shows a mobile phone-hosted WAP interface for customer itinerary modification and itinerary viewing during travel. A travel planning example application is often used by those describing web services technologies, but our
1. Corporate Travel Booked through a UW contracted Travel agency listed on the Travel Services Website. 2. Athletics Travel Booked through Athletics travel desk. 3. State of WA Travel Booked through the following as listed on the Travel Services Website. UW contracted Travel agency State contracted Travel agency EasyBiz
a company travel configuration is created for each country the legal entity is located in. Features Available in Travel System Admin To access Travel System Admin, on the menu, click Administration Travel (on the sub-menu) Travel System Admin. NOTE: If Travel System Admin is your only Travel option, then the commands are
Travel Agency to: Travel Agency rve cel Travel Agency to: – Reserve a Travel: – Cancel a Travel Pay the Travel Payment f a Travel re s Insurance P H – Pay the Travel a The Travel Agency needs to be in contact with a Visa cilities ervation faciliti e urchase nds on be in contact with a Visa payment center in order to be paid by the .
53 Best Travel Agency - Hong Kong Westminster Travel Limited 54 Best Travel Agency - India Thomas Cook (India) Ltd. NEW VS. 2018 55 Best Travel Agency - Indonesia Panorama Destination Indonesia 56 Best Travel Agency - Japan JTB Corp. 57 Best Travel Agency - Malaysia Mitra Tours & Travel 58 Best Travel Agency
Guidance - Travel Plan Contents 1. Executive Summary 2. Introduction of Travel Plan 3. Travel Plan Administration 4. Existing Travel Patterns 5. Proposed Travel Patterns 6. Measures 7. Targets 8. Monitoring and Review 9. Action Plan (example) Appendix - Travel Plan Appendices (examples) A Location of Site(s) B Site Plan C Travel Policy
ROSS User Guide Travel Plan ‐ creating and editing travel plans 2version 2.16.4 January 13, 2016. Creating a travel plan. This section explains how to create a travel plan and how to add travel plan legs to it. You do not need an incident to create a travel plan. Seeravel "T ‐ setting up resource travel."
school’s Senior Staff Assistant in order to process the new online Travel Expense Report (TER) upon completion of travel. Travel Courses Travel Courses are faculty-led domestic or international travel experiences that are credit bearing. Guidelines for domestic travel courses differ from international ones, as detailed in the following sections.
INTERNATIONAL GCSE Accounting . SPECIFICATION Pearson Edexcel International GCSE in Accounting (4AC1) For first teaching in September 2017 First examination June 2019
