slides 12 [3pp], PDF, 30kb - Departamento de Informática

Arquitectura de Software
Componentes y Middleware [1]
Hernán Astudillo
Departamento de Informática
Universidad Técnica Federico Santa María
<hernan at acm.org>
Componentes y Middleware
•
•
•
•
Componentes
Middleware
Políticas y mecanismos
Ejemplo de notación ad-hoc
Sesión 13 [2004/v/04]
Arquitectura de Software H.Astudillo
2
Sobre el informe
Sesión 13 [2004/v/04]
Arquitectura de Software H.Astudillo
3
1
Stakeholders
analista
sp
ec
s
arquitecto
arquitetura
jefe de
projeto
ra
etu
uit
arq
ar
qu
ite
tu
ra
revisor
implantador
sis
tem
a
QA
Sesión 13 [2004/v/04]
sis
tem
a
Arquitectura de Software H.Astudillo
admin
4
Calidad según los stakeholders
• La solución (computaciones) debe...
– Satisfacer los requisitos (según analistas)
• La solución (ejecutables) debe...
– Ser administrable (según administradores)
• La solución (software) debe…
– Ser ‘construible’ (según programadores & diseñadores)
– Ser ‘testeable’ (según QA)
• La descripción de la solución debe...
– Ser evaluable (según otros arquitectos)
• El proceso de construcción debe...
– Ser manejable (según jefe de proyecto)
Sesión 13 [2004/v/04]
Arquitectura de Software H.Astudillo
5
Componentes
2
Componentes
• Componente [Whitehead]
– Pieza separable (independiente del contexto) de software
ejecutable
– ...que tiene sentido como unidad
– ...y puede interoperar con otros componentes
– ...dentro de un ambiente de apoyo
– ...y es accesable sólo vía sus interfaces
– ...y está listo para usar (posiblemente requiriendo
instalación y configuración)
Sesión 13 [2004/v/04]
Arquitectura de Software H.Astudillo
7
Componentes
• Fuentes de componentes
–
–
–
–
Dominio (entidades, propiedades...)
Interfaces
Capas de abstracción (“máquinas virtuales”)
Instanciaciones de arquetipos
Sesión 13 [2004/v/04]
Arquitectura de Software H.Astudillo
8
Interoperabilidad
• Problema: cooperación entre componentes
– Número exponencial de pares
• Se complica al introducir más de una tecnología
• Mecanismos estandarizados para describir interfaces
– CORBA IDL
– COM IDL
– Interoperabilidad entre tecnologías
• “Modelos de componentes”
• COM, CORBA, EJB
• “Wrappers” (envoltorios)
– Servicios
• Propiedades transaccionales
• Manejo de seguridad
• Monitoreamiento
Sesión 13 [2004/v/04]
Arquitectura de Software H.Astudillo
9
3
Modelos de componentes [1/3]
• Modelos de componentes distribuidos (clientes y
servidores)
– COM: Common Object Model (Microsoft; en .NET)
– CORBA: Common ORB Architecture (OMG: Object
Management Group)
• ORB: Object Request Broker
– Java (Sun, JCP)
• Modelos extendidos para mejor apoyar servidores
– MTS (Microsoft Transaction Service)
– CCM (CORBA Component Model)
– EJB (Enterprise Java Beans)
• J2EE (Java 2 Enterprise Edition)
Sesión 13 [2004/v/04]
Arquitectura de Software H.Astudillo
10
Modelos de componentes [2/3]
• Modelos extendidos con soporte adicional
–
–
–
–
Manejo transaccional
Seguridad
Persistencia
Disponibilidad
• “Clustering”, balanceo de carga
– Ambiente de ejecución
• Ciclo de vida (instanciación, GC...)
• “Threading”
• “Pooling” de conexiones
• Manejo de estado
– Monitoreamiento dinámico
Sesión 13 [2004/v/04]
Arquitectura de Software H.Astudillo
11
Modelos de componentes [3/3]
• Servicios
– “Location” (ubicación)
• detección de componentes/servicios; análogo a guía
telefónica
• JNDI (Java Naming & Directory Interface)
• CORBA Naming Service & Trading Service
– Manejo de transacciones
• autenticación, autorización, inviolabilidad, no- repudiación
• CORBA Security Service
• JAASL Java Authentication & Authorization Service
– Eventos, notificaciones & mensajería
• Mensajes asíncronos, point-to-point & publish -subscribe
• CORBA Notification (& Event) Services, Messaging Service
• JMS: Java Messaging Service
Sesión 13 [2004/v/04]
Arquitectura de Software H.Astudillo
12
4
Terminologías de mercado
“2 Capas”
• 2 capas: “cliente-servidor”
• Razón: concentrar recursos escasos en servidores
centralizados
– Redundancia mínima
– Rendimiento puede sufrir
– Autonomía mínima
Sesión 13 [2004/v/04]
Arquitectura de Software H.Astudillo
14
“3 capas”
• 3 capas
– Razón: compartir datos, preservando integridad (ACID)
– “Negocio”: procesamiento propio del negocio
– 2 partes: objetos de negocio (entidades del dominio) y
lógica de control (funciones)
– “Presentación”: interacción con usuarios (incl. informes) y
otros sistemas
– “Datos”: manejo de datos persistentes (incl. integridad)
Sesión 13 [2004/v/04]
Arquitectura de Software H.Astudillo
15
5
“4 capas”
Sesión 13 [2004/v/04]
Arquitectura de Software H.Astudillo
16
“4 capas” (Cont.)
• “Usuario”: mecanismos de interacción con usuarios
y otros sistemas
• “Workspace”: manejo de sesiones y transacciones
• “Negocio” (empresa): procesos y entidades del
negocio
• “Recursos”: elementos únicos compartidos (BD,
sistemas legado, servicios)
Sesión 13 [2004/v/04]
Arquitectura de Software H.Astudillo
17
Productos
• Categorías de productos
– Empaquetados por tipo de problema y tipo de solución
• Tipos de solución: tecnologías
– “Middleware”
– MOM, BD, “directory servers”, TP Monitors, “workflow”...
• Tipos de problemas: servicios del negocio
– Paquetes
– ERP (Enterprise Resource Planning), CRM (Customer
Relationship management) y variaciones, Knowledge
Management...
Sesión 13 [2004/v/04]
Arquitectura de Software H.Astudillo
18
6
Middleware
Middleware
• “Middleware”: tecnologías para comunicar
programas distribuidos
• Britton propone clasificar middleware usando 8
aspectos de la comunicación
–
–
–
–
–
–
–
–
Transporte (enlace) ( ej: TCP/IP)
Protocolo (ej: HTTP)
API (ej: ODBC)
Formato ( ej: ASCII)
Control de recursos en el servidor (ej: MTS)
Directorios/nombres ( ej: DNS)
Seguridad ( ej: Kerberos)
Administración
Sesión 13 [2004/v/04]
Arquitectura de Software H.Astudillo
20
Dimensiones en Middleware (Cont.)
• Participantes en la comunicación
– programas/objetos cada vez más pequeños y numerosos
– IP (hardware), TCP (procesos), IIOP (objetos)
• Modo de comunicación
– sesiones: protocolos con o sin ellas
• TCP (IP con sesión), UDP (IP sin sesión)
– topología: 1:M, peer-to-peer, M:1
– iniciador: push, pull
– integridad vs. puntualidad (“timeliness”)
• Interfaz
– con API: número fijo de entradas
– con IDL: mecanismo para definir API ad-hoc
Sesión 13 [2004/v/04]
Arquitectura de Software H.Astudillo
21
7
Servicios Web
• Integración usando infraestructura Web/Internet
• Aspectos
– Transporte
– Formato
– Búsqueda
• Soluciones empaquetadas (aún en desarrollo)
– “Web services”
• SOAP (Simple Object Access Protocol): HTTP + XML
• WSDL (Web Service Description Language)
• UDDI (Universal Description, Discovery and Integration)
– REST: Representational State Transfer
•
HTTP + URL + XML/HTML/GIF/MIME/etc. (sin
directorios)
– CORBA: IIOP + “marshalling” + Directory/Trader Service
Sesión 13 [2004/v/04]
Arquitectura de Software H.Astudillo
22
Praxis
Catálogos de arquitectura
• Catálogos
– Ingenieros tienen catálogos de partes disponibles
• con especificaciones de contexto, parámetros...
– Necesarios para centralizar y difundir información
• Fundamento teórico propuesto
– Clasificar Middleware
• Análisis de dimensiones aún pendiente
– Políticas y mecanismos
• Enfoque análogo
Sesión 13 [2004/v/04]
Arquitectura de Software H.Astudillo
24
8
Recursos y referencias
• Ivar Jacobson, Martin Griss, Patrik Jonsson
– Software Reuse: Architecture, Process and Organization
for Business Success, Addison Wesley (1997)
• Chris Britton
– IT Architectures & Middleware: Strategies for Building
Large, Integrated Systems, Addison Wesley (2000)
• Brett McLaughlin
– Building Java Enterprise Applications, Vol. 1:
Architecture, O'Reilly (2002)
• Katharine Whitehead
– Component-Based Development : Principles and Planning
for Business Systems, Addison-Wesley (2002)
Sesión 13 [2004/v/04]
Arquitectura de Software H.Astudillo
25
9