WO2000046683A2 - Apparatus and method for data conversion in a computer network - Google Patents

Abstract

Conversion of a data in a varying types of variable field message to fixed format messages. The variable field message has a varying length and fields of varying types of data. The corresponding fixed format message has fields of a fixed data type and length, which facilitates parsing and processing data from the variable field message.

Description

APPARATUS AND METHOD FOR DATA

CONVERSION IN A COMPUTER NETWORK

REFERENCE TO RELATED APPLICATION

The present application is related to the U.S. patent application of John Bamforth, Glen Huber, Kevin Buckley, Aravinda Shenoy, Ken Thorpe, Sudha Akshayakumar, and

Srinivas Karra, Serial No.09/246,507, filed on February 8, 1999, and entitled "Apparatus and

Method for Data Conversion in a Computer Network," which is incorporated herein by reference as if fully set forth.

FIELD OF THE INVENTION The present invention relates to an apparatus and method for performing conversion of data between machines in a computer network.

BACKGROUND OF THE INVENTION A computerized reservation system (CRS) traditionally has provided a communications network for travel agents or other persons to book airline reservations. Other companies may interface their computer systems with a CRS to make information concerning their services available via the CRS. For example, a hotel company may interface its reservation system with a CRS so that when a person books an airline reservation, he or she may also make a hotel reservation through the same network.

CRS's typically use a complex protocol for identifying and transferring data. Other companies desiring to interface their computer systems with a CRS, therefore, may find it difficult or expensive to modify their computer systems to accommodate the complex protocol of a CRS. This situation may discourage other companies from interfacing their computer systems with a CRS, which limits the available information via that network.

Accordingly, a need exists for data conversion in a CRS or other computer network. SUMMARY OF THE INVENTION

An apparatus consistent with the present invention converts message formats. The apparatus receives an input message formatted according to one of a plurality of variable field protocols, and it identifies a type of protocol for the input message among the plurality of variable field protocols and data types for fields of the input message. The apparatus assembles an output message having multiple fields defined by a fixed format and associates data from the input message to specified fields in the output message based on the identified data types and the identified type of protocol.

A method consistent with the present invention converts message formats. The method receives an input message formatted according to one of a plurality of variable field protocols, and it identifies a type of protocol for the input message among the plurality of variable field protocols and data types for fields of the input message. The method assembles an output message having multiple fields defined by a fixed format and associates data from the input message to specified fields in the output message based on the identified data types and the identified type of protocol.

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings are incorporated in and constitute a part of this specification and, together with the description, explain the advantages and principles of the invention. In the drawings, FIG. 1 is a diagram of an exemplary computer network in which systems consistent with the present invention may be implemented including multiple CRS's;

FIG. 2 is a diagram of an exemplary apparatus for performing data conversion; FIG.3 A is a data structure diagram representing an example of a correlation between a first variable field protocol and a fixed field protocol; FIG. 3B is a data structure diagram representing an example of a correlation between a second variable field protocol and a fixed field protocol;

FIG.4A is a diagram of a linked list of conversion functions for translating particular types of variable field messages;

FIGS. 4B and 4C are flow charts of a process for performing data conversion from multiple types of variable field protocols to a fixed field format;

FIG. 5 is a diagram of an exemplary apparatus for performing load balancing; FIG. 6 is a flow chart of a process for a client machine to interface with server machines performing load balancing; and FIG. 7 is a flow chart of a process for server machines performing load balancing to interface with a client machine.

DETAILED DESCRIPTION

The following detailed description of the invention refers to the accompanying drawings. While the description includes exemplary embodiments, other embodiments are possible, and changes may be made to the embodiments described without departing from the spirit and scope of the invention. The following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims and their equivalents. FIG. 1 is a diagram of an exemplary network 100 including multiple CRS's. CRS's are networks permitting access to, for example, travel-related information for making reservations or obtaining such information, and CRS's may use and provide other types of information, depending upon the computer systems interfaced with a particular CRS or the information accessible by the CRS. CRS's are also referred to as computer reservation systems or central reservation systems. In European countries, for example, CRS's are often referred to as global distribution systems. The term "computerized reservation system" and the abbreviation "CRS" are intended to encompass computerized reservation systems, computer reservation systems, central reservation systems, and global distribution systems. Examples of CRS's include those known by the following trademarks and companies: SABRE; AMADEUS; WORLDSPAN; SYSTEM ONE; APOLLO; GEMINI; GALILEO; and AXESS.

