-
-
-
-
-
-
-
-
-
Ver Arquitectura en Capas ~ DNA
Microsoft Transaction Server supone una poderosa herramienta para controlar y optimizar
el rendimiento de nuestras aplicaciones de servidor.
Es un elemento de servidor que se integra totalmente con IIS para mejorar el
rendimiento de las aplicaciones Web: Transaction Server. Lo podemos encontrar en el
Windows NT 4.0 Option Pack, un paquete de aplicaciones que extienden la
funcionalidad del sistema operativo Windows Nt 4.0 para convertirlo en un
auténtico y operativo servidor en Internet.
Transaction Server es un producto que ya existía, pero que muy pocos
desarrolladores conocían hasta ahora, escépticos ante la idea de adentrarse en el
conocimiento de un enésimo producto Microsoft. Bien, es cierto que MTS es
un elemento de servidor avanzado, pero ningún desarrollador de proyectos Web en
entorno servidor Microsoft va a poder seguir ignorando el servidor transaccional.
Por qué Transaction Server
En la nueva versión de IIS, Microsoft ha apostado claramente por la
integración del servidor Web con el servidor de transacciones MTS. El
objetivo de Microsoft es ofrecer una plataforma completa y eficiente para la
creación de aplicaciones Web que hagan uso de componentes ActiveX en el
servidor. Cuando decimos componentes ActiveX hacemos referencia a componentes
reutilizables que siguen el modelo de objetos COM y a los que nuestras aplicaciones Web
van a solicitar servicios.
Componentes
El desarrollo de aplicaciones se está orientando a un escenario, Internet, en el
que los programas creados deben estar preparados para poder ejecutarse en máquinas
desconocidas, con requerimientos y sistemas operativos también desconocidos. En este
ámbito, la industria del desarrollo se está volcando en una nueva idea: el ComponentWare.
Este término se refiere a la estrategia de desarrollo que pretende, antes de
construir programas grandes de manera completa, dedicarse a la programación de pequeños
(o no tanto) componentes que puedan colaborar entre sí, para obtener una funcionalidad
mucho mayor que la que cada uno de ellos proporciona por separado.
El objetivo de esta tecnología es conseguir que los citados componentes puedan
utilizarse sin preocuparse, ni conocer, el lenguaje o plataforma de desarrollo utilizada
para construir cada uno de ellos. Es decir, podemos pensar en estos componentes como
piezas prefabricadas que van a permitirnos, una vez ensambladas, construir el edificio de
nuestra aplicación. Basta con que cada componente cumpla unas ciertas características
desde el punto de vista externo y que facilite un cierto medio para que sus
funcionalidades puedan ser utilizadas.
Estarás pensando que estos componentes milagrosos que estoy presentando poco a poco
empiezan a parecerse peligrosamente a cualquiera de los elementos utilizados hasta el
momento para la reutilización del código: sean clases, librerías estáticas o
librerías dinámicas. El componentware propone una reutilización bastante más
ambiciosa: cada unidad, es decir, cada componente, debe constituirse como un programa
compilado, que posee la funcionalidad de generar y responder a eventos que le permitan
interaccionar con el usuario, con la máquina, o con otros componentes.
Componentes y objetos
Component Object Model(COM) es una tecnología que se ha venido imponiendo
en los últimos años como una de las apuestas tecnológicas más agresivas (y a menudo
denostadas) de Microsoft. La idea que subyace a COM es dotar a los desarrolladores
de un ámbito en y mediante el que crear componentes que puedan comunicarse con otros
componentes o aplicaciones, proporcionándoles servicios, incluso aunque los citados
componentes y aplicaciones hayan sido desarrollados por otros programadores, o en
lenguajes diferentes. COM es un estándar que define un modo de interactuación de
aplicaciones diseñado para conseguir la interactuación entre aplicación mediante
conjuntos de funciones denominados interfaces. No podemos desarrollar aplicaciones
programando en COM sino utilizar un lenguaje de programación para desarrollar
aplicaciones con componentes que se comuniquen e interactúen siguiendo el estándar que COM
define.
COM es un estándar binario, es decir, los objetos desarrollados siguiendo sus
especificaciones deben cumplir sus características una vez creados. Por ello, los objetos
COM o los objetos OLE, si así se prefiere, pueden ser escritos en cualquier
lenguaje de programación. Es más, COM tiene la vocación de facilitar la
comunicación entre objetos escritos en diferentes lenguajes, en espacios de proceso
diferentes e incluso diseñados para plataformas distintas.
Conceptos fundamentales de COM
Los siguientes son conceptos fundamentales en el ámbito de COM
- Componente COM: Una porción de código, ya sea un ejecutable o una librería
dinámica, que contiene el código binario de los objetos COM
- Objeto COM: Un ejemplar o instancia de un componente COM, que tiene sus propios
elementos de datos, definidos en la clase del componente
- Interfaces: Las interfaces proporcionan un mecanismo para que los objetos puedan
exponerse a sí mismos, permitiendo que los otros componentes de una aplicación puedan
hacer uso de los servicios que el objeto ofrece. Se plasman en un conjunto de prototipos
de método, con una cierta finalidad, y que deberán ser implementados posteriormente para
obtener la citada funcionalidad.
Transaction Server. Vamos con la primera parte del nombre. La definición más o
menos clásica de transacción es "una serie de acciones que constituyen una
operación atómica", esto es, que se realizan por completo o no se realizan en
absoluto. Las transacciones resultan extremadamente importantes en entornos en los que
existe riesgo de concurrencia entre diversos operadores que puedan estar intentando
modificar el estado de ciertos datos simultáneamente, con el consiguiente peligro de
inconsistencia. Sirva como ejemplo la situación en la que varias aplicaciones cliente
intenten operar simultáneamente sobre un mismo conjunto de registros en un gestor de base
de datos relacionales cliente/servidor.
Las transacciones deben cumplir un conjunto de propiedades que son conocidas como ACID,
siglas inglesas de Atomicidad, Completitud, Aislamiento y Durabilidad. La Atomicidad hace
referencia a que todas las operaciones de la transacción deban llevarse a cabo o
descartarse simultáneamente mientras que el aislamiento entre transacciones está
soportado por la necesidad de que las transacciones no puedan verse afectadas por las
modificaciones aún no comprometidas de transacciones en curso y la durabilidad.
Pára qué sirve MTS
MTS nace con el objetivo de facilitar el desarrollo y gestión de componentes
que llevan a cabo trabajos en el ámbito de transacciones. Pongámonos, en el lugar de un
desarrollador que crea una aplicación que utiliza componentes COM para realizar tareas
coordinadas. Supongamos que estas tareas deben realizarse todas concertadamente para
conseguir que el resultado sea el esperado. Parece evidente que de la propia naturaleza de
las citadas operaciones va a resultar poco menos que imprescindible definir transacciones
que involucren a los citados componentes. ?Quién coordina esas transacciones, cuando los
elementos de software que realizan las tareas (los componentes) son módulos
independientes que posiblemente desconozcan por completo la existencia de los otros? La
respuesta es que es necesario un servidor que cuide de estos aspectos: Transaction Server.
Toda aplicación que utilice este modelo cliente servidor puede definirse como una
entidad que tiene un cierto estado (por ejemplo los stocks y la facturación en un
negocio) y que permite su modificación mediante una serie de operaciones definidas por la
propia aplicación. Los componentes en un servidor suelen llevar a cabo todas estas
operaciones que permiten que los citados datos sean coherentes, accesibles al tiempo que
facilitan su actualización y consulta.
Estas reglas de coherencia, las reglas de negocio, requieren de una cierta lógica de
aplicación que es el trabajo de los programadores diseñar. Este es el cuerpo del código
de los componentes. El trabajo de MTS es descargar a los programadores de todos los
aspectos tangenciales que no sean estrictamente la implementación de las reglas de
negocio y, especialmente, de los posibles conflictos que unos componentes puedan provocar
sobre los otros. Cuando un componente está controlado durante su ejecución por MTS
todas sus operaciones son susceptibles de enmarcarse en transacciones. MTS se ocupa
de resolver todos los problemas de concurrencia, en memoria, en lógica de programa y en
gestión de recursos.
El modelo de operaciones en MTS
Bien, hemos dicho que nuestro objetivo es crear una aplicación que se ubique en un
servidor (o varios colaborando entre ellos) y que sea accedida por clientes que van a
consultar, actualizar o gestionar los datos que conforman el estado de la citada
aplicación. Las operaciones sobre el estado de la aplicación, la lógica de negocio, van
a implementarse con componentes COM cuyos aspectos transaccionales van a ser controlados y
gestionados por Microsoft Transaction Server.
Los componentes MTS
Cada uno de los componentes de la aplicación, que en principio es un componente
COM cualquiera, se convierte en un componente MTS. Un componente MTS es un componente COM
constituido como una DLL, y que se ejecuta en el entorno de Transaction Server. Para ello
los componentes deben cumplir un conjunto de características avanzadas que no vamos a
exponer aquí.
Del mismo modo que una instancia de un componente COM es un objeto COM, toda instancia
de un componente MTS es un objeto MTS. Cuando creamos un ejemplar de un componente MTS el
servidor crea automáticamente un objeto asociado de contexto (Context Object) que
contiene información sobre quién originó la creación del objeto y cómo se está
ejecutando, principalmente desde el punto de vista de las transacciones en las que el
objeto está inmerso.
Cada uno de estos objetos será accedido por los clientes, y él a su vez realizará
solicitudes a otros componentes o a los recursos (esencialmente datos) que desee manejar.
Los dispensadores y gestores de recursos
Los recursos de los que hablamos son básicamente los datos, que se ubican en uno o
varios servidores, pongamos como ejemplo, y para centrar ideas, SQL Server. Cada
uno de estos datos, que conforman el estado de nuestra aplicación, es controlado por un
gestor de recursos (Resource Manager). SQL Server es un ejemplo de gestor de
recursos que puede atender a transacciones distribuidas.
Los gestores de recursos son consultados y tomados bajo su ámbito de acción por MTS
para asegurar que las transacciones que operan sobre los citados datos son llevadas a
cabo correctamente.
Los componentes MTS no acceden directamente a los gestores de recursos, sino que lo
hacen a través de un módulo intermedio (el dispensador de recursos Resource Dispenser)
que permite la independencia de la llamada a los gestores de recursos, con lo que
diferentes componentes podrán llamar a diferentes gestores de recursos sin variar
significativamente la tarea de programación. Este enredo quedará claro inmediatamente si
ponemos un ejemplo de cada uno de estos elementos. Si SQL Server es un gestor de recursos,
ODBC es un dispensador para él.
El explorador de Transaction Server
Microsoft Transaction Server nos proporciona una herramienta, el explorador de
Transaction Server, que nos permite ver qué es lo que está sucediendo con un conjunto de
componentes MTS que están ejecutándose en el ámbito de Microsoft Transaction Server.
Los componentes en el explorador se agrupan en paquetes (packages). Un paquete
es un conjunto de componentes COM que se agrupan para su gestión conjunta con Transaction
Server. Normalmente se agrupan aquellos componentes que llevan a cabo tareas
relacionadas en la aplicación. Los componentes de un paquete se ejecutan en el ámbito de
un mismo proceso en el servidor.
El explorador presenta los componentes precisamente estructurados en paquetes según
una cierta estructura jerárquica Los paquetes están asociados a una máquina y contienen
un conjunto de componentes. Cada uno de estos componentes tiene asociado interfaces y
métodos. Cada una de estas entidades corresponde a un nodo del árbol jerárquico del
explorador.
Creación e instalación de paquetes
Pueden crearse paquetes con componentes ya existentes no instalados en ningún paquete
(es decir, DLL que pueden o no estar registradas en la máquina), o incorporar al paquete
componentes incluidos en otros. Cuando incorporamos un componente COM no registrado a un
paquete, el proceso se encarga de registrar la DLL en el registro del sistema. Cada
componente puede estar en múltiples paquetes.
El explorador nos proporciona un asistente para la creación de paquetes vacíos. En
este modo de creación se nos solicita simplemente el nombre que deseamos dar al paquete y
la cuenta de Windows NT bajo la que los componentes en el paquete se ejecutarán.
Una vez creado el paquete podemos crear componentes nuevos e incluirlos en él. Crear
nuevos componentes no significa aquí desarrollar los componentes desde el punto de vista
binario, sino más bien "darlos de alta" en el paquete, con lo que les damos un
lugar y un ámbito en el que ejecutarse en el marco del run time environment del
servidor de transacciones. También contamos con un asistente para la creación de nuevos
componentes, en el que se nos presenta la opción de crear un nuevo componente a partir de
un fichero DLL aún no registrado u obtener una lista de los componentes registrados que
cumplen la condición indispensable de ser in-process, para que podamos elegir cual
es el que deseamos añadir al paquete.
Monitorizando y gestionando los componentes de un paquete
Cuando disponemos de un conjunto de componentes agrupados en un paquete ya estamos
preparados para monitorizar el comportamiento de los citados componentes. EL proceso de
instalación de Microsoft Transaction Server crea un conjunto de paquetes
predefinidos que pueden servirnos de aprendizaje. Uno de ellos, "Sample Bank",
simula una aplicación bancaria que hace uso de componentes controlados por MTS
para llevar a cabo las operaciones de la lógica de negocio, tales como hacer ingresos,
reintegros, etc.
La instalación también genera una aplicación cliente que va a permitirnos comprobar
cómo las llamadas a los componentes van a desatar la ejecución de transacciones.
El explorador nos presenta dos vistas de las propiedades de cada componentes de cada
paquete: la visión de estado y de propiedad. La primera de ellas (State View), presenta
el estado (incluyendo si están recibiendo peticiones de servicio o no) de las máquinas,
los paquetes o los componentes. La vista de propiedades (Property View) muestra las
propiedades de cada uno de los elementos, incluyendo el identificador de clase de cada
componente.
Otro aspecto monitorizable son las transacciones. El explorador dispone de dos nodos
especialmente diseñados para presentar esta información. En la figura, mostramos las
estadísticas de las transacciones a las que se ha visto sometido el componente Bank
en una sesión de prueba.
En este artículo se pretende mostrar la necesidad y conveniencia de utilizar Microsoft
Transaction Server presentando la naturaleza básica de este servidor. Transaction Server
no es un elemento abordable en una pocas líneas.
|
