INTEROPERABILIDAD.

Presentación del tema: "INTEROPERABILIDAD."— Transcripción de la presentación:

1 INTEROPERABILIDAD

2 INTEGRACIÓN Son sistemas que se encuentran lógicamente integradas y provistas de una sola imagen de la BD, aún cuando se encuentran físicamente distribuidas. En años recientes, nuevas aplicaciones distribuidas han comenzado a solicitar nuevos requerimientos. La integración de las BDs envuelve el proceso por el cual la información de las BD participantes, pueden conceptualmente integrarse para formar una sola definición de Multi BD.

3 La integración puede ocurrir en dos pasos:
En otras palabras, es el proceso del Diseño del Esquema Conceptual Global. Es decir, ya se cuentan con las BDs individuales locales, y sólo se interconectan lógicamente. El diseño del esquema conceptual global envuelve la integración de estos componentes de BD en una Multi BDs. La integración puede ocurrir en dos pasos: Esquema de Traducción (o sólo Traducción) Esquema de Integración

4 ESQUEMA DE TRADUCCIÓN Es la tarea de mapeo de un esquema a otro. Claramente, el paso de traducción se necesita solamente si los componentes de BDs son heterogéneos. Y donde cada esquema local puede estar definido usando un modelo de datos diferente. En años recientes, el interés comercial se ha enfocado a la integración de múltiples BDs Relacionales, donde el paso de traducción se puede pasar por alto.

5 El esquema de traducción requiere de la espcificación de un modelo de datos origen, para la definición del esquema conceptual global. ESQUEMA DE INTEGRACIÓN Este esquema sigue al proceso de traducción y genera el esquema conceptual global, integrando los esquemas intermedios. Este esquema es el proceso de Identificar los componentes de una BD que están relacionados uno con otro.

6 El esquema de integración involucra dos tareas.
Homogenización. Determina los “problemas” estructurales y semánticos de cada BD componente. Básicamente se refiere a las diferencias entre las BD que relacionan significados e interpretación de los datos. Por ejemplo: Un problema fundamental de nombres. Dos entidades idénticas que tienen diferentes nombres son sinónimas; y dos diferentes entidades que tienen nombres idénticos son homónimas. Integración. Sigue después de la homogenización e involucra la mezcla de los esquemas de las múltiples BDs, para crear el esquema global.

7 PROCESAMIENTO DE CONSULTAS.
El Procesamiento de Consultas Distribuidas se caracteriza por cuatro pasos: Descomposición de la Consulta. Localización de los Datos. Optimización Global. Optimización Local. Esta es una generalización de los pasos del procesamiento de consultas en un SMBD centralizada, la cual incluye solamente: Descomposición, Optimización y Ejecución.

8 PROCESAMIENTO DE CONSULTAS.
La naturaleza de los Sistemas de MultiBase de Datos requieren pasos un poco diferentes. Hay que recordar que los sistemas MultiBD es una capa de software que se ejecuta encima de los SMBD. Donde cada SMBD tiene su propio procesador de consultas. El cual ejecuta las consultas de acuerdo a los tres pasos listados en un SMBD centralizado.

9 PROCESAMIENTO DE CONSULTAS.
El procesamiento de consultas en un sistema de MultiBD es más complejo que en un SMBDD, por las siguientes razones: La capacidad del componente de SMBD puede ser diferente. Similarmente, el costo de procesamiento de las consultas puede ser diferente en cada SMBD diferente. Puede haber dificultades al mover datos entre SMBD. La capacidad de optimización local de cada SMBD puede ser completamente diferente. La Autonomía de Comunicación significa que un componente de SMBD puede terminar su servicio en cualquier momento.

10 PROCESAMIENTO DE CONSULTAS.
Esa autonomía de comunicación, requiere técnicas de procesamiento de consultas que sean tolerantes a fallos en el sistema. La pregunta es cómo el sistema responderá a consultas cuando un componente del sistema se encuentre inaccesible desde el comienzo o se apague en mitad de la ejecución de la consulta. La Autonomía de Ejecución en los sistemas de MultiBD hace difícil aplicar algunas de las estratégias de optimización de consultas.

11 Estructura de un Multi-SMBD Distribuido
USUARIO USUARIO Respuesta del sistema Solicitud de usuario Respuesta del sistema Solicitud de usuario Capa de Multi-SMBD Capa de Multi-SMBD SMBD Componente . . . SMBD Componente SMBD Componente . . . SMBD Componente SITIO 1 SITIO n Estructura de un Multi-SMBD Distribuido

