Desarrollo de aplicaciones para la sociedad de la información

Presentación del tema: "Desarrollo de aplicaciones para la sociedad de la información"— Transcripción de la presentación:

1 Desarrollo de aplicaciones para la sociedad de la información
Máster Universitario Oficial en Sistemas Telemáticos e Informáticos César Cáceres, Despacho 206 – Departamental II (Móstoles) Juan Manuel Serrano, Vivero de empresas de Móstoles (Despacho 9) The information society Applications for the information society Application domains/social contexts Functional aspects: social interactions, presentation issues (interface), decision-making logic Tecnologies for social application development Programming languages, middleware infrastructures, architectural styles, … General purpose technology: Java, C++, CORBA, RMI, AMQP, SOC, … Domain-specific tecnologies for particular social application domains: DSLs, game servers, social network engines, bpms, … Domain-specific technologies for any kind of social application domain: SPEECH middleware and architectural style, … Objectives: raise awareness of social applications and its application domains Introduce a general purpose middleware and architectural style for social applications Knowing particular technologies for particular application domains and its limitations with respect to the reference architecture … Course outline: Intro Reference architecture Social application domains (business, social networks, …) Evaluation -two assignments on the reference architecture and particular technologies Planning Related courses * middleware, … -

2 Objetivos de la sesión ¿Qué es la sociedad de la información y a qué tipo de aplicaciones nos referimos? ¿Cuáles son los objetivos, el programa y la política de evaluación de la asignatura? ¿Cómo se relaciona la asignatura con el resto de asignaturas del máster? MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1

3 ¿Qué es la sociedad de la información?
Sociedades agrarias, sociedad industrial ... sociedad de la información Relevancia de los procesos de generación, distribución y consumo de la información en la economía, cultura, política, ... Otras caracterizaciones: sociedad del conocimiento, sociedad post-industrial, ... Expresión que pretende caracterizar la sociedad contemporánea, y distinguirla de sociedades de épocas anteriores, en particular, de la sociedad industrial. También se puede hacer referencia a otras sociedades como las sociedades del neolítico (de cazadores/recolectores). ¿MÁS EJEMPLOS? **** Concretamente, la expresión hace referencia a la relevancia que tienen los procesos de generación, distribución y consumo de la información dentro del conjunto de la actividad cultural, económica, política, etc., de la sociedad. Impactos económicos: un gran porcentaje de los bienes de consumo de nuestra sociedad no son bienes materiales, sino bienes “de información”. El software es un buen ejemplo. Replicar el software no es costoso (lo costoso es diseñarlo, pero esto también pasa en el resto de productos). Impactos culturales: la forma de consumir películas, música y libros está cambiando Impactos políticos: **** MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1

4 ¿Qué es la sociedad de la información?
Motor de la sociedad de la información: tecnologías de la información y de las comunicaciones (TIC) Ordenadores PDAs, Mainframes, PCs,... Redes Telefonía (SMS, 3G, UMTS, ...) Internet (Usenet, , IRC, WWW, ...) WWW (Blogs, Wikis, redes sociales, ...) Por supuesto, en épocas anteriores también existían los bienes de información (la literatura?), y las comunicaciones no tenían lugar necesariamente en presencia del interlocutor (el telégrafo, el teléfono, ...). Lo que caracteriza a nuestra época es la generalización, universalidad y la ubicuidad de los procesos de gestión de la información en todas las facetas del ser humano. La causa de este universalización o predominancia de estos procesos, reside fundamentalmente en el desarrollo de las tecnologías de la información y las comunicaciones (TIC). La capacidad y la oportunidad de gestionar la información se ha visto incrementada a una escala antes nunca vista con el desarrollo y la aparición del PC, la telefonía celular, internet, WWW, etc. Desde una perspectiva tecnológica, se pueden enfatizar los cambios en la forma de comunicarse y compartir información: * Telefonía móvil: SMS Internet: , newsgroup, IRC, ... Web (1.0): HTML Web 2.0: Wikis, Blogs, Redes sociales, Social Media Sites (Youtube, Flickr, ...). 1983- TCP/IP 1980- Newsgroups (USENET) 1981- IBM PC 1984- Macinstosh 1988- IRC 1989- HTML 1995- Amazon 1999- Napster 2003- MySpace, LinkedIn -Wikis, -Blogs -Bookmarks 2004- Facebook Internet ERAs: 1- Shell accounts 2- SLIP/PPP dialups 3- Broadband 4- Mobile networking 5- Ubiquitous computing Estos cambios tienen un fuerte impacto en la sociedad. Por ejemplo, Internet, y en particular, la Web 2.0, ha dado la posibilidad de que cada vez más gente pueda hacer pública su opinión, y de esta forma democratizar el espacio público (modelo one/few-to-many vs. many-to-many). Llegar a una especie de online democracy. Se habla de Digital Divide, no sólo entre países con mayor o menor índices de desarrollo tecnológico, sino entre los distintos sectores culturales dentro de un mismo país (clase baja/clase media, primaria/universitarios, ...). En general, se puede hablar de digital divide cuando existe un gap socioeconómico entre distintos sectores de la población, por ejemplo, entre los que tienen y no tienen ordenador+adsl en casa. Pero también entre los que producen contenidos digitales y los que no (en el contexto de la web 2.0). MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1

