Arquitecturas Multicapa

Page 1

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


Turn static files into dynamic content formats.

Create a flipbook
Issuu converts static files into: digital portfolios, online yearbooks, online catalogs, digital photo albums and more. Sign up and create your flipbook.