12 PROCESAMIENTO DE CONSULTAS.
En esta arquitectura existe una capa del Multi-SMBD en cada sitio. Es por esto que la ejecución de una consulta distribuida en un Multi-SMBD distribuida involucra de la cooperación entre varios Multi-SMBD local. En un SMBDD, el procesador de consultas tiene que ver sólo con la distribución de datos a través de múltiples sitios.

13 PROCESAMIENTO DE CONSULTAS.
En un ambiente de Multi-SMBD distribuido, los datos son distribuidos no sólo a través de sitios, sino también a través de múltiples BD. Donde cada una es administrada por un SMBD autónomo. CAPA DE PROCESAMIENTO DE CONSULTAS Cuando una consulta se recibe en un sitio, el primer paso que se necesita hacer es “dividirla” en subconsultas, basado en la distribución de los datos a través de lo sitios.

14 CAPA DE PROCESAMIENTO DE CONSULTAS
En este paso, es sólo necesario preocuparse acerca de la colocación de los datos, en vez de su almacenamiento a través de varias BD. La única información que se requiere es la información de la colocación de datos, almacenada en un directorio global (metadatos). El sitio que recibe la consulta y ejecuta la división, llamado “Sitio de Control”, es responsable de la correcta ejecución de la tarea.

15 CAPA DE PROCESAMIENTO DE CONSULTAS
Cada subconsulta es después enviada al sitio donde va a ser procesada. Cada subconsulta es traducida al correspondiente lenguaje del respectivo SMBD. Las consultas enviadas a los componentes de SMBD son procesadas de la siguiente manera: Descomposición, Optimización y Ejecución. El paso de la descomposición involucra la simplificación de la consulta del usuario, que se especifica en algún cálculo relacional y su traducción a un equivalente de consulta de algebra relacional.

16 CAPA DE PROCESAMIENTO DE CONSULTAS
El paso de optimización involucra la reordenación de las operaciones de algebra relacional, así como la determinación de la mejor ruta de acceso a los datos. El resultado de estos pasos es programado y se ejecuta por el procesador de soporte de ejecución. OPTIMIZACIÓN DE CONSULTAS La optimización de consultas en los multi-SMBD es similar a los SMBDD en algunos aspectos, pero diferentes en otros.

17 OPTIMIZACIÓN DE CONSULTAS
Así como con los SMBDD heterogéneas, la optimización de consultas en los multi-SMBD pueden ser basados en heurística o basado en costo. Dos alternativas heurísticas pueden ser empleadas en la descomposición de una consulta en subconsultas. 1er. Alternativa. Se descompone una consulta global en subconsultas, lo más pequeñas posible, cada una ejecutada por un componente de SMBD. Múltiple subconsultas pueden ser enviadas a un componente de SMBD dado. El procesador de consultas global recolecta los resultados parciales.

18 OPTIMIZACIÓN DE CONSULTAS Este enfoque tiene dos ventajas:
La descomposición es relativamente simple. Hay más oportunidades para la optimización en el nivel del optimizador de consulta global. Las desventajas: El procesador/optimizador de consulta global hace más trabajo. Hay más transferencia de mensajes al ejecutar una consulta. 2a. Alternativa heurística. Descompone la consulta global en subconsultas, lo más grande posible. Y cada una de éstas se ejecuta en un SMBD.

19 OPTIMIZACIÓN DE CONSULTAS
Cada SMBD componente ejecuta sólo una subconsulta. Los resultados son recolectados por el procesador de consulta global. En este caso, el procesador/optimizador de consulta global hace menos trabajo, debido a que el procesamiento inter-sitios se minimiza. Se reduce el paso de mensajes. La característica de la optimización de consultas basada en costos, se basa principalmente en términos de funciones de costo.

20 OPTIMIZACIÓN DE CONSULTAS
La principal razón de utilizar algoritmo basado en costo, es que las consultas globales involucran operaciones inter-sitios. Lo cual requiere optimización en el nivel de multi-SMBD, sobre todo en la optimización de reuniones inter-SMBD. ADMINISTRACIÓN DE TRANSACCIONES El reto es permitir actualizaciones globales concurrentes en los componentes de BD, sin violar su autonomía.

21 ADMINISTRACIÓN DE TRANSACCIONES
La autonomía de ejecución implica que las funciones de administración de transacción global, son efectuadas de manera independiente de las funciones de ejecución de los componentes. Es decir, que los componentes SMBD (más específicamente sus administradores de transacciones) no son modificados para acoplarse a una actualización global. El diseño de autonomía tiene la implicación adicional de que los administradores de transacciones de cada SMBD, pueden emplear diferentes protocolos de control de concurrencia y compromiso.