5 Aplicaciones para la sociedad de la información
Aplicaciones diseñadas para dar soporte a los procesos de generación, difusión y consumo de información en un contexto social determinado Utilizaremos la expresión Aplicación Social para enfatizar la relevancia de: los aspectos pragmáticos vs. semánticos la interacción social vs. información SOCIAL SOFTWARE “Software systems that allow users to interact and share data ... The terms Web used to describe this style of software. ” [Wikipedia] SISTEMAS DE INFORMACIÓN “Technology-enabled business development” [ACM Curriculum Guidelines] Cuando hablamos de aplicaciones para la sociedad de la información: No nos referimos, por ejemplo, a las aplicaciones para la gestión de redes de telecomunicación (móviles, wireless, …). Este tipo de software, evidentemente, tiene gran relevancia para el desarrollo de la sociedad de la información, pero lo mismo puede decirse de cualquier otro tipo de software (indirectamente, todo software se desarrolla con un fin social) Nos referimos, en términos generales, a aquellas aplicaciones diseñadas con el propósito explícito de dar un soporte directo a los procesos de generación, difusión y acceso a la información desarrollados en un contexto social determinado. Los sistemas de información son un tipo de aplicaciones que encajan dentro de esta categoría. Y, de hecho, podríamos estar tentados a considerar que los sistemas de información cubren todos los posibles casos. Sin embargo, los sistemas de información aluden por lo general a un tipo de aplicaciones comúnmente asociada a un contexto social concreto: el mundo de la gestión empresarial, los procesos administrativos, etc. **** Definición de Sistema de información, plan de estudios de la ACM Y nosotros queremos hacer referencia a contextos sociales arbitrarios. Es decir, no consideraremos únicamente aplicaciones destinadas a gestionar procesos de negocio, sino que tendremos en cuenta aplicaciones dirigidas a cualquier tipo de contexto social: los procesos educativos, políticos, salud, lúdicos (juegos), redes sociales, etc. Algo parecido ocurre con la expresión “aplicación social”, asociada a las aplicaciones típicas de la Web 2.0, como Blogs, Social networks, Wikis, etc. En general todo lo asociado a Social Software. **** Def. Social software Nosotros preferiremos la expresión “aplicación social” porque: pensamos que los aspectos relativos a la “interacción social” son más relevantes para el desarrollo de este tipo de aplicaciones que los aspectos “informacionales”. De la misma manera que los fenómenos pragmáticos son más relevantes que los semánticos, etc. Hacer énfasis en la palabra “social”, y, por tanto, en los aspectos interactivos, dinámicos, pragmáticos, de las aplicaciones. Frente a las connotaciones estáticas y semánticas de la palabra información. Lo importante es programar la interacción social, el énfasis debe estar en los procesos. La pragmática tiene prioridad sobre la semántica, al menos en el contexto de la ingeniería del software (y desde algún punto de vista filosófico también). También porque quizás debido a cómo se implementa la materia de sistemas de información en los planes de estudios españoles, estos están demasiado ligados a las bases de datos. Y esto es un error, los datos no son información. Sólo tenemos información cuando los datos se generan e interpretan en un contexto social determinado. Son los procesos de negocio ( las interacciones), los elementos más importantes en el modelado de sistemas de información. Y así se reconoce en los currículum de la ACM, y en la práctica real. El objetivo de una aplicación social es dar soporte a los procesos de gestión de la información que tienen lugar en un contexto social concreto. De manera equivalente, y enfatizando los aspectos interactivos, podemos decir que el objetivo básico de una aplicación social consiste en programar las interacciones entre los distintos actores que participan en un contexto social. Y programar las interacciones consiste en programar la estructura de las interacciones sociales y las reglas que gobiernan dichas interacciones. MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1

