Sistemas de procesamiento de transacciones

...

Del mismo modo, si una transacción de cierre (de nivel superior) aborta, todas sus subtransacciones subyacentes tienen que ser abortadas también. Las transacciones anidadas son importantes en los sistemas distribuidos, ya que proporcionan una forma natural de distribuir una transacción a través de múltiples máquinas. Siguen una división lógica del trabajo de la transacción original. Por ejemplo, una transacción para planificar un viaje por el cual tres vuelos diferentes necesitan ser reservados puede dividirse lógicamente en tres subtransacciones. Cada una de estas subtransacciones se puede gestionar por separado e independiente de las otras dos. En los primeros días de los sistemas middleware empresarial, el componente que manejaba las transacciones distribuidas (o anidadas) formaba el núcleo para integrar las aplicaciones en el nivel del servidor o de la base de datos. Este componente se llamó un monitor de procesamiento de transacciones o TP monitor para abreviar. Su tarea principal era permitir que una aplicación accediera a múltiples servidores / bases de datos ofreciéndole un modelo de programación transaccional, como se muestra en la Fig. 1-10.

[pic 3]

INTEGRACION DE APLICACIONES EMPRESARIALES:

Como se mencionó, cuantas más aplicaciones se han desacoplado de las bases de datos en las que se construyeron, más evidente se hizo que se necesitaban instalaciones para integrar aplicaciones independientes de sus bases de datos. En particular, los componentes de la aplicación deben ser capaces de comunicarse directamente entre sí y no simplemente mediante el comportamiento de petición / respuesta que fue soportado por los sistemas de procesamiento de transacciones.

Esta necesidad de comunicación interaplicada condujo a muchas comunicaciones diferentes

Modelos, que discutiremos en detalle en este libro (y por lo que lo mantendremos breve por ahora). La idea principal era que las aplicaciones existentes pudieran intercambiar información directamente, como se muestra en la Fig. 1-11.

[pic 4]

Existen varios tipos de middleware de comunicación. Con llamadas de procedimiento remoto (RPC), un componente de aplicación puede enviar una solicitud a otro

Componente de aplicación haciendo una llamada de procedimiento local, lo que da como resultado que la solicitud se empaqueta como un mensaje y se envía al receptor. Asimismo, el resultado será devuelto y devuelto a la aplicación como resultado de la llamada al procedimiento. A medida que aumentaba la popularidad de la tecnología de objetos, se desarrollaron técnicas

Para permitir llamadas a objetos remotos, dando lugar a lo que se conoce como método remoto

Invocaciones (RMI). Un RMI es esencialmente el mismo que un RPC, excepto que opera en objetos en lugar de aplicaciones. RPC y RMI tienen la desventaja de que el llamador y el llamado ambos deben estar activos y funcionando en el momento de la comunicación. Además, necesitan saber exactamente cómo referirse entre sí. Este acoplamiento apretado se experimenta a menudo como inconveniente serio, y ha llevado a lo que se conoce como middleware mensaje-orientado, o simplemente MOM. En este caso, las aplicaciones simplemente envían mensajes a puntos de contacto lógicos, a menudo descritos por medio de un sujeto. Del mismo modo, las aplicaciones pueden indicar su interés por un tipo específico de mensaje, después de lo cual el middleware de comunicación se encargará de que esos mensajes sean entregados a esas aplicaciones. Estos llamados sistemas de publicación / suscripción forman una clase importante y creciente de sistemas distribuidos. Discutiremos extensamente en el cap. 13.