Network 100 illustrates how customers or service providers may be linked together through a CRS 112 or 126. For example, customer machines 101 and 102 may represent machines located at particular corporations or other entities for providing travel-related and other services for that corporation or entity. Customer machines 101 and 102 are typically interfaced through a frame relay 103 and a router 104 to a server machine 105. Router 104 provides for routing of a protocol over frame relay 103 for long distance communication. Frame relays and routers are known in the art. Server machine 105 is typically interfaced through a universal data router (UDR) 106 to a network 110. UDR 106 may include several servers, as explained below, for performing data conversion for server 105 to communicate with a CRS, for example, CRS 126. Network 1 10 may represent a private network such as the Societe Internationale Telecommunications Aeronautiques (SIT A) network. Network 110 interfaces UDR 106 with a front end processor

111, which provides an interface to a CRS 112. CRS's usually include a front end processor, which are known mainframe components, providing functionality for interfacing the CRS with a network. Customer machines 101 and 102 may also be interfaced with other CRS's 126 through UDR 106. Therefore, when a person at customer machine 101 or 102 desires to, for example, book a travel-related reservation or access other types of information, a communications link is established through the various elements between the customer machine and CRS 112 or 126.

In addition, network 110 may interface travel agent machines with CRS 112 or 126. In particular, network 110 may interface a local area network (LAN) 113 connected to travel agent machines 114 and 115. Travel agent machines 114 and 115 may also be linked into

CRS 112 or 126, in which case network 110 may interface token ring LAN 113 through an international telephone or computer network (not shown). Travel agent machines and LANs are known in the art.

Other companies or service providers may also provide information available via CRS 112. They provide such information by interfacing a service provider machine or other computer systems 124 and 125 through UDR 120 to front end processor 111. UDR 120, which may include several servers as explained below, provides data conversion to interface the computer systems of service provider machines 124 and 125 with the protocol used by CRS 112. Alternatively, service provide machines 124 and 125 may interface with UDR 106 or CRS 126.

Data Conversion Data conversion is useful, for example, for converting messages in a variable field format into a fixed format, making it easier for service providers to communicate electronically with a CRS that employs a variable field message format. CRS's typically operate using a variable field protocol, which is complex. Examples of variable field protocols include Edifact protocol and Slash data protocol. A challenge for companies operating CRS's who want to add other computer systems to the CRS involves making it cost-effective for the other computer systems to interface with data in the variable field protocol. A data conversion explained below for converting from variable field protocols to fixed format messages provides an advantage of reducing expense and time for a service provider or other company to connect its computer system with a CRS in comparison to communicating directly with data in the variable field protocol. The availability of information in a fixed format message, rather than having to communicate directly with data in variable field protocol, significantly reduces the complexity of connecting computer systems with the CRS. Connecting other computer systems with a CRS increases the information available through the CRS and hence may increase the usefulness of the network including the CRS and the associated systems.

FIG. 2 is a diagram of a data converter 201 for performing data conversion. This conversion may be performed, for example, in UDR 120 between CRS 112 and service provider machines 124 and 125 shown in FIG. 1. As shown in FIG. 2, the conversion generally occurs between a client machine 207 and server machine 204. Client machine 207 interfaces a plurality of terminals 208, 209, and 210 with data converter 201. Client machine

207 may represent, for example, a computer system of a service provider, for example, service provider machine 125, providing travel-related services or access to other information, and terminals 208, 209, and 210 may represent computer terminals for users to interact with the computer system, for example, client machine 207. Server machine 204 interfaces data converter 201 with a CRS 205 and possibly another network 206.

Alternatively, data converter 201 may communicate directly with a CRS as shown by the dashed line.

Data converter 201 includes a processor 203 connected to a memory 212, typically storing a function library 202 for retrieving particular software functions or scripts for performing data conversion depending on the segments or fields within a received message and also typically storing a linked list 211, explained below, containing code for use in conversion of data. Memory 212 may also store an application 213 for controlling processor 203 to perform data conversion using function library 212 or linked list 211.

As identified above, CRS's, such as CRS 205, typically use a known protocol such as the Edifact (electronic data interchange for administration, commerce and transport) protocol or standard. Various versions of the Edifact protocol exist, such as those known as

