MODELO VISTA CONTROLADOR Y ORIENTADOS A SERVICIOS

MATERIA: Sistemas distribuidos DOCENTE: Arturo Iván Grajales

Vázquez

Mario Vidal

Vázquez 8 “E”

Ing. Sistemas

computacionales

Modelo Vista Controlador (MVC) Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. El patrón MVC se ve frecuentemente en aplicaciones web, donde la vista es la página HTML y el código que provee de datos dinámicos a la página; el modelo es el Sistema de Gestión de Base de Datos y la Lógica de negocio; y el controlador es el responsable de recibir los eventos de entrada desde la vista. MVC es un patrón de diseño que fue inicialmente utilizado para construir interfaces de usuario en Smalltalk80. MVC consiste de tres tipos de objetos. El Modelo, que son los objetos de la aplicación, también conocida como lógica de negocio, o lógica de aplicación. La Vista especifica la visualización de los datos, algunas veces conocida como lógica de presentación. El controlador es el coordinador entre estos dos últimos, es decir, define la forma en que la interfaz de usuario reacciona ante la entrada de usuario. MVC desacopla el concepto de interfaz de usuario y lógica de negocio para aumentar la flexibilidad y modularidad del software, posiblemente permitiendo que el código pueda ser reutilizado Finalmente, la idea es lograr separar responsabilidades entre las personas que trabajan para un proyecto de desarrollo de software; es decir, descomponer el problema en módulos funcionales, (entre ellos el diseño gráfico), lo que se traduce en enfocar de una forma reduccionista la solución de un proyecto software. Por ejemplo separando las vistas podremos modificar cuantas veces sea necesario el aspecto visual de la página web sin tener que tropezar con el código que se encarga de hacer el tratamiento a los formularios o con la sección que guardaba los datos de usuarios en bases de datos.

Considera dividir una aplicación en tres módulos claramente identificables y con funcionalidad bien definida: El Modelo, las Vistas y el controlador.

Modelo

El modelo es un conjunto de clases que representan la información del mundo real que el sistema debe reflejar. Es la parte encargada de representar la lógica de negocio de una aplicación. Así, por ejemplo, un sistema de administración de datos geográficos tendrá un modelo que representara la altura, coordenadas de posición, distancia, etc. sin tomar en cuenta ni la forma en la que esa información va a ser mostrada ni los mecanismos que hacen que esos datos estén dentro del modelo, es decir, sin tener relación con ninguna otra entidad dentro de la aplicación.

El modelo, a nivel teórico, no debe tener conocimiento acerca de la existencia de las vistas y del controlador. Esta situación es interesante, pero de difícil aplicación práctica, pues deben existir interfaces que permitan a los módulos comunicarse entre sí, por lo que SmallTalk sugiere que el modelo en realidad esté formado por dos submódulos: El modelo del dominio y el modelo de la aplicación.

Modelo de Dominio

Se entiende por modelo de dominio al conjunto de clases definidas a través del análisis de la situación real del problema que queremos solucionar. Si seguimos el ejemplo anterior, sobre datos geográficos, pertenecerían a este dominio las clases; Rio, Montaña, Mar, etc...El modelo del dominio no debería tener relación con nada externo a la información que contiene.

Modelo de la aplicación

El modelo de la aplicación es un conjunto de clases que sirven de puente en la relación de las vistas con el modelo de dominio. Tienen conocimiento de las vistas e implementan los mecanismos necesarios para notificar a éstas los cambios que se pudieren dar en el modelo del dominio. El modelo de la aplicación es llamado también coordinador de la aplicación.

Vista

Las vistas son las encargadas de la representación de los datos, contenidos en el modelo, al usuario. La relación entre las vistas y el modelo son de muchas a uno, es decir cada vista se asocia a un modelo, pero pueden existir muchas vistas asociadas al mismo modelo. De esta manera, por ejemplo, se puede tener una vista mostrando la hora del sistema como un reloj analógico y otra vista mostrando la misma información como un reloj digital.

La vista solo necesita la información requerida del modelo para realizar un despliegue. Cada vez que se realiza una actuación, que implica una modificación del modelo de dominio, la vista cambia a través de notificaciones generadas por el modelo de la aplicación. Sencillamente, es la representación visual del modelo que redibuja las partes necesarias cuando se produce una modificación del mismo.

Controlador

