9 4 Q O 3 4

S.E.P. S.E.I.T. D.G.1.T

CENTRO NACIONAL DE INVESTIGACION

Y DESARROLLO TJXNOLOGICO

cenidet DESARROLLO DE UN LENGUAJE DE COORDINACION

DE OPERACIONES DISTRIBUIDAS PARA SISTEMAS

DE INFORMACION INTEROPERABLES

T E S I S QUE PARA OBTENER EL GRADO DE

MAESTRO EN CIENCIAS DE LA COMPUTACION

P R E S E N T A

FRANCISCO PABLO MUNGUIA GAYTAN

..

CLJERNAVACA, MOR MARZO DE 1994

8 WP SISTEMA NACIONAL DE INSTITUTOS TECNOLOGICOS

entro Nacional de Investigación y Desarrollo Tecnológico

ACAtJEüIA DE LA W S T R I A EN CIENCIAS COMPUTACI(MULES

Cumnavaca, M o t . , e n m o 25 de 1994 .

Ut. Juan Manuel ficatio C a h U t o Di~ec to t d d CENIDET P z e b e n t e

ILt'n.: M.C. Lwn GatcZa M & L t e z Jede d d Depto . de Ciencia4 Computauonata

Pot &$.te conduc.to, hacemos de 4u conocún¿ento que, d a w & de habm 40- metido a t e v i 4 i ó n e t Ocabajo de tu& U a d o :

"DESARROLLO VE UN LE"€ VE ~OORDlNACloF l VE OPERACIONES VI~IBUIDAS PARA SISTEW DE INFORU4CION INTEROPERABLES"

d a m t o e t a d o p o t el L . 1 . F h a n d c o Pabto Mung& Gaytán, y habiendo cum p t ido con toda4 La5 c o m e c c i o n a que de t e indicahon, aXam04 de acuet: do en que se t e conceda t a autoh¿zaúón paila La ú n p t a i ó n de t a tu&, a d como t a decha pMa bwtentah 5u examen de gtado.

interior Internado PalmVa S/N CF! 62490

Telr: (73) 18 77 41 y (73) 12 76 13

:entro Nacional de Investigación y Desarrollo Tecnológico

SUBDIRECCION ACADEMICA

DEPTO. DE CIENCIAS COMPUTACIONALES

Cuernavaca, Mor., marzo 14 de 1994.

L.I. Francisco Pablo Mungufa Gaytán Candidato al tiraao cie Maestro en Ciencias Computacionales P r e s e n t e

Por este medio, le comunico. que su expediente escolar fue revisado, y considerando que cumple con los requisitos para sustentar el exa- me'n de grado, s e le autoriza l a impresión de su tesis.

De igual manera, le comunico que.deberá ponerse de acuerdo con los integrantes de 1a.Comisión Revisora para determinar la fec.ha. de su

. examen.

Sin otro particular, reciba;mis más sinceras felicitaciones por la á a punto de culminar, dentro de su carrera

. . ' ,

".f

f .

D O.I.+b ?IGkC\OII

p.(\gNbl !'I "" Kl3.P. e ?O " DE' *p I ' . ' S(IIiD:fi','Lh h t . .,i' /.I* '(k

C.C.P.: C.P. Delia Barba Puga - Servicios Escolares Expediente

Interior Internado Palmira S/N CI? 62490

Teh: (73) 18 77 41 y (73) 12 76 13

A mi Pareja y Maestra Yolanda AIvurez Cracks por Iodo tu Amor. Te Amo.

A mis Padres Gracias, los amo.

A mi hermana Selene Por el Guerrero que es

A mi tia Chela y Mamá Carmen Por enseñarme lo que es amor y apoyo total hacia alguien

A mis hermanos Meche y Uíises. Los amo, sigan adelante

A la Energía, por todo lo que me ha dado.

A mi mismo, por la oportunidad que me d i

Compromiso: La capacidad del Ser de mantener su intención y sus esfuerzos sobre tiempo a pesar de óbstaculos. La capacidad de no darse por vencido jamás.

AM4. Michael Powell

AGRADECIMIENTOS

Expreso mi mas sincera gratitud a mi asesor de Tesis Dr. Armando Maldonado Talamantes por todo el apoyo que me brindo a lo largo de este proyecto.

Agradesco al CENIDET la oportunidad que me brindo de haber sido alumno de la institución, reconosco a sus profesores, directivos y personal administrativo y de operación, su amistad y trabajo.

Agradesco al personal del ITAM por todo su apoyo y amistad brindada durante mi estancia de Tesis.

*

Agradesco a la Familia [barra por todo su Amor y por haberme abierto las puertas de su casa durante mi estancia en la Cd. de México.

Agradesco a Digital Equipment de México (DEC) por el apoyo financiero y material otorgado, sin el no hubiera sido posible la realización de la Tesis.

Agradesco a la Asociación Mexicana de Cultura (AMC) el apoyo administrativo otorgado, este apoyo fue el medio por el cual se pudo financiar el proyecto de Tesis.

Agradesco al CONACYT por la apoyo economico otorgado el cual sirvio de complemento financiero durante UM etapa importante del Proyecto.

Agradesco a mis compañeros de Proyecto: Joe, Gerardo, Ray, Vicky, Hugo, Yogui, Somy, Luz, El Chino y Micky. Por toda su amistad y apoyo, gracias por ayudarme (especialmente Gerardo) y por hacer mi estancia mas agradable.

Agradesco a Carlos Estrada su amistad,'su apoyo para entrar al proyecto y su apoyo para entrar en el camino de la Autorrealización.

Agradesco a la Asociación Mexicana de Metafisica, Metapsicología y Misticismo (AM4) y en forma especial a su fundador Dr. Thomas Michael Powell por sus conocimientos, los cuales fueron un factor decisivo para que este proyecto pudiera realizarse y verse concluido.

Agradesco a Victor Velasco por su amistad y apoyo.

Y finalmente agradesco a la Energia por el llamado a la Excelencia y a todos los Seres que en este tiempo y en otros tiempos me ha mandado para ayudarme a despertar (especialmente a Irma Ascencio por haber cumplido bien su Misión).

Lista de Figuras

TABLA DE CONTENIDO

Página

iv

Introducción 1

1 Contexto General del Sistema IPL

I , I Conceptos Básicos

I . I . 1 Un Modelo de Cómputo Distribuido

I . I .2

1.1.3

Algunos Sistemas de Apoyo a Aplicaciones Distribuidas

Interoperabilidad en Sistemas de Información Heterogéneos

1.2 El proyecto ELECTRA

1.2. I

I .2.2

1.2.3 El Prototipo ELECTRA

Alcances del Proyecto ELECTRA

Arquitectura Conceptual del Proyecto ELECTRA

1.3 Objetivos del Sistema IPL

I .4 El Paradigma Transaccional

6

7

11

11

12

16

17

19

1.4.1 La Noción de Transacción 19

I .4.2 Problemas Inherentes a la Autonomía Local 22

1.5 Modelos de Transacciones 23

I S.1 24

1 S.2 Un Modelo de Transacciones Multibase de Datos 26

1.5.3 El Modelo de Transacciones Flexibles 31

1.5.3.1 Alternativas 31

1.5.3.2 Dependencias 32

Modelos de Transacciones para Aplicaciones Avanzadas de BD's

I

I S.3.3 Compensabilidad

Estructura y Ejecución de las Transacciones Flexibles 1.5.4

1.5.4.1 La Estructura Funcional

1.5.4.2 Estados de Ejecución

1.5.4.3 La Ejecución de Transacciones

2 Diseño del Sistema

2.1 Particularidades del Sistema IPL

2. I . 1 Descripción del Lenguaje IPL

2. I . 1. I Componentes del Lenguaje IPL

Objetos y Tipos

Definición de Subtransacciones

Descripción de Dependencias

Estados Aceptables

2. I . I .2 El Protocolo de Atomicidad Global Basado en la

,Semántica de la Aplicación

Un Ejemplo de Programación 2. I , I .3

2.1.2 Precompilación de IPL

Fases de los Compiladores e Interpretes

2.2 Arquitectura General del Sistema IPL

2.2. I El Módulo de Traducción

Analizador Léxico

Analizador Sintáctico

Analizador Semántico

Manejador de Errores

*.Generador de Código

2.2.2 El Ejecutor de Transaccioncs Flcxibles

ii

33

34

34

35

36

38

41

41

41

42

42

44

45

46

49

54

55

55

5 1

5 1

59

59

60

61

63

El Algoritmo de Control de Ejecución

Las Primitivas de Comunicación

MonitoreoDiagnostico

3 Implantación y Pruebas

3. I Entorno de Implantación

3.1. I El Ambiente Operativo Windows

3.1.2 Herramientas Utilizadas

3.1.2.1 PCYACC

3.112.2 Borland C

3.1.3 ,InteracciÓn con Otros Modulos

3.2 Pruebas Realizadas

3.2. I

3.2.2

3.2.3 Pruebas a la Aplicación

Pruebas al Analizador Léxico, Sintáctico y Semántica

Pruebas al Ejecutor de Traisacciones Flexibles

4 Conclusiones y Lineas Futuras

Lineas Futuras

Bibliografía

Apéndice A : La Sintaxis del Lenguaje IPL

Apéndice B : La Semántica del Lenguaje IPL

Apéndice C : Ejemplos de Programación IPL

Apéndice D : Atomicidad de Transacciones Globales

Apéndice E : Redes de Transición de Predicados

Glosario

64

67

67

68

69

69

70

70

73

76

77

77

77

79

80

82

84

88

90

94

100

105

109

... 111

Figura

1.1 1.2

1.3 1.4 1.5 1.6 1.7 1.8 2.1 2.2 2.3 2.4 2.5 2.6 2.1 2.8 3.1 3.2

LISTA DE FiGURAS

Página

Un Modelo de Cómputo Distribuido Un Sistema de Información Interoperable

Arquitectura Conceptual de ELECTRA Arquitectura General del Prototipo ELECTRA Modelo de Procesamiento de Transacciones Características de los Modelos de Transacciones Avanzados Representación General de una Subtransacción Etapas de Especificación y Ejecución de las Transacciones Multibase de Datos Acceso Integrado Mediante Interoperación Fases de los Compilalores e Intérpretes Arquitectura General del Sistema IPL Estructura de Datos para la Sección de Objetos y Tipos Estructura de Datos para la Sección de Estados Aceptables Estructura de Datos para la Sección de Subtransacciones Estructura de Datos para la Sección de Dependencias Algoritmo de Control de Ejecución Amhiente Operativo del Sistema IPL Flujos de Datos entre SSL'S

A.D1 A.El A.E2

Los Diagramas de Transición de Estados Una Red de Transición de Predicados Reglas para la Conexih de Transiciones

5 10 15 18 21 26 28 30 40 56 58 61 61 62 63 66 18 19

104 106 108

iv

INTRODUCCION

La proliferación de plataformas @mesador y sistema operativo) y sistemas software (gestores de datos y paquetes aplicativos) heterogéneos es el resultado de la historia de desarrollo individual de cada organización. La cooperación armónica entre estos sistemas heterogéneos podna conducir a incrementos sustanciales de productividad y eficiencia. Sin embargo, la carencia achial de soluciones satisfactorias impide la realización de aplicaciones globales que requieren de la interoperación de sistemas software heterogéneos. ,

UM aplicación global requiere de acceso.consistente y confiable a múltiples, autónomos y heterogéneos sistemas software participantes. Para ello es imprescindible preservar la autonomía local de los sistemas software Con objeto de que las aplicaciones locales (preexistente) continuen operando. Esto significa que es necesario usar el paradigma transaccional para asegurar consistencia de los datos a pesar de fallas y de accesos concurrentes. Por lo tanto una transacción global equivale a una aplicación global, y una subtransacción componente se refiere a una subtarea (de la aplicación global) que se ejecuta bajo un determinado sistema software local.

El modelo tradicional de transaciones no es adecuado para sistemas heterogéneos, pues pretende preservar las propiedades ACAD (atomicidad, ,consistencia, aislamiento y durabilidad) sin considerar caractenstica alguna del entorno de aplicación. El modelo de transacciones flexibles [ELL901 fué definido expresamente para regir el comportamiento de transacciones en Sistemas Multibase de Datos, En particular extiende el modelo tradicional para incluir formulación de alternativas, dependencias y compensabilidad.

El lenguaje IPL (Interbase Parallel Language), d i s e d o en la universidad de Purdue [BCC92], mapea el modelo de transacciones flexibles en un lenguaje de programación. IPL es un lenguaje declarativo que permite escribir transacciones globales al especificar las operaciones asociadas a sus subtransacciones, su secuencia de ejecución, las dependencias lógicas y sus flujos de datos. También ofrece las construcciones bis¡& para definir protocolos de atomicidad global basados en la semántica de la aplicacion.

En este trabajo de tesis se presenta UM implantacion particular del lenguaje IPL, dentro del marco del proyecto ELECTRA. Este primer prototipo, abre un vasto camino a recorrer en la caracterización e implantación de aplicaciones globales :que satisfagan los nuevos desafíos de las

organizaciones modernas. I I

En el primer capiíulo se vierten conceptos básicos sobre Sistemas. Distribuidos e Interoperabilidad. Se reseñan los diferentes aspectos del proyecto ELECTRA; enseguida se describen los objetivos del Sistema IPL y ñnalmente se presentan en forma tutorial conceptos básicos y avanzados sobre transacciones. El segundo capítulo describe, especifica y detalla el diseño de los diversos módulos componentes del sistema IPL. En el tercer capítulo se presentan las particularidades derivadas de la implantación, pruebas y resultados del Sistema IPL. Por su parte, en el cuarto capítulo se resumen I& conclusiones obtenidas a lo largo del proyecto y se'expresan las lineas futuks vislumbmdas. También se presenta la bibliografia utilizada a lo largo del proyecto, as¡ como una sección fiMl de apéndices en los cuales se abordan con mayor detalle algunos aspectos. En el apéndice A se describe la sintaxis del lenguaje IPL. El apéndice B reseña la sintaxis y semántica de algunas construcciones no evidentes de manera intuitiva. El apéndice C proporciona algunos ejemplos de uso del lenguaje IPL. El apéndice D presenta en cierto detalle aspectos importantes de la atomicidad global de transacciones. Por, último en el apendice E se describe una breve reseña de las redes de transición de predicados, usadas como base para elaborar el algoritmo de control de ejecución.

2

CAPITULO I

CONTEXTO GENERAL DEL SISTEMA IPL

3

1.1 CONCEPTOS BASICOS

De manera informal un Sistema Distribuido se conform de un conjunto de sistemas de cómputo autónomos e interconectados mediante una red de comunicaciones, con objeto de procesar funciones propias de una organización. Estas computadoras componentes no comparten memoria común, motivo por el cual no intercambian datos vía variables globales, sino que interactúan por

transferencia de mensajes a través de la red.

1.1.1 UN MODELO DE COMPUTO DISTRIBUIDO

Cuando se desea entender (o diseñar) un sistema complejo lo recomendable es descomponerlo en varios niveles funcionales. Para ello es importante que cada nivel funcional defmido pueda ser analizado (o diseñado) independientemente, y que además se permitan interaccioncs entre los niveles contiguos a travb de interfaces bien especificadas.

En la figura 1.1 se ilustra un modelo de-cómputo distribuido estructurado en tres niveles funcionales:

I . LOS Servicios de Comunicación, ubicados en el nivel uno, proporcionan las facilidades necesarias para transferir infoFación entre los sistemas de Computo componentes. Estos servicios incluyen tccnologias de sistemas de transmisión (por ejemplo par trenzado, cable coaxial, fibra óptica, microondas, satélite, etc.), de t6cnica.s de enlace de datos, y de diversos protocolos redltransportc con sus correspondientes tecnologias de interconexión heterogéneas. En resumen, su responsabilidad es proporcionar la propiedad de conectividad, infraestructura material imprescindible para la puesta en operación de sistemas distribuidos.

2 Los servicios de apoyo para aplicaciones distribuidas permiten la interoperación de aplicaciones ubicadas en sitios geográficamente distribuidos. Estos servicios incluyen facilidades para el intercambio de correo electrónico, para localizar recursos de usuarios autorizados y para accesar y manipular bases de datos remotas, entre otros.

3. Las aplicaciones distribuidas soportan directamente las actividades de UM organización. Las aplicaciones distribuidas tienen relación con las funciones organ¡zac¡onalcs por ejemplo: procesamiento de pedidos, control de inventarias, nómha,

4

Actividades de Organizaciones A Nivel 3

Control de inventarios. pedidos. - Sistemas de manufactura, ingeniería, - Aplicaciones

Distribuidas Finanzas,

Nivel 2 Acceso a Base de Datos, Tmccion, I Gestión de directorio, seguridad, Llamado de procedimiento remoto

Servicios de Apoyo para Aplicaciones

Distribuidas

interfaces de Programación

Sistemas de redes Servicios (Sockets netbias, -.)

(Protocolos de comunicación, puertas, ruteadores, pasarelas, -1 Sistemas de transmisión (Par trenzado, fibra óptica, satélite, etc.)

de Comunicaciones

Nivel 1

Figura I , I Un Modela de Computo Distribuido

5

presupucsto, etc. (Estas aplicaciones podrían diseñarse como i procesamiento transaccional, toma de decisiones, sistemas expertos o sistemas de apoyo ejecutivo).

'Este modelo no es exhaustivo y tiene la simple intensión de delimitar el alcance y caracterizar la estructura de los diferentes servicios requeridos en un sistema distribuido.

1.1.2.ALGUNOS SISTEMAS DE APOYO A APLICACIONES DISTRIBUIDAS

La mayor parte de las tecnologias relevantes de los servicios de comunicaciones ya adquirieron la madurez necesana para ofrecer productos robustos. Por ejemplo, TCPOP, SNA, DECNET, OSI, SPX/IPX, etc. Como consecuencia de ello, en los últimos cinco años, han surgido varias áreas de investigación emergente que pretenden proporcionar servicios variados de apoyo a

aplicaciones distribuidos. Entre ellas distinguimos tres posibles áreas de interés : 1) Interoperabilidad, 2) Cooperabilidad, y 3) Colaborabilidad. Como sustento necesario de todas estas áreas está la Conectividad.

¡. Conectividad es la capacidad requerida para interconectar cualquier computadora a una red, de tal forma que cada computadora pueda intercambiar mensajes con cualquier otra, sin importar sus plataformas (procesador y sistemas operativo) y protocolos de red. Como puede observarse, estos son los requerimientos que deben proporcionar los servicios de comunicación. En términos del modelo de referencia OSIASO, ésto representa los primeros cuatro niveles (fisico, enlace de datos, red y transporte).

2. Interoperabilidad implica la capacidad requerida para que dos o más sistemas software (también denominados gestores de datos) interactúen mediante la ejecución de tareas conjuntas. Los sistemas sohiare pueden ser : SGBD's (sistemas de gestión de base de datos), SGA's (sistemas de gestión de archivos), SGBC's (sistemas de gestión de bases de conocimientos), paquetes de aplicación (por ejemplo el paquete estadístico SAS), el Shell de~üNIX, etc. Un ejemplo útil lo constituye uqa tarea EXCEL que interactúa con una tarea ORACLE, con objeto de intercambiar datos corporativos. Es importante señalar que los servicios de conectividad (FTP, TELNET, ... )proporcionan "interoperabilidad básica'' a nivel sistema operativo, careciendo de incidencia alguna en los sistemas software.

3. Cooperabilidad denota la interacción conjunta de agentes inteligentes que cooperan para la solución de un problema global. La interacción se concreta mediante protocolos de diálogo

6

que Uitercambian conocimiento con objeto de inferir decisiones colectivas. Un ejemplo simple podria ser la cooperación entre sistemas expertos en medicina para diagnosticar UM enfermedad compleja. Es interesante resaltar que la cooperación se dá entre iguales y no

implica necesariamente una relación de dependencia. Por ejemplo, dos especialistas independientes que cooperan con sus conocimientos en un problema global.

4. Colaborabilidad denota la interacción conjunta de tareas que auxilian a usuarios que colaboran en un grupo de trabajo. En este contexto las tareas auxilian a usuarios que mantienen relaciones de dependencia con respecto a otros. Es decir, un usuario colabora con otro, es su auxiliar o ayudante.

En un intento por asociar estas áreas emergentes a los diversos aspectos de la conocida trilogia Dato + Información -+ Conocimiento, de manera informal podríamos hacer las siguientes consideraciones :

La lnteroperabilidad tiene. un fin utilitarista : integrar los datos residentes en múltiples y heterogéneos recipientes, con objeto de generar información global.

La Colaborabilidad transfiere información (en forma de documentos u objetos no estructurados) entre usuarios que colaboran en la realización de un proceso de negocios.

La Cooperabilidad transfiere conocimientos entre agentes para obtener soluciones globales a un problema de negocios.

De acuerdo con la caracterización anterior se puede concluir que la Interoperabilidad constituye una extensión del tradicional problema de acceso a recipientes : sólo que ahora es necesario el acceso integrado a múltiples y heterogéneos recipientes de datos. Por otro lado, con un enfoque diferente, la Colaborabilidad y la Cooperabilidad inciden primordialmente en el comportamiento del proceso de negocios.

1.1.3 INTEROPERABILIDAD EN SISTEMAS DE INFORMACION HETEROGENEOS

De manera general un sistema de información automatiza alguna(s) función (es) OrganizaCiOMi (es). Cada sistema 'de información muestra UM estructura lógica constituida por tres grandes componentes:

1 I El recipiente de datos, el cual mantiene los datos organizados de acuerdo con un modelo de datos particular. Por ejemplo, relaciona¡, jerárquico, redes, semántico, orientado a Objetos, archivos p h o s , etc. Los datos almacenados pueden ser estnichidos (tablas), semiestructurados (imágenes) o conocimiento en forma de reglas. En general el acceso al recipiente es controlado por un gestor de datos local asociado, por ejemplo SGBD (sistema de gestión de base de datos), SGA (sistema de gestión de archjvos), SGBC (sistema de gestión de base de conocimientos), etc.

2. Los programas de aplicación (o tareas) que manipulan los datos. Estos programas interactiian directamente con la interfaz que ofrezca el gestor de datos : SQL (para relacionales), funciones @ara archivos planos), macros (para hojas de cálculo), comandos (para el Shell de UNK), etc. Estas tareas pueden referirse a consultas/actualizaciones de bases de datos, archivos planos, inferencias de sistemas expertos, graficación en hojas de cálculo. etc.

3. La interfaz con el usuario permite procesar (en forma amigable) los accesos dictados por el usuario. Esta podria ser concretada con procedimientos de texto, gráficos o multimedia según la conveniencia particular.

En un entorno distribuido caracterizado por la coexistencia de múltiples sistemas de informacion heterogéneos, podrian presentarse las siguientes variantes :

a) Recipientes y gestores de datos heterogéneos en los diferentes sitios, e inclusive podria ocurrir que dos recipientes del mismo tipo tengan diferente gestor local. Por ejemplo, recipientes relacionales con gestores Oracle y Sybase respectivamente.

b) Los programas de aplicacion podriq residir en el mismo sitio del gestor de datos o en el de la interfaz con el usuario.

