Talk:AOD - Assistance on Demand Infrastructure

From wiki.gpii
Jump to: navigation, search


What it is

What is your tool/technology about?
What does your tool/technology and/or its parts bring to the DeveloperSpace?

The Assistance on Demand Services infrastructure is a generic open-source infrastructure that supports current and emerging needs for Assistance on Demand services employing cloud computing technologies and matching the Prosperity4All overall architectural and ecosystem perspective. Once instantiated, it will offer a set of unique features since it will:

  • allows individuals to set up services that seek assistance in an organized fashion from a set of predefined sources based on the type of need, the type (human or machine based) and quality of  the required service, and other personal preferences,
  • offers zero/default configuration mode options for efficiently supporting non professional with low digital literacy users to set up AoD services, while allowing for configuring the service to fit the user needs,
  • enables the set up of user-defined network of assistance services,
  • allows application developers and service providers to easily register the services they offer (or set up new ones), which can be of any type e.g. machine, human, crowd-based assistance services,
  • supports multiple charging models and enables payment for all services through the associated P4A payment system, including the support of micropayment and micro-funding schemes,
  • supports set up of QoS-price negotiation and “try harder” approaches,
  • supports the set up of multi-modal technical support including both human based and machine-based (e.g. text, voice or video-based) AoD,

It will allow the developers and other stakeholders interested in offering AoD services to:

  • promote and sell their services bringing them closer to large audiences, relieving them from deploying their own charging/payment infrastructures
  • discover new user needs and undertake the development of new services.


Its value as a whole (to developers)

Who are the target users of your tool/technology?
What value would these developers see in using this tool/these components?
(e.g. how is it better than what they might have currently – or could develop.)
You can illustrate the specific value by describing a target use case.