El controlador es el encargado de interpretar y dar sentido a las instrucciones que realiza el usuario, realizando actuaciones sobre el modelo. Si se realiza algún cambio, comienza a actuar, tanto si la modificación se produce en una vista o en el modelo. Interactúa con el Modelo a través de una referencia al propio Modelo.

Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo de control generalmente es el siguiente: 1. El usuario interactúa con la interfaz de alguna manera (ej. presionando un botón, un enlace). 2. El controlador recibe (por parte de los objetos de la interfaz vista) la notificación de la acción solicitada por el usuario 3. El controlador accede al modelo, posiblemente actualizando los datos enviados por el usuario. 4. El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. 5. La vista usa el modelo para generar la interfaz apropiada para el usuario donde se refleja los cambios en el modelo. 6. En algunas implementaciones la vista no tiene acceso directo al modelo, dejando que el controlador envíe los da tos del modelo a la vista. Esta segunda es la que utilizaremos en este curso. 7. La interfaz espera por nuevas interacciones de usuario para iniciar nuevamente el ciclo. Se tienen muchas ventajas como:

La implementación se realiza de forma modular. Sus vistas muestran información actualizada siempre. El programador no debe

preocuparse de solicitar que las vistas se actualicen, ya que este proceso es realizado automáticamente por el modelo de la aplicación.

Cualquier modificación que afecte al dominio, como aumentar métodos o datos contenidos, implica una modificación sólo en el modelo y las interfaces del mismo con las vistas, no todo el mecanismo de comunicación y de actualización entre modelos.

Las modificaciones a las vistas no afectan al modelo de dominio, simplemente se modifica la representación de la información, no su tratamiento.

MVC está demostrando ser un patrón de diseño bien elaborado pues las aplicaciones que lo implementan presentan una extensibilidad y una mantenibilidad únicas comparadas con otras aplicaciones basadas en otros patrones.

Como desventajas tenemos:

Para desarrollar una aplicación bajo el patrón de diseño MVC es necesario una mayor dedicación en los tiempos iniciales del desarrollo. Normalmente el patrón exige al programador desarrollar un mayor número de clases que, en otros entornos de desarrollo, no son necesarias. Sin embargo, esta desventaja es muy relativa ya que posteriormente, en la etapa de mantenimiento de la aplicación, una aplicación MVC es mucho más mantenible, extensible y modificable que una aplicación que no lo implementa.

MVC requiere la existencia de una arquitectura inicial sobre la que se deben construir clases e interfaces para modificar y comunicar los módulos de una aplicación. Esta arquitectura inicial debe incluir, por lo menos, un mecanismo de eventos para poder proporcionar las notificaciones que genera el modelo de aplicación; una clase Modelo, otra clase Vista y una clase Controlador

genéricas que realicen todas las tareas de comunicación, notificación y actualización que serán luego transparentes para el desarrollo de la aplicación.

MVC es un patrón de diseño orientado a objetos por lo que su implementación es sumamente costosa y difícil en lenguajes que no siguen este paradigma.

¿Cómo funciona una aplicación MVC?

Captura de la petición en el controlador

La aplicación recibe peticiones que son centralizadas en el Controlador. Éste es el encargado de interpretar, a partir de la URL de la solicitud, el tipo de operación que hay que realizar. Normalmente, esto se hace analizando el valor de algún parámetro que se envía anexando a la URL de la petición y que se utiliza con esta finalidad.

Procesamiento de la petición

Una vez que el Controlador determine la operación a realizar, procede a ejecutar las acciones pertinentes, invocando para ello a los diferentes métodos expuestos por el Modelo.

Dependiendo de las acciones a realizar (por ejemplo, un alta de un usuario en el sistema), el Modelo necesitará manejar los datos enviados por el cliente en la petición, datos que le serán proporcionados por el controlador. De la misma manera, los resultados generados por el Modelo (por ejemplo la información resultante de una búsqueda serán entregados directamente al controlador).

Para facilitar este intercambio de datos entre el Controlador y Modelo y, posteriormente, entre Controlador y Vista, las aplicaciones MVC suelen hacer uso de JavaBeans. Un JavaBean no es más que una clase que encapsula un conjunto de datos con métodos de tipo set/get para proporcionar un acceso a los mismos desde el exterior.

Generación de respuestas

Los resultados devueltos por el Modelo al Controlador son depositados por éste en una variable de petición, sesión o aplicación, según el alcance que deban tener. A continuación, el Controlador invoca a la página JSP que debe encargarse de generar la vista correspondiente, está página accederá a la variable de ámbito donde estén depositados los resultados y los utilizará para generar dinámicamente la respuesta XHTML que será enviada al cliente.