IOTA and UN standards, and the Edifact protocol is used generally for processing data for travel, banking, and industrial purposes. An example of the Edifact protocol is explained in the following document, which is incorporated herein by reference: Henry Schlieper, "Henry's Yellow UN EDIFACT Book; Introduction to UN/EDIFACT Messages," 10th revised issue (October 1996). The term "Edifact" in this description is intended to cover any version of the Edifact protocol used for any purpose.

Slash data is a another example of a variable field protocol used by CRS's. Slash data protocol was developed for use by the Worldspan CRS, and it includes an alphanumeric string with segments or fields separate by slash ("/") symbols. With reference to FIG.2, server machine 204 processes, for example, data formatted according to the Edifact or Slash data protocol, which are complex. Client machine 207, on the other hand, may use its own protocol for the data on which it operates, particularly if client machine 207 represents the computer system of a service provider that does not support the CRS protocol. Data converter 201 provides a fixed format message to client machine 207. Thus, data converter 201 may provide a more simple interface for client machine 207 such that client machine 207 need not analyze a message in the complex Edifact, Slash data, or other variable field protocol.

The Edifact and Slash data protocols are in some respects complex because they include variable fields. In other words, a particular type of data may appear in different fields depending upon each particular Edifact or Slash data message, which are data formatted according to the Edifact or Slash data protocols, respectively. In general, a variable field message includes data formatted according to a variable field protocol. Variable field messages may not be of fixed length and, depending on the data to be transmitted, the length of variable field messages may change. Thus, a machine receiving a variable field message cannot necessarily determine that certain data is of a particular type because of the field in which it exists. In order to understand a variable field message, a machine typically has to analyze each segment of data in the message to determine the type of data. A fixed format message is a record or other data structure in which each particular field is known or predefined so that in a stream of data, for example, each field has a certain length and type of content. With data in a fixed format message, therefore, a machine need only, for example, count bytes to determine fields and datatypes. In a fixed format message, the data for each segment is typically at a particular position or offset in the message, which facilities a customer's ease in processing the data and may result in a faster rate of data manipulation than if the customer were to analyze a variable field message.

A fixed format message data structure may be of fixed length for each type of variable field message. A structure for a fixed format message is typically defined depending on a particular variable field message and data required by a customer or a particular application. For each variable field message data structure, one or more fixed format messages may be defined. A fixed format message may be defined by analyzing the variable field message data structure for each type of message and may depend upon the size and characteristics of the messages. The description of data fields for the structure of a fixed format message may change depending on the type of data received or transmitted. It is possible to define one fixed format message for all variable field messages. However, that fixed format message would typically be large, containing fields that may not be used by many variable field messages and potentially adversely affecting processing speed because of its size. Therefore, it may be more advantageous to define a fixed format message for a group of variable field messages, for example, ten to fifteen messages for one fixed format message.

FIG. 3 A is an example of a data structure 300 illustrating a correlation between segments of an Edifact or other variable field message and corresponding fields of a fixed format message. There are different types of Edifact messages and examples include, but are not limited to, the following: Availability Request Message (AVLREQ), Availability Response Message (AVLRSP), Profile Request message (PROREQ), Profile Response Message (PRORSP), Reservation Request Message (RESREQ) and Reservation Response Message (RESRSP). The letters within each box in FIG. 3A represent a known segment of an Edifact message, and each box has a predefined length in bytes. The linking of the boxes illustrates how the fields are linked together and a definition of each one. The number nine in the box for the group 1 (GRΪ) segment means that the corresponding group of three segments (ODI, TVL, CNX) are repeated nine times. The number four in the box for the group 2 (GR2) segment means that the corresponding segment (TVL) is repeated four times. This example thus illustrates how variable fields of an Edifact or other variable field message may be translated into a fixed format message so that a system reading such a message knows the type of data in each field and its length. Table 1 provides an explanation of each thee-letter Edifact code in the data structure of FIG. 3. TABLE 1 code meaning UNB interchange header

UNH message header

MSG message segment

ORG origination of request details

EQN number of units RPI related product information

CRI consumer reference information

SSR special requirements details

ODI origination and destination details

TVL travel product information CNX connection details

UNT message trailer

UNZ interchange trailer

FIG. 3B is a data structure diagram 301 representing an example of a correlation between Slash data and a fixed format message. The letters within each box in FIG. 3B represent a known segment of a Slash data message, and each box has a predefined length in bytes. The linking of the boxes illustrates how the fields are linked together and a definition of each one. Table 2 provides an explanation of each Slash data code in the data structure of FIG. 3B.

