ORIENTACIONES PARA LA SELECCIÓN DE TECNOLOGÍAS DE INTEGRACIÓN DE SISTEMAS DE SOFTWARE

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

Download "ORIENTACIONES PARA LA SELECCIÓN DE TECNOLOGÍAS DE INTEGRACIÓN DE SISTEMAS DE SOFTWARE"

Transcripción

1 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 de Procesos y Sistemas, Universidad Simón Bolívar. Apartado Postal 89000, Caracas 1080-A. Caracas Venezuela. Telef.: +58 (212) / 3328 / 3314 / Fax: +58 (212) / {movalles, lmendoza, RESUMEN Es frecuente encontrar en las organizaciones de hoy lo que se denominan islas de información, a pesar que ellas llegaron en algún momento a satisfacer necesidades específicas del negocio, provocaron la fragmentación de las aplicaciones, a la vez que no cumplen con los objetivos y las estrategias del negocio. Los Sistemas de Software (SS) han evolucionado dando origen al concepto de Integración de Sistemas como respuesta a esta problemática. Esto ha generado que exista en el mercado una amplia gama de tecnologías para la integración de los sistemas. El objetivo de esta investigación en progreso, es orientar a los Ingenieros de Software en la selección más adecuada de estas tecnologías, al momento de conformar un Portafolio de Proyectos de Integración de Sistemas. Palabras Claves: Integración de Sistemas de Software, Tecnologías para la integración, Proyectos de software, Middleware, Portafolio. INTRODUCCIÓN En el siglo XXI la integración de la información corporativa resulta obvia: las organizaciones sin información integrada simplemente no están en capacidad de responder como una corporación. Alter define la integración como la conexión y la colaboración mutua entre actividades o procesos; lo que sugiere que la integración es más que una actividad simple de unir partes; la integración debe permitir que esas partes se unan de forma coherente [1]. En el ámbito organizacional actual, el término integración posee dos vertientes importantes y estrechamente relacionadas: la integración del negocio y la integración de los Sistemas de Software (SS); esta relación llega a ser tan fuerte que Markus [11] señala que la falta de integración de sistemas puede impedir la integración del negocio, o dicho en otros términos, la integración de sistemas es necesaria para la integración del negocio. La integración del negocio se refiere a la creación de actividades de negocio coordinadas, manejada por diferentes personas, en grupo o por organizaciones, de modo de formar un proceso de negocio unificado. La integración del negocio requiere de procesos de negocio "fluidos" y SS integrados capaces de combinar informaciones provenientes de muchas fuentes [11]. La integración de SS significa que los SS se combinan o fusionan dentro de una facilidad, en lugar de tener hardware, software y comunicación independiente. Además, permite derribar las barreras entre las unidades de la organización y reduce la duplicación de esfuerzos [20]. Sandoe señala que integrar SS no es tarea fácil dada la gran cantidad de factores involucrados y los riesgos financieros debido a la inversión necesaria en tiempo y recursos [17]. De forma similar, Bednar se refiere a los proyectos de integración de SS como desafiantes, ya que por su complejidad resultan proyectos costosos, lo que hace necesario invertir tiempo, dinero y comprometer a la organización en todos sus niveles [5]. Estos proyectos deben ser pensados tomando en cuenta que actualmente existe en el mercado una amplia gama de tecnologías para la integración de SS; se puede notar cómo diferentes proveedores ofrecen para este propósito, servicios y productos los cuales se traducen en proyectos a desarrollar. Lo anterior permite deducir que no es fácil formalizar un Portafolio de Proyectos de integración, ni decidir cuál debe ser la tecnología más apropiada. La meta de esta investigación que está en progreso es proponer un método que sistematice la formulación de este Portafolio. Es por ello que, el objetivo de este artículo es orientar la selección de estas tecnologías con el fin de conformar el Portafolio de Proyectos de Integración de SS acorde con las necesidades y limitaciones de una organización que desee alcanzar cierto Nivel de Integración. Este artículo comienza por definir brevemente lo que se conoce por Portafolio de Proyectos de Integración como alternativa para manejar la complejidad de la integración, de modo de garantizar coherencia entre los proyectos que lo conforman a

2 la vez que se encuentran alineados con los objetivos de la organización. Luego, se describen los Niveles de Integración para introducir el concepto de Enterprise Application Integration (EAI) y con ello, los Middleware y su categorización y posteriormente, apoyado en lo anterior, presentar la orientación basada en escenarios y en las tecnologías ofrecidas para este tipo de proyectos. Finalmente, se cierra con las conclusiones más relevantes. PORTAFOLIO DE PROYECTOS DE INTEGRACIÓN DE SISTEMAS DE SOFTWARE Para Alter, un Proyecto de Sistemas es aquel cuya meta inmediata es construir o modificar SS. Estos proyectos se declaran terminados cuando el sistema satisface las necesidades y es aceptado por los usuarios y/o gerentes [1]. Por otro lado, el conjunto particular de proyectos de SS definidos por los Proyectos de Integración de Sistemas, corresponde a aquellos cuyo fin no es el desarrollo de una aplicación, si no la puesta en relación y funcionamiento de un conjunto heterogéneo de componentes para conseguir una solución global que responda a una necesidad del usuario [21]. McKeen señala que la presión de la competencia y la demanda de los clientes dan a las organizaciones pocas opciones para la innovación. Dentro de las TI, el desafío de innovación es manejar una cartera o portafolio de proyectos enlazados de modo que soporte las necesidades del negocio en una manera efectiva a nivel de costos [13]. Los proyectos de desarrollo de SS son significativamente diferentes a los proyectos de integración de SS, ya que los primeros proponen soluciones tácticas a un problema definido probablemente por un departamento especifico, mientras que los proyectos de integración, proponen soluciones que involucran el reuso dinámico de las aplicaciones de la empresa, con especial énfasis sobre el soporte estratégico del modelo de negocio [6]. Estos proyectos están relacionados con el Nivel de Integración que tiene la empresa y el nivel que se desea obtener; en otras palabras, es necesario identificar dónde está la empresa y hacia dónde quiere ir para poder determinar el Portafolio de Proyectos de Integración de Sistemas que le permita lograrlo. En el siguiente punto se describen los Niveles de Integración propuestos por Schmidt [18]. NIVELES DE INTEGRACIÓN Los Niveles de Integración permiten establecer Proyectos de Integración de Sistemas al definir cómo está la empresa y hasta dónde quiere llegar, lo que permitirá identificar la estrategia a utilizar. Schmidt [18] define los niveles como el grado de cooperación o compatibilidad mutua entre actividades o procesos distintos y establece cuatro, a saber: 1. Nivel 1: Integración Punto a Punto. Representa el nivel más pobre de integración, ya que las tecnologías utilizadas se comunican a través de interfaces intermedias donde no se contempla la visión del negocio; es decir, establece una infraestructura básica para el intercambio de datos entre aplicaciones. La interrelación entre los sistemas es baja, por lo que tienen un alto grado de independencia. 2. Nivel 2: Integración Estructural. A este nivel, la empresa usa tecnología Middleware para estandarizar y controlar el intercambio de información. Deben tomarse en cuenta dos aspectos: (1) existe una estructura central que controla el intercambio de información; y (2) a nivel de Middleware se consolidan las reglas de negocio y las transacciones entre las aplicaciones. En este nivel, las organizaciones cuentan con interfaces integradas y fuentes de datos comunes, pero no se integra con componentes externos del negocio. 3. Nivel 3: Integración de Procesos. A este nivel, la organización ya ha logrado la transición de compartir la información entre aplicaciones para manejar en realidad el flujo de información entre las aplicaciones. Para conseguirlo, han desarrollado un modelo de negocio común que cubre la totalidad de la empresa. Utiliza tecnología sofisticada para poner en práctica el modelo de negocio en la capa Middleware. Existe gran integración en este nivel, debido a que se toman en cuenta las reglas de negocio y el flujo de procesos. 4. Nivel 4: Integración Externa. Las compañías en este nivel están considerando las verdaderas aplicaciones empresariales, la influencia tecnológica, la transformación de los procesos de negocio y las nuevas estructuras, para redefinir la organización desde el punto de vista de servir a los clientes. Estas organizaciones usan tecnologías de EAI para transformar el negocio, a menudo uniendo directamente a clientes y proveedores para operaciones internas. Estas compañías contemplan nuevas capacidades para crear innovadoras ofertas en línea, nuevos productos y servicios, y pueden mejorar una marca registrada o crear una nueva identidad en Internet.

3 Por las características de este nivel, la compañía es rápida, flexible y satisface la dinámica del mercado actual. Estos niveles propuestos por Schmidt están orientados a las TI, donde el paso de un nivel a otro significa una evolución por parte de la empresa en lo que respecta a integración. Por otro lado, un intento por reducir la complejidad en la formulación del portafolio de este tipo de proyectos y ofrecer una alternativa a la empresa para obtener una evolución de nivel, se plantea con el concepto de EAI; que según McKeen, se define como los planes, métodos, herramientas de apoyo a la modernización, consolidación, integración y coordinación de los SS dentro de la organización [12]. Adicionalmente, McKeen añade el concepto de EAI Middleware refiriéndose a los SS que habilitan directamente interacciones entre aplicaciones independientemente diseñadas en un entorno distribuido [12]. Lo anterior se debe a que EAI Middleware posee una arquitectura que mejora la comunicación, añade conectividad y proporciona seguridad [19]. TECNOLOGÍA MIDDLEWARE Sumathi señala que tradicionalmente la integración de sistemas era punto a punto (P2P); sin embargo, este enfoque requiere de grandes esfuerzos que se ven incrementados por el número de SS que se desean integrar, además de causar pérdidas en la integridad de datos [19]. 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 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 [2]. Mas formalmente, y a efectos de este artículo, se define Middleware, como la capa de software que se coloca entre el usuario y el entorno distribuido, abstrayendo al usuario 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 en distintos lenguajes de programación, sistemas operativos y plataformas [13]. En otras palabras, engloba los elementos que permiten la comunicación entre los sistemas. Como puede verse, no existe una diferencia significativa entre los conceptos de EAI Middleware y Middleware, dado que ambos conceptos hacen referencia a los SS que soportan la interconexión, la intercomunicación y la interacción entre aplicaciones heterogéneas; por lo tanto, para los fines de este artículo se van a manejar indistintamente estos conceptos, haciéndose sólo a Middleware para referirse a esta tecnología. 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 [2] 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 [2], 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 [3], Creamer [7] y Jones [9]. 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.

4 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 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. Algunos productos que proporcionan Middleware para procesamiento de transacciones son: BEA Tuxedo, Transarc's Encina y CICS de IBM. 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

5 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. Aquí se encuentran, por ejemplo, Internet Information Servers (IIS), TOMCAT, Apache, Oracle9i Application Server, IBM WebSphere Application Server. Como se aprecia, las tecnologías Middleware fundamentalmente dependen de los mecanismos que permiten la comunicación entre 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 [3]. Entonces, cuál de las tecnologías descritas es la apropiada?, la respuesta a esta pregunta no es trivial, a continuación se dan orientaciones que implican la formulación de un Portafolio de Proyectos de Integración de Sistemas. ORIENTACIÓN EN LA SELECCIÓN DE TECNOLOGÍAS MIDDLEWARE En este punto se presentan algunas consideraciones útiles para orientar al ingeniero de software en la formulación del Portafolio de Proyectos de Integración tomando en cuenta los Niveles de Integración y los tipos de tecnologías antes descritos. Con el propósito de visualizar mejor su aplicabilidad se identificaron las ventajas y las desventajas de estas tecnologías Middleware, las cuales se resumen en la Tabla 1 y se basan en lo expresado en [2,3,4,8,10,14,15,16]. Tabla 1. Ventajas y Desventajas de los Middleware. Adaptado de [2,3,4,8,10,14,15,16]. MIDDLEWARE VENTAJAS DESVENTAJAS DT Permite compartir datos entre aplicaciones, con poco impacto en el rendimiento. Provee un modelo poderoso para manejar sistemas de objetos distribuidos RPC MOM DOM CORBA Por ser el primer tipo de Middleware es el menos complicado de usar y comprender. Por ser síncrono, provee mayor integridad de datos. 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 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.

6 RMI DCOM TP Monitors DBAT COF DS AS Gracias a la máquina virtual Java soporta multiplataforma. Soporta multilenguaje. Ú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. 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. Sólo para objetos Java. Especialmente diseñado para trabajar sobre sistemas operativos de Microsoft. No son útiles para el intercambio de información. Puede resultar mas lento, el intercambio entre la aplicación y a 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. Se utilizan sólo en ambientes multicapas (actualmente, es el caso de la mayoría de los ambientes) Al analizar la Tabla 1 y las definiciones antes mencionadas, se puede decir que no es posible hacer una comparación entre estos tipos de Middleware, 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 Middleware pueden coexistir; es decir, no son excluyentes. Aún más, existen tipos que están estrechamente relacionados, sobre todo si pertenecen al mismo fabricante. Sin embargo, las comparaciones son posibles entre tipos de tecnologías Middleware que se basan en el mismo paradigma. Con base en la reflexión anterior, los niveles de integración definidos por Schmidt [18] y tomando en cuenta la información de la Tabla 1 con algunas consideraciones planteadas por los autores antes mencionados, se describen varios escenarios y las orientaciones propuestas para decidir sobre la tecnología Middleware apropiada. Cabe señalar que tal como se mencionó anteriormente, el paso de un nivel a otro puede representar una evolución tecnológica por parte de la empresa; por lo tanto, algunas tecnologías Middleware que propician en mayor medida el nivel 2, por ejemplo, pueden estar presentes en niveles superiores, aún cuando no apoyen dicho nivel directamente, sino mas bien a alguna otra tecnología que si soporta directamente a dicho nivel. El nivel 1 no contempla la presencia de tecnología Middleware; sin embargo, en muchas aplicaciones es frecuente el uso de DBAT para comunicarse con las bases de datos. 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 en disco 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.

7 Los DT pueden estar en los niveles 2, 3 y 4, dependiendo como se combine con otras tecnologías, debido a que por si solo se ubica en el Nivel 2. Si entre los sistemas que se desean integrar existe alguno heredado del cual no se posee código fuente, la posibilidad de integració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. Nuevamente, lo anterior implica que la empresa estará en el Nivel 2. Para alcanzar el Nivel 3 se debería obtener una integración que involucre los procesos del negocio, lo cual es posible si se utilizan 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 presente en la empresa, de manera que la primera sugerencia es trabajar usando tecnología del mismo fabricante. Además, se debe considerar si los sistemas de software 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 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+ (con.net), 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. Por su parte, el Nivel 4 requiere integración externa. En este caso, conviene evitar el uso de RPC, debido al alto consumo de procesamiento que requiere, 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 integración: datos, procesos o ambos). Sin embargo, actualmente la tendencia en aplicaciones e-commerce, es usar MOM debido a que permite una comunicación asíncrona entre aplicaciones de software. 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 Información. Las tecnologías como TPM y para manejo de base de datos, son posibles en los niveles 3 y 4. Sin embargo, TPM propicia en mayor medida el nivel 3 (debido a las funciones que realiza y su alto costo). Los TPM son especialmente empleados en los sistemas 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 (tal vez de luz o conexión) sea posible tomar acciones, las cuales generalmente revierten la transacción. Los grandes sistemas (por ejemplo bancarios) se encuentran en plataforma UNIX, lo que imposibilita el uso de componentes Microsoft, debido a que no son multiplataforma. Los API de base datos se pueden incorporar en cualquier Nivel de Integración para comunicar las aplicaciones con la base de datos, en este caso la recomendación sigue siendo mantener la plataforma utilizada en la empresa. Debido a la flexibilidad que ofrecen las tecnologías Middleware como DOM, ellas pueden propiciar además del nivel 3 (como se mencionó anteriormente) los niveles 2 y 4. Las consideraciones de uso de COF dependen nuevamente de la plataforma. Ahora bien, en sistemas altamente distribuidos (sobre todo si estamos en nivel 4) 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. Por estar esta tecnología estrechamente relacionada con DOM, de la misma manera puede apoyar los niveles 2, 3 y 4. Los Middleware tipo DS son fundamentales en una red moderna, debido a que los servicios que proporcionan permiten identificar y administrar las relaciones entre todos los elementos de la red. En ese sentido, y aunque su funcionalidad puede extenderse, es posible encontrarlo a partir del nivel 2. Los Middleware AS se utilizan principalmente en aplicaciones WEB, las cuales se ubican regularmente en los

