2013

1.-MODELO VISTA CONTROLADO (MVC) 2.-ORIENTADO A SERVICIOS(SOA)

ALUMNO: HERVIN RENE PERAL ANTONIO GRUPO: 8 F MATERIA: SISTEMAS DISTRIBUIDOS

03/03/2013

INTRODUCCION Los patrones de arquitectura expresan esquemas fundamentales de la estructura organizacional de los sistemas de software. Estos proporcionan un conjunto de subsistemas predefinidos, especifica sus responsabilidades, e incluyen las normas y directrices para la organizacin y las relaciones entre ellas. Entre los patrones de arquitectura, existe uno denominado Modelo Vista Controlador (MVC). El MVC fue desarrollado originalmente en 1970 en la Xerox Palo Alto Research Center (PARC). Fue construido originalmente para el manejo de la GUI (graphical user interface). El problema de diseo que el MVC resuelve, se puede simplificar en tres funciones principalescomunes en muchas aplicaciones. Los datos se mantienen en un back-end store o en un sistema remoto. Muestra una capa de presentacin para el usuario final. Presenta una capa lgica que decide cuales pantallas son presentadas al usuario, qu sucede cuando ocurre un error?, y exactamente cmo y cuando el sistema es actualizado

El otro patrn de arquitectura se llama Orientada a Servicios (SOA) El acrnimo SOA proviene del ingls Service-Oriented Architecture. Se trata de un modelo de arquitectura que caracteriza el procedimiento para crear y usar los diversos procesos, reunidos en forma de servicios, que configuran un determinado Proceso de Negocio (Un proceso de negocio se puede ver como un conjunto estructurado de tareas, que contribuyen colectivamente a lograr los objetivos de una organizacin.) Esta arquitectura define y proporciona la infraestructura necesaria para que el intercambio de informacin y la participacin en los procesos de negocio se lleve a cabo con total independencia de la plataforma hardware-software sobre la que trabajan: sistema operativo, lenguaje de programacin, caractersticas de los equipos, etc.

DESARROLLO ARQUITECTURA MODELO VISTA CONTROLADO

Este patrn fue descrito por primera vez por Trygve Reenskaug en 1979, y la implementacin original fue realizada en Smalltalk en los laboratorios Xerox. MVC se basa en la separacin de la aplicacin en tres capas principales: Modelo, Vista y Controlador. Se usa (l o alguna de sus variantes) en la gran mayora de las interfaces de usuario. La arquitectura MVC (Model/View/Controller) fue introducida como parte de la versin Smalltalk-80 del lenguaje de programacin Smalltalk a la ingeniera de Software. Fue diseado para reducir el esfuerzo de programacin necesario en la implementacin de sistemas mltiples y sincronizados de los mismos datos. Sus caractersticas principales son que el Modelo, las Vistas y los Controladores se tratan como entidades separadas; esto hace que cualquier cambio producido en el modelo se refleje automticamente en cada una de las vistas. En la siguiente figura, vemos la arquitectura MVC en su forma ms general, Hay un Modelo, mltiples Controladores que manipulan ese modelo, y hay varias vistas de los datos del Modelo, que cambian cuando cambia el estado de ese Modelo.

Ventajas Este modelo de arquitectura presenta varias ventajas: Hay una clara separacin entre los componentes de un programa; lo cual nos permite implementarlos por separado. Hay un API muy bien definido; cualquiera que use el API, podr reemplazar el Modelo, la Vista y el Controlador, sin aparente dificultad. La conexin entre el Modelo y sus vistas es dinmica; se produce en tiempo de ejecucin no en tiempo de compilacin Muchas aplicaciones utilizan un mecanismo de almacenamiento persistente (como puede ser una base de datos) para almacenar los datos. MVC no menciona especficamente esta capa de acceso a datos porque supone que est encapsulada por el modelo. Independencia del dispositivo que visualiza nuestra aplicacin. Automatizacin y reutilizacin del cdigo en todas las aplicaciones que desarrollemos Posibilidad de crear equipos altamente especializados Se presenta la misma informacin de distintas formas. Las vistas y comportamiento de una aplicacin deben reflejar las manipulaciones de los datos de forma inmediata. Debera ser fcil cambiar la interfaz de usuario (incluso en tiempo de ejecucin). Permitir diferentes estndares de interfaz de usuario o portarla a otros entornos no debera afectar al cdigo de la aplicacin.

Al incorporar el modelo de arquitectura MVC a un diseo, las piezas se pueden construir por separado y luego unirlas en tiempo de ejecucin. Si uno de los componentes funciona mal puede reemplazarse sin afectar a las otras piezas. MVC es utilizado con mayor frecuencia en las aplicaciones web, donde la Vista es la pgina HTML, y el Controlador es el cdigo que rene la data dinmica y genera el contenido de la pgina. El Modelo es representado por el contenido actual, que usualmente se encuentra almacenado en una base de datos o en archivos XML.

