Integration of Workflows into a Federated Database System with SQL/MED

111 pages In this work, so-called federated functions are built by interconnecting function calls to different application systems in a distributed and heterogeneous environment. These federated functions are realized as workflows, whereas the activities of the workflows are responsible for invoking...

Full description

Bibliographic Details
Main Author: Wagner, Ralf
Other Authors: Anwendersoftware (IPVR), <wagnerrf@rupert.informatik.uni-stuttgart.de>
Format: Thesis
Language:English
Published: Stuttgart, Germany, Universität Stuttgart 2001
Subjects:
DML
Online Access:http://www2.informatik.uni-stuttgart.de/cgi-bin/NCSTRL/NCSTRL_view.pl?id=DIP-1888&engl=1
Description
Summary:111 pages In this work, so-called federated functions are built by interconnecting function calls to different application systems in a distributed and heterogeneous environment. These federated functions are realized as workflows, whereas the activities of the workflows are responsible for invoking the single functions. The workflows will be integrated into a federated database system by means of wrappers, and table functions respectively. For the wrapper approach, the SQL/MED standard will be utilized, which provides the notion of foreign tables representing external data, i.e. in this case the result data of workflows. The standard provides an interface, which has to be used to implement wrapper executables that are responsible for supplying the foreign tables with external data. In contrast to SQL/MED, the table function approach is not based on such an elaborated standard because a standardized interface for the implementation of table function executables is missing. Only the DDL and DML for defining and accessing table functions is specified. When the FDBS receives a global SQL query referencing a foreign table or a table function, the associated wrapper executable or table function executable respectively are responsible for executing the correct workflow. The workflow then returns the result data from its execution and the executable has to convert and transform this data to correspond with the table format of the foreign table or the table function respectively. For every workflow a separate wrapper executable has to be implemented. Therefore, the wrapper executable will be structured and divided up into different components. As a result, only some of the wrapper components have to be reimplemented for each workflow. Some components of the wrapper can also be used to build the corresponding table function executable. In order to further decrease the efforts of implementing wrappers and table functions, a generation approach will be proposed, which minimizes the manual portion in implementing a ...