Bajo este escenario, iCómo lograr interoperabilidad . , en sistemas de información heterogéneos?.

En realidad esta pregunta general la podríamos particularizar de la siguiente forma : ¿Cómo permitir la interopersción entre gestores locales con recipientes y esquemas heterogéneos?. ES decir, al operar cada gestor sobre su tarea correspondiente. ¿Cómo lograr que interoperen (intcrcambien datos) entre si, con el propósito de integrar .datos residentes en múltiples y heterogéneos recipientes (inclusive esquemas)?.

8

Además, en un sistema de información distribuido es imprescindible asegurar c,jmputo consistente y confiable, por lo que la interoperación debe regirse de acuerdo con el paradigma tmacCiOMl.

Para completar el panorama es necesario advertir que 10s sistemas de información componentes son autónomos. Es decir, fueron configurados y diseMos en forma independiente y ya operaban con usuarios locales antes de que se decidiera integrarlos. Por tanto, las nuevas aplicaciones o transacciones globales (distribuidas), compuestas de múltiples tareas denominadas subtransacciones, deberán coexistir con las locales preservando así las inversiones de la organización. Por lo tanto, para entender plenamente la connotación del término interoperabilidad en sistemas de información heterogénm, es necesario explorar ampliamente un nuevo tipo de sistemas conformados por múltiples, autónomos y heterogéneos sistemas de información : Los Sistemas Multibase de Datos (SMD) y los Sistemas de Información Interoperables (SII). En la figura 1.2 se ilustra la hncionalidad general de un sistema de información interoperable o conjunto integrado de sistemas de información heterogéneos.

A) Un sistema multibase de datos [LIT881 es una pieza de software que permite el acceso integrado a datos almacenados en múltiples sistemas de bases de datos (SBD's) preexistentes. En este sentido, es importante señalar una característica primordial de los SMDs: los SBD's componentes son autónomos. Es decir son independientes, pues fueron diseñados. desarrollados y administrados por grupos de trabajo separados. En consecuencia, cada SBD mantiene un control 'de acceso restringuido de sus datos con respecto a otros SBD's; asimismo es 'libre de accesar y manipular sus datos independientemente. Esto significa que en un SMD coexisten dos tipos de usuarios : 1) locales, derivados de la aplicaciones preexistentes en cada SBD, y que es deseable preservar por conveniencias funcionales y económicas de las organizaciones Propietarias, y 2) globales, producto de las nuevas aplicaciones que incluyen acceso integrado a múltiples SBD's. Se supone que los SBDs residen en sitios geográficamente distribuidos y están interconectados mediante alguna red de comunicación.

.

B) Un sistema de información Interoperable (SII) [MAL921 es una facilidad que soporta aplicaciones globales que accesan múltiples bases de información preexistentes y quizás hetcrogéneas. Los sistemas de gestión de información componentes son autónomos y posiblemente heterogeneos. Existe la coexistencia concurrente de aplicaciones globales y locales y ticncn efecto las consecuencias derivadas del respeto a la autonomia local. En los SIl's se aplican todos los aspectos considerados en los Sistemas Multibase de Datos

9

Interfaz Usuario Global

n. / I"..\

Si, S2, Sn Subtransacciones globales TLi.TLn Transaccionesldes PALtpALn Programas de aplicación locales PAGiJAGn Programas de a p h c i ó n globales GDi,i,-GDLn Gestores de datos I d e s BD Base de. datos Arch Archivos Bc Base de conocimientos

Local

Figura 1.2 Un Sistema de Información Interoperable

10

(heterogeneidad semántica, descomposición/pIanific~ión de consultas y gestión global de transacciones), más lo referente a la interconexión de sistemas de archivos, sistemas expertos y hojas de cálculo. El aspecto adicional más delicado es la manera en que debe abordarse el problema de gestión de transacciones, al incluir sistemas que no disponen de mecanismos de control de concurrencia y confiabilidad. De la descripción anterior se puede concluir que los SMDs son un subconjunto de los SIi's.

En resumen, estos son los desafios que enfrenta el proyecto ELECTRA, el cual será descrito en la siguiente sección.

1.2 EL PROYECTO ELECTRA

El proyecto ELECTRA (Entorno para la Localización y Ejecución Cooperativa de Transacciones Remotas Atómicas) constituye una iniciativa de investigación y desarrollo tecnológico en el área de Sistemas Distribuidos, de la División de Computación del ITAM. Sus principales objetivos son :

I . Asimilar la experiencia internacional acumulada durante el último decenio en lo referente a la definición, acceso y manipulación remota dc los datos.

2. Generar conocimientos orientados a la creación de productos acordes con normas internacionales y que sean competitivos con los existentes comercialmente.

3. Fomentar la formación de recursos humanos en estas nuevas tecnologias; propiciar la cohesión de actividades multidisciplinarias en Bases de Datos, Comunicaciones, Sistemas Distribuidos e lntcrfaces de Usuario-

1.2.1 ALCANCES DEL PROYECTO ELECTRA

Los entornos conformados por múltiples, autónomos y hctcrogénws sistemas de información constituyen una nueva generación de sistemas distribuidos que apenas se empiezan a entender. Con objeto de acelerar los pmcesos de asimilación y generación de conocimientos, se adoptó una estrategia de investigación y desarrollo fuertemente vinculada con la construcción de un aparato expcrirneniai. Los propósitos particulares de esta estrategia han permitido formar un grupo de

11

trabajo, elaborar algunas hipótesis que tendrán que ser confrontadas con un "sistema real", y adecuar el aparato experimental a problemas reales de grandes organizaciones.

El proyecto ELECTRA ha sido planteado con un alcance amplio. En él se consideran aspectos de investigación básica, desarrollo tecnológico, transferencia de tecnología y desarrollo de aplicaciones. Estos diversos aspectos se agruparon y planificaron en tres etapas:

I . Desarrollo tecnológico combinado con la investigación básica necesaria, con el objetivo de asimilar y generar. los conocimientos suficientes para construir ei aparato experimental requerido. En esta etapa se incluyen el diseño y construcción de los diferentes módulos de ELECTRA (ver sección 1.2.2) : compiladoreshtérpretes de los lenguajes MSQL e IPL con sus respectivos ejecutores, asi como también sus correspondientes interfaces grrificas; controlador de concurrencia global para aplicaciones transaccionales con IPL, gestor de datos interdependientes para especificar y reforzar integridad interbases de datos; mecanismos de comunicación de alto nivel Windows-UNIX; agentes de interoperabilidad (bases de datos relacionales, shell de UNIX, multimedia, terminal y desplegado); algunos servidores específicos como multimedia, desplegado y de terminal.

2. En esta segunda etapa se pretende transferir la tecnologia elaborada a alguna(s) gran(des) organización(es). En forma paralela se podrán caracterizar y desarrollar aplicaciones distribuidas (bajo ELECTRA) que reflejen la funcionalidad de la problemática de lab) organización(es) elegida(s).

3. En la tercera etapa, ya en la madurez del grupo de trabajo, se realizará con mayor intensidad investigación básica en gestión de transacciones y gestión de datos interdependientes. También se .continuarán ,extensiones posibles al prototipo ELECTRA y nuevas aplicaciones distribuidas.

1.2.2 ARQUITECTURA CONCEPTUAL DEL PROYECTO ELECTRA

La idea básica en la arquitectura de ELECTRA se sustenta en los conceptos de servicio y servidor. El termino servicio denota las facilidades de acceso a recipientes de datos estructurados o semiestnicturados, bajo alguna organización particular (BD, Arch., BC). El servidor (o gestor de datos) es la entidad responsable de proporcionar tal acceso (SGBD, SGA, SGC), mediante primitivas o comandos específicos (SQL, macros, funciones, ... ).

12

De manera complementaria, el usuario global especifica en su transacción global (aplicación global) las diversas actividades de acceso (subtransacciones) para cada uno de los servicios requeridos. Las acciones enunciadas en cada subtransacción constituyen la tarea que debe realizar

el servidor con objeto de proporcionar el servicio deseado.

Pero a causa del respeto a la autonomia local de los sistemas de hformacion invo luc~os , como Por razones de UNfOmiidad de diseño, el servidor de datos no debe interactuar con la aplicación global. Es por ello que debe incluirse un agente de interoperabilidad, bajo el control de la aplicación global, que se comporta en forma análoga a un usuario local. De tal manera que el servidor de datos no distingue entre un usuario local y un agente de interoperabilidad. Esto significa que habrá tantos agentes como servidores/servicios disponibles. Esta red de agentes necesita de un controlador global. Para llevar a cabo lo anterior se incluye un gestor de tareas distribuidas, cuya función principal es la coordinaciónlsincronización de

2

z ; g w O U

I* g:

E actividades a enviar a los agentes para su respectiva ejecución. La interacción entre el gestor de tareas distribuidas y los agentes de interoperabilidad se puede llevar a cabo mediante algún mecanismo de comunicaci6n que proporcione primitivas de alto nivel adecuadas para ello. La transaparencia en la localización requiere del almacenamiento de caractensticas de los servicios y

U ' d P o o o u- Qb

de la identificación de objetos de BD exportables en un diccionario global.

Como el gestor de tareas distribuidas se ocupa únicamente de coordinar la ejecución de las subtransacciones, se requiere de un gestor de 'eontrol de concurrencia global. que evite los posibles conflictos entre subtransacciones y transacciones locales. También se requiere de un sewidor de desplegado de resultados, el cual podria procesar 10s datos recibidos Según especificaciones del usuario global.

También es necesario incluir lenguajes.de manipulaci6n/coordinaci6n de acceso integrado a múltiples y heterogéneos sisimas de información. Esto es fundamental para la realización de herramientas de desarrollo de aplicaciones globales.

Con base en las consideraciones anteriores se especificó y diseñó una arquitectura para el soporte de aplicaciones globales en entomos de múltiples, autónomos y heterogéneos sistemas de información. Esta arquitectura debe ser válida para SMDs y Sll's, pues si en ambos existen problemas similarcs, entonces también deben compartir soluciones comunes.

13

Con objeto de implantar la arquitectura especificada se him UM revisión critica de trabaios I sobre lenguajes de manipulaciÓn/cwrdin¡Ón existentes. Como resultado de ello se eligieron

MSQL [LAN891 e IPL [BCC92]. Ambos lenguajes están orientados a sistemas distribuidos débilmente acoplados, por lo que los problemas de heterogeneidad se&tica e integración de esquemas no es necesario considerarlos. MSQL extiende la sintaxis y s e h t i c a de las sentencias SQL a un entorno de múltiples sistemas de base de datos relacionales, pero carece de operaciones explícitas .de transacciones, por lo que su gran utilidad puede ser en consultas multibase de datos. Con un enfoque distinto, IPL fue concebido como un lenguaje para la especifi&ión de transacciones globales. En realidad su diseño refleja completamente las caractensticas del modelo de transacciones flexibles [ELLR90], el cual rompe con el modelo de transacciones tradicional ai relajar las propiedades de atomicidad y aislamiento. Ademis IPL puede también ser considerado un lenguaje multisistemas, dado que la descripción de las actividades de las subtransacciones componentes se hace. en el lenguaje nativo del servidor de información.

En la figura I .3 se puede apreciar la arquitectura conceptual derivada de nuestros heamientos deinteroperabilidad. Esta considera la coexistencia de usuarios globales y locales. Ademis permite UM separación de usuarios globales: programadores y usuarios finales. Los programadores deben ser especialistas en computación y el desarrollo de aplicaciones globales lo harían codificando de acuerdo con la sintaxis y semántica de MSQL e IPL. Por el contrario, los usuarios ñnales harían uso de interfaces gráficas realizadas exprofeso.

Existe un traductor para MSQL y otro para IPL. Cada traductor hace uso de un diccionario global (del cual se ticne una copia en cada máquina) para obtener información correspondiente al tipo de servicio, sitio de residencia, dirección, tamaño de tablas, etc. Posteriormente el gestor de tareas distribuidas recibe del traductor el código intermedio con las especificaciones necesarias para llevar a cabo la coordinación de su ejecución. Es importante señalar que los gestores de tareas distribuidas son diferentes, pues mientras la coordinación de ejecuciones en MSQL es simple, en IPL es muy complicada y una solución factible consiste en modelarlo con redes de petri [LEB90].

El gestor de tareas distribuidas analiza las dependencias de ejecución de las subtransacciones, incluyendo una petición de verificación de conflicto al controlador de concurrencia global @ara el caso IPL). A continuación, ya con el orden de ejecución establecido, inicia el envío de las subtransaccioncs. Antes de enviar la tarea solicita la disposición del servicio deseado, creando un agente de interoperabilidad en el sitio de residencia del senicio, mediante la primitiva IniciaSeMcio(parámetros). El agente creado, según el seMcio indicado, desencapsula los parámetros y verifica las condiciones básicas de ejecución (nombre usuario, password, privilegios,

14

. . Comunicación

S i c m a Autónomo Local

Figura 1.3 Arquitectura Conceptual de ELECTRA

15

etc.). si todo es COITe&J notifica de dl0 ai gestor mediante una s e h l lógica y qu& a la espera de comandos. Enseguida el gestor de tareas distribuidas envia la tarea a ejecutar mdiante la RealuaServicio(tarea, parámetros). Al recibir la tarea y los parámetros de entrada/salida de datos, el agente somete a ejecución la tarea al servidor de información correspondiente. Al t é d o de la ejecución el agente envia los resultados (si los hubiera) a otro agente especificado @odna ser al asociado al servidor de desplegado) en los parámetros y notifica del éxito o f r a w o al gestor, Los datos pueden ser simples, estructurados o semiestructurados (tablas, imágenes, ...) y se transfieren con la primitiva EnvíaDato(dato). Finalmente el gestor indica el ñn de uso.del servicio con la primitiva TerminaServicio(confrmac¡6n). Esto causa que el agente aplique la confirmación o no confirmación de la tarea realizada, notifique al gestor, cierre conexiones y se autoaniquile. En IPL la confirmaciódno confirmación puede concretarse con comandos comit/abolt o incluirse código de subtransacciones compensatonas.

1.2.3 EL PROTOTIPO ELECTRA

En la arquitectura general del prototipo ELECTRA (ver fig. 1.4) se consideran dos grandes componentes: 1) procesadores frontales, y 2) procesadores dorsales. En los procesadores frontales se generan las peticiones de acceso (ClientdServidor, Multibase de . Datos o interoperables), las cuales se ejecutan en los procesadores dorsales, que a su vez retornan los resultados correspondientes para su respectiva integración. Los procesadores frontales, en la primera etapa de nuestro proyecto, se conforman de computadoras personales bajo el entorno WINDOWS; en una segunda etapa podrán ser estaciones de trabajo con interfaces de usuario MOTIF u OPEN LOOK, Los procesadores dorsales pueden ser minicomputadoras, estaciones de trabajo o computadoras personales, bajo los sistemas operativos UNIX o WINDOWS respectivamente. Ellos disponen de servidores de información: de base de datos (SYBASE, ORACLE, INFORMIX), de base de conocimientos (KES), de archivos ( I S M ) y de multimedia (audio, imagen y video). Debido a la arquitectura modular de ELECTRA, cualquier otro tipo de servidor de información podrá ser integrado en el fuiuro,

El mecanismo de comunicación de alto nivel entre el gestor de tareas distribuidas y los agentes de interoperabilidad se concreta mediante el módulo denominado Ruteador. Complementando esta acción, del lado servidor se fabrican las ,actividades particulares para cada servicio de información. Adicionalmente a los protocolos TCPílP y al mteador, se incluyen los módulos agente de interoperabilidad y gestor de datos interdependientes. El agente de interoperabilidad se encarga de procesar las subtransacciones enviadas por el módulo ejecutor (que realiza las funciones

16

asignadas al gestor de tareas distribuidas, en la sección anterior), residente en los procesadores frontales. Cada agente de interoperabilidad recupera los resultados producidos por la transacción y los puede remitir a otro(s) agente(s) o directamente al ejecutor que la generó. También se incluyen agentes de lnteroperabilidad Shell o AWK en el entorno UNE. El gestor de datos interdependientes se ocupa de mantener la consistencia mútua (al grado requerido) de los datos interrelacionados (mediante alguna restricción de integridad) y almacenarlos en diferentes BD's. Es por esto que únicamente los servicios de información de BD's y Archivos disponen de este módulo.

Para proporcionar el sustento requerido por aplicaciones globales Multibase de Datos y de Multisistemas, se incluyen los lenguajes correspondientes. Se ofrecen traductores para el lenguaje Multibase de Datos MSQL y para el lenguaje de coordinación distribuida IPL. Asociado a IPL y MSQL se incluyen sus correspondientes ejecutores y el diccionario global. Adicionalmente se

incorpora un módulo de gestión de transacciones globales. Este se compone fundamentalmente de un gestor de control de concurrencia global. También se complementan estos módulos con interfaces gráficas amigables para MSQL e IPL.

1.3 OBJETIVOS DEL SISTEMA IPL

El sistema IPL constituye el centro neurálgico del proyecto ELECTRA para efectos de especificación y coordinación de accesos en actualización 'a múltiples, autónomos y heterogéneos sistemas software locales. En este trabajo de tesis se abordan desde el entendimiento del modelo de transacciones, pasando por la implantación del lenguaje IPL, hasta la caracterización y especificación de aplicaciones globales distribuidas. Estas grandes temáticas están inmersas en los siguientes objetivos particulares :

1. Caracterizar un modelo general. de transacciones multibase de datos, incluyendo multisistemas heterogéneos.

2. Estudiar el modelo de transacciones flexibles, uno de los modelos de transacciones mas adecuados para sistemas multibase de datos.

3. implantar un precompilador para el lenguaje IPL, un lenguaje de coordinación de tareas distribuidas mapeado del modelo de transacciones flexibles. También se pretende elaborar una versión intérprete para su uso interactivo.

17

I

w w I

/

Procesadores Dorsales

Figura 1.4 Arquitectura general del Prototipo ELECTRA

4. Definir e implantar un ejecutor de tareas distribuidas acorde con la semántica de IPL. Este ejecutor debe inkractuar con los módulos del controlador de concurrencia global y de los diversos agentes de interoperabilidad, mediante las primitivas de comunicaciones establecidas.

5.- Caracterizar, especificar en IPL y ejecutar algunas aplicaciones globales distribuidas de interés.

Todos estos puntos serán considerados en las secciones y capitulos correspondientes

1.4 EL PARADIGMA TRANSACCIONAL

El paradigma transaocional constituye la más importante alternativa tecnológica para construir sistemas de cómputo distribuido consistente y confiable [GRA92]. Sin embargo, los conceptos y técnicas elaboradas para sistemas centralizados o distribuidos homogéneos no necesariamente son aplicables a entornos de cómputo autónomos y heterogéneos.

1.4.1 LA NOCION DE TRANSACCION

La noción de transacción se ha convertido en una abstracción fundamental para el análisis y diseño de sistemas de información con acceso concurrente y confiable. Esto permite ocultar al programador los efectos de posibles fallas, asi como los detalles de ejecución concurrente.

Una transacción constituye una unidad de ejecución que accesaíactualiza una base de datos mediante un conjunto de operaciones explicitas (begin- read/wnte, commit, abort, endtran). El uso de la transacción permite preservar cuatro propiedades fundamentales w83], denominadas ACAD por la letra inicial de cada una de ellas : Atomicidad, Consistencia, Aislamiento y

Durabilidad. La propiedad de atomicidad establece que todas las operaciones de una transacción, o ninguna de ellas, se llevan a cabo. La consistencia significa que cuando una transacción se ejecuta completamente, ésta presewarii la consistencia de la base de datos; esto es, transforma la base de datos de un estado consistente a otro. El aislamiento tiene dos únplicaciones : I) si varias transacciones se ejecutan concurrentemente, los resultados serin los mismos que si éstas fueran ejecutadas en orden secuencial, lo cual se con@.% como seriabilidad, 2 ) una transacción puede ofrecer sus resultados a otras únicamente después de su compromiso, lo cual es necesario para

19

evitar abortos en cascada PHG87J. Por Ultimo, la durabilidad establece que los resultados de una transacción comprometida permanecerán a pesar de posibles próximas fallas. La consistencia Y el aislamiento tienen que ver con el aspecto control de concurrencia, mientras que la atoMcidad y la durabilidad con la confiabilidad (compromiso y recuperación). Los SGBD’s comerciales garantizan las propiedades mediante el uso de algoritmos de control de concurrencia, compromiso

y recupemión.

Con objeto de modelar el comportamiento transaccional de los SMD’s, en [GPZ86] se propuso un modelo de procesamiento de transacciones, el cual fue modificado posteriormente por FD90J. Ver figura 1.5.

Por simple observación pragmática es posible concluir que la integración de los diferentes SBDs se hace de manera ascendente (bottom-up). En consecuencia, el procesamiento de transacciones es de carricter jerárquico. Es decir, cada SGBD participante asegura la ejecución correcta de las transacciones propias a su sitio, mientras que la capa SMD, en un nivel superior a los SGBD’s, controla la ejecución de las transacciones globales y coordina las ejecuciones locales.

Analizando la figura 1.5, observamos que la capa SMD se compone de dos módulos funcionales : el Gestor de Datos Globales (GDG) y el Gestor de Transacciones Globales (GTG). Su funcionalidad es la siguiente : Un usuario global somete transacciones globales Ti al GDG. Este módulo las analiza, las descompone en subtransacciones, las traduce, optimiza e integra los resultados. Esto significa que por cada transacción global Ti se producirán Unj=i Ti, subtransacciones. El GTG tiene a su cargo el envio (según cierto orden compatible con el criterio de validez utilizado) y ejecución (consistente y confiable) de las subtransacciones globales. Con objeto de preservar la autonom’a local, y quizá reforzar el orden de seriación global, se asocia a cada uno de los sitios participantes un proceso servidor, que además de servir de interf” GTG<-SGBD, controla la ejecución de la subtransacciones en ese sitio.

