A user-centric approach for developing and deploying service front-ends in the future internet of services

Service-Oriented Architectures (SOAs) based on web services have attracted a great deal of interest and Internet Technology (IT) investment over the last few years, principally in the context of business-to-business integration within corporate intranets. However, they are now evolving and breaking through enterprise boundaries in a revolutionary attempt to make the approach pervasive. This is leading to what we call a user-centric SOA. A user-centric SOA is an SOA conceived as an internet of services made up of compositional resources empowering end users to collaboratively remix and ubiquitously exploit these resources. In this paper we explore the architectural basis, technologies, frameworks and tools considered necessary to tackle this novel vision of SOA. We also present the rationale behind Ez Web/FAST, an ongoing EU-funded project whose first outcomes could serve as a preliminary proof of concept

Greenpass Client Tools for Delegated Authorization in Wireless Networks

Dartmouth\u27s Greenpass project seeks to provide strong access control to a wireless network while simultaneously providing flexible guest access; to do so, it augments the Wi-Fi Alliance\u27s existing WPA standard, which offers sufficiently strong user authentication and access control, with authorization based on SPKI certificates. SPKI allows certain local users to delegate network access to guests by issuing certificates that state, in essence, he should get access because I said it\u27s okay. The Greenpass RADIUS server described in Kim\u27s thesis [55] performs an authorization check based on such statements so that guests can obtain network access without requiring a busy network administrator to set up new accounts in a centralized database. To our knowledge, Greenpass is the first working delegation-based solution to Wi-Fi access control. My thesis describes the Greenpass client tools, which allow a guest to introduce himself to a delegator and allow the delegator to issue a new SPKI certificate to the guest. The guest does not need custom client software to introduce himself or to connect to the Wi-Fi network. The guest and delegator communicate using a set of Web applications. The guest obtains a temporary key pair and X.509 certificate if needed, then sends his public key value to a Web server we provide. The delegator looks up her guest\u27s public key and runs a Java applet that lets her verify her guests\u27 identity using visual hashing and issue a new SPKI certificate to him. The guest\u27s new certificate chain is stored as an HTTP cookie to enable him to push it to an authorization server at a later time. I also describe how Greenpass can be extended to control access to a virtual private network (VPN) and suggest several interesting future research and development directions that could build on this work.My thesis describes the Greenpass client tools, which allow a guest to introduce himself to a delegator and allow the delegator to issue a new SPKI certificate to the guest. The guest does not need custom client software to introduce himself or to connect to the Wi-Fi network. The guest and delegator communicate using a set of Web applications. The guest obtains a temporary key pair and X.509 certificate if needed, then sends his public key value to a Web server we provide. The delegator looks up her guest\u27s public key and runs a Java applet that lets her verify her guests\u27 identity using visual hashing and issue a new SPKI certificate to him. The guest\u27s new certificate chain is stored as an HTTP cookie to enable him to push it to an authorization server at a later time. I also describe how Greenpass can be extended to control access to a virtual private network (VPN) and suggest several interesting future research and development directions that could build on this work

Enhancement of the usability of SOA services for novice users

Recently, the automation of service integration has provided a significant advantage in delivering services to novice users. This art of integrating various services is known as Service Composition and its main purpose is to simplify the development process for web applications and facilitates reuse of services. It is one of the paradigms that enables services to end-users (i.e.service provisioning) through the outsourcing of web contents and it requires users to share and reuse services in more collaborative ways. Most service composers are effective at enabling integration of web contents, but they do not enable universal access across different groups of users. This is because, the currently existing content aggregators require complex interactions in order to create web applications (e.g., Web Service Business Process Execution Language (WS-BPEL)) as a result not all users are able to use such web tools. This trend demands changes in the web tools that end-users use to gain and share information, hence this research uses Mashups as a service composition technique to allow novice users to integrate publicly available Service Oriented Architecture (SOA) services, where there is a minimal active web application development. Mashups being the platforms that integrate disparate web Application Programming Interfaces (APIs) to create user defined web applications; presents a great opportunity for service provisioning. However, their usability for novice users remains invalidated since Mashup tools are not easy to use they require basic programming skills which makes the process of designing and creating Mashups difficult. This is because Mashup tools access heterogeneous web contents using public web APIs and the process of integrating them become complex since web APIs are tailored by different vendors. Moreover, the design of Mashup editors is unnecessary complex; as a result, users do not know where to start when creating Mashups. This research address the gap between Mashup tools and usability by the designing and implementing a semantically enriched Mashup tool to discover, annotate and compose APIs to improve the utilization of SOA services by novice users. The researchers conducted an analysis of the already existing Mashup tools to identify challenges and weaknesses experienced by novice Mashup users. The findings from the requirement analysis formulated the system usability requirements that informed the design and implementation of the proposed Mashup tool. The proposed architecture addressed three layers: composition, annotation and discovery. The researchers developed a simple Mashup tool referred to as soa-Services Provisioner (SerPro) that allowed novice users to create web application flexibly. Its usability and effectiveness was validated. The proposed Mashup tool enhanced the usability of SOA services, since data analysis and results showed that it was usable to novice users by scoring a System Usability Scale (SUS) score of 72.08. Furthermore, this research discusses the research limitations and future work for further improvements