22 ADMINISTRACIÓN DE TRANSACCIONES
La arquitectura MSMBD involucra un número de SMBD, cada cual con su propio administrador de transacciones, llamado Administrador de Transacciones Locales. Y una capa de MSMBD en la parte superior. El administrador de transacciones del MSMBD se llama Administrador de Transacciones Globales.

23 Componentes de un MSMBD
USUARIO Respuesta del sistema Solicitud de usuario Capa de Multi-SMBD SMBD SMBD procesador de consultas procesador de consultas administrador de transacción administrador de transacción . . . planificador planificador administrador de recuperación administrador de recuperación procesador de ejecución procesador de ejecución

24 CONTROL DE CONCURRENCIA EN UN MSMBD
Existen propuestas para asegurar la consistencia en la ejecución de transacciones en un ambiente de Multi-BD. Algoritmos de control de concurrencia sincronizan transacciones concurrentes, ordenando sus operaciones conflictivas. Tal como si fueran ordenadas en serie (o serializables) las transacciones. No es fácil para el administrador de transacciones global (ATG) determinar conflictos en un MSMBD.

25 CONTROL DE CONCURRENCIA EN MSMBD
Ya que no son fácil de detectar por el ATG. Incluso transacciones locales pueden causar conflictos entre las transacciones. Y este tipo de conflictos indirectos no pueden ser detectados por el ATG, y es una fuente significativa de dificultas en los MSMBD. Existen condiciones que ayudan a determinar la funcionalidad mínima requerida por los administradores de transacciones.

26 CONTROL DE CONCURRENCIA EN MSMBD
Primer condición para proveer control de concurrencia global, se necesita tener administradores de BD individuales que garanticen la atomicidad de sincronización local. Esto significa que los administradores de transacción local (ATL) son responsables por la correcta ejecución de las transacciones en su respectiva BD. Segunda condición, el ATG es responsable de coordinar el envío de las subconsultas a los ATL y coordinar su ejecución.

27 CONTROL DE CONCURRENCIA EN MSMBD
El ATG es responsable de lidiar con el interbloqueo que ocurra entre las transacciones globales.

28 INTEROPERABILIDAD ENTRE OBJETOS

29 ORIENTADO A OBJETOS E INTEROPERABILIDAD
Hay un buen número de plataformas de computación de objetos distribuidos cuyo principal propósito es facilitar el desarrollo de sistemas abiertos. Permitiendo a las aplicaciones, con esto, comunicarse fácilmente con entre sí. Una de estas plataformas es la Arquitectura de Administración de Objetos (OMA).

30 ORIENTADO A OBJETOS E INTEROPERABILIDAD
OMA es del Grupo de Administración de Objetos (OMG). Otro ejemplo de estas plataformas de objetos distribuidos es el Modelo de Objeto Componente (COM), Modelo de Objeto Componente Distribuido (DCOM) y el ambiente de Objeto Ligado e Incrustado (OLE) de Microsoft. Las plataformas proveen una infraestructura que soporta comunicación entre componentes, y entre programas de aplicación y componentes.

31 ORIENTADO A OBJETOS E INTEROPERABILIDAD
E incorporan servicios que son necesitados comúnmente por todas las aplicaciones distribuidas. Estas diversas plataformas difieren en cómo llevan a cabo estos objetivos. ARQUITECTURA DE ADMINISTRACIÓN DE OBJETOS (OMA) OMA es un ambiente definido por la OMG. La OMG es un consorcio de industriales que apoyan el enfoque Orientado a Objetos.

32 OMA OMA define un modelo de objeto común, un modelo común de interacciones por medio de invocaciones de objetos, y un conjunto de servicios y facilidades de objetos comunes. CORBA (COMMON OBJECT REQUEST BROKER) Es el mecanismo de comunicación clave de OMA, en el cual los objetos se comunican con otros vía del Agente de Solicitud de Objeto (ORB, object request broker).

33 CORBA

34 CORBA (COMMON OBJECT REQUEST BROKER)
Es un estándar que establece una plataforma de desarrollo de sistemas distribuidos. Facilitando la invocación de métodos remotos bajo un paradigma orientado a objetos. CORBA fue definido y está controlado por el Object Management Group (OMG).