El controlador de concurrencia global (CCG) es un componente del GTG, el cual mrdina las ejecuciones de las subtransacciones globales en los diferentes sitios, de tal manera que se

mantenga la consistencia global, con un grado de concurrencia aceptable y sin violar la autonom’a local.

El controlador de confiabilidad global (CCE) es la parte del GTG que reúne las actividades de compromiso y recuperación, las cuales garantizan atomicidad y durabilidad globales, a pesar de fallas. Para asegurar la atomicidad global, el protocolo de compromiso de dos fases (2PC : two-

20

@ Resultado Integrado Formulación comultai actualización global ~i

I I I I

I I

I

I I

I

-. t -I- -- - - - - - - - I- - - - - - - -- GDG

Descomposción de consultas Transformación de comandos

Optimación de consultas integración de multados

I I

I I

I , I

I I I I

(T4) /'Til

GTG

Control de Concurrencia Global

Control de Confiabilidad Global

, .~ ...... .................................. i

SGBDZ

: ..... ~~ ........ ......... . . ~ ....,...........

TL\ 69 Y

, . ! . . .

Ti - Transacción Global GDG - Gestión de Datos Globales TL - Transacciones Locales SGBD - Sistema de Gestión de Base de Datos

Til, Ti2, - Subtranbones Globales . GTG - Gestión de Transacciones Globales

BD - BasedeDatos

Figura 1.5 Modelo de Procesamiento de Transacciones

21

p h a s e a m i t ) resulta demasiado restrictivo, por lo que es necesario investigar otros enfoques

[ELM92].

1.4.2 PROBLEMAS INHERENTES A LA AUTONOMIA LOCAL

La autonomia local define el derecho de cada SBD para ejercer sus propias decisiones, sin injerencias o imposiciones extemas : por ejemplo elegir a su conveniencia el SGBD y definir el esquema conceptual según su propia metodología. La autonomía también es necesaria para asegurar que los usuarios locales puedan continuar ejecutando SUS aplicaciones, a pesar de la integración, garantizando sus requerimientos de consistencia, seguridad y desempeño, mientras se

facilita el acceso de usuarios globales a sus porciones de datos permitidas. Sin embargo, la autonomía es dificil de cuantificar. Para precisar sus efectos en el procesamiento de transacciones, es necesario hacer uso de la siguiente clasificación [SL90] :

Autonomía de Diseño.- Cada SBD es libre de elegir su propio diseño. Esta elección es referente a modelo de datos, lenguaje de interrogación, restricciones de integridad y estrategia de procesamiento de transacciones.

Autonomía de Ejecución.- Se refie? al derecho de autogestión de que goza un SGBD para decidir en que momento y como ejecuta las operaciones locales, sin injerencia de operaciones externas.

Autonomía de Comunicaci6n.- Tiene que ver con la libertad que tiene cada SGBD para proporcionar o no cierta información a algún agente externo.

Autonomía de Asociación.- Cada SBD tiene la libertad de decidir que porciones de datos comparte con los usuarios globalcs.

De manera intuitiva se puede deducir que las autonomías de diseño y de asociación constituyen aspectos estáticos. Es decir, ellos podrían ser conocidos o negociados en el momento de la integración. Por otro lado, las autonomias de ejecución y de comunicación son de carácter dinámico, pues consideran decisiones a tomar por el SBD en el tiempo de ejecución.

Para preservar las autonomias de diseño y de asociación, el GTG no deberá imponer restricción alguna sobre los SBD's (limitar a cierto modelo de datos, lenguaje de interrogación,

dgoribno de control de concurrencia, etc.); tampoco exipid alguna

de 10s SGBD's. En el mismo sentido, no violar las autonomías de ejecución y de implica que e! GTG no ejercer6 control alguno sobre las ejeciciones locala, e x q t o en el envío de las subtransacciones globales.

en la atrucaira

de

De las aseveraciones anteriores podemos inferir que los efectos resultantes de las autonomias de diseño y de asociación, a pesar de que son más dificiles de conciliar, son relativamente &¡les a comprender, debido a que pueden ser analizados &t¡camente. Por ejemplo, si los SGBDs tienen diferente algoribnos de control de concurrencia (bloqueo en dos fases, ordenamiento por sellos de tiempo, etc.). en base a esa información se puede plantear una estrategia de control de concurrencia global. Por el contrario, los efectos~resultant& de las autonomías de ejecución y de comunicación son más dificiles a comprender, pues dependen de las ejecuciones particulares de las aplicaciones, y en consecuencia tal información es muy dificil de obtener. De aquí se deduce que un SGBD no tiene conocimiento de la existencia de otros; por tal motivo, los SGBD's no pueden asegurar que la ejecución combinada de transacciones lbcales y subtransacciones globales mantengan la consistencia global. Es por esta d n que se requiere de un gestor de transacciones globales, el cual coordine la ejecución de las transacciones en un SMD. Además, como las transacciones locales se ejecutan fuera del control del GTG,' éste no tiene conocimiento de los posibles conflictos indirectos entre subtransacciones globales, causados por la ejecución invisible de transacciones locales [ED~O]. importante señalar que este efecto origina que el mantenimiento de la seriabilidad como criterio de validez para SMD's sea Casi imposible. . ' .

1.5 MODELOS DE TRANSACCIONES

Todo modelo de transacciones se caracteriza por .cierto grado de exigencia de los requerimientos básicos de cómputo consistente y confiable, para un entorno de aplicación particular. Esto significa que no es congruente la existencia de un "modelo universal", sino que podrá haber tantos modelos de transacciones como entornos de aplicación posibles. , .

En general un modelo de transacciones incluye cuatro componentes principales :

1.- Las propiedades ACAD. La preservación de estas cuatro propiedades satisface los requerimientos básicos de cómputo consistente y confiable (ver sección 1.4. I).

23

2.- El criterio de validez (correchies criteria) establecido para garantizar las propiedades de Aislamiento y Consistencia, según el grado requerido.

3.- El protocolo de atomicidad (commit protocol) asegura el cumplimiento de las propiedades

de Atomicidad y Durabilidad, según el grado requerido.

4.- La semántica de las aplicaciones denota el comportamiento especifico del entorno de aplicación particular. De este comportamiento se. derivan directamente los requerimientos que permiten establecer el criterio de validez y el protocolo de compromiso adecuados, lo que indirectamente relaja algUM(S) propiedad(es) ACAD.

Por ejemplo, para los sistemas centralizados y distribuidos homogéneos, con uso frecuente en banca, reservaciones y renta de autos, de su semántica de aplicaciones se derivan requerimientos de transacciones competitivas y de corta duración (segs) con seriabilidad como criterio de validez (garantiza un alto grado de consistencia) y de protocolos de atomicidad estrictos (UNDO, REDO, TWO PHASE COMMIT o simplemente 2PC). De manera diferente, en sistemas multibase de datos las transacciones son cooperativas y de iarga duración, además de que la senabilidad y el protocolo de atomicidad 2PC resultan demasiado estrictos. Estas consideraciones necesariamente conducen al relajamiento de alguna(s) propiedad(es) ACAD.

1.5.1 MODELOS DE TRANSACCIONES PARA APLICACIONES AVANZADAS DE BD's.

A continuación se describen brevemente los principales modelos de transacciones para aplicaciones avanzadas :

a) Transacciones Anidadas, propuesto por Moss en [Mos8I] y ampliado en [Mos85]. Una transacción en este modelo puede contener cualquier número de subtransacciones. y cada

subtransacción puede contener cualquier número de subtransacciones

b) Sagas, propuesto en [GMS87], está basado en el concepto de transacciones compensatorias propuesto en [Gra81]. Para UM transacción T, la transacción compensatona C es una transacción que semánticamente puede deshacer los efectos de T después de que ésta ha sido comprometida. Sagas fue propuesto por Garcia-Molina y Salem para resolver el problema de Transacciones de Larga Duración.

24

c) Transacciones de Duración Indefinida, propuesto por Pu et. al. en [PKH88]. Este modelo fue propuesto principalmente para soportar aplicaciones de duración indefinida. Algunos ejemplos de aplicaciones de duración indefinida son proyectos CAD/CAM, disefio VLSl y desarrollo de sohare .

d) Transacciones Diferidas y Desacopladas, este modelo de transacciones fue propuesto por Dayal et. al. en [DHL91] y [DHL90]. Este modelo es una generalización del modelo de transacciones anidadas.

e) Transacciones con Jerarquia Cooperativa, fue introducido por Nodine y Zdonik en mZ84]. Este modelo está diseñado para soportar aplicaciones cooperativas tales como CAD.

f ) Transacciones Multi-Nivel, modelo propuesto en [wS91], como UM estructura que soporta métodos de control de concurrencia de alta-eficiencia.

g) Sistemas Groupware, propuesto en [Eii9i], fue diseñado para propósitos específicos de colaborabilidad, es decir, sistemas que permiten que dos o más usuarios trabajen en forma fuertemente acoplada en UM tarea común.

h) Transacciones S, modelo propuesto en [EVT88], fue introducido para soportar la cooperación del sistema bancario internacional.

i) Modelo ConTract, fue propuesto por Reuter en [Re11891 para definir y controlar transacciones de larga duración, computación compleja en aplicaciones no esthdar, tales como automatización de oficinas, CAD y control de manufactura.

j) Transacciones Tool Kits, el enfoque tool kit propuesto por Unlad y Schlageter [Us911 representa un intento para modelar y controlar las transacciones que tengan requerimientos conflictivos entre sus subtransacciones.

Los modelos de transacciones anteriores se resumen en la figura 1.6, en ella se observan 10s requerimientos que soporta cada uno, que justamente el modelo tradicional de transacciones ignora.

25

X - requerimiento soportado. -

Figura I .6 Características de los modelos de transacciones avanzados.

1.5.2 UN MODELO DE TRANSACCIONES MULTIBASE DE DATOS

En entornos multibase de datos es necesario coordinar las actividades de SGBD's autónomos que heron diseñados para operar en forma aislada e independiente. Esta autonomía justifica que cada SGBD disponga de sus propios mecanismos de gestión de transacciones (control de concurrencia, atomicidad y recuperación). Este hecho sugiere que en lugar de desarrollar un nuevo mecanismo global que duplique la hncionalidad de los SGBD's locales, lo adecuado sena aprovechar su existencia y lograr UM convivencia eficaz. Con este enfcque resultaría inevitable UM extensión al modelo tradicional de transacciones.

La principal dificultad para aplicar las técnicas tradicionales de gestión de transacciones a entornos multibase de datos, obedece a los requerimientos de autonomía local de los sistemas componentes. Además, debido a que las transacciones multibase de datos incluyen múltiples sistemas con capacidades de procesamiento diferentes, muy frecuentemente éstas se manifiestan como actividades de larga duración. Por otro lado, en el modelo tradicional de transacciones la única posibilidad de interacción entre transacciones concurrentes la determina el grado de competición por los elementos de datos, como consecuencia del aislamiento completo requerido. Por el contrario, las transacciones multibase de datos se caracterizan por un mayor deseo de cooperación que de competición.

26

La larga duración de una transacción multibase de. datos puede causar serios problemas de desempeño, pues las subtransmiones componentes retienen sus candados hasta que no mum el compromiso global, causando con ello que otras subtransacciones esperen (demasiado tiempo) la liberación de éstos. Una solución interesante [GRA81] consiste en hacer que las subtransacciones se comprometan, liberando as¡ sus candados asociados. Pero si la t&acción global fracasa, entonces ciertas subtransacciones compensatorins podrían nuliñcar los efectos de las subtransacciones comprometidas.

Un modelo de transacciones multibase de datos debe tener un énfasis primordial en capturar (lo mejor posible) la semántica de las aplicaciones. Por lo tanto, además de especificar Ins subtransacciones, un diseñador de transicciones multibase de datos debería definir los aspectos de ejecución cooperativa : dependencias de ejecución y flujo de datos entre subtransacciones. También sena necesano definir los requerimientos de atomicidad que mitiguen los efectos derivados de la larga duración de las transacciones. A partir de las dependencias y del flujo de datos sena posible elaborar la planificación de la ejecución de las subtransacciones (a este módulo lo hemos denominado Ejecutor). De manera similar, los requerimientos de atomicidad servirán para especificar el (los) estado(s) de terminación posible(s). En breve, la estructura de una transacción multibase de datos depende de'la semántica de la aplicación particular y de las caractensticas de los sistemas software locales.

Las subtransacciones componentes de una transacción global se envían (esto lo hace el ejecutor) a los sistemas software participantes para su correspondiente ejecución. Estas subtransacciones, en su evolución natural, pasan por ciertos puntos discretos que reflejan su estado de ejecución :

Latente (L) En ejecución (E) Abortada (A) Preparada para comprometerse (P) Comprometida (C)

Es importante seitalar que el estado P sólo puede ser alcanzado por subtransacciones enviadas a sistemas software que soporten two-phase commit (2PC).

La vocación cooperativa de las subtransacciones induce al intercambio de datos entre. ellas mcdiante variables de entrada y de salida. Las variables de entrada pueden contener padmetros

21

de ejecución para la tarea de una subtransacción mientras que sus variables de salida representan

los resultados generados por ésta, los que pueden ser remitidos a otra subtransacción (en otro sitio) y que constituirh a su vez la variable de entrada de aquélla. De ata manera el flujo de datos entre. subtransacciones se determina al asignar valores a sus variables de entrada y salida. Concluyendo, el estado de ejecución de UM transacción multibase de datos, en cualquier instante de tiempo, es la unión de los estados de sus subtransacciones, los valores de todas sus variables de entradaísalida y todas las variables dc dependencia especificas. En la figura 1.7 se ilustra la representación general de UM subtransacción.

SGBD - Sistema de aestión de Bap de Data

Figura 1.7 Representación General de una Subtransacción

En cuanto a las variables de dependencia de las subtransacciones componentes, éstas se pueden dividir en tres grandes partes :

1. Las dependencias de ejecución se refieren a las restricciones de ejecución derivadas de la semántica de la aplicación. Por ejemplo, la subtransacción S3 se ejecuta si la ejecución de S I fue exitosa.

2.- Las dependencias de valor Ocurren cuando la variable de entrada de UM subtransacción corresponde a la variable de salida de otra. En este caso las subtransacciones se ejecutan en forma secuencial. Es obvio que si no existe dependencia de valor (ni de ejecución) las subtransacciones podrían ejecutarse en paralelo.

28

3.- Las dependencias temporales son necesarias cuando alguna subtransacción tiene restricciones temporales para su ejecución. Es decir, su ejecución depende de la ocurrencia de eventos temporales.

Por otro lado, para paliar las dificultades'surgidas de la larga duración de las transacciones multibase de datos, es necesario analizar en detalle los requerimientos de atomicidad de falla de estas. En la noción tradicional de atomicidad de falla, es suficiente con que UM subtransacción falle para que la transacción global también fracase. Sin embargo, en transacciones muitibase de datos, para muchos casos, es posible superar la falla de .UM subtransacción al ejecutar otra equivalente. Por lo tanto, lo indicado seria'que el diseñador de la transacción global pudiera especificar los requerimientos de atomicidad de falla. El sistema, a su vez, garantizaría que la ejecución de la transacción terminaria en un estado que satisfaga la atomicidad de falla definida. Estos estados constituinan los estados de terminación aceptables.

De acuerdo con las consideraciones anteriores, para especificar UM transacción multibase de datos, el diseñador tendrá que definir los siguientes componentes estructurales :

I , La tarea a realizar por la subtransacción (S) 2 . Las condiciones de dependencia asociadas a cada subtransacción (CD) 3. El conjunto de estados de terminación aceptables (EA)

El ejecutor es un módulo que planifica la ejecución de transacciones multibase de datos, y envia las subtransacciones componentes a los SGBD's locales. Su función principal es hacer respetar las dependencias entre subtransacciones y garantizar el arribo a un estado de terminación aceptable de la transacción multibase.de datos. No se debe. confundir la función del ejecutor con la del controlador de concurrencia. El ejecutor asegura la ejecución correcta de las transacciones globales de acuerdo con su semktica especificada, mientras que el controlador de concurrencia global resuelve los conflictos entre subtransacciones de múltiples transacciones multibase de datos preservando la consistencia global.

En la figura I .8 se muestran los componentes de las etapas de especificación y ejecución de las transacciones multibase de datos.

29

Especificación ~ I Ejecución 1 I I

I

I

I I

I I I I I

I I

I

I I

Entorno I Ejecución

Ejecutor

l I A /’ I I I I I I I I

S - Tarea a realizar por la subtransacción

CD - condiciones de dependencia entre subtransacciones

EA - Estados aceptables de la transacción global

Tg - Transacción global

Figura 1.8 Etapas de Especificación y Ejecución de las Transacciones Multibase de Datos

30

1.5.3 EL MODELO DE TRANSACCIONES FLEXIBLES

El modelo tradicional de transacciones no es adecuado para sistemas multibase de datos, pues pretende preservar las propiedades ACAD sin considerar caracteristica alguna del entorno de aplicación. Por el contrario, en la sección anterior (1.5.2) se him énfasis en capturar la semántica del entorno multibase de datos. Como resultado de esta reflexión se esbozó un modelo general que

muestra la naturaleza cooperativa y de larga duración de.las transacciones multibase de datos. La distinción coopcrativa conduce a la especificación obligatoria de dependencias entre subtransacciones. En el mismo sentido, la peculiaridad de larga duración debe ser contrarrestada con técnicas compensatonas y con la definición.de requerimientos de atomicidad de falla acordes con la aplicación particular.

El modelo de transacciones flexibles [ELLR90], [LEE901 y [RELL90], fué definido expresamente para modelar el comportamiento de transacciones en sistemas multibase de datos. Su estructura y semintica son similares a los lineamientos descritos en la sección anterior, y en particular extiende el modelo de transacciones tradicional para incluir la fonpdación de :

alternativas. dependencias y compensabilidad.

1.5.3.1 ALTERNATIVAS

Con frecuencia los usuarios de multibase de datos disponen de alternativas funcionalmente equivalentes p a n alcanzar sus objetivos. Atendiendo este hecho el modelo de t&sacciones flexibles permite expresar diferentes trayectorias alternativas para llevar a cabo un objetivo particular, incrementando asi la capacidad de recuperación de fallas. La posibilidad de altematividad se ilustra con el ejemplo siguiente :

Ejemplo 1 ' Considere un sistema de información para agencias de viajes (AV) [Gra81]; una transacción global en este sistema puede consistir de las siguientes tareas :

I AV negocia con las lineas aéreas para comprar boletos de avión. 2 AV negocia con las compañías de renta de autos para reservar vehiculos. 3 AV negocia con los hoteles para reservar cuartos

31

Se supone que para propósitos de viaje existen dos compañías de líneas aéreas (Aeroméxico y Mexicana), una compañía de renta de autos (Hertz) y tres hoteles (Hilton, Sheraton y Ramrlda). El agente de viajes puede planear el itinerario considerando las siguientes tareas :

1. Ordenar un boleto de Aeroméxico o Mexicana, 2. Rentar un auto de Hertz. 3. Reservar un cuarto en alguno de los tres hoteles citados

Estas tres tareas pueden ser descompuestas respectivamente en los conjuntos ti,tz), (b y

t4,t<,t6), donde las t, 's son definidas como sigue :

ti

t 2

ti tr

ts

16

Ordenar un boleto de Aeroméxico; Ordenar un boleto de Mexicana; Rentar un auto de Hertz; Rcscrvar un cuarto en el Hilton; Reservar un cuarto en el Sheraton; Reservar un cuarto en el Ramada.

En el ejemplo anterior se usa el término tarea para denominar UM función especifica que se desea ejecutar. As¡ pues, comprar un boleto es una tarea. Si dos subtransacciones se designan para realizar la misma tarea, entonces se dice que son funcionalmente equivalentes. De esta,manera, ti y t 2 son dos subtransacciones funcionalmente equivalentes para la tarea de ordenar un boleto. También se dice que una tarea se ejecuta exitosamente si alguna de las subtransacciones equivalentes es ejecutada exitosamente. Asimismo una transacción es exitosa si todas sus tareas se ejecutan exitosamente. La ,meta de UM transacción flexible T, se define como el conjunto. de subtransacciones que satisfacen sus requerimientos al ejecutarse todas exitosamente. Por ejemplo, el conjunto (ti,ti,t.i,es una de las metas aceptables en el sistema de información de la agencia de viajes.

1.5.3.2 DEPENDENCIAS

Considere un conjunto T de subtransacciones , tal que T = ti,t2, , . . ,h. La ejecución de una subtransacción t, puede depender de la falla o el éxito de ejecución de otra subtransacción, y adcmás también puede depcnder de algunos parámetros externos (tales como el tiempo). En forma más precisa las dependencias se definen como :

32

Dependencia de éxito : La subtransacción ti mantiene dependencia de éxito con la subtransacción tJ. si 18 pucdc ser ejecutada únicamente después de que tJ ha sido ejecutada cxitosamcnte.

Dependencia de falla : La subtransacción ti mantiene dependencia de falla con la

subtransacción tj, si ti puede ser ejecutada únicamente después de que la ejecución de tj ha fracasado.

Dependencia externa : Sea X un conjunto de parámetros (X es disjunto de T). La subtransacción ti mantiene dcpendencia externa con X, si la ejecución de ti depende de que un predicado de X sea verdadero.

Si en el ejemplo previo se reemplazan tz, ts y ts por las subtransaccioncs' t'2, t's y t's

respectivamente las cuales se definen a continuación:

t'z

t'<

t's

Ordenar un boleto de Mexicana, Si ti falla; Reservar un cuarto en cl Shcraton, entre las 8AM y las 5PM; Reservar un cuarto en el Ramada. si ti es exitoso.

Se puede observar que en el conjunto T = ti, t'z, t3, t4, t'5, t 1 6 , t'z manticne dependencia de falla con ti, t'5 tiene dependencia dc tiempo y t '6 mantiene dependencia de éxito con ti.

1.5.3.3 COMPENSABILIDAD

Como se ha estipulado en las secciones anteriores, las transacciones multibase de datos pueden ser de larga duración. En [Gra8 I ] se describen los problemas de eficiencia y atomicidad originados por la exigencia de un aislamiento estricto en aplicaciones de larga duración. Es por ello que la granularidad dcl aislamiento de la transacción global debcrá ser reducida. Para resolver estos inconvcnientes [GraS ¡] propone asociar a cada subtransacción componente una subtransacción compcnsatoria. la cual. si es requerido, "nulifique" semánticamente los efectos de una subtransacción coinpromctida. Estc concepto permite que la transacción global revele sus

rcsultados (parcialcs) a o t r a transaccioncs antcs de compromcterse. AI hacer esto, la granularidad del aislamiento de la transacción global se rcduce a nivcl subtransacción en lugar dcl tradicional mancjo a nivel dc transacción global. Una transacción global compuesta únicamente de subtransaccioncs conipcnsables se Ilania Saga [GMSX7]. Sin embargo, en el mundo real no todas

33

las subtransacciones pueden ser compensadas. Por ejemplo, las' subtransacciones que controlan acciones en tiempo real (por ejemplo, retiro de un cajero automático) tipicamente son no compensables.

Para incluir subtransacciones compensables, en el modelo de transacciones flexibles se introduce el concepto de "tipos" de subtransacciones. Así pues, UM transacción flexible puede estar compuesta por dos tipos de subtransacciones : Compenssbles y no-compenssbles. A las subtransacciones compensables se les permite comprometerse antes de que la transacción flexible se comprometa (commit), mientras que el compromiso de las no-compensables debe esperar UM

decisión global. Cuando se toma la decisión de abortar una transacción flexible, las subtransacciones activas y las subtransacciones no-compensables en espera de una decisión global son abortadas, mientras que las subtransacciones compensables ya comprometidas son compensadas. En este sentido las transacciones flexibles son diferentes de las transacciones S [EVT88] o Sagas [GMS87], las cuales únicamente permiten subtransacciones compensables.

Hasta aquí las transacciones flexibles cubren el amplio espectro desde Sagas (que suponen compensabilidad de todas las subtransacciones) hasta las transacciones distribuidas tradicionales (que suponen subtransacciones no-compensables). Las transacciones flexibles son más poderosas, pues permiten la convivencia de subtransacciones compensables y no compensables.

1.5.4 ESTRUCTURA Y EJECUCION DE LAS TRANSACCIONES FLEXIBLES

En la seccion anterior se describieron las tres eitensiones (alternativas, dependencias y compensabilidad) consideradas en el modelo de transacciones flexibles. Ahora corresponde analizar en detalle su estructura funcional y la evolución en sus estados de ejecución.

1.5.4.1 LA ESTRUCTURA FUNCIONAL

Una subtransacción'se designa de tipo C si es compensable y NC si es no-compensable.

Una transacción flexible se define formalmente como una 5-tupla (B,S,F,Y,G), donde :

B = (ti, h. . . ., t.) es el conjunto de todas las subtransacciones de T, donde cada t, puede ser de tipo C (compensable) o NC (no-compensable).

34

S indica la dependencia de éxito en B. F indica la dependencia de falla en B.

indica el conjunto de predicados externos sobre B. G c p(B) cs el conjunto de todas las metas aceptables de T, donde p(B) denota el conjunto de metas posibles de B.

En la definición de'amba S implica un orden de ejecución secuencial; (&,ti) E S (denotado por ti;tj) significa que t; mantiene UM dependencia de éxito con ti. De manera similar F también implica un orden de ejecución secuencial. (ti,tj) E F (denotado por ti$) significa que tj mantiene una dcpendencia dc falla con ti. Las definiciones previas se pueden ilustrar haciendo uso del ejemplo anterior de la agencia de viajes.

Ejemplo 2 : Considere la transacción global del ejemplo 1, a la cual se aiiade lo siguiente : (1) las subtransacciones que ordenan boleto son no-compensables; (2) además estas subtransacciones deben ejecutarse en horario de negocios de 8am a 5pm, y t3 podrá ser ejecutada únicamente después de que ti fallo; (3) la subtransacción rentar un auto podrá ser ejecutada Únicamente después de laejecución de la subtransacción ordenar un boleto, mientras que la ejecución de la subtransacción reservar un cuarto estará cbndicionada por un costo de $100 dólares: ( 5 ) la transacción global es exitosa si las subtransacciones ordenar boleto, rentar auto y reservar cuarto son exitosas. Esta transacción global de agencia de viajes se formaliza en la siguiente transacción flexible :

B = (tiOlJC), WW. t3(C), W ) , W ) , W ) s = ti$3, t2$3 F = ti:tz