Conclusión:

El patrón Modelo – Vista – Controlador fue inventado en el contexto de Smalltak para realizar una separación entre la interfaz gráfica y el código del funcionamiento de una aplicación. Esta idea teórica afectó, de forma importante, a gran parte del código de Smalltalk y fue posteriormente aplicada a los lenguajes que están basados en objetos. Biografía: http://www.ibm.com/developerworks/ssa/webservices/newto/index.html http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/122

Arquitectura Orientada a Servicios (SOA)

La Arquitectura Orientada a Servicios es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio.

Permite la creación de sistemas altamente escalables que reflejan el negocio de la organización, a su vez brinda una forma estándar de exposición e invocación de servicios (comúnmente pero no exclusivamente servicios web), lo cual facilita la interacción entre diferentes sistemas propios o de terceros.

SOA proporciona una metodología y un marco de trabajo para documentar las capacidades de negocio y puede dar soporte a las actividades de integración y consolidación.

Lamentablemente SOA no es tan sencilla, y al decir que es un paradigma y un estilo arquitectónico ya se está diciendo que es algo abstracto, y una forma de pensar en términos de servicios, junto con esto se debe entender que, al igual que el Diseño OO tuvo sus principios los cuales pocos cumplen y muchos desconocen, el análisis y diseño orientado a servicios que se desprende del paradigma orientado a servicios y que constituye la base de SOA posee también una serie de principios inviolables más una serie de patrones que son los que definen como SOA se expresa y funciona, y garantizan además el cumplimiento de las promesas que han posibilitado su adopción por la industria.

Se puede resumir que SOA es un enfoque para diseñar y construir soluciones de negocio, a partir de componentes independientes que exponen funciones como servicios accesibles por otros componentes a través de interfaces estándares.

SOA no se trata de software o de un Lenguaje de programación, es un marco de trabajo conceptual que permite a las organizaciones unir los objetivos de negocio con la infraestructura TI, integrando los datos y la lógica de negocio de sus sistemas separados.

Arquitectura orientada a el servicio (SOA). Es la primera arquitectura de Tecnologías de Información (TI) que asume lo que los negocios han sabido desde hace mucho tiempo. Se trata esencialmente de un set de servicios sueltos, donde cada uno es relativamente económico para construirlo o reemplazarlo si es necesario.

La metodología de modelado y diseño para aplicaciones SOA se conoce como análisis y diseño orientado a servicios. La arquitectura orientada a servicios es tanto un marco de trabajo para el desarrollo de software como un marco de trabajo de implementación. Para que un proyecto SOA tenga éxito los desarrolladores de software deben orientarse ellos mismos a esta mentalidad de crear servicios comunes que son orquestados por clientes o middleware para implementar los procesos de negocio. El desarrollo de sistemas usando SOA requiere un compromiso con este modelo en términos de planificación, herramientas e infraestructura.

La Arquitectura Orientada a Servicios (SOA) es un estilo arquitectónico de TI que soporta la transformación de su empresa en un conjunto de servicios vinculados o tareas empresariales repetibles a las cuales se puede acceder en una red cuando sea necesario. Puede ser una red local, Internet o bien una red geográfica y tecnológicamente distinta, que combina servicios en Nueva York, Londres y Hong Kong, aunque estén todos instalados en su desktop local. Esos servicios pueden combinarse para realizar una tarea empresarial específica, para permitir que su empresa se adapte a condiciones y requisitos cambiantes Cuando la implementación de SOA es guiada por objetivos empresariales estratégicos, usted asegura la transformación positiva de su empresa y puede obtener los beneficios principales de SOA, que son: ¿Cómo se aprovecha la SOA y cómo ella afecta su empresa? IBM ha identificado cinco puntos de entrada para asegurar que toda solución basada en SOA que se realice proporcione valor empresarial real. Cada punto de entrada está acoplado a un caso de ejemplo o enfoque definido que implementa las tecnologías y, por consiguiente, los valores empresariales definidos en cada punto de entrada.

Personas: Este punto de entrada a SOA enfoca la experiencia del usuario para

ayudar a generar innovación y más colaboración, lo que posibilita la interacción

consistente entre personas y procesos y, consecuentemente, aumenta la

productividad empresarial. Al usar SOA se puede, por ejemplo, crear portlets

