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 2 Sobre el informe 3 1
sistema Stakeholders analista specs sistema arquitetura arquitecto arquitetura arquitetura revisor jefe de projeto implantador QA 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) 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 accesablesólo vía sus interfaces...y está listo para usar (posiblemente requiriendo instalación y configuración) 7 Fuentes de componentes Dominio (entidades, propiedades...) Interfaces Capas de abstracción ( máquinas virtuales ) Instanciaciones de arquetipos Componentes 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 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) 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 Monitoreamientodinámico 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 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 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) 15 5
4 capas 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) 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... 18 6
Middleware Middleware : tecnologías para comunicar programas distribuidos Middleware 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 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 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 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 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) 25 9