Find JSRs
Submit this Search


Ad Banner
 
 
 
 

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 42: Travel Industry Reservation Booking Foundation API Specification

Stage Access Start Finish
Withdrawn   13 Jun, 2000  
CAFE   30 Nov, 1999 11 Jan, 2000
JSR Approval   23 Nov, 1999 29 Nov, 1999
Status: Withdrawn
Reason: Withdrawn at the request of the submitter. Community support was not sufficient to form an expert group.
JCP version in use: 1.0
Java Specification Participation Agreement version in use: 1.0


Description:
This intended to ease the building of applications for reservation booking in the travel industry that would cross all aspects of travel (air, car, hotel, cruise, and other travel activities).

Please direct comments on this JSR to the Spec Lead(s)
Team

Specification Leads
Expert Group
       
       

This JSR has been Withdrawn
Reason: Withdrawn at the request of the submitter. Community support was not sufficient to form an expert group.

Original Java Specification Request (JSR)

Identification   |   Request  |   Contributions

Original Summary: This proposal intended to make it easier to build applications for reservation booking in the travel industry that will cross all aspects of travel (air, car, hotel, cruise, and other travel activities).

Section 1: Identification

Submitting Participant: IBM
Contact Person: Sherry Shavor
E-Mail: sshavor@us.ibm.com
Telephone: 919-254-1537
Fax: 919-486-0574

List of other Participants who endorse this JSR:

  • British Airways
  • Business Interactive Corporation
  • Galileo International
  • International Air Transport Association (IATA) 
  • Lanyon
  • Online Fulfillment Services
  • Open Travel Alliance (OTA)
  • Xcelerate

Section 2: Request

2.1 Please describe the proposed Specification:
This request is to develop a set of industry-standard APIs for the JavaTM platform that will make it easier to build applications for reservation booking in the travel industry. This specification will introduce a set of classes and interfaces for the travel industry reservation booking sector that will be utilized for access to current CRS (Computer Reservation System) legacy systems, and for implementing new reservation systems. This specification seeks to define this initial set of classes and interfaces in concert with emerging travel industry efforts that are underway to define travel industry XML DTDs. Ideally, the result of this specification will form the foundation set of industry agreed upon Java classes and interfaces that fit closely with these emerging Travel XML efforts from such groups as the Open Travel Alliance, IATA, etc.

The advantages that these classes will bring is that it raises the bar in terms of programmer productivity by providing classes and interfaces that are closer to the solution or problem domain.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)
This effort would focus on the desktop Java platform. It must be able to support business to business (B2B) including (EJB/server) and business to consumer (B2C) models including (desktop/pervasive devices).
2.3 What need of the Java community will be addressed by the proposed specification?
Increasingly, many companies in the Travel industry, and software companies servicing the Travel industry, are using Java for key business solutions. This is especially true in the Internet Reservation space. Standard interfaces for accessing current reservation systems through Java will reduce the architecture and design time for these solutions, and provide a consistent approach to accessing backend reservation systems over the internet through Java. This will ultimately result in better and quicker solutions for the end travel internet user.
2.4 Why isn't this need met by existing specifications?
The travel industry has well defined standards addressing areas involved at the line protocol area used between terminals and backend reservation systems, and standards that address system-to-system exchange of data for travel inventory to support sales of travel industry products, such as airline seat inventory, etc. Other standards exist as well in other sectors of the travel industry. However, as the internet reservation market emerges, there are no industry standards for support of representing that same information through application code built on a web server using object oriented programming.. Industry standards in this area, will help encapsulate backend reservation systems from the web logic perspective, as most backend reservation systems differ superficially, but provide much of the common base functionality concerning reservation bookings.
2.5 Please give a short description of the underlying technology or technologies:
[Not applicable]
2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, com.something, etc.)
As Java industry standards into the industry domains begin to emerge, setting package name standards is a forefront consideration. We suggest that the package names be architected for consistency, with an open-ended approach that can be extended and defined by the industry groups over time. We suggest the general package names for Java standards that specifically address the industry domains follow a convention of:

javax.industry.X.*

where X is a specific industry such as "travel", "manufacturing", or "medical". Consideration should also be taken into account for cross-industry packages such as packages containing "people" objects, etc. For cross-industry packages, we propose:

javax.industry.common.*

For the travel industry in specific, we suggest:

javax.industry.travel.*

And for types and interfaces specifically for this JSR, we would forecast two possible packages:

javax.industry.travel.common.*
javax.industry.travel.reservation.*

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?
No.
2.8 Are there any security issues that cannot be addressed by the current security model?
No.
2.9 Are there any internationalization or localization issues?
No.
2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?
No.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.
There are various standards documents within the Travel industry that address various aspects of travel. One of the primary standards bodies in the travel industry is:

IATA (International Air Transportation Association) http://www.iata.org

A variety of documents can be purchased from IATA that describe line communication protocols and information exchange protocols that will provide a base line of terminology and structure for which a higher-level OO effort could begin.

Other relevant standards bodies are:

The OTA (OpenTravel Alliance) http://www.disa.org/opentravel.com

Services in the travel industry encompasses air, car rental, rail, motel, and more. Other relevant links, such as that addressing motel can be found at: http://www.hedna.org

3.2 Explanation of how these items might be used as a starting point for the work.
This JSR specifically seeks to address Java classes and interfaces applicable to online, or other digital channels, reservation bookings. Much of the information flowing through current standards at the data interchange level, are also applicable to define the base relations, types, and interfaces for the Java environment.

Section 4: Additional Information

More specifically, and as an example, the focus of this JSR is to address types, and interfaces for travel notions such as:

  • "TravelVehicle" -> (aircraft, rental car, etc)
  • "TravelServiceLocations" ->(airport, rental car dropoff, motel, etc)
  • "TravelSegment" ->TravelVehicle movement between TravelServiceLocations
  • Notifications of a confirmed, changed or cancelled reservation
  • Traveler profile information such as seating or dietary preferences