An approach for distributed rostering by means of Web service technologies

La planificación automática de turnos de trabajo (rostering de aquí en adelante) es un proceso fundamental para la mayoría de empresas. Este proceso les permite gestionar sus recursos de forma eficiente. La mayoría de soluciones de planificación automática trabajan en escenarios centralizados. Este proyecto tiene como meta dar un nuevo enfoque al proceso de planificación automática transformando el entorno centralizado en uno distribuido. La tecnología escogida para esta transformación son los servicios Web. Los servicios Web se han posicionado como una de las tecnologías más importantes y utilizadas, sin embargo la combinación de los procesos de planificación automática con servicios Web no ha sido investigada y estudiada en profundidad. Este nuevo enfoque pretende crear soluciones más ligeras y flexibles para empresas de forma que no tengan que preocuparse de tediosas instalaciones y configuraciones El enfoque distribuido puede proveer numerosos beneficios a ambas partes; permitiría centrar este área tecnológica en un entorno web 2.0. Las compañías de planificación automática se actualizarían convirtiéndose en empresas con gran capacidad de interacción con el resto de elementos de la web 2.0. Al mismo tiempo, la empresa que consume los servicios de rostering no tiene que preocuparse por el mantenimiento y actualizaciones. Los calendarios de turnos de trabajo pueden ser obtenidos en cualquier lugar y en cualquier momento. Esto mejora el valor de la empresa y las relaciones con los empleados. Para el desarrollo del proyecto se han creado diferentes aplicaciones. Estas aplicaciones han sido configuradas de distintas formas para abarcar distintas posibilidades de desarrollo y poder así obtener una visión más amplia de las capacidades y posibilidades del sistema distribuido. Las configuraciones están centradas en el tipo de servicio Web usado (SOAP, REST) y en la seguridad y sus diferentes posibilidades. El proyecto es una prueba de concepto de como este nuevo enfoque funcionaría, resaltando los puntos fuertes y deficiencias de éste; de la misma manera pretende sentar una base para futuros proyectos en este área. El proyecto ha conseguido cumplir con los objetivos propuestos, mostrando los puntos fuertes y débiles del enfoque. De forma sorprendente y contraria a las expectativas los problemas aparecen al obtener los datos necesarios de las diferentes empresas para crear el calendario. En principio, se esperaba que el cuello de botella del sistema se encontrase en el proceso de rostering, ya que normalmente es un proceso costoso y pesado. Los resultados del proyecto muestran como el cuello de botella está localizado cuando se intenta obtener la información de empresas externas. Este problema resalta la característica principal de este nuevo enfoque: es necesario un sistema personalizado para cada empresa que quiera consumir los servicios de rostering. Esto significa que a pesar de tener un sistema global funcionando con servicios Web, no es válido para todas las empresas que quieran utilizarlo y consecuentemente hay que adaptarlo a cada una de ellas. La colaboración entre empresas se vuelve esencial en este nuevo enfoque. Esto complica la idea inicial y cambia los objetivos de las empresas de rostering que necesitan una profunda transformación de sus sistemas y su funcionamiento

Usage Analysis & Demonstrators - Version 2.0

