Técnicas Avanzadas para Gestión de Sistemas de Información. Tarea obligatoria sobre: Tecnologías para Sistemas de Información

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Técnicas Avanzadas para Gestión de Sistemas de Información. Tarea obligatoria sobre: Tecnologías para Sistemas de Información"

Transcripción

1 Instituto de Computación Facultad de Ingeniería Universidad de la República Oriental del Uruguay Técnicas Avanzadas para Gestión de Sistemas de Información Carrera de Ingeniería en Computación Edición 2003 Tarea obligatoria sobre: Tecnologías para Sistemas de Información Título Estudiantes Estado del Arte en Federico Becaría Rodrigo Suárez Fabián Feijó Bernardo Fagalde Docente encargado: Dr. Ing. Hermann Steffen 1

2 T.A.G.SI Bernardo Fagalde Fabián Feijó Federico Becaría Rodrigo Suárez Instituto de Computación Facultad de Ingeniería Universidad de la República

3 Índice Índice... 2 Abstract... 4 Contexto... 4 Contenido... 4 I. Introducción... 4 Ubicación lógica... 6 Ubicación física... 6 Otras funcionalidades... 7 II. BEA TUXEDO Un poco de historia... 8 Características del sistema... 8 Componentes ATMI... 9 Infraestructura de BEA Tuxedo... 9 Interface de Programación ATMI BEA Tuxedo Workstation Componentes CORBA Tuxedo IIOP Listener/Handler Objetos de ambiente y TP Framework Cliente ActiveX Escalabilidad y Performance Soporte de plataformas, lenguajes y modelos de programación Seguridad Herramientas de administración Estándares soportados Acceso web a los servicios de aplicación de BEA Tuxedo Acceso a los servicios de aplicación de Tuxedo a través de Web Services III. MTS (Microsoft Transaction Server) Un poco de historia Propósito del MTS Características El modelo de operaciones en MTS Arquitectura de MTS Los componentes MTS Actividad Transaccional Dispensadores de Recursos Activación Just-in-Time Pooling de Recursos Seguridad Lenguajes y modelos de programación Component Object Model (COM) Componentes y objetos Conceptos fundamentales de COM DCOM COM El explorador COM Creación e instalación de paquetes IV ENCINA Especificaciones varias: Características generales Página 2 de 34

4 Soporte de estándares de la industria: Soporte de plataformas populares: Soporte de lenguajes de programación Escalabilidad y performance Alta disponibilidad y manejo de errores Seguridad Herramientas para administración: Componentes en el cliente y el servidor V Comparación Costos transaccionales entre MTS y Tuxedo Competencia de Encina Comparación entre Encina y Tuxedo Comercial Portabilidad e Interoperabilidad: Productividad de Programación: Integración con sistemas Legacy: Seguridad Escalabilidad Almacenamiento de Datos: Apéndice I: Glosario Apéndice II: Referencias Webgrafía Bibliografía Página 3 de 34

5 Abstract En este documento presentamos una visión general del estado actual de los monitores transaccionales. Se desarrollan a grandes rasgos tres de los productos mas conocidos en el mercado actual que implementan un monitor transaccional: TUXEDO, MTS y ENCINA Contexto Este trabajo se desarrolla en el marco de un obligatorio del curso Técnicas avanzadas para la gestión del Sistemas de Información (versión 2003). Esta materia forma parte de las materias electivas de la carrera de Ingeniería de computación de la Facultad de la República. Contenido En el primer Capítulo se define un monitor transaccional, se presenta a grandes rasgos la evolución de los mismos, su ubicación y se resume las funcionalidades más importantes que poseen. En los tres siguientes Capítulos se presentan los tres productos mas conocidos en el mercado actual que implementan un monitor transaccional: Capítulo II: TUXEDO, de BEA Systems Capítulo III: MTS, de Microsoft Capítulo IV: ENCINA, de IBM En el Capítulo V se presentan comparaciones entre los productos expuestos. En el Apéndice I se presenta el glosario y en el Apéndice II las referencias I. Introducción En la historia del acceso centralizado a datos, los primeros problemas que se plantearon fueron los de concurrencia al acceder a los mismos archivos. Estos problemas ya estaban siendo resueltos por los sistemas operativos multitarea. Por naturaleza, los problemas que resolvían eran los de acceso concurrente a distintos recursos. A medida que la tecnología y el volumen tanto de información como de usuarios fue aumentando, los Sistemas Operativos (SO) se vieron sobrecargados por estas actividades y su performance se vio afectada. Los Sistemas de Gestión de Base de Datos (SGBD) aparecieron como una solución para aliviar al SO y permitirle que se ocupara de las demás tareas. El SGBD se especializa en atender los requerimientos concernientes a la base de datos, pero de todas maneras no es independiente del SO. Estos requerimientos ya no eran simplemente consultas, sino que se maneja el concepto de transacción, fundamental para entender el ambiente en el que estamos desarrollando el tema. Por lo tanto daremos una pequeña introducción a lo que son y que características deben cumplir: Una transacción se define como una unidad lógica de procesamiento de base de datos. La duración de una transacción no es despreciable, pero lógicamente se debe ver como una unidad indivisible, es decir que se realiza por completo o no se realiza en absoluto. Una vez iniciada una transacción se considera distintos estados de la misma hasta su finalización. Cualquiera sea el camino que siga una transacción deberá Página 4 de 34

6 terminar habiendo logrado su objetivo inicial por completo o no habiéndolo logrado en absoluto. leer, escribir inicio fin trans. Parcialmente confirmar activa confirmada transacción confirmada abortar abortar fallida terminada Una vez iniciada la transacción, entra en un estado activo y permanece en él mientras se ejecuten las lecturas y escrituras que la componen. Una vez que estas hayan terminado pasa a un estado parcialmente confirmado hasta que el gestor de transacciones verifique la independencia de las lecturas y escrituras realizadas con las demás transacciones que se están ejecutando concurrentemente. También se chequea que la transacción quedará permanentemente registrada en caso de la caída del sistema. Si ambos chequeos resultan satisfactorios se confirmará la transacción y terminará. En caso contrario se abortará y resultará en una transacción fallida, deshaciendo lo realizado por la transacción y terminando. Un sistema transaccional debe tener la capacidad de mantener las características ACID de las mismas. Estas son: Atomicidad: (Atomicity) Una transacción es una unidad atómica de procesamiento. Se realiza por completo o no se realiza en absoluto Consistencia: (Consistency) La ejecución de la transacción no debe dejar a la Base de Datos en un estado inconsistente Aislamiento: (Isolation) Una transacción no debe afectar ni ser afectada por otra que se está ejecutando concurrentemente Durabilidad o permanencia: (Durability) Una vez que una transacción se ha confirmado, los efectos de modificación que esta tuvo en la Base de Datos deben ser mantenidos, incluso frente a una caída del sistema posterior. El manejo de los distintos estados, y el compromiso de mantener las características ACID son responsabilidad del SGBD. A medida que continuó el avance en los volúmenes de información y la concurrencia (especialmente esta última), el SGBD se ocupaba del manejo de las transacciones, y el cuello de botella se empezó a ver en la cantidad de conexiones que debían mantenerse (una por transacción). Para cada transacción era creado un proceso (asignación de recursos mediante) y luego se ejecutaba, cuando esta terminaba se consideraba el proceso finalizado y se liberaban los recursos asignados. Esta asignación de recursos, por lo tanto el proceso en sí era creado por el SO, aunque la ejecución y el acceso a la BD era manejado por el SGBD. Para atacar este problema se crean los monitores transaccionales (MT). Entonces, en principio los MT fueron creados para Página 5 de 34

7 gestionar los procesos (uno por conexión) que eran creados para acceder a la BD. Con el paso del tiempo se le fueron agregando otras funcionalidades como ser: - acceso a servicios (aplicaciones distribuidas) - balance de carga - control de seguridad (acceso a la BD) Por lo tanto, aplicaciones que acceden a la BD y antes estaban en el cliente o en el servidor se han trasladado al MT. Esto tiene la buena característica de no sobrecargar al servidor y ser accesible de mas puestos cliente. Ubicación lógica Un MT se encuentra en una capa intermedia entre los clientes (aplicaciones cliente) y el SGBD: MT El MT mantiene una conexión con cada cliente por cada requerimiento y una con el SGBD. También puede mantener mas de una conexión con el SGDB si la carga lo amerita, pero siempre mantendrá menor cantidad que las que mantiene con los clientes. Ubicación física El MT puede estar centralizado en un servidor o puede estar distribuido, parte en el cliente y parte en el servidor. Solamente en el servidor: Página 6 de 34

8 MT En el cliente y en el servidor: MT (client) MT (client) MT (client) MT (server) Otras funcionalidades Como se ha mencionado, en la evolución de los servidores transaccionales se le han ido agregando funcionalidades al mismo. La ubicación, ya que las transacciones pasan todas por él, lo hacen ideal para colocarle las políticas de seguridad a la BD y también aliviar al SGBD de esta tarea. Lo que en realidad no fue una ampliación de la funcionalidad, si no mas bien una fusión de componentes resulta en lo que hoy conocemos como servidor de aplicaciones. Los ORB (Object Request Brokers) eran componentes del SGBD que brindaban facilidad de acceso a procesos distribuidos. Resultaron entonces los servidores de aplicaciones que proporcionan un entorno de componentes (o servicios) en el servidor que gestiona la concurrencia, transacciones, balance de carga, seguridad, y gestión de recursos. Se podría ver gráficamente de la siguiente manera: Página 7 de 34

