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

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

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

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

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

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

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

Ingeniería de Software

Ingeniería de Software Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6

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

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

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

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

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

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

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

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

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

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

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

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

Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia

Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia Implantación de una arquitectura orientada a servicios. Un caso de uso Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia Introducción Los compromisos

Más detalles

Implantación de Aplicaciones Web Fecha: 20-09-13

Implantación de Aplicaciones Web Fecha: 20-09-13 Página 1 de 24 RESUMEN DE LA PROGRAMACIÓN ADMINISTRACIÓN DE SISTEMAS INFORMÁTICOS EN RED CURSO AC. 2012 / 2013 ÁREA / MATERIA / MÓDULO PROFESIONAL Implantación de Aplicaciones Web (84 horas 4 horas semanales)

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

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

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

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente.

Más detalles

CAPÍTULO 3 VISUAL BASIC

CAPÍTULO 3 VISUAL BASIC CAPÍTULO 3 VISUAL BASIC 3.1 Visual Basic Microsoft Visual Basic es la actual y mejor representación del viejo lenguaje BASIC, le proporciona un sistema completo para el desarrollo de aplicaciones para

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

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

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

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

I. E. S. Cristóbal de Monroy. DEPARTAMENTO: Informática. MATERIA: Aplicaciones Web. NIVEL: 2º Sistemas Microinformáticos y Redes

I. E. S. Cristóbal de Monroy. DEPARTAMENTO: Informática. MATERIA: Aplicaciones Web. NIVEL: 2º Sistemas Microinformáticos y Redes DEPARTAMENTO: Informática MATERIA: Aplicaciones Web NIVEL: 2º Sistemas Microinformáticos y Redes 1. Objetivos. Competencias Profesionales, Personales y Sociales 1.1 Objetivos del ciclo formativo Según

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

Windows Server 2003. Windows Server 2003

Windows Server 2003. Windows Server 2003 Windows Server 2003 Windows Server 2003 Es un sistema operativo de la familia Windows de la marca Microsoft para servidores que salió al mercado en el año 2003. Está basada en tecnología NT y su versión

Más detalles

Arquitectura de Aplicaciones Empresariales. Lic. Esteban Cesar Calabria

Arquitectura de Aplicaciones Empresariales. Lic. Esteban Cesar Calabria Arquitectura de Aplicaciones Empresariales Aplicaciones empresariales Temario Aplicaciones Empresariales Arquitectura Aplicaciones Empresariales Layering Negocio Persistencia Presentación Ejemplos Aplicaciones

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

TEMA: PROTOCOLOS TCP/IP

TEMA: PROTOCOLOS TCP/IP TEMA: PROTOCOLOS TCP/IP HISTORIA: El Protocolo de Internet (IP) y el Protocolo de Transmisión (TCP), fueron desarrollados inicialmente en 1973 por el informático estadounidense Vinton Cerf como parte de

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

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

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

Plataforma de Administración Electrónica de la Comunidad Autónoma de la Región de

Plataforma de Administración Electrónica de la Comunidad Autónoma de la Región de Plataforma de Administración Electrónica de la Comunidad Autónoma de la Región de Murcia Director General de Informática Consejería de Economía y Hacienda Comunidad Autónoma de la Región de Murcia Jefe

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

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

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

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

ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS

ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS Base de Datos ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS Una base de datos es un conjunto de elementos de datos que se describe a sí mismo, con relaciones entre esos elementos, que presenta

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

INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2

INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2 Programa de Capacitación y Certificación. INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2 Contenido PERFIL DE UN ESPECIALISTA EN BASES DE DATOS.... 3 6231. MANTENIENDO UNA BASE DE DATOS DE SQL SERVER 2008

Más detalles

Ofrezca la nueva tendencia de innovación empresarial con un entorno de red abierta

Ofrezca la nueva tendencia de innovación empresarial con un entorno de red abierta Descripción general de la solución Ofrezca la nueva tendencia de innovación empresarial con un entorno de red abierta Lo que aprenderá A medida que tecnologías como la nube, la movilidad, los medios sociales

Más 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

http://www.ips.es/webintranets/html/vision.html

http://www.ips.es/webintranets/html/vision.html Página 1 de 5 Nuestra Visión sobre Intranets INTRANETS: NUESTRA VISIÓN 1. Qué son? 2. Qué servicios prestan? 2.1. Tipos de servicios Servicios de Usuarios Servicios de Red 3. Intranet y las Redes de Area

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

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

ACCESS 2010 OFIMÁTICA AULA MENTOR

ACCESS 2010 OFIMÁTICA AULA MENTOR ACCESS 2010 OFIMÁTICA AULA MENTOR Módulo I: Introducción UNIDADES DIDÁCTICAS: 1. Unidad didáctica 1 2 Introducción a las Bases de Datos 2. Unidad didáctica 2 10 Comenzar a trabajar con Access Página 1

Más detalles