This second version of the "Usage Analysis and Demonstrators " document mainly presents four case studies done during the second part of the SCOrWare project: ● (Task 3.1) Component and service-oriented architecture in the Scientific Software field (improvements of works done during the first year) ● (Task 3.2) SCA as a SOA design methodology in the domain of CDE (Collaborative Development Environment). Following the withdraw of one of the partners (eXo Platform, provider of an open-source portal solution) during the first year, some changes have been decided during the second part of the project and an alternative demonstrator has been designed. ● (Task 3.3) How SCA contributes to reusing and enriching software components. Following the first year project's review, this scenario has been reinforced, and is the major demonstrator for the SCOrWare platform in the field of enterprise business applications. ● (Task 3.5) Using the SCOrWare platform and a component-oriented architecture in the context of a network monitoring system. A new partner (Thales Communications, in collaboration with Open Wide and EBM Websourcing) has joined the SCOrWare consortium during the second part of the project, following the withdraw of Amadeus

Variability in remote portlets

130 p.Contexto Los portales corporativos (EIP, acrónimo en inglés de Enterprise Information Portal ) integran información, personas y procesos dentro de los límites de las organizaciones. Una característica importante de los portales corporativos es la descentralización en la creación de los contenidos y la gestión de los mismos, esto ayuda a mantener la información siempre actualizada. Otra característica distintiva es que pueden atender no sólo al personal interno de la organización a la que pertenecen, sino que también son capaces de proveer servicios a personal externo tales como clientes, proveedores y socios comerciales. Los portales permiten a las personas comunicarse y colaborar, proporcionan un punto de acceso uni cado al contenido dinámico generado por las aplicaciones de negocio, fraccionan los silos de contenido y proveen información personalizada de forma e caz. Los portales son también plataformas de integración. Además de ofrecer sus propios servicios, un portal es también un conducto para aplicaciones externas. Estas aplicaciones son técnicamente conocidas como portlets. Un portlet es un componente Web con interfaz de usuario que puede ser ofrecido a través de aplicaciones de terceros (por ejemplo, un portal). Los portlets tienen interfaz de usuario, es decir, en lugar de devolver datos en crudo, los portlets presentan vistas a los usuarios. Además, los portlets son aplicaciones complejas con contexto que pueden soportar ujos de trabajos compuestos de múltiples pasos. La especi cación de portlet [6, 7] ofrece interoperabilidad entre las plataformas de portales y los portlets, estos es, permite a los desarrolladores escribir el portlet una vez, y reutilizarlo en cualquier portal que soporte la especi cación. Esto proporciona la infraestructura para hacer posible un mercado de portlets de manera que, los portales puedan ofrecer portlets provistos por terceros. En 2006 se puso en marcha el proyecto Open Source Portlet Repository Project (un repositorio de portlets de código abierto) para fomentar el libre intercambio de portlets de código abierto. Este repositorio es "una biblioteca de aplicaciones listas para correr que se pueden descargar y desplegar directamente en su portal sin, en la mayoría de los casos, con gura- 1 ciones adicionales" [2]. Otras iniciativas similares son Portlet Swap (jboss.org) y Liferay Marketplace (liferay.com). La especi cación Web Services for Remote Portlets (WSRP) va un paso más allá y permite el renderizado remoto de los portlets. El mantra de esta especi - cación es desplegar una vez, proveer en cualquier lugar . Con WSRP, un portlet puede estar alojado ( producido ) en una infraestructura completamente aislada de los portales que ofrecen ( consumen ) el portlet a sus usuarios. Esto convierte a WSRP en una solución viable para construir portales federados, es decir, una red de portales interconectados donde los recursos alojados en un portal pueden estar disponibles en muchos. Desde esta perspectiva, los portlets juegan en la capa de presentación el mismo papel que los servicios web convencionales juegan en la capa de lógica de negocio: permiten crear sistemas complejos mediante la composición de sistemas reusables más sencillos. Las principales diferencias con los servicios web tradicionales consisten en qué se está reutilizando (que incluye la interfaz de usuario) y dónde se produce la integración (en la capa de presentación). 2 Problema General La variabilidad en software es la capacidad de un sistema o artefacto software para ser modi cado, personalizado o con gurado para su uso en un contexto particular. Pero, ¿cuánta variabilidad debemos considerar? ¿Quién es consciente de la variabilidad requerida? Para responder a estas preguntas vamos a introducir un ejemplo. Considere una compañía aérea (por ejemplo, IBERIA) que ofrece dos servicios en términos de portlets: searchFlight y bookFlight. De esta manera, las agencias de viajes (por ejemplo, HALCON) pueden hacer uso de estos portlets dentro de sus portales. Los usuarios (por ejemplo, los clientes de HALCON) acceden al portal de la agencia de viajes sin ser conscientes de que searchFlight está siendo ofrecido por un tercero (es decir, IBERIA). Por lo tanto, los portlets son explícitamente desarrollados para ser utilizados en múltiples portales, ya sea desplegados localmente o provistos de forma remota. El punto importante a destacar es que los portlets pueden ser reutilizados por diversos contextos y audiencias. Por ejemplo, IBERIA ofrece sus servicios no sólo a HALCON, sino también a otras agencias de viajes (por ejemplo, EROSKI). Esto signi ca que searchFlight también debe atender a las necesidades de integración de EROSKI. Por otro lado, incluso los clientes de un portal dado pueden tener diferentes necesidades. Por ejemplo, el usuario Oscar es muy aprensivo a las condiciones climáticas por lo que siempre consulta el pronóstico del tiempo antes de jar la fecha de un viaje. Esto sólo se aplica a Oscar, y no es contemplado por el portlet ightBooking. Por lo tanto, el Sr. Oscar se ve obligado a moverse fuera del ámbito del portal para satisfacer esta necesidad de datos (por ejemplo, a través de un widget weatherForecast ), y es su responsabilidad pasar los datos necesarios para la consulta del portal al widget. El ejemplo anterior sirve para ilustrar los diferentes contextos en los que la 2 variabilidad puede ser jada y decidida. En concreto, existen tres "reinos de decisión": el proveedor del portlet (por ejemplo, IBERIA). En este caso, el proveedor realiza un análisis profundo del dominio para satisfacer las variaciones del portlet requeridas por todos los usuarios y escenarios donde su portlet puede ser utilizado. el consumidor del portlet (por ejemplo, HALCON). Aquí, el portal del consumidor realiza un análisis de su base de consumidores, y provee los medios al propietario del portal para con gurar el portlet adecuadamente. el usuario nal (por ejemplo, el Sr. Oscar). Ningún diseño puede proporcionar información para cada situación, y ningún diseñador puede incluir información personalizada para cada usuario. Esto es cierto para cualquier aplicación web, y los portlets no son una excepción. Merece la pena mencionar, que estos reinos de decisión no son ortogonales sino complementarios. Todos, el proveedor del portlet, el consumidor del portlet, e incluso, los usuarios nales, deben colaborar para obtener una mejor experiencia en la web. Las secciones siguientes profundizan en cada uno de estos escenarios. 3 Escenario 1: Variabilidad basada en el Provee- dor Este escenario pone la carga de la variabilidad sobre los hombros del proveedor. El proveedor debe realizar un análisis del dominio con el n de comprender los diferentes entornos en los que sus portlets van a ser desplegados. Esto lleva a la noción de Consumer Pro le (o per l del consumidor). El Consumer Pro le incluye no sólo detalles sobre la plataforma del consumidor (por ejemplo, JBoss GateIn, Liferay, eXo Platform), sino también requisitos funcionales planteados por el propietario portal que necesitan ser atendidos por el proveedor del portlet. Mientras que el per l de usuario caracteriza al usuario nal (por ejemplo, edad, nombre, etc.), el Consumer Pro le recoge la idiosincrasia de la organización a través de la cual se está ofreciendo el portlet (por ejemplo, el propietario del portal) en cuanto a la funcionalidad del portlet se re ere. El per l de usuario puede ser dinámico y, por lo tanto, requiere que el portlet pueda ser personalizado en tiempo de ejecución. Por el contrario, el Consumer Pro le se conoce en tiempo de registro, y no siempre es apropiado o posible considerarlo en tiempo de ejecuci ón. En este caso, es mejor personalizar el código en tiempo de desarrollo y producir un portlet especí co para la organización que incluya funcionalidad personalizada. Para este n, se propone el uso de líneas de producto software (SPL) para el desarrollo de portlets. 3 Desarrollo basado en SPL hace referencia a los métodos, herramientas y técnicas para la creación de una colección de sistemas software similares a partir de un conjunto compartido de artefactos software utilizando un medio de producci ón común. En este escenario, ya no tenemos un portlet sino una familia de portlets, y el proveedor de portlet se convierte en la "cadena de montaje" de esta familia. Este trabajo promueve esta visión mediante la introducción de una arquitectura compatible con el estándar WSRP que permite a los consumidores de portlets manejar familias de portlet de la misma manera en la que manejan "portlets tradicionales". Al hacer esto, los portlets están más cerca de convertirse en servicios realmente reutilizables y, por lo tanto, permitir la construcción de Arquitecturas Orientadas a Servicios (SOA) usando portlets. Una arquitectura SOA de de ne como "una estrategia de TI que organiza las funciones discretas contenidas en las aplicaciones empresariales en servicios interoperables estándares que pueden ser combinados y reutilizados de manera ágil para satisfacer las necesidades del negocio" - BEA Systems, Inc. SOA ofrece a las organizaciones una mayor agilidad, ya que pueden desplegar rápidamente nuevos procesos de negocio o modi car los existentes en respuesta a los cambios del mercado. Los portales basados en portlets podrían proporcionar un enfoque ligero a las SOA. La de nición anterior puede reformularse utilizando la terminolog ía de portales como una estrategia de TI que organiza las funciones discretas contenidas en las aplicaciones empresariales [portlets] en servicios interoperables [portlets remotos pueden comunicarse y compartir datos] estándares [WSRP está basado en los estándares de servicios web] que pueden ser combinados [los portales pueden agregar información de múltiples portlets] y reutilizados de manera ágil [WSRP no requiere esfuerzo de programación] para satisfacer las necesidades del negocio . Aunque un número creciente de organizaciones se están moviendo hacia las SOA muchas están teniendo di cultades para identi- car el primer paso en el proceso. Aquellas empresas que buscan bene ciarse de las SOA pueden utilizar los portales basados en portlets como su primer paso en este camino [9]. Este escenario SOA no sólo requiere interoperabilidad (a través de los estándares de portlets) y la difusión de los portlets (a través de los repositorios de portlets), sino también variabilidad. Los portlets tienden a ser componentes de grano grueso, ya que encapsulan tanto la capa de presentación, como la capa de funcional. Estos componentes de granularidad gruesa tienen menos posibilidades de ser reutilizados "tal cual" [5]. Esto puede poner en peligro la visión de los portlets como servicios reutilizables. Esto introduce las siguientes preguntas de investigación: ¿Cómo se puede aplicar el desarrollo basado en SPL a los portlets? ¿Cuáles serían las implicaciones para el estándar WSRP? 4 4 Escenario 2: Variabilidad basada en el Con- sumidor Los proveedores de portlets no siempre pueden prever todas las necesidades de los consumidores, o algunos portlets podrían necesitar extensiones que no pueden ser soportadas utilizando los mecanismos de parametrización habituales. El etiquetado social es un ejemplo de ello. Los portales, en un grado mayor que otras aplicacionesWeb, tienen la noción de comunidad profundamente arraigada en el interior de su naturaleza. Especí camente, los Enterprise Information Portals nacieron para dar soporte a los empleados dentro de una organización. Por lo tanto, es natural integrar funcionalidades presentes en las redes sociales dentro de estos portales. Entre estas funcionalidades, este trabajo se centra en el etiquetado. La motivación para llevar el etiquetado al lugar de trabajo, admite una doble perspectiva. Desde el punto de vista de la empresa, el etiquetado es un medio económico para compartir y retener conocimiento en el contexto de una organización, previniendo la fuga de datos críticos fuera de la empresa [4]. Desde la perspectiva de un empleado, distintos estudios [11, 1, 8] concluyen que las motivaciones individuales para utilizar el etiquetado en el lugar de trabajo, tales como la creación de un repositorio personal o re-encontrar los recursos propios aún son motivaciones importantes. En este escenario, los etiquetadores (es decir, la comunidad del portal) y las etiquetas son activos del portal. Sin embargo, y a diferencia de los sitios de etiquetado tradicionales, los portales podrían no contener la descripción de todos los recursos susceptibles de ser etiquetados. Por ejemplo, la descripción de los libros o de los hoteles que se ofrecen a través del portal la podría proveer de forma remota, por ejemplo, por Amazon y Expedia, respectivamente. Esta externalización de la descripción de los contenidos no implica que no merezca la pena etiquetar los recursos externos. Esto nos lleva a distinguir entre dos actores: el proveedor de recursos, que mantiene el contenido de los recursos etiquetables (por ejemplo, la descripción del libro en el caso de Amazon), y el consumidor de recursos (es decir, el portal), que mantiene la comunidad de etiquetadores y las etiquetas. De la misma manera en que los portlets adaptan su capa de presentación a las directrices estéticas del portal que los aloja, el etiquetado a través de los portlets también debe adaptarse a las peculiaridades del portal del consumidor. Esto introduce las siguientes preguntas de investigación: ¿Cómo pueden los portlets ser conscientes de las especi cidades del portal, en concreto, aquellas referentes al etiquetado? 5 Escenario 3: Variabilidad basada en el Usuario La personalización es el proceso de adaptación de las páginas a las características o preferencias individuales de los usuarios de manera que resulten más e caces para satisfacer sus objetivos. Se basan en la teoría de que cada usuario tiene intereses y necesidades únicas. Desafortunadamente, los usuarios normalmente 5 no tienen in uencia en la elección de qué contenido puede ser personalizado o cómo puede este personalizarse. Además, no siempre es fácil para el diseñador prever los distintos contextos y objetivos desde los que se acceden a su aplicación. "Ningún diseño puede proporcionar información para cada situación, y ningún diseñador puede incluir información personalizada para cada usuario" [10]. No hace mucho tiempo, sólo los desarrolladores podían crear aplicaciones. Los usuarios sólo podían utilizar lo que los desarrolladores habían creado antes. Sin embargo, las cosas han cambiado. Con los mashups, los usuarios pueden evitar el departamento de TI y crear sus propias aplicaciones en respuesta a sus propias necesidades. Un mashup es una aplicación web ligera creada por la combinación de información y capacidades de más de una fuente existente para ofrecer nuevas funciones y conocimiento. Nuevas herramientas están actualmente disponibles (por ejemplo, Software AG Presto, IBM Mashup Center, Kofax Kapow) que requieren poca o ninguna participación del departamento de TI y permiten a los usuarios con experiencia crear el mashup que necesitan, cuando lo necesitan. Habilitando a los usuarios de esta manera, se puede reducir el número de aplicaciones que esperan a la cola del departamento de TI para ser creadas, el tiempo y los costos de desarrollo y se puede reducir el costo de crear información personalizada ya que los usuarios pueden adaptar ellos mismos la información a la forma en que la necesitan [3]. Esto introduce las siguientes preguntas de investigación: ¿Cómo pueden los mashups ser introducidos en los portales basados en portlets? 6 Contribuciones Esta tesis se ha desarrollado en el contexto de la ingeniería, lo que nos empujó a lograr no sólo una contribución académica sino también a mirar la aplicabilidad de estas ideas. Para ello, se proporciona una implementación de las ideas aquí introducidas. En nuestra opinión, esta tesis hace las siguientes aportaciones: 6.0.1 Variabilidad basada en el Proveedor Este trabajo promueve la visión de los portlets como servicios reutilizables mediante la introducción de la noción de Consumer Pro le como una forma de capturar las especi cidades de las diferentes organizaciones, donde el portlet puede ser utilizado. Esto a su vez conduce al uso de un enfoque de desarrollo de portlets basado en SPL y a la introducción de una arquitectura compatible con el estándar WSRP que permite a los consumidores de portlets manejar familias de portlet de la misma manera en la que manejan "portlets tradicionales". La solución se ha apoyado en el proyecto WSRP4Java1. 1http: //portals.apache.org/wsrp4j/ 6 6.0.2 Variabilidad basada en el Consumidor Esta tesis explora aquellos medios que pueden ser más adecuados para dar soporte a las características especí cas del consumidor. El etiquetado se utiliza como un ejemplo. Este trabajo argumenta que el etiquetado debe ser ortogonalmente soportado como una funcionalidad transversal encima de los portlets. El principal reto se basa en la coherencia tanto en el back-end (esto es, el uso de una estructura común de datos, por ejemplo, un conjunto común de etiquetas), y el front-end (esto es, las interacciones con la funcionalidad de etiquetado deben ser soportadas de forma homogénea a lo largo de todo el portal utilizando estilos de presentación similares). El mecanismo de eventos de los portlet y las anotaciones RDFa se utilizan para cumplir con este requisito. Un ejemplo sobre Liferay ilustra la viabilidad del enfoque. 6.0.3 Variabilidad basada en el Usuario El enfoque presentado introduce mashups como un mecanismo de personalizaci ón adicional mediante el cual los usuarios del portal pueden complementar los servicios del portal (es decir, los portlets) con sus propias necesidades de información. El enfoque se implementa sobre Liferay como la plataforma de portales utilizando los portlets como la tecnología para soportar los servicios del portal y XBL como que la tecnología de integración. Para facilitar la adopción del enfoque se ha desarrollado una herramienta visual que oculta los tecnicismos de XBL a los usuarios. 7 Conclusiones El protocolo WSRP describe la conversación entre los proveedores de portlets y los consumidores que actúan en nombre de los usuarios nales: los proveedores son los servicios web con capa de presentación que alojan los portlets y son capaces de procesar las solicitudes de markup y las de interacción del usuario con los portlets, los consumidores utilizan estos servicios web como parte de las vistas que presentan a los usuarios nales y gestionan las interacción de los usuarios nales con la capa de presentación de los portlets, los usuarios nales son los clientes de los consumidores Estos roles constituyen los diferentes contextos en los que la variabilidad de los portlets remotos se puede jar y decidir. el proveedor de portlet. En este caso, el proveedor de portlets lleva a cabo un análisis profundo del dominio y proporciona a los consumidores un conjunto cerrado de variantes entre las que elegir. 7 el consumidor portlet. Los consumidores de portlets también pueden crear y añadir sus propias variantes especí cas del producto, por ejemplo, para tener en cuenta los requisitos que para ser satisfechos requieren el uso de funcionalidad externa. el usuario nal. Hay una tendencia creciente para proporcionar variabilidad a los usuarios nales (por ejemplo, mecanismos a través de plugins). Sin embargo, no podemos esperar que los usuarios nales puedan editar y compilar el código fuente. Esta tesis aborda el reto de soportar variabilidad para cada uno de estos escenarios

