Capacity Planning

All capacity planning decisions should initiate from the projected scope and requirements of the client application. Capacity relates to the functionality of three basic components:

• The design and required functionality for the client application.

• The size and type of network connection.

• The number of allocated host resources for a requestor. A host resource includes the number of GTIDs, the capacity within the CRS complex, and current request behaviors.

The expected volume of Web Service calls is the key factor in capacity planning. Issues for determining expected volume include:

• The expected look-to-book ratio between requests to the CRS and actual bookings.

• The expected number of sessioned vs. sessionless transactions.

• The types of Web Service calls planned, and their expected message sizes.

The most appropriate type of connection depends on the requirements of the client application and the available resources. Dedicated connections are generally faster and have more reliable availability, while Internet connections are typically less expensive. However, many of these factors vary depending on the environment. For example, in many locations dedicated connections are prohibitively expense for some organizations, while in other locations Internet connections may actually be more reliable than the local telecommunications required for a dedicated connection.

Client Application

All capacity planning decisions should initiate from the projected scope and requirements of the client application. Answering the following questions may assist in formulating capacity requirements:

What is the expected volume of Web Service calls?

The anticipated number of transactions with the CRS directly influences the number of Web Service calls. The following questions can help to determine the expected volume.

• What is the expected look-to-book ratio, i.e., the number of requests made to the CRS before a customer actually makes a reservation?

The actual look-to-book ratio for a client application can vary greatly depending on a number of design and business factors. For example, the ratio for leisure web sites with public access is typically much higher than for a proprietary corporate application because users may be more likely to shop extensively for low fares and to receive less direct user support.

• What are the expected types of transactions, i.e., sessioned or sessionless?

In sessioned transactions, state information, such as itinerary data, is stored on the CRS. In sessionless transactions, state information is stored in the client application.

Traditional agency applications function in a purely sessioned environment, in which one session corresponds to one user sign on. In this environment, users typically stay signed on for long periods of time. Many consumer web sites use more sessionless transactions, which use a programmatic sign on. Sessionless transactions are typically more efficient because they require a specific GTID (see the following question) only for the period of time required to perform the transaction.

In Galileo Web Services, some transactions, such as booking transactions, must be sessioned. Therefore, all client applications use some combination of sessioned and sessionless transactions. Also, all terminal transactions are sessioned.

• What is the expected usage for GTIDs (Global Terminal Identifiers)?

The types and rate of transactions also relate directly to the number of host resources required for a client application. A GTID identifies a specific transaction session. Each travel provider is assigned a pool of GTIDs as part of their host resource allocation, and each session is assigned a GTID from that pool. As noted in the previous question, the number and usage of sessions will vary depending on the type of client application.

The number of available GTIDs defines how many sessions to the CRS can be open simultaneously. Sessioned environments use one GTID per session. For sessionless transactions, each transaction is assigned a GTID, which is then returned to the pool when the transaction is complete.

Before Galileo Web Services, each GTID was configured to a single Pseudo City Code (PCC), which determined security permissions for a particular organization such as a travel agency branch or travel web site. With Galileo Web Services, GTIDs are still used by the CRS; however, these GTIDs are now dynamically configured by the CRS. Clients are no longer assigned specific GTIDs as part of the provisioning process for Galileo Web Services.

Note that GTID usage alone is not the sole determinant for host resources. In addition to the number of concurrent GTIDs, the capacity within the CRS complex and current request behaviors are also used to determine the entire capacity status for a client application. Therefore, all of these factors must be taken into consideration when capacity planning.

See the following Host Resource Governance section for details about GWS usage requirements for GTIDs.

What are the type of web service calls planned, and their expected message sizes?

The type of transaction directly affects the message size. For example, flight availability and faring transactions require significantly more data than car availability and pricing transactions. The average message sizes may vary greatly depending on the business requirements for a client application.

What is the average duration of individual transactions?

In addition to the message size, the expected duration of a particular transaction can affect capacity planning. As with message sizes, the typical duration of a transaction can vary greatly depending on the business requirements and usage of a client application. The duration of a given transaction can be affected by a variety of factors, including: network connection times, processing time by GWS, processing time by the Apollo or Galileo CRS, and (when applicable) processing time by a vendor system.

One issue that can significantly affect the duration of a transaction is the use of links between the CRSs and third-party vendors, through system relationships such as Inside Link, Inside Availability, Link Partner, and Interactive Sell. See Vendor Participation Levels for additional information. While most links between the CRSs and third-party vendors are direct, which typically limits connection time issues, the internal processing time by the vendor system cannot be anticipated by GWS.

The effect of these extended-duration transactions can potentially skew the average duration of transaction times, and significantly impact specific transaction times during peak transaction times for that vendor. Therefore, sufficient research and testing should be made to include potential vendor-specific concerns for transactions that rely on a direct link to vendor data.

Network Connection

Galileo Web Services can be supported only through an internet connection.

• An Internet connection, with TLS 1.2 protocol for security, is appropriate for most client applications.

• The amount of network bandwidth is the most important factor in planning for adequate capacity. Regardless of the type of network connection, the size of the connection has the most direct effect on the speed and capacity of the client application.