8 Niveles 3 y 4. La Tabla 2 refleja un resumen de lo anteriormente expuesto, donde de manera matricial se presentan, a través de las zonas sombreadas, los niveles versus los tipos de tecnologías Middleware que los soportan. La aparición del sombreado en una celda significa que la tecnología en cuestión soporta la meta de integración de ese nivel. Finalmente, de la tabla 2 se puede concluir que: Los Niveles más altos de integración se apoyan en el enfoque OO, debido a que ofrecen mayor portabilidad y pueden utilizar las tecnologías existentes (lo que facilita la integración externa) y poseen mecanismos que apoyan la comunicación, los datos y los procesos. Por su parte, MOM facilita la integración externa, al ser flexible e independiente de los procesos internos de las organizaciones involucradas. Además se cuenta con estándares establecidos para el intercambio de información, tal como XML. En organizaciones grandes, como los bancos, la tendencia es el uso combinado de TMP y DT. DT por si solo ofrece una integración baja, pero combinada con otras tecnologías puede llegar incluso al Nivel 4. En sistemas altamente distribuidos y heterogéneos no se recomienda el uso de tecnología Microsoft aunque está por verse las facilidades multiplataforma que brinda.net y que solventaría esta limitación. DBAT es una tecnología de comunicación con la base de datos ampliamente usada desde hace mucho tiempo (puede ser visto como un estándar); sin embargo, por si sola no posiciona a la empresa en ninguno de los niveles de integración. Tabla 2. Matriz Nivel de Integración vs. Tecnología Middleware Tecnología DT RPC MOM DOM TPM DBAT COF DS AS Nivel CONCLUSIONES La selección apropiada de los proyectos que conforman el Portafolio de Proyectos de Integración de Sistemas y, por ende, las tecnologías que lo soportan, tiene una importancia significativa como estrategia de negocio. El portafolio de proyectos seleccionado para la integración de sistemas, debe estar conformado por aquellos proyectos que satisfagan los aspectos de comunicación requeridos según el Nivel de Integración que se aspire. Además, dicho portafolio no debe dejar de lado las estrategias del negocio. Es fundamental tener muy claro las tecnologías que sustentan las aplicaciones que se desean integrar, 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 EAI no sólo debe pensarse como mecanismo para comunicar los sistemas heredados con los sistemas modernos, sino que además puede extenderles la vida y mantener la integración con sistemas futuros. Es decir, para definir el Portafolio de Proyectos de Integración de Sistemas lo fundamental es que la organización conozca tecnológicamente lo que tiene, el nivel de integración actual y el nivel deseado, y por último, su visión del negocio. En estas orientaciones es posible detectar como los paradigmas Orientado a Objetos y de Componentes propician los niveles más altos de integración debido a la alta portabilidad que proporcionan. De igual manera, MOM (apoyado en tecnologías como XML) propicia el nivel 4 de integración. En el primer caso, los paradigmas mencionados apoyan

