Coupling of fdbs and Wfms for Integrating Database and Application Systems : Architecture, Complexity, Performance



Descargar 30.2 Kb.
Fecha de conversión26.01.2017
Tamaño30.2 Kb.






Discusión del artículo

“Coupling of FDBS and WfMS for Integrating Database and Application Systems : Architecture, Complexity, Performance”


Autores : Klaudia Hergula y Theo Härder

(Marzo 2002)

Estudiantes : Gerardo Fernández

Pablo Werner

Índice




1 Área de Investigación 3

2 Objetivos 3

3 Motivación 3

4 Trabajos Relacionados 3

5 Enfoque 4

Modelo Propuesto 4

Puntos Débiles 5

Puntos Fuertes 5

Objetivos Cumplidos 5

Trabajos futuros 6

6 Resumen 7

Administración 7

Autonomía de los sistema de aplicaciones 7

Integración semántica 7

7 Referencias 8

1Área de Investigación

El área de investigación de este artículo es la integración de fuentes de datos heterogéneas, incluyendo acceso a través de un lenguaje de consulta genérico y vía funciones de acceso predefinidas.



2Objetivos

Presentar una propuesta de integración de funciones y bases de datos basada en un motor de workflow (WfMS) y un sistema de bases de datos federado (FDBS).

Adicionalmente comparar esta propuesta con otras arquitecturas que no utilizan un WfMS para la integración de funciones.

3Motivación

La mayoría de las empresas trabajan en ambientes de sistemas heterogéneos, donde diferentes sistemas operativos y de redes, DBSs, así como aplicaciones son usados para cubrir el ciclo de vida completo de un producto. Existen soluciones enfocadas principalmente a solucionar el problema de la heterogeneidad de la información, basadas por ejemplo en FDBS o sistemas de múltiples bases de datos, a pesar de que aún existan cuestiones sin resolver. Pero la realidad de las bases de datos está cambiando. Mientras que antes muchas empresas elegían su sistema de DB y diseñaban sus esquemas a medida, hoy en día se enfrentan con bases de datos que ya vienen incluidas en paquetes de software, los llamados sistemas de aplicaciones, a las cuales sólo es posible acceder mediante funciones predefinidas que conforman la API de dicho sistema.

Como consecuencia, la integración de la información ya no es posible, ya que a los DBs se puede acceder mediante un lenguaje de consulta genérico (SQL) mientras que los sistemas de aplicaciones solo proveen el acceso a los datos a través de funciones predefinidas.

Por lo tanto, la recuperación de información desde fuentes tan heterogéneas y encapsuladas necesita la combinación de consultas genéricas así como de acceso por funciones predefinidas.



4Trabajos Relacionados

La mayoría de los trabajos orientados a la integración de fuentes de datos heterogéneas están enfocados en la capacidad de combinar diferentes modelos de datos y sistemas heterogéneos, proveyendo una interfase que no es tan poderosa como la que brinda SQL. Trabajos como los mencionados en las referencias [7], [8] y [9] se enmarcan en soluciones basadas en mediadores o wrappers en donde la pérdida de funcionalidad de las fuentes de datos es compensada por el servidor de integración.

En el trabajo presentado por estos autores todas las fuentes de datos que no pueden ser accedidas mediante SQL son integradas por el WfMS, mientras que las fuentes de datos que sí pueden ser accedidas mediante SQL son gestionadas por el FDBS. En consecuencia, el FDBS debe comunicarse con el WfMS para acceder a fuentes no SQL.

Es en este contexto que surge la propuesta de los autores que consiste en una solución específica para soportar la interoperabilidad entre el FDBS y el sistema de workflow.


5Enfoque




Modelo Propuesto

La arquitectura propuesta por los autores consta de tres niveles. El primer nivel está referido a los usuarios y aplicaciones que reciben una vista homogénea de los datos.; mientras que al tercero lo conforman las fuentes heterogéneas de datos.

E
l nivel central o servidor de integración está formado por dos elementos centrales : un FDBS que realiza la integración de bases de datos y un WfMS que integra funciones invocando y controlando el acceso a las funciones predefinidas de los sistemas de aplicaciones.

Arquitectura de integración
De esta forma, el procesador de consultas del FDBS, evalúa las consultas del usuario y la parte que requiera el acceso a funciones externas son asignadas al wrapper el cual activa al WfMS. El resto de la consulta es procesada por el FDBS.