LA COLABORACIÓN, UNA REALIDAD GRACIAS A LA ARQUITECTURA TECNOLÓGICA HP EGOVERNMENT FRAMEWORK

LA COLABORACIÓN, UNA REALIDAD GRACIAS A LA ARQUITECTURA TECNOLÓGICA HP EGOVERNMENT FRAMEWORK 1 LA COLABORACIÓN, UNA REALIDAD GRACIAS A LA ARQUITECTURA TECNOLÓGICA HP EGOVERNMENT FRAMEWORK Miguel Angel Abellán Juliá Gerente de Soluciones para Administraciones Públicas. Hewlett-Packard Española,

Más detalles

1. Instala servicios de configuración dinámica, describiendo sus características y aplicaciones.

1. Instala servicios de configuración dinámica, describiendo sus características y aplicaciones. Módulo Profesional: Servicios en Red. Código: 0227. Resultados de aprendizaje y criterios de evaluación. 1. Instala servicios de configuración dinámica, describiendo sus características y aplicaciones.

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

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

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

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

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

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

Más detalles

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

Bienvenidos a la presentación: Introducción a conceptos básicos de programación.

Bienvenidos a la presentación: Introducción a conceptos básicos de programación. Bienvenidos a la presentación: Introducción a conceptos básicos de programación. 1 Los programas de computadora son una serie de instrucciones que le dicen a una computadora qué hacer exactamente. Los

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

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

aspectos y no estaríamos donde estamos hoy, si hubiéramos utilizado otra herramienta.

aspectos y no estaríamos donde estamos hoy, si hubiéramos utilizado otra herramienta. 4D es una plataforma de aplicación Web, flexible, potente y muy escalable. Este documento examina los requerimientos comunes para servidores de aplicación Web, y discute las ventajas ofrecidas por la línea

Más detalles

Despliegue de plataforma Q-expeditive

Despliegue de plataforma Q-expeditive How to Despliegue de plataforma Q-expeditive Versión: 2.0 Fecha de publicación 08-04-2011 Aplica a: Q-expeditive 3.0 y Q-flow 3.1 Índice Requerimientos de Software... 4 Diagramas de arquitectura... 5 Componentes

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

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

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

mope PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS Página 0 PASEO GENERAL MARTINEZ CAMPOS 20 28010 MADRID 91 752 79 59 www.mope.es info@mope.

mope PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS Página 0 PASEO GENERAL MARTINEZ CAMPOS 20 28010 MADRID 91 752 79 59 www.mope.es info@mope. DENOMINACIÓN: Código: IFCT0609 Familia profesional: Informática y Comunicaciones Área profesional: Sistemas y telemática Nivel de cualificación profesional: 3 Cualificación profesional de referencia: IFC303_3

Más detalles

5. MODELOS DE CLIENTE Y SERVIDOR ORIENTADOS A AGENTES MÓVILES

5. MODELOS DE CLIENTE Y SERVIDOR ORIENTADOS A AGENTES MÓVILES SISTEMAS DISTRIBUIDOS DE REDES 5. MODELOS DE CLIENTE Y SERVIDOR ORIENTADOS A AGENTES MÓVILES Programación remota: Introducción y generalidades INTRODUCCIÓN Debido a la dificultad de la arquitectura actual

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

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

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

Modelo de Gestión de Expedientes y Centros de Atención al Ciudadano basado en Tecnologías de Workflow/Gestión Documental

Modelo de Gestión de Expedientes y Centros de Atención al Ciudadano basado en Tecnologías de Workflow/Gestión Documental Modelo de Gestión de Expedientes y Centros de Atención al Ciudadano basado en Tecnologías de Workflow/Gestión Documental Autores: Reinerio Villa Alvarez Alejandro Morán Marco INDICE 1 INTRODUCCIÓN 3 2

Más detalles

NUEVA WEB DE LA CONSEJERÍA DE INNOVACIÓN, CIENCIA Y EMPRESA: LA INNOVACIÓN COMO NEXO COMÚN DE UN DESARROLLO WEB

NUEVA WEB DE LA CONSEJERÍA DE INNOVACIÓN, CIENCIA Y EMPRESA: LA INNOVACIÓN COMO NEXO COMÚN DE UN DESARROLLO WEB NUEVA WEB DE LA CONSEJERÍA DE INNOVACIÓN, CIENCIA Y EMPRESA: LA INNOVACIÓN COMO NEXO COMÚN DE UN DESARROLLO WEB Jefe del Servicio de Informática Consejería de Innovación, Ciencia y Empresa Jefe de Proyectos

Más detalles

Arquitectura de desarrollo Fomento.Net

Arquitectura de desarrollo Fomento.Net Casos de éxito everis Arquitectura de desarrollo Fomento.Net Resumen País: España. Sector: Administración. Perfil del Cliente Subdirección General de Tecnologías y Sistemas de la Información (SGTSI) del

Más detalles