35 CORBA La OMG define las APIs, el protocolo de comunicaciones y los mecanismos necesarios para permitir la interoperabilidad entre diferentes aplicaciones escritas en diferentes lenguajes y ejecutadas en diferentes plataformas, lo que es fundamental en computación distribuida. En un sentido general, CORBA "envuelve" el código escrito en otro lenguaje en un paquete que contiene información adicional sobre las capacidades del código que contiene, y sobre cómo llamar a sus métodos.

36 CORBA Los objetos que resultan pueden entonces ser invocados desde otro programa (u objeto CORBA) desde la red. En este sentido CORBA se puede considerar como un formato de documentación legible por la máquina, similar a un archivo de cabeceras pero con más información. ORB, acrónimo de Object Request Broker.

37 CORBA El ORB, en computación distribuida es el nombre que recibe una capa de software (también llamada Middleware), que permite a los objetos realizar llamadas a métodos situados en máquinas remotas, a través de una red. Maneja la transferencia de estructuras de datos, de manera que sean compatibles entre los dos objetos. Para ello utiliza un estándar para convertir las estructuras de datos en un flujo de bytes, conservando el orden de los bytes entre distintas arquitecturas.

38 CORBA El ORB provee de servicios entre los servidores y los clientes. Básicamente permite a objetos distribuidos interactuar entre sí de manera transparente, es decir, como si estuviesen en la misma máquina. Los clientes envían una solicitud al ORB preguntando por ciertos servicios, para ser ejecutados por cualquier servidor que cubra ese requisito. El ORB encuentra el servidor, le pasa el mensaje del cliente, y recibe los resultados, los cuales se pasan al cliente.

39 CORBA La comunicación básica entre dos objetos CORBA se efectúa gracias al núcleo ORB. En la mayoría de las implementaciones del ORB, existen métodos IPC (Inter-Process Communication). Que son como en UNIX bibliotecas de sockets, memoria compartida y bibliotecas de multihilos. Que se usan para lograr la comunicación entre clientes, servidores y el ORB.

40 CORBA El ORB puede ser tan simple como una biblioteca que soporta la comunicación entre objetos y sus clientes los cuales pueden co-residir en el mismo espacio de procesamiento. Para crear una solicitud, el cliente necesita conocer las operaciones que va a pedir de un objeto. Es decir, necesita conocer la interfaces del objeto que responderá a la solicitud. Las interfaces son definidas por medio del Lenguaje de Definición de Interfaces (IDL).

41 CORBA CORBA utiliza el Lenguaje de Definición de Interfaces (IDL), para especificar los interfaces con los servicios que los objetos ofrecerán. CORBA puede especificar a partir de este IDL la interfaz a un lenguaje determinado, describiendo cómo los tipos de dato CORBA deben ser utilizados en las implementaciones del cliente y del servidor. Implementaciones estándar existen para Ada, C, C++, Smalltalk, Java y Python. Hay también implementaciones para Perl y TCL.

42 CORBA El IDL es independiente del lenguaje Host, es un lenguaje declarativo. No es un lenguaje de programación. Obliga a las interfaces a ser definidas de manera separada de las implementaciones de los objetos. Y los objetos, así como sus implementaciones, pueden ser construidos usando lenguajes de programación diferentes. Los compiladores de IDL generan parte de código (stubs) del lado del cliente.

43 CORBA Al compilar una interfaz en IDL se genera código para el cliente y el servidor (el implementador del objeto). El código del cliente sirve para poder realizar las llamadas a métodos remotos. Es el conocido como stub, el cual incluye un proxy (representante) del objeto remoto en el lado del cliente. El código generado para el servidor consiste en unos skeletons (esqueletos) que el desarrollador tiene que rellenar para implementar los métodos del objeto.

44 CORBA Es decir, se genera código (skeleton) plantilla del lado del servidor. Estos segmentos de código, de interface-específica, cooperan para un intercambio efectivo de solicitudes y resultados. CORBA 2.0 especifica una arquitectura de interoperabilidad basada sobre el protocolo GIOP (General Inter-ORB Protocol).

45 CORBA GIOP especifica una sintaxis de transferencia y un conjunto estándar de formatos de mensajes para ORB en la inter-operación sobre cualquier transporte orientada-a-conexión. CORBA 2.0 también soporta el protocolo IIOP (Internet Inter-ORB Protocol), el cual es una implementación de GIOP sobre el transporte TCP/IP. Con IIOP, los ORBs pueden inter-operar con otros sobre Internet.

46 Implementación de Objeto
ARQUITECTURA DE CORBA Cliente Implementación de Objeto Interface de Patrón Dinámico (DSI) Interface de Invocación Dinámica (DII) Adaptador de Objeto Repositorio de Interface (IR) Patrón IDL Stubs IDL Interface ORB Núcleo ORB