9 los procesos de negocios, mientras que en el segundo caso, MOM apoya a la integración externa a través de estándares para el envío de mensajes. La integración de sistemas es un proceso que podría no terminar nunca, la evolución tecnológica es constante; cada vez es mayor la necesidad de comunicarse con más fuentes de información, socios y clientes. Por lo tanto, la tendencia actual, es la integració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. Las orientaciones aquí propuestas apoyan y soportan al Ingeniero de Software en la formulación del Portafolio de Proyectos. El siguiente paso en esta investigación será sistematizar estas orientaciones en un método y evaluarlo con ayuda del estudio de un caso. AGRADECIMIENTOS Esta investigación 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 Se desea agradecer también el apoyo brindado por Manapro Consultores C.A. para la culminación de este trabajo. REFERENCIAS [1] Alter, S. (2002). Information Systems Foundation of E-Business. Prentice Hall. [2] Ariannejad (2001). Trends in Middleware Systems. Computer Engineering Research Group. Disponible en la dirección electrónica [3] Bakken, D. (2002). Middleware. Chapter in Encyclopedia of Distributed Computing, J. Urban and P. Dasgupta, eds., Kluwer Academic Publishers, [4] Basanta, D. y Tajes, L. (1999). Tecnologías para el Desarrollo de Sistemas Distribuidos: Java versus Corba. X Jornadas de Paralelismo. La Magna del Mar Menor, Murcia. [5] Bednar, E. (2002). Adapting to your Environment Self-Generating Adapters to Change EAI Landscape. Disponible en la dirección electrónica [6] Brown, L. (2002). Integration Models: Templates for Business Transformation. SAMS. [7] Creamer, M. EAI Middleware: Heterogeneous Computing Comes of Age. Enterprise System Journal. [8] Hawick, K., James, H., y Pritchard, L. (2002). Tuple-Space Based Middleware for Distributed Computing. Technical Report DHPC-128. [9] Jones, T. (2003). Middleware Options. Butler Group Concept Paper. [10] Lublinsky, B. (2001). Achieving the Ultimate EAI Implementation. Disponible en la dirección electrónica [11] Markus, L. (2000). Paradigm Shifts E-Business and Business/Systems Integration. Communications of the Association for Information Systems, 4(10). [12] McKeen J y Smith, H (2002). New Developments in Practice II: Enterprise Application Integration. Communications of the Association for Information Systems, 8(31). [13] McKeen J y Smith, H (2002). New Developments in Practice IV: Managing the Technology Portfolio. Communications of the Association for Information Systems, 9(5). [14] Randall, D, John Hughes, Jon O Brien, Tom Rodden, Mark Rouncefield, Ian Sommerville and Peter Tolmie Banking ontthe old Technology: Understanding the Organizational Context of Legacy Issues. Communications of the Association for Information Systems, 2(8). [15] Rinetti, G., y Rubio, M. (2001). Role of Middleware in Application Integration. T Enterprise Systems Integration, [16] Rogers State University. (1999). Middleware Technology. Emerging Technologies TECH [17] Sandoe K., Corbitt G., Boykin R. "Enterprise Integration". California State University, Chico. John Wiley & Sons, Inc [18] Schmidt, J. (2000). Enabling Next-Generation Enterprises. eaijournal, 2(7). [19] Sumathi, C. (2003). Spatial World Chants the EAI Mantra. Map India 2003 Poster Session. [20] Turban, E., Rainer, K., y Potter, R. (2001). Introduction to Information Tecnology. John Wiley & Sons, Inc. [21] Universidad Pontificia de Madrid. Departamento de O.E.I. Disponible en la dirección electrónica ficheros/transparencias/arquitectura.ppt

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

