Bd distribuidas terminología

1. 1
Bases de datos distribuidos
Terminología
Elabora: Benjamín Joaquín Martínez
Índice
CORBA 2
DCOM (Distributed COM) 5
RMI: Remote Method Invocation (Invocación Remota de Métodos) 6
Data Mining 9
OLAP 11
Bibliografía 12

2. 2
CORBA
CORBA (Common Object Request Broker Architecture) es una arquitectura abierta
desarrollada por los miembros del OMG (Object Management Group). Desde 1989
la misión del OMG ha sido la especificación de una arquitectura para un bus
software abierto, o Object Request Broker (ORB), sobre el que diversos
componentes de objetos escritos por diferentes vendedores puedan interoperar a
través de la red y de los sistemas operativos. Este estándar permite que los objetos
CORBA realicen llamadas entre ellos sin conocer dónde residen los objetos a los
que acceden o en qué lenguaje están implementados estos últimos. OMG define un
lenguaje (Interface Definition Language: IDL) usado para definir las interfaces de los
objetos CORBA.
Los objetos CORBA difieren principalmente de objetos escritos en cualquier
lenguaje de programación típico en:
 Los objetos CORBA pueden estar en cualquier sitio de la red
 Los objetos CORBA pueden interoperar con objetos de otras plataformas
 Los objetos CORBA pueden escribirse en cualquier lenguaje de
programación para el que exista un "mapeado" (correspondencia) desde el
OMG IDL a dicho lenguaje. Actualmente las correspondencias definidas
incluyen Java, C++, C, Smalltalk, COBOL, y Ada).
Arquitectura CORBA
CORBA consiste en la especificación de un modelo de objetos distribuido
idependiente del lenguaje, sistema operativo y plataforma. La parte principal de
CORBA es el ORB (Object Request Broker). ORB actúa como un bus de mensajes
que transporta peticiones de invocación de operaciones y sus resultados sobre
objetos CORBA, proporcionando la infraestructura de comunicación necesaria de
forma que oculte todos los detalles de la comunicación entre objetos distribuidos.
La noción de transparencia es fundamental en CORBA. La transparencia de
localización es la capacidad de acceder e invocar operaciones sobre un objeto
CORBA sin necesidad de conocer dónde reside dicho objeto. La idea es que debería
ser igualmente sencillo invocar una operación residente en una máquina remota que
un método de un objeto en el mismo espacio de direcciones. La transparencia de
lenguaje de programación proporciona la libertad de implementar la funcionalidad
encapsulada un objeto usando el lenguaje más adecuado, bien por las habilidades
de los programadores, la idoneidad del lenguaje para la tarea específica, o la
elección de un "tercer" desarrollador que proporciona componentes ya creados (off-

3. 3
the-shelf components). La clave de este grado de libertad es un lenguaje de
definición de interfaces que es neutral con respecto a la implementación, y que
proporciona una separación entre la interfaz y su implementación.
Dicho lenguaje se denomina Interface Denifition Language (IDL), y se utiliza para
definir las interfaces de los objetos, independientemente del lenguaje de
programación en el que estén implementados. Es un lenguaje fuertemente
declarativo, con un rico conjunto de tipos de datos para describir parámetros
complejos. Una interfaz IDL actúa como un contrato entre los desarrolladores de
objetos y los eventuales usuarios de dichos interfaces. También permite a los
usuarios de CORBA compilar las definiciones de las interfaces en código oculto para
la transmisión de peticiones de invocaciones a través de las redes y las
arquitecturas de las máquinas sin necesitar ningún conocimiento sobre el protocolo
de red utilizado, o incluso la localización del objeto involucrado.
Las definiciones de interfaz IDL informan a los clientes de un objeto que oferta una
interfaz sobre qué operaciones soporta dicho objeto, los tipos de sus parámetros y
qué tipos de resultados se esperan. Un programador de un cliente solamente
necesita el IDL para escribir código cliente listo para invocar operaciones sobre un
objeto remoto.
El compilador IDL genera código stub que el cliente deberá linkar, y los tipos de
datos del lenguaje en un formato adecuado para su transmisión por la red
(marshals). La implementación del objeto remoto se debe linkar con un código
similar denominado skeleton, que decodifica (unmarshals) la petición en tipos de
datos de un determianado lenguaje de programación. La Figura 5.1 muestra el uso
de subs, skeletons y ORB para realizar una invocación remota. Las interfaces con
los componentes de ORB son especificados en IDL.
Invocación remota a través de ORB.

