Arquitecturas Multicapa

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