Schema Conversion

A schema conversion (or accounting for the differences in application semantics) is the process of changing the structure of a message and thus remapping the schema so that it is acceptable to the target system. Though it is not difficult, application integration architects need to understand that this process must occur dynamically within the integration server. For example, if a message containing accounts receivable information arrives from a DB2 system on a mainframe, it may look something like this:

 Cust_No              Alphanumeric     9 Amt_Due              Numeric   9 Date_of_Last_Bill              Date 

With the following information:

 AB99999999 560.50 09/17/98 

The client/server system created to produce the annual report receives the information and must store it according to the following schema:

 Customer_Number                Numeric   20 Money_Due                 Numeric   8 Last_Billed               Alphanumeric   9 

Clearly, the schema in the client/server system is different from the schema in the DB2 system. Moving information from the DB2 system (the source system) to the client/server system (the target system) without a schema conversion would most likely result in a system error because of the incompatibility of the formats. For the systems to communicate successfully, the information in Cust_No (which is alphanumeric and holds 9 positions) needs to be converted to all-numeric information capable of holding 20 digits or positions. All data that is not numeric (that is, letters) must be translated into numeric data. This can be accomplished either by deleting all characters when translating Cust_No to Customer_Number or by converting characters into numeric representations (A=1, B=2, and so on). This process can be defined within the rules-processing layer of the integration server by creating a rule to translate data dynamically, depending on its content and schema. Moving information from one system to another demands that the schema/format of the message be altered as the information is transferred from one system to the next (see Figure 9.6).

Figure 9.6. Translating schemas/semantics dynamically.

Although most integration servers can map any schema to any other schema, it is prudent to try to anticipate extraordinary circumstances. For example, when converting information extracted from an object-oriented database and placing it in a relational database, the integration server must convert the object schema into a relational representation before it can convert the data within the message. The same holds true when moving information from a relational database to an object-oriented database. Most integration servers break the message moving into their environment into a common format and then translate it into the appropriate message format for the target system. (As we already noted, the rules-processing engine within the integration server allows appropriate programming to take place.)