6 Dominios de aplicaciones sociales
Contextos sociales Aplicaciones sociales Business process Management Systems Empresa Redes sociales Social networking Tools Juegos Game servers Podemos considerar distintos tipos de aplicaciones sociales en función de los distintos tipos de contextos sociales en los que participamos en nuestro día a día. Por ejemplo, podemos considerar todas las interacciones que tienen lugar en el contexto de la empresa, en torno a los distintos procesos de negocio: facturación, logística, ventas, etc. Las herramientas de gestión de procesos de negocio son, por tanto, un tipo de aplicación social. O las interacciones relacionadas con el mantenimiento y reproducción de nuestras redes sociales, es decir, las interacciones que mantenemos con nuestros amigos, familiares, entorno profesional, etc. Hablamos aquí de todo lo relativo a las redes de contactos. Y dar soporte a la gestión de estos contactos y facilitar su reproducción es lo que hacen las herramientas de redes sociales. …. Economía E-commerce Salud E-Health Política E-democracy ….. ….. MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1

7 Dominios de aplicaciones sociales
Redes sociales (LinkedIn, MySpace, Facebook, last.fm, Google+...) Juegos (Casinos, Portales online, MMORPG, ...) Economía (Empresas, Agencia Tributaria, ...) Organismos legales y de administración de justicia (Congreso, Senado, Juzgado, Cuerpos de seguridad, ...) Mercado de trabajo (Seguridad Social, ETTs, ...) Redes de transporte (movilidad) (Metro, EMT, ...) Educación y cultura (Universidades, Institutos, Colegios, Academias, Bibliotecas, ... ) Deporte (Federaciones, clubes, polideportivos, competiciones, ...) Espectáculos artísticos (teatro, cine, música, etc.) (Conciertos, exposiciones, representaciones, ...) Otros (Organismos de estandarización (W3C, OMG, JCP, ...), Convocatorias de proyectos, ONGs, Trabajos de fin de máster, Proyectos de desarrollo de software,...) MMORPG: Massively multiplayer online role-playing game MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1

8 ¿Qué se persigue con una aplicación social?
Dar soporte al proceso social Facilitar las interacciones entre los participantes del proceso Mejorar su rendimiento Mejorar la eficiencia (uso de recursos) Mejorar la escalabilidad Mejorar el coste, ... etc. MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1

9 Aspectos funcionales en todo proceso social
Las actividades de toma de decisiones de los usuarios que deben ser automatizadas (total o parcialmente) Las estructura y las reglas que gobiernan las interacciones entre los usuarios La presentación de información y los mecanismos de actuación que la aplicación pone a disposición del usuario (interfaz) MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1

10 Asociaciones deportivas
10 MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1

11 Normas sociales D. SINGLES ENTRY AND WITHDRAWAL 1. Entry
…. A player may apply for entry into one but not more than six Futures Tournaments for a specific tournament week, in which case he must indicate a priority. … I. DRAWS The Singles Main Draw shall consist of 32 players. The Singles Qualifying Draw shall be a minimum of a 32 Draw and a maximum of a 64 Draw ... MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1 11

12 Tecnologías para el desarrollo de aplicaciones sociales
Las aplicaciones sociales son aplicaciones distribuidas Los usuarios de la aplicación se encuentran representados y acceden a la aplicación a través de componentes software que se encuentran conectados a una infraestructura de middleware que gestiona las interacciones entre ellos Componentes software Varían en complejidad: simples interfaces de usuario o componentes inteligentes que reemplazan al usuario (al menos en determinadas funciones) Middleware Infraestructura que gestiona las interacciones entre componentes software distribuidos Estilos arquitectónicos Las distintas tecnologías de middleware pueden clasificarse en función de los mecanismos de interacción que ponen a disposición de los componentes software ¿Cuál es la arquitectura hw y sw básica de una aplicación social y qué requisitos no funcionales debe satisfacer? Sobre la misma representación, mostrar la tecnología hardware (PDAs, PCs, …, Servidores, Redes, etc.) y software (Android, navegadores web, … , middleware) para desarrollar una aplicación social. Además de los requisitos de autonomía, heterogeneidad, escalabilidad (sistemas abiertos), están los típicos de un sistema distribuido: tolerancia a fallos, etc. 12 MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1

13 Tecnologías para el desarrollo de aplicaciones sociales
Las AS son sistemas abiertos Heterogeneidad de componentes Hardware (smartPhones, PCs, …) Software Windows, Mac, Linux, .. Navegadores (Firefox, iExplorer,…), interfaces ad-hoc, … Android, iPhone Sistemas dinámicos La población de componentes varía con frecuencia Componentes autónomos Cierto tipo de componentes tienen control absoluto sobre su estado interno Una aplicación social es un sistema distribuido, en el que los componentes, por lo general, serán interfaces de usuario que representan a los usuarios humanos. Se trata también de un sistema distribuido muy dinámico, en el que la población de componentes puede variar a lo largo del tiempo. Heterogéneo, dado que los componentes pueden estar implementados en base a distintas tecnologías. Y los componentes tienen un alto grado de autonomía (en el sentido de ingeniería del software). En general este tipo de sistemas distribuidos se les denomina sistemas abiertos. 13 MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1