The target users of the AoD infrastructure are:

  • service providers / developers (SP) who want to offer
    • a bundle of services for a specific target group of service consumers; such SP instantiates the AoD and acts as mediator between end-users and service providers and can be either a company or any community/organisation,
    • individual service providers trying to sell through a specific P4A AoD instance their service avoiding to set up their own infrastructure to reach customers
  • individual end users/ service consumers. 
  • </ul>

    For the SP/developers, the P4A AoD infrastructure added value stems from the fact that it:

    • consists an access point to a very wide userbase since it enables the set up of assistance services of any type (machine or human based) for any type of disability/literacy,
    • offers security and payment functionality through interconnection to the relevant systems developed in P4A, allowing the developers to concentrate on the functionality of the service they develop.

    For the individual end users (service consumers), the added value stems from the fact that it offers:

    • a great variety of service and an easy personalised user interface that facilitates searching for services in an intelligent multi-criteria manner
    • the opportunity to set up a network of services for the people they take care of (friends, family members, e.t.c.). For example, a lady can choose specific services for housekeeping, nurses, doctors and other daily life tasks for her parents that are incapable of taking care of these tasks.
    • improved ease of use through multi-modal technical support
    • easy billing and charging accumulating micro-charges and forming a monthly bill
    • micro-funding opportunities and definition of services that are desired but not available. 

    Currently there is no generic open source infrastructure that can support the set up of several types of machine- and human- based AoD services, notably for non-developers and family members. As such, the P4A AoD can be very valuable for service consumers of AoD, as well as individuals and organisations wanting to offer AoD services.

    The AoD platform aspires to be the entry point for numerous assistance services just like Google Search platform is the entry point for whatever we look for in the internet. As such, it can attract a very large group of users.  Consider, for example, consumers (e.g. hard of hearing persons) who are in need of subtitling services. Once the request from a consumer for receiving a subtitling service is received, the AoD infrastructure will expose the registered subtitling service(s) to the consumers who need it; the services can be machine-enabled (automatic) or offered by humans. This is one of the criteria that the service listing functionality of the AoD infrastructure will use to rank the services that will be presented to the consumer – other criteria under examination are the cost of the service, the quality of the services as assessed by other consumers, etc. Now, let’s suppose that the consumer selects an automated subtitling service but after using it for a short period, she is not satisfied with the quality of service. The AoD infrastructure will enable her to push the “try harder’ button and be presented with similar services which are of higher quality but also higher cost (e.g. services offered by humans).

    On the other hand, there are large numbers of developers that can develop very interesting and effective assistance applications/services, who, however, are not fully aware of the consumers’ needs or do not want to spend too much time in building a complete framework that  takes care of payment issues and security issues. The AoD infrastructure will facilitate the set up of AoD services for such developers by offering them, e.g., payment and security components that are easy-to-integrate in existing or newly built services, thus lowering the delivery cost of the service. Moreover, the AoD infrastructure, by interconnecting to the micro-payment and biding components, will bring developers closer to what consumers want, request and are willing to micro-fund.


    'Value of parts 'of it

    In addition to using it as a whole, what parts might also be of use to a developer?

    AoD will be designed in a modular way leaving the organisation/individual that instantiates it to decide the sub-set of the functionality that it wishes to deploy. For example, the AoD without the try-harder component or without the micro-funding part can also be valuable platforms depending on the requirements at hand. Additionally, the AoD infrastructure will include a component enabling the set up of peer/community support network enabling IT support for consumers, which, per se, will be useful for organisations or individuals wishing to offer IT support services or enhance existing IT support services.

    There are many more parts of the AoD that will be useful  per se, even if not integrated.


    Support after P4A

    How would this tool / these components (and those who use them) be supported
    after the end of this grant?


    AoD will be a generic open-source infrastructure and its support and maintenance will be cclosely linked to the GPII sustainability. Options will be investigated during the exploitation activities of the project. Some possibilities can be foreseen at the moment:

    • SILO will undertake the support and maintenance (and further enhancement possibly) of the infrastructure with a fee;
    • establish a community allowing contributions from 3rd parties to foster the AoD sustainability. It is expected that as AoD deployments will proliferate, this community will augment and the support of AoD will be handeled in a shared/distributed manner.


    Technologies used

    What technologies are used or will be used in the P4A implementation of your tool/components?

    (a) On what platforms does it run?

    (b) In what programming language is it implemented?

    (c) What dependencies does it have on third-party libraries, frameworks, or development tools?

    (d) Does it have a user interface?

    (e) What other technologies, tools, libraries, or applications is it designed to integrate with, and how?

    (f) Are there licenses, duties, or other limitations to use of this?

    As the P4A architecture and requirements are ongoing, a final decision regarding the technologies that will be used has not been reached. The technologies under consideration are:

    1. Linux (e.g. Ubuntu, CentOS) as the main OS supporting the AoD services, Wirecloud[1] as the main user interface enabler
    2. Python and/or Java as the main backend services development languages, HTML(5), JavaScript and CSS
    3. Django framework, Apache Web Server, MySQL, MongoDB for the backend services, BootStrap, JQuery for the UI development, Eclipse/Netbeans as the development environments, Git as the main source control system, Jenkins as build service provider, SonarCube as code quality manager/monitor.
    4. yes
    5. we plan to integrate with several existing components, e.g. billing platforms such as the Paypal, the Google Wallet System and security services.  
    6. The licences accompanying the aforementioned software contain re-distribution friendly directives (Apache, BSD etc.). None of them is proprietary and/or of limited (re)use.



    Problems/challenges/risks you anticipate with your project goals

    What is the current status of your tool/components?

    What problems do you see taking the tools/components you had and changing
    them into the best form for developers and the DeveloperSpace?

    Do you see any problems/challenges/risks in getting broad adoption/use of your work?

    Please mark any parts of your answers that you don’t want to have on the WIKI or other public sources and deliverables.

    The main challenge we anticipate is the development of the rich functionality that the AoD is expected to offer. We plan to place emphasis on the proof of the concept, on scalability and modularity so that the version that will be developed within P4A can be easily extended to offer additional functionality. For example, we plan to implement three charging models and two micro-funding schemes but we will clearly define the interfaces of the relevant modules so that other modules implementing additional charging schemes and micro-funding mechanisms can be easily integrated.

    The AoD is currently in the requirements and use cases identification and analysis phase and (the first version of) its architecture will be defined in August/early September.

    P4A AoD will be built on the technologies defined above and the maximum effort to fit the needs of the developers will be placed.

    As AoD will offer rich functionality, we consider the risk of getting broad adoption low. On the other hand, we foresee a risk in being able to deliver a mature AoD infrastructure for all promised functionalities. It is expected that some functionalities will be of lower maturity than others: e.g. the service ranking/prioritisation functionality is still very much a research topic; nevertheless, we will try to achieve the maximum possible maturity by the end of the project.