Desventajas

El tiempo de desarrollo de una aplicacin que implementa el patrn de diseo MVC es mayor, al menos en la primera etapa, que el tiempo de desarrollo de una aplicacin que no lo implementa, ya que MVC requiere que el programador implemente una mayor cantidad de clases que en un entorno de desarrollo comn 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 muchsimo ms mantenible, extensible y modicable 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 modicar y comunicar los mdulos de una aplicacin. Esta arquitectura inicial debe incluir, por lo menos: un mecanismo de eventos para poder proporcionar las noticaciones que genera el modelo de aplicacin; una clase Modelo, otra clase Vista y una clase Controlador genricas que realicen todas las tareas de comunicacin, noticacion y actualizacin que seran 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.

DEFINICION DE LAS PARTES DEL MODEL-VIEW-CONTROLLER

MODELO: Es la representacin especfica de la informacin con la cual el sistema opera. La lgica de datos asegura la integridad de estos y permite derivar nuevos datos

El Modelo es el responsable de: 1. Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo sea independiente del sistema de almacenamiento. 2. Define las reglas de negocio (la funcionalidad del sistema). Un ejemplo de regla puede ser: Si la mercanca pedida no est en el almacn, consultar el tiempo de entrega estndar del proveedor. 3. Lleva un registro de las vistas y controladores del sistema. 4. Si estamos ante un modelo activo, notificar a las vistas los cambios que en los datos pueda producir un agente externo (por ejemplo, un fichero batch que actualiza los datos, un temporizador que desencadena una insercin, etc.).

Vista: Este presenta el Modelo, usualmente la interfaz de usuario. La vista es la capa de la aplicacin que ve el usuario en un formato adecuado para interactuar, en otras palabras, es nuestra interfaz grfica.

Las vistas son responsables de: 1. Recibir datos del modelo y los muestra al usuario. 2. Tienen un registro de su controlador asociado (normalmente porque adems lo instancia). 3. Pueden dar el servicio de Actualizacin(), para que sea invocado por el controlador o por el modelo (cuando es un modelo activo que informa de los cambios en los datos producidos por otros agentes).

Controlador: El Controlador es la capa que controla todo lo que puede realizar nuestra aplicacin. Responde a eventos, usualmente acciones del usuario e invoca cambios en el modelo y probablemente en la vista. Est compuesto por acciones que se representan con funciones en una clase. Por ejemplo, yo tengo mi controlador llamado Clientes, y este controlador puede realizar las acciones Crear,Editar,Listar entre otras.

El controlador es responsable de: 1. Recibe los eventos de entrada (un clic, un cambio en un campo de texto, etc.). 2. Contiene reglas de gestin de eventos, del tipo SI Evento Z, entonces Accin W. Estas acciones pueden suponer peticiones al modelo o a las vistas. Una de estas peticiones a las vistas puede ser una llamada al mtodo Actualizar (). Una peticin al modelo puede ser Obtener_tiempo_de_entrega (nueva_orden_de_venta).