i 7 = P,Q) donde P y Q son dos predicados definidos por. : P = (8 < time(ti) < 17, 8 < time(t2) < 17)

Q = (cost(@) < $100, cost(ts) < $100, cost(ts) < $100)

G = ( I t l ,k@I. ti,t%tS), (tl,h,t6), f2,h,f4), b,D,t~), tZ,tl,k)

1.5.4.2 ESTADOS DE EJECUCION.

Después de definir la estructura de las transacciones flexibles corresponde ahora especificar sus reglas de ejecución. De antcmano es necesario definir sus estados de ejecución.

35

Para una transacción flexible T compuesta por m subtransacciones, su estado de ejecución x es

una m-tupla (X IJ~, ._.. x"), donde :

xi =

- N si la subtransacción ti no ha sido remitida para su ejecución; E si ti está siendo ejecutada, S si ti ha sido exitosamente completada; F si ti ha fallado o ha sido completada sin haber llevado a cabo

- su objetivo;

Para una subtransacción compensable el estado "exitosamente completado" significa que la subtransacción se ha comprometido, mientras que para una no-compensable significa que ésta se encuentra en el estado preparado para compromekrse (útil para sistemas software que disponen del protocolo 2PC). Este estado de ejecución se usa para registrar el estado de las ejecuciones de las subtransacciones de una transacción flexible. En consecuencia, se dice que la ejecución de una transacción flexible es exitosa, si ha alcanzado un estado de ejecución que satisfaga alguna meta equivalente del conjunto de metas posibles. Más especificamente, un estado de' ejecución x será aceptable si existe una meta gi E G, tal que. V tk E gi XL = S en x. En otros términos, una transacción flexible es exitosa si alcanza un estado aceptable, donde el conjunto de estados

aceptables es un subconjunto de todos sus posibles estados de ejecución.

1.5.4.3 LA EJECUCION DE TRANSACCIONES

El estado de ejecución de una transacción flexible evoluciona de acuerdo con los estados de ejecución por los cuales transiten las subtransacciones componentes.

Una subtransacción ti es elegible para transitar a un determinado estado de ejecución si no ha sido ejecutada (xi = N), si las subtransacciones con las que ti tiene dependencia de éxito han sido ejecutadas exitosamente, si las subtransacciones con las que ti tiene dependencia de falla han sido ejccutadas y han fracasado y todas sus dependencias externas son satisfechas.

Con base en la descripción anterior, es posible formular las reglas de ejecución de UM transacción flexible, de la siguiente manera :

procedure Ejec-transacci6n-flex(in:T, out:R)

1.- Inicializar x := (N,N, .,., N), R :=O y

2.- Mientras R = O y EXEC 0 O'

begin

Calcular el conjunto EXEC de todas las subtransacciones ejecutables;

ejecutar concurrentemente todos los elementos de EXEC; wlocar la respuesta en x (xi = el estado de ejecución de ti); si xes un estado aceptable, entonces R = (x;

de lo contrario abortar 3.- Si R#O entonces comprometer la transacción flexible

end

AI analizar estas reglas de ejecucibn se obsenia que se permite la ejecución concurrente de subtransacciones. Cuando se conocen los resultados de ejecución, en consecuencia se~modifica el estado de ejecución de la transacción. Después de que se completa la transacción se verifica si esta ha alcanzado un estado aceptable. Si un estado aceptable ha sido alcanzado, entonces se compromete la transacción flexible . Pero si la transacción flexible termina sin haber alcanzado un estado aceptable (por ejemplo EXEC = O), entonces se aborta.

CAPITULO 2

DISEÑO DEL SISTEMA

38

En este trabajo se entiende por aplicación global una aplicación distribuida que requiere de acceso integrado, consistente y confiable a múltiples y autónomos sistemas de.información heterogéneos. En contraste una aplicación local accesa en forma consistente y confiable un sólo sistema de.informaci6n. Pam asegurar la convivencia de. aplicaciones globales y locales es imprescindible respetar la autonomia de los sistemas software componentes (SGBD, SGA, SGBC, ...). Una descripción detallada del concepto de autonomia se encuentra en la sección 1.4.2 . En la arquitectura conceptual del proyecto ELECTRA se incluyen agentes de interoperabilidad que permiten preservar la auionomia local de los sistemas software (ver sección 1.2.2). En este capitulo se aborda UM posible solución a la problemática del acceso integrado, consistente y confiable.

El principio fundamental del acceso integrado se basa en la interoperaci6n de los sistemas software locales. El término interoperación significa que las operaciones de procesamiento en los diferentes sistemas software mantienen relaciones de cooperación que requieren de intercambio de datos entre si. Una operaci6n denota cierto procesamiento a realizar por el sistema software de acuerdo con su interíaz de ejecución (SQL para SGBD's relacionales, Macros para hojas de cálculo, funciones para SGA's, ,..). El pro&samiento de la operación es indicado por la especificación de una tarea. Si la operación se lleva a cabo en forma consistente.^ confiable, entonces se trata de UM subtransacción. 'El conjunto de subtransacciones constituyen UM

transacci6n o aplicaci6n global.

Por lo tanto, para lograr interoperación de sistemas software es necesario coordinar la ejecución y cooperación de sus subtransacciones. A la entidad coordinadora la hemos denominado con el nombre de ejecutor, cuya visión global y transparente requiere de actividad central. En realidad el ejecutor coordina indirectamente los sistemas software. Realiza acciones de ejecución, sincronización y control de las subtransacciones, las cuales envia directamente a los agentes de intcroperabilidad mediante las primitivas de comunicación: IniciaSeMcio, RealizaSeMcio y TerminaServicio.

Hasta aqui la idea de interoperación es interesante, ¿pero qué falta?. En alguna ocasión el filósofo Wingenstein dijo "si una idea merece discutirse, entonces amerita tener un lenguaje para hacerlo". En efecto, se requiere de un lenguaje de interoperación que permita al usuario programador describir su aplicación global sin importar la heterogeneidad de los sistemas software componentes. A partir de esta especificación global (que incluirá indicaciones de coordinación, sincronización y control), algún módulo traducirá a una representación intermedia, estructuraW las subtransacciones. las pasari al ejecutor, el cual previa consulta del diccionario global y solicitud

de acción al controlador de concurrencia global, las remitirit a los agentes de intemperabilidad considerados para su ejecución adecuada.

En la figura 2.1 se ilustran los diversos requerimientos para lograr acceso integrado, consistente y confiable, haciendo uso de la interoperación de los sistemas software locales.

4 -Ejecutor Conmladorde Diccionario ,/ Concurrencia Global Global

Figura 2. I Acceso Integrado Mediante Interoperación

En este capitulo se describen las caractensticas del lenguaje de interoperación IPL, el diseño de sus etapas tmductor-ejecutor y sus interacciones con el diccionario global, controlador de concurrencia global y agentes de interoperabilidad.

40

2.1 PARTICULARIDADES DEL SISTEMA IPL

Los lenguajes de programación distribuida de carácter general (LiNDA, CONIC, ...) no son adecuados para desa-llar aplicaciones globales en entornos de múltiples y autónomos sistemas de información heterogeneos. Esto se debe a dos causas principales : 1) no fueron concebidos para operar de acuerdo con el paradigma transaccional, y 2) carecen de operaciones complejas de acceso a datos. Debido a estos dos grandes obstáculos parecería &s razonable una alternativa de lenguaje que coordine, en lugar de que ofrezca instrucciones generales de programación, actividades transaccionales distribuidas. Estas actividades transaccionales se refieren al acceso consistente y confiable a diversos sistemas software, por lo que es deseable que su especificación se realice en el lenguaje nativo de cada sistema involucrado.

En esta sección se describen las' caractensticas particulares del lenguaje IPL, así corno los lineamientos establecidos para elaborar el diseño del sistema IPL.

2.1.1 DESCRlPClON DEL LENGUAJE IPL

El lenguaje IPL (1nterbase.Parallel Language) fue diseñado en la Universidad de hrdue [BCC92] p a 4 propósitos de acceso integrado, consistente y confiable. IPL mapea el modelo de transacciones flexibles ([ELLR90] ver sección 1.5.3) en un lenguaje de programación. Por lo que es un lenguaje transaccional orientado a entornos multibase de datos que permite representar especificaciones de transacciones flexibles. Esto es, las propiedades de compensabilidad, alternatividad y dependencia pucden fácilmente ser implantadas en IPL. Además ofrece la posibilidad de ejecución paralela de subtransacciones. Permite la coexistencia de subtransacciones compensables, noampensables y con restricciones temporales. También proporciona un protocolo de atomicidad basado en la semántica de fallas de la aplicación global. En resumen el lenguaje IPL no sólo coordina multibase de datos sino sistemas en general (pues las operaciones de las subtransacciones se codifican en el lenguaje nativo del sistema software) y proporciona en forma integrada la gestión de transacciones y el procesamiento de consultas.

2.1.1.1 COMPONENTES DEL LENGUAJE IPL

IPL contiene cuatro componentes fundamentales : I) objetos y tips, 2) definiciones de subtransacciones, 3) descripciones de dependencias entre subtransacciones, y 4) conjuntos

41

aceptables Estos componentes soportan no sólo el modelo de transacciones flexibles sino también proporcionan otras capacidades.

Objetos y tipos La ejecución de una subtransacción produce un objeto, el cual podia enviane como resultado

a un usuario, transfenne como parametro de entrada a otra subtransacción o ser evaluado por el guardia de alguna subtransacción. Por otro lado, el tipo especifica la clase de resultado que UM

subtransacción exitosa puede producir. El tipo puede ser un elemento básico : entero, real, cadena; complejo homogéneo : arreglo de enteros; e inclusive complejo heterogéneo : enteros mezclados con reales y cadenas.

Por ejemplo, para definir el tipo producido por la subtransacción Sheraton se hana :

class room of customer : charstring; rooniNo : charString: cost : real: time : charstring;

endclass:

Donde room corresponde al nombre del tipo; class, of y endclass son palabras reservadas de IPL

Definicibn de Subtransacciones En IPL una subtransacción es una tarea a ejecutar sobre un sistema software local. La

subtransacción puede requerir como entrada los resultados de otras subtransacciones. La subtransacción también puede ser ejecutada bajo restricciones particulares de tiempo u otras condiciones. Una subtransacción debe declararse con un identificador Único dentro del contexto de la transacción global. La naturaleza de una subtransaccion se especifica por los siguientes parhetros :

I .- La opción de parámetros de entrada de una subtransacción se especifica por el nombre de otra subtransacción además del suyo. Esto se necesita cuando el resultado ,de una subtransacción es la entrada de otras subtransacciones.

2.- Su tipo de resultado.

42

3.- El nombre del sistema software bajo el cual se ejecutará la subtransacción.

4.- El nombre de la máquina hacia donde se remitirá la subtransacción para su ejecución

5.- Las opciones de tiempo incluyen el tiempo de inicio, tiempo de terminación, periodo de tiempo válido para su ejecución, y tiempo de ejecución. Esta caracieristica soporta predicados temporales [ELLR90] y restricciones de timeout.

6.- La opción de guardia para otras condiciones de ejecución, a definir por el usuario.

7.- El cuerpo de operaciones de la subtransacción.

8.- El cuerpo de una operación commit. Esta opción se ejecuta cuando la subtransacción es instruida a comprometerse en función de la atomicidad global.

9.- El cuerpo de UM' operación undo, cuya opción se ejecuta cuando la subtransacción es abortada.

Los predicados externos sobre una subtransacción pueden ser expresados por los parámetros 5 y 6, esto es, restricciones de tiempo y guardias. Por ejemplo, se puede definir una subtransacción para ordenar un boleto de avión como sigue :

subtrans order-ticket (user-igfb) : tickel use Sybase at order.aa.com between 8:OO to 17:OO beginexec

endexec beginconfirm I* operaciones para cuando se compromete *I

endconfirm beginundo I" operaciones para cuando se aborta "I

endundo

texto de las operaciones para reservar un boleto

texto de las operaciones para confirmar la reservación

texto de las operaciones para cancelar la reservación

endsubtrans

En este ejemplo el tipo de salida de la subtransacción order-ticket es rickel, lo cual indica que se regresa un objeto ticker como resultado si la subtransacción es exitosa. El sistema software local es el SGBD Sybase, el cual opera sobre la' máquina denominada order.aa.com. Además. se rcstringue la ejecución de la subtransacción al periodo entre las 8:OO y 17:OO horas. El resultado de la subtransacción user-infi es la entrada de esta subtransacción y le proporciona información

43

relacionada con el usuario : nombre del usuario y las ciudades de origen y destino: El cuerpo de las operaciones de la subtransacción, el cuerpo de la operación commit, y el cuerpo de la operación undo se definen respectivamente por las palabras reservadas de IPL : beginexec y endexec (la construcción <executing>), beginconfirm y endconfirm (la construcción <confirm>), y beginundo y endundo (la construcción <undo>).

Descripción de Dependencias La descripción de dependencias, el tercer componente de IPL, proporciona un mecanismo para

la especificación de dependencias explícitas entre las subtransacciones de una transacción global. Con esta facilidad se pude definir el orden de ejecución de las subtransacciones de una transacción global. Por ejemplo, suponga las siete subtransacciones ci, Cz, C3, C4, cs, Cs y C7, con el siguiente orden de ejecución :

I . cz pude ser ejecutado únicamente si ci es exitoso 2. C3 puede ser ejecutado unicamente si Ci falla. 3. C4 puede ser ejecutado únicamente si Cz o C3 es exitoso 4. Cs pude ser ejecutado únicamente si Cz o C3 es'exitoso. 5. C6 puede ser ejecutado únicamente si C3 y C4 son exitosos o si Cs falla. 6. la transacción global es exitosa si al menos dos de las subtransacciones C4, Cs y C6 son

exitosas.

L a descripción de dependencias IPL para estas subtransacciones puede ser :

dependency ci : cz: not Ci : C3; Ci or C3 : C4: C2 or C3 : Cs; (0 and C4) or not Cs : C6; (2 : Cd, Cs, c6) : accept;

en'ddep

Cada programa IPL debe tener una descripción de dependencias que se inicia con la palabra rcservada dependency y termina con enddep. Una descripción de dependencias incluye uno o más pares de dependencias, cada uno de los cuales consiste de UM expresión booleana o UM expresión de éxito parcial, una coma, y un identificador de subtransacción. Lasubtransacción dependiente dc la expresión booleana o expresión de éxito parcial es elegible para ser remitida a ejecución

44

Únicamente después de que su expresión es verdadera (true). Si su expresión.es falsa valse), entonces se rechaa su ejecucibn como si hubiera failado. Si UM subtransacción no depende de alguna otra subtransacción, entonces puede ser remitida a ejecucih inmediatamente. En este ejemplo CI se ejecuta primero. Si es exitosa, entonces se ejecuta Cz; en caso contrario, se ejecuta Ci. Y si Ci o CI son exitosas, entonces C4 y Cs se ejecutan simultáneamente. Si C3 y C4 son exitosas y cs falla, entonces se ejecuta c6. si ai menos dos subtransacciones de entre G, cs y Cs son exitosas, entonces la transacción global es exitosa; en caso contrario la transacción global falla. La palabra reservada accept indica el estado de éxito/falla de la transacción globd (GO. Si este valor es irue, entonces GTes exitosa, pero si esfalse, entonces GTfalIó; en caso contrario GT sigue en ejecución hasta que accept sea true ofase

La descripción de dependencias de IPL soporta situaciones de éxito y de falla de las transacciones flexibles. Pero adicionalmente este mecanismo permite especificar dependencias explícitas más complicadas que las que puede soportar el modelo de transacciones flexible. Es por ello que IPL representa además una extensión del modelo de transacciones flexibles.

Estados Aceptables Los estados aceptables, el cuarto componente de IPL, se inician con la palabra reservada

acceptable-sets y terminan con la palabra reservada endaccs. Un estado aceptable coniiste de una lista de subtransacciones y de una condición aceptable suficiente de la transacción global. Cuando u ~ . t ~ ~ ~ a c c i ó n global alcanza un estado final, el usuario debe elegir el estado aceptable de su preferencia de entre varios posibles. Todas las subtransacciones de un estado aceptable deben ser exitosas. Las subtransacciones exitosas no compensables se mantienen en un estado no comprometido hasta que la transacción global se completa. Cuando la transacción global se compromete, las subtransacciones no comprometidas en el estado 'aceptable ejecutan SUS

operaciones commit, todas las subtransacciones no comprometidas ejecutan sus operaciones abort, y las subtransacciones compensables que no están en el conjunto aceptable ejecutan SUS

operaciones compensatonas. Si la transacción global decide abortar, entonces todas las subtransacciones exitosas ejecutan sus operaciones de aborto o de compensación.

Los estados aceptables reflejan las funciones aceptables de las transacciones flexibles y soportan con ello la duplicación de funciones, permitiendo tolerar fallas de subtransacciones individuales al explotar la capacidad de diversos sistemas software de poder realizar la Ksma función. Para el ejemplo de las siete subtransacciones los estados aceptables son :

4s

En este ejemplo se incluyen cinco estados aceptables : (Ci,Cz,G,Cs), (cl,c2,6,c6), (CI,O,C~,C~), (C%Cd,Cs), y (CsG,C6). El éxito de cualquiera de ellos puede llevar al éxito de la transacción global, proporcionando así duplicación de funciones en la transacción global.

Sin embargo, es importante observar que CI y C3 son excluyentes, por lo que habrá a lo más tres estados aceptables para elegir alguno entre ellos. Obviamente los estados aceptables elegibles no deberán incluir subtransacciones fracasadas. Finalmente todas las subtransacciones del conjunto elegido deberán ser comprometidas, mientras que todas las otras subtransacciones deberán ser aboriadas.

.

2.1.1.2 EL PROTOCOLO DE ATOMICIDAD GLOBAL BASADO EN LA SEMANTICA DE LA APLICACION

La atomicidad de una transacción global implica que todas las operaciones efectuadas por sus subtransacciones componentes se validen (comprometan) o se cancelen (aborten) con objeto de mantener consistencia global a pesar de posibles fallas. Para el caso de una transacción flexible el

principio de atomicidad global podria enunciarse de la siguiente manera : es necesario validar (comprometer) sólo aquellas subtransacciones que satisfacen el estado aceptable elegido, las restantes deberán cancelarse (abortarse o compensarse).

El protocolo de compromiso en dos fases (2PC : two phase commit) fue propuesto para controlar el compromiso atomico de transacciones en sistemas de bases de datos distribuidas homogéneas, en presencia de fallas (ver apéndice D). Sin embargo, para aplicar 2PC a sistemas multibase de datos es imperativo solucionar al menos dos problemas : 1) algunos SGBD's no proporcionan un visible estado preparado para compromiso (ver apéndice D), el cual es necesario para implantar 2PC, y 2) aun si todos los SGBD's proporcionaran un visible estado

