SISTEMAS DISTRIBUIDOS CON COMPONENTES

Desde siempre que se ha utilizado la computadora para el procesamiento de datos, ha ido de la mano el desarrollo y evolución del H.W y S.W para poder soportar arquitecturas y procesamientos cada vez más grandes. La tecnología Cliente – Servidor propiciada por la aparición de las computadoras personales y la tecnología de redes, estableció una revolución en la forma en que se desarrollan las aplicaciones. la tecnología de componentes, la cual consiste en partir una aplicación en objetos inteligentes que, distribuidos en diferentes computadoras en una red, funcionan juntos y transparentemente para los usuarios, proporcionando una máxima flexibilidad, un mejor desempeño y generalmente un menor costo. Existen dos estándares que norman la construcción de componentes: uno es CORBA (Component Request Broquer Arquitecture) elaborado y promovido por el Object Management Group y el otro es DCOM elaborado y promovido por Microsoft.

SISTEMAS MULTIUSUARIO
Durante los años 60 y 70, las empresas que necesitaban tener gran poder de cómputo utilizaban una arquitectura centralizada. Consistía en una computadora única o mainframe a la cual, bajo el control de un sistema operativo multiusuario,  se conectaban terminales ahora llamadas “tontas” por carecer de un procesador central.  En esa época no existían los conceptos de cliente o de servidor, podemos ahora decir que se pueden distinguir un servidor en el sentido de que hay un computador que proporciona servicios y varios clientes.

SERVIDOR DE ARCHIVOS
Esta arquitectura consiste en conectar varias computadoras personales o workstations a una computadora central (o varias) la cual proporciona acceso a recursos de cómputo como impresoras y discos duros. Esta arquitectura trajo un cambio radical comparada con la del mainframe. Como se muestra en la Fig. 2, la lógica o “inteligencia” de la aplicación reside ahora en los “clientes” en lugar del servidor. El servidor se encarga de enviar archivos o grandes bloques de datos conforme le son requeridos.

CLIENTE-SERVIDOR
Uno de los objetivos de este modelo es el de prorratear lo más eficientemente posible las cargas del proceso entre todas las computadoras. El es un paradigma en el cual los elementos de un sistema de computación requieren servicios desde otro sistema para completar una tarea. El que requiere el servicio se denomina cliente y el que lo proporciona es el servidor. Se maneja por solicitudes y peticiones, el servidor esta encendido en espera de solicitudes a aceptar y atender, el mismo responde la solicitud y la envía de vuelta.

CLIENTE-SERVIDOR DE DOS CAPAS
El que requiere el servicio se denomina cliente y el que lo proporciona es el servidor. En este modelo los papeles de cliente y servidor no son necesariamente fijos, un servidor por ejemplo podría solicitar un servicio a otro servidor con el fin de satisfacer la petición de su cliente, actuando por lo tanto en ese momento a su vez como cliente.

Como se dijo, las aplicaciones CS más comunes hoy en día se encuentran alrededor de un manejador de base de datos. Estas aplicaciones conocidas como backends, proveen el soporte para el almacenamiento, manipulación y recuperación de los datos de la empresa. Estos sistemas utilizan SQL (structured query language), el lenguaje estándar de acceso a bases de datos, como la herramienta para enviar las peticiones al servidor desde el cliente.

CLIENTE-SERVIDOR DE TRES CAPAS
Además de que las aplicaciones presenten información adecuada reportes, estadísticas y demás, otro objetivo es: que sean sistemas de información robustos y que puedan cambiar conforme cambien las necesidades de la empresa o institución. Mientras las aplicaciones se utilicen en el ámbito y edificio de una empresa de regular.
El modelo de dos capas se encuentra ligado fuertemente a la implantación física, esto es, una computadora personal operando como el cliente y un servidor en la red conteniendo la base de datos de la empresa y la maquinaria de software (engine) para operar aquella.
El concepto de n capas ha cambiado con el tiempo, puede referirse tanto a hardware como a software. La más clara definición se refiere al hardware, donde una arquitectura será de n capas si esta repartida en n computadoras.
Desde el punto de vista de software, y que también es la visión que se plan-tea en este trabajo, la arquitectura cliente servidor de tres capas está dada por los tres elementos funcionales básicos que generalmente tiene una aplicación, ya sea CS o no: presentación, lógica y datos. Cada aplicación que interacciona con un usuario necesita una sección de software que se encargue de establecer la inter-fase hombre – máquina.
Algunos sistemas parten las aplicaciones aún más y dividen una o más de las capas (tiers) a través de la red. Por ejemplo la base de datos de la empresa se puede repartir en varios servidores (aún con distintas plataformas) presentando una vista única de la misma a la parte de lógica de la aplicación que necesita acceder a la base de datos. De igual manera es posible dividir la lógica de la aplica-ción (quizá la parte que conforma las reglas del negocio) en múltiples computado-ras. De esta manera, la aplicación puede correr en cuatro, cinco o aún más equi-pos recibiendo el nombre de n capas (n–tiers).