Estudio de Tecnologías Middleware para Sistemas Peer-to-Peer

Estudio de Tecnologías Middleware para Sistemas Peer-to-Peer 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

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

MÉTODO PARA SOPORTAR LA FORMULACIÓN DE UN PORTAFOLIO DE PROYECTOS DE INTEGRACIÓN

MÉTODO PARA SOPORTAR LA FORMULACIÓN DE UN PORTAFOLIO DE PROYECTOS DE INTEGRACIÓN MÉTODO PARA SOPORTAR LA FORMULACIÓN DE UN PORTAFOLIO DE PROYECTOS DE INTEGRACIÓN María Pérez, Luis E. Mendoza, Yorka Carvajal Laboratorio de Investigación en Sistemas de Información (LISI), Dpto. de Procesos

Más detalles

Gerencia 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 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 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

Arquitectura cliente/servidor

Arquitectura 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 detalles

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

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO

SERVICE 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 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

Permite compartir recursos en forma coordinada y controlada para resolver problemas en organizaciones multiinstitucionales

Permite compartir recursos en forma coordinada y controlada para resolver problemas en organizaciones multiinstitucionales The Anatomy of the Grid Enabling Scalable Virtual Organization Autores : Ian Foster, Carl Kesselman y Steven Tuecke. 2001 GRIDS y Organizaciones Virtuales Permite compartir recursos en forma coordinada

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