Flujo que sigue el control en una implementacin general de un MVC Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo que sigue el control generalmente es el siguiente: 1. El usuario interacta con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botn, enlace) 2. El controlador recibe (por parte de los objetos de la interfaz-vista) la notificacin de la accin solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a travs de un gestor de eventos (handler) o callback. 3. El controlador accede al modelo, actualizndolo, posiblemente modificndolo de forma adecuada a la accin solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). Los controladores complejos estn a menudo estructurados usando un patrn de comando que encapsula las acciones y simplifica su extensin. 4. El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se refleja los cambios en el modelo (por ejemplo, produce un listado del contenido del carro de la compra 5. La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.

ARQUITECTURA ORIENTADA A SERVICIOS (SOA)

La Arquitectura Orientada a Servicios de cliente (en ingls Service Oriented Architecture), 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 bien definida 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 define las siguientes capas de software: Aplicaciones bsicas: Sistemas desarrollados bajo cualquier arquitectura o tecnologa, geogrficamente dispersos y bajo cualquier figura de propiedad. De exposicin de funcionalidades: Donde las funcionalidades de la capa aplicativa son expuestas en forma de servicios. (generalmente como servicios web). De integracin de servicios: Facilitan el intercambio de datos entre elementos de la capa aplicativa orientada a procesos empresariales internos o en colaboracin. De composicin de procesos: Que define el proceso en trminos del negocio y sus necesidades, y que vara en funcin del negocio. De entrega: Donde los servicios son desplegados a los usuarios finales.

Elementos esenciales de una Arquitectura Orientada a Servicios. Esta arquitectura presenta un modelo de construccin sistemas distribuidos en el que la funcionalidad demandada ser entregada a la aplicacin a travs de servicios. En la siguiente figura se muestra el esquema de la arquitectura y los elementos. El esquema se encuentra dividido en 2 zonas; una que abarca el mbito funcional de la arquitectura y otra vinculada a la calidad de servicio.

Funciones: Transporte: es el mecanismo utilizado para llevar las demandas de servicio desde un consumidor de servicio hacia un proveedor de servicio, y las respuestas desde el proveedor hacia el consumidor. Protocolo de comunicacin de servicios: es un mecanismo acordado a travs del cual un proveedor de servicios y un consumidor de servicios comunican qu est siendo solicitado y qu est siendo respondido. Descripcin de servicio: es un esquema acordado para describir qu es el servicio, cmo debe invocarse, y qu datos requiere el servicio para invocarse con xito. Servicio: describe un servicio actual que est disponible para utilizar. Procesos de Negocio: es una coleccin de servicios, invocados en una secuencia particular con un conjunto especfico de reglas, para satisfacer un requisito de negocio. Registro de Servicios: es un repositorio de descripciones de servicios y datos que pueden utilizar los proveedores de servicios para publicar sus servicios, as como los consumidores de servicios para descubrir o hallar servicios disponibles.

Calidad de Servicio: Poltica: es un conjunto de condiciones o reglas bajo las cuales un proveedor de servicio hace el servicio disponible para consumidores. Seguridad: es un conjunto de reglas que pueden aplicarse para la identificacin, autorizacin y control de acceso a consumidores de servicios. Transacciones: es el conjunto de atributos que podran aplicarse a un grupo de servicios para entregar un result ado consistente. Administracin: es el conjunto de atributos que podran aplicarse para manejar los servicios proporcionados o consumidos.

Diseo y desarrollo de SOA

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. En un ambiente SOA, los nodos de la red hacen disponibles sus recursos a otros participantes en la red como servicios independientes a los que tienen acceso de un modo estandarizado. La mayora de las definiciones de SOA identifican la utilizacin de Servicios Web (empleando SOAP y WSDL) en su implementacin, no obstante se puede implementar SOA utilizando cualquier tecnologa basada en servicios.

Beneficios Los beneficios que puede obtener una organizacin que adopte SOA son: Mejora en los tiempos de realizacin de cambios en procesos. Facilidad para evolucionar a modelos de negocios basados en tercerizacin. Facilidad para abordar modelos de negocios basados en colaboracin con otros entes (socios, proveedores). Poder para reemplazar elementos de la capa aplicativa SOA sin disrupcin en el proceso de negocio. Facilidad para la integracin de tecnologas dismiles.

Desventajas SOA depende de la implementacin de estndares. Sin estndares, la comunicacin entre aplicaciones requiere de mucho tiempo y cdigo. SOA no es para: aplicaciones con alto nivel de transferencia de datos, aplicaciones que no requieren de implementacin del tipo request/response y para aplicaciones que tienen un corto periodo de vida. Incrementalmente se hace difcil y costoso el ser capaz de cumplir con los protocolos y hablar con un servicio. Implica conocer los procesos del negocio, clasificarlos, extraer las funciones que son comunes a ellos, estandarizarlas y formar con ellas capas de servicios que sern requeridas por cualquier proceso de negocio. En la medida en que un servicio de negocio, vaya siendo incorporado en la definicin de los procesos de negocio, dicho servicio aumentara su nivel de criticidad. Con lo cual cada que se requiera efectuar una actualizacin en dicho servicio (por ejemplo, un cambio en el cdigo, una interfaz nueva, etc.), deber evaluarse previamente el impacto y tener mucho cuidado con su implementacin. Sin embargo, parte de la problemtica anterior, puede ser solventada en virtud a un buen diseo del servicio.

CONCLUSION Conclu que estos son patrones de arquitectura que funcionan y cada uno de estos patrones funcionan diferentes. El MVC funciona para reducir el esfuerzo de programacin necesario en la implementacin de sistemas mltiples y sincronizados de los mismos datos. El MVC se divide en tres partes MODELO: Representa la informacin especifica con el cual el sistema opera. VISTA: Este representa la capa de la aplicacin que ve el usuario en un formato adecuado para interactuar. CONTROLADOR: Es la capa que controla todo lo que puede realizar nuestra aplicacin. El SOA permite la creacin de sistemas altamente escalables que reflejan el negocio de la organizacin, a su vez brinda una forma bien definida de exposicin e invocacin de servicios El SOA contiene los siguientes elementos para sus funciones Transporte Protocolo de comunicacin Descripcin del servicio Servicio Proceso de Negocio

REFERENCIAS BIBLIOGRAFICAS

1. http://www.slideshare.net/rolys35/arquitectura-orientada-a-servicios-soa7084661 2. http://prestashop5estrellas.wordpress.com/2010/03/29/el-patron-mvcmodelo-vista-controlador/ 3. http://soa-fpuna.blogspot.mx/2011/11/ventajas-y-desventajas.html 4. http://es.scribd.com/doc/51278468/Modelo-Vista-Controlador