9 MT II. BEA TUXEDO 8.1 BEA Tuxedo es un producto de middleware que brinda el framework necesario para construir aplicaciones escalables, de n-capas, en ambientes heterogéneos y distribuidos. Estas aplicaciones distribuidas son independientes del hardware, sistema operativo, ambiente de red y base de datos. Un poco de historia... La última versión de BEA Tuxedo es la 8.1, lo cual indica un largo trayecto en la evolución de este software. En el año 1983, Tuxedo comenzó como proyecto en los Laboratorios Bell de la compañía AT&T. En 1989, Tuxedo fue transferido al Laboratorio de Sistemas UNIX de AT&T, y comenzó a ofrecerse como producto comercial. En el año 1993, Tuxedo fue transferido a Novell cuando esta empresa adquirió el Laboratorio de Sistemas UNIX. Finalmente, en 1996, BEA Systems comenzó un acuerdo exclusivo con Novell para distribuir y continuar el desarrollo de Tuxedo en diversas plataformas, como Windows y la mayoría de sistemas Unix. Características del sistema BEA Tuxedo brinda los siguientes servicios de middleware: Interface de programación ATMI ATMI significa Application-to-Transaction Monitor Interface, es la API principal del Tuxedo. Incluye funciones de manejo transaccional, envío/recepción de mensajes, manejo de buffers entre otros. Interface de programación CORBA Esta interface consiste de ORBs de C++ y Java que permite la comunicación entre objetos CORBA. Página 8 de 34

10 BEA Tuxedo incluye servicios de ATMI y objetos C++ CORBA necesarios para el manejo transaccional, seguridad, transporte de mensajes, administración del sistema, y soporte de base de datos para el procesamiento two-phase commit. Componentes ATMI BEA Tuxedo ATMI es un conjunto de tecnologías que permite desarrollar aplicaciones ATMI que utilicen e integren distintas plataformas, base de datos y sistemas operativos. Implementan el modelo de procesamiento de transacciones distribuidas (DTP) de X/Open brindando todas las características y ventajas de un sistema de procesamiento online de transacciones (OLTP). El modelo DTP asegura que un trabajo se completa de manera atómica, lo que significa que todas las bases de datos involucradas se actualizan de manera consistente si el trabajo es correcto, o vuelven a su estado original si el trabajo resulta fallido. Tuxedo ATMI está compuesto por los siguientes componentes: Infraestructura Tuxedo. Provee de servicios básicos para correr y administrar una aplicación ATMI. Interface de Programación ATMI BEA Tuxedo Workstation Permite clientes ATMI residir en workstations y comunicarse a través de una red con el servidor de aplicaciones ATMI. Infraestructura de BEA Tuxedo La Infraestructura de Tuxedo provee de servicios básicos para correr y administrar las aplicaciones. Es común al entorno ATMI como al entorno CORBA. Los componentes fundamentales de la infraestructura Tuxedo son los siguientes: Paradigmas de mensajería: existen distintas modalidades de transferencia de mensajes entre cliente y servidor. Tuxedo incluye los siguientes paradigmas: request/response, conversacional, encolado, publish-and-subscribe y notificación no solicitada. MIB Management Information Base: en ésta base se almacena toda la información de Tuxedo y sus aplicaciones. Servicios de procesamiento de aplicaciones. Servicios administrativos Tuxedo implementa el protocolo XA para comunicarse con administradores de recursos (Resource Manager). En la siguiente figura se puede apreciar la infraestructura Tuxedo: Página 9 de 34

11 Interface de Programación ATMI La interface de programación ATMI está formada por un conjunto de funciones en C y COBOL, que permiten conectar clientes ATMI con el sistema Tuxedo. Algunas de las tareas más importantes que pueden realizarse con ATMI son: inicialización de clientes, mensajería, gestión de transacciones, despacho de servicios, etc. Algunos ejemplos de funciones son los siguientes (en lenguaje C): tpinit - permite a un cliente unirse a una aplicación. tpalloc permite crear un buffer de mensaje. tpbegin, tpcommit y tpabort para manejo transaccional. tpopen, tpclose abre o cierra un resource manager. Las aplicaciones ATMI envían y reciben datos en Typed Buffers. Estos buffers no se crean a partir de memoria del sistema operativo sino que son creados a partir del sistema Tuxedo, lo cual brinda ventajas ya que el sistema puede manejarlos de manera óptima durante las comunicaciones. Estos buffers contienen información sobre ellos mismos (metadata), lo cual permite al usuario desarrollador abstraerse de la representación de los datos en las distintas máquinas que forman parte de una aplicación Tuxedo, lográndose mantener una independencia de máquina. BEA Tuxedo Workstation Los componentes cliente de ATMI permiten a un cliente residir en un equipo remoto que no tenga una instalación completa del sistema. Las comunicaciones entre el cliente y el servidor de aplicaciones se realizan a través de la red. Algunas ventajas de tener estos componentes en el cliente son: Menos sobrecarga administrativa Mayor seguridad al mantener a los clientes por fuera de los servidores del sistema Tuxedo. Menor trabajo de CPU en los servidores Tuxedo. Los componentes involucrados en este proceso son los siguientes: Página 10 de 34

12 Workstation cliente (WC): un proceso instalado en la máquina que funciona como cliente ATMI. Workstation Listener (WSL): proceso que corre en un servidor Tuxedo, y acepta conexiones de los WC y asigna conexiones a los WSH, los cuales también corren en el servidor. El WSL maneja un pool de procesos WSH, los cuales activa según la demanda. Worsktation Handler (WSH): proceso que maneja las comunicaciones entre un WC y el servidor de aplicaciones. Pueden manejar múltiples clientes. Componentes CORBA Como alternativa a ATMI, Tuxedo brinda el modelo de programación CORBA como parte de su tecnología de procesamiento de transacciones. Combina el modelo ORB con funciones de procesamiento online de transacciones (OLTP) para crear un monitor transaccional de objetos (Object Transaction Monitor, OTM). Los componentes CORBA de Tuxedo utilizan los recursos existentes de la infraestructura Tuxedo con respecto al manejo de transacciones, seguridad, transporte de mensajes, administración del sistema y soporte para bases de datos que cumplan con XA. Los componentes centrales de Tuxedo CORBA son: ORB s Tuxedo IIOP Listener/Handler Objetos de ambiente y TP Framework Cliente ActiveX ORB s Tuxedo ORB, por Object Request Broker, es una librería que permite a clientes localizar y comunicarse con servidores independientemente de la ubicación del servidor y de las conexiones de red. Interface de Programación La interface de programación CORBA de Tuxedo consiste de un ORB C++ servidor, un ORB C++ cliente, un ORB Java cliente y un software cliente ActiveX del estilo ORB. Estos ORB s tienen soporte transaccional incorporado. EL ORB C++ en el servidor está directamente ligado a los procesos CORBA del servidor, mientras que los distintos ORB s cliente se comunican utilizando el protocolo de CORBA IIOP. Las aplicaciones CORBA de Tuxedo se desarrollan como un conjunto de objetos CORBA, y definiendo luego sus interfaces a través del lenguaje de definición de interfaces (IDL) de la OMG. La comunicación con el resto de los objetos se realiza a través de las ORB s. Tuxedo IIOP Listener/Handler El IIOP Listener/Handler permite a clientes CORBA que no residan en una máquina que tenga una instalación completa de Tuxedo, comunicarse con una aplicación CORBA en el servidor. Las ventajas que se obtienen son las mismas mencionadas cuando se habló del componente cliente (Workstation) de la interface ATMI. La arquitectura de comunicación consiste de los siguiente procesos: Cliente CORBA o ActiveX: proceso que corre en el equipo donde esté instalado cualquiera de los ORB s cliente. IIOP Listener (ISL): proceso que corre en un servidor Tuxedo, y acepta conexiones de los clientes CORBA y asigna conexiones a los ISH, los cuales también corren en el servidor. El ISL maneja un pool de procesos ISH, los cuales activa según la demanda. IIOP Handler (ISH): proceso que maneja las comunicaciones entre un cliente CORBA y el servidor de aplicaciones. Pueden manejar múltiples clientes. Página 11 de 34