preparado para compromiso, el 2PC podria violar seguramente la autonomía local al bloquear los sistemas participantes por períodos indefinidos de tiempo. Estos obstaculos obligan a explorar protocolos de atomicidad global más adecuados a multibase de datos.

46

Por otro lado, la semántica de UM subtransacción puede conducir a diferentes protocolos de atomicidad. Por ejemplo, una subtransacción compensable se comprometerá inmediatamente después de realizar sus operaciones sin esperar el final de la transacción global. De manera distinta, UM subtransacción noampensable; después de terminar sus operaciones esperará la decisión final de la transacción global. UM solución deseable buscaria determinar el protocolo de atomicidad global requerido para una aplicación específica operando sobre ciertos SGBD's. Es decir, ¿Los SGBD's participantes ofrecen 2PC visible? si es afirmativo, ¿Se trata de la implantación del mismo protocolo o existen diferencias?. Si un SGBD no soporta 2PC visible, entonces podría haber dos situaciones : I ) que el SGBD comprometa automáticamente sus operaciones (sin necesidad de commit explícito), o 2) que disponga de commit/abort explicitos. Del análisis integrado de la semántica de la subtransacción y de la (no) disponibilidad de 2PC resultana el protocolo de compromiso adecuado.

Con las construcciones del lenguaje IPL executing>, <conjrm>, y urndo> el usuario podría definir sus propios protocolos de atomicidad global basados en la semántica de las subtransacciones y en la disponibilidad de protocolos de atomicidad individual de los SGBD's pahicipantes. Obviamente el ejecutor del sistema IPL (ver sección 2.4) coordinaría las especificaciones vertidas por el usuario.

Para entender el protocolo de atomicidad global basado en semántica es necesario primero introducir el concepto de los estados de reserva. Desde un 'estado de reserva una subtransacción puede fácilmente ser nuiificada sin causar inconsistencias. Por ejemplo, en 10s sistemas de reservación de lineas aéreas es posible reservar u ordenar un boleto. El proceso de reservación requiere de confirmación en un periodo especificado, sin causar algún cargo por cancelación. En contraste, la cancelación de un boleto ordenado o es imposible u ocasiona algún recargo determinado. "Un boleto reservado" es un ejemplo de un estado de reserva para una subtransacción que ordena un boleto de avión.

De estas observaciones se puede inferir lo siguiente : un estado de reserva puede ser el estado de UM subtransaccion no compensable justo antes de su compromiso, el estado de UM

subtransacción compensable justo después de su ejecución, y cualquier estado de una

subtransacción de consulta exclusiva. En consecuencia, UM subtransaccion puede tener diversos estados de reserva. Sin embargo, sólamente uno entre ellos podrá ser alcanzado durante la ejecución de la subtransacción, por lo que se le conocerá como el mejor estado de reserva de la subtransacción. Por ejemplo, para una subtransacción que ordena un boleto de avión, "un boleto reservado" es su mejor estado de reserva.

47

El mejor estado de reserva es crucial para la deftnición de la ejecución parcial de la subtransacción (EPS), de la confirmación parch1 de la subtransacción (CPS) y de 'la nulificación parcial de la subtransacción (NPS). Para el caso de alguna subtransacción, el EPS incluye todas SUS operaciones desde el inicio hasta el mejor estado de reserva; el CPS contiene operaciones a partir del mejor estado hasta el compromiso y el NPS considera aquellas operaciones desde el mejor estado hasta el aborto. En breve, para UM subtransacción que ordena un boleto de avión : "reserva boleto" es el EPS, "ordena boleto reservado" el CPS y "cancela boleto reservado" el NPS.

En IPL la construccion <executing> indica un EPS, <confirm> un CPS y urndo> un NPS

El mejor estado de reserva se obtiene de la semántica, más que de la sintáxis de UM

subtransacción. Es por ello que es razonable que el usuario defina el mejor estado de reserva de una subtransacción y. por ende, los convenientes EPS, CPS y NPS. Este enfoque es lo que se denomina Protocolo de Compromiso Basado en Semántica.

Ahora es necesario "aternzar" estos conceptos y determinar los EPS, CPS, y NPS para diversos tipos de subtransacciones .

I ) Para una subtransacción compensable (Si) [GMSj, KL90] el mejor estado de 'reserva es por definición el estado después de la ejecución de Si. Por lo tanto su EPS es Si en sí, su NPS podría ser la subtransacción compensatoria para Si, y no se necesita definir CPS alguno para Si.

2) Si SI es una subtransacción de consulta exclusiva, o el dato modificado por S, no necesita ser consistente, entonces Únicamente el EPS para St debe ser definido. Para este caso el EPS es S, en sí

3) Cuando se trata de una subtransacción noampensable (Sj) de una transacción global fin). El EPS de S; alcanza el mejor estado de reserva. Durante la etapa final de ejecución de Ti, el usuario elige comprometer o abortar Si. En el primer caso se usa el CPS para completar Sj y comprometerlo, en el segundo el NPS nulifica la ejecución del EPS.

Independientemente del número de subtransacciones parciales definidas para UM

subtransacción (SJ, IPL deberá ejecutar pnmero el EPS. Para el estado final de la transacción global, si S, deberá ser comprometido y su CPS es definido, entonces el CPS será remitido para

48

comprometer SI; por el contrario, si Si deberá ser'abortada y su NPS es definido, entonces el NPS será remitido para nulificar Si. La estructura semántica de IPL delega en el usuario la responsabilidad de definir el mejor estado de reserva, así como el EPS, CPS, y NPS requeridos. A partir de esta dcfinición IPL (su ejecutor) determina el tipo más apropiado de operación de compromiso.

2.1.1.3 UN EJEMPLO DE PROGRAMACION

A continuación se muestra un programa que ilustra las capacidades de IPL para soportar aplicaciones modeladas por transacciones flexibles.

Considere un profesor que intenta asistir a un ciclo de conferencias que se darán en el Hotel Sheraton de'San Francisco del 4 al 6 de Agosto de 1993. Una transacción global para este itinerario podria consistir de los siguientes objetivos :

Proporcionar información como su nombFe, origen y destino del viaje, tiempos de estancia y de retorno, y tipo y número de tarjetas de crédito posibles con las cuales se pagana el boleto 'de avión;

Contactar compañías de aviacih para consulta de vuelos;

Contactar el Hotel Sheraton para la reservación de un cuarto; y

Contactar las compañias de tarjetas de credit0 para pagar el boleto de avión.

Se supone que para viaje se contactan tres compañías de aviación (USAir, United, y American) y una de tarjetas de crédito (VISA).

También se supone que el profesor tiene las siguientes prekrencias :

I . Ordenar un boleto de avión de United Airlines o American Airlines únicamente si no hay boleto disponible en USAir.

2. Reservar un cuarto en el Sheraton únicamente si hay boleto de avión disponible. Si no hay boleto de avión disponible, entonces no asistirá al ciclo de conferencias.

49

3. Reservar un cuarto en el Sheraton antes de las 3:OO p.m. del 3 de Agosto de 1993. Si no se

le reserva un cuarto para esa fecha, entonces no hará el viaje.

4. El costo del boleto de avión deberá ser menor o igual a $350, pues es el limite miximo de su presupuesto.

Los cuatro objetivos pueden ser descompuestos en cuatro conjuntos de subtransacciones (user), (usair, united, american, (sherafon), y (visa), donde éstas se definen como sigue :

user :

usair :

united : american ;

sherafon :

visa:

obtener la información del usuario; Ordenar un boleto de USAir; Ordenar un boleto de United Airlines; Ordenar un boleto de American Airlines Reservar un cuarto de Sheraton; Pagar el boleto de avión con VISA;

Como se indicó en las preferencias del cliente, existen dependencias explicitas entre las subtransacciones usair, united, american, sherafon, y visa, las cuales pueden ser definidas como sigue : las subtransacciones unifed y american deben ser ejecutadas únicamente si la ejecución de la subtransacción usair falló, la subtransacción sherafon se ejecutará únicimente si alguna de las subtransacciones usair, wifed y american es exitosa y la subtransacción visa también es exitosa.

Existen dependencias implicitas entre el conjunto (usair, mired, american) y el conjunto (visa, pues si no hay un boleto de avión disponible, entonces es innecesario realizar el pago, y si no hay suficiente crédito disponible en la tarjeta de crédito, entonces el boleto no puede ser comprado. Los dos conjuntos de subtransacciones dependen uno del otro, y las dependencias implicitas pueden ser usadas para definir estas relaciones. Debido a que todas las subtransacciones necesitan la información adquirida por la subtransacción user, existen dependencias implicitas entre user y las dcmás subtransacciones.

Es claro que la transacción global es exitosa si alguna de las subtransacciones usoir, unifed y american es exitosa, y además sherafon y vlsa también.

Un programa IPL para esta transacción global puede ser escrito como sigue :

so ,

program

class creditcard of cardholder : charstring; num : charstring; creditRemains : real; reserved-credit : real;

endclass

class user-info of name : charstring; origin : charString; destination : charstring; departure-time : charstring; returntime : charstring; visa : creditcard;

endclass

class ticket of fligihNo : charString; customer : user-info; cost : real; paid-by : creditcard;

endclass

class room of customer : charstring; roomNo : charstring; cost : real; time : charstring;

endclass

subtrans user : user-info use user-interface at Customer-service beginexec

end ex e c endsubtrans

subtrans risair(user, vim) : ticket use ticket-order at USAir

obtener la información del usuario

beginexec

endexec beginconfirm

endconfirm

reservar un boleto para user.name

ordenar el boleto reservado, pagar con visa

51

beginundo

endundo endsubtrans

subtrans unired(user, visa) : ticket use ticket-order at United-&

cancelar el boleto reservado para user name

beginexec

endexec beginconfirm

endconfirm beginundo

endundo endsubtrans

reservar un boleto para user.name

I ordenar el boleto reservado, pagar con VISU

cancelar el boleto reservado para user.name

subtrans american(user, visa) : ticket use ticket-order at American-Air beginexec

endexec beginconfirm

endconfirm beginundo

endundo endsubtrans

subtrans sherafon(user) : room use room-reserve at Sheraton-Hotel before Ago 3 15:OO

reservar un boleto para user.name '

ordenar el boleto reservado, pagar con visa

cancelar. el boleto reservado para user.name

EST 1993 beginexec

endexec beginundo

endundo endsubtrans

subtrans visa(user, usair, united, american) : creditcard use cndtprocess at ViSACard guard

((usair.cost 2 $350 and user.visa.creditRemains > usair.cost) or (unifed.cost < $350 and user.visa.creditRemains > unifdcost) or (american.cost S $350 and user.visa.creditRemains > american.cost));

reservar un cuarto para zrser.name

cancelar el cuarto reservado para user.name

beginexec

endexec reservar el crédito para el boleto de user.name

52

beginconfirm pagar para usair si este es elegido pak wmprometene, en caso contrano, pagar para united si unifed es escogido para compmm&E, en caso contrario, pagar para american

endconfirm beginundo

endundo endsubtrans

dependency

cancelar el crédito reservado para el boleto de user.name

not usair : united, not usair : american; (usair or united or american) and visa : sheraton; (usair or united or american) and sheraton and visa : accept;

enddep

acceptable-sets

endaccs (usair, sheraton, visa), (united, sheraton, risa), (american, sheraton, visa)

endprogram

En el ejemplo anterior se ilustra como se representan las preferencias de un usuario en un programa IPL, como operan los guardias y las funciones de restricciones de tiempo, y como se

especifican las relaciones de dependencia explícita e implícita entre las subtransacciones de una transacción global. . .

Las dependencias explícitas denotan relaciones entre subtransacciones que determinan el orden correcto de su ejecución. Estas dependencias como tales son tomadas en consideración por el modelo de transacciones flexible. Estas relaciones de dependencias se definen en la construcción de descripción de dependencias. Una subtransacción es elegible para ser remitida a ejecución únicamente si su dependencia es true. En' el ejemplo de programación la preferencia 1 constituye una dependencia explicita para unifed y american: la preferencias 2 lo es para sheraton.

UM transacción mixta involucra varias clases .de subtransacciones que pueden ser implantadas según una definición cuidadosa de su ejecución parcial, de su confirmación parcial, y de su aborto parcial, En nuestro ejemplo la subtransacción sherafon es UM subtransacción compensable, mientras usair, unifed, american y visa son subtransacciones no-wmpensables.

53

La restricción de tiempo para cada subtransacción se define según la constmcción uime-expn. En nuestro ejemplo la preferencia 3 es una restricción de tiempo para la subtransacción sheraton.

Un guardia impone algún tipo de condición para la ejecución de una subtransacción. En el ejemplo previo el guardia para la subtransacción visa asegura que el boleto pueda ser pagado por la tarjeta proporcionada. Así como la falla de usair, united, o american puede abortar la transacción global, también la falla de visa podrá hacerlo; los guardias tienen la íiinción de garantizar la correcta ejecución de la transacción global. ' .

También se ilustra la utilidad del concepto de dependencias implícitas entre subtmaaiones. En este ejemplo existen dependencias implicitas entre los dos grupos de subtransacciones usair, uniled, arnericun) y visa). También existen dependencias implicitas entre la subtransacción user

y todas las demás subtransacciones.

Existen tres estados aceptables de subtransacciones, de los cuales el usuario podrá elegir alguno de ellos. Todas las subtransacciones del.estado elegido deberán ser comprometidas y todas las otras subtransacciones deberán ser abor tah . En este ejemplo la atomicidad global está basada en la semántica de la aplicación, pues se aplican diferentes protocolos de compromiso a los conjuntos de subtransacciones (user), (usair, united, american, visa) y (sheraton. El protocolo apropiado pude ser deducido de la semántica de estas subtransacciones. Ver sección 2.1.1.2. "

En el ejemplo de programación anterior se pretendió ilustrar las estructuras de control del lenguaje IPL sin entrar en detalle en los Sistemas Software Local (SSL's) y en los Agentes de Interoperabilidad (Al's). También da idea sobre la efectividad del compromiso y aborto parciales de las subtransacciones, debido a que la mayoria de los negocios permitcn a SUS usuarios confirmar y cancelar reservaciones sin un cargo extra.en un periodo de tiempo, lo cual es adecuado para la ejecución de la transacción global.

2.1.2 PRECOMPILACION DE IPL

Un precompilador es un traductor que produce como salida código en lenguaje de alto nivel o alguna representación estructural particular. La función de un intérprete es semejante. con la diferencia de que no produce codigo de salida sino que directamente ejecuta las instrucciones contenidas en el código fuente (traducción y ejecución integradas) [MAK91].

55

Un interprete es útil cuando se desea detectar errow que se presentan hasta el momento de ejecución (por ejemplo, una división entre cero). Esta caractenstica es imposible de lograr en 10s compiladores, pues en el programa ejecutable no se almacena Npna infomiación relativa al código fuente. Sin embargo, uno de los aspectos más relevantes de cualquier prognwia es su rapidez de ejecución. En cuyo caso es indiscutible la ventaja de los compiladores sobre los intérpretes. Durante la ejecución el intérprete debe realizar las etapas de análisis y manipulacion de código (descritas posteriormente) que incrementan el tiempo de respuesta. En el caso del compilador esas etapas se realizaron previamente por lo que la ejecución resulta más eficiente. Además los compiladores pueden llevar a cabo optimizaciones más complejas que las conseguidas por los intérpretes

Fases de los compiladores e intérpretes. Los compiladores e intérpretes operan en varias fases, cada una de las cuales transforma el

código fuente de UM representación a otra [ASUSS]. Las etapas típicas de estos programas se

muestran en la figura 2.2.

En realidad varias etapas pueden agruparse o ejecutarse de manera alternada. Inclusive las representaciones intermedias pueden no ser construidas totalmente.

Las primeras tres etapas (adis is léxico, sintáctico y semántico) verifican la correcta estructura de la instrucción en diferentes facetas. Mientras que la última etapa se encarga de

generar el código objeto.

2.2 ARQUITECTURA GENERAL DEL SISTEMA IPL

El sistema de traducción-ejecución IPL constituye el centro de control del entorno ELECTRA. Su función principal es traducir los programas IPL y coordinar la ejecución consistente y confiable de las subtransacciones componentes.

El sistema IPL es responsable de la realización de las siguientes actividades : I) verificar la siniaxis y semántica del programa IPL (UM transacción global); 2) generar la gráfica de ejecución derivada de las especificaciones de las subtransacciones: 3) manipular la gkfica de ejecución de acuerdo con el flujo de control especificado por las subtransacciones (dependencias, altematividad, compensabilidad, estados aceptables); 4) abrir conexiones virtuales con los agentes de interoperabilidad involucrados; 5 ) obtener permiso del controlador de concurrencia global (si es

55

Programa fuente

1

! Programa objeto O

Instrucciones ejecutables

Figura 2.2 Fases de los Compiladores e Intérpretes

56

que existe) para ejecutar subtransacciones; 6) ejecutar subtransacciones (mediante su envio a los correspondientes agentes de interoperabilidad) según lo permita el estado de éstas; 7) determinar el estado aceptable f i ~ l de la transacción global; 8) comprometer o abortar subtransacc'iones de acuerdo con el estado aceptable elegido; 9) monitorear el estado de todas las actividades previas.

El sistema IPL controla el ciclo de vida completo de una transacción global : desde su introducción como programa fuente hasta su compromiso o aborto global.

De acuerdo con las actividades descritas antenomente se definió la arquitectura general del sistema de traducción-ejecución IPL. La funcionalidad de los midulos incluidos refleja las diversas etapas del ciclo de vida de las transacciones globales. En la figura 2.3 se muestran los módulos componentes y sus correspondientes interacciones.

2.2.1 EL MODULO DE TRADUCCION

a

El módulo de traducción recibe como. entrada un .programa fuente IPL y proporciona como salida UM representación de su gráfica de ej&ución, la cual será manipulada por el ejecutor de transacciones flexibles.

El proceso de traducción requiere de diferentes fases correspondientes a los siguientes submódulos :

Analizador Lkxico Esta fase se ocupa de obtener los simbolos que componen el programa fuente IPL para su

posterior uso por parte del analizador sintáctico y semántico este submódulo opera directamente las cadenas de caracteres del programa IPL : recorre e identifica el tipo de cada elemento; los tipos de simbolos que el analizador léxico es capaz de reconocer son :

Palabras, que pueden ser reservadas o no. Constantes, que pueden ser númeriw (reales o enteras) o de'texto. Caracteres especiales tales como punto, coma, dos puntos, paréntesis, operadores

El texto existente entre las construcciones <executing>, <confirm> y urndo> matemáticos y de comparación, eic

57

Diccionario Global

Programa IPL us1

Módulo de Traducción I I 1 I

- - ___ - -____ -______________ Tabla de

Diagnostico 7 .- I I

trio

a

I I

P n m i t h de bIuN&h I A

Figura 2.3 Arquitectura General del Sistema IPL

58

E1 analizador léxico invocado por el analizador sintáctico, sepiui vaya requiriendo de nuevos

una palara, S ~ b o l O S para el adisis de la sintaxis del programa fuente. Si el simbolo d M 0 entonces se realiza una busqueda en la tabla de palabras reservadas del lenguaje IPL.

Analizador Sintáctico La función del analizador sintáctico es verificar que el programa fuente haya sido acrito de

acuerdo con las reglas gramaticales del lenguaje (para una mayor claridad las reglas pmticaia establecidas se encuentran escritas en formato BNF en el apéndice A); en caso de que el programa fuente no cumpla con alguna de estas reglas, el analizador reullloce este incumplimiento como un error de sintaxis y lo reporta al programador IPL. EL proceso de dlis is sintáctico se realiza mediante un árbol de derivación (o árbol de sintaxis). Este mecanismo permite crear un árbol que apartir de un estado inicial, tenga tantas ramas como alternativas existan en la sintaxis especificada.

Analizador Semhntico El análisis semántico venfica'que las instrucciones del programa fuente tengan un significado

válido que pueda ser. ejecutado. Un ejemplo simple de verificación semántica es el caso de referencia a un simbolo definido previamente; q u i el analizador semhtico checa que el simbolo haya sido declarado en alguna otra parte. del p'rograma fuente. Con esto podemos observar que la responsabilidad por el manejo de la tabla de símbolos recae en el analizador semántico. La importancia de la tabla de simbolos está en dependencia directa del punto del código fuente desde el cual es solicitada la intervención del analizador semhtico, como ejemplo veamos el caso en el cual se define el nombre de UM subtransacción:

subtrans user: user-info use user-interface at Customer-service

En este punto del código fuente la existencia previa de un simbolo user causará un error, dado que no pueden existir dos subtransacciones con el mismo nombre, la no existencia previa de la subtransaccion traerá como consecuencia el aceptar UM nueva subtransacción. Por otro lado

analizemos una linea donde se realiza una declaración de dependencias.

user : accept;

Para el ejemplo anterior la existencia de la subtransacción user en la tabla de simbolos implica que se está haciendo rcferencia a un objeto previamente descrito con lo cual es valida nuestra

declaración de dependencias, la no existencia del identificador en la tabla implica un error dado que se estana haciendo referencia a una subtransacción que no ha sido declarada.

Manejrdor de Errores Una de las funciones claves de los precompiladores e intérpretes es detectar la existencia de

errores en el código fuente. Es posible dividir los errores en cuatro grandes grupos :

Errores léxicos. Son errores causados por la escritura incorrecta de identificadores, palabras reservadas, operadores, etc.

Errores sintácticos. Se presentan cuando el código no se ajusta a la gramática del lenguaje; por ejemplo, el tener paréntesis incompletos en una expresión.

