MODELO VISTA CONTROLADOR Y ORIENTADOS A SERVICIOS

MATERIA: Sistemas distribuidos DOCENTE: Arturo Ivn Grajales Vzquez

Mario Vidal Vzquez

Ing. Sistemas computacionales

8 E

 Modelo Vista Controlador (MVC) Modelo Vista Controlador (MVC) es un patrn de arquitectura de software que separa los datos de una aplicacin, la interfaz de usuario, y la lgica de control en tres componentes distintos. El patrn MVC se ve frecuentemente en aplicaciones web, donde la vista es la pgina HTML y el cdigo que provee de datos dinmicos a la pgina; el modelo es el Sistema de Gestin de Base de Datos y la Lgica de negocio; y el controlador es el responsable de recibir los eventos de entrada desde la vista. MVC es un patrn de diseo 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 aplicacin, tambin conocida como lgica de negocio, o lgica de aplicacin. La Vista especifica la visualizacin de los datos, algunas veces conocida como lgica de presentacin. 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 lgica de negocio para aumentar la flexibilidad y modularidad del software, posiblemente permitiendo que el cdigo 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 mdulos funcionales, (entre ellos el diseo grfico), lo que se traduce en enfocar de una forma reduccionista la solucin de un proyecto software. Por ejemplo separando las vistas podremos modificar cuantas veces sea necesario el aspecto visual de la pgina web sin tener que tropezar con el cdigo que se encarga de hacer el tratamiento a los formularios o con la seccin que guardaba los datos de usuarios en bases de datos.

Considera dividir una aplicacin en tres mdulos claramente identicables y con funcionalidad bien denida: El Modelo, las Vistas y el controlador. Modelo El modelo es un conjunto de clases que representan la informacin del mundo real que el sistema debe reflejar. Es la parte encargada de representar la lgica de negocio de una aplicacin. As, por ejemplo, un sistema de administracin de datos geogrficos tendr un modelo que representara la altura, coordenadas de posicin, distancia, etc. sin tomar en cuenta ni la forma en la que esa informacin va a ser mostrada ni los mecanismos que hacen que esos datos estn dentro del modelo, es decir, sin tener relacin con ninguna otra entidad dentro de la aplicacin.

El modelo, a nivel terico, no debe tener conocimiento acerca de la existencia de las vistas y del controlador. Esta situacin es interesante, pero de difcil aplicacin prctica, pues deben existir interfaces que permitan a los mdulos comunicarse entre s, por lo que SmallTalk sugiere que el modelo en realidad est formado por dos submdulos: El modelo del dominio y el modelo de la aplicacin. Modelo de Dominio Se entiende por modelo de dominio al conjunto de clases definidas a travs del anlisis de la situacin real del problema que queremos solucionar. Si seguimos el ejemplo anterior, sobre datos geogrficos, perteneceran a este dominio las clases; Rio, Montaa, Mar, etc...El modelo del dominio no debera tener relacin con nada externo a la informacin que contiene. Modelo de la aplicacin El modelo de la aplicacin es un conjunto de clases que sirven de puente en la relacin 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 aplicacin es llamado tambin coordinador de la aplicacin. Vista Las vistas son las encargadas de la representacin de los datos, contenidos en el modelo, al usuario. La relacin 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 analgico y otra vista mostrando la misma informacin como un reloj digital. La vista solo necesita la informacin requerida del modelo para realizar un despliegue. Cada vez que se realiza una actuacin, que implica una modificacin del modelo de dominio, la vista cambia a travs de notificaciones generadas por el modelo de la aplicacin. Sencillamente, es la representacin visual del modelo que redibuja las partes necesarias cuando se produce una modificacin 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 algn cambio, comienza a actuar, tanto si la modificacin se produce en una vista o en el modelo. Interacta con el Modelo a travs 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 interacta con la interfaz de alguna manera (ej. presionando un botn, un enlace). 2. El controlador recibe (por parte de los objetos de la interfaz vista) la notificacin de la accin 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 enve 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 implementacin se realiza de forma modular. Sus vistas muestran informacin actualizada siempre. El programador no debe preocuparse de solicitar que las vistas se actualicen, ya que este proceso es realizado automticamente por el modelo de la aplicacin. Cualquier modificacin que afecte al dominio, como aumentar mtodos o datos contenidos, implica una modificacin slo en el modelo y las interfaces del mismo con las vistas, no todo el mecanismo de comunicacin y de actualizacin entre modelos. Las modificaciones a las vistas no afectan al modelo de dominio, simplemente se modifica la representacin de la informacin, no su tratamiento. MVC est demostrando ser un patrn de diseo 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 aplicacin bajo el patrn de diseo MVC es necesario una mayor dedicacin en los tiempos iniciales del desarrollo. Normalmente el patrn exige al programador desarrollar un mayor nmero 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 aplicacin, una aplicacin MVC es mucho ms mantenible, extensible y modificable que una aplicacin 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 mdulos de una aplicacin. Esta arquitectura inicial debe incluir, por lo menos, un mecanismo de eventos para poder proporcionar las notificaciones que genera el modelo de aplicacin; una clase Modelo, otra clase Vista y una clase Controlador