BOLETÍN DE NOVEDADES Barcelona, junio de 2008

BOLETÍN DE NOVEDADES Barcelona, junio de 2008 BOLETÍN DE NOVEDADES Barcelona, junio de 2008 Introducción El objeto de este documento es presentar y describir brevemente las principales actuaciones en los últimos meses de Carver en algunos de sus clientes,

Más detalles

Comunicación entre procesos

Comunicación entre procesos Comunicación entre procesos Patrones de comunicación Comunicación cliente-servidor En la que los mensajes de petición y respuesta proporcionan la base para la invocación remota de métodos o de procedimientos.

Más detalles

RESUMEN INFORMATIVO PROGRAMACIÓN DIDÁCTICA CURSO 2013/2014

RESUMEN INFORMATIVO PROGRAMACIÓN DIDÁCTICA CURSO 2013/2014 RESUMEN INFORMATIVO PROGRAMACIÓN DIDÁCTICA CURSO 2013/2014 FAMILIA PROFESIONAL: INFORMATICA Y COMUNICACIONES MATERIA: 28. DESARROLLO WEB EN ENTORNO SERVIDOR CURSO: 2º DE CFGS DESARROLLO DE APLICACIONES

Más detalles

MS_20489 Developing Microsoft SharePoint Server 2013 Advanced Solutions

MS_20489 Developing Microsoft SharePoint Server 2013 Advanced Solutions S MS_20489 Developing Microsoft SharePoint Server 2013 Advanced Solutions www.ked.com.mx Av. Revolución No. 374 Col. San Pedro de los Pinos, C.P. 03800, México, D.F. Tel/Fax: 52785560 Introducción Este

Más detalles

ENCUENTA - CONTABILIDAD Net. Definiciones generales

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

Más detalles

TFC J2EE. Aplicación Web para la gestión de facturación de una empresa de cerrajería. Sara Gutiérrez Melero ITIG Junio de 2012

TFC J2EE. Aplicación Web para la gestión de facturación de una empresa de cerrajería. Sara Gutiérrez Melero ITIG Junio de 2012 TFC J2EE Aplicación Web para la gestión de facturación de una empresa de cerrajería Sara Gutiérrez Melero ITIG Junio de 2012 Consultor: Jose Juan Rodriguez Índice 1. Introducción Objetivos Planificación

Más detalles

Módulo 2. Arquitectura

Módulo 2. Arquitectura Módulo 2. Arquitectura Introducción Objetivos o Analizar la arquitectura física y lógica de la plataforma Agrega. o Identificar los componentes más importantes de la arquitectura física. o Exponer las

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

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

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

Arquitectura y Diseño de la Solución

Arquitectura y Diseño de la Solución Arquitectura y Diseño de la Solución Recuento de Conceptos importantes Modelamiente / Versionamiento de trámites Vista Conceptual Subsistemas Funcionales Principales Detalle de los subsistemas Vista de

Más detalles

PLATAFORMA DE DESARROLLO DE APLICACIONES EN.NET. AdviserDev

PLATAFORMA DE DESARROLLO DE APLICACIONES EN.NET. AdviserDev PLATAFORMA DE DESARROLLO DE APLICACIONES EN.NET Qué es? AdviserDev Es un Framework o Plataforma, para desarrollar aplicaciones en.net En un principio fue creada para el desarrollo de nuestras propias aplicaciones

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

MS_20488 Developing Microsoft SharePoint Server 2013 Core Solutions

MS_20488 Developing Microsoft SharePoint Server 2013 Core Solutions S MS_20488 Developing Microsoft SharePoint Server 2013 Core Solutions www.ked.com.mx Av. Revolución No. 374 Col. San Pedro de los Pinos, C.P. 03800, México, D.F. Tel/Fax: 52785560 Introducción En este

Más detalles

1. Objetivos generales del título

1. Objetivos generales del título 1. Objetivos generales del título a) Organizar los componentes físicos y lógicos que forman un sistema microinformático, interpretando su documentación técnica, para aplicar los medios y métodos adecuados

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

Servicios de infraestructura. Aplicaciones web

Servicios de infraestructura. Aplicaciones web 10 Julio 2013 Servicios de infraestructura Compílela o tráigala y nosotros la ejecutamos Windows Azure proporciona infraestructura a petición que se escala y se adapta a las necesidades cambiantes de cada

Más detalles

ESTUDIO SOBRE EL ESTADO ACTUAL DE LAS HERRAMIENTAS E-BUSINESS

ESTUDIO SOBRE EL ESTADO ACTUAL DE LAS HERRAMIENTAS E-BUSINESS ESTUDIO SOBRE EL ESTADO ACTUAL DE LAS HERRAMIENTAS E-BUSINESS Fecha: 28-08-2006 1 ÍNDICE 1.-Introducción 2.-Objetivo 3.-Herramientas E-Business 3.1.-Conceptos Generales 3.2.-Características principales

Más detalles