13 Objetos de ambiente y TP Framework Tuxedo brinda una serie de objetos CORBA para ayudar a los clientes. Estos objetos facilitan la tarea de loguearse al ambiente CORBA, invocar objetos CORBA, y comenzar y terminar transacciones. Los objetos para aplicaciones cliente son los siguientes: Objeto Bootstrap: este objeto facilita la conexión de un cliente con el servidor de aplicaciones. También brinda referencias a objetos comunes que un cliente utilza. Objeto CORBA OTS TransactionCurrent: este objeto coordina todo lo referente a transacciones. Objeto SecurityCurrent: este objeto obtiene las credenciales de seguridad del cliente del servicio de seguridad, y registra estos certificados al ISH, el cual los utiliza para permitir o denegar permisos. El TP Framework es un modelo de programación que ayuda a los desarrolladores de aplicaciones con las complejidades de las interfaces CORBA. Este modelo provee de una serie de funciones que son requeridas en una aplicación CORBA estándar. El desarrollador es responsable únicamente de escribir la lógica de negocios de la aplicación y de sobrescribir acciones que provee el TP Framework. Cliente ActiveX El componente cliente ActiveX permite a programas ActiveX interactuar con objetos CORBA de BEA como si fueran componentes ActiveX. BEA incluye herramientas que facilitan el trabajo con estos componentes, pero a partir de la versión 8.1 de Tuxedo este cliente y las herramientas son consideradas obsoletas. Escalabilidad y Performance Tuxedo reacciona de manera dinámica a cambios en la carga de trabajo, ya sea inicializando o terminando servidores (ATMI), o activando y desactivando objetos (CORBA). Realiza un balance de acuerdo a la carga de manera que los servicios u objetos disponibles sean efectivamente utilizados. Tuxedo brinda soporte tanto para un solo cliente y un solo servidor, como para varios miles de cliente y cientos de servidores, sin realizar ningún cambio en el código de la aplicación. De esta manera la performance no se ve alterada por un incremento en la cantidad de clientes o servidores. Soporte de plataformas, lenguajes y modelos de programación El sistema Tuxedo ha sido portado a diferentes plataformas tanto para el cliente como para el servidor. Los sistemas cliente soportados son: Windows 2000, XP y 98, y la mayoría de los sistemas workstations de Unix. Con respecto a los servidores, las plataformas soportadas son las siguientes: Windows 2000 Server, Compaq Tru64 Unix, HP-UX, IBM AIX, Red Hat Linux y Solaris. El sistema soporta dos modelos de programación y cinco lenguajes. Los modelos soportados son ATMI y CORBA, de los cuales se ha hablado previamente. Los lenguajes de programación soportados son los siguientes: Página 12 de 34

14 C y COBOL, soportados para aplicaciones ATMI cliente y servidor. C++, soportado para aplicaciones ATMI cliente y aplicaciones CORBA C++ tanto cliente como servidor. Java, soportado para aplicaciones cliente CORBA y Jolt (*). Visual Basic, soportado para aplicaciones ATMI cliente y aplicaciones CORBA cliente que incluyan ActiveX. (*) BEA Jolt es una librería de clases Java (accesible vía una API) que permite conectividad con servicios ATMI vía internet. Esto puede realizarse tanto desarrollando clientes Java remotos (applets o aplicaciones) como instalando representantes Jolt en servidores web para que clientes web puedan acceder a los servicios ATMI. Seguridad BEA Tuxedo incluye autenticación, autorización y encriptación para asegurar la privacidad de los datos en la comunicación a través de una red. Se soportan dos niveles de encriptación: Encriptación a nivel de red, utilizando el protocolo propietario LLE (Link-Level Encryption). Encriptación a nivel de aplicación, utilizando el protocolo SSL y encriptación basada en clave pública. El protocolo LLE es utilizado en la comunicación entre clientes ATMI y Jolt, y el servidor Tuxedo, y entre servidores Tuxedo. El protocolo SSL es utilizado básicamente en la comunicación entre clientes CORBA y ActiveX y el servidor Tuxedo. Herramientas de administración Existen varias opciones para administrar un sistema Tuxedo. Estas son: consola de administración, línea de comandos y MIB API. La consola de administración es una interfaz gráfica que permite realizar la mayoría de las tareas de administración y configuración de las aplicaciones. Está implementada como un conjunto de applets de Java, lo cual permite ejecutarla desde cualquier plataforma que soporte un browser que pueda correr applets de Java. Esta herramienta tiene como limitación que no ha sido actualizada para soportar nuevas características que han sido introducidas luego de la versión 7.1. La línea de comandos provee la mayoría de la funcionalidad necesaria para la modificación dinámica de las aplicaciones y de la configuración de un dominio BEA Tuxedo. La MIB API es una interfaz de programación que permite acceder y manejar la información de la MIB (Management Information Base, elemento central donde se maneja toda la información de configuración del sistema Tuxedo). Esta interfaz brinda un control total de la configuración de las aplicaciones, como también control en situaciones de fallas. A través de la API de MIB es la única forma de manejar cualquiera de las posibles fallas que puedan ocurrir. Página 13 de 34

15 BEA Tuxedo brinda un agente SNMP (por Simple Network Management Protocol) que permite a sistema de administración compatibles con SNMP administrar un sistema Tuxedo utilizando este protocolo. Además de realizar tareas de administración, estas herramientas son utilizadas para aislar errores y realizar tareas de recuperación cuando ocurren fallas en una aplicación. BEA Tuxedo puede recuperarse automáticamente de varios tipos de fallos, sin embargo los fallos más serios requieren la intervención de una administrador para determinar la falla. Estándares soportados BEA Tuxedo cumple con los estándares de X/Open del Open Group. Incluye soporte para el estándar XA para el procesamiento two-phase commit, la API ATMI, y el estándar para la internacionalización del lenguaje XPG (X/Open Portability Guide). Como se mencionó anteriormente implementa el modelo DTP. También soporta la especificación CORBA para el desarrollo de aplicaciones distribuidas. Otros estándares soportados son: LDAP protocolo para el acceso a directorios de información. Certificados digitales X.509. Public-Key Cryptography Standard 7 (PKCS-7) uno de los estándares de clave pública desarrollado por RSA. Acceso web a los servicios de aplicación de BEA Tuxedo Por acceso web entendemos tener disponibles servicios de aplicación a clientes web a través de un servidor de aplicaciones web. El procedimiento general es el siguiente: en el servidor de aplicaciones web se encuentra una aplicación la cual se comunica con los clientes a través del protocolo HTTP. Por otro lado, utilizando un gateway Tuxedo, la aplicación en el servidor de aplicaciones web puede acceder a los servicios ATMI o CORBA del servidor Tuxedo. Existen tres mecanismos para este acceso: A través del Workstation Client: este caso el servidor de aplicaciones C/C++ utiliza un Workstation Client instalado en el servidor para comunicarse con servicios ATMI del servidor Tuxedo. A través de BEA Jolt: este mecanismo ofrece dos posibles servidores, cualquier servidor de aplicaciones Java o Microsoft Internet Information Server. En el primer caso, la aplicación es un HTTP servlet que permite conectarse con Tuxedo para acceder a servicios ATMI, mientras que en el segundo caso existe una ASP de Jolt que permite conectarse con Tuxedo para acceder servicios ATMI, de manera que los clientes Web utilizan estos servicios a través de la ASP. En ambos casos es necesarios instalar paquetes de la API Jolt en el servidor. Página 14 de 34

16 Utilizando el servidor de aplicaciones de BEA WebLogic: en este caso la aplicación residente en el servidor de WebLogic puede acceder tanto a servicios ATMI como CORBA a través de gateways especiales para cada caso. Acceso a los servicios de aplicación de Tuxedo a través de Web Services En la actualidad se está trabajando para exponer servicios ATMI y CORBA de Tuxedo como Web Services utilizando el servidor de aplicaciones WebLogic. El mecanismo de comunicación sería de la siguiente manera: cualquier aplicación cliente, Java o no, accede a los servicios de Tuxedo expuestos como Web Services construyendo un mensaje SOAP y enviándolo vía HTTP al servidor WebLogic. Este llama al servicio Tuxedo a través del WebLogic Tuxedo Connector (WTC), empaqueta la respuesta en un mensaje SOAP y la envía vía HTTP al cliente que realizó el pedido. En la figura se aprecian los componentes principales de la propuesta de BEA Para lograr esta funcionalidad se deben brindar las siguientes características: Proveer del ambiente de web services y componentes Java para la creación de interfaces de web services para los servicios de Tuxedo Generar los WSDL que describa las interfaces de los componentes Java. Publicitar los WSDL a través de registros UDDI. Automáticamente mapear y rutear pedidos SOAP de clientes a los apropiados servicios Tuxedo a través del gateway WTC. Rutear respuestas de servicios Tuxedo a los clientes correspondientes. III. MTS (Microsoft Transaction Server) El MTS es un sistema de proceso transaccional basado en componentes para el desarrollo de aplicaciones sobre Internet e Intranet, escalables, robustas y de alta performance. Utilizando el MTS el desarrollo de aplicaciones es más simple puesto que desliga al programador de aspectos que antes debían ser contemplados y programados por el. El objetivo del MTS es facilitar el desarrollo y gestión de componentes que llevan a cabo trabajos en el ámbito de transacciones. MTS es parte de Windows DNA, un framework para construcción de componentes basado en la arquitectura de tres capas. Es una estrategia para desarrollar aplicaciones usando tecnologías Microsoft. Las principales tecnologías y productos provistos para este modelo son COM, MTS, UDA, ASP, DHTML, MSMQ, y COMTI [MS1] [GRO1]. Página 15 de 34

