4.1 DE LOS MODELOS DE OBJETOS
CENTRALIZADOS A LOS MODELOS DE OBJETOS DISTRIBUIDOS.
Los sistemas de bases de datos centralizados son aquellos que se
ejecutan en un único sistema informático sin interaccionar con ninguna otra
computadora. Tales sistemas comprenden el rango desde los sistemas de bases de
datos mono usuario ejecutándose en computadoras personales hasta los sistemas de
bases de datos de alto rendimiento ejecutándose en grandes sistemas. Por otro
lado, los sistemas cliente-servidor tienen su funcionalidad dividida entre el
sistema servidor y múltiples sistemas clientes.
OBJETOS DISTRIBUIDOS
Definición:
En los sistemas Cliente/Servidor, un objeto distribuido es aquel que
esta gestionado por un servidor y sus clientes invocan sus métodos utilizando
un “método de invocación remota”. El cliente
invoca el método mediante un mensaje al servidor que gestiona el objeto,
se ejecuta el método del
objeto en el servidor y el resultado se devuelve al cliente en otro
mensaje.
Tecnologías orientadas a los objetos distribuidos:
Las tres tecnologías importantes y más usadas en este ámbito son:
1. RMI.- Remote Invocation
Method.- Fue el primer framework para crear sistemas distribuidos de Java. El
sistema de Invocación Remota de Métodos (RMI) de Java permite, a un objeto que
se está ejecutando en una Máquina Virtual Java (VM), llamar a métodos de otro
objeto que está en otra VM diferente. Esta tecnología está asociada al lenguaje
de programación Java, es decir, que permite la comunicación entre objetos
creados en este lenguaje.
2.
DCOM.- Distributed Component Object Model.- El Modelo de Objeto ComponenteDistribuido,
esta incluido en los sistemas operativos de Microsoft. Es un juego deconceptos
e interfaces de programa, en el cual los objetos de programa del cliente,
pueden solicitar servicios de objetos de programa servidores en otras
computadoras dentro de una red. Esta tecnología esta asociada a la plataforma
de productos Microsoft.
3.
CORBA.- Common Object Request Broker Architecture.- Tecnología
introducida por el Grupo de Administración de Objetos OMG, creada para
establecer una plataforma para la gestión de objetos remotos independiente del
lenguaje de programación.
Ventajas de las Base de Datos
Distribuidas
• Descentralización.- En un sistema
centralizado/distribuido, existe un administrador que controla toda la base de
datos, por el contrario en un sistema distribuido existe un administrador
global que lleva una política general y delega algunas funciones a
administradores de cada localidad para que establezcan políticas locales y así
un trabajo eficiente.
• Economía: Existen dos aspectos
a tener en cuenta.
o El primero son los costes de comunicación; si las bases de datos están
muy dispersas y las aplicaciones hacen amplio uso de los datos puede resultar
más económico dividir la aplicación y realizarla localmente.
o El segundo aspecto es que cuesta menos crear un sistema de pequeñas
computadoras con la misma potencia que un único computador.
• Mejora de rendimiento: Pues los datos
serán almacenados y usados donde son generados, lo cual permitirá distribuir la
complejidad del sistema en los diferentes sitios de la red, optimizando la
labor.
• Mejora de fiabilidad y
disponibilidad: La falla de uno o varios lugares o el de un enlace de comunicación no
implica la inoperatividad total del sistema, incluso si tenemos datos
duplicados puede que exista una disponibilidad total de los servicios.
• Crecimiento: Es más fácil acomodar
el incremento del tamaño en un sistema distribuido, por que la expansión se
lleva a cabo añadiendo poder de procesamiento y almacenamiento en la red, al
añadir un nuevo nodo.
• Flexibilidad: Permite acceso local
y remoto de forma transparente.
• Disponibilidad: Pueden estar los
datos duplicados con lo que varias personas pueden acceder simultáneamente de
forma eficiente. El inconveniente, el sistema administrador de base de datos
debe preocuparse de la consistencia de los mismos.
• Control de Concurrencia: El sistema
administrador de base de datos local se encarga de manejar la concurrencia de
manera eficiente.
4.2 EVOLUCIÓN DE LOS SISTEMAS
DISTRIBUIDOS
Sistemas Distribuidos
Definición:
“Sistemas cuyos componentes hardware y software, que están en
ordenadores conectados en red, se comunican y coordinan sus acciones mediante
el paso de mensajes, para el logro de un objetivo. Se establece la comunicación
mediante un protocolo prefijado por un esquema cliente-servidor”.
Características:
Concurrencia.- Esta característica de los sistemas distribuidos permite
que los recursos disponibles en la red puedan ser utilizados simultáneamente
por los usuarios y/o agentes que interactúan en la red.
Carencia de reloj global.- Las coordinaciones para la transferencia de
mensajes entre los diferentes componentes para la realización de una tarea, no
tienen una temporización general, esta más bien distribuida a los componentes.
Fallos independientes de los componentes.- Cada componente del sistema
puede fallar independientemente, con lo cual los demás pueden continuar
ejecutando sus acciones. Esto permite el logro de las tareas con mayor
efectividad, pues el sistema en su conjunto continua trabajando.
Motivación
Los sistemas distribuidos suponen un paso más en la evolución de los
sistemas informáticos, entendidos desde el punto de vista de las necesidades
que las aplicaciones plantean y las posibilidades que la tecnología ofrece.
Antes de proporcionar una definición de sistema distribuido resultará
interesante presentar, a través de la evolución histórica, los conceptos que
han desembocado en los sistemas distribuidos actuales, caracterizados por la
distribución física de los recursos en máquinas interconectadas.
Utilizaremos aquí el término recurso con carácter general para
referirnos a cualquier dispositivo o servicio, hardware o software, susceptible
de ser compartido.
Tipos de sistemas
Desde una perspectiva histórica se puede hablar de diferentes modelos
que determinan la funcionalidad y la estructura de un sistema de cómputo, las
características del sistema operativo como gestor de los recursos, y su campo
de aplicación y uso:
·
· Sistemas de lotes. Son los primeros sistemas operativos, que permitían
procesar en diferido y secuencialmente datos suministrados en paquetes de
tarjetas perforadas. Hoy en día, sobre sistemas multiprogramados con interfaces
de usuario interactivas, el proceso por lotes tiene sentido en aplicaciones de
cálculo intensivo, por ejemplo en supercomputación.
·
· Sistemas centralizados de tiempo compartido. Fue el siguiente paso, a
mediados de los 60. El objetivo es incrementar la eficiencia en el uso de la
CPU, un recurso entonces caro y escaso, disminuyendo los tiempos de respuesta
de los usuarios, que operan interactivamente. Los recursos están centralizados
y se accede al sistema desde terminales.
·
· Sistemas de teleproceso. Se diferencian del modelo anterior en que los
terminales —más recientemente, sistemas personales— son remotos y acceden a un
sistema central utilizando una infraestructura de red (por ejemplo la
telefónica) y un protocolo de comunicaciones normalmente de tipo propietario.
El sistema central monopoliza la gestión de los recursos.
Ejemplos de aplicaciones que resolvía este modelo son los sistemas de
reservas y de transacciones bancarias.Sistemas personales. La motivación de
este tipo de sistemas estuvo en proporcionar un sistema dedicado para un único
usuario, lo que fueposible gracias al abaratamiento del hardware por la
irrupción del microprocesador a comienzos de los 80. Precisamente, el coste
reducido es su característica fundamental. El sistema operativo de un ordenador
personal (PC) es, en un principio, monousuario: carece de mecanismos de
protección. Aunque, por simplicidad, los primeros sistemas operativos eran
monoprogramados (MS-DOS), la mejora del hardware pronto permitió soportar
sistemas multitarea (Macintosh, OS/2, Windows 95/98), e incluso sistemas
operativos diseñados para tiempo compartido, como UNIX y Windows NT1. Un
sistema personal posee sus propios recursos locales. Inicialmente, éstos eran
los únicos recursos accesibles, pero hoy en día la situación ha cambiado. Por
otra parte, la evolución hardware ha llevado a los ordenadores personales hacia
versiones móviles (PC portátiles y otros dispositivos como PDAs y teléfonos
móviles).
Sistemas distribuidos. Los recursos de diferentes máquinas en red se
integran de forma que desaparece la dualidad local/remoto. La diferencia
fundamental con los sistemas en red es que la ubicación del recurso es
transparente a las aplicaciones y usuarios, por lo que, desde este punto de vista,
no hay diferencia con un sistema de tiempo compartido. El usuario accede a los
recursos del sistema distribuido a través de una interfaz gráfica de usuario
desde un terminal, despreocupándose de su localización. Las aplicaciones
ejecutan una interfaz de llamadas al sistema como si de un sistema centralizado
se tratase, por ejemplo POSIX. Un servicio de invocación remota (por ejemplo a
procedimientos, RPC, o a objetos, RMI) resuelve los accesos a los recursos no
locales utilizando para ello la interfaz de red. Los sistemas distribuidos
proporcionan de forma transparente la compartición de recursos, facilitando el
acceso y la gestión, e incrementando la eficiencia y la disponibilidad.
El modelo de sistema distribuido es el más general, por lo que, aunque
no se ha alcanzado a nivel comercial la misma integración para todo tipo de
recursos, la tendencia es clara a favor de este tipo de sistemas. La otra
motivación es la Hoy en día existe un hardware estándar de bajo coste, los
ordenadores personales, que son los componentes básicos del sistema. Por otra
parte, la red de comunicación, a no ser que se requieran grandes prestaciones,
tampoco constituye un gran problema económico, pudiéndose utilizar
infraestructura cableada ya existente (Ethernet, la red telefónica, o incluso
la red eléctrica) o inalámbrica.
4.3 LA TECNOLOGÍA DE OBJETOS PARA EL
DESARROLLO DE SISTEMAS DISTRIBUIDOS
El Cliente Stub es una entidad de programa que invoca una operación
sobre la implementación de un objeto remoto a través de un Stub cuyo
propósito es lograr que la petición de un cliente llegue hasta el ORB Core.
Logrando el acoplamiento entre el lenguaje de programación en que se escribe el
cliente y el ORB Core. El stub crea y expide las solicitudes del cliente.
Un Servidor Skeleton es la implementación de un objeto CORBA en algún
lenguaje de programación, y define las operaciones que soporta una interface
IDL CORBA. Puede escribirse en una gran variedad de lenguajes como C, C++,
Java, Ada o Smalltalk. Y a través del skeleton entrega las solicitudes
procedentes del ORB a la implementación del objeto CORBA.
La función del ORB consiste en conectar las dos partes: cliente y
servidor. Presumiblemente estas partes se ejecutan sobre plataformas distintas
y funcionan con diferentes sistemas operativos. Esto significa que pueden
existir diferencias en tipos de datos, el orden de los parámetros en una
llamada, el orden de los bytes en una palabra según el tipo de procesador, etc.
Es misión del ORB efectuar los procesos conocidos como marshaling y
unmarshaling. En caso de que el método invocado devuelva un valor de retorno,
la función de los ORB del cliente y servidor se invierte. Éste realiza el
marshaling de dicho valor y lo envía al ORB del cliente, que será el que
realice el unmarshaling y finalmente facilite el valor en formato nativo.
Existe una gran variedad de implementaciones CORBA.
En las siguientes páginas web:
se encuentran implementaciones basadas en CORBA y se describen sus
características, algunas son propietarias y otras más son libres.
COM/DCOM/Activex
COM (Component Object Model) es un estándar que permite la creación de
objetos que ejecuten tareas que resuelven problemas específicos pero comunes a
varias aplicaciones que puedan desear hacer uso de ellos. Estos pueden ser
invocados por diferentes programas que los requieran, tanto OLE como ActiveX
están basados en esta tecnología.
La idea es tener un mundo de objetos independientes de un lenguaje de
programación. Por ello COM proporciona un estándar para las comunicaciones
entre componentes, de tal forma, que una aplicación puede utilizar
características de cualquier otro objeto de la aplicación, o del sistema
operativo, y permite actualizar el software de un componente sin afectar a la
operación de la solución global.
COM soporta comunicación entre objetos de equipos de cómputo distintos,
en una LAN, WAN, o incluso en Internet.
DCOM extiende el estándar COM de objetos remotos, para su utilización en
redes. Inicialmente se desarrolló para Windows NT 4.0, y posteriormente para
Solaris 2.x y Macintosh, así como para diferentes versiones UNIX.
Se encarga de manejar los detalles muy bajos de protocolos de red, por
lo que el desarrollador se puede centrar en la realidad de los negocios,
proporcionando así mejores soluciones a los clientes.
La arquitectura define cómo los componentes y sus clientes interactúan
entre sí. Esta interacción es definida cual traduce la llamada del cliente a un
formato neutro, totalmente independiente, que puede transportarse sobre
cualquier medio
para el cual exista un protocolo de comunicación.
4.4 LOS ESTÁNDARES PARA EL DISEÑO DE
SISTEMAS DISTRIBUIDOS CON OBJETOS
CORBA
Define servidores estandarizados a través de un modelo de referencia,
los patrones de interacción entre clientes y servidores y las especificaciones
de las APIs.
Con CORBA se facilita:
El diseño de middleware de distribución que facilita el
diseño de aplicaciones en plataformas heterogéneas sin necesidad de conocer los
detalles de los recursos y servicios que ofrece cada elemento de la plataforma.
La capacidad de diseñar aplicaciones desarrolladas en
diferentes lenguajes de programación. Supliendo los recursos necesarios para
implementar las interfaces entre ellas.
La insteroperatividad entre aplicaciones desarrolladas por
diferentes fabricantes. Para que un componente sea interoperable sólo se
requiere que ofrezcan las interfaces y los patrones de interacción basados en
la especificación CORBA.
Beneficios que ofrece CORBA.
Capacidad para que los clientes invoquen métodos de objetos ubicados en
cualquier nudo de la plataforma.
Capacidad de invocar los métodos estáticamente (conocidos cuando se
compila el cliente) y dinámicamente (desconocidos cuando se compiló el
cliente).
Facilita la heterogeneidad de los lenguajes de programación. Los
clientes y servidores pueden ser desarrollados en lenguajes diferentes. CORBA
proporciona los recursos necesarios para compatibilizarlos.
Capacidad de incorporar información reflectiva que describe en tiempo de
ejecución a los clientes las capacidades que ofrecen los servidores instalados.
Transparencia de la ubicación en las invocaciones de los objetos que se
invocan.
Incorpora los mecanismos de seguridad en los acceso y de consistencia de
las transacciones que se ejecutan.
Polimorfismo en las invocaciones.
Coexistencia con otras tecnologías (EJB, DCOM, etc.) a través de la
especificación de los elementos puentes.
4.5 ESTUDIO DETALLADO DE CORBA
CORBA es una arquitectura de objetos distribuidos diseñada para permitir
que dichos objetos distribuidos interoperen sobre entornos heterogéneos, donde
los objetos pueden estar implementados en diferentes leguajes de programación
y/o desplegados sobre diferentes plataformas. CORBA se diferencia de la
arquitectura Java RMI en un aspecto significativo: RMI es una tecnología
propietaria de Sun Microsystems, Inc. y sólo soporta objetos que se encuentren
escritos en el lenguaje Java. Por el contrario, CORBA ha sido desarrollado por
OMG (Object Management Group) [corba.org, 1], un consorcio de empresas, y fue
diseñado para maximizar el grado de interoperabilidad. Es importante saber que
CORBA no es en sí mismo una herramienta para dar soporte a objetos distribuidos;
se trata de un conjunto de protocolos. Una herramienta que dé soporte a dichos
protocolos se denomina compatible con CORBA (CORBA compliant), y los objetos
que se desarrollen sobre ella podrán interoperar con otros objetos
desarrollados por otra herramienta compatible con CORBA.
CORBA proporciona un conjunto de protocolos muy rico [Siegel, 4], y el
abordar todos ellos está más allá del ámbito de este libro. Sin embargo, se
centrará en los conceptos clave de CORBA que estén relacionados con el
paradigma de objetos distribuidos. También se estudiará una herramienta basada
en CORBA: Interface Definition Language (IDL) de Java.
Arquitectura básica
La Figura 10.0 muestra la arquitectura básica de CORBA
[omg.org/gettingstarted, 2]. Como arquitectura de objetos distribuidos, guarda
una gran semejanza con la arquitectura RMI. Desde el punto de vista lógico, un
cliente de objeto realiza una llamada a un método de un objeto distribuido. El
cliente interactúa con un proxy – un stub – mientras que la implementación del
objeto interactúa con un proxy de servidor – un skeleton. A diferencia del caso
de Java RMI, una capa adicional de software, conocida como ORB (Object Request
Broker) es necesaria. En el lado del cliente, la capa del ORB actúa con
intermediaria entre el stub y la red y sistema operativo local del cliente. En
el lado del servidor, la capa del ORB sirve de intermediaria entre el skeleton
y la red y sistema operativo del servidor. Utilizando un protocolo común, las
capas ORB de ambos extremos son capaces de resolver las diferencias existentes
en lo referente a lenguajes de programación, así como las relativas a las
plataformas (red y sistema operativo), para de esta forma ayudar a la
comunicación entre los dos extremos. El cliente utiliza un servicio de nombrado
para localizar el objeto.
Referencias a objetos
CORBA
También como en el caso de Java RMI, un objeto
distribuido CORBA se localiza por medio de una referencia a objeto. Ya que CORBA es independiente de lenguaje, una
referencia a un objeto CORBA es una entidad abstracta traducida a una
referencia de objeto específica de cada lenguaje por medio del ORB, en una
representación elegida por el desarrollador del propio ORB.
Por interoperabilidad, OMG especifica un protocolo
para referencias abstractas de objetos, conocido como protocolo Interoperable Object Reference (IOR). Un ORB que sea compatible con el protocolo IOR permitirá que una
referencia a objeto se registre y se obtenga desde un servicio de directorio
compatible con IOR. La referencias a objetos CORBA representadas en este
protocolo se denominan también IOR (Interoperable
Object References).
4.6 LA CONFLUENCIA DE CORBA Y EL WEB
DESARROLLO WEB
Caso particular de los sistemas Cliente-Servidor con representación
remota. En donde se dispone de un protocolo estándar: HTTP y un Middleware
denominado WebServer. En la actualidad la aplicación de sistemas informáticos
basados en Internet, es una herramienta fundamental para las organizaciones que
desean tener cierta presencia competitiva.
Tecnologías de la lógica de la aplicación en el servidor web:
• CGI: Common Gateware Interface..- Son programas que se ejecutan en el
servidor, pueden servir como pasarela con una aplicación o base de datos o para
generar documentos html de forma automática. Cada petición http ejecuta un
proceso, el cual analiza la solicitud y genera un resultado. Son independientes
del SO, y presentan la ventaja de que, dado un programa escrito en un lenguaje
cualquiera, es fácil adaptarlo a un CGI. Entre los lenguajes que se usan para
CGIs, el más popular es el Perl.
• Servlets: Pequeños programas en Java que se ejecutan de forma
persistente en el servidor, y que, por lo tanto, tienen una activación muy
rápida, y una forma más simple de hacerlo. Estos programas procesan una petición
y generan la página de respuesta.
• ASP (Active Server Pages): Una página ASP es un fichero de sólo texto
que contiene las secuencias de comandos, junto con el HTML necesario, y que se
guarda con la extensión “.asp”. Al ser llamado por el navegador, el motor ASP
del
IIS (Internet Information Server) se encarga automáticamente de
ejecutarlo como se suele hacer con un programa cualquiera, pero cuya salida
siempre será a través del navegador que le invoca. Es un entorno propietario de
Microsoft y el lenguaje de secuencia de comandos predeterminado del IIS es el
VBScript, aunque puede cambiarse.
• JSP (Java Server Pages), que consisten en pequeños trozos de código en
Java que se insertan dentro de páginas web, de forma análoga a los ASPs. Ambas
opciones, hoy en día, son muy populares en sitios de comercio electrónico.
Frente
a los ASPs, la ventaja que presentan es que son independientes del
sistema operativo y del procesador de la máquina.
• PHP es un lenguaje cuyos programas se insertan también dentro de las
páginas web, al igual que los ASPs y JSPs; es mucho más simple de usar, y el
acceso a bases de datos desde él es muy simple. Es tremendamente popular en
sitios de comercio electrónico con poco tráfico, por su facilidad de desarrollo
y rapidez de implantación.
Consideraciones a tomar en el desarrollo de un sistema WEB
a. Separar la lógica de la aplicación de la interfase de usuario.
b. Utilizar métodos estándar de comunicación entre la lógica de
aplicación y la
interfase de usuario.
c. Herramientas que permitan una fácil adaptación de las aplicaciones a
los nuevos dispositivos que irán apareciendo.
d. Definir el coste en comunicaciones que debe asumir la organización.
e. Tener en cuenta los procesos de réplica, periodicidad y el ancho de
banda que
consuman.
f. Replantear la idoneidad de la ubicación de cada proceso.
g. Extremar las pruebas al diseñar e implementar los protocolos de
comunicación.
El concepto de servicio Web
El servicio Web se ha definido como un componente de software
reutilizable y distribuido que ofrece una funcionalidad concreta, independiente
tanto del lenguaje de programación en que está implementado como de la
plataforma de ejecución. Se puede considerar como aplicaciones autocontenidas
que pueden ser descritas, publicadas, localizadas e invocadas sobre la Internet
(o cualquier otra red) y basada en estándares del W3C (especialmente XML).
Arquitecturas actuales de sistemas WEB.
A continuación se muestran algunas arquitecturas que se presentan en
nuestros días al momento de desarrollar una aplicación distribuida sobre la
Web.
4.7 JUSTIFICACIÓN DE UNA ARQUITECTURA
CON OBJETOS DISTRIBUIDOS PARA EL WEB
Las necesidades y aplicaciones de negocios del mundo de hoy requieren de
un conjunto de componentes distribuidos cada vez más complejos a través de las
redes de telecomunicaciones. Aunque la complejidad estriba en el
software/hardware que ponen a funcionar a esos componentes, todo esto va
enfocado a facilitar a los usuarios sus diversas actividades diarias.
Sin que seamos conscientes de ello, en Internet navegan dos tipos de
entes muy distintos: las personas que visitan páginas web o acceden a servicios
interactivos, y las aplicaciones distribuidas. En la web hay miles de programas
que conversan entre sí, intercambiándose datos de forma automática, sin
mediación humana.
Usando servicios web, un programador puede implementar aplicaciones
basándose en rutinas y datos proporcionados desde un servidor distante.
Así, por ejemplo, existen servidores que proporcionan rutinas que
permiten conocer la previsión meteorológica de una localidad o las cotizaciones
en bolsa de una empresa, etc.
Esas rutinas pueden ser usadas, por ejemplo, para
simplemente mostrar información en una página web, o pueden ser usadas como los
datos de entrada en un programa de predicción o de ayuda a la toma de
decisiones. Si el acceso a dichas rutinas y a los datos que generan se hace
usando ciertos protocolos estandarizados, entonces es cuando hablamos de servicio web.
De esta manera inicia el estudio a los servicios web topando temas como
su surgimiento, conceptos, ciclo de vida, arquitectura, ventajas, etc.
La década de los 80′s fue marcada por el surgimiento de la PC y de la
interfase grafica. En la década de los 90′s Internet permitió conectar
computadoras en una escala global. En principio la conexión fue entre PCs y
servidores por medio del explorador de Internet. A comienzos de este siglo es
clara la necesidad de permitir a las computadoras conectadas a Internet
comunicarse entre ellas.
Desde entonces se va dando forma al nuevo modelo de computación
distribuida llamado servicios Web basados en XML. El objetivo es permitir
comunicarse entre sí a sistemas heterogéneos dentro y fuera de una empresa.
Esta comunicación es independiente del sistema operativo, lenguaje o modelo de
programación.
La simplicidad de las interacciones en el modelo de programación Web posibilita
construir sistemas incrementalmente. A diferencia del acoplamiento fuerte de
RPC y de los sistemas de objetos distribuidos, que requieren la implantación de
todas las piezas de una aplicación de una vez, podemos añadir tantos clientes y
servidores a sistemas basados en Web como necesitemos. Podemos establecer
fácilmente conexiones a aplicaciones nuevas de un modo descentralizado, sin
ninguna coordinación central más allá del registro de nombres DNS, y con un
grado de interoperabilidad, escalabilidad y capacidad de gestión
extraordinariamente alto.
SERVICIO WEB
Definiciones.-
“Aplicaciones de negocio modulares y autocontenidas que tienen
interfaces abiertos, orientados a Internet y basados en interfaces estándares”.
Consorcio UDDI .
“Una aplicación software identificada por un URI, cuyas interfaces se
pueden definir, describir y descubrir mediante documentos XML. Un servicio Web
soporta interacciones directas con otros agentes software utilizando mensajes
XML intercambiados mediante protocolos basados en Internet”.
“Una forma estándar de integrar aplicaciones basadas en Web utilizando
los estándares abiertos XML, SOAP, WSDL y UDDI. XML se utiliza para etiquetar
los datos, SOAP para transferir los datos, WSDL para describir los servicios
disponibles y UDDI para listar que servicios están disponibles”.
Los servicios web (SW) son colecciones de funciones u objetos
distribuidos que son presentados como una sola entidad la cual es anunciada en
la red para ser usada por otros programas. Con un interfaz definido y conocido,
al que se puede acceder a través de Internet, al igual que una página web está
definida por un URL (Uniform Resource Locator), un servicio web está definido
por un URI (Uniform Resource Identification) y por su interfaz, a través del cual
se puede acceder a él.
El concepto de servicio web es un paradigma de
la computación distribuida que consiste en un
conjunto de protocolos de comunicación que permiten el intercambio de datos
entre aplicaciones remotas.
Los Servicios WEB son componentes de software reutilizables, ligeramente
acoplados que semánticamente encapsulan funcionalidades discretas que son
distribuidas y accesibles a nivel de programación a través de protocolos de
Internet.
4.8 ASIMILACION DE UNA IMPLEMENTACION
DE CORBA: VISIBROKER FOR JAVA
Visibroker es un ORB que cumple con todos los requerimientos de CORBA.
Visibroker se compone de lo siguiente (Los nombres de servicio entre comillas
son los nombres de la implementación de Visibroker en particular):
• Librerías de CORBA.
Las librerías de CORBA le ayudan a los programas a exponer métodos CORBA
y a utilizar los métodos desde los programas Clientes.
Las librerías de CORBA pueden ser de dos tipos:
1. ORB
El ORB es el exportador e importador de interfases. Todos los clientes y
servidores deben inicializar el ORB y utilizarlo para obtener interfases.
Básicamente el ORB es el que interpreta los punteros de interfases y los
traduce a mensajes de red, o recibe llamadas de red y los traduce a punteros
locales para su ejecución.
2. Adaptador de Objetos
Básico (BOA)
El adaptador de Objetos Básico (Basic Object Adaptor) es la librería que
le ayuda a exportar el puntero de interfase. Se utiliza en el servidor.
Nota: En computación distribuida, los términos “servidor” y “cliente”
pueden resultar intercambiables, ya que el cliente puede implementar objetos y
exportarlos al servidor. En estos casos, los clientes también necesitan usar el
BOA (pero solo si exportan interfases). Esto será mas claro en los ejemplos,
pero recuerde que “cliente” y “servidor” son rolesque puede jugar un ejecutable
en cualquier momento.
• Servicio de
Nombres “SmartAgent”
El servicio SmartAgent le ayuda a exportar un objeto para su utilización
en una red local. Si usted tiene el código de interfase I.O.R. en específico,
usted no necesita un servicio de nombres.
• Servicio de
Activación “OAD”
Cuando usted escribe un programa COM que exporta interfases, Windows
utiliza uno de sus servicios internos (TODO:Averiguar Nombre del Servicio) para
ejecutar el archivo (.exe, .dll, etc) donde la interfase “vive”. CORBA no es
una tecnología que dependa en el sistema operativo, así que el servicio de
activación tiene una lista de las interfases y los nombres de sus ejecutables
para poder iniciar automáticamente el ejecutable. Note que si usted comienza el
ejecutable por sí mismo, no necesita registrarlo en el OAD. De esta manera,
usted puede tener varios servicios en su AUTOEXEC.BAT (o lista de servicios en
Windows NT) que aceptarán peticiones de los clientes.
• Compilador de
IDL
IDL es un lenguaje “neutral” para definición de interfases. Como tal, tiene
declaraciones pero no tiene sintaxis de control (for, do while, etc). Bajo
CORBA, usted describe su interfase utilizando IDL y utiliza el compilador de
IDL para crear clases de apoyo a su implementación, y clases auxiliares para
que los clientes puedan crear instancias del objeto.
Visibroker y Delphi
La versión de Visibroker que viene con Delphi 4 es:
prompt> vbver oad.exe Information for: /Program
Files/Borland/vbroker/Bin/oad.exe Product Name: VisiBroker for C++ Version:
03.02.00.C2.02 Copyright: (C) 1996, 1998 Company: Visigenic Software, Inc. Build Date:
03/02/1998 11:57:32
Como podrá ver, Delphi 4 utiliza una versión de Visibroker para C++.
Como es el caso con todas las librerías de C++, las llamadas han sido
traducidas a archivos .PAS para su uso en Delphi.
4.9 EL WEB DE OBJETOS CON VISIBROKER
En 1989, los altos ejecutivos de varias compañías (desde compañías de
Software hasta Bancos) se reunieron para hablar acerca de interfases, y de la
importancia que éstas tendrían en el futuro. Estas empresas (que forman el
llamado “Open Management Group”) decidieron que, dada la enorme importancia que
las interfases tendrían, sería muy util especificar un estándar para que todos
los lenguajes de programación pudieran exponer interfases, sin importar el lenguaje,
el sistema operativo o el vendedor de servicios de objetos.
CORBA es el resultado de muchos años de trabajo de varias compañías para
definir un estándar que satisfaga a todos los lenguajes de todos los sistemas
operativos. COM fué el primer transporte de interfases soportado por Delphi,
pero CORBA es una tecnología mucho más madura y sólida para tranporte de
interfases, por el simple y sencillo motivo de que CORBA ha estado funcionando
por mucho tiempo en varios sistemas operativos y lenguajes.
Así que la primera diferencia entre COM y CORBA es que COM nos limita a
tecnologías Windows, mientras CORBA nos abre las puertas a la posibilidad de
usar e implementar interfases en Unix, Linux, Mainframes de IBM, Solaris,
Sillicon Graphics, Windows, etcétera, en lenguajes tan dispares como Java, C,
Delphi, COBOL, SmallTalk, FORTRAN, LISP y muchos otros.
Independencia de Lenguaje
¿Cómo se logra la independencia entre lenguajes? Tal como vimos en el
capítulo 9, Las interfases CORBA se representan en un Lenguaje unificado
llamado IDL (Interface Definition Language). Cada lenguaje (Delphi, Java, C,
etc.) cuenta con un traductor (también llamado “compilador”) de IDL, que
traduce las sentencias de la definición de la interfase al lenguaje adecuado.
Cuando usted compra librerías de CORBA (también llamadas ORBs) para su
lenguaje, las librerías normalmente vienen con programas llamados “idl2XXX”,
donde “XXX” es el nombre de su lenguaje. De esta manera, un ORB para java viene
con un compilador de IDL llamado “idl2java”, mientras que C++ vendría con un
compilador llamado “idl2cpp”. En delphi tenemos un caso especial, porque Delphi
puede leer IDL directamente en el editor de librerías de tipos y traducirlo a
PAS automáticamente (así que el compilador de IDL viene integrado en las
versiones Client/Server y Enterprise).
Independencia de Sistemas Operativos y Lenguajes
Como ORB no es dominado por una sola compañía sino por un grupo,
mientras uste pueda compilar su programa para un sistema operativo X y pueda
comprar unas librerías ORB para el mismo sistema operativo (y que funcionen con
su lenguaje), usted puede hablar con cualquier otro servicio en la red que
exponga un ORB, sin importar qué sistema operativo o qué marca de ORB está
ejecutándose en la máquina que expone el ORB.
CORBA es una Especificación
Tal como lo hicimos en las interfases, hay que ver lo que CORBA no es:
• CORBA NO ES un
producto
CORBA es una especificación de como debe funcionar un set de librerías
específicas para llamarse un ORB. Decir “yo sé usar CORBA” no es suficiente;
usted normalmente debe decir cosas como “yo sé CORBA usando Visigenics”, o “yo
sé CORBA usando IONA”. Visigenics e IONA son dos productos que implementan la
tecnología CORBA. Los productos que implementan CORBA se llaman ORBs.
• CORBA NO ES un
lenguaje
De la misma manera, Visigenics (un ORB) está disponible para varios
lenguajes bajo varias plataformas (Visigenics for C++/Linux, Visigenics for
C++/Windows, Visigenics for Java). Pero CORBA en sí mismo no es un lenguaje,
sino una serie de librerías y servicios. Así que recuerde que cuando explique a
otra persona que usted puede programar en CORBA, recuerde que debe decirlo de
forma “Yo programo CORBA usando Visibroker para Delphi bajo Windows”, o “Yo
programo CORBA usando Visibroker para Java”, etcétera.
No hay comentarios:
Publicar un comentario