14 Tecnologías para el desarrollo de aplicaciones sociales
¿Cómo encajan los distintos requisitos funcionales con el hecho de que las aplicaciones sociales sean sistemas distribuidos? Componentes Toma de decisiones y presentación Middleware Interacciones Los lenguajes de programación utilizados se pueden clasificar también en función de los distintos aspectos funcionales Lenguajes de programación de componentes Lenguajes de presentación ¡Lenguajes de programación de interacciones! 14 MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1

15 Aplicaciones sociales
:Middleware :Component :Component :Component :Component :Component 15 MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1

16 Clasificación de tecnologías
Software Lenguajes de modelado: UML Lenguajes de program.: C++, Java, ... JavaScript, ... Middleware: CORBA, AMQP, ... Aplicaciones sociales Social Software APIs: OpenSocial, Facebook Connect, ... Middleware: Social networking engines, ... Lenguajes de modelado: Islander, MOISE, ... Lenguajes de programación: Speech, ... Middleware: AMELI, S-MOISE+, ... Business apps AMQP: Advanced Message Queuing Protocol DSL: Domain Specific Language The MOISE framework includes an organisational modelling language (OML) that explicitly decomposes the specification of organisation into structural, functional, and normative dimentions. AMELI: An agent-based middleware for electronic institutions. The combination of ISLANDER and AMELI provides full support for the design and development of electronic institutions. (WEBI 2) S-Moise + : A Middleware for developing Organised Multi-Agent Systems. This software ensures that all agents will follow the organisation without requiring that they are developed in a specific language or architecture. DSLs: worlflow/rule/doc languages Middleware: workflow/rules engines: ... ………. MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1

17 Tecnologías genéricas
Lenguajes e infraestructuras de middleware de propósito general, no particularizadas ni adaptadas al dominio concreto de la aplicación a desarrollar Lenguajes de programación genéricos Java, PHP, Python, … Middleware Orientados a objetos: Java RMI, CORBA Orientado a servicios: Web Services Orientado a mensajes: AMQP, JMS, … MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1

18 Middleware ¿Qué tecnología de middleware es más apropiada para el desarrollo de aplicaciones sociales? Podemos comparar los distintos tipos de middleware en base al paradigma de interacción (o estilo arquitectónico) soportado, gestión del ciclo de vida de los componentes, etc. Middlewares ¿Qué tipo de middleware nos hace falta? La tarea del middleware es mediar las interacciones entre los componentes del sistema. En particular, un middleware se encarga también de otras funciones: transparencia de acceso, etc. (funciones clásicas del middleware). Y podemos distinguir entre los distintos tipos de middleware en función del paradigma de interacción que soporta: orientados a objetos, mensajería, web, etc. A nosotros no nos viene bien ninguno de ellos por varias razones: Algunos de estos middlewares no respetan la autonomía de los componentes. Por ejemplo, el ciclo de vida de los objetos que se comunican a través de CORBA es gestionado por el ORB. Nosotros tenemos que gestionar interacciones sociales. Los mecanismos de interacción que utilizan son de muy bajo nivel. Understandability muy mala. (relacionado con lo anterior) La programabilidad del middleware es muy limitada: la mayor parte de la lógica de la interacción tiene que ser programada en los componentes. Lo cual va en contra del principio de separación de aspectos. En este último punto subyace una falacia básica en el desarrollo de sistemas distribuidos: que la lógica de la aplicación, o la funcionalidad, reside en los componentes, no en los conectores, es decir en el middleware. Esto no es cierto: ejemplos concretos. Orientados a objetos (CORBA, Java RMI, …) Orientados a mensajes (AMQP, JMS, …) Orientados a la Web (REST-based WS, W3C WS…) Peer-to-peer (BitTorrent, e2dk, …) 18 MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1