Virtual learning process environment (VLPE): a BPM-based learning process management architecture

E-learning systems have significantly impacted the way that learning takes place within universities, particularly in providing self-learning support and flexibility of course delivery. Virtual Learning Environments help facilitate the management of educational courses for students, in particular by assisting course designers and thriving in the management of the learning itself. Current literature has shown that pedagogical modelling and learning process management facilitation are inadequate. In particular, quantitative information on the process of learning that is needed to perform real time or reflective monitoring and statistical analysis of students’ learning processes performance is deficient. Therefore, for a course designer, pedagogical evaluation and reform decisions can be difficult. This thesis presents an alternative e-learning systems architecture - Virtual Learning Process Environment (VLPE) - that uses the Business Process Management (BPM) conceptual framework to design an architecture that addresses the critical quantitative learning process information gaps associated with the conventional VLE frameworks. Within VLPE, course designers can model desired education pedagogies in the form of learning process workflows using an intuitive graphical flow diagram user-interface. Automated agents associated with BPM frameworks are employed to capture quantitative learning information from the learning process workflow. Consequently, course designers are able to monitor, analyse and re-evaluate in real time the effectiveness of their chosen pedagogy using live interactive learning process dashboards. Once a course delivery is complete the collated quantitative information can also be used to make major revisions to pedagogy design for the next iteration of the course. An additional contribution of this work is that this new architecture facilitates individual students in monitoring and analysing their own learning performances in comparison to their peers in a real time anonymous manner through a personal analytics learning process dashboard. A case scenario of the quantitative statistical analysis of a cohort of learners (10 participants in size) is presented. The analytical results of their learning processes, performances and progressions on a short Mathematics course over a five-week period are also presented in order to demonstrate that the proposed framework can significantly help to advance learning analytics and the visualisation of real time learning data

