Arquitectura del software Parte I. Introducción Tema 2- Estilos de la vista de componentes y conectores

Please download to get full document.

View again

All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
 6
 
 

Art

  Arquitectura del software Parte I. Introducción Tema 2- Estilos de la vista de componentes y conectores Juan Manuel Serrano Universidad Rey Juan Carlos Ingeniería
Related documents
Share
Transcript
Arquitectura del software Parte I. Introducción Tema 2- Estilos de la vista de componentes y conectores Juan Manuel Serrano Universidad Rey Juan Carlos Ingeniería Informática Referencias P. Clements et al. Documenting Software Architectures. Views and Beyond. Addison Wesley, 2003 Parte I (Software Architecture Viewtypes and Styles) N. Medvidovic, E.M.Dashofy, R. N. Taylor. The role of middleware architecturebased software development. International Journal of Software Engineering and Knowledge Engineering. Vol. 13, nº 4 (2003) I. Gorton. Essential Software Architecture. Springer-Verlag, 2006 W. Emmerich, M. Aoyama, J. Sventek. The impact of research on middleware technology. ACM SIGSOFT Software Engineering Notes, Vol. 32, nº 1, 2007 G. Mühl, L. Fiege, P. Pietzuch. Distributed Event-Based Systems. Springer, P. Th. Eugster, P. A. Felber, R. Guerraoui, A. Kermarrec. The Many Faces of Publish/Subscribe. IEEE Computer Surveys, vol. 35, nº2, M. Papazoglou. Web Services: Principles and Technology. Prentice Hall, 2008 Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 2 1 Content Introducción Orientadas a objetos Cliente/Servidor Peer-to-peer Orientadas a servicios Orientadas a eventos Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 3 Vista de componentes y conectores En general, los estilos de las vistas modulares y de asignación son universales; los estilos de C&C definen modelos computacionales particulares Clasifican el software en distintas categorías (ej. paradigmas de programación; tipología de middlewares) Desarrollo de software orientado a componentes vs. desarrollo de software guiado por la arquitectura Conectores como elementos software de primer orden Proporcionan patrones arquitectónicos dirigidos a la resolución de problemas de diseño Permiten evaluar propiedades no-funcionales claves del sistema ej. rendimiento, eficiencia, fiabilidad (tolerancia a fallos, disponibilidad, etc.) seguridad; mantenibilidad, portabilidad, reusabilidad, etc. En etapas tempranas del proceso de desarrollo A partir de las propiedades de los componentes y conectores que lo constituyen Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 4 2 Estilos de la vista de C&C Pipe & Filter Object-oriented Client/Server Peer to peer Publish/Subscribe Shared data Mobile code Service-oriented Process-oriented (e.g. multiagent architectures)... Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 5 Clasificación [Mühl et al., 06] Initiator: el componente que inicia la interacción, o bien el consumer (consumidor de información o servicios) o el productor (de información o servicios) Adressee: indica si la comunicación es directa (el componente que inicia la interacción conoce al receptor) o no Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 6 3 Clasificación [Eugster et al., 03] Las interacciones pueden estar desacopladas en diferentes aspectos Tiempo Los participantes en la interacción no tienen por qué estar todos activos al mismo tiempo Espacio Los participantes en la interacción no tienen por qué conocerse de antemano; ni tienen referencias de los demás, ni saben cuántos están participando en la interacción Sincronización Los participantes en la interacción no bloquean su flujo de control cuando intervienen activamente en la misma. Un mecanismo de interacción puede ser síncrono con respecto al consumidor, al productor o a ambos. Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 7 Clasificación [Eugster et al., 03] RPC ( Remote Procedure Call / Remote Invocations ) Hacen transparente la comunicación con componentes remotos E.g. Java RMI, CORBA, DCOM,.NET Remoting, Los consumidores están fuertemente acoplados temporal y espacialmente; el consumidor también se encuentra acoplado síncronamente Dos alternativas para eliminar la sincronización del consumidor One-way, asynchronous calls (aka. Fire-and-forget) Future remote invocations Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 8 4 Clasificación [Eugster et al., 03] 1) Synchronous RPC 2) One-way RPC 3) Future RPC Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 9 Clasificación [Eugster et al., 03] Notificaciones (aka observer pattern) Los consumidores registran su interés por determinada información con el propio productor Los productores gestionan las subscripciones y notifican directamente a su lista de subscriptores Una invocación síncrona se desdobla en dos tipos de notificaciones asíncronas, consiguiendo el desacoplamiento síncrono Sin embargo, productores y consumidores siguen acoplados espacial y temporalmente Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 10 5 Clasificación [Eugster et al., 03] Shared data (aka tuple spaces, shared memory) Productores y consumidores comparten un espacio de memoria compartido al que acceden para exportar (out), importar (in) y leer (read) información E.g. JavaSpaces, TSpaces, Desacoplamiento espacial y temporal. Acoplamiento síncrono con los consumidores: extraen (pull) la información síncronamente JavaSpaces extiende el modelo básico con notificaciones asíncronas One-to-n y one-of-n semantics Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 11 Clasificación [Eugster et al., 03] Mensajería (aka message queuing) Denotan una familia de productos (e.g. MQ Series, TIBCO, ) conocida como Message Oriented Middleware (MOM) Suelen ofrecer soporte adicional para Publish/Subscribe Point-to-point queuing Los mensajes son concurrentemente y síncronamente extraídos (pull) de las colas (one-of-n semantics similar a los espacios de tuplas) Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 12 6 Infraestructuras de middleware Sistemas distribuidos Aplicaciones software en las que los componentes del sistema no comparten un espacio de memoria y flujo de control común. Grado de distribución: red de área local., internet Infraestructuras de middleware Capa de software situada entre la aplicación y el sistema operativo que facilita la comunicación y coordinación de los componentes distribuidos Permite al programador concentrarse en la funcionalidad de la aplicación El middleware se encarga de servicios que no proporciona el sistema operativo concurrencia, gestión de transacciones, gestión de la comunicación por red, etc., Papel similar a los sistemas de gestión de bases de datos en el desarrollo de sistemas de información Requisitos no funcionales relevantes rendimiento (invocaciones remotas), fiabilidad (fault tolerance, availability) (fallos en la red, en el host servidor, ), escalabilidad, seguridad, interoperabilidad, etc. Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 13 Middlewares vs. arquitecturas C&C Middlewares como conectores compuestos El middleware en sí mismo es un conector compuesto Gestiona distintas conexiones entre los componentes conectados a él Los distintos tipos de middleware se pueden distinguir por los conectores primitivos que proporcionan un middleware concreto implementa un estilo arquitectónico básico Estilo arquitectónico Client/Server Publish/Subscribe, Service oriented. Tipo de middleware Middleware orientado a objetos Middleware orientados a mensajes Middleware orientado a servicios Productos CORBA, Java RMI,. Net Remoting, IBM WebSphere MQ, TIBCO Rendezvous,... Web services (W3C, Restful,..) Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 14 7 Middlewares vs. arquitecturas C&C :Host :Middleware :Host :Component :Interaction :Host :Host attached :Interaction COMPONENTES Gestión del ciclo de vida (activación, ) Gestión de concurrencia (colas, hilos, ) Replicación/Persistencia/Migración (fiabilidad/escalabilidad) Heterogeneidad (interoperabilidad) INTERACCIONES Modalidad (síncrona, asíncrona, ) Cardinalidad: 1-1, 1-many, Servicios de directorio (páginas blancas, amarillas) Transparencia de acceso/localización (escalabilidad) QualityOfService (QoS): best effort, transaccionalidad (fiabilidad) Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 15 Middlewares vs. arquitecturas C&C Ambas se refieren a las interacciones entre componentes del sistema Distinto nivel de abstracción y etapa del proceso de desarrollo (diseño vs. implementación) Arquitecturas software: diseño del sistema a un nivel alto de abstracción/granularidad Middlewares: facilitan la interoperabilidad de los componentes a nivel de implementación Desarrollo dirigido por la arquitectura (architecture-driven development) La implementación de los conectores debe satisfacer las propiedades básicas identificadas a nivel arquitectónico Dirigido a evitar posibles desajustes arquitectónicos (architectural mismatch) Encapsulación de middlewares convencionales en conectores de alto nivel Desacoplamiento de componentes y middlewares básicos Estrategia similar a la implementación de componentes (interfaz vs. implementación) Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 16 8 Middlewares vs. arquitecturas C&C Arquitectura C&C (Estilo Arquitectónico C2) Alternativa Implementación I Notificaciones Peticiones Alternativa Implementación II Encapsulación de la implementación Componentes no comparten espacio de memoria ni flujo de control Conectores multicast, two-way, message-based Interfaz C2 [Medvidovic et al. 03] Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 17 Content Introducción Orientadas a objetos Cliente/Servidor Peer-to-peer Orientadas a servicios Orientadas a eventos Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 18 9 Modelo de computación orientado a objetos :ObjectMachine :OBJECT 1 attr 1 =... op attr 2 =... 1 op met 1 =... op met 2 =... n... :Caller CONNECTORS Message sending/operation calls op i (...): OperationCall results, exceptions :Callee :Caller op 1 op 2... op n :OBJECT 2 attr 1 =... attr 2 = met 1 =... met 2 = COMPONENTS encapsulation of state & funcionality op i (...) :OBJECT 4 attr 1 =... op attr 2 =... 1 op met 1 =... op met 2 =... n... :Callee :Callee op i (...) :Caller op 1 op 2... op n :OBJECT 3 attr 1 =... attr 2 = met 1 =... met 2 = Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 19 Middlewares orientados a objetos Evolución de middlewares procedurales (Invocaciones remotas de procedimientos -RPCs) Paralela a los lenguajes de programación orientados a objetos RPCs ya soportadas por los sistemas operativos actuales (Windows, Unix, ) Tecnologías OMG CORBA, Microsoft DCOM, Java RMI,.NET Remoting, W3C SOAP Componentes/Conectores Componentes Heterogéneos (CORBA): Java, Lisp, Python, Homogéneos: objetos Java (RMI)/ Componentes C# (.NET) Conectores: peticiones a objetos remotos (síncronas) Un objeto cliente solicita a un objeto servidor (posiblemente remoto) la ejecución de una operación Marshalling/Unmarshalling (serialization/deserialization) realizada de forma transparente por stubs Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 20 10 Middlewares orientados a objetos Conectores alternativos (CORBA) Sincronización diferida y peticiones send-and-forget (one-way) Servicios de notificación y eventos Servicios de middleware (CORBA) Varias políticas de activación y políticas de threading Propiedades Interoperabilidad CORBA: datos, lenguajes, SSOO, plataforma e inter-middleware (COM - CORBA - RMI) Fiabilidad At-most once (excepciones) Exactly-once mediante el servicio de notificación o CORBA messaging CORBA, COM y RMI también tienen un servicio de transaccionalidad Escalabilidad Algo de balanceo de carga en CORBA, pero no replicación Principal limitación con respecto a MOM y TM Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 21 CORBA Java :ORB Network COBOL C++ :Component :Server op i ( ):SynchRequest :Client Ada attached IDL specification op 1 op n :Object one-way, deffered op i (mode, ):AsynchRequest :Client Python C :Server Naming service Lisp Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 22 11 Arquitecturas orientadas a objetos Ventajas Estandarización de interfaces de componentes Desventajas Componentes fuertemente acoplados ( Tight coupling ) Los componentes deben estar sincronizados Emisor y receptor de peticiones activos Conocimiento detallado de las interfaces de componentes Conocimiento de la identidad de los componentes Conclusión: adecuados solamente para sistemas rígidos y estáticos Interacciones one-to-many no soportadas Interacciones asíncronas mediante polling Difícil de calibrar: recursos malgastados vs. demora excesiva Sólo soportan interacciones atómicas Estado de conversaciones almacenado en los componentes Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 23 CORBA Dynamic Invocation Interface Douglas C. Schmidt and Steve Vinoski, Object Interconnections: Dynamic CORBA, Part 1: The Dynamic Invocation Interface, C/C++ Users Journal, July, // IDL module Stock { exception Invalid_Stock {}; interface Quoter { long get_quote (in string stock_name) raises (Invalid_Stock); }; }; STATIC INVOCATION // C++ CORBA::Object_var obj = //...obtain object reference... Quoter_var s_obj = Stock::Quoter::_narrow (obj); retval = s_obj- get_quote ( IONA ); Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 24 12 CORBA Dynamic Invocation Interface DYNAMIC INVOCATION CORBA::Object_var obj = //...obtain object reference... CORBA::Request_var req = obj- _request ( get_quote ); req- add_in_arg () = IONA ; req- set_return_type (CORBA::_tc_long); req- exceptions ()- add (Stock::_tc_Invalid_Stock); req- invoke (); CORBA::Environment_ptr env = req- env (); if (!CORBA::is_nil (env) && env- exception () == 0) { CORBA::Long retval; req- return_value () = retval; }... req- send_deferred ();... req- get_response (); //blocking... if (req- poll_response ()) // non-blocking req- get_response ();.. Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 25 Content Introducción Orientación a objetos Cliente/Servidor Peer-to-peer Orientadas a servicios Orientadas a eventos Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 26 13 Cliente/Servidor Modelo computacional Una serie de componentes (servidores) proporcionan servicios y aguardan a que otros componentes (clientes) los soliciten RPCs a nivel macro Aplicaciones Servidores de nombres (name resolver, name server); servidores de correo (mail server, mail clients), servidores web (web server; web browsers; HTTP: conector request/reply); game servers; e-commerce; Componentes/Conectores Componentes: clientes y servidores Los servidores hacen pública una colección de operaciones/servicios Puede haber varios servidores (clusters) y distintas topologías Conectores: petición de servicios Roles: request (clientes), reply (servidores) Interacción punto-punto; asimétrica: iniciada por los clientes (procesos trigger vs. procesos reactivos); el cliente debe conocer la identidad del servidor Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 27 Cliente/Servidor Refinamientos Client-stateless-Server El estado de la interacción global entre cliente y servidores se almacena en el cliente Escalabilidad, fiabilidad, Sesiones remotas Los conectores son sesiones en las que tienen lugar distintas peticiones El servidor almacena el estado de la sesión (ej. telnet) Cache client/server Mediadores entre clientes y servidores (ej. NFS) Eficiencia, rendimiento, N-tier client/server ej. Presentación/Lógica de negocio/almacenamiento de datos (J2EE s EJB) Separación de aspectos funcional (evolvability, reusabilidad, ) Tiers desplegadas en distintas unidades de procesamiento (escalabilidad, rendimiento, ) Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 28 14 Servidores de aplicaciones Browser Client Tier Web Server (Servlets, JSPs, ASPs) Container (J2EE EJBs,.NET Comp., CORBA Objects) BBDD, ERPs http Web Tier RMI,.NET Remoting, IIOP Business Component Tier JDBC, SQL Enterprise Information System Tier Activación de comp. Transacciones Persistencia Seguridad Arquitectura N-Tier para aplicaciones Web [Gorton, 06] Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 29 Content Introducción Orientación a objetos Cliente/Servidor Peer-to-peer Orientadas a servicios Orientadas a eventos Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 30 15 Peer-to-peer Modelo computacional La computación se lleva a cabo mediante el intercambio de servicios entre una red de peers (que actúan como cliente y servidores al mismo tiempo) Aplicaciones Intercambio bidireccional de información (Gnutella, freenet, edonkey, BitTorrent, etc.) Transmisión de audio/video en tiempo real (VOIP, etc.) Componentes/Conectores Componentes: Peers Especifican qué servicios ofrece y qué servicios requiere Conectores: definidos por los protocolos correspondientes Segmented download: múltiples peers participan en una interacción de petición de información Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 31 Peer-to-peer file sharing Modelos Puros vs. Modelos híbridos Modelos mixtos: algunos servicios se ofrecen en modo cliente/servidor (ej. búsquedas) SMTP Red peer-to-peer de Mail-Transfer Agents Conexiones cliente/servidor entre Mail-User Agents y Mail Servers edonkey network Servers: servicio de directorio Peer-to-peer: intercambio de información Modelos puros: no existe el concepto de servidor Gnutella (flooding) Freenet (heuristic key-based routing) Kad network (kademlia protocol) BitTorrent (when using DHT for decentralized tracking) Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 32 16 BitTorrent :BitTorrent network :Azureus :Swarm :BitTornado :Peer :Peer :Azureus :Peer :Peer :Tracker :Swarm :Seeder :Peer :BitTornado :Azureus :Peer :Peer :Tracker :Swarm :Seeder :Peer :Opera :µtorrent :Seeder :Peer :Leech :Peer :Swarm {torrent=...} :Leech :Peer :Peer :BitTorrent :µtorrent :Peer :Peer :... Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 33 Peer-to-peer Ventajas Tolerancia a fallos Información y servicios distribuidos/replicados (vs. único punto de fallo en cliente/servidor) Escalabilidad Adición de nuevos nodos a la red (vs. saturación de servidores) Eficiencia Load-balancing, uso más eficiente de recursos (computacionales, almacenamiento, ancho de banda) Inconvenientes Mantenibilidad Diseminación de datos (vs. gestión de datos centralizada) Seguridad Privacidad, integridad de datos Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 34 17 Content Introducción Orientación a objetos Cliente/Servidor Peer-to-peer Orientadas a servicios Orientadas a eventos Tema 2. Estilos de la vista de componentes y conectores/arq. Soft./09-10/Ing. Inf./URJC 35 Arquitecturas orientadas a servicios SOA (Service Oriented Architectures) Conceptualizan la estructura (C&C) de una aplicación en términos de servicios programables débilmente acoplados que encapsulan funcionalidad proporcionada por aplicaciones ya existentes o de nuevo desarrollo, con la intención de que sean utilizados por usuarios finales u otros servicios software Motivación: interoperabilidad/integrabilidad, reusabilidad/extensibilidad/ escalabilidad Modelo de referencia SOA (OASIS) Vs. desarrollo orientado a componente
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks
SAVE OUR EARTH

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!

x