19 Middleware :Component … :Interaction :Interaction :Middleware
:Host :Middleware :Host :Component :Interaction :Host :Host :Interaction attached 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) Los protocolos de red no suelen ser fiables con respecto a la transmisión de datos: por ejemplo, no se garantiza que los datos sean efectivamente recibidos, o que se reciban en el orden en el que se envían. La fiabilidad del mecanismo de comunicación entre en conflicto con su rendimiento (el número de datos que pueden ser transmitidos por unidad de tiempo), por lo que el mecanismo de comunicación tiene asociados distintos grados de fiabilidad (o calidades de servicio- QualityOfService- QoS): best effort (no se garantiza la ejecución del servicio- debido a fallos en el sistema, o a un time-out que vence por problemas de red o indisponibilidad del receptor), at-most-once (se garantiza que la petición se ejecuta como máximo una sóla vez -- pero no que se ejecute, en cuyo caso se notifica al solicitante), at-least-once (la petición se satisface, pero es posible que se ejecute más de una vez) y exactly-once (el nivel más alto, las solicitudes se ejecutan una vez y sólo una). Alternativamente, también se habla de calidades Best-Effort, Persistente y transaccional. Con respecto a las peticiones de grupo se han identificado diferentes grados de fiabilidad: k-reliability (como poco, k componentes reciben la comunicación), time-outs (después del time-out, no se intenta la comunicación), totally-ordered requests. Cuando se trata de peticiones múltiples (compuestas por más de una petición), las transacciones garantizan que múltiples solicitudes sean ejecutadas de forma atómica (atomic- o se ejecutan todas o no se ejecutan), consistente (consistency-preserving- cuando se ejecutan todas, su ejecución es consistente), aislada (isolated- de otras transacciones concurrentes) y duraderas (durable- sus efectos no pueden ser deshechos) . Los middleware también soportan la fiabilidad de un sistema distribuido mediante servicios de redundancia o replicación: si un componente no se encuentra disponible, el servicio podría ser llevado a cabo por una réplica suya alojada en otro host. El middleware debe garantizar que el estado de ambas réplicas se encuentra sincronizado. También el middleware puede proporcionar un mecanismo de persistencia en el estado de los componentes (o de los elementos de comunicación): el estado del componente se actualiza en disco ante la posibilidad de que el sistema falle y luego se pueda recuperar. También puede haber redundancia del middleware en sí mismo (mediante clusters transparentes a los componentes- si uno falla otra instancia del cluster puede ocupar su lugar). La escalabilidad hace referencia a la posibilidad de soportar una carga creciente en el sistema a la considerada inicialmente. En un sistema centralizado, cliente-servidor, la escalabilidad del sistema depende de la carga que puede asumir el servidor. En un sistema distribuido, el middleware puede favorecer la escalabilidad del sistema, sin necesidad de modificar la arquitectura y el diseño de los componentes del sistema (hasta cierto punto), mediante la distribución dinámica de los componentes en un conjunto variable de hosts por medio de mecanismos de balanceo de carga, replicación, etc. Para ello, es necesario que los middleware soporten diferentes mecanismos de transparencia en la provisión de servicios (estándar ISO/ODP-- open distributed processing): La transparencia de acceso (access transp.) consiste en que la forma en la que se solicita un servicio es invariable con respecto a la ubicación del componente (remoto o local). La transparencia de localización (location transp.) consiste en que los componentes no conocen la ubicación física de los otros componentes con los que interactúan. La transparencia de migración (migration transp.) consiste en que los componentes no son conscientes del balanceo de carga que lleva a cabo el middleware para compensar el desequilibrio entre los diferentes hosts. También puede haber balanceo de carga con respecto a los recursos del propio middleware. La transparencia de replicación (replication transp.) consiste en que los componentes no son conscientes de si la petición la satisface la copia maestra o una réplica suya en un host diferente. COMPONENTES Gestión del ciclo de vida (activación, …) Gestión de concurrencia (colas, hilos, …) Replicación/Persistencia/Migración (fiabilidad/Escalabilidad) Heterogeneidad (interoperabilidad) … MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1 19