Entre las ventajas de la arquitectura de tres capas con respecto a la de dos capas mencionamos las siguientes:

• Administración menos compleja porque en los servidores de cada capa se descarga el grueso de la administración

• La seguridad se incrementa porque se pueden establecer controles finos en cada capa y, además por ejemplo, en vez de actuar con los datos directa-mente, el cliente tiene contacto con las reglas del negocio y nada más. Los datos y las reglas quedan encapsulados.

• Mayor facilidad de escalamiento (crecimiento), intrínseca en el modelo

• Soporte para bases de datos heterogéneas

• Mucho mayor flexibilidad de distribución de las funciones de la aplicación

SOLUCIONES POR COMPONENTES
Para ir más allá del modelo CS de n capas se llega hasta utilizar componentes. Se habla de la necesidad de un midleware que los controle y de la necesidad de estándares para lograr una co-municación entre diferentes plataformas.
Las aplicaciones Cliente Servidor con Objetos Distribuidos. Esta nueva tecnología promete la construcción de aplicaciones eficientes, robustas, “escalables” y “mantenibles”.
Será posible con ella, instalar sistemas de información complejos simplemente ensamblando y/o extendiendo las capacidades de componentes de software reutilizables que trabajan juntos, independientemente del tipo de computadoras, redes, lenguajes y sistemas operativos.

Componentes

 Los componentes pueden interoperar entre ellos inde-pendientemente de lenguajes, herramientas, sistemas operativos y redes y pue-den extenderse utilizando herencia por implementación.
Un objeto típico construido con C++ o Java, como dijimos es un programa inteligente que encapsula código y datos pero, aunque permite una reutilización de código mediante la herencia y la encapsulación, solo vive dentro de un programa, solo el compilador que los crea conoce su existencia.
En contraste, un componente (objeto distribuido), es un programa inteligen-te que puede vivir en cualquier lugar en la red. Se empacan como piezas indepen-dientes e inteligentes de código, a los cuales pueden acceder clientes remotos vía invocaciones de sus métodos. El lenguaje y el compilador que se utilizaron para crearlos (los componentes servidores) no son importantes para los componentes. Una característica importante de los componentes es que tienen separada su intefase de su implementación, esto es, una cosa es el objeto con funcionalidad propia y que se encarga de hacer el trabajo para lo que fue creado y otra cosa es el código que permite la comunicación del componente con otros componentes.

Igual que cualquier objeto, un componente solo puede manipularse a través de su interfase. Sin embargo, la interfase de un componente está separada de su implementación.

Para enfatizar y facilitar su utilización, los componentes deben poderse agrupar en cajas o paletas de herramientas gráficas desde donde puedan ser utilizados y personalizados.

ORB Object Request Brokers

Para que el esquema de componentes distribuidos trabaje, debe existir algún mecanismo para conocer el lugar en que se encuentran y para encaminar los requerimientos de los componentes cliente y las respuestas de los componentes servidor,  conocidos como Object Request Brokers (ORB) en inglés y en español, vendrá a ser algo así como un intermediario o gestor de componentes.

Un object request broker es el software que reside en la parte media o middleware³ del esquema Cliente - Servidor y que se encarga de comunicar componentes cliente con componentes servidor. El cliente invoca un método de un componente remoto, el ORB localiza un ejemplar de la clase de ese componente, invoca el método solicitado que hace que el componente trabaje y regresa el resultado al objeto cliente.

Estándar CORBA

CORBA son las siglas de Common Object Request Broker Arquitecture. Estas si-glas designan a un conjunto de estándares que forman un marco de referencia para establecer la interacción de los componentes.
CORBA fue diseñado desde su origen para resolver el problema de inter-comunicar máquinas es entonces una arquitectura ad hoc para manejar componentes remotos o distribuidos. La especificación CORBA establece una infraestructura para que exista una comunicación entre procesos dentro de la misma má-quina o entre diferentes máquinas.

Estandar DCOM
Microsoft creó COM (Component Object Model) modelo de objetos componentes, que es un estándar para la creación y comunicación entre componentes pero dentro de la misma máquina. Al final de 1996, Microsoft introdujo DCOM (La D es de distribuido) un conjunto de extensiones a COM que permite distribuir a los objetos COM en varias computadoras en la red,

OTM Object Transaction Monitors
Se han hablado de las características de ORB. Sin embargo, un ORB no facilita del todo las cosas. Queda pendiente una administración efectiva y eficiente de los millones de componentes a los que los clientes pueden acceder. Ejemplos de aspectos pendientes serían por ejemplo los aspectos de seguridad, permisos, ciclo de vida de los componentes, cuando y como llamar a todos los servicios del ORB. La solución que se ha encontrado es emplear un OTM (Object Transaction Manager) o gestionador de las transacciones de los componentes. Un OTM es el software que se encarga de crear un medio ambiente organizado para manejar y controlar los componentes del lado del servidor. Permite definir y administrar los componentes típicamente en un medio ambiente gráfico. El OTM establece un pool de componentes, distribuye sus cargas y coordina las transacciones entre componentes.
Cuando se utiliza un OTM se logra que los componentes adquieran características adicionales en su funcionamiento como las que se mencionan enseguida:
*Seguridad
*Permisos
*Versiones
*Manejo ciclo de vida
*Persistencia
*Creación de colecciones
*Auto Instalacion

