Arquitecturas de n-niveles y J2EE para el desarrollo de grandes aplicaciones de gestión de red

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

Download "Arquitecturas de n-niveles y J2EE para el desarrollo de grandes aplicaciones de gestión de red"

Transcripción

1 Arquitecturas de n-niveles y J2EE para el desarrollo de grandes aplicaciones de gestión de red Francisco Maciá Pérez 1, Virgilio Gilart Iglesias 1 y Juan Antonio Gil Martínez-Abarca 1 1 Departamento de Tecnología Informática y Computación, Universidad de Alicante AP. 99, 03080, Alicante, España {pmacia, vgilart, Resumen. Abordar el desarrollo e implantación de grandes aplicaciones escalables sobre redes globales dirigidas a entornos empresariales o industriales implica aspectos realmente críticos: cómo elegir las tecnologías más adecuadas en la actualidad y que puedan ser vigentes al mayor largo plazo posible; cómo hacerlo desde una visión global en la que se considere las aplicaciones y sistemas ya existentes y se facilite la implantación y ampliación de aplicaciones e infraestructuras a medida que evoluciona la organización; cuáles son las implicaciones para las aplicaciones de negocio existentes, en particular para las CRM, las ERP, los SCM y la BI; cómo se desarrolla una visión para una arquitectura a largo plazo; o cómo se produce el retorno de la inversión y la mejora en la eficacia. En este artículo se ponen de manifiesto todas estas cuestiones y se presenta una arquitectura de componentes software distribuidos basada en el modelo arquitectural de n-niveles, como uno de los modelos que en la actualidad mejor se adaptan a la resolución de este tipo de problemas. Una vez definido el modelo, se discuten diversas plataformas middleware disponibles en la actualidad para su desarrollo y cuáles son patrones de diseño que mejor se ajustan a las necesidades planteadas. Introducción En la actualidad está claro que las grandes aplicaciones de negocio electrónico deben aprovechar todo el potencial que ofrecen las tecnologías vigentes [6] como Internet, el almacenamiento masivo, las técnicas de programación basadas en componentes software distribuidos, etc., sin embargo, esta necesidad parece que todavía no se ha visto reflejada en el desarrollo de las aplicaciones que deben gestionar tanto estas grandes aplicaciones de negocio electrónico como las infraestructuras que les deben dar soporte: aplicaciones de monitorización de red, de gestión de la seguridad, de administración de sistemas o de gestión de recursos y usuarios en general [7]. Observando este tipo de aplicaciones se puede apreciar con facilidad que siguen modelos tradicionales de diseño, desarrollo e integración con el resto del sistema. Modelos que están mucho más centrados en resolver un determinado problema de administración que en constituirse como parte integrada en

2 un todo. En cualquier caso, se trata de enfoques divergentes con respecto a los enfoques seguidos para las aplicaciones de negocio. En este artículo se propone, precisamente, la necesidad de plantear enfoques convergentes en el desarrollo de ambos tipos de aplicaciones. Es más, la necesidad de no realizar distinciones entre las mismas más allá de lo puramente necesario. Para alcanzar este objetivo resulta imprescindible obtener una visión que permita concebir una arquitectura más sólida y duradera, superando el tradicional modelo clienteservidor [8] y realizando una concepción global del sistema; concepción que debe abarcar todos y cada uno de los aspectos que intervienen y, previsiblemente, intervendrán en el sistema que se desea desarrollar, incluida la identificación de los elementos importantes para mantener las actuales inversiones en sistema de gestión heredados [6,2]. Finalmente, se deberá definir un plan de implantación que determine cómo migrar a dicha arquitectura [6]. Dicho plan deberá establecer los procedimientos, plazos y evaluaciones necesarias para que pueda ser viable un proyecto tan ambicioso. A pesar de esta necesidad ineludible de aprovechar y extraer al máximo aquello que las tecnologías de la información y de las comunicaciones puedan ofrecer en la actualidad, la solución propuesta no puede, ni debe, implicar en ningún momento tecnología. Obviamente, utilizaremos tecnologías Internet y procesos de negocio innovadores para desarrollar aplicaciones de gestión que amplíen los límites tradicionales de tiempo, espacio, departamentos, organizaciones, etc. Sin embargo, esta utilización deberá estar contemplada dentro de un plan global preconcebido [11] en lugar de confiar en ella para resolver posibles problemas que no hubieran sido contemplados desde un principio, como la necesidad de mayores anchos de banda o la ampliación del espacio de almacenamiento. Las aplicaciones así desarrolladas deben ofrecer características adicionales a los sistemas tradicionales de gestión: añadiendo valor, abaratando los costes e impulsando la exploración de nuevos métodos de gestión. Resumiendo, los principios de diseño que se proponen para el desarrollo de estas grandes aplicaciones de gestión son los siguientes: Desarrollo basado en estándares y tecnologías abiertas: flexibilidad para transportar la aplicación entre diferentes plataformas físicas. Dividir la aplicación en diferentes capas: fuertemente acopladas las internas y débilmente con respecto a las de otros modelos. Utilizar tecnologías probadas y estables que presenten una curva de madurez adecuada a las necesidades. Aprovechar inversiones en sistemas existentes: uno de los mayores potenciales de las aplicaciones ebusiness. Prever la dificultad y costes para conseguir personal con habilidades técnicas puesto que se trabaja con un mercado laboral muy concreto. Siguiendo estos principios, en el siguiente apartado analizaremos las tecnologías web actuales como tecnología válida para la implantación de aplicaciones basadas en modelos cliente-servidor ligeros. En el apartado tercero analizaremos las plataformas middleware que deben dar soporte a los modelos basados en componentes software distribuidos. En el apartado cuarto se analizará la conveniencia de contemplar la totalidad de los aspectos que pudieran intervenir en el desarrollo de la aplicación y la idoneidad de utilizar una arquitectura técnica de n-niveles [12,13] que pueda obtener

3 mayor partido de las tecnologías actuales. Una vez sentadas las bases del desarrollo de las aplicaciones, en los apartados cinco, seis y siete nos centraremos en la plataforma J2EE como conjunto de especificaciones y tecnologías que permiten contemplar todos los aspectos descritos, justificando su elección sobre otras tecnología y herramientas. En el apartado octavo se aborda un escenario de integración de las tecnologías implicadas. Finalmente, en el apartado noveno, se analiza las principales conclusiones que se extraen de las propuestas realizadas. Tecnología Web En sus orígenes, la tecnología Web, basada en el protocolo HTTP para la transmisión de hipertexto sobre protocolos de comunicaciones TCP/IP, sirvió para proporcionar una nueva visión de Internet [8]. Si antes, con servicios como FTP, la Red se concebía como un conjunto de nodos servidores que había que conocer, ahora se logra un nivel de abstracción mayor: lo que importa es la información los contenidos en términos del WWW en lugar de su ubicación o de las características de los servidores en los que está ubicada. Es más, deja de preocupar en gran medida desde qué tipo de dispositivo queramos acceder a los contenidos computador personal, PDA, WebTV, teléfono móvil, etc [9]. Cliente Servidor Red de Comunicación Recurso Cliente Protocolo de Comunicación (TCP/IP) Protocolo de Aplicación Servicio Know- How Figura 1. Modelo Cliente/Servidor sobre TCP/IP. Estas características de independencia entre clientes y servidores, unida al auge de la generación de contenidos en Internet y la enorme heterogeneidad reinante en el entorno de las TIC, facilitan que prospere rápidamente este nuevo modelo cliente/servidor [8]. Sin embargo, debido en parte a su cada vez mayor participación en el mundo de los negocios y a la necesidad, por tanto, de generación de contenidos dinámicos, cada vez son más las tecnologías que en los últimos tiempos han ido adosándose a nuestros servidores Web y, porqué no, a engordar nuestros navegadores. Está claro que se necesita una mejor gestión de recursos y una mayor organización. Atrás quedaron los tiempos en que la Web era un mero escaparate de consulta de información estática, dónde las empresas presentaban su catálogo de productos o su oferta de servicios. En la actualidad se tiende a ir paulatinamente haciendo efectivos

4 los diferentes servicios, que ya se prestan por otros medios, en esa red universal que es Internet. Para ello, las aplicaciones convencionales cliente/servidor para redes locales o corporativas, escritas pensando en un entorno determinado, deberán ser adaptadas a las nuevas características e idiosincrasia que imponen las tecnologías de Internet en general y de la Web en particular [6]. Servicio HTTP Básicamente, una aplicación Web es cualquier aplicación basada en la arquitectura cliente/servidor [8], donde el cliente es un navegador y el servidor es un servidor Web, utilizando ambos para su entendimiento los protocolos de Internet (ver figuras 1 y 2). Servidor WEB Gestión de transacciones protocolo solicitud-respuesta (HTTP) representación externa de datos (MIME) Navegador SO protocolo comunicación (TCP/IP) SO TCP/IP HW NIC HW NIC Red de Comunicación Figura 2. Modelo de servicios de la arquitectura cliente/servidor sobre Intenet. El protocolo con el que se comunican las diferentes máquinas conectadas a Internet es TCP/IP [8]. Después, y a modo de capa por encima de éste, cada servicio existente en la red implementa su propio protocolo de aplicación, de forma que clientes y servidores de un mismo servicio puedan entenderse y hablar el mismo leng uaje. Método URL Versión Cabecera GET //www.dtic.ua.es/index.html HTML/1.1 Figura 3. Formato de una solicitud HTTP. Un servidor Web y un cliente Web o navegador se entienden a través del protocolo HTTP, por medio del cual intercambian información. En la figura 3 se puede apreciar un ejemplo de solicitud de página HTML utilizando este protocolo.

5 El cliente realiza peticiones y el servidor se las sirve. Es la filosofía general de toda aplicación basada en la arquitectura cliente/servidor, dentro de la cuál una aplicación Web no es una excepción. En principio, un servidor Web elemental sólo está preparado para servir información estática, normalmente en forma de páginas HTML, lenguaje que se utiliza para posicionar el contenido de dicha página y que conoce el cliente o navegador que las va a interpretar. En la figura 4 se presenta el contenido de una sencilla página HTML con el típico caso de ejemplo hola a todos. <HTML> <CAB> <TITTLE> Saludos </TITTLE> </CAB> <BODY> Hola a todos <BR> </BODY> </HTML> Figura 4. Contenido de un sencillo documento HTML. Un documento HTML (HiperText Markup Language), tal y como sus siglas indican, está formado por los siguientes elementos: Documento de texto. Etiquetas de formato: <etiqueta [arg1 arg2...]>... [</etiqueta>] Referencias cruzadas: <A HREF= URL > texto descriptivo </A> Puesto que HTML es un protocolo pensado para la transferencia de texto, aquellos archivos de datos binarios (imágenes, sonidos, etc.) asociados al documento y que son necesarios para su representación se codifican en un formato de texto denominado MIME (Multipurpose Internet Mail Extension) que permite el intercambio de datos en formato texto a través de Internet. Una vez recogida la respuesta por parte del navegador, éste la interpretará con el fin de presentársela de forma adecuada generalmente en modo gráfico al usuario final (figura 5). A medida que crece la importancia de las aplicaciones Web y comienzan a necesitar generar información dinámica, propia del mundo de las aplicaciones de índole comercial, empiezan a añadirse una gran diversidad de tecnologías nuevas, tanto a la parte servidora como a la parte cliente. Durante los últimos años, esto se ha ido haciendo de una forma casi anárquica, implementando tecnologías, en su mayoría propietarias, con pretensiones de convertirse en estándares [6]. En la parte cliente, los navegadores crecen en capacidad de interpretación y son capaces de trabajar con tecnologías como DHTML, ActiveX o applets Java, por no

6 mencionar los innumerables plug-ins que introduce el mundo multimedia en la Web. En general, tal y como se muestra en la figura 6, la idea fundamental de estas mejoras se orienta a añadir kown-how en la parte del cliente. Esto se consigue, entre otras formas, transfiriendo dicho conocimiento junto con la información a tratar. Cliente Servidor Web Internet TCP/IP J Pág. PEG J HTML PEG HTML Cliente ligero Navegador Web HTTP JPEG Pág. HTML JPEG httpd Figura 5. Posible escenario de desarrollo para un servicio HTML básico Servidor Web Cliente Internet HTML Cliente ligero Navegador Web HTTP J Pág. PEG J PEG HTML knowhow httpd Figura 6. Modelo de enriquecimiento del Cliente. En la parte servidora, se rodea al servidor Web de una serie de tecnologías que le permiten ampliar su funcionalidad básica de servir información estática. Unas van perfeccionando a otras, pero es tan rápida su evolución que, si bien se tiende a sustituir las más viejas, hoy por hoy conviven todas en cualquier aplicación Web de cierta envergadura o que lleve cierto tiempo en el mercado, como es el caso de los portales corporativos de las grandes empresas. Conviene por ello hacer un repaso, siquiera somero, a todas ellas.

7 Servidores ligeros Dentro de los servidores ligeros se incluyen tecnologías como php, servlets o dll generadas con ASP.Net [14]. En todos los casos, la idea fundamental subyacente es la de crear pequeñas aplicaciones que se ejecutan en el servidor al ser invocadas por un determinado cliente, realizan una tarea y generan una salida que es enviada al navegador, generalmente en términos de HTML o XML. Sus funcionalidades y método de trabajo aportan características como: portabilidad, rendimiento, habilitación del concepto de sesión y software distribuido. Páginas Activas Esta tecnología está basada en la incrustación de código escrito en un lenguaje script dentro de las páginas Web, con el fin de que dicho código sea interpretado por el servidor Web y pasado a HTML antes de servir la página al cliente. Desde este código se accede, si es necesario, a los recursos externos que sean precisos (figura 7). Servidor Web Cliente Internet TCP/IP JP EG HTML JP EG HT+ Script Cliente ligero Navegador Web HTTP JPEG JP EG Pág. HTML Servidor W b JP EG HTML JP EG + Script script script Otros Recursos Externos Figura 7. Escenario de desarrollo para una página activa. Esta forma de desarrollar aplicaciones basadas en Web es de las más aceptadas actualmente ya que otorga un control entre la aplicación y el servidor. Además, habilita el concepto de sesión de usuario, es decir, podemos conocer el estado de la conexión de un usuario en un momento determinado. Asimismo, gestiona bien los recursos externos, como es el caso de accesos a bases de datos, y permite una gran flexibilidad de compartición de los mismos y de programación de la petición y respuesta Web. La mayoría de las operaciones se realizan en el servidor y hasta que no están totalmente gestionadas no se sirve la página resultante al cliente. Esto independiza en gran medida la aplicación Web del navegador que nos visite. El desarrollador deberá aprender el lenguaje script correspondiente, el cual es propietario del servidor Web que lo ha de interpretar. Los servidores Microsoft implementan esta tecnología con el nombre de ASP (Active Server Pages), basadas en Visual Basic Script, mientras que Netscape lo hace con un lenguaje llamado Livewire, basado en Javascript. Una tercera alternativa es JSP (Java Server Pages).

8 Representa una nueva tecnología de páginas activas cuyo lenguaje script es Java, por lo que ofrece todas las características que hacen de éste un lenguaje idóneo para la red [15]. Como ya se ha comentado, las páginas activas de Microsoft y Netscape son propietarias. La tecnología ASP está totalmente vinculada con el servidor Microsoft Internet Information Server [14] y Visual Basic Script y Livewire lo está con Netscape Enterprise Server y es un sucedáneo de Javascript propio. En este sentido, JSP representa la opción que más se ajusta al concepto de tecnologías abiertas y código libre por estar basada en Java estándar. Servidor de Aplicaciones Para centralizar todas las posibles tareas de índole dinámica que un servidor Web ha de realizar no suele ser una buena solución cargarle con todo el trabajo a base de parches o añadidos de diversa naturaleza. Un enfoque más ambicioso es colocar detrás de él un cerebro o motor: el servidor de aplicaciones [9,13]. contenidos estáticos Servidor Web Cliente J PEG Pág. J PEG HT HTML Servidor de Aplicaciones Navegador Web J PEG Pág. J PEG HTML HTTP Servidor Web Pág. HTML Servidor de aplicaciones Otros Recursos Externos contenidos dinámicos Lógica Negocio Figura 8. Relación entre un servidor Web y un servidor de aplicaciones. La filosofía general de funcionamiento es la siguiente: las peticiones que se hagan al servidor Web que deban generar contenido estático las despachará el propio servidor Web como de costumbre; pero las peticiones que deban generar contenido dinámico serán delegadas en el servidor de aplicaciones; éste interactuará con el recurso externo que sea necesario, ejecutará la lógica de negocio que se precise y le pasará la respuesta en formato HTML al servidor Web que, a su vez, la remitirá al cliente (figura 8). Tras la idea de servidor de aplicaciones se esconden todo un conjunto de servicios y tecnologías que hacen viable esta propuesta: estamos hablando del concepto de middleware [9] y, debido a su complejidad, merece un tratamiento especial.

9 Middleware El middleware se puede definir como el nivel lógico del sistema que proporciona una abstracción sobre la infraestructura que le da soporte a las aplicaciones, dotando de transparencia de ubicación e independencia de los detalles del hardware de los computadores, del sistema operativo, de la red de interconexión y de los protocolos de comunicaciones (figura 9) e, incluso, del lenguaje de programación utilizado para su desarrollo. Desde el punto de vista del programador de aplicaciones, el middleware establece un modelo de programación sobre bloques básicos arquitectónicos, utilizando protocolos basados en mensajes para proporcionar abstracciones de nivel superior. Servidor Web Cliente HTML Navegador Web Servidor Web Componentes Middleware Servidores de Aplicaciones Figura 9. Capa de middleware en el contexto de un sistema distribuido basado en componentes software. En cualquier caso el middleware se puede estudiar desde dos puntos de vista bien diferenciados: desde el punto de vista de la propia infraestructura que conforma el middleware y desde el punto de vista del diseñador de aplicaciones. Desde el punto de vista de la infraestructura viene definido por su arquitectura, en la que resaltan los siguientes elementos: El modelo de representación de datos, responsable de convertir las estructuras de datos internas de los componentes en secuencias de bytes, bien para su almacenamiento, bien para su transferencia a través de la red de comunicaciones. El modelo de comunicaciones, encargado de facilitar la comunicación entre componentes a través de una red de comunicaciones. Para desarrollar su labor se apoya en un modelo de representación de datos responsable de su serialización, en un protocolo de comunicaciones tipo petición/respuesta como

10 mecanismo de comunicación efectivo para sistemas distribuidos, y en un modelo de invocación de métodos remotos que permite el acceso a la funcionalidad del componente con el que se quiere establecer contacto. Un conjunto de servicios adicionales que proporcionan un equipamiento genérico que puede utilizarse en una gran variedad de aplicaciones. Estos servicios suelen incluir servicio de nombres, servicios de eventos y notificación, servicio de seguridad, y servicios de transacción y concurrencia. aplicaciones comp comp comp comp comp comp comp comp comp modelo de servicios abstractos middleware middleware middleware RMI protocolo solicitud-respuesta representación externa de datos SO SO SO HW HW HW plataforma de comunicaciones Figura 10. Modelo general de capas del sistema con middleware. Desde el punto de vista del diseñador de aplicaciones, el middleware representa un modelo de programación al que le incumbe definir nítidamente la estructura que deben tener los componentes a diseñar, así como los mecanismos que deben emplearse para acceder a los recursos y a los servicios que proporciona la plataforma [6]. Con respecto a la estructura de los componentes, el modelo define tres grandes elementos: El estado del componente, encargado de mantener las estructuras de datos que utiliza el componente y que definen su bagaje. El comportamiento, definido a través de una serie de métodos que implementan la lógica de aplicación o de negocio que encapsula el componente. La interfaz del componente, en la que deben especificarse los métodos y las propiedades que posee el componente y que están accesibles a otros componentes y objetos. Con respecto al mecanismo de acceso a los recursos de la plataforma, se debe tener en cuenta que, desde el punto de vista del programador o del componente la plataforma es un suministrador de servicios por lo que, con el objetivo de facilitar su acceso sobre todo con independencia de los lenguajes y herramientas de programación que se utilicen, uno de los métodos más habituales es proporcionar un API de los servicios disponibles en la plataforma.

11 Arquitectura middleware Desde el punto de vista de la propia infraestructura que conforma el middleware, éste viene definido por su arquitectura (figura 11), en la que resaltan los siguientes elementos: el modelo de representación de datos, el modelo de comunicaciones en el que se incluye el protocolo de comunicaciones y el modelo de invocación de métodos remotos y los servicios que proporciona la plataforma [16]. Aplicación Cliente Objeto Proxy Réplica auxiliar Interfaz Objeto Componente núcleo servicios middleware núcleo servicios middleware Protocolo comunicación Figura 11. Arquitectura middleware. Modelo de representación de datos Independientemente de la forma de comunicación utilizada, las estructuras de datos y atributos de los objetos deben ser convertidos en una secuencia de bytes antes de su transmisión y, posteriormente, reconstruidos en el destino. Para hacer posible que dos computadores puedan intercambiar información, éstos deben acordar previamente un esquema común o incluir la especificación del formato de emisión en el propio mensaje. Al estándar acordado para la representación de los valores y estructuras de datos a transmitir en los mensajes se le denomina representación externa de datos por ejemplo, CDR de CORBA [16]. Modelo de comunicación El protocolo petición-respuesta define el nivel adecuado para establecer una comunicación típica según la arquitectura cliente/servidor en sistemas distribuidos basados en UDP o TCP. El propio mensaje de respuesta se considera como un reconocimiento del mensaje de petición, evitando de este modo las sobrecargas de los mensajes de reconocimiento adicionales. Sobre esta capa de protocolo se construyen los modelos de comunicación de llamada a procedimiento remoto (RPC) [16] y el modelo de invocación a métodos remotos (RMI) [13]. RPC permite a programas cliente invocar procedimientos pertenecientes a programas servidor que generalmente se ejecutan en computadores distintos. Este modelo evoluciona, posteriormente, permitiendo que objetos de diferentes procesos se comuniquen con los métodos de otros objetos RMI.

12 Servicios Los principales servicios que proporciona el middleware a las capas superiores del sistema son el servicio de nombres, el de eventos y notificaciones y el de seguridad. Servicio de nombres Su objetivo es almacenar los atributos de los objetos en un sistema distribuido, devolviendo esos atributos cuando se realiza una búsqueda sobre cierto nombre de texto. Los principales requisitos que debe poseer son la habilidad para manejar un número arbitrario de nombres, persistencia, alta disponibilidad y tolerancia a fallos. Ejemplos de este servicio son el X.500, LDAP, Jini, etc. Servicio de eventos y notificaciones Este servicio extiende el modelo local de eventos al permitir que varios objetos en diferentes ubicaciones puedan ser notificados de los eventos que tienen lugar en un objeto. Emplean el paradigma del tablón de anuncios, en el que un objeto que genera eventos publica el tipo de eventos que ofrece para su observación. Los objetos que desean recibir notificaciones de un objeto se suscriben a los tipos de eventos que les interesan. Servicio de seguridad Los mecanismos de seguridad se basan esencialmente en la criptografía de clave pública y de clave secreta. Los recursos se protegen mediante mecanismos de control de acceso. Se pueden mantener los derechos de acceso en listas de control (ACL) asociadas a conjuntos de objetos. Ejemplos de este servicio son: el protocolo de autenticación Needham-Schroeder, Kerberos, SSL o Millicent. Modelo de Programación Desde el punto de vista del diseñador de aplicaciones, el middleware representa un modelo de programación al que le incumbe definir nítidamente la estructura que deben tener los componentes a diseñar, así como los mecanismos que deben emplearse para acceder a los recursos y a los servicios que proporciona la plataforma (figura 12). Estructura de un componente Un sistema orientado a objetos consta de un conjunto de componentes que interaccionan entre sí, cada uno de los cuales consiste en un conjunto de datos y un conjunto de métodos. Un objeto se comunica con otro objeto invocando sus métodos, generalmente pasándole argumentos y recibiendo resultados. Así, cada componente se puede estructurar en tres elementos: una interfaz, una lógica de aplicación o de negocio y un estado [6]. Interfaz La interfaz de un componente proporciona una definición de las signaturas de sus métodos los tipos de sus argumentos, valores devueltos, excepciones, etc. sin

13 especificar su implementación. Establece, asimismo, qué métodos y propiedades están accesibles para el resto de componentes y objetos. Por supuesto, nada impide que un mismo objeto implemente distintas interfaces a la vez. componente cliente Interfaz - métodos - propiedades Lógica Negocio Estado API de Servicios Middleware Figura 12. Estructura básica de un componente software y su relación con la plataforma. Cada componente se implementa de forma que oculta tanto su estado como su funcionalidad, excepto la que se hace disponible a través de su interfaz en términos de propiedades y métodos, respectivamente. Esto permite modificaciones en la implementación de la lógica del componente o de su estructura interna siempre que su interfaz se mantenga inalterada. Para que distintos componentes implementados por distintos equipos de desarrollo y, posiblemente, con diferentes lenguajes de programación puedan interactuar entre ellos es necesario que sus interfaces estén definidas de forma homogénea. Para facilitar esto, el modelo de programación introduce los lenguajes de definición de interfaces (IDL) que proporcionan una notación específica en la que, por ejemplo, los parámetros de un método se describen como de entrada o salida y utilizando su propia especificación de tipos. Estado El estado de un componente consta de los valores de sus variables de instancia. En el paradigma de la programación orientada a objetos, el estado de un programa se encuentra fraccionado en partes separadas, cada una de las cuales está asociada a un objeto. El estado de un objeto está accesible sólo para los métodos del objeto, es decir, que no es posible que métodos no autorizados actúen sobre su estado. Algunas implementaciones de middleware, como CORBA [16], permiten empaquetar y almacenar los objetos junto con su estado en un momento dado en los llamados almacenes de objetos persistentes, de forma que métodos de otros objetos puedan activarlos por invocación a través de su interfaz. En general se almacenan en cualquier momento en el que se encuentren en un estado consistente, con lo que dotan al sistema de tolerancia a fallos. Comportamiento El comportamiento define la funcionalidad del componente a través de una serie de métodos que recogen la lógica de aplicación o de negocio que encapsula y a la cual se

14 accede, en caso de estar disponible para otros componentes, a través de las interfaces definidas. Acceso a los servicios Un middleware debe proporcionar un mecanismo que permita a los componentes acceder a sus servicios. El método más habitual es el de proporcionar un API que facilite el acceso, sobre todo, con independencia de los lenguajes y herramientas de programación que se utilicen earchitecture Los sistemas cliente-servidor convencionales resultan muy dependientes tanto del hardware como del software utilizado y precisan de un conocimiento mutuo de las partes dirección del servidor, plug-ins instalados en el cliente, formatos empleados. Esta forma de proceder va en contra de la filosofía abierta de Internet. Un sistema complejo de gestión de redes puede proporcionar mayores oportunidades para automatizar y conseguir eficiencia en nuestra organización [7]. Para ello se debe ampliar el concepto de modelo cliente-servidor hacia un enfoque que aproveche plenamente el verdadero potencial de Internet y las tecnologías que soporta, considerando estándares y redes abiertas, y pensando en términos de arquitecturas cliente-servidor ligeras y aplicaciones basadas en componentes software distribuidos [13]. Dentro de este contexto, si una arquitectura define, a su vez, todo un conjunto de subarquitecturas y modelos, en este artículo, por motivos de espacio, nos centraremos fundamentalmente en cómo definir la arquitectura técnica de nuestra aplicación. Arquitectura técnica La arquitectura técnica describe la estructura de la aplicación y está compuesta por un modelo conceptual que define las diferentes capas funcionales y niveles de distribución de la aplicación, y por las infraestructuras empleadas para su desarrollo: marcos, modelos y patrones. Modelo conceptual El modelo conceptual de una aplicación está compuesto por las capas funcionales, responsables de cada tipo de componente y su ubicación en la capa arquitectural, y los diferentes niveles de distribución que indican cómo se sitúa cada tipo de componente en un sistema distribuido (figura 13) [6].

15 Nivel Usuario Nivel Espacio de trabajo Nivel Empresa Nivel Recursos Capa Aplicaciones User Fuentes Externas Presentación Controlador de Vista Controlador B2B Coordinador Trabajo Perfil Usuario Controlador Actividad Controlador Proceso Componente Entidad Adaptador Aplicación Adaptador Recursos Sistemas Heredados Aplicaciones Empaquetadas Capa Servicios middleware Servicio Autorización Servicios Configuración Servicio Perfiles Servicio Entrada Servicio Flujo Trabajo Servicios Gestión Servicio Reglas Otros Servicios Servicio Persistencia Datos Persistentes Figura 13. El diagrama muestra las distintas capas funcionales tanto de servicio como de aplicación del modelo conceptual que define junto con la infraestructura de desarrollo: marcos, servicios y patrones una arquitectura técnica. Al mismo tiempo, el diagrama recoge los diferentes niveles lógicos en los que se ha dividido dicho modelo conceptual y en el que se han ubicado las diferentes capas funcionales de la aplicación. Podemos resumir los objetivos fundamentales del modelo conceptual en los siguientes puntos: Distribución. Cada capa funcional puede estar ubicada en un nivel distinto. Escalabilidad. La aplicación de los recursos puede realizarse de manera independiente sobre la capa funcional que los precise. Al mismo tiempo, se facilita el balanceo de carga al poder ubicar cada capa en un espacio físico diferente o, incluso, ser replicadas en caso de necesidad. Separación del desarrollo de la aplicación con respecto a las infraestructuras empleadas en su desarrollo. Independencia de la tecnología sobre la que finalmente se implante la aplicación. Independencia del dispositivo utilizado por los clientes para acceder al sistema, gracias a los adaptadores de recursos y controladores de vistas. Integración de aplicaciones. Facilita y sistematiza la integración con aplicaciones y sistemas heredados a través de los adaptadores de aplicaciones. Mejoras y migración. Ante necesidades de actualización o modificación de la aplicación, el impacto que un determinado cambio tenga sobre el resto del sistema es mínimo gracias a su división en capas funcionales. Este mismo esquema será útil para facilitar la migración progresiva del sistema existente a la nueva aplicación. Cada capa funcional puede reemplazarse o dividirse en grano fino y con poco impacto sobre el resto.

16 Capas funcionales Las capas funcionales se pueden dividir, básicamente, en la capa de servicios y la capa de aplicación. La capa de servicios define los componentes del sistema que se consideran básicos, proporcionan servicios a las capas superiores y, en general, estarán disponibles en cualquier nivel lógico y físico en el que se divida la aplicación. Esta capa de servios está plenamente ligada al concepto de middleware abordado en el apartado anterior. En la capa de aplicación es en la que se definen los diferentes componentes desarrollados para la aplicación y que serán particulares para la misma. En nuestro caso, estos componentes pueden ser módulos software, aplicaciones específicas, componentes software distribuidos o clientes ligeros como un navegador web. Niveles de distribución Los niveles de distribución indican cómo se sitúa cada componente dentro de la capa arquitectural. Se diferencia entre niveles de distribución lógico y físico. Los niveles de distribución lógicos indican cómo debe dividirse la aplicación para facilitar la consecución de los objetivos de distribución, escalabilidad y separación antes analizados. Sin embargo, para dicha división no se tendrá en cuenta la ubicación física final de cada componente. A continuación se analizará con más detalle los diferentes niveles lógicos propuestos y que en nuestro caso supone un modelo de n-niveles: Nivel de usuario. Es el nivel en el que se ubica la parte cliente de la aplicación. Está compuesto por el nivel de presentación y por el controlador de vista. La presentación constituye básicamente la aplicación que se proporciona al usuario para interactuar con el sistema. El consejo es intentar que sea lo más ligera e independiente del sistema posible. En cualquier caso, siempre queda la discusión sobre la idoneidad de qué aspectos deben estar embebidos en la misma: funciones muy específicas, validación de datos, etc. El controlador de vista es el encargado de dar soporte a la presentación e independizar al máximo la entrada y salida del sistema del dispositivo y tipo de aplicación cliente con la que ésta se realice. Así, para una presentación que utilice HTML, el controlador puede ser un servlet; en caso de tratarse de una aplicación escrita en Microsoft Visual Basic, estaría generado automáticamente como parte del VB Runtime; si se emplea un teléfono, el controlador sería un simulador de voz para la salida junto con un reconocedor de voz y tecnologías de entrada por teclado para la recogida de información. Nivel de espacio de trabajo. En este nivel se realizan todas las adaptaciones entre el cliente y el servicio; se gestiona la personalización (nivel perfiles de usuario); se recoge toda la información necesaria para un proceso a través de múltiples presentaciones (por ejemplo, un EJB de sesión enlazado con un objeto sesión HTTP). Como caso especial, se contempla la posibilidad de que el usuario que accede al sistema sea, a su vez, otro sistema. En este caso estaríamos hablando de un modelo B2B (frente al modelo B2C tratado hasta el momento) en el que se puede prescindir de mucho del protocolo necesario para tratar con un usuario humano. Representa, por lo tanto, un punto de

17 entrada diferente, mucho más sistematizable y que estará más basado en la comunicación entre procesos a través de estándares como XML. Nivel de empresa. Constituye el núcleo central de la aplicación o servicio. Será en este nivel en el que se recojan las reglas de negocio que rijan la aplicación. Para su desarrollo se ha establecido tres componentes: controlador de actividad, controlador de procesos y reglas de negocio. El controlador de actividad regula el flujo de trabajo, presentando al usuario los procesos de negocio como casos de uso, es decir, como una secuencia de unidades de trabajo, también denominadas funciones de negocio. El controlador de procesos es el encargado de ejecutar un determinado proceso de negocio. Las reglas de negocio constituyen el motor de reglas, por ejemplo: validar información, protocolos de gestión, etc. Nivel de recursos. En este nivel se ubica todo aquello que supone información para nuestra aplicación: aplicaciones heredadas (sistemas ya existentes) o empaquetadas (paquetes ofimáticos o programas de contabilidad) y sistemas de información (bases de datos). Para conseguir la máxima independencia con los recursos se establecen diferentes adaptadores: de aplicaciones y de recursos. Los adaptadores de aplicaciones son componente interfaz con aplicaciones heredadas, mientras que los adaptadores de recursos realizan una traducción de datos existentes a formato utilizado por las entidades de negocio, gestionando la distribución (relación) de los datos (en diferentes aplicaciones, bases de datos, ubicaciones, etc.). Por otra parte, los niveles de distribución físicos indican cuál será la ubicación física de los diferentes componentes definidos por los niveles lógicos. En primer lugar se introduce el concepto de contenedor [2,6]. Un equipo físico puede albergar uno o más contenedores (un contenedor sólo podrá estar en un determinado equipo). Cada contenedor proporciona los servicios (capa middleware) y el entorno de ejecución adecuado para los diferentes componentes que se desplegarán en él. En principio, cada contenedor proporciona todos los servicios, sin embargo, en la práctica, podremos decidir proporcionar tan solo aquellos servicios que precisen los componentes a los cuales darán soporte. En cualquier caso, esto es sólo un problema de optimización de recursos. Una vez establecidos los contenedores adecuados para el despliegue de nuestra aplicación, resultará relativamente sencillo alcanzar los objetivos de distribución, escalabilidad, separación, etc., definidos anteriormente. Por ejemplo, si una vez desplegada nuestra aplicación nos encontramos con que el número de usuarios que acceden a la misma pasa, de los cientos para los que estaba prevista, a los millares, se puede duplicar los contenedores y servidores que los albergan y que estaban encargados de atender las solicitudes de los clientes. Otro ejemplo típico es el de modificaciones en la compañía bien por cambios organizativos internos, bien fruto de absorciones o remodelaciones, de forma que se podrá estudiar cuáles son los nuevos protocolos, casos de uso, reglas de negocio, etc., y actuar sobre los elementos afectados con el menor impacto posible sobre el resto del sistema. Infraestructuras de desarrollo La aplicación de las técnicas, modelos y arquitecturas propuestos supone un cambio de escala radical en el desarrollo de las aplicaciones de gestión. Esto hace que

18 la arquitectura técnica no pueda considerarse completa si no se complementa con aquellos elementos que facilitan su implementación así como la sistematización del proceso. Estos elementos se pueden clasificar en tres grandes apartados: marcos, servicios y patrones. Los marcos hacen referencia a entornos de desarrollo que proporcionen soluciones genéricas configurables (por ejemplo los entornos IDE) y que abarquen todas las fases del desarrollo de la aplicación y todos los niveles funcionales en los que esta se divida. Los servicios representas la infraestructura que permite a las aplicaciones utilizar funciones comunes (seguridad, comunicaciones, acceso a bases de datos, gráficas, etc.) sin que el desarrollador tenga que preocuparse de su implementación, mantenimiento o portabilidad. Los patrones pueden considerarse como plantillas que orientan sobre cómo resolver determinados problemas que aparecen de forma recurrente en el desarrollo de aplicaciones [10]. En la literatura se pueden encontrar patrones de diseño, patrones de integración, patrones de implantación, etc. Plataforma J2EE para soluciones empresariales Hoy en día el desarrollo de aplicaciones conlleva una mayor complejidad, debida principalmente a dos factores estrechamente relacionados. Por un lado, la aparición de requerimientos tecnológicos derivados de los nuevos modelos arquitectónicos comentados. Por otro lado, el número de características que una organización espera y exige que cumplan sus aplicaciones [6,2]. Entre las características y requerimientos necesarios encontramos. Productividad. Es un factor importante para las organizaciones. Las organizaciones cada día solicitan que el desarrollo y la implantación de las aplicaciones sean realizados en el menor tiempo posible y que el tiempo de vida de dichas aplicaciones sea cada vez mayor. Integración. Otro factor deseado es la capacidad de integración de las nuevas aplicaciones con sistemas heredados de la organización, que por su alto coste económico de realización (ERP) o por la importancia de la información almacenada a lo largo del tiempo no pueden ser desechados. Flexibilidad. Las aplicaciones deben adaptarse a los cambios derivados de los avances tecnológicos, sin tener que rediseñar la aplicación. Escalabilidad. Las aplicaciones deben ser capaces de adaptarse ante un crecimiento masivo de usuarios que acceden concurrentemente a dicha aplicación de una manera sencilla o evitar que dicho crecimiento afecte al rendimiento global de la aplicación. Seguridad. La información que mantienen las empresas es muy valiosa y si tenemos en cuenta que dicha información va a circular por entornos poco fiables y proclives a recibir ataques es necesaria la utilización de potentes mecanismos de seguridad en las aplicaciones. Por todas las razones mencionadas aparecen una serie de modelos de desarrollo basados en componentes que aprovechan sofisticadas plataformas de servicios,

19 haciendo que el desarrollo de todas estas aplicaciones sea posible. Si en cada aplicación hubiera que desarrollar estos servicios, necesarios por los requerimientos indicados, la realización de los proyectos no sería factible. Las dos plataformas más importantes en el mercado y con mayores cuotas de usuarios son J2EE y.net. Ambas plataformas satisfacen las necesidades requeridas anteriormente y nos ofrecen servicios equivalentes [13,14]. En la siguiente tabla podemos observar como para cada tecnología ofrecida por una plataforma, existe la equivalente en la otra. Tabla 1. Comparativa de la tecnología J2EE y.net J2EE.NET Componentes EJB.NET Component Mensajería JMS MSMQ Transacciones JTA MTS Acceso distribuido RMI RMI-IIOP.NET Remoting Conectores JCA Host Integration Server Biztalk Server Registro de componentes JNDI Active Directory Bases de datos JDBC ADO.NET Servicios web JAX-RPC.NET Framework Manejo XML JAXP MSXML Sin la existencia de estas plataformas no podríamos adaptarnos de una manera eficiente a los continuos cambios tecnológicos y afectaría directamente a los requerimientos especificados por las organizaciones [11] (productividad, flexibilidad, escalabilidad y seguridad entre otros). Hemos visto que.net y J2EE nos ofrecen soluciones equivalentes. A pesar de esto, no podemos comparar.net con J2EE. La filosofía de ambas es completamente diferente. Mientras que.net es una implementación propietaria de Microsoft como solución a la demanda de las organizaciones, J2EE está formada por un conjunto de especificaciones propuesta por grandes empresas y encabezadas por SUN. Estas especificaciones indican que requerimientos debe cumplir una plataforma J2EE para denominarse como tal. Podríamos comparar.net con una implementación J2EE de un proveedor específico. Esa es una de las ventajas que nos han llevado a optar por J2EE. Se trata de un estándar implementado por varios proveedores (sun, ibm, bea, oracle...) compatibles entre ellos. Esto nos proporciona un amplio abanico donde elegir y no restringirnos a un único proveedor [2]. Por otro lado aunque.net a nivel empresarial pueda ser más apetecible puesto que requiere, a lo mejor, de una menor curva de aprendizaje, J2EE es preferible a nivel universitario puesto que al ser más abierto puede derivar en temas de investigación interesantes para nuestra comunidad. Por último en el momento de tomar la decisión se tuvo en cuenta el tema de las licencias y el coste y puesto que en ese momento, en el cual se debía comenzar a trabajar, J2EE

20 nos ofrecía soluciones empresariales de código abierto se optó por esta solución. En los siguientes puntos veremos más a fondo la plataforma J2EE. Perspectiva general de J2EE La plataforma J2EE conforma un conjunto de especificaciones que nos proveen de servicios y componentes en todos los niveles de una arquitectura de n niveles. Existen componentes y servicios para la creación de aplicaciones clientes y para desarrollar grandes aplicaciones distribuidas de servidor. Estamos pues ante una plataforma de n niveles, donde los distintos módulos de la aplicación pueden correr en diferentes dispositivos. J2EE nos define el número de niveles de los que se compone la plataforma, pudiendo estos a su vez desdoblarse, y qué componentes debemos utilizar en cada nivel con los servicios proporcionados en dichos niveles [2]. Podemos observar que se trata de una plataforma de varios niveles. Vamos a realizar una enumeración de las principales características de J2EE [2]. Gestión de componentes basada en contenedores El contenedor es el elemento principal de la plataforma J2EE. Estos son entornos estándar de ejecución que proveen de servicios específicos a los componentes. Los contenedores nos ofrecen mecanismos que nos permiten modificar el comportamiento de los componentes con simples ficheros XML de configuración en el momento de despliegue de la aplicación. Además este despliegue se realizará en caliente, sin la necesidad de parar la aplicación [2]. J2EE nos define el número de contenedores que una implementación J2EE debería soportar pero no especifica como el proveedor deberá implementar la configuración de los componentes [2]. Por ello si cambiamos de proveedor J2EE deberemos aprender como funciona la configuración del nuevo proveedor.

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

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

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

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

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

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

Más detalles

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

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

Diseño del Sistema de Información

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

Más detalles

Diseño del Sistema de Información

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

Más detalles

Arquitectura. 1.- Aplicaciones Web. Definición. Arquitectura clásica. Contenidos. 1.- Aplicaciones Web

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

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización

Más detalles

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

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

Más detalles

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

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

Notas técnicas de JAVA Nro. 7 Tip Breve

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

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

II Curso Online JAVA-J2EE

II Curso Online JAVA-J2EE II Curso Online JAVA-J2EE TEMA 3 Introducción a J2EE Autor: PCYTA / Centro de Excelencia de Software Libre de Castilla-La Mancha Versión: 1.0 Fecha: Revisado 13-02-2008 23:56 Licencia: CC-by-sa 2.5 0 Licencia

Más detalles

INTRODUCCIÓN A LA TECNOLOGÍA.NET

INTRODUCCIÓN A LA TECNOLOGÍA.NET INTRODUCCIÓN A LA TECNOLOGÍA.NET CONTENIDO 1.1 Definición de.net 1.2 Evolución de.net 1.3 Compatibilidad de.net con Sistemas Operativos 1.4 Componentes de la plataforma.net MONICA CECILIA GALLEGOS VARELA

Más detalles

5.1. Qué es Internet? controla todo el sistema, pero está conectado de tal manera que hace

5.1. Qué es Internet? controla todo el sistema, pero está conectado de tal manera que hace 5. Internet 5.1. Qué es Internet? Internet es una red mundial de equipos que se comunican usando un lenguaje común. Es similar al sistema telefónico internacional: nadie posee ni controla todo el sistema,

Más detalles

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Página 1 de 21 CUALIFICACIÓN DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC154_3 Versión 5 Situación RD 1087/2005 Actualización

Más detalles

Facultad de Sistemas e Informática

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

Más detalles

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

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

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 septiembre 2011 FJRP, FMBR 2008-2011 ccia SCS 5.1 Introducción a Java EE Java EE (Java Enterprise

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

Panorámica de la asignatura

Panorámica de la asignatura Arquitecturas típicas. Mario Muñoz Organero Departamento de Ingeniería Telemática http://www.it.uc3m.es/mario Panorámica de la asignatura RED Comunicaciones Servidores información Intercambio de datos

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

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

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

Más detalles

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

Características de OpenCms

Características de OpenCms Características de OpenCms Se basa en Java y Xml OpenCms está totalmente desarrollado en java bajo el estándar servlet. Por lo tanto, se puede integrar fácilmente en entornos hardware y software existentes,

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

Antes de imprimir este documento piense en el medio ambiente!

Antes de imprimir este documento piense en el medio ambiente! Versión 1.0 Página 1 de 14 1. OBJETIVO: Suministrar la metodología que se aplicará para la estimación de esfuerzo para los desarrollos nuevos en el ICBF, para lo cual se detallan los aspectos a tener en

Más detalles

Tema 1. Introducción a Java EE

Tema 1. Introducción a Java EE Objetivos del tema Propiedades de las aplicaciones empresariales El Modelo Cliente/Servidor Presentar la Plataforma Java Presentar Java EE y otras tecnologías horizontales Tema 1. Introducción a Java EE

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

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

Aproximación al CONCEPTO

Aproximación al CONCEPTO 18 Aproximación al CONCEPTO LA NECESIDAD DE INTERCAMBIAR INFORMACIÓN ENTRE DEPARTAMENTOS Y ÁREAS DE NEGOCIO SE HA VUELTO CRUCIAL Y HA HECHO QUE LAS EMPRESAS VEAN LA INTEGRACIÓN COMO UN ELEMENTO CLAVE PARA

Más detalles

Diseño CRM MV Xestión

Diseño CRM MV Xestión Diseño CRM/09008 Mayo 2009 Diseño CRM MV Xestión Índice 1 Introducción...3 2 Arquitectura...4 2.1 Servidor LDAP OpenLDAP...6 2.2 Servidor Web Apache 2.2...7 2.3 Intérprete de PHP...8 2.4 Servidor de Base

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

El Framework de desarrollo del Consejo

El Framework de desarrollo del Consejo El Framework de desarrollo del Consejo Superior de Investigaciones Científicas Director de la OPCSIC Centro Técnico de Informática (CSIC) Directora Centro Técnico de Informática (CSIC) Palabras clave Framework,

Más detalles

Introducción a Javato

Introducción a Javato Introducción a Javato Fº. Javier Pereñiguez Steria Iberica 20/02/2008 Índice Introducción Arquitectura Ejemplo arquitectura Plataforma Desarrollo Ejemplo de entorno de desarrollo Vías futuras Casos de

Más detalles

Capítulo III. Análisis y diseño.

Capítulo III. Análisis y diseño. Capítulo III. Análisis y diseño. 3.1 Análisis. El análisis es el intermediario entre los requisitos del sistema y el diseño, esta sección definiremos el análisis con una serie de modelos técnicos del sistema,

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

Aplicaciones web construidas a base de componentes:

Aplicaciones web construidas a base de componentes: Java EE Aplicaciones Web/Sistemas Web Juan Pavón Mestras Dep. Ingeniería del Software e Inteligencia Artificial Facultad de Informática Universidad Complutense Madrid Material bajo licencia Creative Commons

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

Desarrollo de Rich Entreprise Applications con Flex

Desarrollo de Rich Entreprise Applications con Flex Desarrollo de Rich Entreprise Applications con Flex Desarrollo de Rich Entreprise Applications con Flex Aplicaciones empresariales orientadas a web. Qué hemos ganado con las aplicaciones web Total ubicuidad.

Más detalles

Trabajo Final de Graduación para optar por el título. Bachiller en Ingeniería en Computación

Trabajo Final de Graduación para optar por el título. Bachiller en Ingeniería en Computación Trabajo Final de Graduación para optar por el título Bachiller en Ingeniería en Computación Migración del Módulo de Inventario del Sistema Business Advance Víctor Guzmán Alfaro Carrera Ingeniería en Computación

Más detalles

Desarrollo de Grandes Aplicaciones de Gestión de Red: Decisiones generales de diseño

Desarrollo de Grandes Aplicaciones de Gestión de Red: Decisiones generales de diseño Desarrollo de Grandes Aplicaciones de Gestión de Red: Decisiones generales de diseño Antonio Hernández Sáez 1 y Virgilio Gilart Iglesias 2 1 Escuela Politécnica Superior, Universidad de Alicante 036 90,

Más detalles

White Paper Help Desk Intranet

White Paper Help Desk Intranet 2004 Koala Developers Versión del documento: 2.0.8 White Paper Help Desk Intranet Autor: Departamento de Comercialización Última modificación: Abril de 2004 1 Contenido 2 Quién debería leer este documento?...3

Más detalles

http://www.cem.itesm.mx/extension/ms

http://www.cem.itesm.mx/extension/ms Diplomado Programación orientada a objetos con Java y UML Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos

Más detalles

Capítulo I. Marco Teórico

Capítulo I. Marco Teórico 1 Capítulo I. Marco Teórico 1. Justificación Hoy en día existe una gran diversidad de aplicaciones que corren sobre la World Wide Web (WWW o Web), y cada una orientada a un fin en particular, el cuál depende

Más detalles

Selección de arquitecturas y herramientas de programación

Selección de arquitecturas y herramientas de programación 1 Selección de arquitecturas y herramientas de programación Objetivos del capítulo 44 Caracterizar y diferenciar los modelos de ejecución de código en un entorno cliente/servidor. 44 Conocer los mecanismos

Más detalles

Herramientas de Software que posibilitan el BPM

Herramientas de Software que posibilitan el BPM Qué es BPM? BPM (Business Process Management) no es solamente una tecnología, sino en términos generales, una disciplina gerencial que trata a los procesos como bienes tangibles que contribuyen al desempeño

Más detalles

JAVA 2 ENTERPRISE EDITION

JAVA 2 ENTERPRISE EDITION JAVA 2 ENTERPRISE EDITION Jon Castro Jonathan Escolano Índice Arquitecturas características de las aplicaciones empresariales Tecnologías J2EE Alternativas a J2EE Tecnologías de integración de aplicaciones

Más detalles

Tema 2: EL MODELO CLIENTE/SERVIDOR

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

Más detalles

Introducción a la plataforma.net

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

Más detalles

Indice 1. Introducción a la computación en nube (cloud computing)

Indice 1. Introducción a la computación en nube (cloud computing) Tema 9. Centros de datos: computación en nube y organización física Indice 1. Introducción a la computación en nube (cloud computing) 2. Virtualización de recursos: consolidación de servidores 3. Arquitectura

Más detalles

Tema 47. Las herramientas ofimáticas. Integración con sistemas de información estructurada.

Tema 47. Las herramientas ofimáticas. Integración con sistemas de información estructurada. Tema 47. Las herramientas ofimáticas. Integración con sistemas de información estructurada. Esquema Introducción... 2 Historia... 2 Suites... 2 Herramientas ofimáticas... 3 Tipos de programas ofimáticos:...

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

Novedades en Crystal Reports 10

Novedades en Crystal Reports 10 Novedades en Crystal Reports 10 Basado en la estabilidad probada de la versión 9, Crystal Reports ofrece nuevas funciones y mejoras. Este capítulo presenta dichas funciones y mejoras proporcionando un

Más detalles

JAVA ENTERPRISE EDITION (J2EE) ARQUITECTURA TECNOLOGÍAS (1/2) (L1)

JAVA ENTERPRISE EDITION (J2EE) ARQUITECTURA TECNOLOGÍAS (1/2) (L1) TECNOLOGÍAS (1/2) (L1) EJB ( Enterprise Java Beans ) JSP ( Java Server Pages ) JNDI ( Java Naming and Directory Interface ) JDBC ( Java Data Base Connectivity ) Java Mail JSF ( Java Server Faces ) TECNOLOGÍAS

Más detalles

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com

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

Más detalles

Cómo puede ayudarle JBuilder en sus Desarrollos Java?

Cómo puede ayudarle JBuilder en sus Desarrollos Java? Artículos técnicos Grupo Danysoft: Cómo puede ayudarle JBuilder en sus Desarrollos Java? Oscar Cristóbal Ruiz Departamento Java Equipo Grupo Danysoft Enero 2003 - (902) 123146 www.danysoft.com Cómo puede

Más detalles

1. Aplicaciones N -Capas 2. J2EE 3. Comparativa J2ee y Microsoft.Net. Internet Explorador. Internet. Netscape. Servidor Web. Opera.

1. Aplicaciones N -Capas 2. J2EE 3. Comparativa J2ee y Microsoft.Net. Internet Explorador. Internet. Netscape. Servidor Web. Opera. I Buscando Información Internet Explorador Netscape Consulta en Banca E -learning Internet Recibe Peticiones Envió de Respuestas Servidor Web Opera 1. Aplicaciones N -Capas 2. J2EE 3. Comparativa J2ee

Más detalles

5 Aplicaciones empresariales con tecnología java EE.

5 Aplicaciones empresariales con tecnología java EE. 5 Aplicaciones empresariales con tecnología java EE. Esta tesis aborda la creación de una aplicación empresarial, pero, a qué se refiere el término de aplicación empresarial? En esencia, las aplicaciones

Más detalles

Diplomado Java. Descripción. Objetivo. A quien está dirigido. Requisitos. Beneficios

Diplomado Java. Descripción. Objetivo. A quien está dirigido. Requisitos. Beneficios Diplomado Java Descripción El lenguaje de programación Java es uno de los más utilizados hoy en día. Su potencia, simplicidad, funcionalidad y capacidad hacen que este lenguaje sea una de las herramientas

Más detalles

ÍNDICE 1 LA NUEVA EDICIÓN DE QUIVIR...1 1.1 ENTORNO WEB...2 1.2 FIABILIDAD Y ROBUSTEZ...4 2 WEBFACING...6 3 MÁS VENTAJAS DEL USO DE LA EDICIÓN WEB...

ÍNDICE 1 LA NUEVA EDICIÓN DE QUIVIR...1 1.1 ENTORNO WEB...2 1.2 FIABILIDAD Y ROBUSTEZ...4 2 WEBFACING...6 3 MÁS VENTAJAS DEL USO DE LA EDICIÓN WEB... QUIVIR WEB EDITION ÍNDICE 1 LA NUEVA EDICIÓN DE QUIVIR...1 1.1 ENTORNO WEB...2 1.2 FIABILIDAD Y ROBUSTEZ...4 2 WEBFACING...6 3 MÁS VENTAJAS DEL USO DE LA EDICIÓN WEB...8 4 CONCLUSIONES FINALES...10 Página

Más detalles

Ciclo Formativo de Grado Superior Desarrollo de Aplicaciones Web

Ciclo Formativo de Grado Superior Desarrollo de Aplicaciones Web Ciclo Formativo de Grado Superior Desarrollo de Aplicaciones Web Proyecto Propio de Ampliación con Programación de Dispositivos Móviles e Inteligentes Paseo de la Puerta del Ángel, s/n 28011 Madrid www.iesellago.net

Más detalles

Tema 4. Diseño arquitectónico.

Tema 4. Diseño arquitectónico. Tema 4. Diseño arquitectónico. Introducción, Objetivos del Diseño. Ingeniería del Software II 2011 Para la transformación del modelo de análisis en un modelo de diseño del sistema, se definen los objetivos

Más detalles

Aplicaciones Distribuidas. Informática III

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

Más detalles

Cursos PROGRAMACIÓN DE APLICACIONES CON JAVA

Cursos PROGRAMACIÓN DE APLICACIONES CON JAVA Cursos CIÓN DE APLICACIONES CON JAVA OBJETIVOS Los cursos ofrecen al alumno fundamentos muy sólidos en la Plataformas de desarrollo Java, no solo en aspectos concretos (lenguaje java, paquetes disponibles,

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

Servidores web. Qué es un servidor web? Tipos de servidores. Lic. Lorena Bernis

Servidores web. Qué es un servidor web? Tipos de servidores. Lic. Lorena Bernis Servidores web Qué es un servidor web? Tipos de servidores. Lic. Lorena Bernis Servidores web 2 SERVIDOR En informática, un servidor es un tipo de software que realiza ciertas tareas en nombre de los usuarios.

Más detalles

Maestría en Ingeniería de Software. Sistemas Distribuidos en Web I. MCC. Carlos Albeto Ochoa Rivera

Maestría en Ingeniería de Software. Sistemas Distribuidos en Web I. MCC. Carlos Albeto Ochoa Rivera Maestría en Ingeniería de Software Sistemas Distribuidos en Web I MCC. Carlos Albeto Ochoa Rivera Descripción general Actualmente existe la tendencia de desarrollo de software que trabaje en un ambiente

Más detalles

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15

Más detalles

Bases de Datos Distribuidas: Arquitectura Cliente/Servidor

Bases de Datos Distribuidas: Arquitectura Cliente/Servidor Bases de Datos Distribuidas: Arquitectura Cliente/Servidor Instituto Tecnológico Superior de los Ríos Ing. en Sistemas Computacionales 30 de enero de 2012 Bases de Datos Distribuidas:Arquitectura Cliente/Servidor

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

Sistema de gestión de tareas y proyectos

Sistema de gestión de tareas y proyectos Sistema de gestión de tareas y proyectos Propuesta de proyecto Seminario de Informática I Luis Muñoz Enrique Viard Contenido Introducción... 3 Descripción general... 3 Arquitectura propuesta... 5 Requisitos...

Más detalles

CAPITULO 3 MOVILIDAD EN LA NAVEGACIÓN Y ALMACENAMIENTO EN BASES DE DATOS

CAPITULO 3 MOVILIDAD EN LA NAVEGACIÓN Y ALMACENAMIENTO EN BASES DE DATOS CAPITULO 3 MOVILIDAD EN LA NAVEGACIÓN Y ALMACENAMIENTO EN BASES DE DATOS La introducción de las redes locales marca una nueva etapa en la evolución de las computadoras personales al permitir ligar varias

Más detalles

ADMINISTRACIÓN Y PROGRAMACIÓN EN SISTEMAS DE PLANIFICACIÓN DE RECURSOS EMPRESARIALES Y DE GESTIÓN DE RELACIONES CON CLIENTES CUALIFICACIÓN PROFESIONAL

ADMINISTRACIÓN Y PROGRAMACIÓN EN SISTEMAS DE PLANIFICACIÓN DE RECURSOS EMPRESARIALES Y DE GESTIÓN DE RELACIONES CON CLIENTES CUALIFICACIÓN PROFESIONAL Página 1 de 23 CUALIFICACIÓN PROFESIONAL Familia Profesional Nivel 3 Código IFC363_3 Versión 5 Situación RD 1701/2007 Actualización ADMINISTRACIÓN Y PROGRAMACIÓN EN SISTEMAS DE PLANIFICACIÓN DE RECURSOS

Más detalles

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

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

Más detalles

Proyecto ELO-330 Administración Salas del Departamento de Electrónica RC1. Gerardo Lecaros Felipe Díaz

Proyecto ELO-330 Administración Salas del Departamento de Electrónica RC1. Gerardo Lecaros Felipe Díaz Proyecto ELO-330 Administración Salas del Departamento de Electrónica RC1 Gerardo Lecaros Felipe Díaz Problemática Petición de salas de forma tradicional Solución J2EE Java 2 Platform, Enterprise Edition

Más detalles

Guía Funcional del Módulo de Integración con Sistemas Heredados. Versión 5.1.0

Guía Funcional del Módulo de Integración con Sistemas Heredados. Versión 5.1.0 Guía Funcional del Módulo de Integración con Sistemas Heredados Versión 5.1.0 1. Introducción Una buena definición de un sistema heredado se puede encontrar en el Omnibus Lexicon http://www.fourthwavegroup.com/publicx/1301w.htm.

Más detalles

Unidad V: Programación del lado del servidor

Unidad V: Programación del lado del servidor Unidad V: Programación del lado del servidor 5.1 Introducción al lenguaje La Programación del lado del servidor es una tecnología que consiste en el procesamiento de una petición de un usuario mediante

Más detalles

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

Curso de Java EE Todos los Derechos Reservados Global Mentoring Experiencia y Conocimiento para tu Vida 1 1 Los Enterprise Java Beans (EJB) es código Java del lado del Servidor. Normalmente tienen la lógica de negocio de nuestra aplicación, y por lo tanto cubren el rol de la capa de servicio de nuestras aplicaciones

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

6.1 Introducción a los sistemas EAI

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

Más detalles

Qué es una aplicación web

Qué es una aplicación web Departamento de Lenguajes y Sistemas Informáticos Qué es una aplicación web Programación en Internet Curso 2006-2007 Índice Introducción Cliente Servidor Transferencia páginas web Entornos web Ventajas

Más detalles

INTRODUCCIÓN AL WEB. Pag. 1 de 10

INTRODUCCIÓN AL WEB. Pag. 1 de 10 INTRODUCCIÓN AL WEB La World Wide Web o simplemente WWW o Web es uno de los métodos más importantes de comunicación que existe en Internet. Consiste en un sistema de información basado en Hipertexto (texto

Más detalles

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

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

Más detalles

DATOS IDENTIFICATIVOS DEL MÓDULO FORMATIVO IMPLANTACIÓN DE APLICACIONES WEB EN ENTORNO INTERNET, INTRANET Y EXTRANET.

DATOS IDENTIFICATIVOS DEL MÓDULO FORMATIVO IMPLANTACIÓN DE APLICACIONES WEB EN ENTORNO INTERNET, INTRANET Y EXTRANET. MÓDULO FORMATIVO DATOS IDENTIFICATIVOS DEL MÓDULO FORMATIVO IMPLANTACIÓN DE APLICACIONES WEB EN ENTORNO INTERNET, INTRANET Y EXTRANET. Duración 90 Código MF0493_3 Familia profesional INFORMÁTICA Y COMUNICACIONES

Más detalles

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

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

Más detalles

Módulo Profesional 01: Bases de datos (código: 0484).

Módulo Profesional 01: Bases de datos (código: 0484). Módulo Profesional 01: Bases de datos (código: 0484). Actividades de enseñanza-aprendizaje que permiten alcanzar los objetivos del módulo. Interpretar diseños lógicos de bases de datos. Realizar el diseño

Más detalles

El servidor Web. Arquitectura y funcionamiento

El servidor Web. Arquitectura y funcionamiento El servidor Web. Arquitectura y funcionamiento ÍNDICE INTRODUCCIÓN Qué es un servidor? Y un servidor Web? FUNCIONAMIENTO DE UN SERVIDOR WEB Arquitectura Tipos de servidores Web Servidores basados en procesos

Más detalles

Servlets. Unidad: 4 Laboratorio de Programación. Universidad Nacional de la Patagonia Austral Unidad Académica Río Gallegos

Servlets. Unidad: 4 Laboratorio de Programación. Universidad Nacional de la Patagonia Austral Unidad Académica Río Gallegos Servlets Unidad: 4 Laboratorio de Programación Universidad Nacional de la Patagonia Austral Unidad Académica Río Gallegos Indice Introducción CGI Servlets: concepto, caracteristicas Servlets Vs. CGI Ciclo

Más detalles

CORPORACIÓN MEXICANA DE INVESTIGACIÓN EN MATERIALES, S.A. DE CV

CORPORACIÓN MEXICANA DE INVESTIGACIÓN EN MATERIALES, S.A. DE CV Página 1 de 6 1. OBJETIVO El presente documento tiene la finalidad de citar los beneficios de la migración de la herramienta de análisis de riesgo, mantenimiento e inspección que en lo sucesivo se denominará

Más detalles

Tema 1: Introducción a Java EE

Tema 1: Introducción a Java EE Tema 1: Introducción a Java EE Índice Arquitecturas características de las aplicaciones empresariales Tecnologías J2EE Alternativas a J2EE Patrones arquitectónicos Model-View-Controller y Layers Recursos

Más detalles

Programación con PHP y MySql Instituto CBTech 5/14

Programación con PHP y MySql Instituto CBTech 5/14 Programación con PHP y MySql Instituto CBTech 5/14 Programación con PHP y MySql Instituto CBTech 6/14 Qué es una aplicación web? Una aplicación web es un sistema informático que los usuarios utilizan accediendo

Más detalles

Sistemas Operativos Distribuidos. Introducción a los Servicios Web (Web Services)

Sistemas Operativos Distribuidos. Introducción a los Servicios Web (Web Services) Introducción a los Servicios Web (Web Services) 2 Evolución de la Web Pasado: Web de documentos Páginas estáticas Web como un enorme repositorio de información Tecnologías: HTTP + HTML Presente: Web de

Más detalles