4. 4
También conviene destacar los protocolos de transmisión utilizados por CORBA.
CORBA define tres protocolos por capas para enviar mensajes entre clientes y
objetos: (a) Common Data Representation (CDR), (b) General Inter-ORB
protocol (GIOP), que incluye CDR y además especifica formatos de mensajes GIOP
y ciertas asunciones sobre el transporte, e (c) IIOP (Internet Inter-ORB Protocol),
que especializa GIOP para TCP/IP, especificando como los agentes abren
conexiones y las usan para transferencias GIOP de mensajes.
CORBA especifica el concepto de interoperabilidad, introducida con el protocolo
GIOP, que constituye el protocolo estándar que todos los productos CORBA usan
para comunicarse unos con otros. EL GIOP tiene que ser "mapeado" con un
protocolo específico de transporte, por ejemplo, cuando se establece su
correspondencia con TCP/IIOP se denomina IIOP (tal y como hemos comentado en
el párrafo anterior). El uso del procotolo IIOP garantiza la interoperabilidad entre
diferentes implementaciones CORBA. CORBA no es el único producto que utiliza
IIOP: como se ha visto en módulos anteriores la plataforma Java adopta IIOP para
RMI y EJBs, haciendo que ambos sean interoperables con CORBA.
La especificación CORBA también define servicios CORBA, que son
funcionalidades adicionales ofertadas mediante interfaces estándar. Los servicios
CORBA incluyen nombrado (naming), trader, ciclo de vida, transacciones, seguridad
y persistencia, entre otros. No todos los servicios CORBA ha sido usados de forma
extensiva en sistemas de información. En términos de integración, son importantes
dos servicios: nombrado y transacciones. El servicio de nombrado es importante
para obtener referencias iniciales (esto es conceptualmente similar a JNDI). El
servicio de transacciones es importante para conseguir transacciones distribuidas
(es decir, transacciones que se extienden a múltiples sistemas). De hecho, el
servicio de transacciones de objetos CORBA (CORBA's Objects Transacion
Service: OTS) forma la base para el API de transacciones de Java (JTA).

