Arquitectura de las aplicaciones Web

Transcripción

1 Arquitectura de las aplicaciones Web A BRAHAM SÁNCHEZ LÓPEZ GRUPO MOVIS FCC-BUAP

2 Arquitectura de las aplicaciones Web 2 El número impresionante de productos y tecnologías vinculados a Internet disponibles actualmente dio origen a numerosas arquitecturas de aplicación Web, múltiples y variadas. Sin embargo, una aplicación de e-comercio bien realizada (analizada y diseñada) implica la existencia de al menos cuatro componentes de arquitectura significativos: el navegador cliente, el servidor Web, el servidor de aplicaciones, el servidor de datos. En un nivel alto, podemos definir en las aplicaciones Web actuales varios patrones arquitectónicos. Un patrón arquitectónico es la expresión de un esquema fundamental de organización para sistemas computacionales. Incluye un conjunto de subsistemas predefinidos, precisa sus responsabilidades y prescribe reglas y consejos para organizar sus relaciones.

3 Patrones arquitectónicos I Los más comunes actualmente son los siguientes: Se emplea al cliente Web muy liviano y universal para las aplicaciones destinadas a Internet, para las cuales la configuración del cliente no es controlable. El cliente sólo requiere un navegador Web normal y se realiza íntegramente la lógica de negocios, así como la lógica de presentación en el servidor: Solamente el lenguaje HTML se utiliza del lado del cliente, lo que maximiza la accesibilidad al sitio (todos los navegadores Web son aptos para navegar) y la seguridad del puesto del cliente. Este patrón implica no obstante innumerables idas y vueltas entre navegador y servidor Web: esto afecta la interactividad. El cliente Web liviano (el patrón más clásico en la actualidad, ver también la parte referente al cliente pesado ) corresponde también a aplicaciones Internet/Intranet para las cuales la configuración de cliente no es controlable, excepto lo que se requiere del lado del cliente un navegador Web bastante reciente, que soporte el lenguaje JavaScript. El cliente navega sobre páginas dotadas con inteligencia (programadas en Javascript), por lo tanto: 3

4 Patrones arquitectónicos II 4 La interactividad se mejora (la validación de los formularios se realiza del lado del cliente, antes del envío de consultas en el servidor Web). La mayoría de los navegadores modernos proponen opciones finas sobre lo que debe o no hacer JavaScript (por ejemplo, prohibir desactivar el menú del contexto o cambiar el texto de la barra de estado, abrir ventanas demasiado frecuentemente, etc.) La portabilidad de las páginas es bastante fácil de garantizar (por ejemplo con el empleo de bibliotecas como Prototype). Sin embargo, JavaScript debe utilizarse para la comodidad: la accesibilidad implica que si se desactiva, la aplicación debe seguir siendo utilizable con una ergonomía razonable o en el peor caso tolerable. El cliente Web más pesado embarca en las páginas Web los componentes más complejos: ActiveX, Applets Java, Plug-ins, lo que permite a una parte significativa de la lógica de negocios, ser ejecutada del lado del cliente. Es decir: La interfaz gráfica puede ser mucho más evolucionada (graficas dinámicas, ). La componente puede restaurarse espontáneamente (y descargar datos brutos del servidor).

5 Patrones arquitectónicos III 5 El despliegue, aunque automático, es mucho más pesado. Los requisitos previos sobre los puestos son más importantes. El riesgo es mucho más importante (típicamente con el ActiveX y los plug-ins que se ejecutan sin restricción sobre el sistema operativo).