Errores semánticos. Ocurren al codificar instrucciones váiidas Iéxica y sintácticamente, pero que no pueden ser ejecutadas pues carecen de significado real; por ejemplo, aplicar un operador a un operando incompatible.

Errores lógicos. Este tipo de errores, el más dificil de detectar, se refiere a instrucciones que pueden ser ejecutadas pero causarían efectos no deseados; por ejemplo, la programación de ciclos infinitos.

Es utópico para todo programador esperar que todo d i g o fuente sea correcto siempre. Por ello es de suma importancia proporcionar un mecanismo que facilite la identificación y corrección de errores. El propósito del manejador de errores es desplegar en su totalidad los errores detectados por los analizadores sintáctico y semántico. También identifica algunos errores semánticos mediante el uso.del diccionario global. Los errores lógicos, al igual que en la mayoría de los compiladores, deben ser detectados por el programador.

Durante las fases de analisis léxico, sintáctico y semántico el sistema IPL termina la ejecuci6n de algún programa fuente ante la ocurrencia del primer error. El submódulo de manejo de errores dispone de una estructura de almacenamiento del error detectado con objeto de proporcionar información necesaria al programador tal como el numero de linea actual (si el error es sintáctico O

semántico), así como el mensaje asociado al error.

60

Generador de Código La huición del generador de 'codigo es construir las estructuras. de datos necesarias para

almacenar la información requerida por el ejecutor durante el proceso de ejecución. Las principales esthcturas de datos que se construyen para tal efecto se representan en las figuras 2.4, 5 , 6 y 7; cada una de estas estructuras de datos sirve para representar un elemento constitutivo.de1 lenguaje IPL : objetos y tipos, subtransacciones, dependencias y estados aceptables.

&trans

Figura 2.4 Estructura de Datos para la Sección de Objetos y Tipos

next next ----- -- I I

name (char) name (char)

Figura 2.5 Estructura de Datos para la Sección de Estados Aceptables

61

L 1

I

Figura 2.6 Estructura de Datos para la Sección de Subtransacciones

62

Dependencias

1

Figura 2.7 Estructura de Datos para la Sección de Dependencias

2.2.2 EL EJECUTOR DE TRANSACCiONES FLEXIBLES

El módulo de ejecución recibe como entrada las estructuras de datos correspondientes a la gráfica de ejecución de la transacción global y, a partir de las especificaciones de control inme&, coordina la ejecución consistente y confiable de las subtransacciones componentes.

El Ejecutor (también denominado planificador o scheduler en inglés) planifica la ejecución de las transacciones globale, mediante la verificación de los predicados de las.dependencias. el envio de peticiones de ejecuciódaborto/compromiso a los sistemas software locales (\.a los agentes de intcroperabilidad asociados), garantizando el ambo a un estado final aceptable.

Sin embargo, la ejecución de transacciones flexibles es más compleja que en otros modelos de transacciones. Se requiere de un potente algoritmo de control de ejecución que preserve las propiedades de alternatividad, dependencia y compensabilidad, garantizando el ambo a un estado final aceptable, El algoritmo de control de ejecución de transaccionb flexibles elaborado e implantado en este trabajo esta. inspirado en [LEB90]. Su esquema de control de ejecución esti basado en las redes de transición de predicados introducidas en [GL81]. . .

La idea básica del algoritmo de control de ejecución consiste en mapear una transacción flexible, en nuestro caso concreto las'estructuras de datos que constituyen la gráfica de ejecución, en una representación de redes de transición de predicados (RTP; para su detalle ver apéndice E).

63

A partir de las RTP's derivadas es posible identificar, para cualquier estado de la transacción flexible, todas las subtransacciones ejecutables. Posteriormente todas las subtransacciones ejecutables se envían (en paralelo) para su ejecución a los agentes de interoperabilidad.

El Algoritmo de Control de Ejecucibn Una RTP modela la ejecución de una transacción flexible al disparar transiciones de acuerdo

con las condiciones especificadas por los predicados asociados a cada transición. Se define UM transición disponible como aquella en que todos sus nodos de entrada contienen al menos WI

token. También se define una transición ejecutable si ésta es disponible y además todos SUS

predicados asociados son verdaderos. Finalmente se define una transición disparable si ésta es ejecutable y su subtransacción asociada ha sido ejecutada exitosamente. El conjunto de todas las transiciones disponibles se denomina simplemente conjunto disponible. Similarmente el conjunto de todas las transiciones ejecutables es el conjunto ejecutable. Para disparar una transición es necesario remitir a ejecución su correspondiente subtransacción. Si la ejecución es exitosa, entonces se dispara la transición; en cualquier otro caso se actualiza la correspondiente variable de estado de ejecución. Para ser mas específico, cuando se dispara la transición tri se llevan a cabo las siguientes acciones :

* Actualizar la variable de estado de ejecución xi; y * Calcular. el nuevo marcado, al retirar un token de cada uno de los nodos de entrada de la

transición tri y colocar un token en cada uno de sus nodos de salida..

El procedimiento evalua-RTP, mostrado en la figura 2.8, implanta el procedimiento Ejec-transaccibn-flex definido en la sección 1 S.4.3.

En el procedimiento evalua-RTP, E es el conjunto disponible actual; U es el conjunto ejecutable achial derivado de E; y G es el conjunto despachado que contiene las transiciones correspondientes a las subtransacciones remitidas. El algoritmo empieza en el estado de ejecución inicial (con todas l,as variables inicializadas a N), calcula el conjunto disponible E, calcula U a partir de E, y remite todas las subtransacciones cuyas transiciones correspondientes pertenezcan a U.

Cada vez que se completa una subtransacción, el algoritmo determina un nuevo estado ejecutable U. Para propósitos de distinción el conjunto U se particiona en dos conjuntos : G y G+.

64

Las transiciones ejecutables que no han sido remitidas a ejecución son contenidas en G+, mien- que las transiciones contenidas en G corresponden a aquellas que a h no han sido remitidas.

Para prevenir la posible pérdida de respuestas provenientes de los agentes de interoperabilidad, átas son almacenadas en UM cola Q. Siempre que Q no este vacía, el algotitmo retira la primer respuesta de Q (al llamar el procedimiento desencola), calcula el nuevo estado de ejecución, dispara la transición correspondiente si la respuesta es "SI", y calcula el nuevo conjunto ejecutable U.

La determinación de conjuntos ejecutables (despacho) continua hasta que se alcanza un estado aceptable ya que no existen subtransacciones y Q está vacia. Cuando la ejecución termina. si el estado de ejecución final x es aceptable, entonces se compromete la transaccion flexible de otra manera se aborta.

Para comprometer UM transacción flexible es necesario comprometer tcdas las subtransacciones nbcompensables ti pertenecientes al conjunto aceptable mediante el envío de un mensaje "COMMIT" a su sistema software local; de otra manera se envia un mensaje "ABORT". Para cada subtransacción compensable ti, completada exitosamente pero no incluida en el estado aceptable, se envia su transacción compensatona correspondiente. A d e m , para cada subtransacción no-compensable .tj (si existe alguna). en G (conteniendo subtransacciones en ejecución), se envia un mensaje "ABORT" a su sistema software local y finalmente se comwn? cada subtransacción compensable en G (después de que se ha comprometido)..

Para abortar una transacción flexible es necesario abortar o compensar (dependiendo de su tipo) las subtransacciones pertenecientes al estado aceptable.

65

procedure evalua-RTP(RTP,A,R) I* RTP es una red de transición de predicados, f es la función de aceptabilidad y R es la salida *I

begin x t W,N,N,...,N) P ninguna subtransacción ha sido ejecutada i es el estado latente*/ E t 0, /*E -conjunto disponible * I u t 0: I* U -conjunto ejecutable *I G t 0; 1' G - conjunio despachado */ Q t empty; I* Q -cola de respuestas *I calcula-conjunto-disponible E de RTP; calcula_conjunto-ejeu~ble U de nuevo conjunto E;

G+ t U - G; I* tri representa tanto transición como subtransacción *I For each transition tri E G+ do

I repeat

begin /*.antes de remitir subtransacción obtener permiso del controlador

remitir la subtransacción tri a su correspondiente sistema software local; G t G w (tn); xi t E /* E para estado de ejecución */

de concurrencia global (si es que existe) */

end; encola respuestas recibida en Q; while (Q = O) do

begin if (U = O) then

begin ' aborta-tran-flex; exit

end end; E S P t descoia(Q);

if ( E S P = SI) then G t G - t i ) ;

begin xi t S; I* llegó a estado exitoso */ dispara(tn); calcula-conjunto-disponible E .

end else

endifi calcula-conjunto-ejecutable U:

xi t F I* fracasó * I

until (x E A); comprometetran-flex; R = x;

end.

Figura 2.8 Algoritmo de Control de Ejecución

66

Las primitivas de Comunicación Por medio de tres primitivas es como se realiza la comunicación entre el módulo ejecutor y los

diferentes agentes de interoperabilidad, las primitivas y sus funciones se describen a continuación .

IniciaSeMcio : Esta primitiva tiene la funcion de abrir un canal de comunicación entre el ejecutor, y un agente el cual actúa como cliente local de un determinado sistema software. Esta primitiva es invocada cuando se detecta que un determinado sistema software va a ser utilizado por la transacción global.

RealizaServicio : Esta primitiva se encarga de mandar ejecutar a un agente una operación o conjunto de operaciones las cuales están escritas en el lenguaje nativo del sistema software local. El texto escrito entre las construcciones executing, confirm y undo es enviado por medio de esta primitiva.

TerminaServicio : El cierre del canal de comunicación es la función llevada a cabo por esta

primitiva. Esta primitiva es invocada justo despues de la decisión de compromiso o aborto de la

transacción global.

MonitoreolDiagnostico Este módulo tiene por objetivo realizar el seguimiento en tiempo real de las operaciones que

son realizadas por el sistema IPL; estas operaciones incluyen las fases de compilación, generación de código intermedio y el resultado final de esta etapa; la apertura de los canales de comunicación con los agentes, la ejecución de las diversas operaciones por parte de los sistemas software, el cierre de los canales de comunicación: también presentará tcda información relacionada con el estado general de la transacción global, por ejemplo si fue'comprometid o abortada, precisando cuales subtransacciones fueron comprometidas, abortadas o compensadas.

61

CAPITULO 3

IMPLANTACION Y PRUEBAS

68

69

Desde su introducción en 1985, Windows es el ambiente g&w que ha prevaiecido como estandar de facto para computadoras personales. Ofrece ai usuario una interfaz amigable, y al constructor de sistemas una interfaz de programación sumamente poderosa.

interfaz Grática de Usuario (GUI). El usuario cuenta con UM interfaz gráfica a base de ventanas, común a todas las aplicaciones bajo Windows.

Concurrencia: Windows, por su arquitectura orientada a mensajes, permite mantener varias aplicaciones "corriendo" al mismo tiempo, multiplicando su tiempo de p d e n t o entre ellas.

Bibliotecas de ligado dinámico. Estas bibliotecas, conocidas como DLCs (Dynamic Link Libraries), permiten desarrollar un conjunto de funciones que se ligan con las aplicaciones en forma dinámica al momento de su ejecución. Esta característica permite compartir recursos, .pues una sola instancia de la biblioteca es compartida por varias aplicaciones. Además las DLL's se pueden ligar con programas codificados en diferentes lenguajes de programación.

Protocolo de comunicación DDE. Windows posee su propio protocolo de comudcación, denominado DDE (Dynamrc Dafa Erchange). Este es un protocolo de intercambio de datos entre aplicaciones; dispone de un conjunto de primitivas para la conexión, transferencia de datos, y ejecución remota de comandos.

3.1.2 HERRAMIENTAS UTILIZADAS

En esta sección se describen las hemien tas de software utilizadas durante el desarrollo del sistema IPL, de igual forma se indican las partes que fueron programadas con dichas herramientas, así como pequeños segmentos del código que fueron programados con cada una de ellas.

3.1.2.1 PCYACC

Es UM versión adaptada al sistema operatwo MS-DOS de la utilena YACC (rei Another Compiler Comprler) [ABRA901 Ésta es UM de las herramientas esthdares para lenguajes

70

provistas por la mayoría de los ambientes W. Su función es de "compilador de compiladores", es decir, es un programa para generar analizadores sinthcticos a partir de su gramática.

PCYACC es un programa que recibe como entrada un código escrito en GDL ( h e a j e de Descripción de Gramática), el cual contiene las reglas gramaticales del lenguaje para el que se construye el compilador y las acciones que debe realizar el analizador sintáctico al cumplirse dichas repias. La salida generada es la función (en d i g o C) que contiene al analizador sintactico. Este código de salida es integrado posteriomente. a los otros módulos que componen el compilador o intérprete. Con PCYACC se implantó el analizador sintáctico. Parte de la programación realizada con el GDL de PCYACC es mostrada a continuación, en primer lugar se muestra la declaración de las palabras ~ ~ e ~ a d a s del lenguaje (por medio de la cláusula TOKEN), seguida de las reglas gramaticales con las cuales se inicia la definición de las cuatro partes del lenguaje IPL (Objetos y tipos, subtransacciones, dependencias y estados aceptables, Únicamente para la sección de objetos y tipos se muestran algunas otras reglas adicionales) :

11 Declaración de los palabras reservadas del Lenguaje IPL, la declaración // de cada palabra reservada se hace por medio de la clausula "%token". I1 %token ACCEPT %token ACCEPTABLE-SETS %token AFTER %token ARRAY %&token AT %token BEFORE %token BETWEEN %token BEGINCONFIRM %token BEGINEXEC %token BEGMüNDO %token CLASS %token DEPENDENCY %token ENDACCS %token ENDCONFIRM %token ENDCLASS %token ENDDEP Ydoken ENDEXEC %token ENDPROGRAM %token ENDSUBTRANS %token ENDUNDO %token GUARD %token OF %token PROGRAM %token SUBTRANS %token TIMEOFDAY

71

%token TIMEOUT %token TO Yotoken USE

I/ Regla gramatical en la cual se establecen las cuatro pattes fundamentale 11 del lenguaje, Tipos, subtransacciones, dependencias y estados aceptable /I así como también las palabras reservadas que marcan el h c i o y fin de /I todo programa IPL "program" y "endprogram" /I P W

dependency-deck f i ~ l - ~ t a h i ~ ENDPROGRAM PROGRAM type-defs subtrans-deck

/I Regla gramatical con la cual comienza la definición de los tipos. /I type-defs : type-defs typedef I type-def

I/ Regla gramatical con la cual se define el cuerpo de un tipo, el resto I/ de las reglas no han sido incluidas en este. texto. /I type-def : CLASS name-mrd OF type-list ENDCLASS PUNTOYCOMA

/I Regla gramatical con la cual comienza la definición de las subtransacciones. I/ subtransdecls su btrans-decl

I subtransdeck subtrans-decl

// Regla gramatical con la cual se define el cuerpo de UM subtransacción, el resto // de las reglas no han sido incluidas en este texto. /I subtrans-decl : SUBTRANS name sub PARENTESISABRE arg list PARENTESISCIERRA DOSPUNTOS type USE rsi AT sitesubtrans-body ENDSUBTGÑS 1 SUBTRANS name-sub DOSPUNTOS type USE rsi AT site subtransbody ENDSUBTRANS

12

I/ Regla gramatical con la cud comienza la definición de las dependencias. // dependency-deck .: dependencias dependency-list ENDDEP

// Regla gramatical con la cual se continua la definición de las dependencias I/ dependency-list : dependencygair 1 dependency-list dependencygair

/I Regla gramatical con la cual se deñne el cuerpo de una dependencia, el rato // de las reglas no han sido incluidas en este texto. I/ dependencygair ' extbool-exp DOSPUNTOS dependiente PUNTOYCOMA I extbool-exp DOSPUNTOS aceptacion PUNTOYCOMA

t

// Regla gramatical con la cual comienza la definición de los estados aceptables, el resto //de las reglas no han sido incluidas en este texto I / acceptablesets : acceptable-sets COMA parentesis subtrans-list PARENTESISCIERRA 1 parentesis subtrans-list PARENTESISCIERRA

El hecho de que la versión de PCYACC usada es para MS-DOS, presentó algunos problemas dentro del proyecto IPL. Fui. necesario modificar el código generado para adaptarlo al ambiente Windows.

3.1.2.2 BORLAND C

El lenguaje de programación elegido para el proyecto IPL es el lenguaje C. Entre las múltiples razones de esta elección se encuentran :

. Su evolución hasta convertirse en un estándar de programación.

13

Su presencia generalizada. Esto permite crear aplicaciones que, si son programadas

La poderosa interfaz de programación para Windows. La existencia de múltiples herramientas auxiliares wmpatibles con el lenguaje C, como en

modularmente, se pueden portar con relativa facilidad a otros ambientes y sistemas.

este caso la utileria PCYACC.

Se utilizó el cornpilador de Borland pues ofrece una interfaz sumamente amigable para el ambiente Windows, y además cuenta con todas las biblioiecas necesarias para la’realización del proyecto : las bibliotecas estándares del lenguaje, las del ambiente Windows y las del protowlo DDE. Enseguida se muestra un segmento de c6digo programado con Borland; dicho segmento consiste de dos funciones: la primera es la encargada de c r k r la ventana principal de la aplicación y la segunda bosqueja en forma general el llamado a las principales funciones que controlan las dive& etapas del sistema IPL.

I’ Nombre: Initlnstance Función: Crea y despliega la ventana de la aplicación del sistema IPL Programador : Fco. Pablo Munguia Gaytin Proyecto: ELECTRA-ITAM *I

BOOL FAR PASCAL InitInstance(”STANCE hinstcurrent, int nCmdShow) ( HWND hWnd;

hlnst = hinstcurrent; hWnd = Createwindow (

“IPL Interprete”, “Sistema de Traducción-Ejecución IPL (ELECTRAY, WSOVERLAPPEDWMDOW, CW-USEDEFAULT, CW-USEDEFAULT, C W-USEDEFAULT, CW-USEDEFAULT, NULL, NULL, hinstcurrent, NULL);

if (hWnd = NULL) return FALSE:

ShowWindow (hWnd, nCmdShow); Updatewindow (hWnd);

14

return TRUE; I

/* Nombre: MainWndProc Función: Controlar y coordinar todas las operaciones del sistema IPLV Nota: Sólo se muestra el caw para cuando el valor de wParam es MY-EXEC; las operaciones

mostradas en MY-EXEC deben ser entendidas como p s e u d d i g o que muestra el flujo de las actividades que se r e a l i q dado que el &digo aquí mostrado no coincide con el implantado '

Programador : Fco. Pablo Munguia Gaykin Proyecto: ELECTRA-íTAM ' I

long FAR PASCAL -export MainWndProc ("D hWná, WORD message, WORD wParam, LONG IParam)

FARPROC IpProcAbout; FARPROC IpProcFile; FARPROC IpProcDebugger; CLIENTCREATESTRUCT ccs;

switch (message) case WMCOMMAND:

switch (wParam) case MYEXEC:

Say( hDlg, "Empezando compilaciÓnW ); inicializa(); if (yyparse(hD1g))

// inicializa las estructuras de datos y algunas variables globales // yyparse controla el &lis¡ l&¡co, sintictic0 y semántico

//limpia las estructuras de datos yyerror(hDlg,"CompilaciÓn Fracasadah"); libemion(); return FALSE;

1 SaybDlg, "Compilación ExitosaW); Say(hD1g ,"Executando SubtmnsadonesW); ejecutor(hD1g); IiberacionO; break;

// controla la fase de ejecución de las transacciones flexibles

default : reium (DefframeProc(hWnd, hMdi, message, wParam, lparam));

break;

1 retum ( OL ):

1

3.1.3 INTERACCION CON OTROS MODULOS

El sistema IPL interactúa directamente con el módulo ruteador del p r o p t o ELECTRA (ver figura 1.4). El ruteador proporciona el servicio de comunicacionm entre el ejecutor y los agentes de interoperabilidad. En su parte frontal recibe peticiones en forma de comandos DDE y las enruta a la máquina y servidor correspondientes. Para la parte dorsal existe la contraparte del ruteador para el ambiente UNIX; éste transfiere directamente las peticiones a los agentes de interoperabilidad, los cuales son encargados de la interacción con el sistema de información correspondi&te y la transferencia de datos entre servidores. Esta distribución de los módulos del proyecto ELECTRA se muestra en la figura 3. I . A continuación se muestran algunas de las funciones por medio de las cuales el sistema IPL interactua con el m6dulo ruteador, a través de llamados a funciones DDE.

It Nombre StartService Función Inicia el canal de comunicación con el agente de interoperabilidad Programador Fco. Pablo Munguia Gaytán Proyecto ELECTRA-ITAM *I

HCONV W A P I StartService(DW0RD dwClient, LPSTR IpSeMce, LPSTR IpParams)

1 return (Ddelnitiate(dwClient, IpSeMce, IpParams));

I* Nombre. ProcessSeMce Función Inicia el canal de comunicación con el agente de interoperabilidad Programador Fco Pablo Munguia Gaytan Proyecto ELECTRA-ITAM *I

BOOL W A P I ProcessSemce (DWORD dwclient, HCONV hConv, LPSTR IpInOut,

HSZ hsdtem =NULL. DWORD dwD& = Istrlen(lpCommand) + I , HDDEDATA hData;

if (IplnOutl=NüLL)

LPSTR IpCommand, LPDWORD dwResult )

hszItem = DdeCreateStringHandle(dwClient, IphOut, CP-WIN ANSO; hData = DdeClientTransaction( (LPBYTE)lpCommand, dwData, hConv, hszItem, C F - T m ,

if ((lpInOutt=NULL) && (hszlteml=NULL)) DdeFreeStringHandle(dwClient, hsdtem),

return((BOOL)hData),

XTYPEXECUTE, TIMEOUT-ASYNC, dwResult ),

I* Nombre: EndSeMce Función: Cierra el canal de comunicación con el agente de interoperabilidad

76

Programador : Fco. Pablo Munguia Gaytan Proyecto: ELECTRA-ITAM */

BOOL W A P l EndService(DW0RD ddl ient , HCONV hconv)

rehim (DdeTerminate(ddlient, hCanv));

3.2 PRUEBAS REALlZADAS

El proceso de pruebas es fundamcntal para el caso de implantación de un lenguaje, pues es indispensable un análisis minucioso de todas las posibles combinaciones pennitidas por k gramática, su correcta transformación a d i g o , la ejecución de dicho código y las condiciones adecuadas para garantizar la ejecución exitosa del sistema. En el apehiice C se incluyen aigunos ejemplos de programación bajo los cuales se probó el sistema IPL, y en los puntos siguientes se reseñan las pruebas a los diversos componentes.

3.2.1 PRUEBAS AL ANALIZADOR LEXICO, SINTACTICO Y SEMANTIC0

Por medio de PCYACC es posible generar un archivo que contenga'un árbol del analizador. sintáctico. Este árbol contiene las posibles derivaciones sintácticas ,de IPL y hié utilizado como guía para generar pruebas exhaustivas de todas las variantes del lenguaje. De esta manera se verificó el funcionamiento correcto de los tres ana l id re s : léxico, sintáctico y semántica. La conclusión satisfactoria de estas etapas fue comprobada mediante el código generado.

3.2.2 PRUEBAS AL EJECUTOR DE TRANSACCIONES FLEXIBLES

Se realizaron pruebas para verificar la correcta operación ante cualquier entrada en cada uno de los estados del algoritmo de ejecución de transacciones flexibles; con ello se comprobó también la eficiencia del ejecutor para manejar diferentes situaciones de aborto y compromiso globales; además se hicieron pruebas para verificar tiempos de respuesta satisfactorios, la gestión del protocolo de intercambio DDE @rocesamiento de todos sus mensajes) y los códigos de error regresados por los agentes dc interoperabilidad

71

En cuanto al flujo de datos entre subtransacciones (dependencias), se realizaron pruebas exhaustivas de mrdmc ión lógica con los agentes de Uiteroperabilidad disponibles (ver fig. 3.2). También se hicieron pruebas fallidas para verificar el buen funcionamiento de las propiedades de altematividad y compensabilidad.

De todas las pruebas realizadas se desprende que el sistema IPL (traducción y ejecución) tiene correcta funcionalidad, por lo que el siguiente paso es usarlo en diversas aplicaciones distribuidas mteroperables

r

Sistema IPL

protocolo DDE

Ruteador ELECTRA

Ai- Agente de

Interoperabilidad

Figura 3.1 Ambiente Operativo del Sistema IPL

78

3.2.3 PRUEBAS A LA APLICACION

Se realizaron pruebas del funcionamiento de cada una de las opciones del menu de la aplicación principal. Asimismo se verificó el adecuado comportamiento de la aplicación IPL bajo diferentes circunstancias operativas: diversas computadoras, varios sistemas IPL "corriendo" simultáneamente, variaciones en la cantidad de memoria disponible, etc..

Origen

Sybase Sybase Sybase Sybase Sybase Oracle Oracle Oracle Oracle Oracle

Informix informix Informix Informix Informix

Shell Shell Shell Shell Shell

S . Multimedia S . Multimedia S. Multimedia S . Multimedia S . Multimedia

Destino

Oracle hfOi-llliX

Shell ;. Desplegado ;. Multimedia

Sybase Informix

Shell S.Desplegado 5. Multimedia

Sybase Oracle Shell

S. Desplegado S. Multimedia

Sybase Oracle

Informix S Desplegadc S. Multimedia

Sybase Oracle

Informix Shell

S Desplegadc

Figura 3.2 Flujos de Datos entre SSL'S

73

CAPITULO 4

CONCLUSIONES Y LINEAS FUTURAS

80

El surgimiento de nuevas aplicaciones avanzadas que quieren de accao comistente y conñable a múltiples y autónomos sistemas de i n f o m i ó n heterógeneos, ha propiciado el desarrollo de modelos y lenguajes de transacciones no-tradicionales. IPL es un lenguaje distribuido orientado a transacciones, basado en el modelo de transacciones flexibles, que ofrece sintaxis y semántica apropiados para el desarrollo conciso de aplicaciones globales. La convivencia de subtransacciones nosompensables, cornpensables y con restricciones de tiempo aumentan grandemente su uso potencial. Por si fuera poco, la disponibilidad de las construcciones <confjrmz y <undo>, ofrecen la facilidad integrada para deñnir el protocolo de atomicidad global, preservando así la consistencia ante posibles fallas. Estos novedosos conceptos sintácticos y semánti&s es posible concretarlos debido a la existencia del entomo de ejecución ELECTRA (ver sección 1.2.2).

Con respecto a los objetivos originalmente planteados al inicio del proyecto de tesis, los cuales deberían ser cubiertos durante el desarrollo de la misma, el resuliado logrado con el sistema de traducciónejecución IPL rebasa las metas originalmente planteadas; dado que el objetivo onginalmente propuesto se basaba en el hecho de lograr exclusivamente un lenguaje que

coordinara operaciones distribuidas en entornos interoperables, esta coordinación practicamente nada tenia que ver con cuestiones o aspectos transaccionales (se limitaba al simple despacho coordinado de las operaciones). A medida que fue avanzando la investigación encontramos la opción IPL que ademis de ofrecer la coordinación de operaciones distribuidas, ofrecia también el paradigma del modelo de transacciones flexibles, el cual al haber sido implementado nos da un gran poder y confiabilidad en el aspecto transaccional distribuido, aspecto que estaba contemplado de manera muy secundaria en el planteamiento original del proyecto de tesis, ademaS de no tener en ese momento idea de los retos tan formidables que implica el manejo de transacciones en entomos interoperables.

El sistema JPL constituye el centro neurálgico del entorno de.ejecución ELECTRA. Todo programa IPL es mapeado (traducido) a una representación interna que corresponde a su red de transición de predicados. Enseguida el algoritmo de control de ejeución (el ejecutor) usa la red de transición de predicados derivada, como estructura de datos, con objeto de planificar la ejecución de las subtransacciones de acuerdo con su especificación. AI arribar a cierto estado aceptable compromete las subtransacciones pertenecientes a éste estado, aborta y/o compensa las no pertenecientes, finalizando así la ejecución global.

El sistema IPL se encuentra operando satisfactoriamente en el laboratorio ELECTRA del Instituto Tecnológico Autónomo de México. Las pruebas realizadas han permitido corroborar la

81

gran versatilidad de IPL para representar aplicaciones complejas. También se demostró su sencillez y elegancia, una vez entendido el modelo de transacciones flexibles. Para esta verificación se instruyeron algunos estudiantes de Ingeniería en Computación, a los cuales se les plantearon algunos problemas globales y fueron capaces en corto tiempo (algunas horas) de traducir los problemas en términos de IPL. Este hecho constató nuestro objetivo principal : ofrecer una herramienta sencilla, elegante y poderosa que permita el rápido desarrollo de aplicaciones globales.

Lineas Futuras

Un gran logro del proyecto ELECTRA es la visión uniforme que tiene el ejecutor de los diversos sistemas sofhvare locales (SGBD's, SGA's, SGBC's, ...) mediante las primitivas de comunicación (IniciaSeMcio, RealizaServicio y Terminaservicio) y los agentes dc interoperabilidad. Para la poríabilidad particular del sistema IPL a otros ambientes gráficos como Motif o Macinstosh, se requiere de algunas modificaciones relacionadas con el monitoreo de actividades del ejecutor.

El sistema IPL no exige conocimiento preciso de los sistemas software locales, sino únicamente de sus lenguajes de operación, El prototipo actual considera que los usuarios son programadores especializados. Para el caso de usuarios finales 6 en exploración el desarrollo de UM interfaz grhfica que permita generar código IPL de manera sencilla, rápida y con validación lógica de su funcionalidad.

Con propósitos de lograr un mayor grado de confiabilidad en el sistema de traducción- ejecución IPL, una importante area de exploración tendrá que ver con el proceso de recuperación de.fallas; para el caso particular de que alguna se presente en el sitio mismo donde IPL está siendo ejecutado, esto puede incluir desde falla íisica hasta alguna posible eventualidad en el sistema operativo. Otro area de investigación tiene como centro el manejo del diccionario global si su ubicación deberá ser centralizada (ubicarse en un solo sitio) o distribuida (tantas copias del diccionario como sistemas IPL existan), los pros y contras de cada solución deben ser sometidas a una estudio seno y profundo.

Posibles extensiones a este trabajo a parte de las ya mencionadas deberán tener que ver con las areas de investigación de : Control de Concurrencia Global, Datos Interdependientes, Flujos de Trabajo, Automatización de oficinas, Segundad de Sistemas, Administración Multisistemas y Repositorios de Datos.

82

El aspecto que suscita mayor interés a corto plazo se refiere a la aplirabilidad del sistema iPL en el seno de las organizaciones. El sistema IPL propone un enfoque novedoso de plantear y desarrollar aplicaciones globales, por lo que su uso se podría condensar en la siguiente metodología : I) identificación del problema (el usuario conoce sus problemas), 2 ) planteamiento del problema (en términos funcionales de la infraestructura del usuario), 3) traducción del problema en términos del sistema IPL (desarrollo de aplicación global con IPL), e 4) implantación final.