5. 5
DCOM (Distributed COM)
Aun cuando en la primera versión de COM se incluían algunas nociones de
componentes distribuidos, el soporte más complejo par la distribución de objetos a
escala empresarial, fue disponible en 1996 con DCOM, el cual está basado en la
OSF (Open Software Foundation, DCE (Distributed Computing Envoiroment), el
protocolo de la red RPC (Remote Procedire Call).
DCOM permite a las aplicaciones comunicarse a través de la red en formad que
los usuarios de DDE, OLE y CO desearon. Las ligas que crea DCOM son,
razonables, seguras y permanentes. Si se remueve el componente del lado del
Servidor, el cliente no lo encontrara por más que lo intente. Esto significa que tanto
el cliente como el servidor deberán existir al mismo tiempo y tener una conexión
entre sí.
Esquema de la Arquitectura DCOM.
La arquitectura DCOM (Distributed Component Model) es una extensión COM que
permite la comunicación entre objetos situados en diferentes maquinas a través de
distintos tipos de redes (LAN, WAN, e incluso internet).
El ser DCOM una evolución natural de COM es posible utilizar todas aquellas
aplicaciones, componentes, herramientas y conocimiento previos para trabajar
ahora en un entorno distribuido.
DCOM pretende solucionar los problemas más comunes que surgen en un entorno
de trabajo distribuido:
 Fiabilidad ante posibles fallos en la red.
 Fiabilidad ante posibles fallos en la hardware.
 Eficiencia en términos de carga de la red.
 Posibilidad de trabajar con máquinas de diferentes prestaciones situadas en
diferentes aéreas geográficas.
 Posibilidad de instalación tanto en grupos de trabajo pequeños como
grandes.

6. 6
RMI: Remote Method Invocation (Invocación Remota de Métodos)
RMI es una tecnología desarrollada por Sun para permitir la colaboración de
objetos que están localizados remotamente. Esta tecnología se enmarca en la
idea de permitir colaboración entre Objetos Remotos. La idea no es que los
objetos se comuniquen a través de la programación del usuario de protocolos
estándares de red. La idea es tener un objeto cliente, donde podamos podamos
completar un requerimiento de datos. El cliente luego prepara el requerimiento que
envía a un objeto ubicado en un servidor. El objeto remoto prepara la información
requerida (accediendo a bases de datos, otros objetos, etc). Finalmente el objeto
remoto envía la respuesta al cliente. En lo posible esta interacción debería ser lo
más semejante posible a requerimientos hechos localmente.
En principio se puede anhelar la colaboración de objetos escritos en cualquier
lenguaje (no es el caso de RMI). Esta idea no es simple de lograr, corresponde al
esfuerzo del grupo OMG (Object Management Group, www.omg.org) los cuales
propusieron CORBA (Common Object Request Broker Architecture), el cual define
un mecanismo común para descubrir servicios e intercambiar datos. CORBA usa
Object Request Broker (ORB) como traductores universales para la comunicación
entre objetos. Los objetos remotos hablan a través de estos ORB. El protocolo de
comunicación entre objetos y ORB es llamado Internet Inter-ORB Protocol o IIOP.
La opción propuesta por Microsoft para comunicar objetos remotos es COM
(Component Object Model). Hoy este modelo parece haber sido superado por la
tecnología .NET.
Cuando el cliente y servidor son escritos en Java, la generalidad y complejidad de
CORBA no es requerida. En este caso Sun desarrolló RMI, un mecanismo más
simple especialmente pensado para comunicación entre aplicaciones Java.
Invocación Remota de Objetos (RMI)
La idea suena simple, si tenemos acceso a objetos en otras máquinas, podemos
llamar a métodos de ese objeto remoto. RMI maneja los detalles de enviar los
parámetros, el objeto remoto debe ser activado para ejecutar el método y los valores
deben ser retornados de regreso al llamador.

7. 7
Invocación remota de objetos
Terminología
 Objeto cliente: objeto cuyo método hace el llamado remoto.
 Objeto servidor: Objeto remoto llamado
Notar que los roles de cliente y servidor aplican sólo a un llamado. Un objeto servidor
luego puede ser cliente al hacer un llamado remoto.
 Marshalling: es el proceso de codificación de los parámetros.
 Stub: es un objeto que encapsula el método que deseamos invocar
remotamente. Así el llamado remoto es semejante a un llamado local. Éste
prepara información con la identificación el objeto remoto a invocar, el
método a invocar y codificación de los parámetros (Marshalling).
 Skeleton: es el objeto del lado del servidor que decodifica los parámetros,
ubica el objeto llamado, llama el método deseado, codifica el valor retornado,
y envía la información de regreso al stub.

8. 8
Stub, Skeleton y codificación de parámetros y valores retornados
Aún cuando el proceso de la Figura es completo, RMI lo hace en gran medida
automático y en gran media transparente para el programador.
La sintaxis de llamados remotos es la misma de los llamados locales.
RMI posee posee un mecanismo para cargar clases dinámicamente desde otro
lugar. Esto es requerido, por ejemplo, cuando el valor retornado corresponde a una
instancia de una clase derivada de la clase conocida por el cliente. Aquí se ocupa
un mecanismo similar al usado por applets.

9. 9
Data Mining
El Data Mining es un conjunto de técnicas y tecnologías que permiten explorar
grandes bases de datos, de manera automática o semiautomática, con el objetivo
de encontrar patrones repetitivos que expliquen el comportamiento de estos datos.
A pesar de que la idea del Data Mining puede parecer una innovación tecnológica
muy reciente, en realidad este término apareció en los años sesenta conjuntamente
con otros conceptos como por ejemplo, el data fishing o data archeology. No
obstante, no fue hasta los años ochenta cuando empezó su consolidación.
La minería de datos surgió con la intención o el objetivo de ayudar a comprender
una enorme cantidad de datos, y que estos, pudieran ser utilizados para extraer
conclusiones para contribuir en la mejora y crecimiento de las empresas, sobre todo,
por lo que hace a las ventas o fidelización de clientes.
Su principal finalidad es explorar, mediante la utilización de distintas técnicas y
tecnologías, bases de datos enormes de manera automática con el objetivo de
encontrar patrones repetitivos, tendencias o reglas que expliquen el
comportamiento de los datos que se han ido recopilando con el tiempo. Estos
patrones pueden encontrarse utilizando estadísticas o algoritmos de búsqueda
próximos a la Inteligencia Artificial y a las redes neuronales.
Por tanto, los datos son el medio o la base para llegar a conclusiones y transformar
estos datos en información relevante, para que las empresas puedan abarcar
mejoras y soluciones que les ayuden a conseguir sus objetivos.
Las personas que se dedican al análisis de datos a través de este sistema son
conocidos como mineros o exploradores de datos, estos intentan descubrir
patrones en medio de enormes cantidades de datos. Su intención es la de aportar
información valiosa a las empresas para así, ayudarlas en la toma de decisiones
futuras. Pero debemos tener claro que la elección del mejor algoritmo para una
tarea analítica específica es un gran desafío, ya que podemos encontrar muchos
patrones distintos, y además, dependerá de los problemas a resolver. Estos pueden
ser la clasificación, regresión, segmentación, asociación y análisis de secuencias.
Los mineros o exploradores de datos a la hora de llevar a cabo un análisis de Data
Mining, deberán realizar cuatro pasos distintos:
1. Determinación de los objetivos: El cliente determina qué objetivos quiere
conseguir gracias al uso del Data Mining.

10. 10
2. Procesamiento de los datos: Selección, limpieza, enriquecimiento,
reducción y transformación de la base de datos.
3. Determinación del modelo: Primero se debe hacer un análisis estadístico
de los datos y después visualización gráfica de los mismos.
4. Análisis de los resultados: En este paso se deberán verificar si los
resultados obtenidos son coherentes.
Actualmente este tipo de trabajos se están realizando en seguridad de
datos, finanzas, salud, marketing, detección de fraude, búsquedas online,
procesamiento del lenguaje natural, coches inteligentes, entre otros. Es por este
motivo, que la minería de datos se está convirtiendo en uno de los trabajos con
mayor proyección para el futuro.

11. 11
Herramientas OLAP
Su nombre proviene de On-Line Analytical Processing, que significa Procesamiento
Analítico en Línea, y como dijimos se basa en el análisis de grandes cantidades de
datos usando estructuras multidimensionales, a los que llaman cubos en donde se
resume los mismos o los sistemas de transacciones OLTP. Este sistema utiliza los
informes de negocios de ventas, el mercadeo, los informes de dirección, minería de
datos y muchos otros más para establecer sus sistemas.
Estas herramientas son utilizadas para conseguir respuestas de consulta rápidas,
esta base de datos logra almacenar todos los datos en tablas normalizadas, se
considera que esta estructura OLAP es muy buena porque permite procesar todos
estos datos en diversos campos para tenerlos a la mano para consultas y análisis
posteriores, que permitan elaborar informes para mejorar las operaciones de
producción, hacer una toma de decisiones de manera inteligente y poder tener una
optimización en la competencia del mercado.
Como es una base que se orienta hacia el procesamiento analítico de información,
en el mismo se hace la lectura de muchos datos que presenten las siguientes
características:
 Que su acceso sea para solo lectura, a través de consultas, que por lo
general presentan pocas inserciones de nuevos datos, actualizaciones de los
mismos o eliminaciones.
 Estos datos se deben estructurar de acuerdo a las áreas de negocios de la
empresa y en formatos que se puedan integran con uniformidad en toda la
empresa.
 El historial de los datos almacenados debe permanecer en uso por largo
plazo, en un tiempo que puede ir de dos a cinco años.
 Estas bases deben tener fuentes de alimentación que vengan de los mismos
sistemas operativos que existen en la empresa, y se buscan a través de
métodos de extracción, transformación y de carga (ETL).

12. 12
References
González, A. J. (n.d.). RMI: Remote Method Invocation. Utfsm.Cl. Retrieved
October 15, 2021, from
http://profesores.elo.utfsm.cl/~agv/elo330/2s09/lectures/RMI/RMI.html
Ribas, E. (2018). ¿Qué es el Data Mining o minería de datos? Thinking for
Innovation. https://www.iebschool.com/blog/data-mining-mineria-datos-
big-data/
Sandoval, L. (2020, November 4). LAS HERRAMIENTAS OLAP, ¿QUÉ SON Y
CUÁL ES SU USO? Ventanainformatica.com.
https://ventanainformatica.com/software/herramientas-olap/
UNIDAD 4: COM/DCOM (component object model/Distributed COM). (n.d.).
Blogspot.Com. Retrieved October 15, 2021, from
http://soteloperlaitiiguala.blogspot.com/p/45-dcom-distributed-com.html
(N.d.). Jtech.Ua.Es. Retrieved October 15, 2021, from
http://www.jtech.ua.es/j2ee/2003-2004/modulos/eai/sesion05-
apuntes.html