Arquitectura de Software

Arquitectura 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 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

Servicio Web. Estándares empleados. Ventajas de los servicios web. Inconvenientes de los servicios Web

Servicio Web. Estándares empleados. Ventajas de los servicios web. Inconvenientes de los servicios Web Servicio Web Un servicio web (en inglés, Web services) es una tecnología que utiliza un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones

Más detalles

UNIVERSIDAD CENTROCCIDENTAL "LISANDRO ALVARADO" DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS

UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS UNIVERSIDAD CENTROCCIDENTAL "LISANDRO ALVARADO" DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS MODELO DE GESTION WBEM PARA ADMINISTRACION DE REDES

Más detalles

Capítulo 5. Cliente-Servidor.

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 detalles

Modelos 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 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 detalles

Objetos Distribuidos - Componentes. Middleware

Objetos Distribuidos - Componentes. Middleware Objetos Distribuidos - Componentes Middleware Middleware Component Oriented Development Arquitecturas 3 Tier Middleware es el software que: conecta y comunica los componentes de una aplicacion distribuida

Más detalles

La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la

La 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 detalles

Uso de los Servicios Web en la nueva arquitectura de N-Capas del Sistema Económico Integral Rodas XXI.

Uso de los Servicios Web en la nueva arquitectura de N-Capas del Sistema Económico Integral Rodas XXI. Ponencia para Evento de Redes. Autor: Rubén Rivera Rodríguez, Citmatel Resumen Uso de los Servicios Web en la nueva arquitectura de N-Capas del Sistema Económico Integral Rodas XXI. Las nuevas tendencias

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

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

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

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

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

TEMA 5. Otras arquitecturas distribuidas II. Objetos distribuidos y CORBA

TEMA 5. Otras arquitecturas distribuidas II. Objetos distribuidos y CORBA TEMA 5. Otras arquitecturas distribuidas II. Objetos distribuidos y CORBA II. Objetos distribuidos y CORBA 1. Objetos Distribuidos 2. CORBA 1. Características 2. Modelo de trabajo 3. ORB 4. Arquitectura

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

MARCANDO LA DIFERENCIA

MARCANDO LA DIFERENCIA MARCANDO LA DIFERENCIA INTEGRACIÓN RÁPIDA Y CONFIABLE entre sus sistemas Simplifique la integración y el mantenimiento de su lógica de negocio con nuestra arquitectura orientada a servicios. Ahorre dolores

Más detalles