genricas que realicen todas las tareas de comunicacin, notificacin y actualizacin que sern luego transparentes para el desarrollo de la aplicacin. MVC es un patrn de diseo orientado a objetos por lo que su implementacin es sumamente costosa y difcil en lenguajes que no siguen este paradigma. Cmo funciona una aplicacin MVC? Captura de la peticin en el controlador La aplicacin 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 operacin que hay que realizar. Normalmente, esto se hace analizando el valor de algn parmetro que se enva anexando a la URL de la peticin y que se utiliza con esta finalidad. Procesamiento de la peticin Una vez que el Controlador determine la operacin a realizar, procede a ejecutar las acciones pertinentes, invocando para ello a los diferentes mtodos 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 peticin, datos que le sern proporcionados por el controlador. De la misma manera, los resultados generados por el Modelo (por ejemplo la informacin resultante de una bsqueda sern 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 ms que una clase que encapsula un conjunto de datos con mtodos de tipo set/get para proporcionar un acceso a los mismos desde el exterior. Generacin de respuestas Los resultados devueltos por el Modelo al Controlador son depositados por ste en una variable de peticin, sesin o aplicacin, segn el alcance que deban tener. A continuacin, el Controlador invoca a la pgina JSP que debe encargarse de generar la vista correspondiente, est pgina acceder a la variable de mbito donde estn depositados los resultados y los utilizar para generar dinmicamente la respuesta XHTML que ser enviada al cliente.

Conclusin: El patrn Modelo Vista Controlador fue inventado en el contexto de Smalltak para realizar una separacin entre la interfaz grfica y el cdigo del funcionamiento de una aplicacin. Esta idea terica afect, de forma importante, a gran parte del cdigo de Smalltalk y fue posteriormente aplicada a los lenguajes que estn basados en objetos. Biografa: 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 utilizacin de servicios para dar soporte a los requisitos del negocio. Permite la creacin de sistemas altamente escalables que reflejan el negocio de la organizacin, a su vez brinda una forma estndar de exposicin e invocacin de servicios (comnmente pero no exclusivamente servicios web), lo cual facilita la interaccin entre diferentes sistemas propios o de terceros. SOA proporciona una metodologa y un marco de trabajo para documentar las capacidades de negocio y puede dar soporte a las actividades de integracin y consolidacin. Lamentablemente SOA no es tan sencilla, y al decir que es un paradigma y un estilo arquitectnico ya se est diciendo que es algo abstracto, y una forma de pensar en trminos de servicios, junto con esto se debe entender que, al igual que el Diseo OO tuvo sus principios los cuales pocos cumplen y muchos desconocen, el anlisis y diseo orientado a servicios que se desprende del paradigma orientado a servicios y que constituye la base de SOA posee tambin una serie de principios inviolables ms una serie de patrones que son los que definen como SOA se expresa y funciona, y garantizan adems el cumplimiento de las promesas que han posibilitado su adopcin por la industria. Se puede resumir que SOA es un enfoque para disear y construir soluciones de negocio, a partir de componentes independientes que exponen funciones como servicios accesibles por otros componentes a travs de interfaces estndares. SOA no se trata de software o de un Lenguaje de programacin, 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 lgica de negocio de sus sistemas separados. Arquitectura orientada a el servicio (SOA). Es la primera arquitectura de Tecnologas de Informacin (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 econmico para construirlo o reemplazarlo si es necesario. La metodologa de modelado y diseo para aplicaciones SOA se conoce como anlisis y diseo 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 implementacin. 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 trminos de planificacin, herramientas e infraestructura.

La Arquitectura Orientada a Servicios (SOA) es un estilo arquitectnico de TI que soporta la transformacin 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 geogrfica y tecnolgicamente distinta, que combina servicios en Nueva York, Londres y Hong Kong, aunque estn todos instalados en su desktop local. Esos servicios pueden combinarse para realizar una tarea empresarial especfica, para permitir que su empresa se adapte a condiciones y requisitos cambiantes Cuando la implementacin de SOA es guiada por objetivos empresariales estratgicos, usted asegura la transformacin positiva de su empresa y puede obtener los beneficios principales de SOA, que son: Cmo se aprovecha la SOA y cmo ella afecta su empresa? IBM ha identificado cinco puntos de entrada para asegurar que toda solucin 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 tecnologas 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 innovacin y ms colaboracin, lo que posibilita la interaccin 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 colaboracin. Procesos: El punto de entrada relacionado con procesos ayuda las compaas 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. Informacin: Al usar ese punto de entrada a SOA, puede sacar provecho a las informaciones de su compaa en forma consistente y visible. Al facilitar informaciones consistentes y confiables a todas las reas de la empresa, habilita todas las reas de la compaa a innovar y, consecuentemente, puede competir con ms 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 compaa. 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 travs de otro canal empresarial. Puede incluso conectarse a socios externos fuera de su firewall en una forma segura. Reutilizacin: La reutilizacin de servicios con SOA permite aprovechar servicios que ya existen en la compaa. Al basarse en los recursos ya existentes, puede optimizar sus procesos empresariales, asegurar la consistencia en toda la compaa y reducir el tiempo de desarrollo. Todo ello ahorra tiempo y dinero. Usted tambin reduce la duplicacin de funcionalidades

en sus servicios y tiene la oportunidad de aprovechar las aplicaciones centrales comprobadas con las cuales el personal de su compaa est familiarizado. Estableceremos la correlacin entre esos puntos de entrada y varios casos de ejemplo a travs de una empresa ficticia llamada JK Enterprise para implementar un enfoque especfico 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 tecnologas de la informacin en un nuevo nivel, convirtindolas en autnticos 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 da es ms competitivo. Algunos de los principales beneficios que obtienen las organizaciones al implementar una Arquitectura SOA son:

Agilidad para habilitar rpidamente soluciones innovadoras y para adaptarse a cambios en el mercado cuando ocurran. Flexibilidad para reducir los tiempos y costos de implantacin, y para contar con una arquitectura gil que permita la evolucin, cambio y crecimiento del negocio. Rapidez para llegar primero al mercado antes que la competencia y crecer la participacin de mercado. Obtener mejor visibilidad de la informacin a travs de toda su organizacin. Optimiza sus procesos de negocios. Tasas internas del retorno sobre la inversin 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 informticas como ERP's, CRM's, etctera. Por otra parte permite: Una "personalizacin masiva" de las tecnologas de la informacin. La simplificacin del desarrollo de soluciones mediante la utilizacin de estndares de la industria y capacidades comunes de industrializacin. Aislar los sistemas frente a cambios generados por otras partes de la organizacin (proteccin de las inversiones realizadas). Alinear y acercar las reas de tecnologa y negocio.

Conclusin: SOA resuelve la mayora de los problemas de software que se presentan en la actualidad, como son los de facilitar y estandarizar la integracin de los sistemas, a travs de la interoperabilidad entre los datos de negocio, las aplicaciones y los requerimientos de los procesos de negocio. Permitiendo mayor flexibilidad y la de reutilizacin de los procesos de negocio para acomodarlos en el nuevo sistema de informacin de la empresa. Y todo ello con dos importantes factores, menor coste y mayor rapidez de desarrollo. Cubriendo las necesidades de las empresas modernas: adaptacin al cambio con el menor coste y tiempo posible.

Biografa: http://www.bsc.co.ve/index.php/soa http://www.ecured.cu/index.php/Arquitectura_Orientada_a_Servicios_(SOA)