20 opi(mode,…):AsynchRequest
Middleware CORBA Java :ORB Network COBOL :Component opi(…):SynchRequest :Object C++ :Object :Server :Client :Object one-way, deffered IDL specification Ada opi(mode,…):AsynchRequest op1…opn :Client Python attached :Object :Object Los protocolos de red no suelen ser fiables con respecto a la transmisión de datos: por ejemplo, no se garantiza que los datos sean efectivamente recibidos, o que se reciban en el orden en el que se envían. La fiabilidad del mecanismo de comunicación entre en conflicto con su rendimiento (el número de datos que pueden ser transmitidos por unidad de tiempo), por lo que el mecanismo de comunicación tiene asociados distintos grados de fiabilidad (o calidades de servicio- QualityOfService- QoS): best effort (no se garantiza la ejecución del servicio- debido a fallos en el sistema, o a un time-out que vence por problemas de red o indisponibilidad del receptor), at-most-once (se garantiza que la petición se ejecuta como máximo una sóla vez -- pero no que se ejecute, en cuyo caso se notifica al solicitante), at-least-once (la petición se satisface, pero es posible que se ejecute más de una vez) y exactly-once (el nivel más alto, las solicitudes se ejecutan una vez y sólo una). Alternativamente, también se habla de calidades Best-Effort, Persistente y transaccional. Con respecto a las peticiones de grupo se han identificado diferentes grados de fiabilidad: k-reliability (como poco, k componentes reciben la comunicación), time-outs (después del time-out, no se intenta la comunicación), totally-ordered requests. Cuando se trata de peticiones múltiples (compuestas por más de una petición), las transacciones garantizan que múltiples solicitudes sean ejecutadas de forma atómica (atomic- o se ejecutan todas o no se ejecutan), consistente (consistency-preserving- cuando se ejecutan todas, su ejecución es consistente), aislada (isolated- de otras transacciones concurrentes) y duraderas (durable- sus efectos no pueden ser deshechos) . Los middleware también soportan la fiabilidad de un sistema distribuido mediante servicios de redundancia o replicación: si un componente no se encuentra disponible, el servicio podría ser llevado a cabo por una réplica suya alojada en otro host. El middleware debe garantizar que el estado de ambas réplicas se encuentra sincronizado. También el middleware puede proporcionar un mecanismo de persistencia en el estado de los componentes (o de los elementos de comunicación): el estado del componente se actualiza en disco ante la posibilidad de que el sistema falle y luego se pueda recuperar. También puede haber redundancia del middleware en sí mismo (mediante clusters transparentes a los componentes- si uno falla otra instancia del cluster puede ocupar su lugar). La escalabilidad hace referencia a la posibilidad de soportar una carga creciente en el sistema a la considerada inicialmente. En un sistema centralizado, cliente-servidor, la escalabilidad del sistema depende de la carga que puede asumir el servidor. En un sistema distribuido, el middleware puede favorecer la escalabilidad del sistema, sin necesidad de modificar la arquitectura y el diseño de los componentes del sistema (hasta cierto punto), mediante la distribución dinámica de los componentes en un conjunto variable de hosts por medio de mecanismos de balanceo de carga, replicación, etc. Para ello, es necesario que los middleware soporten diferentes mecanismos de transparencia en la provisión de servicios (estándar ISO/ODP-- open distributed processing): La transparencia de acceso (access transp.) consiste en que la forma en la que se solicita un servicio es invariable con respecto a la ubicación del componente (remoto o local). La transparencia de localización (location transp.) consiste en que los componentes no conocen la ubicación física de los otros componentes con los que interactúan. La transparencia de migración (migration transp.) consiste en que los componentes no son conscientes del balanceo de carga que lleva a cabo el middleware para compensar el desequilibrio entre los diferentes hosts. También puede haber balanceo de carga con respecto a los recursos del propio middleware. La transparencia de replicación (replication transp.) consiste en que los componentes no son conscientes de si la petición la satisface la copia maestra o una réplica suya en un host diferente. C :Server … :Object :Object … :Object :Object Naming service Lisp MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1 20