TABLE 2 code meaning

SELL-ORG.PARTYNAME party name

SELL-ORG.PLACEID place identification

SELL-ORG.AGENTID agent identification

SELL-ORG.AGENTPCC agent pseudo city code SELL-ORG.AGENTID2 agent identification 2

SELL-ORG.PLACEID2 place identification 2

SELL-ORG.ORIGTYP origin type

SELL-ORG.CNTRYCODE country code

SELL-ORG.CURCODE currency code FIG. 4A is a diagram of linked list 211 of conversion functions for translating particular types of variable field messages. Linked list 211 includes a plurality of nodes 401 , 402, and 403. Each of the nodes identifies a particular type of a variable field message, such as Edifact or Slash data. A plurality of sub-nodes are associated with each node, each sub- node containing code for executing conversion functions for the corresponding variable field message. The code may be stored in memory 212. For example, node 401 includes sub- nodes 404, 405, and 406; node 402 includes sub-nodes 407, 408, and 409; and node 403 includes sub-nodes 410, 411, and 412.

The system stores addresses of each node 401, 402, and 403 associated with the particular types of variable field message, and those addresses may be stored in memory 212. Upon determining a type of received variable field message, the system obtains the address of the appropriate node and, using the address, loads the node for that type of message. By loading the appropriate node, the system traverses the corresponding sub-nodes in order to perform the conversion functions for that type of variable field message. Therefore, by using the linked list of conversion code, the system may convert different types of variable field messages by locating the appropriate node in linked list 211.

FIGS. 4B is a flow chart of a process 413 for performing data conversion from multiple types of variable field protocols to a fixed field protocol. Under control of application 213, processor 203 (FIG. 2) retrieves software functions, referred to as scripts, from function library 202 or linked list 211 for performing data conversion. For example, to convert each type of fixed format message one or more scripts may be used to perform the data conversion. An advantage of using scripts, or similar software processing such as code within sub-nodes of a linked list, is that they may be modified and reloaded without a modification to the corresponding machine code. Processor 203 may compile scripts or other conversion functions at run time and, depending on the data received, it may select the corresponding script or other software function, such as a node in linked list 211, and assemble a fixed format message from data in a variable field message.

As shown in FIG.4B, processor 203 first receives a variable field message, typically including protocol information, from a CRS or other computer system (step 414). It determines a type of the variable field message based on predefined criteria such as, for example, requirements for the Edifact or Slash data protocol (step 415). Upon identifying the type of variable field message, processor 203 obtains an address for the corresponding node in linked list 211 for that data type, and it loads the node (step 416). Processor 203 traverses the conversion functions in the sub-nodes of the node in order to perform the functions necessary to convert that type of variable field message and associate the data from the input message to an output message (step 417).

FIG. 4C is a flow chart of a process 418 illustrating particular steps for conversion of a variable field message, and process 418 may correspond with step 417. In process 418, processor 203 reads a segment or field in the message (step 419), and it determines or identifies the type of data in that segment or field (step 420). The determination or identification may involve using the type of message, and it may also involve downloading predefined software functions from function library 202 or linked list 211 to analyze particular message segments or fields. Processor 203 determines the location of that type of data in the corresponding fixed format message (step 421), which is typically predefined so that it knows the structure and format of that type of message. Processor 203 may also remove unnecessary protocol information from the data (step 422). The protocol information is generally not required in the fixed format message, as the size and data type of the fields may be predefined or known. Processor 203 assembles the fixed format message and maps data from the Edifact or other variable field message to the fields in the fixed format message (step 423) by positioning the data, typically without the protocol information, in the corresponding fields for that data in the fixed format message.

Processor 203 determines if the variable field message contains more segments or fields to process (step 424). If so, it may repeat steps 419-423 to process those segments or fields. Once the message has been translated and the fixed format message has been assembled, processor 203 sends the assembled fixed format message to a client machine or other computer system or network (step 425), and the system may send it in serialized form.

Examples of Data Conversion The following provides examples of a conversion between two variable field messages and fixed format messages. The first example illustrates a correlation between an Edifact message and a fixed format message, and the second example illustrates a correlation between a Slash data message and a fixed format message. These two types of messages typically require different conversion functions, and those functions may be stored in sub- nodes of linked list 211. Therefore, by accessing the appropriate nodes in linked list 211 for conversion of Edifact or Slash data messages, a system may retrieve the necessary functions for conversion of the message. These examples are provided for illustrative purposes only. Any type of fixed format message may be defined for an Edifact, Slash data, or other variable field message. The following is example of a correlation between an Edifact message and a fixed format message. An example of an Edifact message availability request is shown in Table 3. TABLE 3