WS-GUARD: enhancing UDDI Registries with on-line testing capabilities

Abstract This thesis investigates the Service Oriented Architecture and in particular the runtime discovery of Web services through the development of an empowered UDDI registry called WS-GUARD (Guaranteeing Uddi Audition at Registration and Discovery). We start by presenting the Audition framework, a specially conceived framework that applies the idea of testing during the Web service registration in the UDDI registry and then we study the practical implications of its implementation focusing on the most advanced Web service technologies. This thesis aims at modifying and extending the registration protocol of Web services into UDDI registries in order to introduce a testing phase before actual service publishing: only those services that pass the audition are admitted in the registry and become publicly available at runtime. A complete prototype implementation of WS-GUARD is described and analysed. Riassunto analitico La tesi ha investigato l'ambito Service Oriented Architecture e in particolare il run-time discovery di Web service attraverso la realizzazione di un registro UDDI potenziato, denominato WS-GUARD (Guaranteeing Uddi Audition at Registration and Discovery). Principale obiettivo del lavoro è stato la modifica dei protocolli di registrazione del registro UDDI. Tale modifica è stata rivolta all'introduzione di una fase di testing preventiva alla tradizionale fase di registrazione. Ammettendo alla registrazione soltanto quei servizi che superino la fase di verifica si intende fornire maggiori garanzie sulla qualità dei servizi che saranno resi dinamicamente reperibili (discovered) a tempo di esecuzione. La tesi discute le modifiche proposte e ne fornisce un'implementazione reale

