Enterprise Service Bus for persistent data
The major part of FLAM's success is due to the fact that we are able to transform the logical data contents of various physical formats of different operating systems, file systems, and processor architectures (from a bank's mainframe to the controller of a GSM mast) between the distinct worlds in such a way that the logical contents remain legible on each of the respective systems.
In the course of time, heterogeneity of computer platforms and, above all, the number of physical file formats (PS / PDS / PDSE (F, FB, FBA, …V, VB, VBA, ..., U, …) have diminished. But as a countermove, the number of logical file formats (TDA, SWIFT, SEPA, EBICS alone are 4 formate for financial transactions) is increasing continuously. We have always been trying to connect worlds. These were in the past primarily greatly differing mainframe architectures. Today we are connecting the open (distributed) world (Mac, Windows, Linux, Unix) with proprietary mainframes of IBM and other manufacturers. For the future we are planning to connect old and new applications that in fact process the same logical data but accept them in different physical representations (encodings). Our goal is, for example, to provide via our subsystem a legacy Cobol application for a booking system that takes transactions in TDA format with records in that format, even though they were originally submitted as SEPA transactions in XML format. On the other hand, we want to be able to present TDA data sets to a modern WebSphere application in a SEPA compliant XML format.
For online transactions this is already being done by infrastructure components for which the term "enterprise service bus" (ESB) has been coined. With FLAM, we are planning to provide a similar functionality for persistent data sets used with batch processing. A fundamental precondition for that is supporting up to 4 billion different element types. As of version5 one can store with a FLAM archive not only data records with lengths and data but any number of different element types with lengths, data, attrivutes, and hashcodes. This extension allows storing in a FLAM archive any kind of data structure in a neutral form. Since FLAM's architecture permits to freely choose the format when outputting an element, the same logical data can be provided in different physical representations.
The problem here is that you cannot support every single format in every product in the world with transforming to all different representations. Therefore we have set up this project in order to provide FLAM with an interpreter to enable free data conversions, an interpreter that understands a simple language by which the logical data structures and their various physical representations can be described. When reading in with FLAM one signals which physical representation the data have and when writing one can choose in turn which encoding to use for the data.
Such a description language for ESBs has been specified already as an open standard. It is our intention to adapt this open standard to FLAM. But to do so we have to extend the language so as to allow describing attributes and, above all, hash value computations for searching in FLAM archives. This will enable users to define the generating elements of a hash value and how to save it for subsequent searches.
The goal of the project is to enable FLAM by means of the multi format conversion to transparently provide resp. accept from old and new applications that read and write data through the subsystem in the adequate physical representation of the data, to store the in a neutral format, and to transparently provide them to a different application in its required format.