Implementación de Procesos Business Process Management BPM Services Oriented Architecture SOA

Implementación de Procesos Business Process Management BPM Services Oriented Architecture SOA Implementación de Procesos Business Process Management BPM Services Oriented Architecture SOA Título Área específica de la publicación 2 Implementación de Procesos Business Process Management BPM Services

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

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

CAPITULO 3 ARQUITECTURA DE COMPONENTES GIS EN INTERNET

CAPITULO 3 ARQUITECTURA DE COMPONENTES GIS EN INTERNET CAPITULO 3 ARQUITECTURA DE COMPONENTES GIS EN INTERNET 3.1- ARQUITECTURA DE COMPONENTES GIS La presente tesis trata del diseño y desarrollo de una aplicación basado en el Web para servir datos geográficos

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

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).

1 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 detalles

Introducció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 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 detalles

Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos. Unidad didáctica 1: Fase de análisis de requisitos Modelo E/R

Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos. Unidad didáctica 1: Fase de análisis de requisitos Modelo E/R índice Módulo A Unidad didáctica 1: Introducción a las Bases de Datos Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos 3 19 Módulo B Unidad didáctica 1: Fase de análisis de requisitos Modelo

Más detalles

Capítulo 7: Introducción a la dinámica de servicios Web

Capítulo 7: Introducción a la dinámica de servicios Web Servicios Web Capítulo 7: Introducción a la dinámica de servicios Web Pedro J. Álvarez alvaper@unizar.es José Ángel Bañares banares@unizar.es http://diis.unizar.es/postweb/ Departamento de Informática

Más detalles

Bases de Datos Especializadas

Bases de Datos Especializadas Bases de Datos Especializadas BASES DE DATOS ESPECIALIZADAS 1 Sesión No. 12 Nombre: DBMS y Tecnología Web Objetivo: Al término de la sesión, el alumno identificará la integración entre DBMS y la web. Contextualización

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

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

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS 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 detalles

6445 Implementing and Administering Windows Small Business Server 2008

6445 Implementing and Administering Windows Small Business Server 2008 6445 Implementing and Administering Windows Small Business Server 2008 Introducción Este taller práctico de cinco días impartido por instructor, provee a estudiantes con el conocimiento necesario para

Más detalles

Curso de Java EE Todos los Derechos Reservados Global Mentoring 2012 Experiencia y Conocimiento para tu Vida 1

Curso de Java EE Todos los Derechos Reservados Global Mentoring 2012 Experiencia y Conocimiento para tu Vida 1 Todos los Derechos Reservados Global Mentoring 2012 Experiencia y Conocimiento para tu Vida 1 Vivimos en un mundo globalizado, donde la eficiencia y productividad de las empresas es un factor crucial para

Más detalles

Nombre del documento: Programa de Estudio de asignatura de Especialidad. Referencia a la Norma ISO 9001:2008 7.3 Página 1 de 6

Nombre del documento: Programa de Estudio de asignatura de Especialidad. Referencia a la Norma ISO 9001:2008 7.3 Página 1 de 6 Referencia a la Norma ISO 9001:2008 7.3 Página 1 de 6 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura : Sistemas Distribuidos I Carrera: Ing. en Sistemas Computacionales Clave de la asignatura: RSD-1203

Más detalles

Introducción a las redes de computadores

Introducció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 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

Tema 1. Arquitectura Cliente/Servidor

Tema 1. Arquitectura Cliente/Servidor Tema 1. Arquitectura Cliente/Servidor SCS Sistemas Cliente/Servidor 4 o informática http://ccia.ei.uvigo.es/docencia/scs 27 de septiembre de 2009 FJRP, FMBR [sistemas cliente-servidor] CCIA 1.1 Sistemas

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

Análisis, Diseño e Implementación de un Sistema de. Alquiler de autos usando tecnología Cliente/Servidor con

Análisis, Diseño e Implementación de un Sistema de. Alquiler de autos usando tecnología Cliente/Servidor con Análisis, Diseño e Implementación de un Sistema de Alquiler de autos usando tecnología Cliente/Servidor con arquitectura CORBA AUTORES: Carolina Elizabeth Chang Herrera 1 Boris Hernán Montiel Rivera 2

Más detalles

1. Introducción: Qué es la Gestión Documental-TI o Gestor Documental?

1. Introducción: Qué es la Gestión Documental-TI o Gestor Documental? 1. Introducción: Qué es la Gestión Documental-TI o Gestor Documental? Es un tipo de Software o portal para la gestión de conocimiento en una Organización u empresa que se basa principalmente en la administración

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

UNIVERSIDAD ALBERT EINSTEIN FACULTAD DE INGENIERIA

UNIVERSIDAD ALBERT EINSTEIN FACULTAD DE INGENIERIA UNIVERSIDAD ALBERT EINSTEIN FACULTAD DE INGENIERIA Estudio de las herramientas TOAD y DBArtisan para la administración e integración de bases de datos relacionales. PREVIA OPCION AL TÍTULO DE: INGENIERO

Más detalles

El valor de una infraestructura optimizada

El valor de una infraestructura optimizada El valor de una infraestructura optimizada El Estudio del Estado del CIO 2006 (CIO Research, 2006) muestra que los CIO están buscando, cada vez más, introducir, de forma proactiva, soluciones de tecnología

Más detalles

Una propuesta arquitectónica para integrar una herramienta BPMS y un sistema de gestión de reglas de negocio. Contexto