83

BIBLIOGRAFIA

[ABRA901 "Compiler Construction on Personal Computers (iuith PCYACC)". Abraxas Software Inc. 1990.

[ASUSS] A. V. Aho, R. Sethi, and J. D. Ullman. "Compilers. Principles. Techniques, and Tools". Addison-Wesley Publishing Company 1988.

[IBCC92] O. Bukhres, Jiansan Chen, Jidong Chm, A. ELmagamiid, Yungho Leu, and Gang Zhu. IPL : "he Interbase Parallel Languaje. In Proc. of the 2nd. Znternational Worshop on Research Issues on Data Enginnering : Transaction and Quety Processing. 1 992.

[BHG87] U. Dayal, M. Hsu, and R. Ladin. Organizing long-runnig activities with triggers and transactions. Proceedings of the ACM Conference on Management of Data,. pages 204-214, 1990.

[DHL90] U. Dayal, M. Hsu, and R. Ladin. Organizing long-ninnig activities with triggers and transactions. Proceedings o f the ACM Conference on Management o f Data, pages 204-214, 1990.

(DHL911 U. Dayal, M. Hsu, and R. Ladin. A generalized tiansaction model for long ninnig activities and active database. lEEE Data Engineering Bulletin, March 1991.

[EC92] A. Elmagarmid and J. Chen. The Interbase Parallel Language : Supporting the Flex Transaction Model and Beyond, Techical Report CSD-TR-92-017, Department of Computer Sciences, Purdue University, Matzo 1992.

[ECD92] A. Elmagarmid, J. Chen, W. Du, O. Bukhres and Rob Pemli. Interbase : An Execution Environment for Global Applications over Distributed, Autonomous, and Heterogeneous Software Systems, Technical Report SERC-TR-112-P, Department of Computer Sciences, Purdue University, April 1992.

84

(ED901

[E11911

[ELLR90]

[ELM921

[EVr88]

[GLS I]

[GMS87]

[GPZ86]

[GRA78]

[GRA92]

C. Ellis. Consistency with concurrent groupware systems. IEEE Data Engineering Bulletin, March 1991.

A. Elmagarmid, Y Leu, W. Litwin, and M. Rusinkiewicz. A Multidatabase Transaction Model for Interbase. in Proceedings of the International Conference on Vety Large Data Bases, Bnsbane, Australia, August 1990.

A. Elmagarmid (Editor). Database Transaction Models for Advanced Applications. Morgan Kaufmann, 1992.

F. Eliassen, J. Veijalainen, and H. Tim. Aspects of transaction modelling for interoperable information systems. In Proceedings of EWECO ‘88 Conference, pages IO5 1-1067, Elsevier Science Publ. Company, Inc., 1988.

H. J . Genrich and K. Lautenbach. System modeling with high level petn nets. Theorical Computer Science, 13:109-136, 1981.

H. Garcia-Molina and K. Salem. SAGAS. in proceedings of ACM SiGMOD Conference on Management of Data, 1987.

V. Gligor and R. Popescu-Zeletin. Transaction management in distributed heterogeneous database management systems. information Systems, I 1(4):287- 297, 1986.

I. Gray. Notes on database operating systems. in Lecture Nofes in Computer Science-Operating Systems : An Advanced Course, pages 624-633. Spnnger- Verlag, Berlin, 1978.

I. Gray and A. Reuter. Transachons Processing : Concepfs and techniques. Morgan Kaufmann, 1992.

85

[HAB92] Y. Halab¡, M. Ansari, R. Batra, W. Jin, G. Karabatis, P. Krychniak, M Rusinkiewicz, L. Suardi. In Proceedings of the Second International Conference on Systems Integration, Momstown, NI, June 1992.

m 8 3 ] T Haerder and A. Reuter. Principles of t d o n o r i e n t e d database recovery. ACMComputing Surveys, 15(4), July 1983.

H. Korth and E. Levy. A f o d approach to recovery by compensating transactions. In Proceedings of the 16th Internabonal Conference on Very Large Data Bases, Bnsbane, Australia, August 1990.

~ 9 0 1

[LAN891 W. Litwin, A. Abdellatif, B. Nicolas, PH. Vigier, and A. Zeroual. MSQL : A multidabase manipulation languaje. Information Science, June 1989.

[LEB90] Y. Leu, A. Elmagarmid, and N. Boudnga. Spcijcation and execution of transactions for advanced applications. Technical Report SERC-TR-82-P, Department of Computer Sciences, Purdue University, December 1990.

(LIT881 W. Litwin. From database systems to multidatabase systems : why and how. In British National Conference on Databases. Cambridge, Press, Octuber, 1990.

[MAK91] R. Mak. 'Writing Compilers & Interpreters. An Applied Aproach', John Wiley & Sons, Inc. 1991.

[MAL921 A Maldonado. Los Sistemas Interoperables. En Simposlum Nacional de Computación, CENAC-IPN. México, D.F., Nov. 1992.

[MOSS11 J.E. Moss. Nested Transactions : An Approach to Reliable Distributed Computing. PhD thesis, Department of Electrical Engineering and Computer Science, MIT, 198 I .

[MOSSS] E. Moss. Nested Transactions. An Approach to Reliable Distributed Computing. The MIT Press, 1985.

86

[NZ84] M. Nodine and S. Zdonik. Cooperative transaction hierarchies : A transaction model to support design applications. in Proceedings of the International Conference on Very k r g e Data Bases, Pages 83-94, 1984.

[PKH88] C. Pu, G. Kaiser, and N. Hutchinson. Split-Transactions for Open-Ended Activities. in Proceedings of the i4fh International Conference on Data Engineering, 1988.

[RELL90] M. Rusinkiewicz, A. Elmagarmid, Y. Leu, and W. Litwin. &fending the transaction model lo cupture more meaning. ACM SIGMOD RECORD, 19(1), March 1990.

[Re11891 A. Reuter. Contract : A means for extending control beyond transaction boundaries. in Proceedings of the 2nd International Workrhop on High Perjormace Transaction Systems, September 1989.

(SL901 Amit P. Sheth and James A. Larson. Federated databases systems for managing distributed, heterogenous, and autonomous databases. ACM Computing Surveys, pages 183-236, September 1990.

[US91] R Unlad and G Schalgeter A flexible and adaptable tool ktt approach for transaction management in non-standard database systems IEEE Dafa Engineenng Bullenn, March 1991

[wS91] G. Weikum and H. Schek. Multi-level transactions and open nested transactions. IEEE Dafa Engineering Bulletin, March 1991.

87

Aphdice A : LR Sintaxis del Lenguaje IPL

La sintaxis de IPL en la f o m Backus-Naur es la siguiente :

<program> ::= program uype-defs> uubtram-decls>l

Uype-defs> ::= Uype-defs> dype-defi I dype-defi dype-def, ::= class aser-rype> of <rype_lisb endclass; aser-rype> ::= ad>

dependency-decls> sfinal-status> endprogram

U y p e - l i S h ::= dype-llsh <a_@pe> I “-@pe> a-@p> ::= e a r - Iish : dype>; <type> ::= <basic-@pe> 1 aser-@pe> I <compound-lype> <compound-@pe> ::= array of <basic-rype> I array o f aser-@pe> <basic-ype> ::= int 1 real I boolean I charstring 1 bitString uubirans-decís> ::= uubiram - decís> uubirans-decb I aubirans-decl> uubtrans-decb ::= subtrans ad> [ ( arg-bsh ) 1 : Uyp>

use es t> at arte> uubirans-boap endsubtrans e . S I > ::= adz &te> ::= dm aubtrans-body> ::= [ dime-constrainh ] [ <guard> ]

execufjnp [’ <confirm> ] [ ando> J executing> ::= beginexec exec-body> endexec <confirm> ::= beginconfirm aonflrrn-bodp endconfirm urndo> ::= beginundo urn-body> endundo dime-constrainh ::= before dime>

I between dime> to <time> I aíter<h‘me> .

dime> ::= “timeofday“ <guard> ::= guard ext-bool-expr> ; uiependency-decls> ::= dependency dependency-lisb enddep dependency-lish : := dependency-lish d e p e n d e n v y i n

I dependencygairz .dependencypit7 ::= ext-bool-expo : da5 ;

ext-bool-expr> ::= ext-bool-exprz or ext-bool-termi I ext-bool-exprz : accept;

1 ext-bool-term>

88

ext-boo1 - term> ::= e x t - bool-expo and 4xt-bool factor>

ext-boo1 f a c t o n ::= aperand> aompare-op> <operand> I ext-boo1 factor>

I ( <ext-bool-expr> ) I qwrtial-succ-ext-boo¡-expo I dd> I not dd>

aperand> ::= <value> I [ cid> [ (<inden j 1. I <id> <compare-op> ::= > I >= I < I <= I O I =

cpartial - suo-et-bool-expn ::= ( aumber, : uubtram-var-lish) uubtrans - var-lish ::= aar-l ish arg-¡ish ::= aar-¡ish aar- i isb ::= aar-i isb , dd> I dd> &al-status> ::= acceptable-sets <acceptable-sets> endaccs <acceptable-sets> ::= cocceptable-sets> , ( uubtrans-lish )

1 ( uubtrans-lish ) uubtrans - l ish ::= aar-lish

89

Apéndice B : La Semántica del Lenguaje IPL

En este apéndice se describen aquellas construcciones sintácticas IPL que no son entendibles de manera intuitiva. Se supone que el lector está Familiarizado con gramáticas de libre contexto.

uubtram - deel> ::= subtrans <id> [ ( arg- f i sh ) J : uype> use u s b at &te> uubtrans-body> endsubtrans

Esta construcción se usa para definir una subtransacción (por ejemplo S,); su nombre, su tipo, su servidor y su sitio se indican respectivamente en <id>, <rype>, -si>, and d i e > . Cuando S, es elegible para ejecución la evaluación de las restricciones de tiempo y las guardias arrojan un valor frue, entonces el ejecutor inicia el proceso de ejecución al obtener permiso del controlador de concurrencia global (si es que existe). Enseguida abre la conexión con el agente de interoperabilidad asociado al servidor que ejecutará SB. Finalmente, envia las operaciones de Si (al agente de interoperabilidad) para su correspondiente ejecución bajo el sistema software.

La opción arg- l i sb define la lista de parámetros de Si. Como estos parámetros son salidas para otras subtransacciones, entonces la lista de parámetros contiene de los nombres de estas

subtransacciones, los cuales son únicos.

Cada dd> tiene UM doble definición de tipo. El tipo explícito k dado por mientras

que su tipo implicito es un tipo booleano extendido. Esto es, el valor puede ser true, false o undefined, lo que representa respectivamente el exito, falla o indetemiinación del termino <executing> en la construcción a u b t r a - b o d p . El tipo implícito se usa cuando un O& actúa como un cextbool fac tom o aparece en una construcción uubtrans-var-liso; en cualquier otro caso se utiliza el tipo explicito. El uso del tipo explicito permite que el ejecutor procese la salida de la subtransacción como un dato estructurado en lugar de UM cadena no interpretable. Otras subtransacciones pueden entonces incorporar esta salida como un parámetro de su ejecución. Por otro lado, el tipo implicit0 de subtiaasacción permite que dependencias entre subtransacciones puedan ser implantadas como expresiones booleanas extendidas.

a aubirans-body> ::= [ dime - constrainl> ] [ <guar& 1 executing> [ <confirm> ] [ urndo> ]

<executing> ::= beginexec exec-bodp endexec

90

aonfirm> ::= beginconfirm aonfirm-body> endconfirm ando> ::= beginundo ando-body> endundo

La construcción <exec-bo+ constituye un comando de ejecución parcial de subtransacción. El comando será remitido para su ejecución al agente de interoperabilidad.

La construcción opcional cconfirm-body> constituye un comando de confirmación parcial de subtransacción. El comando ser4 remitido para su ejecución al agente de interoperabilidad después de la decisión del compromiso global.

La construcción ando-body> también es optativa y constituye un comando de canfirmación parcial de subtransacción. Este comando será remitido para su ejecución al agente de interoperabilidad después de decidir el aborto global.

Estas tres subtransacciones parciales han sido discutidas en el capítulo 2.

ext-boo¡-expn ::= <exi-booi-expn or.<ext-bwl-term> 1 ext-booi-term>

... exf-booi f a c t o n ::= a p e r a n h <compare-op> <operand>

...

Esta es una definición de expresión bmleana extendida. Cada ext-bool-expn, ext-booi-term> o <ex(-boo1 f a c t o n acarrea un valor de frue,&ise o undefined. Si algún exi-bool-expn es evaluado como undefined, podrá ser evaluado en lo sucesivo hasta que su valor sea true o.faise.

Las construcciones <operand>, en un <ext-bool f a c t o n pueden ser del mismo tipo o de tipos compatibles. Por ejemplo, si uno es entero y el otro es real, el entero, puede ser transformado a real para efectos de comparación. Si los dos <operan& son incompatibles, entonces el valor de doolean faclot7 es false

dime - constroinb ::= before <lime> I between <lime> to dime> 1 síter uime>

91

clime> ::= "timeofday" <guarrh ::= guard ext-bool - expn ; ...

Las construcciones 4me-constrainh y <guar son opcionales. Cuando una subtransacción (SB) es elegible para ejecución, se evaluán sus guardias y restricciones de tiempo. Si hay ausencia de guardias o restricciones de tiempo, entonces se asigna el valor true. Si ambas opciones son true, entonces St puede ser ejecutada, si uno de ellos es false, entonces un valor false es asignado a St, como si la ejecución hubiera fallado. Si ambos son indefinidos, la ejecución de S, es postergada para una evaluación posterior.

clime> indica el tiempo local del sitio donde se ejecuta S,. El ejecutor asocia una zona de tiempo a cada entrada del directorio global, facilitando así la conversión entre el tiempo local y los tiempos remotos.

Para la construcción before, si el tiempo actual es menor que <time>, entonces a.me-constrainrz es irue: de otra manera -ffhne-constrainb es false.

Parala construcción between, si el tiempo actual es menor que <lime>, entonces 4rne-consrrainh es undefined; si el tiempo actual es mayor,que el segundo <time>, entonces a'me-constrainh esfalse. de otra manera dime-constrainh es true:'

Para la construcción after, si el tiempo actual es menor que <time>, entonces dime-consfrainrz es undefined; de otra manera <lime-constrainh es true.

'

. .

Durante la ejecución de Si, el ejecutor evalúa continuamente el <lime-consiruinh. Si la evaluación retom.fiise en algún punto,.la ocurrencia de un evento timeout señala la falla en la ejecución de Si.

uiependrncygair> ::= <exf-boul-expr> : <id> ; I ext-bool-expn : accept;

Esta construcción define una dependencia de ejecución. La subtransacción indicada por U&

es elegible para ejecución si el exf-buol-expn del cual,depende es true. Si el valor regresado por <exi_bool-expr> es false, entonces éso se pasa a la subtransacción, como si su ejecución hubiese fallado.

92

Las subtransacciones se pueden ejecutar en paralelo si no dependen de algún e x t boo1 expo o si la ext-bool-expn de la cual dependen es true y sus restricciones de tiempo y guardias son evaluadas true.

- -

La palabra reservada accept indica el estado final de la transawión global (GI). Si este valor es true, entonces GI es exitoso; si esfalse, entonces GI fatla; de otra manera GI continua en ejecución hasta que accept sea true o false. El accept es true o false si el e x t bool-expn sobre el cual depende es a su vez true o false; de otra manera este valor es undejned.

-

a <portial-succ-ext-bool-expr> ::= ( aumber, ; uubtram-var l ish) -

La expresión booleana extendida parcialmente exitosa es true si al menos el número a u m b e n de subtransacciones en la construcción uubtrans-var-lish tienen el valor de true. Este valor es false si el ejecutor encuentra que no se cumplió que al menos el número a u m b e n en la construcción uubtrans-var-lisb son true. De otra manera este valor es undefined.

utcceptoble-sets> ::= accepiable-setss> , ( uubtrans-lish ) I ( aubtrans-lisb )

Cuando el accept es undefined, el. ejecutor continua ejecutando subtraiisacciones hasta que el accept sea true o false. El valor false indica que'la ejecución de la transacción global ha fallado, y todas las subtransacciones deberán ser .abortadas. El valor true indica que la ejecución de la transacción global ha sido un éxito; en este caso, los diferentes estados aceptable, cada uno consistiendo de un conjunto de subtransacciones, son listados. El usuario determina el conjunto preferido y entonces se comprometen las subtransacciones del conjunto elegido, mientras que se abortan las otras.

93

Apéndice C : Ejemplos de Programación IPL

Ejemplo I Este programa acceSa un archivo plano (electradbf) que contiene la siguiente descripción de campos : un nombre de 15 caracteres, un apellido de 15 caracteres y un teléfono de 10 caracteres La subtransacción subl, ai ser ejecutada por el Shell, realiza una búsqueda (grep) de los elementos que contengan la cadena "luz" en el archivo electmdbf, y envia su resultado a

la subtransacción sub2. Por su parte la subtransacción sub2 recibe los datos enviados por subl y con estos valores ciea una nueva tabla (empleados-luz), ai ser ejecutada por el SGBD sybsse Los sitios involucrados (dsOl y ds02) en este programa son estaciones de trabajo DEC con sistema operativo ULTRIX.

program class empleado-electra of

nombre : charstring; apellido : charstring; teléfono : CharString;

endclass;

subtrans subl : empleado-electra use shell2 at &O2 beginexec

endexec endsubtrans

subtrans sub2(subI) : boolean use sybase at dsOl

grep luz electra.dbf

beginexec create table empleados-luz ( nombre char ( 1 9 , apellido char (IS),

select * from empleados-luz 1

teléfono char (IO) )

endexec endsubtrans

dependency subl . sub2, sub2 accept:

enddep

acceptable-sets (sub I ,sub2)

endaccs endprogram

94

El resultado de la ejecución de este p r o m es el

subtrans sub2[subl) : boolean use sybase at dsOl

. . Ejemplo 2 (los datos de este programa son ficticios) Este programa involucra dos SGBD's : informix (ITAM, campus Santa Teresa) y sybese (ITAM, campus Rio Hondo). La subtransacción subl realiza la transferencia de la tabla pago-diario, en la cual se lleva el registro de los pagos que diariamente realizan los alumnos de sus colegiaturas, esta transferencia ,es necesario hacerla cada día al finalizar las horas hábiles por dos razones : ( I ) El control de pagos de todos los alumnos pertenecientes al iTAM se lleva a cabo en el campus Rio Hondo, que es el campus matriz, (2) La poca capacidad que tiene el dispositivo de almacenamiento de la máquina calix que lleva el control de pagos en Sta. Teresa (razón por la cual, una vez que la transferencia de la tabla es exitosa se el¡minan los registros). Por su parte la subtransacción sub2 recibe los datos que provienen de la subtransaccidn sub1 y crea una tabla con estos valo& Durante el compromiso global la subtransaccion sub1 borra los registro de la tabla, mientras que sub2 (por medio de procedimientos almacenados) respalda la tabla transferida y actualiza el control general de pagos. Durante el aborto global subl imprime una relación de los pagos efectuados ese día

95

@ara su posterior envio a ITAM-Rio Hondo), mientras que sub2 no tiene código a ejecutar. Este programa hace referencia para la subtransacción subl a un sitio calix-sta-teresa que no existe, la maquina calix en sta. teresa es conocida en el diccionario global con otro nombre, el propósito del ejemplo, es demostrar la capacidad del sistema de traducción-ejecución IPL para detectar errores, y como despliega la información de los mismos en la pantalla.

program class pago-diario of

no-control : charstring; periodo : charString; cantidad : red;

endclass

subtrans subl : @rtpo-diario) use informix at calix-sta-teresa beginexec

endexec beginconfirm

endconfirm beginundo

endundo endsubtrans

select * from pago-diario

delete pago-diario

call impnmegago-diario()

subtrans sub2(subl) : boolean use sybase at dsOl beginexec

create table pago-diario-Sta-teresa (no-control char(lS), periodo char(]), cantidad money)

endexec beginconfirm

execute respaldagago-diano execute actualiza-movimientos

. . endconfirm endsubtrans

dependency subl : sub2: sub2 : accept;

enddep

acceptable-sets (sub I ,sub2)

endaccs endprogram

9G

El resultado de la ejecución de este programa es el siguiente:

class pago-diario of nocontrol : charstring: periodo : charstrlng: cantidad : real;

subtrans subl : Ipagodlario] use informix a l cal-sta-leresa

select * from pago-diario

delete pago-diario

Ejemplo 3

El propósito de este programa es mostrar la propiedad de alternatividad de IPL. Se pretende integrar en cualquier SGBD (oracle o sybase, operando en dsO2 y dsOl respectivamente) el registro de empleados del proyecto ELECTRA, el cual hasta la fecha se lleva en forma de archivo plano duplicado para propósitos de respaldo en dos máquinas UNIX (calix y ds03). Después de integrar el archivo plano en alguno de los SGBD’s involucrados, éstos serán

suprimidos.

program class empleado of

clave : charString; nombre : charString; direction : cherString; sueldo : real;

endclass

subtrans subl : empleado use shell at date

91

beginexec

endexec beginconfirm

endconfirm

cat electmdbf

rm electra.dbf

endsubt rans

subtrans sub2 : empleado use shell at &O2 beginexec

endexec beginconfirm

endconfirm

cat electra.dbf

rm electra.dbf

endsubtrans

subtrans sub3 (subI.sub2) : boolean use oracle at ds02 beginexec

create table empl4o-electra ( clave char(S), nombre char(30), direccion char(30), sueldo money )

endexec beginundo

endundo endsubtrans

subtrans sub4 (subl,sub3) : boolean use sybase at dsOl

drop table empleado-electra

. .

beginexec create table empleado-electra ( clave char(5), nombre char(301,

direccion char(30), sueldo money ) endexec beginundo

endundo endsubtrans

dependency

drop table empleado-electra

not subl : sub2; sub1 or sub2 : sub3; not sub3 : sub4; ( I : sub3, sub4) : accept;

enddep

acceptable-sets

endaccs endprogram

(subl, sub3), (subl, sub4). (sub2, sub3), (sub2, sub4)

98

El resultado de la ejecución de este programa se puede describir como sigue:

1 .- Se transfirió la tabla electra.dbf del sitio ds02, dado que la máquina date no estaba prendida en el momento de la ejecución.

2.- Se pudo crear la tabla empleado-electra en los dos sitio seleccionados (&O2 y dsOl).

3.- Se seleccionó el estado aceptable (sub2, sub3), por lo tanto se comprometieron sub2 y sub3, y además se compensó sub4.

99

Apéndice D : Atomicidad de Transacciones Globales

Para asegurar el compromiso wrrecto de UM transacción global se requiere de un protocolo de atomicidad adecuado. Este protocolo comprometerá o abortará la transacción global aún en presencia de fallas.

Las fallas que pueden ocumr en Sistemas Multibase de Datos son

1. Failas de transacción.- Una transacción puede fracasar e n m intento de alcanzar el compromiso deseado debido a las siguientes razones :

La transacción abortó (en forma unilateral) ante la posible violación de alguna restricción de integridad. Por ejemplo se intenta reservar un boleto para un vuelo lleno.

La transacción fué abortada por el SGBD debido a la ocurrencia de un bloqueo mutuo (deadlock).

2. Fallas de sitio.- En un Sistema Multibase de Datos significa que se “cayo” un sistema de base de datos (SBD) participante ‘sin afectar otros’ SBDs. Aquí se incluyen fallas de procesador, memoria central, comunicaciones, alimentación, ... .

. . ,

3.- Fallas de Sistema.- Significa que el Sistema Multibase de Datos (todos sus participantes) .se “cayó”. La probabilidad de que todos los SBD’s se “caigan” es muy baja.

4.- Fallas de disco.- Implica que se mutilan datos almacenados debido al disco dañado

‘De acuerdo con m83] la frecuencia de fallas de diferentes tipos es como sigue : I) las fallas de transacción Ocurren entre IO’y 100 veces por minuto, 2) las de sitio pueden sucederse vanas veces a la semana, y 3) las de disco podrian presentarse una o dos veces al año. Como puede inferirse del avance tecnológico, la frecuencia de fallas de sitio y de disco disminuyen paulatinamente. Esto significa que el espectro de fallas más importante para un protocolo de atomicidad lo constituyen las fallas de transacción. También es necesario señalar que este tipo de fallas en realidad son fracasos que no requieren de procesos de recuperación (recovery), que son muy complejos y dificiles de tratar teóricamente. Por lo que la no inclusión de recuperación en un sistema multibase de datos es suficiente para aplicaciones criticas más no para catastróficas.

100

El Protocolo de Compromiso en dos Fases

El protocolo de compromiso en dos fases IGRA781 (two phase commit : 2PC) fué propuesto para controlar el compromiso atómico de transacciones distribuidas (en sistemas homogéneos) en presencia de fallas. UM transacción distribuida se descompone en múltiples subtransacciones que se ejecutan en diversos sitios. El requerimiento de atomicidad global especifica que todas las subtransacciones deben comprometerse o ninguna de ellas. Para explicar su funcionalidad supongamos que existe un proceso por subtransacción, el cual controla su ejecución.

Un proceso de UM subtransacción se designa como coordinador, mientras los restantes se

denominan participantes. El coordinador inicia la primera fase del protocolo al difundir mensajes "preparado" a todos los participantes. Cuando un participante recibe el mensaje, vota "Si" únicamente si ha terminado sus operaciones y este. listo para comprometer su subtransacción, en

cualquier otro caso vota "No".

Durante la segunda fase el coordinador rxibe todos los votos. Si todos son "Si", entonces envia a todos los participantes al mensaje "Commit" para su compromiso correspondiente, en cualquier otra circunstancia les envia mensajes "Abort' para su aborto respectivo. Es importante señalar que en la práctica no se requiere de mensaje "Preparado", pues los participantes simplemente después de realizar sus operaciones remiten su voto "Si" (o "No" si fracasaron), sin esperar el mensaje "Preparado".

Un participante puede abortar unilateralmente su subtransacción hasta antes de votar "Si"; después de su voto afirmativo no podrá hacerlo y sólo se sujetará a decisiones del coordinador (de compromiso o aborto). Un participante transita al "estado preparado" en el momento en que vota "Si". En este estado deberá satisfacer dos requerimientos : I ) esperar la decisión del coordinador, y 2) comprometer o abortar su subtransacción de acuerdo con la decision del coordinador, a pesar de fallas de sitio o de comunicaciones.

El estado preparado para compromiso en Multibase de Datos

El requerimiento bisico para desarrollar alguna variante 2PC en un Sistema Multibase de Datos es la disponibilidad de un visible estado preparado para compromiso para todas las subtransacciones participantes, Una subtransacción entra a su estado preparado para compromiso

después de completar la ejecución de sus operaciones y sale de éste. cuando es comprometida o abortada. El estado preparado es visible si el SGBD proporciona primitivas que permitan al coordinador decidir cuando comprometer o abortar la subtransacción.

Muchos SGBD's soportan un visible estado preparado para compromiso (por ejemplo Sybase) y pueden d i m e n t e participar en un 2PC Multibase de Datos. Sin embargo existen SGBD's que no proporcionan un estado preparado o bien no ofrecen la primitiva correspondiente. Ante esta situación se presentan tres posibilidades : I) modificar los SGBD's que carecen de estado

preparado con objeto de que satisfagan el requerimiento 2PC, 2) simular el estado preparado para compromiso, y 3) el SGBD compromete automáticamente sus operaciones por lo que no es posible acción alguna.

La solución I viola la autonomía del SGBD y puede no ser una solución aceptable. El segundo enfoque no exige modificación del SGBD por lo que 'no viola su autonomía. Sin embargo el coordinador necesita determinar en que momento todas las operaciones de la subtransacción se han completado exitosamente. Esta actividad podria ser llevada a cabo con relativa facilidad por el agente de interoperabilidad. En cuanto a la tercera posibilidad, no hay manera de hacerlo participe de 2PC, al término de 'sus operaciones se comprometerá autodticamente. Después del compromiso automático de la subtransacción, si la transacción global decide abortar, entonces la Unica manera .de restablecer l a consistencia sena revertir (compensar) los efectos' de la subtransaccion.

¿Cual es entonces la diferencia entre un estado preparado para compromiso y uno simulado preparado para compromiso?. La diferencia sustancial radica en el hecho de que en el estado preparado para compromiso se asegura que no habrá aborto unilateral, mientras que en el simulado no existe tal seguridad. Sin embargo, en la práctica sucede que, las subtransacciones que han completado exitosamenfe sus operaciones. no pueden sufrir "bloqueo mutuo", pues ya han adquirido todos sus candados. Por lo tanto, cuando una subtransacción termina su última operación de lectura o escritura ingresa en un estado que en la práctica no se diferencia del estado preparado para compromiso requerido por 2PC.

Atomicidad de Transacciones Flexibles

El ejecutor de transacciones flexibles es el responsable (tiene el papel de coordinador) de comprometer, abortar o compensar las subtransacciones participantes. La ejecución de una

102

tramawión flexible T termina cuando &a alcanza un estado aceptable o cuando no hay subtransacciones ejecutables.

Para comprometer UM transacción flexible T que alcanza un estado aceptable a,, el ejecutor

deberá realizar las siguientes acciones : I) comprometer todas las subtransacciones no- compensables pertenecientes al estado aceptable (mediante el envío del mensaje "commit"), 2) abortar todas las subtransacciones noampensables que no pertenezcan al estado aceptable (mediante el envio del mensaje "Abort"), y 3) revertir los efectos de aquellas subtransacciones compensables ya comprometidas y que no pertenezcan al estado aceptable (mediante el envío de las operaciones contenidas en la construcción <undo>).

Para abortar una transacción flexible T, el ejecutor aborta todas las subtransacciones no- compensables (en estado preparado o no) y revierte los efectos de todas las subtransacciones compensables.

En la figura A.DI se presentan los diagramas de transición de estados para las subtransacciones no-compensables, compensables y para el coordinador.

Una subtransacción nosompensable ti (fig A.Dl.a) se encuentra inicialmente en el estado latente (L). Posteriormente es elegida por el ejecutor y remitida al sitio correspondiente para su ejecución (evento el), transitando as¡ al estado en ejecución (E). Si ocurre alguna falla (evento a) antes.de completar sus operaciones, aborta y envia un "No" al coordinador quedando en estado final de aborto (A). Si logra completar exitosamente sus operaciones (evento a) quedará en el estado preparado para compromiso (P) y enviará un "si" al uwrdinador. Si estándo en el estado P recibe un mensaje "Commit" (evento es), entonces pasa al estado final de compromiso (C). Por el contrario, si recibe un "Abort", entonces llegará al estado final de aborto (A).

Una subtransacción compensable (fig A.DI.b) se compromete inmediatamente después de ejecutarse exitosamente. De lo contrario abortará

El coordinador (ejecutor) empezará la exploración de subtransacciones ejecutable (evento e'i) transitando al estado de ejecución (E) El ejecutor comprometerá la transaccion flexible cuando alcance algún estado aceptable (evento e'z) y la abortará si se termina la ejecución sin alcanzar el estado aceptable (evento e'3). Ver fig. A.Dl.c.

103

(I) -1-

eí:enviadaparaejecuc¡Ón

e2: ejecución exitosa

e3:ejsxciÓníaiüda

4: reCibe"AB0RT'

6: reCibe'WW

el :determinación de subtransacciones ejecutabIes

eZ: taminadnenestadoacepUble

e3 : terminación sin alcanzar estado aceptable

Figura A.DI Los Diagramas de Transición de Estados

I04

Apkndice E : Redes de Transición de Predicados

La ejecución de transacciones flexibles es más compleja que la de otros modelos de transacciones. Es necesario un poderoso algoritmo poderoso de control de ejecución para proporcionar la flexibilidad inherente al modelo de transacciones flexibles. En este ap6ndice se presenta UM breve revisión de las redes de transición de predicados (RTP) introducidas en [GL8 I] y tomadas como base del algoritmo de control de ejecución (ver sección 2.2.2).

Revisión de las Redes de Transicibn de Predicados De manera simplificada se puede expresar la definición de las redes de transición de

predicados de la siguiente manera. Una red de transición de predicados consiste de :

I . Una grafo bipartita G = (H.K,L) donde H y K se denominan respectivamente nodos y transiciones, y L es un conjunto de arcos dirigidos, cada uno conectando un nodo p E H a una transición t E K o viceversa. Un nodo se representa por un círculo, mientras que una transición por una barra. Para cada. transición, aquellos nodos que están dirigidos hacia la transición se denominan nodos de entrada, y los que estan dirigidos Ñera de la transición son llamados nodos de salida. Un nodo puede contener tokens. Un token en un nodo se representa por un punto en e¡ círculo correspondiente.

2. Una transformación O del conjunto de transiciones al conjunto de formulaciones de lógica de primer orden; y

3. Un marcado Mo de los nodos : &e es un mapeo que asigna a cada nodo h, en H, un conjunto de tokens.

Para clarificar esta definición se proporciona el siguiente ejemplo.

Ejemplo 1 : La figura AE. I representa la red de transición de predicados (H,K,L,K,Mo) dada por :

105

K : ki + (8 <time&) < 17) ki (8 <time&) < 17) ( XI = F) k, + true

Mo : h i + . lu+.

Donde es un token.

h4 ri .

Fig AE. I Una Red de Transici6n de Predicados

Mapea de las Transscciones Flexibles Sea T = (B,S,F,T,G) una cierta transacción flexible, sus redes de t m i c i h de predicados

asociados RTP(T) = (H,K,L,K,Ma) se definen como sigue :

Si B es el conjunto (ti& ,..., h), entonces:

K = B @or ejemplo, asignar a cada subtransaccibn t E B a una transicibn unica, denominada también t, en K)

Mo : asigna un al nodo de entrada de cada tk tal que Sdep(h) = O

donde Sdep(a) es la dependencia de éxito de h

H y L pueden ser derivados a pantr de las siguientes reglas :

I . Para cada subtransacción ti, tal que Sdep(ti) = O, crea y conecta un nodo de entrada a la transición ti.

2. Para cada ti, tal que Sdep(t,) # O, calcule ES; suponiendo que ES = (Ei, ..., L, conecta cada h E Sdep(tij a ti como en'la figura AE.2. En la figura AE.2 ti y tz están em el mismo gNP0 (El).

3. Despues de aplicar las reglas 1 y 2 a todas las transiciones, conectar un nodo de salida a aquellas transiciones que carezcan.de ello (al crear un nuevo nodo).

En el mapeo de arriba K asocia a cada transición ti- un conjunto de predicados, los cuales incluyen los predicados de dependencia de falla (>u = F) para cualquier tk en Fdep(ti) y los predicados externos q(ti) para cualquier q en 1.

donde Fedp(ti) es ¡a dependencia de Falla de ti.

107

F

Figura AE 2 Reglas para la Conexi6n de Transiciones.

108

Glosario

Aplicación Global: Vease Transacción Global.

Aplicaci6n Local: Cualquier aplicación con existencia previa en un determinado sistema software antes de la incorporación de este Último a un SII.

Sistema Distribuido: Conjunto de sistemas de cómputo autónomos e interconectados mediante una red de comunicaciones, con objeto de procesar funciones propias de una organización.

Sistema Software: El termino engloba a toda aquella aplicación de.so&are que principalmente puede ser clasiñcada en cualquiera de las dos siguientes ramas, (a) gestores de datos (SGBD, SCA, SGBC) y (b) paquetes aplicativos (servidores multimedia, hojas de cálculo, paquetes estadísticos, ctc.). *

Brp o Subtarea: Es una subtransacción componente de la aplicación global que se ejecuta bajo un

determinado sistcina software. a

ta Subtransacción Es el procesamiento de una subtarea en forma consistente y confiable

Transacción Global. Es aquella aplicación que requiere de acceso consistente y confiable a

múltiples, autónomos y heterogéneos sistemas software participantes.

109