Abstract:
A faring system includes a production facility including at least one fare shopping server, a staging facility including at least one fare shopping server, and an entry point for conducting bi-directional communications with customers. The staging facility further includes a database storing transformation rules and a traffic generation subsystem configured to receive a transaction via the entry point from a customer, to determine if the received request is one suitable for use in generating simulation data for the fare shopping server of the staging system and, if so, to modify the received transaction in accordance with at least one rule retrieved from the database to create at least one modified transaction, and to send the at least one modified transaction to the fare shopping server of the staging facility for processing. The fare shopping server of the staging facility processes the modified transaction for evaluating a potential new or modified functionality of the faring system.

Description:
TECHNICAL FIELD 
       [0001]    The exemplary embodiments of this invention relate generally to faring systems and, more specifically, relate to the generation of pseudo-traffic (shadow traffic) for evaluating faring system modifications/enhancements. The various exemplary embodiments can be used in an on-line system providing travel-related products to customers. 
       BACKGROUND 
       [0002]    Several terms used below are defined as follows. 
       Transactional Faring System 
       [0003]    A system which is able to compute and return fare quotes based on criteria requested by customers such as cheapest fares which apply for a destination, and best fares around a given date. Customers communicate with the transactional faring system, also referred to herein as a faring system, by means of transactions, i.e., a question (request for fare quote) followed by an answer (computed fare quote). 
       Fare Shopping Servers 
       [0004]    Fare shopping servers are transactional servers which implement the products provided by the faring system. These servers are in charge of computing responses to queries made by the customer. There are two kinds of fare shopping servers: those dedicated to production, those dedicated to staging. 
       Production 
       [0005]    The production is an operational facility (a computer system) where computations take place in order to return answers to the queries made by customers. 
       Staging 
       [0006]    Staging is a relatively small and dedicated part of the faring system where a new product can be “validated” before being publicly made available to customers. 
       Operational Validation 
       [0007]    When a new product has been validated as “functionally” valid, it goes though a series of tests under real life conditions to ensure it is also “operationally” valid (i.e., the impact of the product on the entire faring system is assessed). This is referred to as operational validation. 
       Shadow Traffic 
       [0008]    A part of the traffic (i.e., requests from customers) is duplicated by the faring system to serve as a source of traffic for staging. The responses to this duplicated traffic (referred to as the shadow traffic) are not returned to customers. 
         [0009]    The exemplary embodiments of this invention pertain most particularly to a transactional faring system whose purpose is to compute and return the best fare quotes based on criteria requested by customers: e.g., cheapest flights for a given destination and date, best flight fares around a given date, etc. These services are treated via fare shopping servers and accessed at a high rate (e.g., 90 million transactions per day). 
         [0010]    Forecast changes in the faring system (e.g., new products, new volumes, new customers) are preceded by operational validations to ensure that the system can cope with the expected additional resource consumption (e.g., CPU, memory, database, network and other resources). 
         [0011]    Operational validations are implemented by means of shadow traffic. That is to say, a part of the incoming customer traffic is duplicated from the production facility, without customer awareness. This duplicated, shadow traffic is then forwarded to a phantom operational facility referred to as the staging facility intended to test evolutions in the faring system. The effect of this shadow traffic run on the staging facility is then monitored and analyzed, while the original traffic is processed in a normal fashion by the production facility and returned to customers in a normal manner. 
         [0012]    When introducing such production evolutions (e.g., new markets, new dimension, new products) cases can arise where the existing traffic is not suitable for operational validations. In such cases, it is necessary to simulate traffic in order to generate the inputs necessary for performing the validations. 
         [0013]    It can be noted that several techniques might be envisioned to obtain relevant traffic for operational validations. 
         [0014]    For example, one such possible technique would be to activate the evolution to one client at a time. In this possible approach the evolution (e.g., new product, new market) would be provided by the faring system and enabled only for a few clients in a first phase. It can be expected that the total resources consumed for processing the new service will have a limited impact on the overall production facility, and this cost can be analyzed precisely for creating accurate capacity planning. 
         [0015]    However, this approach involves requesting clients to begin sending new traffic, which may be difficult. There is a risk that the traffic generated even by a few clients consumes more resources than expected and which can consequently endanger the operational stability of the faring system. Another drawback is that this scheme is not applicable in a case where it is a prerequisite to simultaneously open the new service to all clients. 
         [0016]    Another possible technique would be to generate traffic from pre-recorded existing traffic. That is, one might record existing customer traffic for a given period of time and then transform this recorded traffic off-line (e.g., from disk) to make it appear as traffic that will target the new product. The transformed traffic can then be replayed manually while monitoring the resources consumed by the processing of the new service on the pre-recorded and transformed traffic. 
         [0017]    However, replaying pre-generated traffic does not offer sufficient diversity, especially when the validation needs to be run over a long period of time. Moreover, is very difficult to mimic a pace of the replay which looks like actual traffic. At least these two shortcomings result in incomplete benchmarking and thus result in inaccurate capacity planning. 
         [0018]    Another possible technique would be to convert the contents of incoming requests before they are processed. For example, a converter unit can be put in front of the real servers to modify the contents of incoming requests, for example, for enabling new features (i.e. new options) of a product provided by the faring system. No off-line storage need be involved in this process. 
         [0019]    However, this approach is not practical in practice as its operation impacts customers of the production facility. For example, those clients whose traffic is modified can be given responses for different requests that what they have asked for, resulting in customer confusion and the possibility of alienating these customers. 
         [0020]    Another approach would be to copying all the incoming requests from customers and use them on an adjacent server. This way, only realistic traffic is used without bothering the customers. 
         [0021]    However, this method generates an important amount of data especially since customer traffic varies depending on the day and date, special offers, holidays and so on. So the server can actually be overloaded with much more traffic than it can handle, including a lot of useless information. 
       SUMMARY 
       [0022]    The foregoing and other problems are overcome, and other advantages are realized, in accordance with the embodiments of this invention. 
         [0023]    In one aspect thereof the exemplary embodiments provide a method performed by a faring system having a production facility comprising at least one fare shopping server, a staging facility comprising at least one fare shopping server, and an entry point for conducting bi-directional communications with customers. The method is characterized as comprising, in response to receiving a transaction from a customer, sending the transaction to the fare shopping server of the production facility for processing and also to a traffic generation subsystem that forms a part of the staging facility; selectively modifying the received transaction at the traffic generation subsystem in accordance with at least one rule to create at least one modified transaction; and sending the at least one modified transaction to the fare shopping server of the staging facility for processing. 
         [0024]    In another aspect thereof the exemplary embodiments provide a faring system that comprises a production facility comprising at least one fare shopping server, a staging facility comprising at least one fare shopping server, and an entry point for conducting bi-directional communications with customers. The faring system is characterized in that it further comprises a database storing transformation rules and a traffic generation subsystem configured to receive a transaction via the entry point from a customer, to determine if the received transaction is one suitable for use in generating simulation data for the fare shopping server and, if so, to modify the received transaction in accordance with at least one rule retrieved from the database to create at least one modified transaction, and to send the at least one modified transaction to the fare shopping server of the staging facility for processing. 
         [0025]    In another aspect thereof the exemplary embodiments provide a faring system that comprises production facility means having at least one fare shopping server means, staging facility means comprising at least one fare shopping server means, and entry point means for conducting bi-directional communications with customers including receiving transactions from customers and sending received transactions to said fare shopping server means of the production facility means for processing and for sending the received transactions to said staging facility means as shadow transactions. The faring system comprises means for selectively modifying a shadow transaction received from said entry point means at the staging facility means in accordance with at least one rule obtained from a rules database to create at least one modified shadow transaction. The rules database comprises at least a set of transformation rules and a set of execution rules. The faring system is further characterized as comprising means for sending the at least one modified shadowed transaction to the fare shopping server means of the staging facility means to be processed for evaluating a potential new or modified functionality of the faring system. 
         [0026]    In another aspect thereof the exemplary embodiments provide a faring system that comprises production facility means having at least one fare shopping server means, staging facility means comprising at least one fare shopping server means, and entry point means for conducting bi-directional communications with a customer. The faring system comprises means for determining if a received customer transaction (request) is one suitable for use in generating simulation data for the fare shopping server means; means for modifying a suitable customer transaction received from said entry point means at the staging facility means in accordance with at least one rule obtained from a rules database to create at least one modified transaction. The rules database comprises at least a set of transformation rules and a set of execution rules. The faring system is further comprising means for sending the at least one modified transaction to the fare shopping server means of the staging facility means to be processed, and means for sending to the customer a result of the processed modified transaction for use by the customer in evaluating a potential new or modified functionality of the customer. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0027]    The foregoing and other aspects of the presently preferred embodiments of this invention are made more evident in the following Detailed Description of the Preferred Embodiments, when read in conjunction with the attached Drawing Figures, wherein: 
           [0028]      FIG. 1  shows a faring system that is constructed and operated in accordance with the exemplary embodiments of this invention to include a traffic generation subsystem and a transformation rules database. 
           [0029]      FIG. 2  is a logic flow diagram that illustrates the operation of the traffic generation subsystem of  FIG. 1  when transforming a given TXN A  into at least m one TXN B . 
           [0030]      FIG. 3  shows an increase in a maximum number of recommendations. 
           [0031]      FIG. 4  illustrates various steps which occur in the traffic generation subsystem of  FIG. 1  during the generation of the new (transformed) shadow traffic. 
           [0032]      FIG. 5  shows an increase in a number of requested flights from a first transaction to a second, modified transaction. 
           [0033]      FIG. 6  illustrates various steps which occur in the traffic generation subsystem of  FIG. 1  during the generation of the new (transformed) shadow traffic in accordance with the example of  FIG. 5 . 
           [0034]      FIG. 7  shows the faring system that is constructed and operated in accordance with the exemplary embodiments of this invention to include the traffic generation subsystem and the transformation rules database when operated to return information to client for use by the client in characterizing a new product. 
       
    
    
     DETAILED DESCRIPTION 
       [0035]    By way of introduction, the present invention describes a novel system that interacts with a transactional faring system in order to generate any desired traffic from existing traffic coming from the faring system&#39;s operational facility. 
         [0036]    As will be described in detail below, the exemplary embodiments of this invention provide an autonomous system based on a generic framework whose purpose is to transform incoming traffic to resemble new traffic and send it to staging facility fare shopping servers. The framework is driven by a dedicated knowledge database to determine how to transform the incoming transactions and how to populate new fields present in the generated transactions (e.g., possible valuations of fields, inter-relation between field values, etc.). The system adapts its transformations per market depending on the incoming shadow transaction that it receives. The system can rely on plug-ins for business transformations when ad-hoc generation is required (e.g., complex or domain-specific data manipulation). Real-time traffic transformation allows the system to generate diversified transactions continuously, and thus to provide a high level of confidence in the measurements of resource consumption performed during operational validations. The system has the ability to generate as much traffic as is necessary, whatever the amount of incoming traffic happens to be. The system does not impact the production client operations since it operates on shadow traffic, and does not need direct customer intervention to operate. Further, the system throttles traffic generation automatically for operational stability (e.g., to preserve external production systems connected to the staging facility). 
         [0037]    The use of the exemplary embodiments of this invention also provides a number of business-related advantages. For example, the generic transformation framework enables the generation of traffic suitable for simulating a broad variety of situations (e.g., stress test, endurance, robustness, capacity, limits). The generated traffic can be used to test the limits or the corner cases of new products, something which in practicality cannot be achieved with real customer traffic. Further, the accuracy of generated traffic improves the confidence in the metrics gathered during operational validations, which is an important factor when considering the accuracy of capacity planning. The reduced dependency on customers also aids in improving the time to market of new products deployed in the faring system. In addition, the automatically generated traffic reduces the time spent in performing operational validations, thereby reducing cost. Further, the use of the exemplary embodiments of this invention aids in maintaining the operational quality of production facility for daily operations, while reducing the risk of inducing instability during the introduction of new customers or new products in the faring system. The use of the exemplary embodiments of this invention also enables customers to perform their own capacity planning to monitor the impact of new products on their own operational facility. 
         [0038]    For example, exemplary embodiments of this invention can use a generic traffic transformation approach rather than relying on manual transformations. That is, the system generates traffic, based on business transformation rules stored in a knowledge database, and is capable of accommodating plural traffic transformations at one time. This provides a versatile traffic simulator suitable for a broad variety of operational validations. The system alleviates the need to design a new traffic transformer manually each time an operational validation must be performed, thereby reducing the cost of operational validations as compared to maintaining a manually-derived, hand-written traffic transformer. 
         [0039]    The exemplary embodiments provide real time and accurate traffic generation that greatly improves operational validations. The traffic generation is performed on live traffic, and can thus provide day-long operation. This approach allows reproducing all of the traffic behaviours that are typically seen in production, such as changes in transactions per second, as well as transaction stress peaks at specific times during the day. The pace of sending and the relevance of the generated traffic make the use of this invention very effective at extensively testing new products (e.g., limit behaviours and corner cases). The use of the exemplary embodiments enables the faring system to be extensively and realistically stress tested. 
         [0040]    The exemplary embodiments also operate in a transparent manner with respect to production, and are transparent to customers, as transactions are generated from shadow traffic without impacting production performance. The system of this invention does not return data to production. The system is also transparent to staging fare shopping servers as it acts as a standalone interposition server between shadow traffic and staging fare shopping servers. The fare shopping servers are not aware that they receive generated traffic and do not need to be modified to handle the received traffic. 
         [0041]    The system can also throttle or suspend the generation of traffic in the event that it sends too much generated traffic to the staging fare shopping servers, or in the event that the generated traffic results in some technical problem. In case the staging faring system needs to contact external production facilities (e.g. customer booking flights availability servers) mitigation of the effect of too much generated traffic is achieved. 
         [0042]    Reference can be made to  FIG. 1  for showing a faring system  10  that is constructed and operated in accordance with the exemplary embodiments of this invention. The faring system  10  includes a production facility or system  12  containing fare shopping servers  14  and a staging facility or system  16  also containing fare shopping servers  18 . The production facility  12  and the staging facility  16  are communicatively coupled to an entry point  20  through which customers  22  gain access to the faring system  10 , and through which they receive responses to queries. The entry point  20  provides real traffic (TXN A ) received from the customers  22  to the fare shopping servers  14  of the production facility  12 . Note that in an exemplary application and use case the production facility  12  may have no knowledge of the existence and/or operation of the staging facility  16 . 
         [0043]    In accordance with the exemplary embodiments the staging facility  16  further includes a traffic generation server or subsystem  24  coupled with a database  26  storing various business transformations and other information used by the traffic generation subsystem  24  during operation of the traffic generation subsystem  24 . 
         [0044]    The exemplary embodiments of this invention thus include as one aspect thereof the new traffic generation subsystem  24  in the faring system  10 . The faring system  10  provides several products served by the fare shopping servers  14 . The faring system  10  is basically duplicated in two facilities. The first facility is the production facility  12 , which is responsible for processing production requests coming from customers  22 . The second facility is the staging facility  16 , essentially a private facility used during operational validations for staging new services, new markets, etc. 
         [0045]    In  FIG. 1  the production faring facility  12  is shown serving a request from a customer  22  which is targeting product A by issuing the TXN A . It can be assumed that certain operational validations are on-going to stage a new product B which is going to be made available in the production facility  12 . In order to stage this service, some traffic TXN B  must be available to the fare shopping servers of the staging facility  16 . This traffic TXN B  is generated by the traffic generation subsystem  24 . 
         [0046]    When a client (customer  22 ) makes the request TXN A  to the faring system  10  the entry point  20  makes a copy of this request (shadowed TXN A ) and routes it to the traffic generation subsystem  24  in the staging facility  16 . The traffic generation subsystem  24  generates a new request TXN B  and sends a collateral transaction (via entry point  20 ) to the staging fare shopping servers  18  for further monitoring. Meanwhile, the customer  22  receives the response it expects from TXN A , without being impacted by the ongoing operational validation being performed by the staging facility  16 . 
         [0047]    The traffic generation subsystem  24  which implements the invention is preferably configured to listen and respond to any kind of transaction defined in the faring system  10 , and to thus to be able to receive any input traffic. 
         [0048]    Referring also to  FIG. 2 , the traffic generation subsystem  24  operates to selectively transform a given TXN A  into one or more (at least one) TXN B . The generation of this pseudo-traffic follows a technique driven by transformations, also referred to herein as business transformations, stored in the dedicated database  26 . At Block  2 A, the traffic generation subsystem  24  checks by using an input filter whether the incoming TXN A  can be used as a source of traffic for the on-going operational validation. If not, the TXN A  is dropped (ignored) and is thus not transformed into at least one TXN B . Assuming that the incoming TXN A  can be used, then depending on the contents of the fare shopping request TXN A  (e.g., outbound flight, inbound flight, operating carrier, travel agency, etc.) the traffic generation subsystem  24  fetches from the business transformations database  26  a list of transformation rules  26 A that should be applied to generate new traffic. The transformation rules  26 A can include, as non-limiting examples, values rules, distribution rules and relation rules. If no transformation rule is found to apply, the transaction is dropped. Assuming that a transformation rule  26 A is found to be applicable, at Block  2 C the traffic generation subsystem  24  then checks execution rules  26 B that should apply for the generated traffic (e.g., number of transactions to generate from the input, the sending pace, etc.) As shown in  FIG. 2 , the execution rules  26 B can include, for example, throttling rules and looping rules. The traffic generation subsystem  24  then applies, at Block  2 D, the applicable transformation rule(s)  26 A to generate one TXN B , and at Block  2 F sends the generated TXN B  to the fare shopping servers  18  for processing (via the entry point  20 ). Note that this process can be recursive, and can be repeated until the amount of traffic indicated by the execution rules  26 B is reached. This recursion is depicted in  FIG. 2  by the Blocks  2 E and  2 G. 
         [0049]    The traffic generation subsystem  24  thus generates traffic by applying the series of transformation rules  26 A and execution rules  26 B. The applicable rules  26 A,  26 B are stored in the dedicated database  26 . Typically, the database  26  can be populated manually depending on the needs of the operational validation. For traffic to be generated it is sufficient to have at least one rule defined in the database  26 . As a corollary, not all types of rules need to be present in the database  26 . 
         [0050]    Discussing now in further detail the rules  26 A,  26 B, a particular transformation rule  26 A specifies: the type of input it applies to, a set of rules to apply in order to generate a new output (TXN B ), and a name of (or some other type of reference to) one or more of the execution rules  26 B. Some rules can express a simple data mapping, e.g., that the values of fields from TXN A  are copied to fields in TXN B . Other rules can express how to provide a value to new fields in TXN B . These rules, which can be referred to as the valuation rules, define a list of fields (e.g., carrier, market, city, etc.) which will be inserted in the generated requests, along with a list of values which can be generated for each field. For example, a valuation rule can specify to add a city field with either NYC or PAR as the possible values. Distribution rules specify the frequency at which values are generated for a field. In accordance with the example above, one exemplary distribution rule could generate the value PAR 60% of the time, and NYC 40% of the time. Relation rules specify how a field valuation affects the valuation of other fields. Relation rules can be used, for example, to model semantic dependencies between fields, or to blacklist (prohibit) certain combinations of valuations. 
         [0051]    For properties which do not match the generic approach, an ad-hoc transformation can be performed using a plug-in. This can be useful when the generation logic depends on, for example, some specific complex business constraints (e.g. generation based on geographic constraints). 
         [0052]    An execution rule  26 B specifies looping and traffic regulation for the traffic generated from an input transaction. Looping rules specify how many transactions to generate from an input TXN. This can be useful in a case where the real production traffic is not available in sufficient quantity for the needs of the operational validation. In this case then it can be specified to generate n TXN B  from a single TXN A , where n can be equal to one or greater than one. Another type of execution rule  26 B are regulation rules that define how to send the generated traffic, for instance the frequency of sending in TPS (transactions per second). The sending function auto-regulates itself to send less traffic if the generated traffic yields too many technical errors (for instance, too many transaction time outs are generated) 
         [0053]    Several exemplary use cases are now described in order to further explain the to operation of the invention, and the benefits and technical effects that are gained through the use of the invention. 
         [0054]    A first use case example concerns increasing the number of flight recommendations returned to a customer. 
         [0055]    Assume that within the faring system  10  the customer  22  has access to a product A which returns the least expensive flights for a given journey (departure plus destination) on a given date and operated by a given carrier. The faring system  10  returns recommendations for the least expensive flights which match the customer criteria. 
         [0056]    Assume that the customer has the right to request up to 100 flight recommendations, and that it is desirable to test how the faring system  10  would behave if the maximum number of recommendations is raised to a larger value (e.g., to 250 flight recommendations), as shown in  FIG. 3 . 
         [0057]    The evolution of this product can be implemented with the following constraints in mind. First, the customer  22  cannot be granted the right to request more flight recommendations, as this may endanger the operational stability of the faring system  10 . In addition, the maximum number of flight recommendations which can be computed by the faring system  10  is unknown, and needs to be estimated beforehand. 
         [0058]    Given the constraints above, the traffic generation subsystem  24  can be configured with the following transformation rules (stored in the database  26 ): 
         [0059]    one valuation rule which determines the range of flight recommendations number requested by the customer; 
         [0060]    one distribution rule that specifies that the recommendation values are generated randomly; and 
         [0061]    one relation rule that specifies that if the input traffic requests more recommendations than the generated output, keep the largest number of recommendations. 
         [0062]    The sequence shown in  FIG. 4  illustrates the various steps which occur in the traffic generation subsystem  24  during the generation of the new (transformed) shadow traffic. 
         [0063]    Blocks  4 A and  4 B are basically identical to Blocks  2 A and  2 B of  FIG. 2 . In this case traffic captured from the production facility is transmitted to the traffic generation subsystem  24 . The input filter (Block  4 A) only retains the traffic related to product A. 
         [0064]    At Blocks  4 C and  4 D, during the operational validation the valuation rule is updated manually to change the range of flight recommendations number (first [ 100 , 300 ], then [ 200 , 400 ], then [ 300 , 500 ], etc.) until a new acceptable value for “maximum recommendations” is determined. This incremental approach aids in determining the limits of the faring system  10 , something which would have been difficult or impossible to achieve if one were to rely on the use of only real production traffic. 
         [0065]    A second exemplary use case concerns generating complex itineraries for a specific carrier. 
         [0066]    Assume as a non-limiting example that a Japanese customer which currently uses Product B will soon use a new product B′ provided by the faring system  10 . The customer  22  will request fare quotes for a journey comprising “complex itineraries”, such as the least expensive fares for journeys involving at least four flights (domestic or international) over a given date range. Assume further that at present the customer traffic targeting product B only contains domestic requests composed of, at most, two flights. 
         [0067]    In order to generate relevant traffic for operational validation, the traffic to generation subsystem  24  is configured to process transactions from this Japanese client only. The traffic generation subsystem  24  applies the following rules (see also  FIG. 5  and  FIG. 6 ). 
       Transformation Rules: 
       [0068]    One valuation rule: new international flights are inserted in incoming requests. Cities inserted are all accessible from Japan in one direct flight. 
         [0069]    One distribution rule: international flights are inserted randomly in the flight segments of the generated request. 
         [0070]    One relation rule: a semantic relation specifies that inserted flights must be chosen such that all flights remain consecutive in the flight request (as depicted in  FIG. 5 ). 
         [0071]    A second relation rule: whatever the number of flight segments present in the original request (either one or two), there must be four flight segments in the generated request. 
       Execution Rules: 
       [0072]    One regulation rule: new transactions must not be sent at a frequency that is greater than 10 TPS so as not to exceed computational capacity. 
         [0073]    In the foregoing example assume that for an incoming TXN b  not all three constraints (i.e., cities inserted are all accessible from Japan in one direct flight, inserted flights must be chosen such that all flights remain consecutive in the flight request, and there must be four flight segments in the generated request) can be enforced at the same time. In this case, the input filtering function would simply drop the incoming TXN b , and no transaction would be generated. 
         [0074]      FIG. 6  illustrates the various steps which occur in the traffic generation subsystem  24  during the generation of the new traffic (TXN B ′) from the production traffic TXN B . The Blocks  6 A,  6 B and  6 C are substantially the same as Blocks  2 A,  2 B and  2 C, respectively, of  FIG. 2 . Traffic headed to the production facility  12  is captured (i.e., duplicated) by the entry point  20  and is transmitted to the traffic generation subsystem  24 , and only traffic related to product B (TXN B ) is kept. That is, traffic which does not correspond to the Japanese client (and to product B) is simply dropped. Requests are processed according to the valuation rules in Block  6 D, and the new traffic (TXN B ′) is sent to the staging facility fare shopping servers  18 . The newly-generated transactions are dropped before being sent if the amount of generated traffic per second exceeds the limit imposed by the execution rule related to throttling (10 TPS in this example). 
         [0075]    A third exemplary use case concerns performing operational validation on client facilities. 
         [0076]    Assume that an airline (referred to herein as a client  22 ′) is about to deploy a new service on its Web portal. This service makes use of a new product X of the faring system  10 . Reference in this regard can be made to  FIG. 7 , which is similar in several respects to  FIG. 1 . 
         [0077]    Before opening production, the amount of information returned by the faring system  10  to the client airline is not known precisely. In order to ensure that the client&#39;s Web infrastructure will be able to process the amount of data returned by the faring system  10 , the client desires to test its own service (for new product X) before opening it in production. Assume also that the client does not wish to perform its operational validation manually, and needs an existing source of traffic to simulate the new traffic and to verify the operational stability of the client&#39;s Web infrastructure. 
         [0078]    In this scenario it is possible to provide the client  22 ′ with private access to the traffic generation subsystem  24  of the staging facility  16 . Having achieved the private access, the client  22 ′ sends traffic (e.g., pre-recorded traffic transactions, duplicated traffic and/or traffic obtained by the client  22 ′ by whatever means) that is directed to the traffic generation subsystem  24  (TXN W ). This traffic is transformed in accordance with business transformations stored in database  26  into traffic TXN X  that is supplied to the staging system fare shopping servers  18 . In this case the business transformations are selected to implement transaction messages that pertain to the new service to be launched by the airline client  22 ′. The output of the fare shopping servers  18  is subsequently returned as TXN X  traffic to the airline client  22 ′, thereby enabling the client  22 ′ to test its Web infrastructure prior to the actual launch of the new service in conjunction with the faring system  10 . That is, the traffic generation subsystem  24  generates the relevant transactions and passes them to the staging system fare shopping servers  18  for processing. The responses from the fare shopping servers  18  are forwarded to the client  22 ′, who is then able to process the data and perform its own operational validation. 
         [0079]    It is pointed out that the various blocks shown in  FIGS. 2 ,  4  and  6  can represent operations carried out in response to the execution of computer program instructions by one or more data processors that form a part of the traffic generation subsystem  24 , in cooperation with the knowledge model (transformation rules, execution rules) stored in the business transformations database  26 . These computer program instructions are considered to be stored in or on some suitable computer-readable medium, such as fixed or removable disk and/or fixed or removable semiconductor memory or memories, which form a part of the traffic generation subsystem  24 . Alternatively, the various blocks shown in  FIGS. 2 ,  4  and  6  can be viewed as interconnected hardware elements that are configured to carry out the specified functions in cooperation with the knowledge model (transformation rules, execution rules) stored in the business transformations database  26 . Alternatively, the various blocks shown in  FIGS. 2 ,  4  and  6  can be viewed as being a combination of computer program instructions and interconnected hardware elements. 
         [0080]    Further, each of the production facility  12 , staging facility  16  and fare shopping servers  14  and  18  can each be implemented using one or co-located or distributed data processing platforms executing computer program code. In some embodiments all of this functionality may be implemented on a single data processing platform. 
         [0081]    The foregoing description has provided by way of exemplary and non-limiting examples a full and informative description of the exemplary embodiments of this invention. However, various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings and the appended claims. As but one example, the use of other similar or equivalent faring system architectures may be attempted by those skilled in the art. However, all such and similar modifications of the teachings of this invention will still fall within the scope of the embodiments of this invention. 
         [0082]    Further, the various names used for the described system components (e.g., production facility, staging facility, fare shopping server(s), traffic generation subsystem, etc.) are not intended to be limiting in any respect, as these various system components may be identified by any suitable names. For example, the traffic generation subsystem  24  could be referred to, without a loss of generality, as a traffic emulation unit or as a shadow traffic transformation system, as two non-limiting examples. 
         [0083]    Further, it should be appreciated that the use of the exemplary embodiments is not limited to only airline reservation-related purposes, but can be used for making other types of reservations (e.g., train, bus, automobile, hotel, etc.) 
         [0084]    Furthermore, some of the features of the various non-limiting and exemplary embodiments of this invention may be used to advantage without the corresponding use of other features. As such, the foregoing description should be considered as merely illustrative of the principles, teachings and exemplary embodiments of this invention, and not in limitation thereof.