47 CORBA GIOP (Protocolo Entre ORBs General) es el protocolo abstracto por el cual los ORBs se comunican. CORBA es más que una especificación multiplataforma, también define servicios habitualmente necesarios como seguridad y transacciones.

48 CORBA

49 Motivating Mission-Critical Applications
Large-scale Switching Systems Total Ship C&C Center Total Ship Computing Environments IOM BSE Avionics Industrial Process Control Theater Missile Defense

50 CORBA

51 CORBA

52

53 Applying Real-time CORBA to Time-Critical Targets
Challenges are also relevant to TBMD & NMD Goals Detect, identify, track, & destroy time-critical targets Key Solution Characteristics Efficient & scalable Affordable & flexible COTS-based Adaptive & reflective High confidence Safety critical Adapted from “The Future of AWACS”, by LtCol Joe Chapa Joint Forces Global Info Grid Real-time mission-critical sensor-to-shooter needs Highly dynamic QoS requirements & environmental conditions Multi-service & asset coordination Key System Characteristics

54 CORBA

55 CORBA E INTEROPERABILIDAD CON BD
Así como una plataforma de computación distribuida orientada-a-objetos, OMA, y en particular CORBA pueden ser útiles para la interoperabilidad con BD. La heterogeneidad en un sistema distribuido puede darse en el nivel de hardware y sistema operativo, en el nivel de comunicación y en el nivel de SMBD. CORBA trata principalmente con la heterogeneidad de plataforma y comunicación. También trata con la heterogeneidad de los SMBD por medio de la definición de interfaces con IDL.

56 JAVA RMI

57 RMI RMI (Java Remote Method Invocation) es el mecanismo ofrecido en Java que permite a un procedimiento (método, clase, aplicación o como guste llamarlo) poder ser invocado remotamente. Una de las ventajas al diseñar un procedimiento con RMI es su interoperabilidad. Ya que RMI forma parte de todo JDK, por ende, cualquier plataforma que tenga acceso a un JDK también tendrá acceso a estos procedimientos.

58 RMI Esto es algo que lo hace diferente al clásico CORBA, que requiere de otros criterios. Por medio de RMI, un programa java, al que llamaremos servidor, pone uno de los objetos que instancia accesible desde red. De forma que otros programas java en red, que llamaremos clientes, pueden invocar métodos de este objeto. De ahí el nombre de "Remote Method Invocation"

59 RMI Cuando un cliente java le pide al servidor un objeto e invoca a uno de sus métodos, el código de dicho método se ejecuta en el servidor. El código del cliente queda en espera de que el servidor termine de ejecutar el método y devuelva un resultado.

60 COM/DCOM DE MICROSOFT

61 DCOM (DISTRIBUTED COMPONENT OBJECT MODEL)
El Modelo de Objetos de Componentes Distribuidos (Distributed Component Object Model o DCOM) es una tecnología propietaria de Microsoft para desarrollar componentes software distribuidos sobre varias computadoras y que se comunican entre sí. Extiende el modelo COM y proporciona la base de comunicación entre la infraestructura del servidor de aplicaciones COM+ de Microsoft. Ha sido abandonada en favor del framework .NET.

62 DCOM El ambiente DCOM/OLE (object linking embedding) de Microsoft, se puede ver como una alternativa a la estructura de CORBA . DCOM es similar en funcionalidad a CORBA ORB. El origen de DCOM es COM (Component Object Model). El modelo de objetos de COM es completamente diferente de CORBA. Los objetos de COM no son realmente “objetos”.

63 Por ejemplo: los objetos COM no tienen identificadores.
DCOM Por ejemplo: los objetos COM no tienen identificadores. No hay herencia definida entre clases de objetos. Las aplicaciones obtienen un apuntador a las interfaces que apuntan a los métodos que las implementan. Los objetos COM existen en dos formas: DLLs EXEs

64 DCOM Las DLLs deben residir en la misma plataforma donde reside el cliente (servicio local). Los objetos EXEs pueden ser accesados vía red (servicio remoto). Los cliente accesan los objetos COM por medio de las interfaces definidas para cada objeto.

65 Tabla de Función Interface
OBJETOS COM e INTERFACES IUnknown Cliente Tabla de Función Interface Objeto COM Datos Internos Interface de Implementación