21 Middleware orientado a mensajes
PUBLISH-SUBSCRIBE :MOM UNSUBSCRIBE PUBLISH :Component :Producer queue 1 SUBSCRIBE :Consumer NOTIFY ADVERTISE :Producer queue 2 :Consumer :Producer …. :Consumer NOTIFY Los protocolos de red no suelen ser fiables con respecto a la transmisión de datos: por ejemplo, no se garantiza que los datos sean efectivamente recibidos, o que se reciban en el orden en el que se envían. La fiabilidad del mecanismo de comunicación entre en conflicto con su rendimiento (el número de datos que pueden ser transmitidos por unidad de tiempo), por lo que el mecanismo de comunicación tiene asociados distintos grados de fiabilidad (o calidades de servicio- QualityOfService- QoS): best effort (no se garantiza la ejecución del servicio- debido a fallos en el sistema, o a un time-out que vence por problemas de red o indisponibilidad del receptor), at-most-once (se garantiza que la petición se ejecuta como máximo una sóla vez -- pero no que se ejecute, en cuyo caso se notifica al solicitante), at-least-once (la petición se satisface, pero es posible que se ejecute más de una vez) y exactly-once (el nivel más alto, las solicitudes se ejecutan una vez y sólo una). Alternativamente, también se habla de calidades Best-Effort, Persistente y transaccional. Con respecto a las peticiones de grupo se han identificado diferentes grados de fiabilidad: k-reliability (como poco, k componentes reciben la comunicación), time-outs (después del time-out, no se intenta la comunicación), totally-ordered requests. Cuando se trata de peticiones múltiples (compuestas por más de una petición), las transacciones garantizan que múltiples solicitudes sean ejecutadas de forma atómica (atomic- o se ejecutan todas o no se ejecutan), consistente (consistency-preserving- cuando se ejecutan todas, su ejecución es consistente), aislada (isolated- de otras transacciones concurrentes) y duraderas (durable- sus efectos no pueden ser deshechos) . Los middleware también soportan la fiabilidad de un sistema distribuido mediante servicios de redundancia o replicación: si un componente no se encuentra disponible, el servicio podría ser llevado a cabo por una réplica suya alojada en otro host. El middleware debe garantizar que el estado de ambas réplicas se encuentra sincronizado. También el middleware puede proporcionar un mecanismo de persistencia en el estado de los componentes (o de los elementos de comunicación): el estado del componente se actualiza en disco ante la posibilidad de que el sistema falle y luego se pueda recuperar. También puede haber redundancia del middleware en sí mismo (mediante clusters transparentes a los componentes- si uno falla otra instancia del cluster puede ocupar su lugar). La escalabilidad hace referencia a la posibilidad de soportar una carga creciente en el sistema a la considerada inicialmente. En un sistema centralizado, cliente-servidor, la escalabilidad del sistema depende de la carga que puede asumir el servidor. En un sistema distribuido, el middleware puede favorecer la escalabilidad del sistema, sin necesidad de modificar la arquitectura y el diseño de los componentes del sistema (hasta cierto punto), mediante la distribución dinámica de los componentes en un conjunto variable de hosts por medio de mecanismos de balanceo de carga, replicación, etc. Para ello, es necesario que los middleware soporten diferentes mecanismos de transparencia en la provisión de servicios (estándar ISO/ODP-- open distributed processing): La transparencia de acceso (access transp.) consiste en que la forma en la que se solicita un servicio es invariable con respecto a la ubicación del componente (remoto o local). La transparencia de localización (location transp.) consiste en que los componentes no conocen la ubicación física de los otros componentes con los que interactúan. La transparencia de migración (migration transp.) consiste en que los componentes no son conscientes del balanceo de carga que lleva a cabo el middleware para compensar el desequilibrio entre los diferentes hosts. También puede haber balanceo de carga con respecto a los recursos del propio middleware. La transparencia de replicación (replication transp.) consiste en que los componentes no son conscientes de si la petición la satisface la copia maestra o una réplica suya en un host diferente. PUBLISH SUBSCRIBE NOTIFY :Producer SUBSCRIBE … :Consumer queue n SUBSCRIBE :Producer :Consumer … NOTIFY MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1 21

22 Tecnologías específicas de dominio
Las tecnologías de propósito general tienen varios inconvenientes: Violan la autonomía de los componentes Conectores software de bajo nivel de abstracción Bajo nivel de programabilidad: aspectos de la interacción programados a través de componentes En desacuerdo con el principio de separación de aspectos entre interacción y computación ¿Qué tipo de middleware nos hace falta? La tarea del middleware es mediar las interacciones entre los componentes del sistema. En particular, un middleware se encarga también de otras funciones: transparencia de acceso, etc. (funciones clásicas del middleware). Y podemos distinguir entre los distintos tipos de middleware en función del paradigma de interacción que soporta: orientados a objetos, mensajería, web, etc. A nosotros no nos viene bien ninguno de ellos por varias razones: Algunos de estos middlewares no respetan la autonomía de los componentes. Por ejemplo, el ciclo de vida de los objetos que se comunican a través de CORBA es gestionado por el ORB. Nosotros tenemos que gestionar interacciones sociales. Los mecanismos de interacción que utilizan son de muy bajo nivel. Understandability muy mala. (relacionado con lo anterior) La programabilidad del middleware es muy limitada: la mayor parte de la lógica de la interacción tiene que ser programada en los componentes. Lo cual va en contra del principio de separación de aspectos. En este último punto subyace una falacia básica en el desarrollo de sistemas distribuidos: que la lógica de la aplicación, o la funcionalidad, reside en los componentes, no en los conectores, es decir en el middleware. Esto no es cierto: ejemplos concretos. 22 MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1

23 Tecnologías específicas de dominio
Tecnologías específicas para dominios concretos Lenguajes específicos de dominio (DSLs), APIs para lenguajes de propósito general, middleware para dominios concretos, etc. Redes sociales APIs: OpenSocial API, Facebook connect, … Motores (middleware): Elgg, Pinax, … Gestión de procesos de negocios DSLs: BPMN, BPEL, WS-CDL, … Motores (middleware): reglas, workflow, … Otros dominios: Content Management Systems (CMS) especializados en dominios concretos (e-learning, conference management, etc.), herramientas para subastas, etc. Tema 2 Tema 3 Tema 4 MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1