UNB+UN: 1 AALARES:IEDI+XXXX:IEDI+920130: 1330+SES0001 ++AVRL1+E'

UNH+l+AVLREQ:95:l :IA+57482()'

MGS+L29^* ORG+AA:HDQ+31599253:A0B0+++l+US'EQN+4:9*2:10'

CRI+6:8*6:10'

ODI+DFW*MBJ^*

TVL+24121995 : 1115+DF W*MB J+DL++++BCO'

CNX+MIA' ODI+MBJ*DFW

TVL+ 12011995:1300+MB J*DF W+DL++++B CO'

CNX+MIA'

UNT+12+1'

UNZ+1+SES— 1— 1' The Edifact message shown in Table 3 contains twelve segments such as, for example, UNB and UNH. Each segment may have multiple composites, each composite separated by a "+" symbol. Each element inside a composite may be separated by a ":" symbol. If a segment contains repeating elements, they may be separated by a "*" symbol. The data inside an Edifact or other variable field message may vary depending on the type of message and the required information.

The data in Table 4 shows an example of a correspondence between a fixed format message and the first three segments (UNH, UNB, MSG) of the Edifact message shown in Table 3. Table 4 provides the data field definitions in the first column along with the offset and the size of the data. The other segments may be defined in a similar manner. All data fields may be null terminated to obtain the defined length. For example, the first element in this data structure has a data field size of "5." The data is "UN" and the rest of the field includes three null characters (for example, "0") to obtain a five character field. Other characters may be used to terminate fields. Accordingly, the following is a serialized version of the first five fields of fixed format message shown in Table 4: "UN00010AALARESOOOOIEDIOXXXXOOOOOOO". The remaining fields may be attached in a similar manner by using null termination to obtain the appropriate field lengths.

TABLE 4 fixed format Edifact segment field length data

AVRQ-UNB.CTRLAGNCYCODE Size: 5 'UN'

AVRQ-UNB.SYNTAXVERNO Size: 2 T

AVRQ-UNB.LNTAPPTITLE Size: 11 'AALARES'

AVRQ-UNB.INTADDRVERSION Size: 5 ^•IEDΓ A VRQ-UNB . APPENTITYTITLE Size: 11 'XXXX'

AVRQ-UNB.ADDRVERSION Size: 5 ^•IEDΓ

AVRQ-UNB.DATEGMT Size: 7 '920130'

A VRQ-UNB .TIMEGMT Size: 5 '1330'

AVRQ-UNB.INTCTLREF Size: 15 'SES00010001' AVRQ-UNB.APPASSCID Size: 15 'SESoooiooor

AVRQ-UNB.FSEID Size: 15 'AVLR1'

AVRQ-UNB.ASSOCCODE Size: 2 Έ

AVRQ-UNH.MSGREFNO Size: 14 T

AVRQ-UNH.MSGTYPE Size: 7 'AVLREQ' AVRQ-UNH.MSGVERNO Size: 3 ^•95'

AVRQ-UNH.MSGRLSNO Size: 2 '1'

AVRQ-UNH.CNTLAGENCY Size: 3 'IN

AVRQ-UNH.COMACESREF Size: 18 ^•574820'

AVRQ-MSG.BUSFUNCCODE Size: 4 T AVRQ-MSG.MESSFUNCCODE Size: 4 '29'

AVRQ-MSG.RESPCODECNT Size: 4 '0'

AVRQ-MSG-RESPCODE.RESPTYPE Size: 3 ^•0'

AVRQ-MSG-RESPCODE.RESPTYPE Size: 3 '0'

AVRQ-MSG-RESPCODE.RESPTYPE Size: 3 ^•0' AVRQ-MSG-RESPCODE.RESPTYPE Size: 3 '0'

AVRQ-MSG-RESPCODE.RESPTYPE Size: 3 ^■0' The following is example of a correlation between a Slash data message and a fixed format message. Table 5 includes an example of a Slash data message for a "Sell message for Car," used by, for example, a car rental company in conjunction with renting a car.

TABLE 5 000003/NW 52102500010SC/VCZZ/CF 12348-

