105 research outputs found

    An Ontology Based Approach Towards A Universal Description Framework for Home Networks

    Get PDF
    Current home networks typically involve two or more machines sharing network resources. The vision for the home network has grown from a simple computer network, to every day appliances embedded with network capabilities. In this environment devices and services within the home can interoperate, regardless of protocol or platform. Network clients can discover required resources by performing network discovery over component descriptions. Common approaches to this discovery process involve simple matching of keywords or attribute/value pairings. Interest emerging from the Semantic Web community has led to ontology languages being applied to network domains, providing a logical and semantically rich approach to both describing and discovering network components. In much of the existing work within this domain, developers have focused on defining new description frameworks in isolation from existing protocol frameworks and vocabularies. This work proposes an ontology-based description framework which takes the ontology approach to the next step, where existing description frameworks are in- corporated into the ontology-based framework, allowing discovery mechanisms to cover multiple existing domains. In this manner, existing protocols and networking approaches can participate in semantically-rich discovery processes. This framework also includes a system architecture developed for the purpose of reconciling existing home network solutions with the ontology-based discovery process. This work also describes an implementation of the approach and is deployed within a home-network environment. This implementation involves existing home networking frameworks, protocols and components, allowing the claims of this work to be examined and evaluated from a ‘real-world’ perspective

    Workshop on real-time for multimedia (RTMM), Catania, Italy, June 29, 2004

    Get PDF

    Discovering Homecare Services

    Get PDF
    Future homecare networks will consist of a very wide range of embedded services and software that will often rely on numerous other components to achieve their tasks. They will rarely operate in a self sufficient manner. The ability to discover and use services is not however a trivial task. Services may provide raw data, such as temperature readings, or higher contextual data, such as user activity and availability. Networks may change over time and may not be subject to a single management regime, implying the need for a great deal of self-reliance for any software component seeking services from elsewhere within the network. This chapter describes work carried out at the University of Stirling to improve service discovery and allow it to operate effectively in networks with a significant turnover in services. Simple syntactical keyword lookups are insufficient, and so semantics are introduced into the discovery process by using ontologies. However ontologies are known to grow and change over time and so maintaining them can be difficult and error-prone. The described approach employs a hierarchical approach that fosters re-use and sharing of ontologies to alleviate some of the more acute problems of building and maintaining large ontologies

    An Autonomic Cross-Platform Operating Environment for On-Demand Internet Computing

    Get PDF
    The Internet has evolved into a global and ubiquitous communication medium interconnecting powerful application servers, diverse desktop computers and mobile notebooks. Along with recent developments in computer technology, such as the convergence of computing and communication devices, the way how people use computers and the Internet has changed people´s working habits and has led to new application scenarios. On the one hand, pervasive computing, ubiquitous computing and nomadic computing become more and more important since different computing devices like PDAs and notebooks may be used concurrently and alternately, e.g. while the user is on the move. On the other hand, the ubiquitous availability and pervasive interconnection of computing systems have fostered various trends towards the dynamic utilization and spontaneous collaboration of available remote computing resources, which are addressed by approaches like utility computing, grid computing, cloud computing and public computing. From a general point of view, the common objective of this development is the use of Internet applications on demand, i.e. applications that are not installed in advance by a platform administrator but are dynamically deployed and run as they are requested by the application user. The heterogeneous and unmanaged nature of the Internet represents a major challenge for the on demand use of custom Internet applications across heterogeneous hardware platforms, operating systems and network environments. Promising remedies are autonomic computing systems that are supposed to maintain themselves without particular user or application intervention. In this thesis, an Autonomic Cross-Platform Operating Environment (ACOE) is presented that supports On Demand Internet Computing (ODIC), such as dynamic application composition and ad hoc execution migration. The approach is based on an integration middleware called crossware that does not replace existing middleware but operates as a self-managing mediator between diverse application requirements and heterogeneous platform configurations. A Java implementation of the Crossware Development Kit (XDK) is presented, followed by the description of the On Demand Internet Computing System (ODIX). The feasibility of the approach is shown by the implementation of an Internet Application Workbench, an Internet Application Factory and an Internet Peer Federation. They illustrate the use of ODIX to support local, remote and distributed ODIC, respectively. Finally, the suitability of the approach is discussed with respect to the support of ODIC

    Contribution to Quality-driven Evolutionary Software Development process for Service-Oriented Architectures

    Get PDF
    The quality of software is a key element for the successful of a system. Currently, with the advance of the technology, consumers demand more and better services. Models for the development process have also to be adapted to new requirements. This is particular true in the case of service oriented systems (domain of this thesis), where an unpredictable number of users can access to one or several services. This work proposes an improvement in the models for the software development process based on the theory of the evolutionary software development. The main objective is to maintain and improve the quality of software as long as possible and with the minimum effort and cost. Usually, this process is supported on methods known in the literature as agile software development methods. Other key element in this thesis is the service oriented software architecture. Software architecture plays an important role in the quality of any software system. The Service oriented architecture adds the service flexibility, the services are autonomous and compact assets, and they can be improved and integrated with better facility. The proposed model in this thesis for evolutionary software development makes emphasis in the quality of services. Therefore, some principles of evolutionary development are redefined and new processes are introduced, such as: architecture assessment, architecture recovery and architecture conformance. Every new process will be evaluated with case studies considering quality aspects. They have been selected according to the market demand, they are: the performance, security and evolutionability. Other aspects could be considered of the same way than the three previous, but we believe that these quality attributes are enough to demonstrate the viability of our proposal

    Automated software systems generation for process-oriented organizations

    Get PDF
    Tese de doutoramento do Programa Doutoral em Tecnologias e Sistemas de InformaçãoCada vez mais, as organizações suportam as suas operações em sistemas de software. Torna-se, portanto, muito relevante o correto mapeamento das operações nos sistemas de software. Esta tese foca-se em organizações orientadas a processos de negócio, devido à relevância dada pelas normas de qualidade, pelos modelos de excelência, e pelos requisitos dos clientes, a esse tipo de estruturação interna das organizações. Nas organizações orientadas a processos de negócio existem diversos fatores, como o tempo envolvido nos projetos de implementação de processos de negócio em software, as diferenças existentes entre os modelos de processos de negócio e a sua implementação real, ou a quantidade e o tipo de recursos envolvidos nesses projetos, que fazem com que os projetos de desenvolvimento de software sejam demasiado dispendiosos, demorem demasiado tempo, e não garantam que o produto de software resultante seja o mais adequado à realidade da organização que o vai usar. Esta tese propõe que os sistemas de informação e de software devam ser desenvolvidos, desde o início, incorporando os modelos das organizações onde irão ser usados. Além disso, e como existem disponíveis modelos de referência de processos de negócio, esta tese também propõe o seu uso explícito aquando da recolha de requisitos. Assim, o objetivo principal da tese é propor uma metodologia que se inicie com modelos de processos de negócio e que termine com a geração de sistemas de software, para organizações orientadas a processos de negócio. A metodologia denomina-se BIM e é formalizada através do metamodelo EPF. Dada a abrangência dos temas a tratar, a tese foi conduzida tendo em atenção que o processo de desenvolvimento de software para suportar organizações orientadas a processos pode ser otimizado. Para melhor mostrar os diversos passos e resultados intermédios, usamos a metodologia de investigação Action Research. A tese propõe que as atividades de investigação sejam terminadas quando uma dada condição de paragem seja atingida, e para isso usa uma avaliação baseada num conjunto de indicadores para os resultados do produto e do processo, e uma adaptação do modelo de excelência EFQM para a forma como foi executado o processo de desenvolvimento. O foco das Action são os sistemas de software MES, essenciais na ligação entre sistemas de software embebido e sistemas ERP. Nesta tese, as Action iniciam-se com modelos de processos e com arquiteturas de software standard, e terminam com uma proposta de modelo de processo e com arquiteturas de software e tecnologias adaptadas à execução de processos de negócio. A tese propõe também alguns conceitos como IAvO (extensão de modelos de processos de negócio), OBO (componentes de software intermutáveis e não-proprietários), OA (aspetos organizacionais), e PF (framework de processos) para aumentarem a eficiência e eficácia na implementação em software de processos de negócio.Increasingly, organizations support their operations by using software systems, turning very relevant the proper mapping of operations into software systems. This thesis focuses on organizations oriented to business processes, due to the importance that quality norms, excellence models, and customer requirements put on this type of internal structures of organizations. Process-oriented organizations have characteristics, such as the time needed to implement business processes in software, the differences between the business process models and the real business processes, or the quantity and type of the required resources, that lead to development projects too expensive, taking too long to complete, and that do not assure that the resulting product is the most adequate to the reality of the client organization. This thesis proposes that the development of information and software system embodies, since the early stages, the models of the organization where they operate. In addition, and since business process reference models are available, the thesis also proposes to use explicitly such reference models by requirements collection time. Thus, the main goal of the thesis is to propose a methodology that picks business process reference models and ends with software systems, for process-oriented organizations. The methodology is denominated BIM and is formalized by using the EPF metamodel. Due to the wide scope of the studied areas, the thesis is tailored considering that the development process for processoriented organizations can be optimized. To express better the intermediate steps and results, we use the Action Research methodology. The thesis proposes that the research activities terminate when a stopping condition is met, based on a set of indicators for the product, and a tailoring of the EFQM model for the development process. The Actions are focused on MES, crucial for the linking of embedded software systems with ERP systems. In this thesis, the Actions start by using standard process models and software architectures, and end by using a proposed process model, and software architectures and technologies adapted to the execution of business software. The thesis also proposes new concepts like IAvO (extension to business process reference models), OBO (interchangeable and nonproprietary software components), AO (organizational aspects), and PF (process framework) to increase the efficiency and the effectiveness of the implementation of business processes in software

    Un meta-modèle de composants pour la réalisation d'applications temps-réel flexibles et modulaires

    Get PDF
    The increase of software complexity along the years has led researchers in the software engineering field to look for approaches for conceiving and designing new systems. For instance, the service-oriented architectures approach is considered nowadays as the most advanced way to develop and integrate fastly modular and flexible applications. One of the software engineering solutions principles is re-usability, and consequently generality, which complicates its appilication in systems where optimizations are often used, like real-time systems. Thus, create real-time systems is expensive, because they must be conceived from scratch. In addition, most real-time systems do not beneficiate of the advantages which comes with software engineering approches, such as modularity and flexibility. This thesis aim to take real time aspects into account on popular and standard SOA solutions, in order to ease the design and development of modular and flexible applications. This will be done by means of a component-based real-time application model, which allows the dynamic reconfiguration of the application architecture. The component model will be an extension to the SCA standard, which integrates quality of service attributs onto the service consumer and provider in order to stablish a real-time specific service level agreement. This model will be executed on the top of a OSGi service platform, the standard de facto for development of modular applications in Java.La croissante complexité du logiciel a mené les chercheurs en génie logiciel à chercher des approcher pour concevoir et projéter des nouveaux systèmes. Par exemple, l'approche des architectures orientées services (SOA) est considérée actuellement comme le moyen le plus avancé pour réaliser et intégrer rapidement des applications modulaires et flexibles. Une des principales préocuppations des solutions en génie logiciel et la réutilisation, et par conséquent, la généralité de la solution, ce qui peut empêcher son application dans des systèmes où des optimisation sont souvent utilisées, tels que les systèmes temps réels. Ainsi, créer un système temps réel est devenu très couteux. De plus, la plupart des systèmes temps réel ne beneficient pas des facilités apportées par le genie logiciel, tels que la modularité et la flexibilité. Le but de cette thèse c'est de prendre en compte ces aspects temps réel dans des solutions populaires et standards SOA pour faciliter la conception et le développement d'applications temps réel flexibles et modulaires. Cela sera fait à l'aide d'un modèle d'applications temps réel orienté composant autorisant des modifications dynamiques dans l'architecture de l'application. Le modèle de composant sera une extension au standard SCA qui intègre des attributs de qualité de service sur le consomateur et le fournisseur de services pour l'établissement d'un accord de niveau de service spécifique au temps réel. Ce modèle sera executé sur une plateforme de services OSGi, le standard de facto pour le developpement d'applications modulaires en Java

    Variability in remote portlets

    Get PDF
    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
    corecore