66 La adición de la "D" a COM fue debido al uso extensivo de DCE/RPC.
DCOM La adición de la "D" a COM fue debido al uso extensivo de DCE/RPC. O más específicamente a la versión mejorada de Microsoft, conocida como MSRPC. En términos de las extensiones que añade a COM, DCOM tenía que resolver los problemas de: Aplanamiento – Serializar (marshalling) y deserializar (unmarshalling) los argumentos y valores de retorno de las llamadas a los métodos "sobre la red".

67 DCOM Recolección de basura distribuida, asegurándose que las referencias mantenidas por clientes de las interfaces sean liberadas cuando, por ejemplo, el proceso cliente ha caído o la conexión de red se pierde. Uno de los factores clave para resolver estos problemas fue el uso de DCE/RPC, como el mecanismo RPC subyacente bajo DCOM. DCE/RPC define reglas estrictas en cuanto al aplanamiento y a quién es responsable de liberar la memoria.

68 DCOM El paso de COM a DCOM fue algo natural, porque la mayoría de las bibliotecas de funciones soportan componentes distribuidos y de red. Windows provee el código necesario para localizar y comunicarse con componentes sobre una red. Esta facilidad permite a los clientes localizar componentes a través de la red ya sea de manera transparente o solicitando un componente que reside en determinada máquina.

69 DCOM Haciendo “remoto” a un componente no requiere cambios en la implementación de su componente o del cliente que lo accesa. La comunicación se mantiene vía el Registro de Windows y las facilidades de la red. OLE proporciona el encapsulamiento al objeto COM junto con la Fábrica de Clases para la creación de objetos.

70 DCOM DCOM fue uno de los mayores competidores de CORBA. Los defensores de ambas tecnologías sostenían que algún día serían el modelo de código y servicios sobre Internet. Sin embargo, las dificultades que enfrentaron para poder conseguir que funcionasen a través de firewalls y sobre máquinas inseguras o desconocidas, los limitó.

71 DCOM Esto significó que las peticiones HTTP normales, combinadas con los navegadores web, les ganasen la partida.

72 COM/OLE e INTEROPERABILIDAD CON BD
La interoperabilidad con las BD en el ambiente COM/OLE, se provee por OLE DB. OLE DB extiende al ambiente OLE hacia el repositorio de datos. Define una interface uniforme para todos los repositorios de datos en la forma de conjunto de registros. En otras palabras, todos los proveedores de datos OLE DB exponen sus datos como registros, los cuales son representaciones tabulares.

73 COM/OLE e INTEROPERABILIDAD CON BD
Un objeto conjunto de registros sirve como envoltura que provee una interface uniforme. En su forma básica, un objeto conjunto de registros tiene tres interfaces, además de la IUnknown. IRowset: provee métodos para iteraciones secuenciales sobre los registros. IColumnsInfo: provee información acerca de las columnas de los registros. IAccessor: permite la definición de columnas ligadas a las variables de los programas de los clientes.

74 ABSTRACCIÓN DEL OBJETO CONJUNTO DE REGISTRO (ROWSET)
IUnknown IRowset IColumnInfo Rowset Object IAccessor Fuente de Datos

75 COM/OLE e INTEROPERABILIDAD CON BD
Existen más interfaces elaboradas sobre OLE DB, que son definidas para insertar, eliminar y modificar registros. Existen proveedores comerciales de OLE DB para muchos SMBD relacionales. Y estos productos pueden ser usados para lograr marcos de interoperabilidad entre estos sistemas relacionales.

76 COM/OLE e INTEROPERABILIDAD CON BD
OLE DB es una interfaz de acceso a datos basada en el COM. Soporta aplicaciones escritas usando OLE DB o Interfaces de Objetos de Datos basadas en OLE DB. Puede accesar a la información fácilmante que se encuentre en MSQL Server, en otras Bases de Datos relacionales y otras fuentes de datos.

77

78 COM/OLE e INTEROPERABILIDAD CON BD
Conectividad en Bases de Datos Abiertas (ODBC, Open DataBase Connectivity). Es una interfaz por capas. Soporta aplicaciones o componentes que estén escritos usando ODBC o interfaces basadas en ODBC. Puede accesar a los datos en SQL Server, y otras Bases de Datos relacionales, pero generalmente no puede ser usado para accesar otras fuentes de datos.

79 COM/OLE e INTEROPERABILIDAD CON BD
ADO (Active X Data Objects), encapsula la OLE DB API en un modelo simplificado de objetos que reduce el desarrollo de aplicaciones y los costos de mantenimiento. ADO puede ser usado a partir de Microsoft Visual Basic, Visual Basic para Aplicaciones, Active Server Pages (ASP) y el Scripting Object Model de Microsoft Internet Explorer.

80 SOAP