La integración de funciones significa proveer al sistema de funciones federadas que implementen las llamadas a las funciones locales combinando su funcionalidad y de forma transparente para el usuario.

Como ejemplo de función federada se presenta la función BuySuppComp, que sintetiza en un solo paso, una serie de cinco invocaciones a funciones locales por parte de un usuario.

El grafo que representa el mapeo de la función federada a las funciones locales es el siguiente:




El motivo por el cual se eligió un motor de workflow para realizar la integración de funciones es que la herramienta ya existe, no es necesario implementarla. Además se argumenta que el concepto básico de un motor de workflow coincide con el grafo de mapeo y soporta escenarios de mapeos muy complejos. Por otra parte permite el acceso transparente a diferentes plataformas, oculta las interfaces a los sistemas de aplicaciones a ser integrados y trabaja con diferentes sistemas de control de errores. Por último, el mantenimiento de los mapeos implementados es mucho más fácil de mantener cuando se realiza mediante un producto workflow.


Los autores reconocen que un planteo de este tipo puede generar ciertas dudas en lo que refiere a la utilización de un motor de workflow como parte del middleware. Por lo tanto, muestran una serie de arquitecturas alternativas que sustituyen el wrapper por funciones de tabla definidas por el usuario(UDTF).
Finalmente comparan la arquitectura propuesta con otra en la cual las funciones federadas son UDTFs que consisten en sentencias SQL en cuya cláusula FROM se invoca a las UDTFs que acceden a las funciones locales.

En dicha comparación se observa que las arquitecturas en base a UDTFs tienen mejor performance y que los tiempos de procesamiento aumentan gradualmente con el aumento de funciones involucradas. Si bien los tiempos de la arquitectura propuesta (basada en WfMS) son tres veces mayores y a su vez se incrementan cuando se involucran más funciones, no son inaceptables y mejoran cuando se procesan actividades paralelas. Además soportan todos los tipos de mapeo, tienen mayor escalabilidad y facilidad de mantenimiento. En cambio, la arquitectura basada en UDTFs no permite realizar iteraciones y las sentencias SQL se vuelven más complejas y confusas con el aumento del número de funciones locales involucradas.



Puntos Débiles

Como puntos débiles del artículo se observa que el modelo propuesto sólo se aplica a operaciones de consulta de datos.

Tampoco se consideran aspectos relativos a la seguridad y al acceso concurrente a los sistemas de aplicaciones.

Puntos Fuertes

En los puntos fuertes se puede mencionar el hecho que intenta resolver una amplia integración que abarca bases de datos y sistemas de aplicación. Por otro lado utiliza el concepto de utilizar tecnologías y productos ya existentes y no implementar todo nuevo (no reinventar la rueda).

Por último los autores son conscientes que su propuesta puede generar ciertas resistencias, por lo cual en lugar de ignorarlas, evalúan otras alternativas y las comparan con la propia, marcando ventajas y desventajas de cada una.


Objetivos Cumplidos

Creemos que los objetivos planteados por los autores fueron alcanzados, dado que se prueba la factibilidad técnica de la arquitectura de integración propuesta.

Además se implementó un prototipo de la arquitectura basada en un motor de workflow y otro prototipo basado en UDTFs los cuáles permitieron realizar las pruebas de performance antes mencionadas.


Trabajos futuros

Los trabajos futuros que se proponen están orientados a la optimización de consultas, control de acceso a los sistemas de aplicaciones y administración de las funciones federadas.


6Resumen

A continuación remarcamos los puntos que consideramos, en base a los conceptos adquiridos en el curso, los autores deberían haber desarrollado para que su propuesta de integración fuera completa.



Administración

La idea principal de los autores para la integración de funciones es proveer de las llamadas funciones federadas que implementan llamadas a las funciones locales de cada uno de los sistemas de aplicaciones.

Sin embargo, en ninguna sección del artículo, se establece quién o quiénes son los responsables de componer, mantener y administrar estas funciones federadas.

Por los conceptos vistos a lo largo del curso nosotros concluimos que la propuesta de los autores está orientada a un FDBS fuertemente acoplado en donde existe la presencia de un súper usuario quién se encarga de mantener la federación y componer estas funciones federadas.



