Estudio de Tecnologías Middleware para Sistemas Peer-to-Peer
|
|
- Marina Pérez Aguirre
- hace 8 años
- Vistas:
Transcripción
1 1 Estudio de Tecnologías Middleware para Sistemas Peer-to-Peer Luis E. Mendoza, LISI,Universidad Simón Bolívar Abstract El término Peer-to-Peer (P2P) es utilizado para referirse a un esquema de comunicación basado en diferentes tecnologías que permite que una computadora en red pueda interactuar con otra sin necesidad de la intervención de un servidor central. Este esquema de comunicación es muy conveniente cuando se requiere que sistemas heterogóneos se interconecten para realizar diferentes transacciones de manera de aprovechar y compartir eficazmente recursos distribuidos. Dado que en el mercado existe una amplia gama de tecnologías Middleware para conectar aplicaciones distribuidas en tiempo real como las que se pueden conseguir a través de aplicaciones P2P empotradas, el objetivo de esta investigación es orientar a los Ingenieros de Software en la selección más adecuada de estas tecnologías al momento de requerir diseñar la interconexión de Sistemas P2P. Index Terms P2P, Middleware, Sistemas de Tiempo Real, Sistemas Heterogéneos, Selección de tecnología L I. INTRODUCCIÓN A tecnología P2P se está moviendo rápidamente y abarcando muchas categorías. Algunos visionarios del P2P ven la comunicación P2P como el modelo de cómputo que tiene el potencial para reemplazar el modelo de Internet basado en servidor. P2P hace factible un amplio campo de nuevas capacidades y aplicaciones: búsqueda dinámica y distribuida, manejo y almacenado de información en forma distribuida, procesamiento distribuido y paralelo. Las aplicaciones de este tipo también permiten el envío de archivos. Esta tecnología se utiliza también para la conexión de tecnologías dispares, de diferentes plataformas y recursos de computación. Por otro lado, los sistemas de tiempo real [8], pueden apalancarse en el uso de P2P para aprovechar y compartir eficazmente los recursos distribuidos. Ahora bien, estos recursos pueden estar desarrollados en tecnologías diferentes, lo cual puede repercutir negativamente en la interconexión entre ellos para realizar las diferentes transacciones para las cuales fueron diseñados. Manuscrito recibido el 15 de Octubre de Este trabajo fue financiada por el Fondo Nacional de Ciencia, Tecnología e Innovación (FONACIT) de la República Bolivariana de Venezuela, a través del proyecto S (Selección y Adopción de Estrategias para la Integración de Sistemas) Luis E. Mendoza es investigador del Laboratorio de Investigación en Sistemas de Información (LISI), Departamento de Procesos y Sistemas, Universidad Simón Bolívar, Apartado Postal 89000, Caracas 1080-A, Caracas - Venezuela (telefax: ; lmendoza@usb.ve). Con la finalidad de solventar problemas como los anteriores, se utiliza la tecnología Middleware para conectar partes de aplicaciones distribuidas, de tal manera que se logre la abstracción de la complejidad y la heterogeneidad de las arquitecturas, protocolos, sistemas operativos, lenguajes de programación [15] utilizados para la construcción de sistemas distribuidos en general, en particular, sistemas P2P. Lo anterior permite deducir que no es fácil decidir cuál debe ser la tecnología Middleware más apropiada para conectar aplicaciones distribuidas en tiempo real como las que se pueden conseguir a través de aplicaciones P2P empotradas, dado que en el mercado existe una amplia gama de estas tecnologías. Es por ello que, el objetivo de esta investigación es orientar a los Ingenieros de Software en la selección más adecuada de estas tecnologías al momento de requerir diseñar la interconexión de Sistemas P2P. Este artículo comienza por definir brevemente lo que se conoce por Sistemas P2P. Luego, se realiza un estudio que describe las ventajas y desventajas de los distintos tipos de Middleware, para posteriormente, apoyado en lo anterior, presentar unas orientaciones para la selección de las tecnologías ofrecidas. Finalmente, se cierra con las conclusiones más relevantes II. SISTEMAS PEER-TO-PEER (P2P) Durante los últimos años, las redes P2P han revolucionado la manera de aprovechar y compartir eficazmente recursos distribuidos. En contraste con la tradicional arquitectura cliente-servidor, los sistemas P2P son, a nivel de aplicaciones, sistemas colaborativos que trabajan juntos para realizar ciertas tareas [23]. El término P2P es utilizado para referirse a un esquema de comunicaciones basado en diferentes tecnologías que permite que una computadora en red pueda interactuar con otra sin necesidad de la intervención de un servidor central [11]. Bajo este modelo, cada parte involucrada tiene las mismas capacidades y puede iniciar una sesión de comunicación en cualquier momento. En algunos casos en Internet el P2P se implementa otorgándole a cada nodo o participante de las capacidades de cliente y servidor, con esto los usuarios pueden intercambiar archivos de diferentes índoles directamente o utilizando un servidor de mediación [11]. A. Tipos de P2P Las arquitecturas P2P han sido utilizadas para una variedad
2 2 de aplicaciones diferentes, entre las cuales se tienen [3] (Referencias de todos los sistemas dados de ejemplo para cada categoría están en [3]): 1) Comunicación y Colaboración. Esta categoría incluye sistemas que proveen la infraestructura para facilitar la comunicación y la colaboración directa, normalmente en tiempo real, entre las computadoras a la par. En esta categoría se incluyen los chat y las aplicaciones de la mensajería instantáneas, como Chat/Irc, AOL, Icq, Yahoo y MSN. 2) Computación distribuida. Esta categoría incluye sistemas cuyo objetivo es tomar ventaja de la disponibilidad del poder del proceso de computación (ciclos del CPU) del par. Esto se logra desagregando las tareas intensivas de computación en unidades de trabajo pequeñas y distribuyéndolas entre computadoras pares diferentes que ejecutan su unidad de trabajo correspondiente y devuelven los resultados. La coordinación central es requerida, principalmente para la separación y distribución de las tareas y para recolectar los resultados. Los ejemplos de tales sistemas incluyen los proyectos como Seti@home y genome@home. 3) Soporte de servicios de Internet. Varias aplicaciones diferentes basadas en las infraestructuras P2P han surgido para apoyar una variedad de servicios de Internet. Los ejemplos de tales aplicaciones incluyen los sistemas de multidifusión P2P y aplicaciones de seguridad, proporcionando protección contra el rechazo del servicio o ataques de virus. 4) Sistemas de bases de datos. Se ha realizado un trabajo considerable en diseñar sistemas de bases de datos distribuidos basados en infraestructuras P2P. Ejemplo de esto es el Modelo Correlativo Local (LRM), el motor de búsqueda PIER, el sistema Piazza que proporciona datos (por ejemplo de una base de datos relacional), esquemas (u ontologías) o ambos; finalmente, Edutella, un proyecto que provee una infraestructura de metadatos y la capacidad de búsqueda de aplicaciones P2P. 5) Distribución de contenido. La mayoría de los sistemas actuales P2P cae dentro de esta categoría, ya que incluyen sistemas e infraestructuras diseñadas para compartir de medios digitales y otros datos entre los usuarios. El rango de sistemas de distribución de contenidos va desde aplicaciones para la simple distribución directa de archivos a sistemas más sofisticados que crean un medio del almacenamiento distribuido para publicar, buscar, actualizar y recuperar datos de manera segura, eficaz, organizada e indexada. Algunos ejemplos son: Napster, Publius, Gnutella, Kazaa, Freenet, MojoNation, Oceanstore, PAST, Chord, Scan, FreeHaven, Groove y Mnemosyne.. B. Arquitecturas P2P Según Backx [5], todas las arquitecturas P2P tienen una cosa en común: la transferencia datos siempre es P2P: una conexión directa de datos entre el par que ofrece el archivo y el que lo requiere. Sin embargo, el control se lleva a cabo de varias maneras. La Fig. 1 muestra los 3 tipos típicos de secuencia búsquedadescarga que se han identificado, con las cuales se realizan la mayoría de las búsquedas de un archivo y se hacen la descarga desde el par más indicado. Cada aplicación P2P usa una de estas arquitecturas, con sus propias particularidades [5]. control datos Mediada Pura Híbrida Fig. 1. Las tres arquitecturas P2P [5]. 1) Arquitectura mediada. Usa un esquema cliente-servidor para sus operaciones de control. Todos los pares se conectan a un servidor central que maneja el archivo y las bases de datos del usuario. Se envían búsquedas para un archivo al servidor; si se encuentra, el archivo puede descargarse directamente del par. En la mayoría de los casos el servidor tendrá una base de datos de archivos compartido por los pares. 2) Arquitectura pura P2P. Las aplicaciones puras P2P no usarán un servidor central en absoluto (excepto posiblemente para acceder la red). Pueden enviarse búsquedas para los archivos a través de la red o pueden usarse mecanismos más inteligentes [1,2]. Las redes puras P2P no han sido populares porque ellas generan mucho tráfico que debe mantenerse arriba y funcionando. 3) Arquitecturas híbridas. Las arquitecturas híbridas son el último desarrollo en la comunidad P2P [22]. Su meta es ofrecer lo mejor de las propiedades de las arquitecturas mediadas y las puras, a través de la introducción de los llamados ultrapeers. Los ultrapeer realizarán la tarea de un servidor en la arquitectura mediada, pero para sólo un subconjunto de los pares. Los ultrapeers se conectan a través de una red pura P2P. Así, las arquitecturas híbridas introducen dos capas para el control: uno de conexión de pares a los ultrapeers de forma cliente-servidor y uno de conexión entre ultrapeers vía una red pura P2P. Las arquitecturas puras e híbridas construyen una capa de red sobre la red IP existente. En la mayoría de los casos esta capa se construye arbitrariamente; sin embargo, se ha mostrado [18] que esto genera una gran cantidad de tráfico inter-dominio que puede reducirse construyendo esa capa con inteligencia. Como se ha podido ver en las arquitecturas anteriores, a pesar de que puede haber una gran heterogeneidad de pares que están distribuidos en al red, uno de los aspectos más importantes para que las arquitecturas puedan funcionar, es que haya comunicación simétrica (se considera que los pares son iguales) entre los pares [20]. Esta realidad hace que surja el problema de que los pares tengan que interconectarse, a
3 3 pesar de que estén desarrollados con tecnologías distintas, para ejecutar las transacciones requeridas. En este sentido, las tecnologías Middleware ayudan a solucionar este problema ya que habilitan directamente interacciones entre aplicaciones independientemente diseñadas en un entorno distribuido [14]. Lo anterior se debe a que la tecnología Middleware posee una arquitectura que mejora la comunicación, añade conectividad y proporciona seguridad [21]. III. TECNOLOGÍA MIDDLEWARE El esquema tradicional cliente/servidor permite que diferentes módulos de aplicación se comuniquen directamente sin una capa intermediaria. El problema se presenta en sistemas complejos de tiempo real como los P2P y con componentes de diversos proveedores resulta poco flexible e inoperante la comunicación [15]. Middleware es un término, como muchos otros en este campo, ampliamente usado y posee muchas definiciones. De manera informal se le llama plumbing porque conecta partes de aplicaciones distribuidas con pipes de datos y favorece el intercambio de datos entre ellas. También se llama tecnología del glue, porque se utiliza para integrar componentes heredados [4]. Mas formalmente, y a efectos de este artículo, se define Middleware, como la capa de software que se coloca entre cada peer y el entorno distribuido, abstrayendo a los peers de la complejidad y la heterogeneidad de las arquitecturas, protocolos, sistemas operativos, lenguajes de programación; es decir, otorga la posibilidad de intercomunicar aplicaciones desarrolladas dentro de los peers en distintos lenguajes de programación, sistemas operativos y plataformas [15]. En otras palabras, engloba los elementos que permiten la comunicación entre los peers. Diversos autores han escrito acerca de los tipos o categorías de Middleware, lo que hace muy amplia la gama de clasificaciones de los Middleware; sin embargo, Ariannejad [4] hace una clasificación bastante completa, donde cada categoría está incluida en algún punto de la definición dada anteriormente. Esta categorización realizada por Ariannejad [4], presenta nueve tipos de Middleware: Distributed Tuples, Remote Procedure Call, Messaging Oriented Middleware, Distributed Object Middleware, Transaction Processing Monitors, Database Access Technology, Component Oriented Framework, Directory Services, Application Servers. En esta categorización se abarcan otras como la propuesta por Bakken [6], Creamer [9] y Jones [12]. 1) Distributed Tuples (DT). Es el Middleware para acceso a base de datos que permite desarrollar sistemas independientes del manejador de base de datos que lo soporta. Por ejemplo el framework Linda. 2) Remote Procedure Call (RPC). Es el Middleware diseñado como servicio síncrono para permitir la gestión remota de redes. Esconde las operaciones de envío y recepción bajo el aspecto de una llamada convencional a una rutina o procedimiento. Los RPC tienen la misma semántica que las llamadas a procedimientos ordinarios; es decir, se realiza la llamada y se pasa el control al procedimiento servidor; cuando éste devuelve el resultado, el cliente recupera el control. El software que soporta RPC debe ocuparse de tres tareas importantes: la interfaz del servicio, la búsqueda del servidor, y la gestión de comunicación. El sistema RPC de SUN, proporciona un lenguaje de definición de interfaz llamado external Data Representation (XDR) y un compilador de interfaces denominado rpcgen. A partir de una interfaz definida por XDR y con ayuda del rpcgen, se obtiene gran parte de los componentes del mecanismo completo de una RPC. 3) Messaging Oriented Middleware (MOM). Es el Middleware orientado a mensajes; está diseñado para el servicio de mensajes con tecnología asíncrona. Permite el envío de mensajes entre aplicaciones, las aplicaciones sólo ponen y sacan mensajes de las colas, no se conectan. El cliente y el servidor pueden ejecutarse en diferentes tiempos (mensajes asíncronos), por lo que no necesariamente se requiere respuesta. 4) Distributed Object Middleware (DOM). Es el Middleware para tecnologías orientadas a objetos; los objetos piden servicio a otros objetos que se encuentran en la red. Se encarga de establecer comunicación entre los clientes y los objetos de forma transparente respecto a la distribución. Permite localizar a un objeto remoto dada una referencia a ese objeto. El núcleo de estos Middleware es Object Request Broker (ORB). Ejemplo de este Middleware son: Common Object Request Broker Architecture (CORBA) de OMG, Remote Method Invocation (RMI) de SUN Microsystems y Distributed Component Object Model (DCOM) de Microsoft Common Object Request Broker Architecture (CORBA). Es un modelo de soporte para la programación distribuida orientada a objetos. Hace posible que los objetos interactúen a través de lenguajes de programación, protocolos de comunicación y plataformas heterogéneas. Este modelo no especifica cómo hacer el soporte, sino qué debe hacer, basado en cinco aspectos de los sistemas distribuidos: Interface Definition Lenguaje (IDL): permite la descripción de la interfaz que ofrece un objeto. CorbaServices (servicios CORBA): complementan a los objetos que sirven para la construcción de aplicaciones. CorbaFacilities (facilidades CORBA): cubren servicios de alto nivel, como interfaces, administración de sistemas y redes. CorbaDomains (interfaces de dominio CORBA): proveen funcionalidad a usuarios finales en áreas de interés particular. General Inter-ORB Protocol (GIOP). Define los mensajes y el empaquetado de datos que se
4 4 transmiten entre objetos. Además, define su implementación sobre otros protocolos 4.2. Remote Method Invocation (RMI). Posee la misma finalidad que el RPC: invocar de la manera más transparente posible un servicio en una máquina virtual distinta a la que reside el cliente (en la misma máquina física pueden existir varias máquinas virtuales de Java). La diferencia entre estas dos tecnologías radica en que RPC se utiliza en diseños no orientados a objetos, mientras que RMI está soportado por el lenguaje orientado a objetos Java. RMI es un Middleware específico que permite a clientes invocar métodos de objetos como si estuviesen en la misma máquina virtual Distributed Component Object Model (DCOM). Al igual que CORBA y RMI, permiten la comunicación de objetos, pero únicamente para las diferentes versiones del sistema operativo Windows. DCOM surge como evolución de Object Linking and Embedding (OLE) y Component Object Model (COM). 5) Transaction Processing Monitors (TP Monitors). El Middleware para Procesamiento de Transacciones ya que facilita la conectividad y el acceso a un gran número de usuarios con servicios de back-end limitados. Este tipo de Middleware requiere del soporte de un Monitor; es decir, un programa que supervise las transacciones entre procesos, con el propósito de asegurar el éxito de la transacción, o en caso de ocurrir un error, tomar acciones apropiadas. Su principal uso es coordinar el flujo de solicitudes entre los dispositivos y las aplicaciones que procesan esas solicitudes. 6) Database Access Technology (DBAT). Son las Aplication Programming Interface (API) creando una capa transparente para el acceso a base de datos, ocultando la complejidad dada por el manejador de base de datos. Ejemplo de estas API son Java Database Connectivity (JDBC) desarrollado por SUN y Open Database Connectivity (ODBC) desarrollado por Microsoft Java DataBase Connectivity (JDBC). Es una API que facilita programar el acceso a bases de datos para Java sin que se tenga en cuenta a que Servidor se dirige (SQLServer, Oracle, Sybase, Informix, etc.). JDBC hace tres cosas: establece la conexión con una BD, envía sentencias SQL y procesa los resultados Open Database Connectivity (ODBC). Es una API abierta para acceder a bases de datos. Especifica un conjunto de funciones para manejar conexiones a bases de datos, ejecutar declaraciones SQL (Structure Query Language) y consultar las capacidades del sistema de base de datos. 7) Component Oriented Framework (COF). Este Middleware está soportado en el modelo de desarrollo de aplicaciones basado en componentes, permite la creación de una aplicación como conjunto de componentes reusables. Los componentes son una evolución del software orientado a objetos para dar respuesta a la reusabilidad. Los Middleware basados en componentes permiten a éstos "pegarse" con otros componentes para lograr la integración. Algunos ejemplos son: Enterprise Java Beans (EJB), especificación creada por SUN Microsystems; define un framework para los componentes Java del lado del servidor. COM+ es la siguiente generación de DCOM; simplifica la programación y es igualmente diseñado por Microsoft. CORBA Component Model (CCM). 8) Directory Services (DS). Es el Middleware que se basa en directorios que permiten reducir costos administrativos, simplifican y/o distribuyen tareas administrativas, reducen el número de passwords para un usuario mediante una única combinación de login/password, aumentan la seguridad y proporcionan una única localización para la información de los usuarios. Son similares a la bases de datos, pero contienen información más descriptiva; la frecuencia de lectura sobre ellos es bastante más alta que la de escritura y en consecuencia su manejo es más simple que el de una base de datos ya que no hace actualizaciones complejas. LDAP Lightweight Directory Access Protocol (LDAP) es un protocolo para acceder a los DS. Como ejemplo, se tienen los Domain Name System (DNS) que conforman una fuente de datos distribuidas por múltiples máquinas en Internet, cuya tarea es convertir nombres en direcciones. 9) Application Servers (AS). Es el Middleware que se enfoca en la parte de la de aplicación o lógica del negocio. Conceptualmente un sistema puede tener muchas capas; sin embargo, la arquitectura más popular es de tres capas: interfaz, aplicación y base de datos. Como se aprecia, las tecnologías Middleware fundamentalmente dependen de los mecanismos que permiten la interconexión de los sistemas. Es decir, todas las tecnologías Middleware permiten comunicación. La diferencia entre ellas se encuentra en el énfasis que presentan como apoyo en aspectos como datos y procesos [6]. Entonces, cuál de las tecnologías descritas es la apropiada?, la respuesta a esta pregunta no es trivial, a continuación se dan algunas orientaciones que ayudan en la selección de aquella más apropiada para sistemas P2P. IV. ORIENTACIONES PARA LA SELECCIÓN DE TECNOLOGÍAS MIDDLEWARE En este punto se presentan algunas consideraciones útiles para orientar al ingeniero de software en la selección de las tecnologías Middleware para Sistemas P2P, las cuales se resumen en la Tabla I y se basan en lo expresado en [4,3,9,10,15,16,17,19]. Al analizar la Tabla I se puede decir que no es posible hacer una comparación entre estos tipos de Middleware para Sistemas P2P, debido a que los mecanismos que las soportan están diseñados para aplicarse en ambientes y situaciones diferentes (escenarios). Por lo tanto, estos tipos de
5 5 Middleware pueden coexistir, no son excluyentes. Más aún, existen tipos que están estrechamente relacionados, sobre todo si pertenecen al mismo fabricante. Las comparaciones son posibles entre tecnologías Middleware que se basan en el mismo paradigma. TABLA I VENTAJAS Y DESVENTAJAS DE LOS MIDDLEWARE. ADAPTADO DE [4,6,9,10,15,16,17,19]. Middleware Ventajas Desventajas DT RPC MOM DOM CORBA Permite compartir datos entre aplicaciones, con poco impacto en el rendimiento. Provee un modelo poderoso para manejar sistemas P2P de objetos distribuidos. Por ser el primer tipo de Middleware es el menos complicado de usar y comprender. Por ser síncrono, provee mayor integridad de los datos que manejan los sistemas P2P. Por ser asíncrono, un proceso puede enviar una solicitud y continuar ejecutándose sin recibir respuesta de culminación de esta. Es una buena elección cuando se tiene poco ancho de banda o cuando la red es inestable. Aplican en ambientes orientados a objetos. Útil para desarrollar sistemas P2P grandes, soporta multilenguaje de programación. Soporta plataformas y sistemas operativos heterogéneos. Sólo es recomendable cuando los datos no se actualizan con mucha frecuencia. Exige alto nivel de procesamiento. Tiene bajo rendimiento. No aplican cuando se requiere la respuesta de una solicitud para continuar el proceso. No soporta procesos de negocio. Tiene menor desempeño que RMI. Al ser tan amplio, es más complejo que RMI y DCOM. RMI Gracias a la máquina virtual Sólo para objetos Java. Java soporta multiplataforma. DCOM Soporta multilenguaje. Especialmente diseñado para trabajar sobre sistemas operativos de Microsoft. TP Monitors DBAT COF DS Útiles cuando se necesita tener control de las transacciones que se procesan. Las aplicaciones que ejecutan las transacciones generalmente acceden bases de datos y sistemas de comunicaciones. La asignación de recursos no es de forma permanente. Comparten y reutilizan recursos. Es un estándar muy utilizado. Encapsula la complejidad de la conexión con la base de datos. Proporciona lineamientos para el uso apropiado de DOM. Más sencillo de manejar que una BD. Se utiliza para el almacenamiento de: Información de usuarios (autentificación y autorización). Información del hardware de la red. No son útiles para el intercambio de información. Puede resultar más lento el intercambio entre la aplicación y la base de datos que con el uso de otras tecnologías. Puede resultar complejo en ambientes altamente distribuidos. Su uso es específico para entidades de red como aplicaciones, archivos, impresoras y usuarios. AS Agendas de direcciones. Configuraciones de programas. Provee servicios para la administración de procesos (tal como desarrollo, monitoreado y alimentación de procesos) que son compartidos por múltiples aplicaciones. Centraliza la lógica de las aplicaciones, haciendo que la administración de cambios sea más sencilla. Se utilizan sólo en ambientes multicapas (actualmente, es el caso de la mayoría de los sistemas P2P) Con base en la reflexión del párrafo anterior, a continuación se intenta describir varios escenarios y las orientaciones propuestas para decidir sobre la tecnología Middleware apropiada para soportar los sistemas P2P. 1) En muchas aplicaciones P2P es frecuente el uso de DBAT para comunicarse con las bases de datos. 2) El Middleware DT es un framework el cual permite "publicar" información en un Tuple Space (TS) que a su vez permite a quienes se "suscriban" utilizar dicha información. Proporciona integración sólo a través del compartimiento de datos. Mantiene duplicidad de la data, con lo cual sacrifica espacio y posible falta de integridad, pero puede resultar beneficioso para el rendimiento tanto de la aplicación que publica como para los suscriptores de la información, debido a que el proceso de una aplicación no interfiere con el de la otra. Es recomendable sólo si el suscriptor puede trabajar con información que pudiera no estar actualizada al momento. 3) Si entre los sistemas P2P que se desean interconectar existe alguno heredado del cual no se posee código fuente, la posibilidad de comunicación que se tiene es a través de datos, puesto que actuarían como caja negra y sólo se tendrá acceso a la salida de datos que genera. Es decir, se puede manejar un DT o vía API para comunicarse desde una aplicación a la base de datos de software heredado. 4) Para alcanzar una interconexión que involucre los procesos del negocio, es posible utilizar tecnologías Middleware como DOM en aplicaciones donde probablemente se tiene el código fuente y se pueden crear lazos entre las mismas para que trabajen en equipo y colaboren entre si. En este caso, lo recomendable es un estudio de la plataforma de los distintos sistemas P2P, de manera que la primera sugerencia es trabajar usando tecnología del mismo fabricante. Además, se debe considerar si los sistemas P2P involucrados permiten o no orientación a objetos. De no permitirlo, la alternativa es el uso de RPC, pero si lo permite, lo apropiado es DOM, lo cual viene a resaltar la sugerencia anterior, de modo que si la plataforma es Windows, por ejemplo, es recomendable un desarrollo basado en DCOM, el framework deberá ser COM+, pero si además lo que se quiere es comunicar aplicaciones Web, el servidor apropiado es IIS, y si se requiere comunicación con alguna base de datos, entonces se deberá usar el API de comunicación ODBC.
6 6 5) Cuando se requiere un alto grado de interconexión, conviene evitar el uso de RPC, debido al alto consumo de procesamiento que conlleva, lo que baja notoriamente el rendimiento. Bajo las mismas recomendaciones hechas anteriormente, es posible el uso de DT y/o DOM (todo dependerá de la necesidad de interconexión: datos, procesos o ambos). Sin embargo, actualmente la tendencia en aplicaciones P2P, es usar MOM debido a que permite una comunicación asíncrona entre los miembros de la red. Por ejemplo, al efectuar una compra por Internet, el comprador introduce los datos de la compra y de la forma de pago, los envía y posteriormente él recibe información que especifica si sus datos están o no en orden; es decir, hubo un envío de mensaje a una aplicación que se encarga de validar la transacción bancaria y una vez hecho esto se envían mensajes notificando el estado de la compra (como se aprecia, la compra realmente no se hace en línea puesto que los mensajes son asíncronos). Los mensajes suelen usar Extensible Markup Language (XML) debido a la flexibilidad y uniformidad con que puede ser intercambiada la información. 6) Los TPM son especialmente empleados en los sistemas P2P bancarios, donde es de vital importancia el monitoreo de los movimientos bancarios, en cuyo caso es muy importante conocer el éxito o el fracaso de la transacción, de manera que de existir un fallo de conexión sea posible tomar acciones, las cuales generalmente revierten la transacción. 7) Los grandes sistemas P2P (por ejemplo, bancarios) se encuentran en plataforma UNIX, lo que imposibilita el uso de componentes Microsoft, debido a que no son multiplataforma. 8) Las tecnologías Middleware como DOM ofrecen mucha flexibilidad. 9) Las consideraciones de uso de COF dependen nuevamente de la plataforma de los sistemas P2P. Ahora bien, en sistemas altamente distribuidos es posible que se presente la necesidad de combinar tecnologías. Para lo cual se tienen alternativas como integración entre COM y CORBA desarrollada por IONA Technologies o integración entre CORBA y RMI desarrollada en conjunto por OMG y SUN Microsystems. 10) Los Middleware tipo DS son fundamentales en una red P2P moderna, debido a que los servicios que proporcionan permiten identificar y administrar las relaciones entre todos los elementos de la red. 11) Los Middleware AS se utilizan principalmente en aplicaciones WEB P2P. V. CONCLUSIONES Las orientaciones aquí propuestas apoyan y soportan a los Ingenieros de Software en la selección más adecuada de estas tecnologías al momento de requerir diseñar la interconexión de Sistemas P2P. En estas orientaciones es posible detectar como los paradigmas Orientado a Objetos y de Componentes propician los niveles más altos de interconexión de los sistemas P2P debido a la alta portabilidad que proporcionan. Es fundamental tener muy claro las tecnologías que sustentan las aplicaciones P2P empotradas que se desean interconectar, ya que es la base indispensable para la toma de decisiones. Sin embargo, hace poco tiempo atrás, tal vez era difícil imaginar la rapidez con la que se ha desarrollado este tipo de tecnología y el cambio en la forma hacer negocios que han experimentado las empresas con la incorporación de Internet. Por ello, la selección apropiada de la tecnología Middleware no sólo debe pensarse como mecanismo para interconectar los sistemas heredados con los sistemas P2P modernos, sino que además puede extenderles la vida y garantizar la integración con sistemas futuros. La integración de sistemas P2P es un proceso que podría no terminar nunca, la evolución tecnológica es constante; cada vez es mayor la necesidad de comunicarse e interconectarse con más sistemas P2P. Por lo tanto, la tendencia actual, es la interconexión a través de mensajes, ya que proporciona mayor flexibilidad y por lo tanto se estima que no tendrá mayores dificultades de adaptación por cambios tecnológicos futuros. Un siguiente paso en esta investigación es la sistematización de estas orientaciones para ver su correspondencia con sistemas P2P existentes, a través del estudio de casos. REFERENCES [1] Aberer, K., P-Grid: A self-organizing access structure for P2P information systems. Technical Report TR , Ecole Polytechnique Fédérale de Lausanne [2] Aberer, K., Punceva, M., Hauswirth, M., Schmidt, R., Improving Data Access in P2P Systems. IEEE Internet Computing, January-February, [3] Androutsellis-Theotokis, S., Spinellis, D., A Survey of Peer-to-Peer Content Distribution Technologies. ACM Computing Surveys, Vol. 36, No. 4, December 2004, pp [4] Ariannejad, M., Trends in Middleware Systems. Computer Engineering Research Group, Disponible en ibe1.htm [5] Backx, P., Wauters, T., Dhoedt, B., Demeester, P., A comparison of peer-to-peer architectures. In Proceedings of Eurescom Summit 2002, Heidelberg, Alemania, [6] Bakken, D., Middleware. Chapter in Encyclopedia of Distributed Computing, J. Urban and P. Dasgupta, eds., Kluwer Academic Publishers, [7] Basanta, D. y Tajes, L., Tecnologías para el Desarrollo de Sistemas Distribuidos: Java versus Corba. X Jornadas de Paralelismo. La Magna del Mar Menor, Murcia [8] Control-Systems.Net, Glosario. Grupo de Investigación en Sistemas de Control Digital de la Universidad EAFIT, Disponible en: [9] Creamer, M., EAI Middleware: Heterogeneous Computing Comes of Age. Enterprise System Journal, [10] Hawick, K., James, H., y Pritchard, L., Tuple-Space Based Middleware for Distributed Computing. Technical Report DHPC-128, [11] IBM Global Services, Peer-to-peer: More than just downloading music. Executive Tek Report, May 29, Disponible en www- 1.ibm.com/services/us/ imc/pdf/g etr-peer-to-peer.pdf. [12] Jones, T., Middleware Options. Butler Group Concept Paper, [13] Lublinsky, B., Achieving the Ultimate EAI Implementation, Disponible en
7 7 [14] McKeen, J. y Smith, H., New Developments in Practice II: Enterprise Application Integration. Communications of the Association for Information Systems, 8(31), [15] McKeen, J. y Smith, H., New Developments in Practice IV: Managing the Technology Portfolio. Communications of the Association for Information Systems, 9(5), [16] Randall, D, John Hughes, Jon O Brien, Tom Rodden, Mark Rouncefield, Ian Sommerville and Peter Tolmie, Banking on The old Technology: Understanding the Organizational Context of Legacy Issues. Communications of the Association for Information Systems, 2(8), [17] Rinetti, G., y Rubio, M., Role of Middleware in Application Integration T Enterprise Systems Integration, [18] Ripeanu, M., Iamnitchi, A., Foster, I., Mapping the Gnutella Network. IEEE Internet Computing, January-February [19] Rogers State University, Middleware Technology. Emerging Technologies TECH 3023, [20] Roussopoulos, M., Baker, M., Rosenthal, D., Giuli, TJ, Maniatis, P., Mogul, J., 2 P2P or Not 2 P2P? Proceedings of the Third International Workshop on Peer-to-Peer Systems, San Diego, CA, USA, February 2004 [21] Sumathi, C., Spatial World Chants the EAI Mantra. Map India 2003 Poster Session, 2003 [22] Yang, B., Garcia-Moline, H., Designing a Super-Peer Network. Technical Report, Standford University, February [23] Zhang, H., Croft, W., Levine, B., Lesser, V., A Multi-agent Approach for Peer-to-Peer-based Information Retrieval Systems. In proceedings of Autonomous Agents and Multi-Agent Systems conference AAMAS'04, 2004, Luis Eduardo Mendoza Morales. Caracas, 09 de marzo de Miembro de la Association of Information Systems (AIS). Profesor Agregado de la Universidad Simón Bolívar. MSc. en Ingeniería de Sistemas (1999), Especialista en Gestión de Servicios de Información (1993) y Lic. en Matemáticas (1988). Líneas de investigación: Integración de Sistemas, Calidad de Software, Ingeniería del Software y Herramientas CASE. Áreas de interés: Impacto de los Sistemas de Información en las organizaciones. Áreas de experticia: Sistemas de Información, Ingeniería de Software y Metodologías de Desarrollo. Áreas de consultoría: Mejoramiento del Proceso de Desarrollo, Adopción de Metodologías de Desarrollo, Evaluación de la Calidad del Software y Selección de Herramientas CASE.
Capítulo 5. Cliente-Servidor.
Capítulo 5. Cliente-Servidor. 5.1 Introducción En este capítulo hablaremos acerca de la arquitectura Cliente-Servidor, ya que para nuestra aplicación utilizamos ésta arquitectura al convertir en un servidor
Más detallesElementos requeridos para crearlos (ejemplo: el compilador)
Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción
Más detallesSERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO
SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO Introducción:...1 Service Oriented Architecture...2 Elementos de una Service Oriented Architecture...2 Application frontends...2 Servicios...2 Contrato:...3
Más detallesSISTEMAS DE INFORMACIÓN II TEORÍA
CONTENIDO: EL PROCESO DE DISEÑO DE SISTEMAS DISTRIBUIDOS MANEJANDO LOS DATOS EN LOS SISTEMAS DISTRIBUIDOS DISEÑANDO SISTEMAS PARA REDES DE ÁREA LOCAL DISEÑANDO SISTEMAS PARA ARQUITECTURAS CLIENTE/SERVIDOR
Más detallesIntroducción a las redes de computadores
Introducción a las redes de computadores Contenido Descripción general 1 Beneficios de las redes 2 Papel de los equipos en una red 3 Tipos de redes 5 Sistemas operativos de red 7 Introducción a las redes
Más detallesGLOSARIO. 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 detallesModelos de los sistemas distribuidos. Jorge Iván Meza Martínez jimezam@gmail.com
Modelos de los sistemas distribuidos Jorge Iván Meza Martínez jimezam@gmail.com Especialización en Gestión de Redes de Datos Universidad Nacional de Colombia Sede Manizales 1/36 Contenidos Modelo arquitectónico
Más detallesORIENTACIONES PARA LA SELECCIÓN DE TECNOLOGÍAS DE INTEGRACIÓN DE SISTEMAS DE SOFTWARE
ORIENTACIONES PARA LA SELECCIÓN DE TECNOLOGÍAS DE INTEGRACIÓN DE SISTEMAS DE SOFTWARE María Pérez, Luis E. Mendoza, Yorka Carvajal Laboratorio de Investigación en Sistemas de Información (LISI). Departamento
Más detallesLa interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la
Servicios web Introducción Un servicio web es un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes
Más detallesArquitectura cliente/servidor
Departamento de Lenguajes y Sistemas Informáticos Arquitectura cliente/servidor Programación en Internet Curso 2004-2005 Índice Introducción Tipos de servidores Ventajas Separación de funciones Modelos
Más detallesArquitectura de Software
Arquitectura de Software (Estilos Arquitectónicos) Universidad de los Andes Demián Gutierrez Mayo 2011 1 Diseño Arquitectónico Diseño Arquitectónico Arquitectura del Software Estilos Arquitectónicos Frameworks
Más detallesArquitectura 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 detallesPRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE
PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,
Más detallesEspecificació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 detallesJAVA 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 detallesLos mayores cambios se dieron en las décadas de los setenta, atribuidos principalmente a dos causas:
SISTEMAS DISTRIBUIDOS DE REDES 1. SISTEMAS DISTRIBUIDOS Introducción y generalidades La computación desde sus inicios ha sufrido muchos cambios, desde los grandes equipos que permitían realizar tareas
Más detallesService Oriented Architecture: Con Biztalk?
Service Oriented Architecture: Con Biztalk? Pablo Abbate Servicios Profesionales Danysoft SOA supone una nueva forma de pensar acerca de la arquitectura IT para las empresas. De hecho, es una asociación
Más detallesARQUITECTURA DE DISTRIBUCIÓN DE DATOS
4 ARQUITECTURA DE DISTRIBUCIÓN DE DATOS Contenido: Arquitectura de Distribución de Datos 4.1. Transparencia 4.1.1 Transparencia de Localización 4.1.2 Transparencia de Fragmentación 4.1.3 Transparencia
Más detallesIntroducción a los Servicios Web. Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com
Introducción a los Servicios Web Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com Servicios Web y Soa En un contexto SOA y los servicios web son una oportunidad de negocios en la actualidad.
Más detallesColección de Tesis Digitales Universidad de las Américas Puebla. Morales Salcedo, Raúl
1 Colección de Tesis Digitales Universidad de las Américas Puebla Morales Salcedo, Raúl En este último capitulo se hace un recuento de los logros alcanzados durante la elaboración de este proyecto de tesis,
Más detallesLa 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 detallesARC 101 Architecture Overview Diagram
ARC 101 Architecture Overview Diagram Estudio de Arquitectura para la evolución tecnológica de los aplicativos de ATyR Banco de Previsión Social ATYR Evolución Tecnológica Pág 1 of 10 Tabla de Contenidos
Más detallesM.T.I. Arturo López Saldiña
M.T.I. Arturo López Saldiña Hoy en día, existen diversas aproximaciones al tema de cómo hacer que las personas trabajen dentro de una organización de manera colaborativa. El problema se vuelve más difícil
Más detallesUNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos
2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven
Más detallesPropuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA
Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA Documento de trabajo elaborado para la Red Temática DocenWeb: Red Temática de Docencia en Control mediante Web (DPI2002-11505-E)
Más detallesSISTEMAS DE INFORMACIÓN III TEORÍA
CONTENIDO: Introducción a los Web services Las bases de los Web services La nueva generación de la Web Interactuando con los Web services La tecnología de Web services XML: Lo fundamental WSDL: Describiendo
Más detalles1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).
1 GLOSARIO A continuación se definen, en orden alfabético, los conceptos básicos que se han abordado a lo largo del desarrollo de la metodología para la gestión de requisitos bajo la Arquitectura Orientada
Más detalles1 EL SISTEMA R/3 DE SAP AG
1 EL SISTEMA R/3 DE SAP AG SAP AG es una corporación en el ámbito mundial. Fundada en 1972 y con sede en Walldorf, Alemania, SAP es la cuarta compañía mundial en ventas de software en el mundo. La compañía
Más detallesComponentes 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 detallesArquitectura Cliente/Servidor
Arquitectura Cliente/Servidor Claudio Cubillos Escuela de Ingeniería Informática Pontificia Universidad Católica de Valparaíso, Chile claudio.cubillos@ucv.cl Arquitectura cliente/servidor v Servidor: rol
Más detallesCAPÍTULO 2 Sistemas De Base De Datos Multiusuarios
CAPÍTULO 2 Sistemas De De Multiusuarios Un sistema multiusuario es un sistema informático que da servicio, manera concurrente, a diferentes usuarios mediante la utilización compartida sus recursos. Con
Más detallesPORTAL DE INTEGRACIÓN DE BANCOS DE INFORMACIÓN DISPERSOS A TRAVÉS DE WEB SERVICES Autor: Ing. Walther Antonioli Ravetto
PORTAL DE INTEGRACIÓN DE BANCOS DE INFORMACIÓN DISPERSOS A TRAVÉS DE WEB SERVICES Autor: Ing. Walther Antonioli Ravetto Introducción: Sobre casi cualquier tema del quehacer humano que se aborde, existen
Más detallesGerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta
Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración
Más detallesCapítulo VI. Estudio de Caso de Aplicación del Integrador de Información Desarrollado
Capítulo VI Estudio de Caso de Aplicación del Integrador de Información Desarrollado 6.1 Organización elegida La Organización elegida para el caso de aplicación, es la empresa CTM Tours del grupo Costamar,
Más detalles2.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 detallesComunicación entre procesos
Comunicación entre procesos Patrones de comunicación Comunicación cliente-servidor En la que los mensajes de petición y respuesta proporcionan la base para la invocación remota de métodos o de procedimientos.
Más detallesWindows Server 2003. Windows Server 2003
Windows Server 2003 Windows Server 2003 Es un sistema operativo de la familia Windows de la marca Microsoft para servidores que salió al mercado en el año 2003. Está basada en tecnología NT y su versión
Más detallesDescripción. Este Software cumple los siguientes hitos:
WWWMONITORDBACOM Descripción Este Software cumple los siguientes hitos: a- Consola de Monitoreo b- Envío de Alertas (correo, SMS) c- Gestión de Eventos desatendidos (sea capaz ejecutar script de solución
Más detallesAutenticación Centralizada
Autenticación Centralizada Ing. Carlos Rojas Castro Herramientas de Gestión de Redes Introducción En el mundo actual, pero en especial las organizaciones actuales, los usuarios deben dar pruebas de quiénes
Más detallesservicios. 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 detallesWindows Server 2012: Identidad y Acceso. Módulo 2: Descripción General de Windows Server 2012 Remote Desktop Services.
Windows Server 2012: Identidad y Acceso Módulo 2: Descripción General de Windows Server 2012 Remote Desktop Services. Manual del Módulo Autor: Andrew J Warren, Content Master Publicado: Septiembre 10 de
Más detallesLINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN
LINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN Tabla de Contenidos LINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN... 1 Tabla de Contenidos... 1 General... 2 Uso de los Lineamientos Estándares...
Más detallesEn los últimos años, se ha presentado una enorme demanda por servicios portátiles,
Capítulo 1 Introducción En los últimos años, se ha presentado una enorme demanda por servicios portátiles, a los que se les ha llamado tecnologías móviles, este repentino crecimiento de tecnologías ha
Más detallesGenerador 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 detallesUNIVERSIDAD TECNOLOGICA ECOTEC DIEGO BARRAGAN MATERIA: Sistemas Operativos 1 ENSAYO: Servidores BLADE
UNIVERSIDAD TECNOLOGICA ECOTEC DIEGO BARRAGAN MATERIA: Sistemas Operativos 1 ENSAYO: Servidores BLADE AÑO: 2010 Qué es un servidor Blade? Blade Server es una arquitectura que ha conseguido integrar en
Más detallesArquitectura. 1.- Aplicaciones Web. Definición. Arquitectura clásica. Contenidos. 1.- Aplicaciones Web
Arquitectura 1.- Aplicaciones Web Definición Contenidos 1.- Aplicaciones Web 2.- Arquitectura de aplicaciones Web Lo que distingue una aplicación Web de una mero sitio Web reside en la posibilidad que
Más detallesINTRANET DE UNA EMPRESA RESUMEN DEL PROYECTO. PALABRAS CLAVE: Aplicación cliente-servidor, Intranet, Área reservada, Red INTRODUCCIÓN
INTRANET DE UNA EMPRESA Autor: Burgos González, Sergio. Director: Zaforas de Cabo, Juan. Entidad colaboradora: Colegio de Ingenieros del ICAI. RESUMEN DEL PROYECTO El proyecto consiste en el desarrollo
Más detallesPRACTICA CAPITULO 2 MODULO 1 PROTOCOLOS Y LA FUNCIONALIDAD DE LA CAPA DE APLICACIÓN
PRACTICA CAPITULO 2 MODULO 1 PROTOCOLOS Y LA FUNCIONALIDAD DE LA CAPA DE APLICACIÓN Los protocolos de capa de aplicación de TCP/IP más conocidos son aquellos que proporcionan intercambio de la información
Más detallesBASE DE DATOS RELACIONALES
BASE DE DATOS RELACIONALES Una base de datos relacional es una base de datos que cumple con el modelo relacional, el cual es el modelo más utilizado en la actualidad para implementar bases de datos ya
Más detallesUnidad III. Software para la administración de proyectos.
Unidad III Software para la administración de proyectos. 3.1 Herramientas de software para administrar proyectos. El software de administración de proyectos es un concepto que describe varios tipos de
Más detallesUNIVERSIDAD DE SALAMANCA
UNIVERSIDAD DE SALAMANCA FACULTAD DE CIENCIAS INGENIERÍA TÉCNICA EN INFORMÁTICA DE SISTEMAS Resumen del trabajo práctico realizado para la superación de la asignatura Proyecto Fin de Carrera. TÍTULO SISTEMA
Más detallesCapítulo VI. Conclusiones. En este capítulo abordaremos la comparación de las características principales y
Capítulo VI Conclusiones En este capítulo abordaremos la comparación de las características principales y de las ventajas cada tecnología Web nos ofrece para el desarrollo de ciertas aplicaciones. También
Más detallesEl presente documento describe la importancia que está tomando el cómputo distribuido en
INTRODUCCIÓN El presente documento describe la importancia que está tomando el cómputo distribuido en los sistemas de administración integral o empresarial. Con un prototipo particular, mostraremos como
Más detallesCapas del Modelo ISO/OSI
Modelo ISO/OSI Fue desarrollado en 1984 por la Organización Internacional de Estándares (ISO), una federación global de organizaciones que representa aproximadamente a 130 países. El núcleo de este estándar
Más detallesIntroducción. Metadatos
Introducción La red crece por momentos las necesidades que parecían cubiertas hace relativamente poco tiempo empiezan a quedarse obsoletas. Deben buscarse nuevas soluciones que dinamicen los sistemas de
Más detallesdesarrollo. 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 detallesSISTEMAS 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 detallesCapítulo 2. Planteamiento del problema. Capítulo 2 Planteamiento del problema
Capítulo2 Planteamientodelproblema 38 2.1Antecedentesycontextodelproyecto En lo que respecta a los antecedentes del proyecto, se describe inicialmente el contexto donde se utiliza el producto de software.
Más detallesInfraestructura Tecnológica. Sesión 5: Arquitectura cliente-servidor
Infraestructura Tecnológica Sesión 5: Arquitectura cliente-servidor Contextualización Dentro de los sistemas de comunicación que funcionan por medio de Internet podemos contemplar la arquitectura cliente-servidor.
Más detallesCAPÍTULO 1 Instrumentación Virtual
CAPÍTULO 1 Instrumentación Virtual 1.1 Qué es Instrumentación Virtual? En las últimas décadas se han incrementado de manera considerable las aplicaciones que corren a través de redes debido al surgimiento
Más detallesWindows Server 2012: Infraestructura de Escritorio Virtual
Windows Server 2012: Infraestructura de Escritorio Virtual Módulo 1: Application Virtualization Módulo del Manual Autores: James Hamilton-Adams, Content Master Publicado: 5 de Octubre 2012 La información
Más detallesUtilizar 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 detallesFamilia 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 detallesCAPITULO IV. HERRAMIENTAS DE CÓDIGO ABIERTO
CAPITULO IV. HERRAMIENTAS DE CÓDIGO ABIERTO En la actualidad la mayoría de las grandes empresas cuentan con un sin número de servicios que ofrecen a sus trabajadores y clientes. Muchos de estos servicios
Más detallesService Oriented Architecture
Programación Concurrente y Distribuida Ingeniería en Informática Service Oriented Architecture José Carlos Cortizo Pérez josecarlos.cortizo@uem.es http://www.esp.uem.es/jccortizo D. Sistemas Informáticos
Más detallesTécnico y sus funciones. 5. Función de los líderes. 6 Función del analista de datos. 6. Metas del Help Desk. 7 Definir el alcance del Help Desk.
3 Qué es un Help Desk? 3 Cómo trabaja un Help Desk? 3 Cómo se mide el éxito de un Help Desk? 5 Funciones de los miembros del equipo del Help Desk. 5 Técnico y sus funciones. 5 Función de los líderes. 6
Más detallesSeminario Electrónico de Soluciones Tecnológicas sobre VPNs de Extranets
Seminario Electrónico de Soluciones Tecnológicas sobre VPNs de Extranets 1 de 12 Seminario Electrónico de Soluciones Tecnológicas sobre VPNs de Extranets 3 Bienvenida. 4 Objetivos. 5 Interacciones de Negocios
Más detallesFuente: http://www.kzgunea.net
APRENDE A NAVEGAR SERVICIOS DE INTERNET Internet es como el mercado del pueblo en día de feria. En el mercado los puestos se organizan por secciones: por un lado la fruta, por otro las hortalizas, por
Más detallesCAPÍTULO I. Sistemas de Control Distribuido (SCD).
1.1 Sistemas de Control. Un sistema es un ente cuya función es la de recibir acciones externas llamadas variables de entrada que a su vez provocan una o varias reacciones como respuesta llamadas variables
Más detallesVisió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 detallesCURSO COORDINADOR INNOVADOR
CURSO COORDINADOR INNOVADOR PRESENTACIÓN La tarea que el Ministerio de Educación se propone a través de Enlaces, en relación al aseguramiento del adecuado uso de los recursos, con el fin de lograr un impacto
Más detallesTema 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 detallesResumen. El rol del lenguaje SQL en los SGBDR y en la Relacional. cjimenez@inf.udec.cl, tamrstro@inf.udec.cl
El rol del lenguaje SQL en los SGBDR y en la Relacional. cjimenez@inf.udec.cl, tamrstro@inf.udec.cl Resumen demandas de almacenamiento y procesamiento de datos. Es el conjunto de estas dos capacidades
Más detallesCAPITULO 8. Planeamiento, Arquitectura e Implementación
CAPITULO 8 Planeamiento, Arquitectura e Implementación 8.1 Replicación en SQL Server La replicación es un conjunto de tecnologías destinadas a la copia y distribución de datos y objetos de base de datos
Más detallese-commerce, es hacer comercio utilizando la red. Es el acto de comprar y vender en y por medio de la red.
Comercio electrónico. (e-commerce) Las empresas que ya están utilizando la red para hacer comercio ven como están cambiando las relaciones de la empresa con sus clientes, sus empleados, sus colaboradores
Más detalles5.1 Introducción a Servicios Web
5.1 Introducción a Servicios Web Introducción Continuando con el ejemplo de intercambio de información de películas... => Actualmente ya no es necesario implementar la solución sugerida a mano Se han estandarizado
Más detalles1.1.- Objetivos de los sistemas de bases de datos 1.2.- Administración de los datos y administración de bases de datos 1.3.- Niveles de Arquitectura
1. Conceptos Generales 2. Modelo Entidad / Relación 3. Modelo Relacional 4. Integridad de datos relacional 5. Diseño de bases de datos relacionales 6. Lenguaje de consulta estructurado (SQL) 1.1.- Objetivos
Más detallesObjetos educativos y estandarización en e-learning: Experiencias en el sistema <e-aula>
Objetos educativos y estandarización en e-learning: Experiencias en el sistema Fernández-Manjón, B.1, López Moratalla, J.2 Martínez Ortiz, I. 2, Moreno Ger, P. 2 Universidad Complutense de Madrid,
Más detallesGUIA SOBRE LOS REQUISITOS DE LA DOCUMENTACION DE ISO 9000:2000
1 INTRODUCCIÓN Dos de los objetivos más importantes en la revisión de la serie de normas ISO 9000 han sido: desarrollar un grupo simple de normas que sean igualmente aplicables a las pequeñas, a las medianas
Más detallesUnidad II. Interfaz Grafica (continuación ) Basado en clases de Ing. Carlos A. Aguilar
Clase:005 1 Unidad II Interfaz Grafica (continuación ) Basado en clases de Ing. Carlos A. Aguilar 2 Agenda Desarrollo de Apps para Android Aplicaciones en Android Componentes Básicos de las Aplicaciones
Más detallesUtilidades de la base de datos
Utilidades de la base de datos Desde esta opcion del menú de Access, podemos realizar las siguientes operaciones: Convertir Base de datos Compactar y reparar base de datos Administrador de tablas vinculadas
Más detallesSISTEMAS DE INFORMACIÓN I TEORÍA
CONTENIDO: TIPOS DE SI: SISTEMAS DE AUTOMATIZACIÓN DE OFICINAS, GROUPWARE, SISTEMA DE WORKFLOW Material diseñado y elaborado por: Prof. Anna Cecilia Grimán SISTEMAS DE AUTOMATIZACIÓN DE OFICINAS Los Sistemas
Más detallesApp para realizar consultas al Sistema de Información Estadística de Castilla y León
App para realizar consultas al Sistema de Información Estadística de Castilla y León Jesús M. Rodríguez Rodríguez rodrodje@jcyl.es Dirección General de Presupuestos y Estadística Consejería de Hacienda
Más detallesContacto Lespade, Juan Pablo jplespa@infovia.com.ar Dirección: Las Heras 490 Luján (B6700ATJ) Buenos aires Argentina Tel: ++54-2323-434791
Teleinformática Y Redes Trabajo Práctico de Investigación Redes compañero a compañero como soporte de sistemas de archivos distribuidos Lespade, Juan Pablo jplespa@infovia.com.ar División Estadística y
Más detallesSistemas 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 detallesPROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso
PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer
Más detallesBASES DE DATOS OFIMÁTICAS
BASES DE DATOS OFIMÁTICAS Qué es una Bases de Datos Ofimática?. En el entorno de trabajo de cualquier tipo de oficina ha sido habitual tener un archivo con gran parte de la información necesaria para el
Más detallesVISIÓ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 detallesSistema informatizado de Trazabilidad alimentaria
Universdad de Oviedo Trazabilidad Alimentaria Según el reglamento europeo, todas las empresas del sector alimentario han de tener un control de la trazabilidad alimentaria. La forma más eficiente, segura,
Más detallesMANUAL COPIAS DE SEGURIDAD
MANUAL COPIAS DE SEGURIDAD Índice de contenido Ventajas del nuevo sistema de copia de seguridad...2 Actualización de la configuración...2 Pantalla de configuración...3 Configuración de las rutas...4 Carpeta
Más detallesPlataforma desarrollo Java Formación elearning tutorizada en castellano. Fabricante: Java Grupo: Desarrollo Subgrupo: Master Java
C/Comandante Zorita 4 28020 Madrid/ info@ceticsa.es 902 425 524 / 91 700 01 17 Plataforma desarrollo Java Formación elearning tutorizada en castellano JAVA00d Ciclo de formación en plataforma Java Curso
Más detallesOfrezca la nueva tendencia de innovación empresarial con un entorno de red abierta
Descripción general de la solución Ofrezca la nueva tendencia de innovación empresarial con un entorno de red abierta Lo que aprenderá A medida que tecnologías como la nube, la movilidad, los medios sociales
Más detallesSoluciones innovadoras para optimizar su infraestructura TI. Virtualización con el sistema operativo i, PowerVM y Power Systems de IBM
Soluciones innovadoras para optimizar su infraestructura TI Virtualización con el sistema operativo i, PowerVM y Power Systems de IBM Características principales Tenga éxito en su negocio simplemente con
Más detallesProceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:
PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo
Más detallesLa Pirámide de Solución de TriActive TRICENTER
Información sobre el Producto de TriActive: Página 1 Documento Informativo La Administración de Sistemas Hecha Simple La Pirámide de Solución de TriActive TRICENTER Información sobre las Soluciones de
Más detallesServicios de impresión y de archivos (Windows 2008) www.adminso.es
Servicios de y de archivos (Windows 2008) www.adminso.es Servicios de y archivos (w2k8) COMPARTIR ARCHIVOS E IMPRESORAS Servicios de y archivos (w2k8) Los servicios de y de archivos permiten compartir
Más detallesDIPLOMADO EN SEGURIDAD INFORMATICA
DIPLOMADO EN SEGURIDAD INFORMATICA Modulo 9: Soporte Computacional Clase 9_3:Protocolos de comunicación y conectividad de arquitecturas multiplataforma. Director Programa: César Torres A Profesor : Claudio
Más detallesModificación y parametrización del modulo de Solicitudes (Request) en el ERP/CRM Compiere.
UNIVERSIDAD DE CARABOBO FACULTAD DE CIENCIA Y TECNOLOGÍA DIRECCION DE EXTENSION COORDINACION DE PASANTIAS Modificación y parametrización del modulo de Solicitudes (Request) en el ERP/CRM Compiere. Pasante:
Más detallesResumen de la solución SAP SAP Technology SAP Afaria. Gestión de la movilidad empresarial para mayor ventaja competitiva
de la solución SAP SAP Technology SAP Afaria Gestión de la movilidad empresarial para mayor ventaja competitiva Simplificar la gestión de dispositivos y aplicaciones Simplificar la gestión de dispositivos
Más detallesRBAC4WFSYS: Modelo de Acceso para Sistemas Workflow basado en RBAC
RBAC4WFSYS: Modelo de Acceso para Sistemas Workflow basado en RBAC Proyecto Integrador de Tecnologías Computacionales Autor: Roberto García :: A00888485 Director: Jorge A. Torres Jiménez Contenido Introducción
Más detalles