001/CYMSPT01/DA20APR90/RD21APR90/VTLCAR/ID904348/123456/EXY/DOE47/ DT1300/SIBIG RED

CAR/TA0600/CD434545/RTQ/CUUSD/BR10.99/MTMI/FM200/MC0.98 RCBEST/FM 200/FLTWOl/WCY/A D 1901 S OAK ST,HOMETO WN MN 54543/NMSMITH,BILL/SQSKI SIX

BYC/GUCCV123213212321254433EXP01-

90/FTNW56543324345657/IT9899789798798/SSFRILLY/VOWRT23418659K/CPW38 II43234498/FX65432 2157689/BS00001/TC12345678/BC5VN1/AIBT/CTMKC/STMO/COUS+ A Slash data message includes field identifiers, field separators and data. The field separators are slash ("/") symbols. Each field has a two or three letter identifier. In the example shown in Table 5, the "/VC" identifier is the Associate code field, which corresponds with the PARTYNAME of the ORG segment in a fixed format; the "/TC" identifier is the IATA number from agent sign on into the Worldspan CRS and it corresponds with the AgentID of the ORG segment in the fixed format; the "/BS" identifier is the

Booking source and it corresponds with the AgentID2 of the ORG segment in the fixed format; and the "/BC" identifier refers to a Pseudo city code and it is the AGENTPCC of the ORG segment in the fixed format.

With Slash data, a set of tables is used for every type of message to be received or sent defining the data fields used in that message. For example, Table 6 illustrates a definition of fields having fixed lengths for each Slash data segment. The data in the fields in Table 6 may be serialized in a same manner as described with respect to Table 4, using nulls appended to data as required to make each field match its defined length. - I -

TABLE 6 fixed format

Slash data segment field length data

SELL-ORG.PARTNAME size: 36 ^•ZZ' SELL-ORG.PLACEID size: 26

SELL-ORG.AGENTID size: 10 '12345678'

SELL-ORG.AGENTPCC size: 10 ^•5VN1'

SELL-ORG.AGENTID2 size: 10 '00001'

SELL-ORG.PLACEID2 size: 26 SELL-ORG.ORIGTYP size: 4

SELL-ORG.CNTRYCODE size: 4 'US'

SELL-ORG.CURCODE size: 4

Table 7 further explains the data in the data structure defined in Table 6. In particular, the name of the field corresponds to the fixed format field name; the length is the size of the field; the type defines the data type; and the mandatory or optional field indicates whether in the fixed format that field is required. If mandatory, that field will be in the fixed format data message by default. Values column provides the possible values for each field and the data corresponding to that. The last column provides the corresponding Slash data field.

TABLE 7

Fields Length Type Mand/Opt Values Slash/Data Field

Format ORG O Origin of Request Begin Party Name 36 Char o Name of supplier of service - /VC ex AA, ZE, MC, etc

Place ID 1 26 Char o IATA airport/city code of /TC delivering system

Agent ID 1 10 Char o ARC/IATA identification /TC code assigned to a travel agent

Agent In 10 Char o Pseudo City Code assigned to /BC House ID a travel agent by the reservation system

Agent ID 2 10 Char o Booking source as reflected in /BS the BS- field within the Basic Airline Segment If not entered, this will be the same as Agent ID 1

Place ID 2 26 Char o ATA / IATA airport city code of travel agent, if different from the delivering system

Origin Type 4 Char o 'I' = Travel Agent

Country 4 Char o Travel Agent ISO country /CO

Code code

Currency 4 Char o ISO currency code of travel

Code agent

Format ORG

End Clustering Servers for Load Balancing

Load balancing involves assigning customers to one or more servers for performing processing for the customers. Balancing the customer load among the servers is important, for example, to maintain service to the customers and avoid downtime in which service is unavailable.

FIG. 5 is a block diagram illustrating how load balancing may be accomplished in a CRS or computer network. Machine or network 506 interfaces with client machine 501 through, in this example, four servers. These servers include server 502 servicing customer A, server 503 servicing customers A and B, server 504 servicing customers B and C, and server 505 servicing customers C and D. Each customer is thus assigned to one or more servers interfacing client machine 501 with machine or network 506. In addition, each server is typically assigned to a particular port and constitutes the address of that server, as shown by the exemplary port numbers. For example, server 502 is assigned to port 1000 (plOOO), and the other servers are assigned in this example to sequential port numbers. Each server typically includes an element, such as a software table or other data structure, for storing load levels for each of the servers, explained below. As shown in FIG. 5, servers 502, 503, 504, and 505 contain, respectively, load level tables 507, 508, 509, and 510. Each server may have a table or other data structure indicating its own load level and the load levels of all other servers. Load levels may indicate, for example, how many customers a particular server machine is currently servicing. Using the load level information provides for additional load level balancing of customer processing by, for example, routing customers through the server with the lowest load level.