17 Un poco de historia... MTS aparece en la Conferencia de desarrolladores en San Diego a principios del año 1997 como un servidor transaccional multi-threaded basado en RPC. Es una extensión al COM que facilita la creación y el uso de componentes de software en cualquier lenguaje [HPD1]. Propósito del MTS MTS fue creado para atacar dos problemas principales que existían en la arquitectura de tres capas: 1. La inhabilidad de los objetos para escalar. 2. La inhabilidad de los objetos para unirse a otros objetas en transacciones atómicas. MTS extiende el soporte transaccional a la capa de Información, y permite enlistar varios componentes en únicas transacciones. Para proveer escalabilidad en los componentes provee servicios para el manejo de múltiples usuarios, escalamiento de recursos, y otros factores relativos. MTS actúa como un ORB (Object request broker), o sea un intermediario entre la aplicación y las bases de datos, administrando la creación y la asignación de objetos e hilos de ejecución. MTS provee transacciones anidadas [SRA1] [MS3]. Características Las aplicaciones están compuestas por colecciones de componentes ActiveX que proveen la lógica de las reglas de negocio. Instalando estos componentes en el ambiente MTS hace posible que automáticamente se permite la concurrencia de varios clientes en un modo transaccional de ser necesario [DOC1]. MTS puede manejar transacciones entre objetos bajo MS Windows y otros entornos como UNIX. Los componentes que se instalan en MTS son componentes COM, compilados como DLL s. MTS es compatible con bases de datos relacionales como MS SQL, Oracle, y Sysbase. Cuando un componente está controlado durante su ejecución por MTS todas sus operaciones son susceptibles de enmarcarse en transacciones. MTS se ocupa de resolver todos los problemas de concurrencia, en memoria, en lógica de programa y en gestión de recursos [MS2] [TPC1]. El modelo de operaciones en MTS El objetivo es crear una aplicación que se ubique en un servidor (o varios colaborando entre ellos) y que sea accedida por clientes que van a consultar, actualizar o gestionar los datos que conforman el estado de una aplicación. Las operaciones sobre el estado de la aplicación, la lógica de negocio, van a implementarse con componentes COM cuyos aspectos transaccionales van a ser controlados y gestionados por el MTS [ISD1]. Arquitectura de MTS Componentes ActiveX, implementan la lógica de la aplicación. Página 16 de 34

18 El Transaction Server Executive, que provee los servicios en tiempo de ejecución utilizados por los componentes de la aplicación. Procesos de servidor, que proveen el ambiente de procesos para los componentes de la aplicación. Dispensadores de Recursos, que manejan la información utilizada por los componentes en los procesos. El Microsoft Distributed Transaction Coordinator (DTC), que permite transacciones coordinadas entre múltiples administradores de recursos, dispensadores de recursos, y componente de aplicación. Los componentes MTS Cada uno de los componentes de la aplicación, que en principio van a ser un componente COM cualquiera, se convierten en un componente MTS. Un componente MTS es un componente COM constituido como una DLL, y que se ejecuta en el entorno de Transaction Server. Del mismo modo que una instancia de un componente COM es un objeto COM, toda instancia de un componente MTS es un objeto MTS. Cuando creamos un ejemplar de un componente MTS el servidor crea automáticamente un objeto asociado de contexto (Context Object) que contiene información sobre quién originó la creación del objeto y cómo se está ejecutando, principalmente desde el punto de vista de las transacciones en las que el objeto está inmerso. Cada uno de estos objetos será accedido por los clientes, y él a su vez realizará solicitudes a otros componentes o a los recursos (esencialmente datos) que desee manejar. Actividad Transaccional MTS actúa como un TP-Monitor (monitor de proceso transaccional). MTS crea, ejecuta, y administra las aplicaciones de proceso transaccional, y se asegura de que todos los requerimientos para esa transacción se cumplan. El TP-Monitor del MTS esta construido sobre el estándar de X/Open DTP model. En el ambiente MTS, las aplicaciones usan el Microsoft Distributed Transaction Coordinator (DTC transaction manager) para coordinar las transacciones. El MS DTC es un servicio de Windows que es responsable de asegurarse que todas las entidades que forman parte de la transacción sean notificadas acerca del resultado de la misma. El mismo coordina las transacciones que abarcan múltiples manejadores de recursos. Cada servidor en un sistema distribuido tiene su administrador de transacciones, MS DTC utiliza el protocolo transaccional OLE Página 17 de 34

19 (en lugar del protocolo X/Open) para comunicarse con otros administradores de transacciones. El administrador de transacciones es el encargado de que las características ACID se cumplan. DTC implementa el protocolo two-phase commit, y soporta administradores de recursos que implementen transacciones OLE, X/Open, protocolos XA, y LU 6.2 Sync Level 2 [GSR1]. Dispensadores de Recursos Los dispensadores de recursos son otra parte del MTS. Estos dispensadores manejan, entre otras cosas, las conexiones a las bases de datos. Tienen dos interfaces, API s para las aplicaciones, y otra para comunicarse con el administrador de dispensador de recursos del MTS (DispMan). DispMan provee un pooling de recursos para los dispensadores y se asegura que los recursos provistos por el dispensador de recursos sean enlistados de manera correcta en las transacciones. Los recursos de los que hablamos son básicamente los datos, que se ubican en uno o varios servidores, como por ejemplo SQL Server. Cada uno de estos datos, que conforman el estado de nuestra aplicación, es controlado por un gestor de recursos (Resource Manager). SQL Server es un ejemplo de gestor de recursos que puede atender a transacciones distribuidas. El MTS provee dos dispensadores de recursos que son visibles para los desarrolladores. Uno de ellos es el administrador para ODBC, que es un dispensador de recursos para conexiones de base de datos ODBC. El otro es el Shared Property Manager, que es usado para datos compartidos. Los gestores de recursos son consultados y tomados bajo su ámbito de acción por MTS para asegurar que las transacciones que operan sobre los citados datos son llevadas a cabo correctamente. Los dispensadores de recursos (Resource Dispenser) son administrados por el Administrador de Recursos (Manager Dispenser), que mantiene la información para cada tipo de recurso. Los componentes MTS no acceden directamente a los gestores de recursos, sino que lo hacen a través de un módulo intermedio (el dispensador de recursos Resource Dispenser) que permite la independencia de la llamada a los gestores de recursos, con lo que diferentes componentes podrán llamar a diferentes gestores de recursos sin variar significativamente la tarea de programación. Por ejemplo, si SQL Server es un gestor de recursos, ODBC es un dispensador para él. Activación Just-in-Time Cuando se trabaja con componentes estándares, una aplicación cliente que crea una instancia de un componente la va a mantener abierta durante todo el proceso de trabajo con el componente. Esto acarrea que los recursos que utiliza el componente van a mantenerse ocupados inclusive durante el tiempo en el que el mismo este ocioso. Cuando MTS administra los objetos, una llamada por parte del cliente para crear una instancia de un componente no necesariamente asigna los recursos de forma inmediata. MTS va a crear una instancia de un componente solo cuando sea necesario, dando privilegio a aquellos componentes que están actualmente atendiendo a otras solicitudes de otros clientes. Esto implica que los componentes son cargados y descargados muchas veces durante el tiempo en el cual la aplicación cliente presuntamente tenga el componente abierto. Esto sirve para engañar a clientes como el IIS que le hace creer que Página 18 de 34