6 Algunas definiciones I HTML: HyperText Markup Language) es un lenguaje de descripción de contenido basado en marcas. Estas marcas permiten especificar la apariencia de un documento al visualizarlo o al imprimirlo. Las marcas HTML autorizadas están normalizadas por el W3C ( 6 Las páginas HTML son documentos escritos en lenguaje HTML. Estas están compuestas de marcas, de texto y de referencias a otros recursos: otras páginas HTML (vinculadas), datos multimedia (imágenes, sonido, etc.), contenidos activos (applet, ActiveX, plugins). JavaScript: JavaScript es un lenguaje ligero, pero relativamente complejo y potente, que aporta funciones dinámicas a HTML en los navegadores. A pesar de su nombre, es muy diferente del lenguaje Java y no es verdaderamente orientado a objetos (no hay herencia ). Plug-in: Programa descargado e instalado en un navegador. Cuando el navegador detecta un formato de archivo (texto, multimedia, etc.) que reconoce, recurre al plugin asociado para tratarlo. ActiveX: Son componentes computacionales incluidos en una página HTML y cargados por el navegador al mismo tiempo que este se inicializa.

7 Algunas definiciones II 7 ActiveX es una tecnología propietaria que se basa en el COM (Component Object Model), infraestructura de Microsoft, en la cual los desarrolladores pueden construir componentes en los lenguajes de su elección, y compartirlos para elaborar sistemas más complejos y más potentes. La tendencia actual consiste, cada vez más, en ignorar pura y simplemente los ActiveX, que son a menudo rechazados debido a su enorme vulnerabilidad. Applet: es un programa Java cuyo código es cargado en el lado del cliente desde el servidor Web y se ejecuta a continuación en el navegador utilizando un interprete Java (la máquina virtual, o JVM, que esta integrado en la mayoría de los navegadores). El modelo de seguridad de los applets es muy estricto pero evolutivo desde Java 2 (utilización de los certificados). Igualmente puede usarse HTML puro o técnicas basadas en scripts; la utilización de Java (para ser eficaz) requiere de conocimientos previos en diseño y programación orientada a objetos.

8 El cliente Web pesado 8 Desde hace unos años hasta ahora, aparecen nuevas tecnologías que permiten desarrollar la capa de presentación de una aplicación Web. XUL, AJAX, Flash, JSF, Flex, Laszlo, Eclipse RCP, XAML, etc, los buzzwords (Web 2) se multiplican y la elección sobre un proyecto pasa a ser cada vez más difícil! Por lo que se refiere a la arquitectura, las soluciones son sin embargo bastante similares, con la aparición en particular de un concepto de contenedor sobre el lado del cliente. Este contenedor puede ser de distintos orígenes: navegador Web (AJAX), interprete Flash (Flex, Laszlo), máquina virtual Java, Eclipse. Un precursor es XUL: XML User interface Language. XUL es una lenguaje basado en XML, que es utilizado para describir la estructura de la aplicación, pero no las acciones y los comportamientos (es necesario para esto agregarle un lenguaje de script como Javascript.

9 Una arquitectura 9

10 Una alternativa Microsoft propone una alternativa con XAML, basada también en XML y que describe interfaces gráficas, pero se basan en el framework.net 3.0 (antiguamente nombrado WinFX), parte del sistema operativo Vista. Mencionamos también a AJAX, que significa Asynchronous Javascript And XML. Cómo funciona esto? A una petición del cliente, el servidor responde en forma de contenido XML, fragmentos (X)HTML, Javascript, JSON (Javascript Object Notation), etc. Esta respuesta es analizada por el cliente que modifica dinámicamente la interfaz sin recargar integralmente la página Web, con ayuda de Javascript, CSS y HTML. Es pues una técnica que se ejecuta en el navegador y que llama al DHTML (Dynamic HTML). Para concluir (temporalmente) sobre el tema en plena efervescencia del cliente pesado, se puede decir que existen muchas soluciones diferentes con técnicas y niveles de madurez desiguales. Lo que está en juego depende mucho finalmente del contexto: aplicaciones de gestión desarrolladas sobre una intranet o sitios comerciales en Internet, etc. 10

11 Más del cliente pesado 11 El cliente pesado es una aplicación importante, que se realiza en el lado del cliente. Este patrón corresponde típicamente a las aplicaciones Intranet para las cuales se habilita la configuración del cliente: La restricción del despliegue de estos programas es menos fuerte hoy que en el pasado, gracias a la aparición de técnicas de entrega vía la Web (Web delivery). La comunicación cliente/servidor es menos problemática; los protocolos de red son para la mayoría de personas non gratas en la Web debido a las restricciones impuestas por los cortafuegos desde la llegada de los servicios Web. Es por supuesto posible, aplicar varios patrones a una misma aplicación de e-comercio. Nuestro ejemplo podría así, utilizar por un lado el patrón del cliente Web ligero para los casos de uso del internauta, y por otro lado el cliente pesado para los casos de uso de los empleados. El sistema no controla la configuración de los puestos clientes de los internautas (y no queremos limitar a la posible clientela!), pero controla en cambio completamente los puestos clientes de la Librería o el Webmaster.

12 Vista del conjunto de arquitecturas web Presentamos una visión global de las arquitecturas web (que favorecen las tecnologías Java) en la siguiente figura. 12

13 Servicios Web y cookies 13 Un servicio Web (WebService) es un servicio basado en la Web, utilizando XML (extended Markup Language) y más concretamente el formato SOAP para cifrar a la vez el embalaje del mensaje y el contenido del cuerpo del mensaje. Lo que resulta en una integración completamente independiente del sistema operativo, del lenguaje o de cualquier otro producto middleware utilizado por cada uno de los componentes que forman parte del servicio. Un servicio Web no utiliza inevitablemente XML. Las tecnologías iniciales, aún más extendidas, siguen siendo XML-RPC y SOAP, pero REST se esta utilizando cada vez más con mayor frecuencia, y el formato de los datos es libre. Cookie: Pequeño conjunto de informaciones que un servidor puede pedir a un cliente guardar, para pedirle devolverlos más tarde. Una aplicación Web puede por ejemplo utilizar un cookie transitorio para que el servidor siga el rastro de un navegador cliente particular, a lo largo de su recorrido entre las páginas del sitio Web. En cuanto a los cookies permanentes, sirven a menudo de tickets de entrada virtuales evitando al cliente recobrar su información de acceso personal.

14 Algunas definiciones 14 ASP = Active Server Pages (Microsoft) JSP = Java Server Pages (origen: Sun). Los JSP utilizan Java. Los ASP se basan principalmente en los VBScript. Estas páginas son interpretadas en el servidor. Estas pueden así tener acceso a los recursos de la empresa. Es el resultado de esta ejecución que así se devuelve al cliente. EJB = Enterprise Java Beans Los Serviced Components son componentes oficiosos reutilizables albergados por el servidor de aplicación de Microsoft: MTS. En este sentido, son una evolución del modelo COM+, adaptado al framework.net, el colgante de los EJB de la plataforma Java. MTS = Microsoft Transaction Server RDO = Remote Data Object ADO = ActiveX Data Object ODBC = Open Database Connectivity JDBC = Java Database Connectivity

15 El cliente Web ligero I 15 Los componentes principales del patrón arquitectónico cliente Web ligero se encuentran en el servidor. En este sentido, esta arquitectura es efectivamente la de una aplicación Web mínima. El navegador cliente es un navegador HTML estándar compatible con los formularios y con DHTML. Actúa como un dispositivo universal de la interfaz de usuario. Su única función suplementaria puede ser aceptar y devolver cookies. El usuario de la aplicación requiere páginas HTML del lado del servidor a través del navegador. La página devuelta contiene una interfaz enteramente formateada que el navegador presenta en la ventana cliente. El servidor Web es el punto de acceso principal para todos los navegadores clientes. En función de la petición (página HTML estática o página servidor), los tratamientos de la parte del servidor se pueden inicializar. En todos los casos, el resultado es una página HTML mostrada por un navegador HTML estándar. La página servidor es una página que sufre una forma de tratamiento de la parte del servidor. De una manera típica, se aplican estas páginas en el servidor en forma de páginas de escritura (ASP, JSP, etc) que se tratan por un filtro en el servidor de aplicaciones o por un módulo ejecutable. Estas páginas tienen potencialmente acceso a todos los recursos del lado del servidor; esto incluye los componentes de la lógica de negocios, de las bases de datos, de los sistemas tradicionales (legacy) o de los sistemas de pago.

16 El cliente Web ligero II 16 El servidor de aplicaciones es el principal ejecutor de la lógica de negocios del lado del servidor. La ejecución del código en las páginas servidor es de su incumbencia. Puede encontrarse sobre la misma máquina que el servidor Web y puede también ejecutarse en el mismo espacio de proceso. El servidor de aplicaciones es un elemento arquitectónico lógicamente distinto puesto que sólo se le refiere por la ejecución de la lógica de negocios y porque aplica potencialmente tecnologías distintas de las del servidor Web (EJB, Serviced Components). El servidor de datos permite administrar la persistencia de los objetos de negocio, por ejemplo en una base de datos relacional. Para conectarla al sistema, el medio más simple es autorizar los scripts de las páginas servidor que deben accederse directamente al componente de persistencia. Este acceso directo pasará sin embargo por la utilización de bibliotecas estándar de acceso a los datos, como RDO, ADO, ODBC, JDBC, etc. Para sistemas más complejos y más robustos, se prefiere aplicar una capa objeto de negocios completa. Es la óptica que elegimos para nuestro caso de estudio. Como el sistema de persistencia escogido es una base de datos relacional, agregamos una capa (llamada DAO) encargada de efectuar el mapeo entre objeto/relacional.

17 Vista lógica completa del patrón Web ligero La siguiente figura presenta la vista lógica de los principales componentes de la arquitectura del patrón cliente Web ligero. Representamos estos componentes lógicos en forma de paquetes UML, incluyendo temporalmente el modelo de análisis en la capa lógica de negocios. 17

18 Soluciones técnicas propuestas I 18 No tenemos por objetivo presentar en detalle el conjunto de las tecnologías Web existentes. Esto desbordaría por mucho el objetivo propuesto en este curso. Sin embargo, pensamos que es útil bosquejar un cuadro resumido con el fin de incluir las transformaciones que vamos a aplicar a los diagramas de interacciones y a los diagramas de clases. Existen distintas tecnologías para desarrollar aplicaciones Web, por orden de aparición: los CGI, o Common Gateway Interface, que permitieron desarrollar los primeros sitios Web dinámicos. Esta tecnología permite llamar un programa externo al servidor Web en una petición. Este programa puede acceder a todos los recursos necesarios, como una base de datos, y construir la página en función de la petición. Sin embargo, los CGI tienen algunos inconvenientes: mezcla de código HTML y de código de programación que dificulta el mantenimiento, sobrecarga la memoria y la latencia del servicio con el lanzamiento de un nuevo proceso para cada petición, etc.

19 Soluciones técnicas propuestas II 19 Los CGI no se adaptan pues a la creación de aplicaciones web importantes. Las extensiones propietarias de servidores web (ISAPI de Microsoft, NSAPI de Netscape, módulos PHP, Perl de Apache, etc); Los ASP (Microsoft): páginas HTML y VBScript interpretado; Los ASP.NET (Microsoft): páginas HTML y código.net (VB o C#) compilado; Los servlets Java, que son un poco la contrapartida de los applets, pero en el servidor Web. No tienen IHC, son rápidos y potentes. Son también portables bajo la reserva de que los servidores Web concernientes posean una máquina virtual Java embarcada. Los JSP (Java). Vamos a describir más adelante dos grandes tipos de soluciones técnicas: 1. Las soluciones simples a base de lenguajes de script como PHP (o Python); 2. Las soluciones más potentes, pero más complejas, basadas en la plataforma Java (J2EE), en particular con el framework Struts, o sobre la plataforma.net de Microsoft.

20 Solución a base de scripts: PHP I 20 Se utilizan en la actualidad, numerosas lenguajes de scripts para desarrollar sitios Web dinámicos. Entre los más usados, podemos citar Perl, Python y PHP. Este último gana progresivamente el mercado: ha seducido a numerosas personas (desarrolladores) y su simplicidad de aplicación convence también cada vez más a las empresas. Un sitio desarrollado en PHP es muy simple: consta de páginas (cuya extensión es.php) que contienen a la vez código HTML y de las partes de código de programación escritos en lenguaje PHP. Esta última capa manipula las informaciones procedentes de los clientes del sitio mediante sus navegadores Web, y realiza todo tipo de tratamiento. Hay bibliotecas complementarias que permiten a PHP acceder a las bases de datos relacionales como Oracle, MySQL, etc. Si el aprendizaje del lenguaje es trivial, la arquitectura básica que vamos a proponer no asegura la posibilidad de mantenimiento del sitio ni la separación de los roles del programador y del diseñador gráfico.

21 Solución a base de scripts: PHP II 21 Ya que los lenguajes HTML y PHP están completamente entremezclados. Los amateurs de PHP han recurrido a menudo a las técnicas elementales de ingeniería de software externalizando un máximo de código aplicativo en archivos PHP separados, cuyas funciones se invocan desde las páginas de presentación frontales. PHP aplica también los conceptos orientados a objeto (clase, herencia, polimorfismo), los programadores debutantes en orientación a objetos obviamente estarán muy identificados con este tipo de tecnología. La principal crítica que se puede formular respecto a este lenguaje y su plataforma se refiere al desempeño: PHP es una lenguaje interpretado y se ejecutas menos rápido que las páginas dinámicas del tipo servlets/jsp o ASP.NET, que son precompiladas. No obstante, el interprete PHP no deja de mejorarse; los desempeños globales de PHP son pues totalmente aceptables hoy en día para la mayoría de los sitios personales y profesionales.

22 Solución a base de scripts I 22 Además de los lenguajes de scripts que citamos (PHP, Python, Perl), existen iniciativas que se pueden calificar de frameworks globales o de servidores de aplicación, implementados para estos mismas lenguajes y que aportan no solamente servicios técnicos suplementarios, sino que además son guías de buena conducta relativa a la arquitectura técnica. Existe cada vez más; tomemos simplemente el ejemplo de Zope, un servidor de aplicaciones que permite desarrollar aplicaciones de empresa en método cliente ligero, y que se basa en Python del lado del servidor. Zope es un software Open Source, escrito en gran parte en Python ( Ofrece servicios técnicos indispensables para una aplicación de empresa, como la persistencia de los datos de negocios (y la gestión de los antecedentes de los datos), la autenticación de los usuarios, la administración a distancia y a través de la Web de las aplicaciones instaladas Resumidamente, basarse en Zope para desarrollar un sitio de una librería en línea acorta el plazo, limita los riesgos vinculados a la arquitectura técnica, y mejora los desempeños de la aplicación (gracias a una de las técnicas de cache y pooling avanzadas y automáticas).

23 Solución a base de scripts II En dos palabras, Zope incluye a un servidor Web, lo que le permite albergarse y servir las páginas HTML estáticas. Para hacer dinámico el contenido de las páginas, Zope propone el lenguaje DTML, que consiste en un conjunto de marcas que se instalan en la lógica simple en las páginas (iteraciones, visualización de una variable, cálculo muy simple). Sin embargo, el grueso de la lógica de negocios reside en otra parte: es llevada por clases Python que serán manipuladas por las páginas DTML, y las instancias (si se desea) se almacenarán automáticamente en la base de datos orientada a objetos (también incluida en Python). La ventaja de un lenguaje como Python es el compromiso que ofrece entre la simplicidad de aprendizaje e implementación y su potencia de expresión (Python es conciso, orientado a objetos, dinámico, soporta la introspección, etc). Resumidamente, es una lenguaje tan potente como Java o C#, pero más fácilmente accesible. Zope completa Python ofreciendo toda la infraestructura técnica al desarrollador de sitios Web dinámicos. 23

24 Solución Java J2EE, I 24 Con el lenguaje Java apareció una nueva tecnología: los servlets. Estos pequeños servidores o servicios están escritos en lenguaje Java y utilizan una API específica. Corrigen algunas debilidades de los CGI. Los desempeños son mejorados por las funcionalidades multi-threads de los servidores J2EE, evitando la creación de procesos externos. Sin embargo, el desarrollador debe siempre mezclar el código Java y HTML. Además, la menor modificación obliga a recompilar el servlet y a recargarlo. Los JSP, o Java Server Pages, vienen a solucionar estos problemas de recompilación. Aquí, es el código Java el que se incorpora en la página HTML con técnicas de scripting. El servidor compila automáticamente la página en un servlet y lo ejecuta a continuación. Los enfoques a base de scripting requieren la incorporación importante de código aplicativo en HTML.

25 Solución Java J2EE, II 25 Estas técnicas limitan también la reutilización de código. Para lo que es el mundo de Java, se propuso hacer colaborar a los servlets y a los JSP en las aplicaciones. Los desarrolladores utilizan los servlets para administrar los aspectos de programación de una aplicación Web y los JSP se utilizan por los diseñadores gráficos por computadora para efectuar la visualización. Se encuentran así un servlet y un JSP por petición posible en el sitio Web. El servlet no contiene más HTML, y el JSP contiene exactamente el código necesario para la visualización. Este estilo de programación respeta el paradigma MVC.

26 El paradigma MVC (modelo-vista-controlador) 26 El paradigma MVC es un esquema de programación que propone separar una aplicación en tres partes: el modelo, que contiene la lógica y el estado de la aplicación; la vista, que representa la interfaz de usuario; el controlador, que administra la sincronización entre la vista y el modelo. El punto esencial consiste en separar los objetos gráficos de los objetos de negocios, con el fin de poder hacerlos evolucionar independientemente y reutilizarlos. Se puede también administrar fácilmente varias vistas del mismo modelo. El paradigma MVC básico está representado en la figura.

27 Paradigma MVC, I 27 La vista utiliza al controlador para modificar el modelo. Los eventos no hacen más que notificar de un cambio, no del contenido de este cambio. Sin embargo, la vista tiene un determinado conocimiento del modelo puesto que utiliza a sus accesos. Se propuso un MVC optimizado para reducir la comunicación entre las capas.

28 Paradigma MVC, II 28 Los eventos notifican del cambio y de su contenido. El controlador sólo proporciona mutadores. Para los sistemas distribuidos, la notificación puede efectuarse por medio del controlador. Este paradigma esta implementado por Java/Swing. Una tercera versión del paradigma MVC para las aplicaciones Web esta dada en la siguiente figura.

29 Solución Java J2EE, III Al final, tal separación favorece el desarrollo y el mantenimiento de las aplicaciones: Dado que se separó el modelo de los otros componentes, este se desarrolla independientemente. El desarrollador del modelo se concentra en lo funcional y lo transaccional de su aplicación. El modelo no está vinculado a una interfaz, puede entonces reutilizarse (paso de una aplicación con interfaz en Java a una aplicación con interfaz Web). En las aplicaciones J2EE, el modelo está garantizado por EJB y/o los JavaBeans, el controlador está garantizado por los servlets y la vista por los JSP. 29

30 Definiciones 30 JavaBean: Un JavaBean es una clase Java que se ajusta a algunas reglas que permiten la utilización dinámica. Es una clase pública concreta, que posee un constructor público sin argumento. Puede definir propiedades similares a los atributos que poseen los accesos públicos según un convenio de nombrado particular: <property Type> get<propertyname>() void set<propertyname> (<PropertyType>) Framework: Un framework es un conjunto coherente de clases y de interfaces que colaboran para prestar servicios a la parte central de un subsistema lógico. Contiene principalmente clases abstractas que el usuario deberá especializar para sus necesidades funcionales propias, así como las interfaces a las cuales deberá ajustarse.

31 Solución Java J2EE, IV 31 No es sin embargo aún ideal: obliga a escribir una multitud de servlets, que son tantos puntos de entrada en la aplicación. Para atenuar este inconveniente se han desarrollado los frameworks. Estos frameworks que están formados por un único servlet (es decir, un único controlador) se agrupan bajo la etiqueta MVC2. Los frameworks más utilizados actualmente se llaman Struts, Spring y JSF. Struts es un proyecto Open Source desarrollado por la comunidad Yakarta de Apache ( Proporciona un framework MVC2 que incluye los siguientes componentes: un controlador fácilmente configurable que permite asociar acciones (objetos Java) a peticiones http; bibliotecas de tags específicas para crear fácilmente una vista; un Digester, que permite parsear un archivo XML y de recuperar solamente la información deseada; bibliotecas para llenar automáticamente los campos de los formularios y crear aplicaciones que proponen el uso de varios idiomas (internacionalización).

32 Solución Java J2EE, V 32 Spring ( una implementación novedosa del patrón IoC (Inversión del Control) propone también su implementación MVC2. Java Server Faces (JSF) es un framework Web reciente de tipo MVC2 que intenta reconciliar el mundo del desarrollo Internet con el del desarrollo RAD (Delphi, etc.) Su objetivo es permitir el desarrollo de aplicaciones Web basándose en componentes gráficos de alto nivel y un modelo efectivo abstrayendo al desarrollador de las preocupaciones vinculadas a la utilización del protocolo http. Claramente, hay que ser más productivo en la creación de las páginas Web. Desde un punto de vista estratégico y competitivo, JSF es la respuesta de Sun (ahora Oracle) a la tecnología ASP.Net de Microsoft y al concepto de WebForms. Además, Sun desea promover JSF como el framework normal de desarrollo Web, lo que explica su inclusión en el JEE 5, allí donde los otros frameworks del mundo Java (Struts en particular) permanecen como iniciativas Open Source independientes.

33 Solución Java J2EE, VI 33 Técnicamente. JSF es comparable con Struts en numerosos puntos como la presencia de un controlador único (FaceServlet), de bibliotecas de Tags (para facilitar el desarrollo de las vistas) y de un archivo de configuración para definir la cinemática de la aplicación. JSF se limita por el hecho de que las páginas están en auto sumisión (Post-Back), lo que causa una gestión del estado de la vista entre una respuesta del servidor y la petición siguiente del usuario. El ciclo de tratamiento de una demanda es mucho más preciso que con Struts, la programación de más alto nivel, la presencia de eventos del lado del servidor vuelve más fácil la asimilación de esta tecnología por equipos poco familiarizados con el desarrollo Web y la presencia de muchas bibliotecas de componentes JSF (Tomahawk del proyecto Open Source MyFaces que es el más conocido) mejora considerablemente el tiempo de desarrollo.

34 Solución Microsoft.NET, I 34 Microsoft propone desde hace algunos años una herramienta muy simple para el desarrollo de sitios Web (arquitectura cliente ligero): los ASP. Muy próximos a las técnicas de scripting que ya mencionamos, los ASP mezclan lenguaje HTML y lenguaje de programación (VBScript, Jscript, ). No obstante, esta técnica presenta una serie de limitaciones (desempeño, mantenimiento) que impulsaron a Microsoft a mejorar este framework y a hacerlo evolucionar en ASP.NET.

35 Solución Microsoft.NET, II 35 Los ASP.NET ofrecen una manera original de desacoplar el código aplicativo del código de presentación: es siempre posible escribir páginas HTML y de hacer dinámico su contenido por la inclusión de algunas líneas de código (esta vez en lenguaje C# o VB.NET), pero se desplaza la parte esencial del código aplicativo en una clase asociada a la página ASP.NET: una clase denominada CodeBehind (Framework 1.1) o CodeBeside (Framework 2.0). Esta clase puede contener por ejemplo todos los métodos de reacción a los eventos del usuario (click sobre un supervínculo, modificación o introducción de una zona de texto, subordinación de un formulario ) Esto no es todo: ASP.NET propone ir aún más lejos con el framework WebForms, que ayuda a desarrollar gráficamente páginas dinámicas (y reactivadas a los eventos usuario), al igual que cuando se desarrollaría una aplicación «cliente pesado» en VisualBasic, Delphi, PowerBuilder o Java/Swing. La facilidad de uso de estas herramientas es desconcertante e invita a basarse en una arquitectura propia que favorece el mantenimiento y el desempeño, lo que acelera el tiempo de desarrollo.

36 Solución Microsoft.NET, III 36 Finalmente, en este nuevo framework ASP.NET, los resultados se mejoran claramente debido al hecho de que todas las páginas (ASP.NET) y las clases (CodeBehind) son precompiladas y no ejecutadas como era el caso en ASP. El framework.net 3.0 es un agregado al framework.net 2.0. Se suministra con Windows Vista y puede instalarse sobre Windows XP SP2 o Windows 2003 Server, etc. Las contribuciones se refieren a: WCF (Windows Comunicación Foundation, antiguamente Indigo): un modelo de programación para aplicaciones orientadas a servicio (SOA), en particular Servicios Web. WPF (Windows Presentation Foundation, antiguamente Avalon): XAML. WF (Windows Workflow Foundation, ya que WWF ya se consideraba!) : un modelo de programación para aplicaciones bajo la forma de proceso oficioso. WCS (Windows CardSpace): facilita el intercambio de informaciones de identificación personal.

37 .NET Framework