Therefore, load balancing may in general be accomplished using the assignment of customers to servers machines and the load level information. In particular, as mentioned above, customers may be assigned for service to a set of the servers, and each server may store load levels of each of the servers. Customers may be serviced using the servers to which they are assigned based upon the load levels. In particular, among the servers to which they assigned, they may be services by the server with the lowest load level. If the servers to which they are assigned are unavailable, the customers may be serviced using the servers to which they are temporarily assigned during the unavailability.

Servers 502-505 may represent, for example, the UDRs explained above. With reference to FIG. 1 , client machine 501 may represent server machine 105 or service provider machines 124 and 125, and customers may represent customer machines 101 and 102, or service provider machines 124 and 125. Machine or network 506 may represent network 110, front end processor 111 in combination with CRS 112, or CRS 126. Thus, servers 502- 505 may provide, for example, data conversion necessary for customer machines 101 and 102, or service provider machines 124 and 125, to interface with CRS's 126 and 112. The load balancing achieved by servers operating consistent with the present invention may be used in any applicable computer network and for any applicable processing.

FIG. 6 is a flow chart of a process 600 for client machine 501 to interface with servers 502-504 performing load balancing. Client machine 501 contains a processor and memory for performing the load balancing function. As shown in FIG. 6, the client machine sends a "request server" message, indicating that one of the customer machines needs service by one of the servers to which the customer is assigned (step 601). The client machine may broadcast the message to the ports of servers to which the customer is assigned. The client machine determines if it received a response (step 602). If it received a response, it connects to the server specified in the response (step 603). Otherwise, if it received no response, the client machine sends a "request any server message" (step 604). The client machine broadcasts this message to the ports for all servers.

FIG. 7 is a flow chart of a process 700 for servers 502-504 to interface with client machine 501. Each of the servers contains a processor and memory for performing this process. As shown in FIG. 7, each server is in a wait state waiting for a "server request" message from a client machine through an assigned port (step 701). When the server receives a message, it determines if the message is a "request server" message, meaning that a customer assigned to that particular server requested service (step 702). If so, the server determines if it is the least loaded server, which may be accomplished by evaluating its table of server load levels (step 704). The load levels may be stored in tables 507-510 for respective servers 502-505 (see FIG.5). Load levels may constitute, for example, numerical values indicating how many customers a server is currently servicing.

If the server that received the "server request message, is the least loaded server, it sends a response to the client machine and sends to the other servers its new load level (step 706). The response indicates to the client machine that this particular server is available for servicing the customer requesting service. If the server is not the least loaded server, then it waits for another "server request" message (step 701).

If the received message was not a "request server" message, the server determines if the message is a "request any server" message (step 703). If so, the server clears its table containing the other servers load levels (step 705), and it sends a response to the client machine and sends to the other servers its new load level (step 706).

If the received message is neither of those messages, the server determines if the message is an "update other servers load level" message (step 707). If so, the server updates its table with the other servers new load levels (step 708) and waits for another message (step 708).

Additional servers may join the servers already servicing a group of customers. When a server joins the others, it may be predefined to service a group of customers and may broadcast a message to the other servers identifying itself and its load level. It then may perform the processing described above with respect to FIG. 7. While the present invention has been described in connection with a preferred embodiment, many modifications will be readily apparent to those skilled in the art, and this application is intended to cover any adaptations or variations thereof. For example, various other components for the elements shown in FIG. 1 , and different types of variable field messages and fixed format messages for data conversion may be used without departing from the scope of the invention. This invention should be limited only by the claims and equivalents thereof.

Claims

WHAT IS CLAIMED IS:

1. An apparatus for converting message formats, comprising: a memory storing an application program; and a processor coupled to the memory, the processor configured under control of the application program to: receive an input message formatted according to one of a plurality of variable field protocols; identify a type of protocol for the input message among the plurality of variable field protocols and identify data types for fields of the input message; assemble an output message having multiple fields defined by a fixed format; and associate data from the input message to specified fields in the output message based on the identified data types and the identified type of protocol.

