Browse Prior Art Database

High performance data format conversion using semantic mapping model and canonical data formats

IP.com Disclosure Number: IPCOM000125715D
Original Publication Date: 2005-Jun-14
Included in the Prior Art Database: 2005-Jun-14
Document File: 4 page(s) / 49K

Publishing Venue

IBM

Abstract

High performance data format conversion using semantic mapping model and canonical data formats

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 4

High performance data format conversion using semantic mapping model and canonical data formats

An integration scenario typically enables a number of existing systems to make requests against one another, it is often necessary for each message that represents a request, and each message that represents a reply to have its format converted from the format used in the sending system to the format used in the receiving system. This is because each system typically uses its own data format. So in the diagram below, System A is making a request on System B which is replying with a result message. The message in either direction needs to be converted so the receiving system understands it.

Format that is readable by System B

    A format converter is a special piece of mapping code that needs to be developed. This requires human analysis to define the mapping.

    As the number of communicating systems increase, the number of converters required increases at an unmanageable rate ((n-1) factorial) per message. For example, if there were five different systems making requests on each other, you could potentially need (4+3+2+1) = 10 - pairs of converters for each message!

    To combat this escalation in the number of converters, some companies use a canonical data format as an intermediary data format. So the message is converted from the sending format to a canonical format, and then from the canonical format to the receiving system format. The purpose is to reduce the number of different data converters that need to be written (this becomes (n+1)). The downside is that at runtime, the data is being translated twice, reducing the system performance. This publication suggests a model driven approach to get the development time benefits of the canonical data approach, with the runtime performance of the direct conversion approach.

  In brief, the developer of the converter, defines the mapping relationship between the
1.

application specific message format and the canonical format for each message. the developer specifies two application specific messages that need a converter

     Format that is readable by System A

System

A

Converter

System

B

Converter


2.

[This page contains 4 pictures or other non-text objects]

Page 2 of 4


3.

specific messages and the canonical format and determines the direct mapping.

Here is an example of this idea working ...

    Consider a message that sends the date. It is agreed that the canonical format of the date is ccyymmdd (for example, 20041103 for the 3rd November 2004).

Application1 uses a format of ddmmyy Application2 uses a format of mmddyy Application3 uses a format of ddmmccyy Application4 uses a format of mmddccyy

The mapping between the canonical and application specific formats would be


...

the autogenerator program examines the mapping between the two application

Canonical

CC

YY MM

DD

Canonical

CC

YY MM

DD

Application1

DD MM

YY

Application1

DD MM

YY

Calculate from YY

Calculate from YY

Canonical

CC

YY MM

DD

Canonical

CC

Y...