Intranet of the future: functional study, comparison of products and practical implementation

Future intranet: functional study, comparison of products and practical implementation 1. Introduction The project has fulfilled three goals: 1) To perform a study of the functionalities which have to be covered in a modern intranet (web 2.0, unified communication, collaboration, etc) 2) To perform a comparison of tools of the market which can be used to implement intranets (commercial and open source products) 3) To test three of these tools (Oracle WebCenter, Liferay Portal and Microsoft SharePoint) and develop a prototype with Oracle WebCenter. In addition, it includes a research about the evolution of the Intranets among the time, as well as a work to discover the current state of this kind of platforms over the entire world. In this introductory research it is also convenient to include other topics which are not strictly technical involving the use of this Intranet. To be more concrete, there is an analysis of the importance of the human role and management of the Intranet, the process of deploying a new Intranet in an organization and methods to evaluate the performance of this new system.   2. Functional study The approach taken to fulfil this goal is to develop a theoretical model describing the relationship between the Intranet and its users, and a complete set of functionalities which could be covered in the Intranet of the future. These functionalities are categorized in groups. The project describes these groups and the functionalities included on them. 3. Comparison of products The project will describe and compare several technologies which can be used to develop an Intranet that we have previously modelled. The purpose here is to discover the strong points and weaknesses of each technology if it was used to develop the Intranet we desire. After having done such a review, the project focuses on three technologies and performs an extensive evaluation of them. Finally, an extensive comparison between these three technologies is done, highlighting where they offer better solutions and performance compared to the other possibilities. 4. Practical implementation The project focuses on three technologies: Oracle WebCenter, Liferay Portal and Microsoft SharePoint. Then, a prototype which covers a set of functionalities of the modelled Intranet has been built with Oracle WebCenter

CHOReOS Middleware Specification (D3.1)

This deliverable specifies the main concepts of the CHOReOS middleware architecture. Starting from the Future Internet (FI) challenges for scalability, heterogeneity, mobility, awareness, and adaptation that have been investigated in prior work done in WP1, we introduce the aforementioned concepts to deal with the requirements derived from the FI challenges. In particular, we propose an extensible and scalable service discovery approach for the organization and discovery of services that relies on multiple service discovery protocols. Moreover, we introduce an extensible and scalable approach, based on the service bus paradigm, for service access that features the integration and adaptation of multiple interaction protocols. Furthermore, we propose solutions that enable the execution of FI service compositions that range from compositions of choreographed services, developed according to the CHOReOS development process, to massive compositions of things. Finally, we detail the Cloud & Grid middleware facilities that support the overall middleware and the choreographies that are built on it, via a unified API that provides access to multiple cloud infrastructures (e.g., Amazon EC2, HP Open Cirrus, private clouds)