Host Resource Governance

To ensure adequate capacity for all customers, GWS uses a host resource governance process that limits the number of allocated host resources for concurrent CRS transactions that a client application can perform. This process is intended to prevent any single requestor from denying host resources to other customers using GWS.

If a request to GWS exceeds the established limit for a customer, the following response is returned, where NNNNN is the requestor ID:

Host resource usage has been exceeded for requestor NNNNN.

Host Resources per Request

In GWS, the number of host resources in a request equivalent to the number of requests. Because host resources are required to work with the Apollo and Galileo host systems, host resource usage is dependent on the number of requests made to the host for a Web Service transaction, not the number of requests made to GWS.

The number of host requests in a single call varies by Web Service, depending on the type of GWS transaction. Sessioned and sessionless transactions manage host resources differently, as do terminal and XML structured data transactions. The usage of host resources can also vary for each Web Service that uses Encapsulated Business Logic (eBL Web Services).

Sessioned Transactions

A single host resource is used for the duration of the session. Sessions are required for all terminal transactions, and are either required or optional for structured data XML transactions, depending on the type of transaction. Sessioned transactions are submitted only using the XML Select Web Service;  see XML Select Web Service Methods for more details about host resource usage.

• For terminal data requests through the XML Select Web Service, a BeginSession call pre-reserves a single host resource for the duration of the session. The same host resource remains in use until an EndSession call is made, which releases the host resource. Within this session, multiple transactions can be sent using the SubmitTerminalTransaction method; these transactions do not require any additional host resources beyond the session host resource..

• For structured data requests through the XML Select Web Service, the SubmitXmlOnSession method make a single synchronous call to GWS, and uses one host resource per call. Multiple XML transactions cannot be sent within a session.

Sessionless Transactions

For sessionless transactions, a single host resource is used for each transaction. The number of transactions per request varies depending on the type of Web Service and/or Submit method. Sessionless transactions can only be submitted using XML structured data; terminal transactions, by definition, cannot be sessionless.

For sessionless requests through the XML Select Web Service, the following host resource rules apply:

• The SubmitXml method makes a single synchronous call to GWS, and uses one host resource per call.

• The MultiSubmitXml method makes multiple structured data transactions within a single web service call. In this case, the number of host resources is equal to the number of transaction requests within the call. Sufficient host resources must be available to complete all of the transactions in the multi-submit call.
  
  NOTE: Use the MultiSubmitXml method whenever possible, but avoid bundling too many transactions into the MultiSubmitXml call because the response times are affected by the slowest responding transaction. The recommended limit to the number of requests is 15 - 20 included in a single call (never exceed 34), and there are diminishing returns if the number is extremely high.
  
  For example, all requests in a MultiSubmitXml request are processed simultaneously. If the multi-submit contains 14 requests, then the CRS will receive 14 requests at near the same time.
  
  If the load on the CRS is too great for a MultiSubmitXml request (for large XML Transactions, such as AirAvailability, FareQuoteSuperBB, or PNRBFManagement), a Procedure 5030 metering error displays. Reduce the number of XML Transactions in the MultiSubmitXml request.
  
  DO NOT USE MultiSubmitXml with FareQuoteFlexShop. Only use SubmitXml with FareQuoteFlexShop.

• The SubmitCruiseTransaction method makes a series of sequential requests to the host, and uses one GTID per request.

See XML Select Web Service Methods for more details about host resource usage.

Encapsulated (eBL) Web Services

For Encapsulated (eBL) Web Services transactions, the number of requests to the host depends on the service and type of request. Transactions within the Web Service may be submitted as sessioned or sessionless, depending on the type of transaction. For example:

• A hotel definition request using Image Viewer eBL submits a single HotelDescription_5_0 transaction to the host. A single host resource is used for the one transaction request.

• A general air availability request using Trip Planner eBL submits three FareQuoteSuperBB_9 transactions to the host. A host resource is required for each FareQuoteSuperBB_9, so a total of three host resources are required for this request.
  
  If additional Trip Planner eBL transactions are included with the request, such as standard car availability and car description transactions, additional host resources are also required for these transactions.

• Travel Codes Translator eBL does not interact with the host; therefore, no host resources are required for encode or decode requests to this Web Service.

See the Interaction with Host topic for each Encapsulated Web Service for more details about GTID usage for that Web Service.

Number of GTIDs per Customer

Before developing and implementing client applications with GWS, customers should work with their Galileo account representative and the GWS Support Desk to determine their peak utilization and corresponding host resource requirements. If a customer is doing batch processing through GWS, their client application may need to be coded to account for any limits. However, Galileo should typically be able to accommodate any reasonable limit, with sufficient advance notice. It is strongly recommended that host resource needs be established and tested before moving client applications to the Production system.

• If no host resource specified capacity is established for a customer, host resources are applied to customers based on current system capacities.

• If a requestor is using batch processing, the Galileo account representative should create a unique Requestor ID used specifically for batch processing.

If additional host resources are required, contact the GWS Support Desk.