basados en servicios para aumentar esa colaboración.

Procesos: El punto de entrada relacionado con procesos ayuda las compañías

a saber qué está sucediendo en los negocios, lo que les permite mejorar los

modelos empresariales ya existentes. Al usar SOA, puede transformar sus

procesos empresariales en servicios reutilizables y flexibles, lo que le permite

mejorar y optimizar los nuevos procesos.

Información: Al usar ese punto de entrada a SOA, puede sacar provecho a las

informaciones de su compañía en forma consistente y visible. Al facilitar

informaciones consistentes y confiables a todas las áreas de la empresa,

habilita todas las áreas de la compañía a innovar y, consecuentemente, puede

competir con más eficiencia. Al usar SOA, se tiene un control mejor sobre sus

informaciones; al alinear las informaciones a sus procesos empresariales,

puede descubrir relaciones nuevas e interesantes.

Conectividad: Aproveche el punto de entrada relacionado con la conectividad

para conectar su infraestructura con eficiencia, integrando todas las personas,

procesos e informaciones de su compañía. Al tener conexiones flexibles de

SOA entre los servicios y en todo el entorno, puede tomar un proceso

empresarial ya existente y ofrecerlo sin mucho esfuerzo a través de otro canal

empresarial. Puede incluso conectarse a socios externos fuera de su firewall en

una forma segura.

Reutilización: La reutilización de servicios con SOA permite aprovechar

servicios que ya existen en la compañía. Al basarse en los recursos ya

existentes, puede optimizar sus procesos empresariales, asegurar la

consistencia en toda la compañía y reducir el tiempo de desarrollo. Todo ello

ahorra tiempo y dinero. Usted también reduce la duplicación de funcionalidades

en sus servicios y tiene la oportunidad de aprovechar las aplicaciones centrales

comprobadas con las cuales el personal de su compañía está familiarizado.

Estableceremos la correlación entre esos puntos de entrada y varios casos de ejemplo a través de una empresa ficticia llamada JK Enterprise para implementar un enfoque específico de SOA. Primeramente vamos a analizar los casos de ejemplo.

La importancia de la arquitectura SOA es que ofrece una oportunidad real de situar las tecnologías de la información en un nuevo nivel, convirtiéndolas en auténticos habilitadores del negocio. De esta manera se garantiza la agilidad de los negocios, aspecto fundamental para las organizaciones que quieren alcanzar el éxito en el actual mercado mundial, que cada día es más competitivo.

Algunos de los principales beneficios que obtienen las organizaciones al implementar una Arquitectura SOA son:

Agilidad para habilitar rápidamente soluciones innovadoras y para adaptarse a cambios en el mercado cuando ocurran.

Flexibilidad para reducir los tiempos y costos de implantación, y para contar con una arquitectura ágil que permita la evolución, cambio y crecimiento del negocio.

Rapidez para llegar primero al mercado antes que la competencia y crecer la participación de mercado.

Obtener mejor visibilidad de la información a través de toda su organización.

Optimiza sus procesos de negocios.

Tasas internas del retorno sobre la inversión de hasta el 100%.

Ahorro en TCO (Total Cost of Ownership) de los componentes de software y de las aplicaciones construidas utilizando estos componentes.

Capacidad de reutilizar y potenciar otras aplicaciones informáticas como ERP's, CRM's, etcétera. Por otra parte permite: Una "personalización masiva" de las tecnologías de la información.

La simplificación del desarrollo de soluciones mediante la utilización de estándares de la industria y capacidades comunes de industrialización.

Aislar los sistemas frente a cambios generados por otras partes de la organización (protección de las inversiones realizadas).

Alinear y acercar las áreas de tecnología y negocio.

Conclusión: SOA resuelve la mayoría de los problemas de software que se presentan en la actualidad, como son los de facilitar y estandarizar la integración de los sistemas, a través de la interoperabilidad entre los datos de negocio, las aplicaciones y los requerimientos de los procesos de negocio. Permitiendo mayor flexibilidad y la de reutilización de los procesos de negocio para acomodarlos en el nuevo sistema de información de la empresa. Y todo ello con dos importantes factores, menor coste y mayor rapidez de desarrollo. Cubriendo las necesidades de las empresas modernas: adaptación al cambio con el menor coste y tiempo posible. Biografía: http://www.bsc.co.ve/index.php/soa http://www.ecured.cu/index.php/Arquitectura_Orientada_a_Servicios_(SOA)