81 SOAP SOAP (siglas de Simple Object Access Protocol) es un protocolo estándar creado por Microsoft, IBM y otros, está actualmente bajo el auspicio de la W3C. SOAP define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. SOAP es uno de los protocolos utilizados en los servicios Web.

82 SOAP SOAP define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. SOAP es uno de los protocolos utilizados en los servicios Web. A diferencia de DCOM y CORBA, que son binarios, SOAP usa el código fuente en XML, que facilita la eliminación de errores, pero es menos efectivo.

83 SOAP El intercambio de mensajes se realiza mediante tecnología de componentes (software componentry). El término Object en el nombre significa que se adhiere al paradigma de la POO. SOAP es un marco extensible y descentralizado que permite trabajar sobre múltiples pilas de protocolos de redes. Los RPC pueden ser modelados en la forma de varios mensajes SOAP interactuando entre sí.

84 SOAP SOAP funciona sobre cualquier protocolo de Internet, generalmente HTTP, que es el único homologado por el W3C. SOAP tiene como base XML, con un diseño que cumple el patrón Cabecera-Desarrollo de diseño de software, como otros muchos diseños, prueba en HTML. La cabecera Header es opcional y contiene metadatos sobre enrutamiento (routing), seguridad o transacciones.

85 SOAP El desarrollo Body contiene la información principal, que se conoce como carga útil (payload). HTTP fue elegido como protocolo de transporte por sus ventajas, para lidiar con cortafuegos. Por ejemplo, otros protocolos como GIOP/IIOP o DCOM, suelen ser repelidos por los cortafuegos.

86 Ejemplos de mensajes SOAP
Como ejemplo se muestra la forma en que un cliente solicitaría información de un producto a un proveedor de servicios Web: <soap:Envelope xmlns:soap=" <soap:Body> <getProductDetails xmlns=" <productId>827635</productId> </getProductDetails> </soap:Body> </soap:Envelope> .

87 Y esta sería la respuesta del proveedor:
SOAP Y esta sería la respuesta del proveedor: <soap:Envelope xmlns:soap=" <soap:Body> <getProductDetailsResponse xmlns=" <getProductDetailsResult> <productName> Toptimate 3-Piece Set </productName> <productId> </productId> <description> 3-Juegos de Maletas. Piel Negra.</description> <price> </price> <inStock> true </inStock> </getProductDetailsResult> </getProductDetailsResponse> </soap:Body> .

88 ARQUITECTURA .NET

89 .NET .NET es un proyecto de Microsoft para crear una nueva plataforma de desarrollo de software de código abierto. Con énfasis en la transparencia de redes, con independencia de plataforma y que permita un rápido desarrollo de aplicaciones. Basado en esta plataforma, Microsoft intenta desarrollar una estrategia horizontal que integre todos sus productos, desde el Sistema Operativo hasta las herramientas de mercado.

90 .NET .NET podría considerarse como una respuesta de Microsoft al creciente mercado de los negocios en entornos Web, como competencia a la plataforma Java de Sun Microsystems. A largo plazo Microsoft pretende reemplazar la API Win32 o Windows API con la plataforma .NET. Esto debido a que la API Win32 o Windows API fue desarrollada sobre la marcha, careciendo de documentación detallada, uniformidad y cohesión entre sus distintos componentes.

91 .NET Esta falta de estandarización y cohesión estuvo provocando múltiples problemas en el desarrollo de aplicaciones para el sistema operativo Windows. La plataforma .NET pretende solventar la mayoría de estos problemas proveyendo un conjunto único y expandible con facilidad, de bloques interconectados, diseñados de forma uniforme y bien documentados. Permitiendo a los desarrolladores tener a mano todo lo que necesitan para producir aplicaciones sólidas.

92 .NET Debido a las ventajas que la disponibilidad de una plataforma de este tipo puede darle a las empresas de tecnología y al público en general, muchas otras empresas e instituciones se han unido a Microsoft. Impulsando el desarrollo y fortalecimiento de la plataforma .Net. Aparte de la implementación de la plataforma para otros sistemas operativos: (Proyecto Mono de Ximian/Novell para Linux/MacOS X/BSD/Solaris).

93 Como controles, componentes y bibliotecas de clases adicionales.
.NET El desarrollo de lenguajes de programación adicionales para la plataforma (ANSI C de la Universidad de Princeton, NetCOBOL de Fujitsu, Delphi de Borland, entre otros). O bien, participando en la creación de bloques adicionales para la plataforma. Como controles, componentes y bibliotecas de clases adicionales. Siendo algunas de ellas software libre, distribuibles bajo la licencia GPL .