20 el objeto que el necesitaba fue creado, cuando en realidad la creación se efectúa cuando un método es invocado. MTS agrega dos fases al paradigma tradicional de programación que son la activación y desactivación. La secuencia de eventos para una clase de VB por ejemplo, que haya sido creada bajo el contexto del MTS sería: creación, activación, desactivación, y destrucción. Cuando un cliente crea un objeto, MTS crea el objeto pero no lo activa hasta que el cliente hace un llamado al primer método del objeto [MS4]. Pooling de Recursos Los componentes utilizan más recursos que memoria. Para que un componente haga su trabajo va a precisar de recursos tales como hilos de ejecución, o conexiones a bases de datos. Estos recursos pueden ser muy costosos en términos de recursos del sistema. Por ejemplo, cuando una aplicación cliente o componente intenta obtener datos de un servidor de base de datos como el MS SQL Server, debe realizar esto a través de una conexión a una base de datos. Puesto que las conexiones a las bases de datos insumen mucha memoria en el servidor de SQL, el número de conexiones esta restringido por el administrador del Server. Algo que se suele hacer para que la aplicación se mantenga más ágil, es realizar las conexiones a las bases de datos antes y liberarlas cuando todo el proceso haya culminado. Esto implica que el estado de la conexión este ocioso, desperdiciando capacidad que puede ser utilizada por otros usuarios. MTS administra todas las conexiones a la base de datos, así como otros recursos, permitiendo el pooling de conexiones para que sean usadas de forma más eficiente. Seguridad MTS define un modelo de seguridad llamado seguridad de paquetes, que permite asignar una identidad de usuario a un paquete. Un paquete esta compuesto por componentes. Esto hace que los paquetes se comporten como usuarios virtuales. Estos paquetes pueden ser considerados como grupos de usuarios. Las identidades de los paquetes les dan privilegios para realizar acciones sobre los servidores de base de datos. Además, a cada grupo de usuarios definido en el servidor de dominio, se les definen accesos a esos paquetes. La seguridad del MTS se administra en la capa de paquetes. Esto hace más fácil la tarea del administrador puesto que la seguridad a nivel de los recursos (bases de datos), se administra otorgando accesos a los paquetes [BSE1 [GSR1]. Lenguajes y modelos de programación Los componentes de aplicación del MTS son ActiveX in-process servers (DLLs). Estos componentes se pueden crear e implementar con Microsoft Visual Basic, Visual C++, Visual J++, o cualquier herramienta de desarrollo ActiveX o compatible que se base en el modelo COM. Component Object Model (COM) El desarrollo de aplicaciones se está orientando a un escenario, Internet, en el que los programas creados deben estar preparados para poder ejecutarse en máquinas desconocidas, con requerimientos y sistemas operativos también desconocidos. En este Página 19 de 34

2.1 Compuertas para Bases de Datos

2.1 Compuertas para Bases de Datos 1 Colección de Tesis Digitales Universidad de las Américas Puebla Romero Martínez, Modesto Uno de los aspectos mas importantes en un sistema multibase de datos es la forma en como llevar a cabo la comunicación

Más detalles

Tecnología de objetos distribuidos y arquitectura de componentes. Índice. Bibliografía. Introducción. Tema V

Tecnología de objetos distribuidos y arquitectura de componentes. Índice. Bibliografía. Introducción. Tema V Bibliografía Tema V Tecnología de objetos distribuidos y arquitectura de componentes. Szyperski, C. 1998. Component Software. Addison-Wesley. Ruiz Cortés, 1998. A. CORBA: Una visión general. http://www.lsi.us.es/~aruiz

Más detalles

Windows DNA. Mario A. Valdez-Ramírez, Interactive Bureau México. Editor de MSDN Latinoamérica y MSDN Regional Director para Latinoamérica.

Windows DNA. Mario A. Valdez-Ramírez, Interactive Bureau México. Editor de MSDN Latinoamérica y MSDN Regional Director para Latinoamérica. Windows DNA Mario A. Valdez-Ramírez, Interactive Bureau México. Editor de MSDN Latinoamérica y MSDN Regional Director para Latinoamérica. Agenda. Evolución de las aplicaciones. Tecnologías y herramientas

Más detalles

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA 3.1. Características La tendencia hacia el futuro es el de lograr la integración total de componentes realizados por terceras partes, para lo cual es necesario

Más detalles

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes.

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes. SISTEMAS DISTRIBUIDOS DE REDES 2.- MODELOS ORIENTADOS A OBJETOS DISTRIBUIDOS 2.1. Tecnologías de sistemas distribuidos Para la implementación de sistemas distribuidos se requiere de tener bien identificados

Más detalles

ORACLE TUXEDO HOJA DE DATOS DE ORACLE

ORACLE TUXEDO HOJA DE DATOS DE ORACLE HOJA DE DATOS DE ORACLE CARACTERÍSTICAS Y BENEFICIOS CLAVE CARACTERÍSTICAS Procesamiento de transacciones distribuidas Infraestructura de integración extensible Seguridad avanzada Alta disponibilidad Protocolo

Más detalles

C/S:CLIENTE/SERVIDOR

C/S:CLIENTE/SERVIDOR C/S:CLIENTE/SERVIDOR ALEJANDRO DOMÍNGUEZ Curso impartido en la Universidad Autónoma de Ciudad del Carmen, Campeche 15/10/1998 PRINCIPIA INFORMATICA 1 Temario La computación C/S Qué es C/S? Tipos de C/S

Más detalles

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el Capitulo II. Análisis de herramientas y tecnologías de desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el lenguaje de Modelo de Objetos llamado UML (Unified

Más detalles

INTRODUCCION A LOS SGBD

INTRODUCCION A LOS SGBD Parte Primera: INTRODUCCION A LOS SGBD Sistemas de Gestión de Bases de Datos Tabla Tabla Type Fila Tabla Type Fila Tabla text Fila Type Fila Fila text Type Fila Tabla Tabla Fila text Fila text Fila Fila

Más detalles

Capítulo 1. Componentes de CORBA.

Capítulo 1. Componentes de CORBA. Capítulo 1. Componentes de CORBA. La OMA (Object Management Architecture) define en alto nivel de abstracción las reglas necesarias para la distribución de la computación orientada a objetos (OO) en entornos

Más detalles

Unidad I Fundamentos de Sistemas Distribuidos. M.C. Juan Carlos Olivares Rojas

Unidad I Fundamentos de Sistemas Distribuidos. M.C. Juan Carlos Olivares Rojas Unidad I Fundamentos de Sistemas Distribuidos M.C. Juan Carlos Olivares Rojas Temario 1.1. Características de un sistema distribuido 1.2. Objetivos de los sistemas distribuidos 1.3. Ventajas y desventajas

Más detalles

JavaEE. www.javasoft.com

JavaEE. www.javasoft.com JavaEE Java Enterprise Edition www.javasoft.com Por qué Java en el servidor? Ventajas Independencia de la plataforma portabilidad Gran conjunto de APIs Reusabilidad y modularidad Seguro en la ejecución

Más detalles

Contenidos. Sistemas operativos Tema 3: Estructura del sistema operativo. Componentes típicos de un SO. Gestión de procesos.

Contenidos. Sistemas operativos Tema 3: Estructura del sistema operativo. Componentes típicos de un SO. Gestión de procesos. Contenidos Sistemas operativos Tema 3: Estructura del sistema operativo Componentes típicos del SO Servicios del SO Llamadas al sistema Programas del sistema El núcleo o kernel Modelos de diseño del SO

Más detalles

servicios. El API es definido al nivel de código fuente y proporciona el nivel de

servicios. El API es definido al nivel de código fuente y proporciona el nivel de GLOSARIO API Application Program -ming- Interface Es la interfaz por la cual una aplicación accede al sistema operativo u a otros servicios. El API es definido al nivel de código fuente y proporciona el

Más detalles

Sistemas Distribuidos Sincronización, Concurrencia y Transacciones

Sistemas Distribuidos Sincronización, Concurrencia y Transacciones Sistemas Distribuidos Sincronización, Concurrencia y Transacciones Transacciones Distribuidas Sistemas Distribuidos 2 Transacciones Distribuidas Transacciones que afectan de forma atómica a objetos residentes

Más detalles

Tema 3. 3.3 Tecnologías de Desarrollo

Tema 3. 3.3 Tecnologías de Desarrollo Tema 3 3.3 Tecnologías de Desarrollo HTML pronto pasa a ser insuficiente para todas las posibilidades de la Red No se puede interactuar con el servidor Aparecen los primeros scripts para propocionar dichar

Más detalles

1.264 Tema 16. Middleware heredado

1.264 Tema 16. Middleware heredado 1.264 Tema 16 Middleware heredado Qué es el middleware heredado? Cliente (interf. de usuario, aplic. local) Cliente (interf. de usuario, aplic. local) Cómo conectamos clientes y servidores? Middleware

Más detalles

Arquitectura software EN-HORA

Arquitectura software EN-HORA Arquitectura de en:hora Arquitectura software EN-HORA en:hora es un software de control de acceso y presencia con una arquitectura modular. El software se implementa mediante un conjunto de componentes

Más detalles

Servidores de aplicaciones

Servidores de aplicaciones Departamento de Lenguajes y Sistemas Informáticos Productos enlatados Curso 2001-2002 Servidores de aplicaciones iplanet Application Server 4.0 BEA Systems WebLogic Server 4.5 IBM WebSphere 3.0 AE IBM

Más detalles

GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo.

GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo. GLOSARIO Actor: Un actor es un usuario del sistema. Esto incluye usuarios humanos y otros sistemas computacionales. Un actor usa un Caso de Uso para ejecutar una porción de trabajo de valor para el negocio.

Más detalles

Tema 2: EL MODELO CLIENTE/SERVIDOR

Tema 2: EL MODELO CLIENTE/SERVIDOR Tema 2: EL MODELO CLIENTE/SERVIDOR E. U. Informática en Segovia Departamento de Informática Universidad de Valladolid Definición de sistemas cliente/servidor (1) Clientes y servidores: entidades lógicas

Más detalles

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms Patrones Patrones Es una solución reusable de problemas comunes. Los patrones solucionan problemas que existen en muchos niveles de abstracción. desde el análisis hasta el diseño y desde la arquitectura

Más detalles

Arquitectura cliente/servidor

Arquitectura cliente/servidor Departamento de Lenguajes y Sistemas Informáticos Arquitectura cliente/servidor Programación en Internet Curso 2007-2008 Índice Introducción Tipos de servidores Ventajas Desventajas Arquitectura de una

Más detalles

JAVA EE 5. Arquitectura, conceptos y ejemplos.

JAVA EE 5. Arquitectura, conceptos y ejemplos. JAVA EE 5. Arquitectura, conceptos y ejemplos. INTRODUCCIÓN. MODELO DE LA APLICACIÓN JEE5. El modelo de aplicación Java EE define una arquitectura para implementar servicios como lo hacen las aplicaciones

Más detalles

4 ARQUITECTURA DE COMUNICACIONES

4 ARQUITECTURA DE COMUNICACIONES 4 ARQUITECTURA DE COMUNICACIONES Las redes de computadoras son típicamente heterogéneas. Por ejemplo, la red interna de una universidad puede estar hecha de múltiples plataformas. Puede haber un servidor

Más detalles

Justificación Cliente/Servidor. Arquitectura Cliente/Servidor. Nuevas Tareas del Dpto. de Sistemas de Información

Justificación Cliente/Servidor. Arquitectura Cliente/Servidor. Nuevas Tareas del Dpto. de Sistemas de Información Tema IV Arquitectura liente/servidor Justificación liente/servidor AVANE TENOLÓGIO EXIGENIAS DE LA EMPRESA ENTORNO GENERAL ANTES Rigidez. No redistribución. Vinculación al sistema. Solapamiento, duplicación

Más detalles

Unidad 1: Conceptos generales de Sistemas Operativos.

Unidad 1: Conceptos generales de Sistemas Operativos. Unidad 1: Conceptos generales de Sistemas Operativos. Tema 3: Estructura del sistema operativo. 3.1 Componentes del sistema. 3.2 Servicios del sistema operativo. 3.3 Llamadas al sistema. 3.4 Programas

Más detalles

Protección de Software Protección de información Protección para Internet

Protección de Software Protección de información Protección para Internet Protección de Software Protección de información Protección para Internet Con el Sistema Integral de Seguridad HARDkey obtiene una poderosa herramienta de protección de software, cifrado de archivos de

Más detalles

MIDDLEWARE: Arquitectura para Aplicaciones Distribuidas Dr. Víctor J. Sosa Sosa vjsosa@tamps.cinvestav.mx

MIDDLEWARE: Arquitectura para Aplicaciones Distribuidas Dr. Víctor J. Sosa Sosa vjsosa@tamps.cinvestav.mx MIDDLEWARE: Arquitectura para Aplicaciones Distribuidas Dr. Víctor J. Sosa Sosa vjsosa@tamps.cinvestav.mx Contenido Middleware: Introducción Definición Genealogía Aplicaciones actuales: Servicios Web Computación

Más detalles

Glosario Acoplamiento. API. Archivos de recursos. ASCII. Balanceo de carga. Bases de datos federadas. BBDD. Clientes. Constructores.

Glosario Acoplamiento. API. Archivos de recursos. ASCII. Balanceo de carga. Bases de datos federadas. BBDD. Clientes. Constructores. GLOSARIO Glosario Acoplamiento. Posibilidad que tiene un servicio de funcionar de forma autónoma. Se dice que un servicio o aplicación es bajamente acoplado cuando puede funcionar de forma independiente

Más detalles

6.1 Introducción a los sistemas EAI

6.1 Introducción a los sistemas EAI 6.1 Introducción a los sistemas EAI Integración de Aplicaciones (1) El problema de la integración de aplicaciones consiste en hacer colaborar entre sí a aplicaciones distribuidas, heterogéneas y posiblemente

Más detalles

Componentes de Integración entre Plataformas Información Detallada

Componentes de Integración entre Plataformas Información Detallada Componentes de Integración entre Plataformas Información Detallada Active Directory Integration Integración con el Directorio Activo Active Directory es el servicio de directorio para Windows 2000 Server.

Más detalles

Aplicaciones Distribuidas. Informática III

Aplicaciones Distribuidas. Informática III Aplicaciones Distribuidas Informática III Temario Elementos arquitecturales Arquitecturas tradicionales Arquitecturas Cliente/Servidor Arquitecturas distribuidas Elementos Arquitecturales Componentes de

Más detalles

Tema 4: Diseño de flujos interaplicación

Tema 4: Diseño de flujos interaplicación Tema 4: Diseño de flujos interaplicación 4.1 Introducción a los Sistemas EAI Modelo de referencia (1) INTEGRACIÓN B2B INTEGRACIÓN DE APLICACIONES Y PROCESOS INTEGRACIÓN DE DATOS INTEGRACIÓN DE PLATAFORMA

Más detalles

Capítulo 5. Sistemas operativos. Autor: Santiago Felici Fundamentos de Telemática (Ingeniería Telemática)

Capítulo 5. Sistemas operativos. Autor: Santiago Felici Fundamentos de Telemática (Ingeniería Telemática) Capítulo 5 Sistemas operativos Autor: Santiago Felici Fundamentos de Telemática (Ingeniería Telemática) 1 Sistemas operativos Definición de Sistema Operativo Partes de un Sistema Operativo Servicios proporcionados:

Más detalles

Sistemas de Información Introducción a los Sistemas de Información: El Modelo Cliente/Servidor

Sistemas de Información Introducción a los Sistemas de Información: El Modelo Cliente/Servidor Sistemas de Información Introducción a los Sistemas de Información: El Modelo Cliente/Servidor Agradecimientos: por su contribución a la realización de estas transparencias: Jesus Villamor Lugo y Simon

Más detalles

Ombú / Wbs (Web based Systems)

Ombú / Wbs (Web based Systems) Ombú / Wbs (Web based Systems) Tecnología de Desarrollo Empresa Argentina Organización y Gestión SRL San Jose 83 Piso 8 (C1076AAA) Buenos Aires Argentina Tel.: (5411) 4383-4600 email: www.oyg.com.ar 1

Más detalles

Familia de Windows Server 2003

Familia de Windows Server 2003 Familia de Windows Server 2003 Windows Server 2003 está disponible en cuatro ediciones. Cada edición se ha desarrollado para una función de servidor específica, como se describe en la tabla siguiente:

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

CARACTERISTICAS BASICAS DE LOS SMBD ORACLE

CARACTERISTICAS BASICAS DE LOS SMBD ORACLE Qué es una base de datos? Una base de datos es una herramienta para recopilar y organizar información. En las bases de datos, se puede almacenar información sobre personas, productos, pedidos, o cualquier

Más detalles

AcuServer Servidor de Archivos Remoto de Alto Rendimiento

AcuServer Servidor de Archivos Remoto de Alto Rendimiento AcuServer Servidor de Archivos Remoto de Alto Rendimiento RESUMEN EJECUTIVO AcuServer es una tecnología de servidor de datos remoto que ofrece un seguro e inmediato acceso a datos indexados, relativos

Más detalles

INTEROPERABILIDAD ENTRE LOS MARCOS DE GESTION SNMP Y CORBA (GATEWAY)

INTEROPERABILIDAD ENTRE LOS MARCOS DE GESTION SNMP Y CORBA (GATEWAY) UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO DECANATO DE CIENCIA Y TECNOLOGIA MAESTRIA CIENCIA DE LA COMPUTACION MENCION REDES DE COMPUTADORAS INTEROPERABILIDAD ENTRE LOS MARCOS DE GESTION SNMP Y CORBA

Más detalles

VISIÓN PRÁCTICA SOA PREPARATIC

VISIÓN PRÁCTICA SOA PREPARATIC VISIÓN PRÁCTICA SOA PREPARATIC VISIÓN PRÁCTICA SOA PROPÓSITO DE SOA Por qué? Para qué? EVOLUCIÓN VISIÓN PRÁCTICA SOA TÉRMINOS SOA UDDI WSDL XML Gobierno SOA SOAP Orquestación BAM ESB BPEL VISIÓN PRÁCTICA

Más detalles

REPORTE OFICIAL OCTUBRE DE 2014. CA Unified Infrastructure Management para servidores

REPORTE OFICIAL OCTUBRE DE 2014. CA Unified Infrastructure Management para servidores REPORTE OFICIAL OCTUBRE DE 2014 CA Unified Infrastructure Management para servidores 2 Reporte oficial: CA Unified Infrastructure Management para servidores Tabla de contenidos Descripción general de la

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

Informática y Programación Escuela de Ingenierías Industriales y Civiles Grado en Ingeniería en Ingeniería Química Curso 2010/2011

Informática y Programación Escuela de Ingenierías Industriales y Civiles Grado en Ingeniería en Ingeniería Química Curso 2010/2011 Módulo 1. Fundamentos de Computadores Informática y Programación Escuela de Ingenierías Industriales y Civiles Grado en Ingeniería en Ingeniería Química Curso 2010/2011 1 CONTENIDO Tema 1. Introducción

Más detalles

GRID GRIDS. ING. DE INFORMACION II Ing. Alfredo Ramos

GRID GRIDS. ING. DE INFORMACION II Ing. Alfredo Ramos GRID GRIDS ING. DE INFORMACION II Ing. Alfredo Ramos Uso de Bases de Datos en Grid Introducción Qué es una base de datos? Un conjunto de datos no redundantes, almacenados en un soporte informático, organizados

Más detalles

PROGRAMACION CONCURRENTE

PROGRAMACION CONCURRENTE PROGRAMACION CONCURRENTE VI.2: Introducción a los sistemas distribuido: Paradigma cliente/servidor Posibilidades que ofrece Java para la comunicación en red: Socket,RMI y URL. 1 Antiguos y nuevos tiempos

Más detalles

República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción

República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción Dato: Hecho o valor a partir del cual se puede inferir una conclusión.

Más detalles

Taller de Sistemas de Información 2

Taller de Sistemas de Información 2 Taller de Sistemas de Información 2 Clase 1 Aruitecturas y Middlewares Contenido Aruitectura de un sistema Evolución de las aruitecturas Monolíticas File sharing Cliente/Servidor En capas SOA Middlewares

Más detalles

La Arquitectura de las Máquinas Virtuales.

La Arquitectura de las Máquinas Virtuales. La Arquitectura de las Máquinas Virtuales. La virtualización se ha convertido en una importante herramienta en el diseño de sistemas de computación, las máquinas virtuales (VMs) son usadas en varias subdiciplinas,

Más detalles

Nombre: Francis Ariel Jiménez Zapata. Matricula: 2010-0077. Tema: Trabajando con Windows Server 2008 Módulo 6. Materia: Sistema Operativo II

Nombre: Francis Ariel Jiménez Zapata. Matricula: 2010-0077. Tema: Trabajando con Windows Server 2008 Módulo 6. Materia: Sistema Operativo II Nombre: Francis Ariel Jiménez Zapata Matricula: 2010-0077 Tema: Trabajando con Windows Server 2008 Módulo 6 Materia: Sistema Operativo II Facilitador: José Doñe Introducción En este trabajo estaremos tratando

Más detalles

Administración de sitios Web. Capítulo 8. Servidores Web: Internet Information Server

Administración de sitios Web. Capítulo 8. Servidores Web: Internet Information Server 1 of 9 4/15/2010 9:47 PM Anterior Administración de sitios Web Capítulo 8. Servidores Web: Internet Information Server Siguiente En este punto, nos centraremos en las tareas de administración del servidor

Más detalles

Instrucciones de instalación de IBM SPSS Modeler Server 17 para UNIX

Instrucciones de instalación de IBM SPSS Modeler Server 17 para UNIX Instrucciones de instalación de IBM SPSS Modeler Server 17 para UNIX Contenido Instrucciones para la instalación.... 1 Requisitos del sistema........... 1 Requisitos adicionales.......... 1 Instalación...............

Más detalles

Tema 1. Conceptos básicos

Tema 1. Conceptos básicos Conceptos básicos Sistema de Gestión de Bases de Datos, SGBD (DBMS, Database Management System): software diseñado específicamente para el mantenimiento y la explotación de grandes conjuntos de datos 1

Más detalles

BASES DE DATOS. 1.1 Funciones de un DBMS

BASES DE DATOS. 1.1 Funciones de un DBMS BASES DE DATOS Un DBMS, son programas denominados Sistemas Gestores de Base de Datos, abreviado SGBD, en inglés Data Base Management System (DBMS) que permiten almacenar y posteriormente acceder a los

Más detalles

CA Nimsoft Monitor para servidores

CA Nimsoft Monitor para servidores INFORME OFICIAL Septiembre de 2012 CA Nimsoft Monitor para servidores agility made possible CA Nimsoft for Server Monitoring tabla de contenido para servidores: 3 descripción general de la solución Monitoreo

Más detalles

DESPLIEGUE DE SENTINET

DESPLIEGUE DE SENTINET DESPLIEGUE DE SENTINET INTRODUCCIÓN Sentinet es una solución que proporciona gestión y gobierno de infraestructuras SOA desplegadas tanto on-premise, en la nube o en entornos híbridos. Sentinet está desarrollada

Más detalles

Conceptos fundamentales de un Middleware y razones de su importancia en el mundo de hoy

Conceptos fundamentales de un Middleware y razones de su importancia en el mundo de hoy Conceptos fundamentales de un Middleware y razones de su importancia en el mundo de hoy UNLAM, Universidad Nacional de La Matanza, Argentina Matías Leandro Varela 1. Resumen Hoy en día, un gran número

Más detalles

Generador GeneXus JAVA

Generador GeneXus JAVA Generador GeneXus JAVA Última actualización: 2009 Copyright Artech Consultores S. R. L. 1988-2009. Todos los derechos reservados. Este documento no puede ser reproducido en cualquier medio sin el consentimiento

Más detalles

Visión General de GXportal. Última actualización: 2009

Visión General de GXportal. Última actualización: 2009 Última actualización: 2009 Copyright Artech Consultores S. R. L. 1988-2009. Todos los derechos reservados. Este documento no puede ser reproducido en cualquier medio sin el consentimiento explícito de

Más detalles

Facultad de Sistemas e Informática

Facultad de Sistemas e Informática Escuela Politécnica del Ejército Sede Latacunga Facultad de Sistemas e Informática Galarza Maira Tapia Cevallos Paulina DESARROLLO DE APLICACIONES DISTRIBUIDAS UTILIZANDO PATRONES DE DISEÑO MODELO/VISTA

Más detalles

DESARROLLO DE COMPONENTES PARA LA INTEGRACIÓN DEL PORTAL CORPORATIVO DEL CITI CON LA BPMS BIZAGI

DESARROLLO DE COMPONENTES PARA LA INTEGRACIÓN DEL PORTAL CORPORATIVO DEL CITI CON LA BPMS BIZAGI DESARROLLO DE COMPONENTES PARA LA INTEGRACIÓN DEL PORTAL CORPORATIVO DEL CITI CON LA BPMS BIZAGI Informe de Práctica Profesional de 4to Año, Ingeniería Informática Autor: Manuel Alejandro Aguilar Díaz

Más detalles

TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software.

TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software. . TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software. Índice 1 INTRODUCCIÓN 2 2 CARACTERÍSTICAS 2 2.1 Características del cliente...2 2.2 Características

Más detalles

VISIÓN GENERAL HERRAMIENTAS COMERCIALES

VISIÓN GENERAL HERRAMIENTAS COMERCIALES VISIÓN GENERAL El servidor de MS SQL se ha convertido en un estándar en muchas partes de la América corporativa. Puede manejar volúmenes de datos grandes y se integra bien con otros productos de Microsoft.

Más detalles

Lógica de negocio. Dsfg dsfg sdfg. Sdfgdfg dfg Dsf gsdfg sdfg. Dfg. Sdfgdfg dfg. Dfg. Dsf gsdfg sdfg.

<HTML> <IMG src= logo.gif > </HTML> Lógica de negocio. Dsfg dsfg sdfg. Sdfgdfg dfg Dsf gsdfg sdfg. Dfg. Sdfgdfg dfg. Dfg. Dsf gsdfg sdfg. Sdfgdfg dfg Dsf gsdfg sdfg Dsfg dsfg sdfg Sdfgdfg dfg Dfg Dsf gsdfg sdfg Dsfg dsfg sdfg Sdfgdfg dfg Dfg Dfg Índice Programación web Copyright 2001-2003 Víctor ROBLES FORCADA vrobles@fi.upm.es http://laurel.datsi.fi.upm.es/~ssoo/dsw/

Más detalles

las necesitan. Estos índices deben de ser administrados y revisados por lo menos cada tres meses para que los índices no sean un problema.

las necesitan. Estos índices deben de ser administrados y revisados por lo menos cada tres meses para que los índices no sean un problema. CAPÍTULO IV RESUMEN En este capítulo daremos a conocer como es el funcionamiento de las diferentes bases de datos que la aplicación tiene en uso, esto es el caso de las bases de datos EASY y PL, estas

Más detalles

Veritas Cluster Server de Symantec

Veritas Cluster Server de Symantec Ofrece alta disponibilidad y recuperación después de un desastre para las aplicaciones críticas Hoja de datos: Alta disponibilidad Descripción general protege las aplicaciones más importantes contra el

Más detalles

Components & Connectors Viewtype. Estilos

Components & Connectors Viewtype. Estilos Components & Connectors Viewtype Estilos 1 Estilos Especializan el C&C viewtype introduciendo tipos de componente y conector a los cuales pertenecerán las instancias del modelo Especifican patrones de

Más detalles

Introducción a la plataforma.net

Introducción a la plataforma.net Introducción a la plataforma.net Autora: Mª del Pilar Pavón Rosano DNI: 52.923.715-W INTRODUCCIÓN Este artículo está dirigido a los profesores y profesoras del módulo Diseño y Realización de Servicios

Más detalles

DESARROLLO WEB EN ENTORNO SERVIDOR

DESARROLLO WEB EN ENTORNO SERVIDOR DESARROLLO WEB EN ENTORNO SERVIDOR CAPÍTULO 7: Programación de servicios Web Marcos López Sanz Juan Manuel Vara Mesa Jenifer Verde Marín Diana Marcela Sánchez Fúquene Jesús Javier Jiménez Hernández Valeria

Más detalles

Tema 1: Introducción a la gestión y planificación de redes

Tema 1: Introducción a la gestión y planificación de redes Tema 1: Introducción a la gestión y planificación de redes 1. Introducción general 2. Objetivos de la gestión de redes 3. Objetivos de la planificación de redes 4. Sistemas de gestión de red Gestión de

Más detalles

SERVICIOS: EXPLORACIONES EN SOA y WEB.

SERVICIOS: EXPLORACIONES EN SOA y WEB. SERVICIOS: EXPLORACIONES EN SOA y WEB. López, G. 1 ; Jeder, I 1.; Echeverría, A 1.; Grossi, M.D. 2 ; Servetto, A 2.; Fierro, P. (PhD.) 3 1. Laboratorio de Informática de Gestión - Facultad de Ingeniería.

Más detalles

Modelar, documentar, discutir, versionar, difundir, capacitar DESCRIPCIÓN TÉCNICA

Modelar, documentar, discutir, versionar, difundir, capacitar DESCRIPCIÓN TÉCNICA Sistema para Gestión de Conocimiento Modelar, documentar, discutir, versionar, difundir, capacitar DESCRIPCIÓN TÉCNICA Contenido Introducción... 3 Antecedentes... 4 Ediciones... 4 Empresarial... 4 Personal...

Más detalles

Utilizar los servicios de Index Service para buscar información de forma rápida y segura, ya sea localmente o en la red.

Utilizar los servicios de Index Service para buscar información de forma rápida y segura, ya sea localmente o en la red. Funciones de servidor La familia Windows Server 2003 ofrece varias funciones de servidor. Para configurar una función de servidor, instale dicha función mediante el Asistente para configurar su servidor;

Más detalles

WebSphere Extended Deployment

WebSphere Extended Deployment IBM Software Group WebSphere Extended Deployment Gestión de Efectividad y Capacidad Agenda WebSphere Extended Deployment: Introducción Dynamic Operations Extended Manageability High Performance Computing

Más detalles

Notas técnicas de JAVA Nro. 7 Tip Breve

Notas técnicas de JAVA Nro. 7 Tip Breve Notas técnicas de JAVA Nro. 7 Tip Breve (Lo nuevo, lo escondido, o simplemente lo de siempre pero bien explicado) Tema: JAVA Basics: Diferencias conceptuales entre JavaBeans y Enterprise JavaBeans (EJB)

Más detalles

ENCUENTA - CONTABILIDAD Net. Definiciones generales

ENCUENTA - CONTABILIDAD Net. Definiciones generales ENCUENTA - CONTABILIDAD Net Definiciones generales 2013 ENCUENTA - CONTABILIDAD Net Definiciones generales Contenido 1 GENERALIDADES... 3 2 DISTRIBUCIÓN GENERAL DE LOS ELEMENTOS DEL SISTEMA... 3 3 REQUERIMIENTOS...

Más detalles

INTEGRACIÓN DE SISTEMAS HEREDADOS

INTEGRACIÓN DE SISTEMAS HEREDADOS CAPÍTULO 2 INTEGRACIÓN DE SISTEMAS HEREDADOS En el presente capítulo, se presenta el problema de integración de sistemas de Software. Una de cuyas características es la presencia de los llamados Sistemas

Más detalles

CAPITULO V. IMPLEMENTACIÓN DE UNA HERRAMIENTA INTEGRADA DE RED

CAPITULO V. IMPLEMENTACIÓN DE UNA HERRAMIENTA INTEGRADA DE RED CAPITULO V. IMPLEMENTACIÓN DE UNA HERRAMIENTA INTEGRADA DE RED En el presente capitulo se presenta una aplicación que aborda una herramienta de monitoreo de redes para soportar estudios de disponibilidad.

Más detalles

Estructura de Bases de datos. Leonardo Víquez Acuña

Estructura de Bases de datos. Leonardo Víquez Acuña Estructura de Bases de datos Leonardo Víquez Acuña Lenguajes de Bases de Datos Un sistema de bases de datos proporciona Un lenguaje de definición de datos para especificar el esquema de la base de datos

Más detalles

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com EMPRESAS TUXPAN www.tuxpan.com AÑO 2007 INDICE DE CONTENIDO 1 Software de Servicios y Orquestación de Procesos 2 1.1.1 Introducción 2 1.1.2 Software de Orquestación como Integrador 3 1.1.3 Automatización

Más detalles

Unidad I. 1. Introducción. Equipo (PC) Sistema Operativo. Red de PC s. Sistema Operativo de Red. Compartir Recursos Habilitar Usuarios.

Unidad I. 1. Introducción. Equipo (PC) Sistema Operativo. Red de PC s. Sistema Operativo de Red. Compartir Recursos Habilitar Usuarios. Unidad I 1. Introducción. Equipo (PC) Sistema Operativo necesitan Red de PC s Sistema Operativo de Red. para Compartir Recursos Habilitar Usuarios. Niveles de Integración: Añadido al S.O (Novell, Lantastic).

Más detalles

Laboratorio de Procesamiento Paralelo MultiCluster accesible vía v a WEB

Laboratorio de Procesamiento Paralelo MultiCluster accesible vía v a WEB FACULTAD DE INFORMÁTICA UNIVERSIDAD NACIONAL DE LA PLATA Laboratorio de Procesamiento Paralelo MultiCluster accesible vía v a WEB Tesina de Licenciatura en Sistemas Autor: Adrián Pousa Director: Armando

Más detalles

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas CAPITULO 1 Introducción a los Conceptos Generales de 1.1 Preliminares Las empresas necesitan almacenar información. La información puede ser de todo tipo. Cada elemento informativo es lo que se conoce

Más detalles

Cómo lograr una implementación exitosa de SOA?

Cómo lograr una implementación exitosa de SOA? Software Huibert Aalbers Certified Executive Software IT Architect BUE Technical Sales, SW Services Manager IBM de Mexico 2007 IBM Corporation Agenda!Interoperabilidad! De dónde viene SOA?!Las distintas

Más detalles

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra Si en otros tiempos el factor decisivo de la producción era la tierra y luego lo fue el capital... hoy día el factor decisivo es cada vez más el hombre mismo, es decir, su conocimiento... Juan Pablo II

Más detalles

DESCRIPCIÓN TÉCNICA AZUAN PROPIEDAD DE AZUAN TECHNOLOGIES S.A.

DESCRIPCIÓN TÉCNICA AZUAN PROPIEDAD DE AZUAN TECHNOLOGIES S.A. DESCRIPCIÓN TÉCNICA AZUAN PROPIEDAD DE AZUAN TECHNOLOGIES S.A. La información contenida en este documento es confidencial y propiedad de AZUAN TECHNOLOGIES S.A. La información de este documento no puede

Más detalles

La utilización de las diferentes aplicaciones o servicios de Internet se lleva a cabo respondiendo al llamado modelo cliente-servidor.

La utilización de las diferentes aplicaciones o servicios de Internet se lleva a cabo respondiendo al llamado modelo cliente-servidor. Procesamiento del lado del servidor La Programación del lado del servidor es una tecnología que consiste en el procesamiento de una petición de un usuario mediante la interpretación de un script en el

Más detalles

Sistemas Operativos de red (NOS).

Sistemas Operativos de red (NOS). Sistemas Operativos 4 tareas principales: Proporcionar interfaz: de comando o gráfica. Administrar los dispositivos de hardware en la computadora. Administrar y mantener los sistemas de archivo de disco.

Más detalles

Tema 1: INTRODUCCIÓN A LOS SISTEMAS DISTRIBUIDOS Sistemas Distribuidos

Tema 1: INTRODUCCIÓN A LOS SISTEMAS DISTRIBUIDOS Sistemas Distribuidos Tema 1: INTRODUCCIÓN A LOS SISTEMAS DISTRIBUIDOS E. U. Informática en Segovia Departamento de Informática Universidad de Valladolid Introducción a la Computación Distribuida Sistema distribuido: conjunto

Más detalles

Clase 1: Estructuras, Procesos y Diccionario de Datos

Clase 1: Estructuras, Procesos y Diccionario de Datos Clase 1: Estructuras, Procesos y Diccionario de Datos Estructura de la memoria System Global Area Buffer Cache Redo Log Buffer Share Pool Dictionary Cache Large Pool Process Global Area Private SQL Area

Más detalles

TABLA DE CONTENIDO 1. REQUERIMIENTOS NO FUNCIONALES... 2

TABLA DE CONTENIDO 1. REQUERIMIENTOS NO FUNCIONALES... 2 TABLA DE CONTENIDO Pág. 1. REQUERIMIENTOS NO FUNCIONALES... 2 1.1 ATRIBUTOS DE CALIDAD DEL SISTEMA... 2 1.2 OTROS REQUERIMIENTOS NO FUNCIONALES... 4 1.3 REQUERIMIENTOS NO FUNCIONALES PARA HERRAMIENTAS

Más detalles

Modulo I. Introducción a la Programación Web. 1.1 Servidor Web.

Modulo I. Introducción a la Programación Web. 1.1 Servidor Web. Modulo I. Introducción a la Programación Web. 1.1 Servidor Web. Antes de analizar lo que es un servidor Web y llevara a cabo su instalación, es muy importante identificar diferentes elementos involucrados

Más detalles

MATERIA : TECNOLOGIA WEB TEMA : SERVIDORES. DOCENTE : Lic. Cynthia Rodriguez Canaviri

MATERIA : TECNOLOGIA WEB TEMA : SERVIDORES. DOCENTE : Lic. Cynthia Rodriguez Canaviri ESCUELA MILITAR DE INGENIERIA MCAL. ANTONIO JOSE DE SUCRE BOLIVIA MATERIA : TECNOLOGIA WEB TEMA : SERVIDORES DOCENTE : Lic. Cynthia Rodriguez Canaviri ALUMNO : Sof. Incl. Marco Pinto Mencias Sof. Incl.

Más detalles

CAPITULO 9. Diseño de una Base de Datos Relacional Distribuida

CAPITULO 9. Diseño de una Base de Datos Relacional Distribuida 9.1 Operaciones CAPITULO 9 Diseño de una Base de Datos Relacional Distribuida Las consultas distribuidas obtienen acceso a datos de varios orígenes de datos homogéneos o heterogéneos. Estos orígenes de

Más detalles

Interfaces de acceso a base de datos. Interfaces de acceso a base de datos. Interfaces de acceso a base de datos. Interfaces de acceso a base de datos

Interfaces de acceso a base de datos. Interfaces de acceso a base de datos. Interfaces de acceso a base de datos. Interfaces de acceso a base de datos Objetivos del curso Patrimonio Cultural Desarrollo de Herramientas de Administración y Acceso Adquirir visión generalizada de las tecnologías de desarrollo utilizadas en Sistemas de gestión del Patrimonio

Más detalles

Service Oriented Architecture

Service Oriented Architecture Service Oriented Architecture Isaac Gutiérrez Gómez, Salvador Otón Tortosa Universidad de Alcalá, Departamento de Ciencias de la Computación, 28871 Alcalá de Henares, Spain igutierrez09@yahoo.es, salvador.oton@uah.es

Más detalles

Acoplamiento e interoperabilidad

Acoplamiento e interoperabilidad Máster Universitario en Ingeniería Informá3ca Acoplamiento e interoperabilidad Sistemas de Información Orientados a Servicios RODRIGO SANTAMARÍA 2 Acoplamiento débil Tipos de acoplamiento Cabalgando el

Más detalles

Tema 2: EL MODELO CLIENTE/SERVIDOR

Tema 2: EL MODELO CLIENTE/SERVIDOR Tema 2: EL MODELO CLIENTE/SERVIDOR E. U. Informática en Segovia Departamento de Informática Universidad de Valladolid Definición de sistemas cliente/servidor (1) En la arquitectura cliente/servidor: Los

Más detalles