Objetos de Negocio.
La última meta es crear componentes que se comporten como objetos de negocios del mundo real Son objetos que modelan el comportamiento del mundo en algún tema o dominio. Realizan funciones características del objeto que representan, esto es, un cliente, un coche, un hotel, Etc. Estos objetos se agrupan en colecciones que semejan lugares reales y es posible presentarlos en el monitor de la computadora.
Los objetos de negocios son perfectos para crear aplicaciones de tres y más capas ya que intrínsicamente están partidos. En la primera capa se colocan los componente visuales que tienen que ver con el usuario para el manejo de la aplicación.
Los componentes de las capas de en medio interactúan con sus clientes. Estos a su vez, pueden obtener sus datos desde múltiples fuentes, por ejemplo bases de datos SQL, archivos planos de aplicaciones viejas, archivos HTML, Etc.

LENGUAJE XML
XML es un Lenguaje de Etiquetado Extensible muy simple, pero estricto que juega un papel fundamental en el intercambio de una gran variedad de datos. Es un lenguaje muy similar a HTML pero su función principal es describir datos y no mostrarlos como es el caso de HTML. XML es un formato que permite la lectura de datos a través de diferentes aplicaciones.

Las tecnologías XML son un conjunto de módulos que ofrecen servicios útiles a las demandas más frecuentes por parte de los usuarios. XML sirve para estructurar, almacenar e intercambiar información.

¿Para que sirve XML?

·    Representar información estructurada en la web (todos documentos), de modo que esta información pueda ser almacenada, transmitida,
procesada, visualizada e impresa, por muy diversos tipos de aplicaciones y dispositivos.

Ventajas de XML

·    Fácilmente procesable

·    Separa radicalmente el contenido y el formato de presentación

·    Diseñado para cualquier lenguaje y alfabeto. (encoding)

Características

·    XML es un subconjunto de SGML que incorpora las tres características más importantes de este:

o    Extensibilidad

o    Estructura

o    Validación

·    Basado en texto.

·    Orientado a los contenidos no presentación.

·    Las etiquetas se definen para crear los documentos, no tienen un significado preestablecido.

·    No es sustituto de HTML.

·    No existe un visor genérico de XML.

Aplicaciones de XML

·    Publicar e intercambiar contenidos de bases de datos.

·    Formatos de mensaje para comunicación entre aplicaciones (B2B)

·    Descripción de metacontenidos.

Documento XML

·    Conjunto de datos con sus respectivas etiquetas de marcado XML.

·    Se almacena como texto en archivo con extensión .xml.

·    Un documento XML puede incluir cualquier flujo de datos basado en texto: un articulo de una revista, un resumen de cotizaciones de
bolsa, un conjunto de registros de una base de datos, etc..

Estructura de un documento XML

·    Un documento XML está formado por datos de caracteres y marcado, el marcado lo forman las etiquetas:

Estructura

Componentes de un documento XML

·    En un documento XML existen los siguientes componentes:

o    Elementos: Pieza lógica del marcado, se representa con una cadena de texto(dato) encerrada entre etiquetas. Pueden existir elementos
vacíos (<br/>). Los elementos pueden contener atributos.

o    Instrucciones: Ordenes especiales para ser utilizadas por la aplicación que procesa

<?xml-stylesheet type=“text/css” href=“estilo.css”>

o    Las instrucciones XML. Comienzan por <? Y terminan por ?>.

o    Comentarios: Información que no forma parte del documento. Comienzan por <!-- y terminan por -->.

o    Declaraciones de tipo: Especifican información acerca del documento:

<!DOCTYPE persona SYSTEM “persona.dtd”>

o    Secciones CDATA: Se trata de un conjunto de caracteres que no deben ser interpretados por el procesador:

<![CDATA[ Aquí se puede meter cualquier carácter, como <, &, >, ... Sin que sean interpretados como marcación]]>

EJEMPLO

Sintaxis de XML

·    Representa las normas a seguir para la construcción de documentos XML.

·    Estas reglas son dictadas por el organismo W3C (http://www.w3.org/XML). Entre ellas destacan:

·    El XML es Case - Sensitive.

·    Todo elemento tiene que tener su correspondiente etiqueta de inicio y de cierre, o una sola etiqueta vacía.

·    Todo documento, debe haber un elemento (llamado raíz de documento) que contenga a los demás.

·    Todos los elementos deberán estar correctamente anidados.

·    Todos los valores de los atributos deberán ir entre comillas.