94 .NET Con esta plataforma Microsoft incursiona de lleno en el campo de los Servicios Web. Y establece el XML como norma en el transporte de información en sus productos y lo promociona como tal en los sistemas desarrollados utilizando sus herramientas. .NET intenta ofrecer una manera rápida y económica pero a la vez segura y robusta de desarrollar aplicaciones.

95 .NET Permitiendo .NET, a su vez una integración más rápida y ágil entre empresas y un acceso más simple y universal a todo tipo de información desde cualquier tipo de dispositivo. El “Framework" o marco de trabajo, constituye la base de la plataforma .Net. Y denota la infraestructura sobre la cual se reúnen un conjunto de lenguajes, herramientas y servicios que simplifican el desarrollo de aplicaciones en entorno de ejecución distribuido.

96 Diagrama detallado del Marco de Trabajo .NET
.NET Framework

97 .NET Bajo el nombre .NET Framework se encuentran reunidas una serie de normas impulsadas por varias compañías, además de Microsoft. Como Hewlett-Packard , Intel, IBM, Fujitsu Software, Plum Hall, la Universidad de Monash e ISE. Entre las normas se encuentran: La norma que define las reglas que debe seguir un lenguaje de programación, para ser considerado compatible con el marco de trabajo .NET (ECMA-335, ISO/IEC 23271).

98 La norma que define el lenguaje C# (ECMA-334, ISO/IEC 23270).
.NET (ECMA-335, ISO/IEC 23271). Por medio de esta norma se garantiza que todos los lenguajes desarrollados para la plataforma, ofrezcan al programador un conjunto mínimo de funcionalidad, y compatibilidad con todos los demás lenguajes de la plataforma. La norma que define el lenguaje C# (ECMA-334, ISO/IEC 23270). Este es el lenguaje insignia del marco de trabajo .NET, y pretende reunir las ventajas de lenguajes como C/C++ y Visual Basic en un solo lenguaje. La norma que define el conjunto de funciones que debe implementar la librería de clases base (BCL por sus siglas en inglés) (incluido en ECMA-335, ISO/IEC 23271).

99 .NET (ECMA-335, ISO/IEC 23271). Esta norma define un conjunto funcional mínimo que debe implementarse para que el marco de trabajo sea soportado por un sistema operativo. Aunque Microsoft implementó esta norma para su sistema operativo Windows, la publicación de la norma abre la posibilidad de que sea implementada para cualquier otro sistema operativo existente o futuro. Permitiendo que las aplicaciones corran sobre la plataforma, independientemente del sistema operativo para el cual haya sido implementada.

100 .NET El Proyecto Mono emprendido por Ximian, pretende realizar la implementación de la norma para varios sistemas operativos adicionales, bajo el marco del software libre o código abierto. El CLR (Common Language Runtime) es el verdadero núcleo del Framework de .Net. Es el entorno de ejecución en el que se cargan las aplicaciones desarrolladas en los distintos lenguajes, ampliando el conjunto de servicios del sistema operativo (W2k y W2003).

101 .NET La herramienta de desarrollo compila el código fuente de cualquiera de los lenguajes soportados por .Net en un código intermedio (MSIL, Microsoft Intermediate Lenguaje), similar al BYTECODE de Java. Para generar dicho código, el compilador se basa en el Common Language Specification (CLS) que determina las reglas necesarias para crear ese código MSIL compatible con el CLR.

102 .NET Para ejecutarse se necesita un segundo paso, un compilador JIT (Just-In-Time) es el que genera el código máquina real que se ejecuta en la plataforma del cliente. De esta forma se consigue con .Net independencia de la plataforma de hardware.

103 Common Language Runtime (CLR)
Diagrama de la estructura interna del Entorno de Común de Ejecución para Lenguajes (CLR) Common Language Runtime (CLR)

104 .NET La compilación JIT la realiza el CLR a medida que el programa invoca métodos. El código ejecutable obtenido, se almacena en la memoria caché del ordenador, siendo recompilado de nuevo sólo en el caso de producirse algún cambio en el código fuente.

105 Principles Of Distributed Database Systems 2ª. Ed.
M. Tamer Ozsu y Patrick Valduriez Prentice Hall Fundamentos de Bases de Datos 4a. Edición Silberschatz, Korth y Sudarshan Mc Graw Hill Procesamiento de Bases de Datos 8a. Ed. David M. Kroenke Pearson. Introducción a los Sistemas de Bases de Datos 7a. Ed. C. J. Date Prentice Hall.

106