Una propuesta arquitectónica para integrar una herramienta BPMS y un sistema de gestión de reglas de negocio. Contexto Una propuesta arquitectónica para integrar una herramienta BPMS y un sistema de gestión de reglas de negocio Parra Julián Matias 1, Mg. Patricia Bazán 2, Lic. José Martinez Garro 3 1 3 Facultad de Informática

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

Simulador de Protocolos de Red a tráves de WEB

Simulador de Protocolos de Red a tráves de WEB Simulador de Protocolos de Red a tráves de WEB Propuesta de Estudio 20071608 Director Ing. Francisco Antonio Polanco Montelongo Resumen Introducción Actualmente, el desarrollo tecnológico a alcanzado niveles

Más detalles

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE

PRUEBAS 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 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

SISTEMAS DE INFORMACIÓN III TEORÍA

SISTEMAS 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 detalles

Definición arquitectura cliente servidor

Definición arquitectura cliente servidor www.monografias.com Definición arquitectura cliente servidor 1. Introducción 2. Elementos principales 3. En resumen 4. Algunos antecedentes, Por qué fue creado? 5. Evolución de la arquitectura cliente

Más detalles

Arquitectura Cliente/Servidor

Arquitectura 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 detalles

Experiencias con J2EE

Experiencias con J2EE Experiencias con J2EE Carlos Luna García Project Manager J2EE carlos.luna@sistel.es Presentación corporativa (1)! Presentación de la compañía.» Sistel es una compañía de integración y desarrollo de sistemas

Más detalles

asired middleware XML Así-Red Servicios Telemáticos, S.L.L. w w w. a s i r e d. e s

asired middleware XML Así-Red Servicios Telemáticos, S.L.L. w w w. a s i r e d. e s w w w. a s i r e d. e s 1 INDICE Presentación Que nos permiten Sobre que actuan Que hacen Hasta donde alcanzan Arquitectura Tecnología Acceso Beneficios Ventajas Posibilidades A quienes va dirigido Como

Más detalles

Soluciones 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 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 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

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

Francisco D. Acosta Escalante Fecha de elaboración: 25/05/2010 Fecha de última actualización: 17/06/2010

Francisco D. Acosta Escalante Fecha de elaboración: 25/05/2010 Fecha de última actualización: 17/06/2010 PROGRAMA DE ESTUDIO Desarrollo de aplicaciones orientadas a servicios Programa Educativo: Licenciatura en Informática Administrativa Área de Formación : Integral Profesional Horas teóricas: 2 Horas prácticas:

Más detalles

CONSTRUCCIÓN DE PORTALES

CONSTRUCCIÓN DE PORTALES Curso «Los portales de internet». Fac. Documentación. Universidad de Murcia. 29 CONSTRUCCIÓN DE PORTALES Juan Antonio Pastor Sánchez 1. Introducción La Gestión de los contenidos informativos de los portales

Más detalles

WebSphere Message Broker como Entreprise Service Bus

WebSphere Message Broker como Entreprise Service Bus IBM Software Group WebSphere Message Broker como Entreprise Service Bus Irene Couso, IT Specialist, SWG WebSphere Services Agenda WebSphere Problemática En Los Clientes Por Qué Esta Arquitectura? Oferta

Más detalles

Interoperabilidad Cómputo Cliente/Servidor

Interoperabilidad Cómputo Cliente/Servidor Middleware r. José Raúl érez Cázares (raul.perez@itesm.mx) ITESM epartamento de Ciencias Computacionales Interoperabilidad Cómputo / S Macintosh ECStation OS/2 MacOS UIX Acceso Remoto Base de datos? WA

Más detalles

Introducción al Software basado en Componentes. Motivación. Un poco de historia.

Introducción al Software basado en Componentes. Motivación. Un poco de historia. Introducción al Software basado en Componentes Juan José Moreno Navarro Curso de Doctorado LSIIS (junto con Lars-Ake Fredlund) Motivación Antecedentes: Sistemas distribuidos y el problema de la reutilización.

Más detalles

Automatizador de Procesos

Automatizador de Procesos Automatizador de Procesos Más que un workflow, esta aplicación es un BPM (Business Process Management), una completa plataforma de automatización de procesos, diseñada para apoyar la transformación empresarial;

Más detalles

Indice TECNIMAP CACERES 2000 1

Indice TECNIMAP CACERES 2000 1 Indice Introducción 2 Enterprise Information Portals (EIP) o Portales Corporativos 3 Qué es un Enterprise Information Portal? 3 Necesidades a cubrir por un EIP 4 Servicios proporcionados por plataforma

Más detalles

Capí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 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 detalles

Tema 5. Plataforma Java EE

Tema 5. Plataforma Java EE Tema 5. Plataforma Java EE SCS Sistemas Cliente/Servidor 4 o informática http://ccia.ei.uvigo.es/docencia/scs enero 2009 FJRP, FMBR 2008/09 ccia SCS 5.1 Introducción a Java EE Java EE (Java Enterprise

Más detalles

ARC 108 Component Model

ARC 108 Component Model ARC 108 Component Model Evolución Tecnológica de RNOM Banco de Previsión Social Tabla de Contenidos ARC 108 Component Model 1. INTRODUCCIÓN 3 2. OBJETIVO 4 3. NOTACIÓN 5 4. ARQUITECTURA GLOBAL 6 4.1. DIAGRAMA

Más detalles

Información de Producto:

Información de Producto: Windows Server 2008 Foundation La nueva tecnología rentable de Windows Server 2008 Foundation La tecnología confiable y comprobada de Windows Server Foundation proporciona una base para ejecutar las aplicaciones

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

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR En este capítulo se describe el análisis y diseño de un sistema, denominado e-commerce Constructor, el cual cumple con los siguientes objetivos: Fungir

Más detalles

Sistemas de Operación II

Sistemas de Operación II Sistemas de Operación II Procesos en Sistemas Distribuidos Prof. Carlos Figueira Basado en material de Yudith Cardinale, Mariela Curiel (USB) Andrew Tanembaum y Marteen van Steen Contenido Clientes Servidores

Más detalles

RESUMEN DE COBIT 4.1. Los recursos de TI identificados en COBIT se pueden definir como sigue [2]:

RESUMEN DE COBIT 4.1. Los recursos de TI identificados en COBIT se pueden definir como sigue [2]: RESUMEN DE COBIT 4.1 COBIT es un marco de trabajo y un conjunto de herramientas de Gobierno de Tecnología de Información (TI) que permite a la Gerencia cerrar la brecha entre los requerimientos de control,

Más detalles

UNIVERSIDAD ESTATAL DE MILAGRO

UNIVERSIDAD ESTATAL DE MILAGRO UNIVERSIDAD ESTATAL DE MILAGRO TRABAJO DE INVESTIGACION DE BASE DE DATOS TEMA: SISTEMAS DISTRIBUIDOS NOMBRE: ANGEL SAUL NOBOA BARRENO PROFESOR: ING. RICHARD RAMIREZ CURSO: 6 To SEMESTRE C SISTEMAS DISTRIBUIDOS

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

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

5. Modelos de Sistemas Distribuidos

5. Modelos de Sistemas Distribuidos Sistemas Distribuidos 5. Modelos de Sistemas Distribuidos Prof. María Feldgen Curso 2006 Índice Modelos Modelo Cliente-Servidor Framework CORBA Java RMI Microsoft DCOM Message-Oriented Middleware Dificultades

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

Service Oriented Architecture: Con Biztalk?

Service 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 detalles

Caso J2EE. Necesidades del negocio. Arquitectura Luther

Caso J2EE. Necesidades del negocio. Arquitectura Luther Caso J2EE Grupo de Construcción de Software Facultad de Ingeniería Universidad de los Andes Necesidades del negocio Describa el objetivo funcional del sistema que desea Inmedius Enumere los RNF que debe

Más detalles

SEDA. Servicio Ejecución Distribuida de Aplicaciones. Dossier de Presentación. Versión 1.0

SEDA. Servicio Ejecución Distribuida de Aplicaciones. Dossier de Presentación. Versión 1.0 SEDA Servicio Ejecución Distribuida de Aplicaciones Dossier de Presentación Versión 1.0 2 SEDA Edificio RD Sistemas 1 ÍNDICE 1 ÍNDICE 3 2 EVOLUCIÓN TECNOLÓGICA DE RDSISTEMAS5 3 ARQUITECTURA SEDA 6 3.1

Más detalles

GLOSARIO DE TÉRMINOS

GLOSARIO DE TÉRMINOS MINISTERIO DE EDUCACIÓN, CULTURA Y DEPORTE SECRETARÍA DE ESTADO DE EDUCACIÓN, FORMACIÓN PROFESIONAL Y UNIVERSIDADES DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES

Más detalles

Planeación del Proyecto de Software:

Planeación del Proyecto de Software: Apéndice A. Cuestionarios del Sistema Evaluador Nivel2. Requerimientos de Administración: Goal 1: Los requerimientos del sistema asociados a software están bien controlados y existe un estándar para los

Más detalles

D E S C R I P C I Ó N

D E S C R I P C I Ó N ADAPTOR pertenece a la nueva generación en herramientas de Integración de Sistemas (EAI) fuertemente inspirada en el paradigma SOA y capaz de funcionar en un bus de servicios (ESB), es la forma más eficiente

Más detalles

Bajo Costo de Implementación y Soporte: Ofrecer un bajo costo de implementación y mantenimiento.

Bajo Costo de Implementación y Soporte: Ofrecer un bajo costo de implementación y mantenimiento. Documento de Referencia Una Única Solución que Integra Todas las Aplicaciones que su Empresa Requiere Tecnologizar los procesos financieros, operacionales y de gestión de su empresa, es sólo cuestión de

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

Introducción a Bases de Datos

Introducción a Bases de Datos de a M. -Tastets Universidad de Concepción,Chile www.inf.udec.cl\ andrea andrea@udec.cl II Semestre - 2007 y del s: Sistemas de y del s: de y del s: Objetivos de la Unidad Dar a conocer las características,

Más detalles

CAPÍTULO 3: Resultados

CAPÍTULO 3: Resultados CAPÍTULO 3: CAPÍTULO 3: RESULTADOS La meta de un proyecto de consolidación de servidores físicos o de virtualización, es la creación de las máquinas virtuales que sean capaces de ejecutar las aplicaciones

Más detalles

RODRIGO TAPIA SANTIS (rtapiasantis@gmail com) has a. non-transferable license to use this Student Guide

RODRIGO TAPIA SANTIS (rtapiasantis@gmail com) has a. non-transferable license to use this Student Guide Introducción Objetivos del Curso Al finalizar este curso, debería estar capacitado para: Instalar, crear y administrar Oracle Database 11g Versión 2 Configurar la base de datos para una aplicación Utilizar

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