Autonomía de los sistema de aplicaciones


En el artículo no se discute las características de autonomía de los sitios locales, que en este caso son sistemas de aplicaciones. No se establece si estos sistemas que participan en la integración pueden ejecutar sus operaciones locales sin interferir con la ejecución de los pedidos que lleguen desde la federación (autonomía de ejecución) y si tienen la capacidad de decidir cuándo y como responder a estos pedidos (autonomía de comunicación).


Con respecto a la autonomía de participación pensamos que no existe, dado que es el súper usuario encargado de componer las funciones federadas quién establece las funcionalidades (funciones locales) que deben ser compartidas por cada sistema independiente.
La única afirmación que podemos realizar es que, por su naturaleza, los sistemas de aplicaciones tienen autonomía de diseño ya que encapsulan sus bases de datos y tienen libertad de elegir su modelo de datos, lenguaje de consulta, implementación, etc.

Integración semántica

La crítica más notoria que realizamos al artículo es que, dado que su objetivo es realizar una integración de bases de datos y funciones, en ningún momento los autores ponen de manifiesto los problemas a los cuáles hay que enfrentarse a la hora de integrar funciones.



Su propuesta solamente comenta que la integración de funciones se realiza mediante la invocación de las funciones locales de los sistemas de aplicaciones referenciados.
Sin embargo todos los problemas que hemos visto a lo largo del curso y se presentan a la hora de integrar esquemas y datos: como establecer correspondencias semánticas, resolver heterogeneidades, etc, también están presentes y deben ser resueltos a la hora de integrar funciones.

7Referencias



[1] Härder T., Sauter G., Thomas J.: The Intrinsic Problems of Structural Heterogeneity and an Approach to their Solution. VLDB Journal 8:1 (1999) 25-43
[2] Sheth A.P., Larson J.A.: Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases. ACM Computing Surveys 22:3 (1990) 183-236
[3] SAP AG: SAP R/3. (2001)

http://www.sap.com/solutions/r3/

[4] Hergula K., Härder T.: A Middleware Approach for Combining Heterogeneous Data Sources – Integration of Generic Queries and Predefined Function Access. Proc. 1st Int. Conf. on Web Information Systems Engineering, Hongkong (2000) 22-29
[5] Leymann F., Roller D.: Production Workflow: Concepts and Techniques, Prentice Hall (2000)
[6] ISO & ANSI: Database Languages – SQL – Part 9: Management of External Data, Working Draft (2000)
[7] M. Tork Roth, P. Schwarz: Don’t Scrap It, Wrap It! A Wrapper Architecture for Legacy Data Sources. Proc 23rd Int. Conf. on Very Large Data Bases, Athens (1997) 266-275
[8] Levy A.Y., Rajaraman A., Ordille J.J.: Querying Heterogeneous Information Sources Usign Source Descriptions. Proc 22nd Int. Conf. on Very Large Data Bases, Bombay (1996) 251-260
[9] Papakonstantinou Y., Garcia-Molina H., Widom J.: Object Exchange Across Heterogeneous Information Sources. Proc 11th Int. Conf. on Data Engineering, Taipei (1995) 251-260
[10] Chaudhuri S., Shim K.: Query Optimization in the Presence of Foreign Functions. Proc. 19th Int. Conf. on Very Large Data Bases, Dublin (1993) 529-542
[11] Florescu D., Levy A., Manolescu I., Suciu D.: Query Optimization in the Presence of Limited Access Patterns. Proc. ACM SIGMOD Int. Conf. on Management of Data, Philadelphia (1999) 311-322
[12] Garcia-Molina H., Labio W., Yerneni R.: Capability-Sensitive Query Processing on Internet-Sources. Proc. 15th Int. Conf. on Data Engineering, Sidney (1999) 50-59
[13] Reinwald B., Pirahesh H., Krishnamoorthy G., Lapis G., Tran B., Vora S.: Heterogeneous Query Processing through SQL Table Functions. Proc. 15th Int. Conf. on Data Engineering, Sidney (1999) 366-373
[14] Hergula K., Härder T.: How Foreign Function Integration Conquers Heterogeneous Query Processing. Proc. 10th Int. Conf. on Information and Knowledge Management, Atlanta (2001) 215-222


La base de datos está protegida por derechos de autor ©bazica.org 2016
enviar mensaje

    Página principal