2. The apparatus of claim 1 wherein the processor is further configured to: determine a type of the input message based on predefined criteria, and use the input message type to identify the data types.

3. The apparatus of claim 1 wherein the processor is further configured to: exclude from the output message protocol information included in the input message.

4. The apparatus of claim 1 wherein the processor is further configured to download predefined functions for determining the type of the data.

5. The apparatus of claim 1 wherein the processor is further configured to receive the variable field message formatted according to an Edifact protocol.

6. The apparatus of claim 1 wherein the processor is further configured to receive the variable field message formatted according to a Slash data protocol.

7. The apparatus of claim 1 wherein the processor is further configured to receive the variable field message from a computerized reservation system.

8. The apparatus of claim 1 wherein the processor is further configured to: access a node of a list based upon the identified type of protocol; and use functions identified by the node for associating the data from the input message to the specified fields of the output message.

9. The apparatus of claim 1 wherein the processor is further configured to generate a serialized version of the fixed format message.

10. A system for converting a variable field message into a fixed format message, comprising: a server machine; a client machine; and an apparatus, interfacing the client machine with the server machine, for converting message formats, the apparatus including a memory storing an application program and a processor coupled to the memory, the processor configured under control of the application program to: receive an input message formatted according to one of a plurality of variable field protocols; identify a type of protocol for the input message among the plurality of variable field protocols and identify data types for fields of the input message; assemble an output message having multiple fields defined by a fixed format; and associate data from the input message to specified fields in the output message based on the identified data types and the identified type of protocol.

11. The system of claim 10 wherein the processor is further configured to: determine a type of the input message based on predefined criteria, and use the input message type to identify the data types.

12. The system of claim 10 wherein the processor is further configured to: exclude from the output message protocol information included in the input message.

13. The system of claim 10 wherein the processor is further configured to download predefined functions for determining the type of the data.

14. The system of claim 10 wherein the processor is further configured to receive the variable field message formatted according to an Edifact protocol.

15. The apparatus of claim 10 wherein the processor is further configured to receive the variable field message formatted according to a Slash data protocol.

16. The system of claim 10 wherein the processor is further configured to receive the variable field message from a computerized reservation system.

17. The system of claim 10 wherein the processor is further configured to: access a node of a list based upon the identified type of protocol; and use functions identified by the node for associating the data from the input message to the specified fields of the output message.

18. The system of claim 10 wherein the processor is further configured to generate a serialized version of the fixed format message.

19. A computer-implemented message format conversion method, comprising: receiving an input message formatted according to one of a plurality of variable field protocols; identifying a type of protocol for the input message among the plurality of variable field protocols and identifying data types for fields of the input message; assembling an output message having multiple fields defined by a fixed format; and associating data from the input message to specified fields in the output message based on the identified data types and the identified type of protocol.

20. The method of claim 19 wherein the receiving step includes determining a type of the input message based on predefined criteria, and the identifying step includes using the input message type to identify the data types.

21. The method of claim 19 wherein the assembling step includes excluding from the output message protocol information included in the input message.

22. The method of claim 19 wherein the identifying step includes downloading predefined functions for determining the type of the data.

23. The method of claim 19 wherein the receiving step includes receiving the variable field message formatted according to an Edifact protocol.

24. The method of claim 19 wherein the receiving step includes receiving the variable field message formatted according to a Slash data protocol.

25. The method of claim 19 wherein the receiving step includes receiving the variable field message from a computerized reservation system.

26. The method of claim 19, further including: accessing a node of a list based upon the identified type of protocol; and using functions identified by the node for associating the data from the input message to the specified fields of the output message.

27. The method of claim 19 wherein the assembling step includes generating a serialized version of the fixed format message.

28. A method for load balancing of processing provided by multiple server machines interfaced with a client machine servicing multiple customers, comprising the steps of: assigning each of the customers to a set of the server machines; storing load levels of each of the server machines; and servicing the customers using the server machines to which they are assigned based upon the load levels, and, if the server machines to which they are assigned are unavailable, servicing the customers using the server machines to which they are temporarily assigned during the unavailability, wherein the servicing step further includes: receiving an input message formatted according to one of a plurality of variable field protocols; identifying a type of protocol for the input message among the plurality of variable field protocols and identifying data types for fields of the input message; assembling an output message having multiple fields defined by a fixed format; and associating data from the input message to specified fields in the output message based on the identified data types and the identified type of protocol.