Arquitecturas Multicapa. Del modelo Monolítico al Multicapa
TGP 2006/7 – Ses.s 6 y 7
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
1
j m r r
Arquitectura de Componentes 2:Component frameworks
1:Components
Tier 1: Arquitectura de componentes individuales.
Tier 2: Arquitectura de los marcos de componentes. Macro-componentes definidos para realizar una función de negocio concreta.
Tier 3: Arquitectura del sistema de componentes. Super-componente que define todo el sistema.
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-2
j m r r
Arquitectura de Componentes (2)
COMPONENTE = módulo + conjunto de recursos
Módulo = conjunto de clases y puede que elementos de proceso no orientados a objeto (procedimientos y funciones).
Conjunto de recursos = múltiples interfaces que cada uno representa un servicio ofrecido por el componente.
Problemas: No basta una modelización correcta de jerarquía de clases e interacciones, se necesita una infraestructura (nivel de transporte) de comunicación que permita el flujo transparente de mensajes entre objetos de distintas aplicaciones en distintas máquinas Se debe evitar el crecimiento exponencial de interfaces
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-3
j m r r
Tecnologías de Componentes
Alternativas:
Sockets.
Remote Procedure Calls (RPC).
Menos maduro, menos portable y además propietario.
Java Remote Method Invocation (RMI)
No soporta objetos explícitamente.
Microsoft Distributed Component Object Model (DCOM)
Implementación costosa.
Solo para JAVA.
Common Object Request Broker Architecture (CORBA)
Multiplataforma, multilenguaje, ...
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-4
j m r r
Evolución C/S 2 capas Sistemas monolíticos
Presentación Negocio
C/S 3 capas Presentación
Presentación Negocio Datos
Negocio
Negocio
Datos Datos
BD TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-5
j m r r
Multi-Capa Cada “Capa” contiene responsabilidades propias (Abstración) Sin acoplamiento (enlaces débiles). Independencia de las “Capas” Utilizaremos clases (Encapsulación y Herencia) que facilitaran la mantenibilidad y reutilización
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-6
j m r r
¿Por que cambiar?
Beneficios (Larman, 1998): Aislamiento
de la lógica de la aplicación en componentes separados reutilizables en otras aplicaciones. Distribución de capas en diferentes máquinas o procesos, lo que puede mejorar el rendimiento, aumentar la coordinación y la compartición de información entre cliente y servidor. Dedicación de recursos a cada una de las capas y posibilidad de desarrollarlas en paralelo. TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-7
j m r r
Tres Capas
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-8
j m r r
Tres capas - MĂşltiples Clientes
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-9
j m r r
Multicapa General
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-10
j m r r
Multicapa (2)
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-11
j m r r
Paquetes y Subpaquetes
Dentro de cada capa se pueden establecer diferentes subsistemas o subcapas que pueden encerrar diferentes funcionalidades. TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-12
j m r r
Modelo Tres capas
Tes capas Presentación
Formularios, cuadros de diálogo, Páginas Web, Documentos Ofímática...
Lógica
o Interfaz
de Dominio
Todas los paquetes y clases relacionados con las reglas del negocio.
Persistencia
Todas los paquetes y clases relacionados con la forma de almacenar los datos y los sistemas gestores de bases de datos.
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-13
j m r r
Relaciones
Relaciones entre capas Se
agrupan los componentes en paquetes que suelen tener una relación de dependencia entre ellos:
Dentro de un paquete hay elementos que necesitan de los elementos del otro paquete.
Los
elementos de Presentación necesitan a los de Lógica de Dominio para funcionar
Recogen/muestran información de/a los usuarios Algunos objetos de la capa de presentación necesitan conocer a algunos de la capa de lógica de dominio, pero no al revés -> Los objetos del dominio no deben depender de la presentación
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-14
j m r r
Relaciones (2)
Los de Lógica de Dominio necesitan a los de Persistencia para funcionar y éstos a los de Lógica de Dominio. Los
objetos del dominio querrán almacenar datos pero necesitan conocer a objetos de la capa de persistencia. Será necesario que los de persistencia conozcan el estado de los de dominio, por lo que la relación de dependencia es mutua Es poco deseable que los componentes de la lógica del dominio dependan de alguien, y menos de la Presentación porque será necesario que funcionen con cualquier tipo de pantalla. TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-15
j m r r
Problema de acoplamiento
Problema
El principal problema es el acoplamiento entre clases de distintas capas
Soluciones (diseño)
Aplicando patrones de diseño
Para construir la base de datos del sistema a partir diagrama de clases (ej. Patrón 1C1T) Para acceder a la BB.DD (ej. Patrón Agente / Broker) Para sincronizar el interfaz de usuario con lo que la capa de aplicación (ej. Patrón Observador)
Tecnológicas (Leguajes “Interchange”)
Texto, SQL, XML,
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
… Jmrr-16
j m r r
Patrón 1C1T
Consiste en que cada clase del diagrama de clase se va a convertir en una tabla relacional. Las
relaciones de herencia se transforman en restricciones de clave 1:1 Las asociaciones de agregación se traducen en relaciones de clave externa cuya cardinalidad depende de la multiplicidad de la asociación o agregación. TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-17
j m r r
Patrón Agente o Broker
Un Agente o Broker es
una clase que se encarga de dar acceso a la base de datos a los objetos de la capa de dominio, de manera que se consigue un cierto desacoplamiento de éstos. Es la única clase que tiene un conocimiento directo de la base de datos, ofreciendo una interfaz con las aplicaciones CRUD. TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-18
j m r r
Patrón Modelo- VistaControlador
MVC Permite
desacoplar la interfaz de usuario de la lógica de dominio Resuelve el problema de sincronización entre objetos que trabajan sobre los mismos datos. Se crea una clase intermedia que es conocida por la clase de dominio y que conoce a los distintos interfaces. Cuando se producen cambios en la instancia de la clase de dominio los notifica a la clase de interfaz, quedando una vista consistente para todos 2006/7 (seslos 6 yque 7) estén usando esa clase.
TGP Arquitecturas Multicapa
Jmrr-19
j m r r
Aplicaciones WEB
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-20
j m r r
Servicios WEB
Web Services, como indica su propio nombre, son servicios ofertados vía Web. Un servicio web es un servicio, con un interfaz definido y conocido, al que se puede acceder a través de internet Un servicio web está definido por un URI (Uniform Resource Identification) y por su interfaz las aplicaciones se convierten en clientes que integran servicios web procedentes de diferentes proveedores
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-21
j m r r
Servicios WEB
Los servicios web se dividen en:
servicios de transporte (HTTP)
Servicios de mensajería (SOAP)
que especifican cómo se tiene que codificar el mensaje, que contiene los datos que se intercambian, entre el cliente y el servidor
Servicios de descripción (WSDL)
los protocolos del nivel más bajo, que codifican la información independientemente de su formato, y que pueden ser comunes a otros servicios
Los servicios deben de especificarse, para que una aplicación sepa de forma automática qué formato usar para comunicarse con un servicio
Servicios de descubrimiento (UDDI)
permitiendo no sólo describir servicios web, sino productos, la empresa en sí, y cómo está dispuesta a llevar a cabo transacciones
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-22
j m r r
Servicios WEB
Una petición de un servicio web constaría de los siguientes pasos: En el cliente se elabora una petición de una operación con unos parámetros La petición se transforma a formato XML utilizando WSDL La petición transformada se envía vía HTTP utilizando SOAP El servidor de servicios web recibe la petición El servidor determina que operación debe realizarse y transforma los parámetros de formato XML a su representación correspondiente en el lenguaje utilizado para implementar el servidor El servidor invoca la operación con los parámetros enviados, elabora una respuesta y se la envía al cliente de la misma forma que se ha explicado 2006/7 (ses 6 y 7)
TGP Arquitecturas Multicapa
Jmrr-23
j m r r
Servicios WEB
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-24
j m r r
Desarrollo Servicios WEB
Para implementar servicios web existen varias APIs (comerciales y
gratuitas) para los lenguajes más usuales. Las APIs no son estándares pero esto no afecta a la interoperabilidad ya que la interoperabilidad es posible porque los protocoles (SOAP, WSDL, UDDI) están estandarizados. Dos tipos de APIs:
APIs de programación basadas en mensajes:
tanto el receptor como el emisor disponen de un proveedor de mensajería. Permiten mensajes síncronos y asíncronos, enviar a más de un receptor y calidad de servicio. Son APIs muy potentes pero complejas.
APIs de programación basadas en RPCs:
en el caso de un lenguaje orientado a objetos, este tipo de APIs permiten definir interfaces (en WSDL) cuyos métodos se pueden invocar remotamente (similar a CORBA). No es tan potente como las APIs basadas en mensajes pero es mucho más sencilla de usar.
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-25
j m r r
Desarrollo Servicios WEB
Dónde encontrar APIs Dentro
de la tecnología Microsoft, los servicios web forman parte de .NET en cuanto a Java, existen muchas APIs de distintos fabricantes (Iona, Inprise, Oracle, IBM, Sun,...) y también gratuitas (Apache). Sun está estandarizando el API Java para servicios web. Consta de varias APIs que forman parte de J2EE: JAXM: Java API for XML Messaging JAX-RPC: Java API for XML-based RPC JAXR: Java API for XML Registries TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-26
j m r r
Más Información
Información sobre Servicios Web: http://www.webservices.org Servicio gratuito para registrar y buscar servicios web: http://www.uddi.org Documentación sobre el API Java estándar de Servicios Web e implementación de referencia de Sun: http://java.sun.com/j2ee/webservices/index.html Documentación y software para distintos lenguajes: http://www.ibm.com/developerworks/webservices W3C: http://www.w3.org
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-27
j m r r
Persistencia
Operaciones Persistencia (CRUD) Create,
Operación Insert en BB.DD relacionales
Read,
se utilizan para desmaterializar
se utilizan para materializar
Operación Select en BB.DD relacionales
Update,
se utilizan para actualizar el estado de una base de datos
Operación Update en BB.DD relacionales
Delete,
Se utilizan para eliminar registros de la base de datos
TGP 2006/7 (ses 6 y 7) Delete Operación Arquitecturas Multicapa
en BB.DD relacionales Jmrr-28
j m r r
Lógica Clases y Sistemas desarrollando la funcionalidad de la aplicación Múltiples capas Sistemas Remotos
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-29
j m r r
Presentación
Clientes Pesados o Fuertes Windows
Clientes Ligeros o Débiles WEB,
Forms, Diálogos Controles
Script, …
Aplicaciones Ofimática Word,
Excel, Access
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-30
j m r r
Tecnologías de Presentación
Lenguajes de Marcas HMTL,
XML, XHTML
Lenguajes de Script JavaScript,
Modelos de Objetos DOM,
VSS, VBA, Perl,
DHTML, …
Diálogos y Controles OCX
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-31
j m r r
Presentación (Forms) Formularios, Diálogos y Controles Arquitectura SAA Fuerte dependencia del Cliente local
Sistema
Operativo Librarías Locales Instalación
Aumenta seguridad
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-32
j m r r
Presentación (Ofimática) Dependencia del sistema local Dificultad de mantenimiento Necesidad de controles exhaustivos Usuarios altamente motivados Problemas: “propiedad de la información” Más utilidad en extracción de datos que en mantenimiento
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-33
j m r r
Presentación (WEB) Sin dependencias locales Dificultades de comunicación (Refresco) Sin mantenimiento no necesidades de formación Problema : Seguridad Facilidades de Mantenimiento
TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-34
j m r r
Propuesta de Capa de Presentación
Entrada de Datos y Mantenimiento Cliente
Tareas de seguimiento y otras sencillas Cliente
Pesado (Formularios) Ligero (WEB)
Explotación de datos e información Cliente
Ligero (WEB ) Ofimática TGP 2006/7 (ses 6 y 7) Arquitecturas Multicapa
Jmrr-35