24 Sociedades computacionales
Una sociedad computacional (SC) es un sistema distribuido en el que los mecanismos de interacción proporcionados por el middleware tienen un carácter social Origen en el campo de los sistemas multiagente AMELI, INGENIAS toolkit, MadKit, S-Moise+, etc. Otras denominaciones: instituciones electrónicas, organizaciones virtuales, etc. Programar una SC requiere programar el middleware social y los componentes que participan en la sociedad Tecnología específica de dominio, pero al mismo tiempo genérica: cubre todo el espectro de aplicaciones sociales Se basan en distintos estilos arquitectónicos propios para las aplicaciones sociales Organizaciones, instituciones, grupos, equipos, actos de habla, conversaciones, etc. Protocolos basados en conceptos normativos permisos, obligaciones, compromisos, políticas, sanciones, etc. Middleware social definido acorde con los conectores característicos del estilo arquitectónico 24 MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1 24

25 El lenguaje Speech Un lenguaje para la programación de aplicaciones sociales en términos de sociedades computacionales Lenguaje específico de dominio Vs. Lenguaje de propósito general Un lenguaje para la programación de procesos sociales Lenguaje orientado a interacciones Lenguajes de programación de normativas en dominios de aplicación social arbitrarios Vs. Lenguaje para la programación de componentes Un lenguaje de programación Vs. Lenguaje de modelado Middleware social como máquina abstracta programable 25 MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1 25

26 Lenguaje de procesos sociales
El lenguaje Speech Lenguaje de procesos sociales ESPECIFICACIÓN Máquina abstracta (middleware social) Sistema de tipos (cómo programar el middleware) Sintaxis (visual, XML, texto) LIBRERÍA ESTÁNDAR (built-in) meta-aplicaciones Tipos de conectores reutilizables IMPLEMENTACIÓN Máquina virtual (distribuida) (VM) HERRAMIENTAS USUARIO VM sniffer VM debugger type editor event manager ... WEB SERVICES VM (REST, SOAP) Messaging (AMQP, JMS, …) 26 MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1 26

27 El lenguaje Speech Tema 6 Temas 5/6 ESPECIFICACIÓN Tema 5 MIDDLEWARE
SOCIAL Estructura Dinámica SISTEMA DE TIPOS Meta-tipos especialización SINTAXIS Notación UML Notación XML Notación RDF Notación BNF 27 MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1 27

28 Objetivos de la asignatura
Comprender la categoría de aplicación social, su relación con el desarrollo de la sociedad de la información y la necesidad de lenguajes orientados a la programación de procesos sociales Ser capaz de analizar el dominio de una aplicación social en base a un estilo arquitectónico orientado a la programación de procesos sociales Conocer las tecnologías para el desarrollo de aplicaciones sociales de algunos de los dominios más relevantes y ser capaz de evaluar críticamente dicha tecnología MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1

29 Temario BLOQUE I: Introducción Tema 1. Introducción
BLOQUE II: Dominios de aplicaciones sociales Tema 2. Redes sociales Tema 3. Gestión de procesos de negocio Tema 4. Aplicaciones sociales en otros dominios BLOQUE III: Estilo arquitectónico para el desarrollo de aplicaciones sociales Tema 5. Middleware social Tema 6. Lenguajes de procesos sociales MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1

30 Evaluación Test: 30% (Nota mínima 5 puntos)
Práctica 1: Descripción y evaluación de una tecnología para el desarrollo de aplicaciones sociales (35%) Nota mínima 5 puntos Memoria (30%) Presentación y debate en clase (5%) Práctica 2: Análisis de un dominio de aplicación (35%) MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1

31 Planificación (tentativa …)
Fecha Clases Prácticas Semana 1 (10/9) Tema 1: Introducción Semana 2 (17/9) Tema 2: Redes Sociales Semana 3 (24/9) Semana 4 (1/10) Tema 3: Procesos de negocio Semana 5 (8/10) Práctica 1 Semana 6 (15/10) Semana 7 (22/10) Tema 4: Otros dominios Semana 8 (29/10) Tema 5: Middleware social Semana 9 (5/11) Semana 10 (12/11) Tema 6: Lenguajes sociales Semana 11 (19/11) Semana 12 (26/11) Práctica 2 Semana 13 (3/12) Semana 14 (10/12) Semana 15… Test Entrega P1 (12/11) Entrega P2 (12/01) MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1

32 Relación con otras asignaturas del máster
Redes, Aplicaciones y Servicios de Internet (programación de dispositivos móviles) Middleware (orientados a objetos, servicios, p2p, grid, ...) Desarrollo de aplicaciones para la sociedad de la información Arquitecturas Orientadas a Servicios (Servicios Web, familias de productos) Redes Inalámbricas e Internet Infraestructura y Gestión de Redes Móviles e Internet Redes Ad-hoc Inalámbricas ... MOSTI/Desarrollo de aplicaciones para sociedad de la información/Tema 1