iVolunteer - Towards a Multitenant and Trustable Volunteer ...

Submitted byBerthold Roiser, BSc

Submitted atInstitute of Telecoopera-tion - Department of Co-operative Information Sys-tems

SupervisorAssoc. Prof. Mag. Dr.Wieland Schwinger, MSc

Co-Supervisora.Univ.-Prof. Mag. Dr.Werner Retschitzegger

February, 2020

JOHANNES KEPLERUNIVERSITY LINZAltenbergerstraße 694040 Linz, Österreichwww.jku.atDVR 0093696

iVolunteerTowards a Multitenantand Trustable VolunteerManagement SystemImplementation

Master Thesisto obtain the academic degree of

Diplom-Ingenieur

in the Master’s Program

Computer Science

S W O R N D E C L A R AT I O N

I hereby declare under oath that the submitted Master’s Thesis has beenwritten solely by me without any third-party assistance, informationother than provided sources or aids have not been used and those usedhave been fully documented. Sources for literal, paraphrased and citedquotes have been accurately credited.

The submitted document here present is identical to the electronicallysubmitted text document.

Linz, February 2020

ii

A B ST R A C T

Volunteering plays a tremendous role in our society. Not only in largescale crises like floodings or earthquakes but also in much smaller scaleactivities, like mentoring of children or health care. Independent ofthe concrete kind of activity, volunteering is usually an unpaid activityaiming to help society. Many people volunteer for large, globally actingorganizations like the Red Cross or the Fire Brigade; some people alsovolunteer for other individuals outside of any organizational structure.The challenge for volunteer involving organizations (VIOs) and otherexternal parties is not primarily to manage volunteers and activitiessince existing Volunteer Management Systems (VMS) already supportsuch functionalities. Today’s challenge is to put volunteers in the mid-dle of concern as targeted by the research project iVolunteer whichrepresents the basis for this thesis. iVolunteer breaks the isolations ofVIOs and seeks to build a community, allowing volunteers to cooperatewith different VIOs at the same platform.Based on the research project iVolunteer, this thesis demonstrates "howa multitenant, trustable volunteer management system, that is centeringits functionalities around volunteers" is implemented. Consequently,the goal of this thesis was to build a platform for multiple VIOs, al-lowing in a first step volunteers to get informed about present, pastand future activities in different VIOs at the same client as well as tobe encouraged to get involved in the volunteering community. As asecond step, this platform should provide volunteers the possibilitiesto cooperate with different VIOs at the same time. Beyond that basicfunctionality, each VIO is enabled to configure their activities withindividual underlying workflow steps (e.g., reserve activity, assign foractivity) in order to take into account the peculiarities of different VIOs.Finally, it is demonstrated by means of a proof-of-concept prototype,"how the engagements of volunteers can be digitized and exploited ina life-long way".All in all, this thesis is the continuation of conceptual work describedin the master thesis of Markus Weißenbek [19] , mainly focusing onimplementation aspects of a proof-of-concept prototype realizing amultitenant, trustable volunteer management system.

iii

K U R Z FA S S U N G

Freiwilligenarbeit spielt eine enorme Rolle in unserer Gesellschaft,nicht nur bei großen Krisen wie Überschwemmungen oder Erdbeben,sondern auch bei Aktivitäten wie der Betreuung von Kindern oderder Gesundheitsfürsorge. Unabhängig von der konkreten Art derTätigkeit ist Freiwilligenarbeit meist eine unentgeltliche Tätigkeit fürdie Gesellschaft. Viele Menschen engagieren sich freiwillig für große,global agierende Organisationen wie das Rote Kreuz oder die freiwilligeFeuerwehr, andere wiederum engagieren sich auch für Menschen außer-halb derartiger Organisationsstrukturen und leisten so ihren Beitrag.Die Herausforderung für Freiwilligenorganisationen (VIOs - "Volun-teer Involving Organisations") besteht nicht primär darin Freiwilligeund Aktivitäten einfach nur zu verwalten, da derartige Funktionaliätenmeist von existierenden Freiwilligenmanagementsystemen unterstütztwerden. Vielmehr besteht eine zentrale Herausforderung darin, die Frei-willigen in den Mittelpunkt des Interesses zu rücken, ein Ziel das auchim Forschungsprojekt "iVolunteer" verfolgt wird und die Grundlage fürdiese Masterarbeit darstellt. iVolunteer durchbricht die Isolation vonVIOs und versucht, eine Community aufzubauen in welcher Freiwilligemit verschiedenen VIOs auf derselben Plattform zusammenarbeitenkönnen.Basierend auf dem Forschungsprojekt iVolunteer wird in dieser Arbeitdemonstriert, wie ein mandantenfähiges, vertrauenswürdiges Freiwilli-genmanagementsystem implementiert werden kann, dessen Funktion-alität insbesondere Freiwillige selbst unterstützt. Ziel dieser Arbeit istes daher, eine Plattform für mehrere VIOs zu schaffen, die es Freiwilli-gen in einem ersten Schritt ermöglicht, sich über aktuelle, vergangeneund zukünftige Aktivitäten von verschiedenen VIOs zu informierensowie um ermutigt zu werden sich in der Freiwilligengemeinschaftzu engagieren. Im zweiten Schritt soll diese Plattform Freiwilligen dieMöglichkeit bieten, gleichzeitig mit verschiedenen VIOs zusammen-zuarbeiten. Über diese Grundfunktionalität hinaus kann jeder VIO seineAktivitäten mit einzelnen zugrunde liegenden Workflow-Schritten kon-figurieren (z. B. das Reservieren einer Aktivität oder das Zuweisen einerAktivität an einen Freiwilligen), um die Besonderheiten verschiedenerVIOs zu berücksichtigen. Abschließend soll anhand einer Proof-of-Concept-Implementierung demonstriert werden wie das Engagementvon Freiwilligen digitalisiert und genutzt werden kann.Diese Arbeit basiert auf der Masterarbeit von Markus Weißenbek [19],in der die Anforderungen an iVolunteer und die konzeptionelle Ar-chitektur des Systems beschrieben wurde. Somit konzentriert sich dieseArbeit hauptsächlich auf die Implementierungsaspekte eines Proof-of-Concept-Prototyps indem ein mandantenfähiges, vertrauenswürdigesFreiwilligenmanagementsystem realisiert wird.

iv

A C K N O W L E D G M E N T S

At this point, I would like to thank all those who have significantlysupported me throughout the realization of this Master’s thesis. Most ofall, I would like to thank both of my supervisors, Assoc. Prof. Mag. Dr.Wieland Schwinger, MSc and a.Univ.-Prof. Mag. Dr. Werner Retschitzeg-ger for their professional and competent care. For their constructivecriticism, the wealth of ideas and the endless effort, which they havespent over the last years.Special thanks to my colleagues Markus Weißenbek and Philipp Starzerfor jointly implementing the proof-of-concept prototype. It was a plea-sure to cooperate and work together during the last years. As a result,we implemented an incredible prototype representing the groundworkof this thesis.Last of all, thank you to my parents Astrid and Erwin for supportingme throughout my life; without them, I would not have come this far.

v

P R E FA C E

This thesis originates from the project „iVolunteer - Eine Digitale Platt-form zur Nutzbarmachung informeller Kompetenzen im Freiwilligen-bereich“, which is funded by the Austrian Research Promotion Agency(FFG, ProjectNr. 871494) under the COIN-program line.It has to be noted that, in the context of this project, a prototype foriVolunteer has been built, together with my collegues Philipp Starzerand Markus Weißenbek. Whereas the master thesis of Markus focusedon the requirement elicitation part and the conceptual architecture ofiVolunteer [19], this thesis is mainly dedicated to (i) the functionalityof the system in terms of its web-based user interface (ii) the system’srun-time architecture and (iii) implementation aspects of the system.

vi

C O N T E N T S

1 introduction 1

1.1 Volunteering . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Challenges of Volunteer Management Systems . . . . . . 2

1.3 Research project - "Cooperative Activities (CrAc)" . . . . 4

1.4 Research project - "iVolunteer" . . . . . . . . . . . . . . . 4

1.5 Problem definition . . . . . . . . . . . . . . . . . . . . . . 5

1.6 Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 requirements 7

2.1 User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Volunteer . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.2 Help-Seeker . . . . . . . . . . . . . . . . . . . . . . 8

2.1.3 Marketplace Administrator . . . . . . . . . . . . . 9

2.1.4 Platform Administrator . . . . . . . . . . . . . . . 9

2.2 Cross-Marketplace Component . . . . . . . . . . . . . . . 9

2.2.1 User Management . . . . . . . . . . . . . . . . . . 10

2.2.2 Multitenancy Management . . . . . . . . . . . . . 10

2.2.3 Social Management . . . . . . . . . . . . . . . . . . 12

2.2.4 UI Management . . . . . . . . . . . . . . . . . . . . 13

2.3 Marketplace Component . . . . . . . . . . . . . . . . . . . 13

2.3.1 Marketplace Configuration Management . . . . . 14

2.3.2 Task Management . . . . . . . . . . . . . . . . . . 14

2.3.3 Competence Management . . . . . . . . . . . . . . 17

2.3.4 Resource Management . . . . . . . . . . . . . . . . 18

2.3.5 Recommendation Management . . . . . . . . . . . 19

2.4 Footprint Component . . . . . . . . . . . . . . . . . . . . 20

2.4.1 Footprint Verification Management . . . . . . . . 21

3 functionality 23

3.1 Cross-Cutting Functionalities . . . . . . . . . . . . . . . . 23

3.1.1 Login . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1.2 Logout . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1.3 Start Page . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Volunteer Functionalities . . . . . . . . . . . . . . . . . . . 25

3.2.1 Dashboard . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.2 Your Profile . . . . . . . . . . . . . . . . . . . . . . 30

3.2.3 Your Engagement . . . . . . . . . . . . . . . . . . . 31

3.2.4 Your Achievements . . . . . . . . . . . . . . . . . . 33

3.2.5 Get Engaged . . . . . . . . . . . . . . . . . . . . . 35

3.2.6 Get Connected . . . . . . . . . . . . . . . . . . . . 37

3.2.7 Task Details . . . . . . . . . . . . . . . . . . . . . . 37

3.3 Help Seeker Functionalities . . . . . . . . . . . . . . . . . 38

3.3.1 Project List . . . . . . . . . . . . . . . . . . . . . . . 39

3.3.2 Project Form . . . . . . . . . . . . . . . . . . . . . . 39

3.3.3 Task List . . . . . . . . . . . . . . . . . . . . . . . . 40

3.3.4 Task Form . . . . . . . . . . . . . . . . . . . . . . . 40

3.3.5 Task Details . . . . . . . . . . . . . . . . . . . . . . 41

3.3.6 Task-Template List . . . . . . . . . . . . . . . . . . 42

3.3.7 Task-Template Form . . . . . . . . . . . . . . . . . 42

vii

contents viii

3.4 Platform Administrator Functionalities . . . . . . . . . . 42

3.4.1 Marketplace List . . . . . . . . . . . . . . . . . . . 43

3.4.2 Marketplace Form . . . . . . . . . . . . . . . . . . 43

4 architecture 45

4.1 Conceptual Architecture . . . . . . . . . . . . . . . . . . . 45

4.1.1 Blockchain . . . . . . . . . . . . . . . . . . . . . . . 45

4.1.2 Client . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.1.3 Cross-Marketplace . . . . . . . . . . . . . . . . . . 47

4.1.4 Marketplace . . . . . . . . . . . . . . . . . . . . . . 47

4.1.5 Marketplace Trustifier . . . . . . . . . . . . . . . . 47

4.1.6 Local Repository . . . . . . . . . . . . . . . . . . . 47

4.2 Run-time Architecture . . . . . . . . . . . . . . . . . . . . 48

4.2.1 Blockchain Server . . . . . . . . . . . . . . . . . . . 48

4.2.2 Client Computer . . . . . . . . . . . . . . . . . . . 49

4.2.3 Cross-Marketplace Server . . . . . . . . . . . . . . 49

4.2.4 Marketplace Server . . . . . . . . . . . . . . . . . . 49

5 implementation 51

5.1 Cross-Marketplace . . . . . . . . . . . . . . . . . . . . . . 51

5.1.1 User-Management . . . . . . . . . . . . . . . . . . 51

5.1.2 UI-Management . . . . . . . . . . . . . . . . . . . 54

5.1.3 Multitenancy-Management . . . . . . . . . . . . . 55

5.2 Marketplace Trustifier . . . . . . . . . . . . . . . . . . . . 57

5.2.1 Trust-Management . . . . . . . . . . . . . . . . . . 58

5.3 Marketplace . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.3.1 Competence-Management . . . . . . . . . . . . . . 60

5.3.2 Task-Management . . . . . . . . . . . . . . . . . . 60

5.3.3 Task Workflow Control . . . . . . . . . . . . . . . 69

6 future work 75

6.1 UI Management . . . . . . . . . . . . . . . . . . . . . . . . 75

6.2 User Management . . . . . . . . . . . . . . . . . . . . . . . 75

6.3 Social Management . . . . . . . . . . . . . . . . . . . . . . 76

6.4 Competence Management . . . . . . . . . . . . . . . . . . 76

bibliography 77

L I ST O F F I G U R E S

Figure 1.1 Introduction - iVolunteer Overview [6] . . . . . . 5

Figure 2.1 Use Case Packages . . . . . . . . . . . . . . . . . . 8

Figure 2.2 Multitenancy Management Use Cases . . . . . . . 11

Figure 2.3 Task Management Use Cases . . . . . . . . . . . . 15

Figure 2.4 Competence Management Use Cases . . . . . . . 17

Figure 2.5 Resource Management Use Cases . . . . . . . . . 19

Figure 2.6 Recommendation Management Use Cases . . . . 20

Figure 3.1 Cross-Cutting - Login . . . . . . . . . . . . . . . . 24

Figure 3.2 Cross-Cutting - Logout . . . . . . . . . . . . . . . 25

Figure 3.3 Cross-Cutting - Start Screen . . . . . . . . . . . . . 25

Figure 3.4 Volunteer - Navigation Flow . . . . . . . . . . . . 26

Figure 3.5 Volunteer - Dashboard - Presentation Mode . . . 27

Figure 3.6 Volunteer - Dashboard - Configuration Mode . . 28

Figure 3.7 Volunteer - Dashboard - Configuration Dialog . . 28

Figure 3.8 Volunteer - Dashboard - Dashlet Timeline Activi-ties, Project Members and Timeline . . . . . . . . . . 29

Figure 3.9 Volunteer - Dashboard - Dashlet Timeline Tasks . . 29

Figure 3.10 Volunteer - Your Profile - About Me . . . . . . . . 31

Figure 3.11 Volunteer - Your Profile - Friends . . . . . . . . . 31

Figure 3.12 Volunteer - Your Engagements - Opportunities . 32

Figure 3.13 Volunteer - Your Engagements - Collaborations . 32

Figure 3.14 Volunteer - Your Engagements - Contributions . . 33

Figure 3.15 Volunteer - Your Achievements - Opportunities . 34

Figure 3.16 Volunteer - Your Achievement - Collaborations . 34

Figure 3.17 Volunteer - Your Achievement - Contributions . . 35

Figure 3.18 Volunteer - Your Achievement - Encouragement . 35

Figure 3.19 Volunteer - Get Engaged - Recommendations . . 36

Figure 3.20 Volunteer - Get Engaged - Suggestions . . . . . . 36

Figure 3.21 Volunteer - Get Engaged - Search . . . . . . . . . 37

Figure 3.22 Volunteer - Get Connected . . . . . . . . . . . . . 37

Figure 3.23 Volunteer - Task Detail . . . . . . . . . . . . . . . . 38

Figure 3.24 Help Seeker - Navigation Flow . . . . . . . . . . . 39

Figure 3.25 Help Seeker - Project List . . . . . . . . . . . . . . 39

Figure 3.26 Help Seeker - Project Form . . . . . . . . . . . . . 40

Figure 3.27 Help Seeker - Task List . . . . . . . . . . . . . . . 40

Figure 3.28 Help Seeker - Task Form . . . . . . . . . . . . . . 41

Figure 3.29 Help Seeker - Task Detail . . . . . . . . . . . . . . 41

Figure 3.30 Help Seeker - Task-Template List . . . . . . . . . . 42

Figure 3.31 Help Seeker - Task Template Form . . . . . . . . . 42

Figure 3.32 Platform Administrator - Navigation Flow . . . . 43

Figure 3.33 Platform Administrator - Marketplace List . . . . 43

Figure 3.34 Platform Administrator - Marketplace Form . . . 44

Figure 4.1 Component Diagram of the Architecture (basedon [19]) . . . . . . . . . . . . . . . . . . . . . . . . . 46

Figure 4.2 Deployment Diagram of the Architecture (basedon [19]) . . . . . . . . . . . . . . . . . . . . . . . . . 49

ix

Figure 5.1 Cross-Marketplace - User-Management (based on[19]) . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Figure 5.2 User-Management - Authentication . . . . . . . . 53

Figure 5.3 Cross-Marketplace - UI-Management . . . . . . . 55

Figure 5.4 Cross-Marketplace - Multitenancy-Management . 56

Figure 5.5 Multitenancy-Management - Register Marketplace(based on [19]) . . . . . . . . . . . . . . . . . . . . 56

Figure 5.6 Multitenancy-Management - Subscribe Marketplace 57

Figure 5.7 Marketplace Trustifier - Trust-Management (basedon [19]) . . . . . . . . . . . . . . . . . . . . . . . . . 58

Figure 5.8 Trust-Management - Write a Contract Hash . . . 58

Figure 5.9 Trust-Management - Verify a HashableObject . . 59

Figure 5.10 Marketplace - Task-Management (based on [19]) . 61

Figure 5.11 Task Management - Life-Cycle . . . . . . . . . . . 63

Figure 5.12 Task-Management - Publish a Task . . . . . . . . 64

Figure 5.13 Task-Management - Reserve a Task . . . . . . . . 65

Figure 5.14 Task-Management - Assign a Task . . . . . . . . . 65

Figure 5.15 Task-Management - Start a Task . . . . . . . . . . 66

Figure 5.16 Task-Management - Finish a Task . . . . . . . . . 67

Figure 5.17 Task-Management - Abort a Task . . . . . . . . . 68

Figure 5.18 Task Workflow - Workflow Definition (based on[19]) . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Figure 5.19 Task-Workflow-Control - Workflow-Process . . . 71

L I ST O F TA B L E S

Table 2.1 Task Configuration Overview . . . . . . . . . . . . 15

L I ST I N G S

Listing 4.1 Example of a Local Repository (based on [19]) . . 48

Listing 5.1 User-Management - Decoded content of a JSONWeb Token . . . . . . . . . . . . . . . . . . . . . . . 52

Listing 5.2 User-Management - JWTAuthorizationFilter.java . 53

Listing 5.3 Task-Management - Project - Search for by Status 61

Listing 5.4 Task-Workflow-Control - Search for Workflow-Type 72

Listing 5.5 Task-Workflow-Control - Search for upcomingWorkflow-Step . . . . . . . . . . . . . . . . . . . . 73

x

1 I N T R O D U C T I O N

Contents1.1 Volunteering . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Challenges of Volunteer Management Systems . . . . . . . 21.3 Research project - "Cooperative Activities (CrAc)" . . . . . 41.4 Research project - "iVolunteer" . . . . . . . . . . . . . . . . 41.5 Problem definition . . . . . . . . . . . . . . . . . . . . . . . 51.6 Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . . 6

In this chapter, an introduction to volunteering in general and conse-quently to volunteer management systems with their related challengesare given. Afterwards, the research projects iVolunteer and its predeces-sor Cooperative Activities are presented, which represent two differentapproaches of volunteer management systems. Finally, the problemdefinition is presented followed by a short outline of this thesis. Pleasenote, that this chapter is in large parts also contained in the masterthesis of Markus Weißenbek [19].

1.1 volunteeringVolunteering is an integral part of our society in various different do-mains - health care, education, environmental protection or disasterrelief [13]. While according to Merrill [7] the understanding of the termvolunteering can vary depending on the country and culture, it is stillalways characterized by the following four features. (i) Volunteeringinvolves active participation or contribution in the form of time, energyor competence and does not include just the contribution of financial ormaterial resources, which would rather fall in the domain of donation-s/sponsoring as opposed to volunteering. (ii) Volunteering is uncoerced,i.e., volunteers contribute their time, energies and competences freelywithout compulsion. (iii) Even though volunteers sometimes are com-pensated for their personal and material expenses, volunteering is neverprimarily motivated by any financial gain. Last, (iv) the outcome ofvolunteering focuses on the common good as opposed to individualenrichment.Since volunteers scarcely work the amount of hours normal workersdo, the number of volunteers is measured in full-time equivalent (FTE)workers [12] in order to adequately compare the volunteer workforce.The global volunteer workforce in 2018 accounted for 109 million vol-unteers [18] measured in full-time equivalent (FTE) workers, whichexceeds for example the workforce of the Russian Federation or Japan.According to the State of the World’s Volunteerism Report by the UnitedNations Volunteers (UNV) [18] around 30% of the 109 million FTE vol-unteers participate formally through an organization (e.g. Red Cross)

1

1.2 challenges of volunteer management systems 2

and 70% informally for other individuals. For Europe, the report states,that of the 29 million FTE volunteers, 26.7% are informal FTE workersand 73.3% formal ones. Interestingly a similar statistic for Europe bySalamon et al. [13] suggests otherwise with a distribution of 59% FTEformal volunteers and 31% informal volunteers. The remaining 10 % areattributed to cooperatives and social enterprises. A study by the JohnsHopkins University [14] investigated 13 countries, including Canada,Israel, France, USA, Japan and Norway, and found, that on average,volunteers make up more than 7 % of the total workforce for all ofthese countries as well as that for 6 of the 13 countries the averageworkforce accounts for more than 10 %. In Europe, the volunteeringsector comprises volunteers equal to almost 30 million FTE workers[13] and is therefore barely behind the manufacturing (32 million) andtrade (30.7 million) sector [13].Furthermore, not all volunteers act similar in their way of engaging.Kapsammer et al. [6] show a broad spectrum of volunteers starting with(i) Patchwork Volunteers, engaged in various different VIOs throughouttheir life, to (ii) Engagement Hoppers, which spontaneously getting activedepending on their own availability and demand for volunteers andfinally, (iii) Crowd Volunteers focusing primarily on online micro-tasks(e.g. helping and presenting solutions on stackoverflow1). Irrespective ofthe way volunteers engage in, volunteering is additionally one of thebest places for informal learning [4], i.e., learning outside of traditionaleducational institutions like schools or universities. Informal learningusually results in the attainment of new competences, which are notonly valuable for other VIOs, but can also be used in the labor andeducation market. In order to manage not only the voluntary work tooptimize processes from an economic point of view, but also exploit thepotential of volunteers the need for adequate IT-support arose, leadingto a plethora of volunteer management systems.

1.2 challenges of volunteer managementsystems

A volunteer management system (VMS) brings together volunteersand volunteering opportunities from VIOs and allows for the schedul-ing, allocation and execution of volunteering tasks and projects. Itfurhter provides means for communication and coordination in orderto encourage collaboration [16]. Due to the vast amount of volunteers,already a lot of VMSs emerged [1], often focusing on different goalsand supporting different phases of the volunteering process (e.g. volun-teer acquisition, management or encouragement, etc.) [16]. Unlike theproposed VMS of this thesis, most VMS favor a VIO-centric approach,trying to support VIOs as best as possible by managing their volunteersand tasks with the drawback, that volunteers rarely receive certificationabout tasks they carried out respectively their earned competences.However, if a VMS does allow volunteers to receive certifications, theyrarely have full access over their data since they are stored centrally

1 www.stackoverflow.com

1.2 challenges of volunteer management systems 3

at the VIO, similar to data silos. This raises the problem, that whilevolunteers perform a tremendous amount of work, they get awardednearly nothing that shows their commitment and efforts and due tothe missing interoperability of existing VMSs, their gained knowledgecan rarely be exploited for purposes outside of the VIO, e.g. for jobinterviews. While the challenge of allowing volunteers to better exploittheir competences they earned already represents a major challenge,VMS suffer from much more problems as Kapsammer et al. [16] found:

inhomogeneous conglomerate of resources and tasks As al-ready stated, VMSs try to support VIOs among other things with theallocation of tasks, involving bringing together on the one hand tasks,requiring resources in order to be able to be carried out and on theother hand available resources which have to be allocated for the tasks.Both, available resources and resources a task needs are often highlyinhomogeneous and therefore an allocation between them is far fromtrivial. For human resources, i.e. volunteers, the challenge is the inho-mogeneity between their competences, interests resp. personalities andthe needed competences and qualifications required to carry out tasks.Additionally to human resources, also non-human resources need to beconsidered during the task allocation.

configuration of tasks Tasks have to be able to be split intosmaller ones, thus building a hierarchical task structure. Furthermore,the structural and behavioural relations between tasks have to be consid-ered.

flexible allocation allowing brokerage and negotiation Sincevoluntary work is rarely paid, keeping volunteers motivated is a ne-cessity in order to inspire volunteers for certain tasks and to achieve asustainable level of commitment of them over time. Thus, the matchingbetween a volunteer’s competences as well as interests and tasks playsa key role, especially because exact matching might not suffice. Thus, aflexible kind of brokerage employing different matching strategies, whichnot only focus on the matching but also incorporating some sort ofwell-balanced effort distribution may be beneficial. Further expandingon this idea, instead of either carrying out a task or not, a negotiationbetween VIOs and volunteers could establish a more finely-grainedway of defining the contribution of a volunteer to a task.

adaptation- and motivation-oriented assessment In order toidentify potential improvements of the outcome of voluntary tasks,appropriate assessment mechanisms along the volunteering processare crucial. These mechanisms should not only allow an assessmentby volunteers or the VIO, but also by the beneficiaries of the voluntarywork. Moreover, the assessment should comprise different parts ofthe volunteering, including the task and its outcome, volunteers (e.g.engagement, etc.), allocation of tasks, social aspects or gain of expertise.

continuous evolution The last challenge is to incorporate evolu-tion mechanisms into a VMS, thus, enabling the improvement of the vol-untary process itself by the allowing adaptation of tasks (e.g. extending,

1.3 research project - "cooperative activities (crac)" 4

merging and decomposing of tasks) and resources (e.g. incorporatingachievements).

1.3 research project - "cooperative ac-tivities (crac)"

Cooperative Activities (CrAc) is the predecessor project of iVolunteer,which was funded by the Austrian Research Promotion Agency (FFG;ProjectNr. 845947) under the COIN-program line. The aim of CrAcwas the development of interdisciplinary concepts allowing for dy-namic, profile-based assignments of cooperative tasks to volunteers[3]. Moreover, CrAc focused on continuously adapting tasks and par-ticipants to real conditions by incorporating evaluation criteria andaims at the following three goals [11]. First, the support of dynamic,multi-granular profiles for volunteers as well as for tasks, supported byinformation extraction and ontology learning to structure and fill upthe profiles. Second, intelligent techniques for the matching of tasksto volunteers by regarding similarity measures and spatio-temporalcalculations of the profiles as well as by incorporating balanced taskallocation mechanisms. Last, CrAc should employ crowd-based as-sessment and evolution mechanisms leading to a dynamization of theprofiles and the matching techniques. All of the three goals shouldresult in an increase in the effectiveness of volunteering and stimulatecreative potential within volunteer organizations.

1.4 research project - "ivolunteer"In contrast to its predecessor project CrAc, iVolunteer is centered aroundvolunteers with a focus on how the engagement of volunteers can bedigitized and exploited in a life-long way and proposes a digital plat-form for utilizing formal and informal competences, which are acquiredthrough voluntary engagement (see Fig. 1.1). iVolunteer strives for thefollowing three goals [4]. The first goal is, that volunteers should be ableto oversee and track their volunteering engagement (i.e. their volunteerfootprint), which will be stored in an individual "digital volunteer pass".It should not only consist of the activities that were carried out, butalso list competences a volunteer earned, respectively the feedback theyreceived. The volunteer footprint should allow for the decentralizedstorage at the sole disposal of the volunteer, thus giving the volunteersmore sovereignty and responsibility over their data and therefore di-rectly counteracts the current trend to store data in centralized datasilos. These competences are then used to support further competenceacquisitions and applications at iVolunteer Marketplaces, which repre-sent the second goal of iVolunteer. These iVolunteer Marketplaces bringtogether volunteers and volunteering opportunities by coordinatingoffers and needs between VIOs and volunteers. iVolunteer marketplacesare generally independent of any certain VIO, thus allowing also infor-mal volunteering to take place by incorporating informal volunteers

1.5 problem definition 5

and their help-seeking people directly. Nevertheless, VIOs should alsohave the possibility to participate by operating one or more market-places. Therefore, iVolunteer supports both, formal volunteering foran organization and informal volunteering directly for other persons.The third goal of iVolunteer is to integrate volunteer encouragement bysupporting gamification mechanisms in order to lower entry barriersinto volunteering and maximize life-long engagement.

Figure 1.1: Introduction - iVolunteer Overview [6]

1.5 problem definitionThis thesis is situated in the realm of the iVolunteer project, contribut-ing mainly to the the main research goal of iVolunteer, the iVolunteerMarketplaces including the verification part of the iVolunteer Footprint.In particular, UI-functionalities should be designed, which is focusingon the presentation of the volunteering activities. Furthermore, anotherbig part of this thesis is implementing a proof-of-concept prototype,tackling the functionalities of the multitant and trustable volunteer man-agement system. All in all, the implemented proof-of-concept prototypeshould focus on a small sub-part of the requirements (see Section 2) forthe vision of iVolunteer.The implementation of the proof-of-concept prototype of the volunteersfootprint will be described in more detail in the master thesis of mystudent collegue Philipp Starzer. The overall theoretical conceptual ap-proach of the prototype is described by Markus Weißenbek in his masterthesis [19]. In this thesis UI-functionalities and implementation of amultitant and trustable volunteer management as a proof-of-conceptprototype is described.

1.6 thesis outline 6

1.6 thesis outlineBased on the described vision of iVolunteer and the problem definitiongiven, this thesis is structured as follows. Chapter 2 introduces therequirements of iVolunteer, which further expand on the brief problemdefinition given above. The requirements represents the foundation ofthe functionalities in Chapter 3, the architecture in Chapter 4 and theimplementation in Chapter 5. Finally, in Chapter 6, the future work of theimplementation of the proof-of-concept prototype is discussed.

2 R E Q U I R E M E N T S

Contents2.1 User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Volunteer . . . . . . . . . . . . . . . . . . . . . . . 82.1.2 Help-Seeker . . . . . . . . . . . . . . . . . . . . . . 82.1.3 Marketplace Administrator . . . . . . . . . . . . . 92.1.4 Platform Administrator . . . . . . . . . . . . . . . 9

2.2 Cross-Marketplace Component . . . . . . . . . . . . . . . . 92.2.1 User Management . . . . . . . . . . . . . . . . . . 102.2.2 Multitenancy Management . . . . . . . . . . . . . 102.2.3 Social Management . . . . . . . . . . . . . . . . . 122.2.4 UI Management . . . . . . . . . . . . . . . . . . . 13

2.3 Marketplace Component . . . . . . . . . . . . . . . . . . . 132.3.1 Marketplace Configuration Management . . . . . 142.3.2 Task Management . . . . . . . . . . . . . . . . . . 142.3.3 Competence Management . . . . . . . . . . . . . 172.3.4 Resource Management . . . . . . . . . . . . . . . 182.3.5 Recommendation Management . . . . . . . . . . 19

2.4 Footprint Component . . . . . . . . . . . . . . . . . . . . . 202.4.1 Footprint Verification Management . . . . . . . . 21

In this section, the emerged user roles are presented, followed by adescription of the requirements for each core component of iVolunteer(see Fig. 2.1) - (i) the marketplace component, (ii) the cross-marketplacecomponent and (iii) the footprint component. Within iVolunteer, eachformal resp. informal volunteering organization should operate onededicated marketplace component representing the organization’s mar-ketplace, which coordinates between demand and supply of voluntarywork and performing the bonding between help-seekers and volunteers.The cross-marketplace component represents the central communicationpoint between users and other two components, i.e., the marketplacecomponents and the footprint component. Last, the footprint componentmanages the volunteering footprint by giving volunteers full controlover it while still guaranteeing, that it nevertheless can be verified forcorrectness (i.e. whether the entries of the volunteer footprint can betrusted to be true). Please note, that this chapter is in large parts alsocontained in the master thesis of Markus Weißenbek [19].

7

2.1 user roles 8

Figure 2.1: Use Case Packages

2.1 user rolesWithin iVolunteer, four user roles emerged, representing the differentactors for the use cases presented in the following sections. The userroles within iVolunteer are the (i) volunteer, who carries out tasksmanaged by (ii) help-seekers on the marketplaces. Each marketplacecomponent of iVolunteer is manged by (iii) marketplace administrators,while the cross-marketplace component is operated by the (iv) platformadministrator. In addition to user roles, a permission system should beimplemented enabling a fine-grained configuration of which user isable to perform which functionality.

2.1.1 Volunteer

Within iVolunteer, volunteers play the central role by offering not onlytheir human resources (i.e. time or competences), but also additionalnon-human resources (e.g. tools, vehicles, etc.) in order to help othersby performing tasks mediated on certain marketplaces (see Section 2.3).In order to participate on a marketplace, they must first subscribe tothem, before being able to carry out tasks as described in Section 2.3.2,or synchronizing their volunteer footprint with the marketplace (seeSection 2.4.1).

2.1.2 Help-Seeker

Help-seekers are the counter part to volunteers within iVolunteer. Whilevolunteers carry out voluntary tasks, help-seekers are responsible forcreating and managing them on the marketplace component. Similar to

2.2 cross-marketplace component 9

volunteers, help-seekers must be able to subscribe to marketplaces inorder to operate on them. Furthermore, help-seekers must be able tocreate tasks and manage them (e.g. assign volunteers to tasks, start andfinish tasks; see Section 2.3). Since the management of tasks can be criti-cal and involve disclosed information about participants, organizationsmight want to control, whether help-seekers can freely participate ornot. Especially for formal volunteering, the respective VIO might wantto refrain help-seekers outside of the organization to join. Therefore,iVolunteer supports a mechanisms to allow or disallow help-seekers tojoin, by setting adequate subscription rules, which are further explainedin Section 2.3.1.2.

2.1.3 Marketplace Administrator

The marketplace administrator is responsible for setting up, managingand customizing a marketplace component. The user who initially regis-ters a new marketplace component at the cross-marketplace component willautomatically become its marketplace administrator. Besides choosingthe name and description of the marketplace, marketplace adminis-trators have three other configuration possibilities. First, they mustbe able to set subscription rules (see Section 2.3.1.2) for users, statingwhether users are allowed to subscribe to a marketplace as volunteeror help-seeker. Second, marketplace administrators should be able todefine available task life-cycles (see Section 2.3.2.1), handling how tasksare processed by defining the steps a task goes through the user in-teractions of help-seekers and volunteers that are responsible for thedifferent steps of the task life-cycle. After the marketplace administratorconfigured the desired set of task life-cycles, help-seekers can createtasks attributed with one of these task life-cycles. Third, marketplaceadministrators should be able to configure the set of competences (seeSection 2.3.3) that are needed at the respective marketplace. Not leastsince organizations often not only utilize general-purpose competences(e.g. teamwork), but also employ domain-specific (e.g. Extinguish Fire)or organization-specific ones (e.g. radio course of the Fire Brigade).

2.1.4 Platform Administrator

The platform administrator is responsible for managing the cross-marketplacecomponent and should be able to register new marketplaces at the cross-marketplace component, thereby enabling users to subscribe to them asvolunteers and help-seekers. Furthermore, the platform administratorshould be able to update and delete already existing marketplaces fromthe cross-marketplace component.

2.2 cross-marketplace componentThe cross-marketplace component should represent the central communica-tion point between users and the other two components, i.e. marketplacecomponent as well as the footprint component. The first main requirementof the cross-marketplace component is to handle the different types


of users described in section 2.1, called the user management (see Sect.2.2.1).The second requirement is to establish multitenancy (Sect. 2.2.2)by enabling the registration of new and the management of existingmarketplace components and thereby allowing custom interactionswith their volunteers and organization-specific processes under onecommon platform while still ensuring, that the data of each VIO isseparately stored from each other at the marketplace components. Thethird major requirement besides the multitenancy is, that the cross-marketplace component should manage the social management (Sect.2.2.3) of iVolunteer and thereby allowing users to communicate witheach other across the boundaries of the marketplaces. Finally, the lastrequirement of the cross-marketplace component is to allow users toconfigure their dashboard, which is described by the UI management(Sect. 2.2.4).

2.2.1 User Management

Since iVolunteer should manage personal data of users, especially ofvolunteers and help-seekers, means for authentication need to be inplace to protect unauthorized access to the data. Therefore, all users -volunteers, help-seekers, marketplace administrators and platform ad-ministrators - are required to be logged in before they should be able touse it. Thus an appropriate registration and authentication mechanismhas to be provided. Since iVolunteer is a distributed application, notonly the authentication at the cross-marketplace component has to bemanaged, but also the authentication at the marketplaces. Furthermore,since it would be laborious for users to register respectively authenticateat the cross-marketplace component and all their marketplaces sepa-rately, one common single sign-in authentication should be implemented,which authenticates users at both, the cross-marketplace componentand their marketplaces using only a single registration respectivelylogin. This should minimize the effort for users, subscribed to severalmarketplaces at once. To assure that access to the cross-marketplacecomponent and the marketplace components are authenticated, a se-cure token technology with validation date should be applied, ensuringa platform wide single sign-in authentication.

2.2.2 Multitenancy Management

iVolunteer should support multiple formal and informal volunteeringorganizations independently of each other by allowing them to registerand manage their very own marketplace at the cross-marketplace com-ponent. In order for volunteers and help-seekers to use the marketplaceof a particular organization, they need to subscribe to it and thereby ex-pressing their wish to contribute at that organization. The requirementof multitenancy (see Fig. 2.2) is formulated in the following features:


Figure 2.2: Multitenancy Management Use Cases

• Marketplace RegistrationIn order to be able to use a marketplace within iVolunteer, an orga-nization has to register their marketplace at the cross-marketplacecomponent, thereby publishing the marketplace to volunteersand help-seekers enabling them to subscribe and contribute bycarrying out tasks for the respective organization.

• Marketplace UpdateOnce a marketplace is registered at the cross-marketplace compo-nent, it should be possible to change the details of the marketplacelike name or location.

• Marketplace DeletionIt should be possible to delete registered marketplaces and therebyremoving them from iVolunteer, making it unavailable for vol-unteers and help-seekers to join it anymore. All volunteers andhelp-seekers, that already joined the marketplace beforehand willno longer be able to operate on the marketplace through thecross-marketplace component.

• Search for MarketplaceUsers should be able to search for registered marketplaces byentering keywords, which should be matched against the nameof the marketplace, its respective organization operating the mar-ketplace, the domain of the organization or properties of taskspublished at the marketplace.

• Subscribe to MarketplaceOnce a marketplace is registered at the cross-marketplace com-ponent, volunteers and help-seekers should be able to subscribe.In general, volunteers should be allowed to join every market-place, while help-seekers should only be able to join informalmarketplaces (see Sec. 2.3.1.1).

• Unsubscribe from MarketplaceAfter users joined a marketplace, they of course should be allowedto leave it again, their data (e.g. published competencies) deleted


from the respective marketplace. After they unsubscribed, usersshould no longer be able to access the marketplace (e.g. searchand register for tasks) without subscribing again. Nevertheless,earned achievements (e.g. competences) must still be usable ifthey were synchronized before by utilizing the mechanisms of thefootprint component (see Sec. 2.4).

2.2.3 Social Management

Additionally to multitenancy and thus following the management ofmarketplace components, the cross-marketplace component is also re-sponsible for social management within iVolunteer. Social managementshould provide opportunities to have social relationships of differentusers across multiple marketplaces and therefore represents an essentialcornerstone of iVolunteer since these social relationships are one of themain reasons, why volunteers are actively engaged [17] and is thusof utmost importance in order to keep them motivated. Social man-agement is divided into the following categories - (i) social relationshipmanagement, (ii) social awareness management and (iii) social communica-tion management -, each of them forming an essential requirements foriVolunteer.

2.2.3.1 Social Relationship Management

Social relationship management should consist of mechanisms for mod-elling and integrating social relationships between users (i.e. othervolunteers or help-seekers). The social relationship management shouldat least contain a dedicated friend system as well as an integrationof a group system. The friend system serves as the stepping stone forthe realization of further social interactions (cf. below). In general, thefriend system should either support bi-directional relationships, whereboth users have each other listed as friend or uni-directional relation-ships, where one user can follow another user, without them havingto follow as well. Additionally to friends, groups enable users to builda community together with other selected users. In general, groupsshould be configurable to either be private or public, meaning that themembership to the group is either restricted or not.

2.2.3.2 Social Awareness Management

Social awareness management should be responsible for giving users in-formation (i.e. making them aware) about upcoming events or activities,eventually also of other user’s engagement. In order to achieve aware-ness an activity feed in the form of a timeline should be incorporatedinto iVolunteer. The timeline gives users a chronological history of theirfriend’s activities, posts, upcoming events, earned achievements as wellas information related to their volunteering tasks, like when a task wasfinished. Each entry of the timeline should allow for comments in orderto further social intercourse.

2.3 marketplace component 13

2.2.3.3 Social Communication Management

The social communication management should offer two different commu-nication possibilities among users - user-chat and the group-chat. Whilethe user-chat only allows for the bi-directional chat between two users,the group-chat broadcasts the messages to all participant of the group.

2.2.4 UI Management

The UI management supports users of iVolunteer with additional con-figuration possibilities, when it comes to their user interface. Whilethese configuration possibilities could be numerous, like the selectionof different of fonts, colors, location and size of user interface elements(UI elements), this thesis should focuses on two main configuration op-portunities - (i) the configuration of the dashboard and (ii) the adaptiveuser interface by selecting and deselecting of marketplace activities.The configuration of the dashboard should enabling users to createtheir own user-defined dashboards with their preferred UI elements.Users should be able to select these from a fixed set of UI elementsand freely place them in their preferred location. Furthermore, usersshould be able to create multiple dashboards with different UI elementplacement.The functionality of adaptive user interfaces should allow volunteers tointeract with multiple marketplaces simultaneously without switchingapplications. This allows users to simultaneously access informationabout upcoming marketplace activity through a common user interface.

2.3 marketplace componentThe marketplace component should offer the possibility to coordinatebetween supply and demand for volunteering by employing a highlyconfigurable task management handling volunteering tasks and the al-location of volunteers to tasks. In order to find appropriate tasks forvolunteers and vice versa, a recommendation management is needed,recommending tasks based on the similarity between a volunteer’scompetences and requirements of tasks as well as by considering othervolunteer or task-specific preferences like time or priority. In orderto handle the competences, a competence management is needed, han-dling both, formal and informal competences as well as employingcompetence derivation mechanisms in order for volunteers to receivethese competences based on certain task fulfillments. To further com-plement tasks, a resource management should allow for the managementof human and non-human resources within a VIO, enabling users toclaim resources for the timespan of tasks. Furthermore, as previouslydiscussed, marketplaces should be able to be configurable leading tomarketplace configuration management.


2.3.1 Marketplace Configuration Management

The marketplace configuration management is responsible for allowingmarketplace administrators to configure their marketplace component.In general, the configuration possibilities for marketplaces could benumerous and would therefore go far beyond the scope of this thesis.For this thesis, the marketplace configuration management has twomain responsibilities - (i) the management of the marketplace formalitytype and (ii) the handling of subscription rules.

2.3.1.1 Marketplace Formality Type

As already mentioned, there has to be made a distinction betweenformal and informal volunteering, directly influencing the user struc-ture of a marketplace and the functionality they are able to use. Themain difference between the two types of volunteering is, that formalvolunteering is generally done for a volunteer-involving organizations,while informal volunteering is done for an individual (e.g. helping aneighbour). Since iVolunteer should support both, formal and infor-mal volunteering, appropriate mechanisms are needed to fulfill therequirements for both types of volunteering. In essence, the differenceis, that on marketplaces operated by VIOs - called formal marketplaces- help-seekers are generally employees of the respective VIO, while oninformal marketplaces (i.e. for informal volunteering), anyone shouldbe able to be a help-seeker. Therefore, appropriate mechanisms (i.e. sub-scription rules) are required to restrict the registration of help-seekerson formal marketplaces, while allowing all users to subscribe to aninformal marketplace as both, volunteer and help-seeker.

2.3.1.2 Subscription Rules

In order to not only allow users to subscribe to a marketplace as volun-teer or help-seeker based on the marketplace formality type (i.e. formalor informal marketplace), but to enable marketplace administratorsto adapt the preconditions to subscribe to a marketplace in a morefine-grained way, subscription rules should be introduced. These sub-scription rules should not only restrict access for help-seekers, but alsofor volunteers allowing a marketplace to be publicly accessible or pri-vate for volunteers. For example, the subscription rule could state, thathelp-seekers can only subscribe to a marketplace after they received aninvitation e-mail.

2.3.2 Task Management

The task management (see Fig. 2.3) is responsible for supporting waysto manage and carry out volunteering tasks. Since VIOs have their veryown ways of handling volunteering tasks and their underlying pro-cesses, a highly configurable task management needs to be integratedinto the marketplace component allowing them to realize and integratethese processes within iVolunteer. In the following sections, require-ments regarding task management are presented which are inspired byMundbrod and Reichert [8], [9], resp. [10], starting with the task config-


uration, i.e, how tasks can be adapted to the needs of VIOs, followedup by the incorporation of task templates in order to simplify the taskcreation process and finishing with the functionality to generate tasksand task template from existing tasks and templates in order to simplifythe process of creating tasks and task templates.

Figure 2.3: Task Management Use Cases

2.3.2.1 Task Configuration

Two dimensions of task configuration can be distinguished - (i) intravs. inter and (ii) structural vs. behavioural (see Fig. 2.1). The intraconfiguration comprises all configuration possibilities of a single task,while the inter configuration covers configuration possibilities of a setof tasks. A structural configuration includes the change of the structureof one task or the structure of a set of tasks, while a behaviouralconfiguration means a change of the execution of a single task or a setof tasks.

Intra InterStructure Task Properties Structural Task Relationships

Behaviour Task Life-Cycle Configuration Behavioural Task Relationships

Table 2.1: Task Configuration Overview

Because of these two dimensions, four possible variations of task con-figurations emerge:

• Task PropertiesIt should be possible, that tasks can be adaptable w.r.t their in-ternal structure, i.e., their properties. There should be a basic setof properties available for each task, e.g., name, description starttime or end time. Furthermore, it should be possible to add addi-tional properties to tasks. An example for additional propertieswould be whether a driver’s license is required or not. In orderto make these properties as adjustable as possible, not only thename of properties should be customizable, but also its respective


value type, e.g., boolean, floating point number or character string.Task properties should be used as a basis to look for appropriatevolunteers, resp. volunteers can find appropriate tasks accordingto these properties.

• Task Life-Cycle ConfigurationThe main requirement for the intra-task configuration besides taskproperties is to manage how tasks are processed and executed,called configuration of the task life-cycle [8]. Task life-cycles areenforced by task workflows, which control the states a task runsthrough and evaluate which actions are available at each pointin the workflow. A task workflow is a graph consisting of statesand transitions, depicting the states a task can reach and thetransitions in-between. A set of pre-defined states and transitionsshould be available, including create task, publish task, assign task,finish task. Furthermore, there should be a possibility to definenew custom states and transitions in order to support the differentvolunteering task processes of VIOs. A task life-cycle should alsobe able to incorporate the sequential and parallel execution ofthese pre-defined and user-defined states.

• Structural Task RelationshipsiVolunteer should incorporate structural task relationships, whichdeal with combining tasks together and forming compositionsof tasks. In general, hierarchical structures are desirable, sincethey can depict task compositions with a parent-child relationship.Hierarchically structured tasks form a tree, where the root-taskis often times the overarching project the tasks belong to, inter-mediate nodes are grouping tasks, and leaves are workables, i.e.,executable tasks.

• Behavioral Task RelationshipsLast, behavioral task relationship should be incorporated, relatingto modelling behavioral interdependencies between tasks. Forexample, one task has to be performed before another can start(i.e. temporal relationship), which can be necessary due to datadependencies (the result of one task is the prerequisite of another)[5].

2.3.2.2 Task Templates

Task templates serve as templates for tasks, in order to quickly createrecurring tasks. Similar to tasks, task templates also comprise intra-task configuration possibilities, i.e., (i) task properties and (ii) life-cycleconfiguration, but do not have any inter-task configuration possibilities,because they are neither structurally nor behaviourally dependent uponother task templates or tasks.

2.3.2.3 Task & Task Template Generation

It should not only be possible to generate tasks from task templates, butrather both, tasks and task templates, should be able to be generatedfrom existing tasks as well as from task templates. In both cases, the


existing intra-task configuration, i.e., task properties and task life-cycleconfiguration should be taken over to the generated task and tasktemplate.

2.3.3 Competence Management

As already stated in Chapter 1, volunteering is regarded as a uniqueopportunity for informal learning thereby supporting the acquisitionof new competences respectively the refinement of already acquiredones. Thus, not only formal competences acquired through educationand training courses, but also informal ones acquired through fulfill-ing volunteering tasks and working in a volunteering team should beintegrated into iVolunteer. It has to be emphasized that competenceswithin iVolunteer should not only be usable at one specific marketplace,but rather volunteers should be able to transfer the competences fromone marketplace to other ones and utilize them there as well. Thisrequirement is further described in Section 2.4. The competence man-agement (see Fig. 2.4) of the marketplace component should implementthe following use-cases:

Figure 2.4: Competence Management Use Cases

• Manage available competencesThe marketplace component should come with a pre-defined set ofcompetences used within iVolunteer, which should be based onalready existing competence models and ontologies. A marketplaceadministrator should be able to adapt these existing competences(e.g. adapt possible proficiency levels) as well as create new ones.This is especially necessary, because there exist many domain-specific or organization-specific competences which VIOs shouldbe able to incorporate into iVolunteer.

• Manage Profiling MechanismThe marketplace administrator should be able to change the profil-ing mechanism, deciding how competences are awarded or takenaway. The profiling mechanism should be adaptable from simplerules with pre-conditions, which have to be fulfilled in order toreceive the competence, to fully-fledged machine-learning algo-rithms, which learned how these competences should be awarded.This mechanism should not only be available for formal compe-


tences, but also for informal ones, for which the definition of thepre-conditions are much harder to grasp. For example, whichqualification is enough to decide whether a volunteer receives thecompetence "team player".

• Update CompetencesGenerally, there should be two ways volunteers can update theircompetences, i.e., receive new competences, change existing com-petences (e.g. reaching a higher proficiency level) as well as losealready acquired ones. An example where volunteers could losecompetences is in the domain of paramedics of the Red Cross,requiring them to have to recertify their defibrillator usage eachyear.The first way, how volunteers should be able to update their com-petences is, that they should be able to develop them based ontheir execution of volunteering tasks as well as on interactionswithin iVolunteer (i.e. with other volunteers and help-seekers).The second way to update the competences is to get credited foralready existing competences acquired from other organizationslike schools, jobs or other VIOs. Therefore, adequate mechanismsare needed for volunteers to be able to obtain these competencesby showing ample qualification certificates from these other or-ganizations, e.g., a driver’s license. The update of competencesshould be done automatically by the respective profiling mecha-nism, deciding whether volunteers receive or lose competences.

2.3.4 Resource Management

Another major requirement of the marketplace component closely cou-pled with task management is resource management (see Fig. 2.5), al-lowing for the management of resources contributed by the VIO andits volunteers. These resources can be claimed and used during theexecution of tasks. Resources can be distinguished into two types -human and non-human resources -, both of which should be usablewithin iVolunteer. Human resources generally refer to the time andcompetences volunteers contribute, while non-human resources canbe any objects brought in by the VIO or the volunteers, which willbe utilized throughout the execution of the respective volunteer task.Examples for non-human resources are chairs or benches, which canbe provided for a certain task. The resource management contains thefollowing use-cases:


Figure 2.5: Resource Management Use Cases

• Manage ResourceIt should be possible to add human and non-human resourcesto the marketplace component. Each resource should containat least properties describing name, type (i.e. human or non-human resource) and owner. Furthermore, concepts regarding theavailability of resources should be considered, especially becausenon-human resources often can only be used by one task at thesame time. After a resource was created within iVolunteer, theowner of the resource should be able to change or remove it.

• Append Resource to TaskAfter resources are integrated into iVolunteer, it should also beable to append them to tasks and therefore claiming them for thedefined time period of the task. It should not be possible to claima resource twice at the same time, except when the resource isexplicitly defined to be usable concurrently by several tasks (e.g.software).

• Append Resource to Task TemplateFurthermore, it should be possible to append resources to tasktemplates. This process should be identically to the appending ofa resource to a task, except that the availability of the resources isnot needed to be considered, because task templates do not claimthe resource.

2.3.5 Recommendation Management

In order to achieve better coordination between demand and supply ofvoluntary work, a recommendation mechanism (see Fig. 2.6) on basisof a volunteer’s competences and a task’s requirements is required.Additionally to the competences of volunteers and requirements oftasks, further circumstances like the volunteer’s temporal and spatialconstraints w.r.t. the task should be taken into consideration. This wouldallow for a better fit between task and volunteers and therefore may

2.4 footprint component 20

increase the volunteer’s motivation and contribution. There should betwo ways to receive task recommendations - (i) recommendations fromthe matching algorithm of iVolunteer and (ii) task suggestions fromother users within iVolunteer.

Figure 2.6: Recommendation Management Use Cases

• Receive RecommendationIn the first use-case of recommendation management, volunteersshould receive task recommendation based on their competencesand preferences matched against the requirements of tasks. Inorder to find appropriate fits between tasks and volunteers, match-ing algorithms of recommender systems should be employed, ad-ditionally incorporate interests of volunteers, as well as temporaland spatial information of both, volunteers and tasks.

• Receive SuggestionAdditionally, to receive recommendations from the iVolunteerplatform, it should also be possible for volunteers to receivesuggestions from other users, i.e., other volunteers or help-seekers.These suggestions could range from last-minute requests fromhelp-seekers, because they quickly need another volunteer for acertain task to friends suggesting tasks to each other in order tocarry them out together.

• Suggest TaskIn order for volunteers to receive suggestions in the first place, itmust be possible for users to suggest tasks to them.

2.4 footprint componentThe footprint component should be responsible for allowing volunteersand marketplaces to utilize the volunteer footprint, which should keeptrack of each actions carried out by a volunteer and can range from tasksthey contributed to, earned competences and accomplished achieve-ments to feedback they received from other volunteers and the respec-tive help-seekers involved in the task, e.g., how well volunteers carried


out the task, respectively how well they integrated into the team. Thus,the footprint represents a way to empower volunteers by allowingthem to automatically track their volunteering activities in terms of anindividual digital volunteering pass [6]. Examples of what a volunteerfootprint can comprise are (i) all tasks a volunteer carried out, (ii) allformal and informal competences they acquired, (iii) their feedback aswell as feedback they receive (e.g. feedback regarding tasks, projects,etc.) and (iv) social interactions they have with other volunteers orhelp-seekers. Typically in VMSs, volunteer footprints are stored digi-tally at large data centers leading to huge data silos and users, whichoften don’t know what information is stored about them. To counteractthis trend of data centralization and privacy infringements, iVolunteershould store the volunteer footprints decentralized for the exclusivedisposal of the volunteer in the so called local repository. Since volunteersare empowered by this decentralization and could therefore alter theirvolunteer footprint at will, appropriate verification mechanisms shouldbe implemented. The footprint component is therefore divided intotwo packages - (i) the footprint verification management, responsible forverifying footprint entries and the footprint synchronization management,covering the synchronization mechanisms between marketplaces andvolunteers.

2.4.1 Footprint Verification Management

The footprint verification management should provide mechanisms toverify volunteer footprint entries and check whether they are validor not. The verification is needed, because due to the empowermentof volunteers to have full leverage over their data, still a verificationmethod is needed in order to detect, whether the footprint entriesprovided by volunteers to a marketplace are valid. For example, volun-teers could append additional competences in their volunteer footprint,which must be detected, because otherwise no marketplace could trustthe footprint of volunteers, thus rendering the volunteer footprintsuseless. The footprint verification management therefore should havetwo main focal points - (i) the warranty to store each footprint entryat a trusted place besides the local repository of volunteers and (ii)using this second storage of the footprint entries for the verification offootprint entries from the local repository. The second storage of thefootprint entries should mainly be used for the verification of footprintentries and will therefore be called verification storage from now on. Theverification storage has to have the following two characteristics - (i)trustability, (ii) immutability - and has to enforce the (iii) verifiability and(iv) information obfuscation of footprint entries.

2.4.1.1 Trustability

As described earlier, the verification storage should be used for verifica-tion of footprint entries, thus establishing trust between volunteers andmarketplaces whenever volunteers try to synchronize footprint entries(e.g. acquired competences) with marketplaces. In order to establishthis trust, not only the verification mechanism, but also the verifica-


tion storage itself has to be trusted, otherwise the whole verificationmechanism could not be trusted at all.

2.4.1.2 Immutability

The verification storage must guarantee the immutability of all con-tained footprint entries, i.e., it should not be possible to change anentry once it exists in the verification storage, additionally to its storagewithin the local repository. By forcing immutability of the footprintentries, the verification mechanism can be assured, that the footprintentries of the verification storage can be trusted to be true and thereforeachieves a similar goal than the previously described characteristictrustability. The main difference between them is, that immutabilityguarantees, that existing footprint entries are not changed, while trusta-bility assures that no new footprint entries are added to the verificationstorage, that are valid.

2.4.1.3 Information Obfuscation

Since the volunteer footprint, which contains critical personal infor-mation about volunteers is stored in the verification storage, adequatemeasures to save and protect the data from unauthorized access haveto be implemented. But rather than authorizing, which informationcan be accessed by which user of the verification storage, obfuscationmechanisms should be applied, while still guaranteeing verifiability (cf.below).

2.4.1.4 Verifiability

Since the verification storage is mainly used to verify, whether footprintentries from the local repository of volunteers are valid or not, it hasto guarantee, that the verification mechanism can be applied to itsentries, even though the previously explained information obfuscationcharacteristic will make the entries unreadable. In order to achieve both,information obfuscation and verifiability, one-way hashing algorithmsshould be applied to the entries of the verification storage to obfuscatethem. In order to verify footprint entries from the local repository, theyhave to be hashed with the same algorithm and compared with entriesfrom the verification storage. If an entry in the verification storage canbe found, the respective footprint entry of the local repository is valid,respectively invalid, if the comparison is without result.

3 F U N C T I O N A L I TY

Contents3.1 Cross-Cutting Functionalities . . . . . . . . . . . . . . . . . 23

3.1.1 Login . . . . . . . . . . . . . . . . . . . . . . . . . 243.1.2 Logout . . . . . . . . . . . . . . . . . . . . . . . . . 243.1.3 Start Page . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Volunteer Functionalities . . . . . . . . . . . . . . . . . . . 253.2.1 Dashboard . . . . . . . . . . . . . . . . . . . . . . 263.2.2 Your Profile . . . . . . . . . . . . . . . . . . . . . . 303.2.3 Your Engagement . . . . . . . . . . . . . . . . . . 313.2.4 Your Achievements . . . . . . . . . . . . . . . . . 333.2.5 Get Engaged . . . . . . . . . . . . . . . . . . . . . 353.2.6 Get Connected . . . . . . . . . . . . . . . . . . . . 373.2.7 Task Details . . . . . . . . . . . . . . . . . . . . . . 37

3.3 Help Seeker Functionalities . . . . . . . . . . . . . . . . . . 383.3.1 Project List . . . . . . . . . . . . . . . . . . . . . . 393.3.2 Project Form . . . . . . . . . . . . . . . . . . . . . 393.3.3 Task List . . . . . . . . . . . . . . . . . . . . . . . . 403.3.4 Task Form . . . . . . . . . . . . . . . . . . . . . . . 403.3.5 Task Details . . . . . . . . . . . . . . . . . . . . . . 413.3.6 Task-Template List . . . . . . . . . . . . . . . . . . 423.3.7 Task-Template Form . . . . . . . . . . . . . . . . . 42

3.4 Platform Administrator Functionalities . . . . . . . . . . . 423.4.1 Marketplace List . . . . . . . . . . . . . . . . . . . 433.4.2 Marketplace Form . . . . . . . . . . . . . . . . . . 43

In this section describes all user interface functionality of iVolunteer, asstated in the requirements (see chapter 2).In general, the user interface functionality is implemented as an Angu-lar client, which is running on a browser of the user’s device, using theAPI (=application programming interface, described in Chapter 5) ofthe components based on our architecture (described in 4).The user interface (UI) is split into three categories - (i) volunteers,(ii) help-seekers and (iii) the platform administrator, according to theuser-roles described in section 2.1. The login and logout functionalityfor all three user roles is the same, but after a successful login, the avail-able UI views differ as described in the following sections. Therefore,the functionalities are split into the following four parts - (i) cross-cutting functionalities, (ii) volunteer functionalities, (iii) help-seekerfunctionalities and (iv) platform administrator functionalities.

3.1 cross-cutting functionalitiesThe cross-cutting functionalities of iVolunteer are those that are neededby all users independent of their role, which are (i) login, (ii) logout

23

3.1 cross-cutting functionalities 24

and (iii) the start page, which is linked as first page after a successfullogin into the application.

3.1.1 Login

To use iVolunteer, all users have to login into the application (seeFigure 3.1) by using their respective credentials (i.e., username andpassword). If the credentials are correct, the user will be redirected totheir respective dashboard, according to their role. Otherwise, the userstays at the login-page, and an error message is displayed.

Figure 3.1: Cross-Cutting - Login

If the login was successful, the cross-marketplace component gener-ates a JSON Web Token1 with a validation timeframe of 10 days andstores it for future usage in the Web Storage of the browser. This Webstorage allows us to store simple key/value data in the browser . Thefunctionalities of such an web storage is similar to cookies, but canstore greater amounts of. That enables the user to skip a renewed loginas long as the token is valid (i.e., 10 days) [2].

3.1.2 Logout

The logout is used to exit the iVolunteer application. The user is redi-rected to the login page and has to login again. Within iVolunteer, thereare two ways to log out - (i) explicitly via the logout button (see Figure3.2), where the token is deleted and (ii) implicitly via the timeout of thesession (i.e., the validation timeframe of the token is expired).

1 https://jwt.io/

3.2 volunteer functionalities 25

Figure 3.2: Cross-Cutting - Logout

3.1.3 Start Page

The start page is linked as the first page in the navigation flow. Thismeans that every user will be redirected to the start page after suc-cessful login. The start page includes two main functionalities, whichare available for all users - (i) the navigation menu and (ii) the mar-ketplace menu - shown in Figure 3.3. While the navigation menu in(1) is different for all user roles, the marketplace menu is only neededfor volunteers. Therefore, the marketplace chips in (2) represent allavailable marketplaces for a volunteer. Each chip represent a subscribedmarketplaces of a volunteer. By clicking on those chip, each of themarketplaces can be selected and deselected. All of the six pages willaggregate the displayed information (e.g. available tasks, currently run-ning tasks, achievements) according to the chosen marketplaces. Forexample, if a volunteer wants to see the currently running tasks, thenan aggregated list of all of the running tasks of the selected market-places is displayed. This mechanism implements the requirement of theaggregated view described in section 2.2.4.

Figure 3.3: Cross-Cutting - Start Screen

3.2 volunteer functionalitiesThe user interface for the volunteer is the most sophisticated regardingall three roles and is divided into six pages - (i) dashboard, (ii) your profile,(iii) your engagements, (iv) your achievements, (v) get engaged and (vi) get


connected. We fully implemented the task management as describedin section 2.3.2, which can be seen in the pages your engagements, yourachievements, get engaged, where your engagements gives an overview ofall currently running tasks, your achievements includes finished tasksand get engaged handles tasks, for which the volunteer can participate in.In addition, we fully implemented the page dashboard and get connectedcover parts of the social aspect. Currently, the requirements of the socialaspect are only implemented as UI-prototype, without having an APIImplementation. This is mainly relevant for the pages your profile andget connected.

The full navigation flow is displayed in Figure 3.4 and shows, that allof the six pages are accessible after the login was successful and oncethe volunteer logs out, the navigation flow ends and can be startedagain after another login.

Figure 3.4: Volunteer - Navigation Flow

3.2.1 Dashboard

The dashboard (="What’s Up") functionality is included in the start page(see Section 3.1.3) for volunteers. This is realised as a prototype. Thatmeans that the goal of this part of the master thesis was to provideimplementation possibilities for an adaptive and multitenant user inter-face. Therefore the implementation of dashlets is limited. More detailsare described in Section 6.1.For better classification of the functionality, the functionality dividesinto two modes. The first mode is the Presentation Mode, the secondmode is the Configuration Mode. Within the presentation mode, thedashboard with their dashlets is rendered. In the configuration mode,volunteers can manage, adapt and configure their dashlet (= widget,custom view-element), also the resize and positioning opportunitiesare available.


3.2.1.1 Presentation Mode

Within the Presentation Mode (see Figure 3.5), the dashboard and allincluded dashlets are loaded and rendered. This figure visualizes the (i)timeline, (ii) timeline activities and (iii) project members dashlets (seesection 3.2.1.3).The red boxes in the figure visualize special functionalities, which areaccessible for each volunteer.

• In (1) the presentation mode of the dashboard with the threeloaded dashlets are defined.

• The box (2) displays a toggle button, where the volunteer canenter the configuration mode.

Figure 3.5: Volunteer - Dashboard - Presentation Mode

While the volunteer has entered the presentation mode, the dashletsare rendered. Therefore a configuration of them is not possible. Withineach dashlet, volunteers can scroll up and down to see the full contentof the dashlets. That is necessary, because of the visualization of theentire content of the dashlet.

3.2.1.2 Configuration Mode

In the configuration mode, volunteers can manage, configure and adaptthe dashboard and their containing dashlets.The core idea behind the configuration mode is to offer the volunteer thepossibility to rearrange each view element at their desired position onthe dashboard. For better visualization of the configuration mode, thedashboard background renders grid lines signalling that the dashboardlayout can change. The six functionalities of the configuration mode(see Figure 3.6) are:

• In (1), the visualization of a dashlet is displayed. In opposite tothe presentation mode, the grid lines show that volunteers canrearrange these dashlets and support them on positioning andresizing of a dashlet.

• In (2) the dashboard’s name input field is displayed.


• The button in (3) opens the dashboard selection dialog (see Figure3.7). Within the dialog a volunteer can add new dashlets into thecurrent dashboard visualization.

• The button in (4) saves the dashboard and switches to the presen-tation mode.

• The button in (5) deletes the dashboard and switches to thepresentation mode of a new dashboard.

• In (6a) the settings - button of an dashlet is displayed. After click-ing the button, the settings - menu in (6b) is opened.

Figure 3.6: Volunteer - Dashboard - Configuration Mode

Figure 3.7: Volunteer - Dashboard - Configuration Dialog

3.2.1.3 Dashlet

In general, dashlets are small, placeable visualisations of differentfunctionalities of iVolunteer. Within the dashboard functionality, thereexist four dashlets - (i) Project Members, (ii) Timeline, (iii) TimelineActivities and (iv) Timeline Tasks. Figures 3.8 and 3.9. Each dashletshould summaries the content of the upcomming functionalities.


Figure 3.8: Volunteer - Dashboard - Dashlet Timeline Activities, Project Membersand Timeline

Figure 3.9: Volunteer - Dashboard - Dashlet Timeline Tasks

project members The dashlet project members shown in Figure 3.8,provides an overview of the top recently collaborating volunteers. Dueto the requirement social management (see Section 2.2.3), the profile pic-tures of the volunteers are linked to the volunteers profile (see Section3.2.2). The dashlet’s content provides the same information as the contri-butions-tab of the your engagements-page and the your achievements-page(see Section 3.2.3 and 3.2.4).

timeline The dashlet timeline shown in Figure 3.8 is a UI-prototypeimplementation of a timeline. The timeline is a time-ordered overviewabout posts, comments and the social relationships.Within iVolunteer’s timeline, volunteers are allowed to post statusupdates as important milestones of task engagements, videos andpictures of the voluntary work. Depending on the settings, the timelineinteractions of volunteer’s friends may be visible to the volunteer (seeSection 3.2.6).


timeline activities Similar to the timeline, the dashlet timeline ac-tivities (displayed in figure 3.9) is a short summary of the last timelineactivities of the volunteer’s friends. Both dashlets renders the inter-actions of the volunteer’s friends. The purpose of this dashlet is tomotivate other volunteers to get engaged.

timeline tasks The dashlet for the timeline tasks, tasks of the selectedmarketplaces are displayed in a list form. This dashlet is the onlydashlet, which is customizable via the settings menu, and means thatthe dashlet (see Figure 3.9) includes settings, which allows a volunteerto view only (i) available tasks, (ii) engaged tasks, (iii) finish tasks or(iv) all tasks of a selected marketplace.

Available Tasks Available tasks are all those tasks which have beenpublished, and the volunteers can register.

Engaged Tasks An engaged task denotes either a published taskwhere a volunteer already has reserved for, or a published task wherea volunteer was assigned to, or a running task where the respectiveuser is part of. In other words, engaging tasks are all those not finishedtasks where a volunteer is in any way involved in.

Finished Tasks Finished task are tasks which have been marked asfinished by help seekers.

3.2.2 Your Profile

The page your profile manages the personal information (name, address,photo, friends etc.) about a volunteer on the selected marketplaces.The mentioned functionalities are divided into four tabs - (i) about meand (ii) friends. The first two tabs will be described in the followingsections.

3.2.2.1 About Me

The about me-page is displayed when a user opens the your profile-pageand shows personal information about the user as shown in Figure3.10.


Figure 3.10: Volunteer - Your Profile - About Me

3.2.2.2 Friends

The second tab of the your profile-page shows other users with whichthe user is a friend, as well as groups the user is participating in asdisplayed in Figure 3.11.

Figure 3.11: Volunteer - Your Profile - Friends

3.2.3 Your Engagement

The page your engagement shows all subscribed marketplaces, currentlyrunning tasks and projects, a volunteer participates in, as well as all per-sons they collaborate with and the non-human resources they contributeto. This page is split into three tabs - (i) opportunities, (ii) collaborationsand (iii) contributions, which will be described in the following sections.

3.2.3.1 Opportunities

The tab opportunities (see Figure 3.12) displays currently running projectsand tasks (see (1) in Figure 3.12) a volunteer is engaged with, as well assubscribed marketplaces (see (2) in Figure 3.12). In area (1), all tasks are


grouped together by their respective project. For each task, its detailscan be viewed by clicking on details of their respective menu whichopens, when clicked on the three vertical dots. In area (2) a volunteercan not only see subscribed marketplaces but can also decide to unsub-scribe from them by clicking leave, in the menu of the marketplace.

Figure 3.12: Volunteer - Your Engagements - Opportunities

3.2.3.2 Collaborations

In the tab collaborations (see Figure 3.13), all volunteers your are cur-rently engaged with in the same projects are displayed. As alreadymentioned, there exists no backend implementation for the social rela-tionship management and therefore, this view is only a UI-prototype.

Figure 3.13: Volunteer - Your Engagements - Collaborations

3.2.3.3 Contributions

In the final tab of your engagements - contributions - all human resources(i.e., hours of volunteering) and non-human ones (e.g. paper cups


needed for the serving of drinks, clothing, etc.) a volunteer contributesto all currently running projects and their tasks are listed (see Figure3.14). Not only the own contributions are displayed, but also those fromfriends and other volunteers participating in the same projects. SinceiVolunteer currently does not support non-human resources, this pageis only a UI-prototype.

Figure 3.14: Volunteer - Your Engagements - Contributions

3.2.4 Your Achievements

The page your achievements displays all finished engagements (i.e., fin-ished projects and tasks) and tries to show insights by means of vi-sualizing the data. For example the hours worked in a given period(e.g. last week/month/year). Similar to the page your engagements, thispage is divided into four tabs - (i) opportunities, (ii) collaborations, (iii)contributions and (iv) encouragements, which will be described in thefollowing sections.

3.2.4.1 Opportunities

The tab opportunities shows projects and tasks for the selected mar-ketplaces (see (1) in Figure 3.15), which are finished and where thevolunteer participated in (see (2) resp. (3)). Additionally, a summaryof important statistics is displayed in area (4), showing (i) the numberof subscribed marketplaces as well as (ii) projects and (iii) tasks thevolunteer participated in. The bottom two stats display the number of(iv) likes and an (v) average value of the volunteer’s rating. The last twostats are only implemented as UI-prototype since iVolunteer currentlydoes not contain any feedback mechanisms (like/rating) for volunteers.


Figure 3.15: Volunteer - Your Achievements - Opportunities

3.2.4.2 Collaborations

The tab collaborations shows friends and other volunteers a volunteercooperated with in finished projects and tasks as displayed in Figure3.16.

Figure 3.16: Volunteer - Your Achievement - Collaborations

3.2.4.3 Contributions

Similar to the contributions-tab of the your engagements-page, it showsthe human and non-human resources contributed to finished projectsand tasks as displayed in Figure 3.17.


Figure 3.17: Volunteer - Your Achievement - Contributions

3.2.4.4 Encouragements

The encouragements-tab displays earned achievements like badges (see(1) in Figure 3.18) or competences (see (2)).

Figure 3.18: Volunteer - Your Achievement - Encouragement

3.2.5 Get Engaged

The page get engaged is the third and last page of the implementedtask management and displays opportunities which a volunteer canparticipate in. Furthermore, it gives volunteers the possibility to searchand filter for opportunities as well as to receive suggestions from friends.The matching of tasks to volunteers would go beyond the scope of thisthesis, but other publications (like [15]) did already propose a match-making process as well as discussed challenges and caveats. This pageis split into four tabs - (i) recommendations, (ii) suggestions and (iii) search,which will be described in the following sections.

3.2.5.1 Recommendations

The tab recommendations displays opportunities recommended by theiVolunteer application and is split into two areas. While area (1) in


Figure 3.19 shows projects and tasks, which a volunteer can participatein, area (2) displays available marketplaces, which can be subscribed to.

Figure 3.19: Volunteer - Get Engaged - Recommendations

3.2.5.2 Suggestions

Similar to the tab recommendations, which are opportunities recommendby the iVolunteer Application, the tab suggestions is focusing on sug-gestions from other friendly volunteers. Figure 3.20 displays in area (1)suggested projects and tasks and in area (2) suggested marketplaces.

Figure 3.20: Volunteer - Get Engaged - Suggestions

3.2.5.3 Search

In the tab search, volunteers are able to search for interested projectsand tasks as marketplaces (see Figure 3.21).


Figure 3.21: Volunteer - Get Engaged - Search

3.2.6 Get Connected

The page get connected is focusing, as the page get engaged, on futureinteractions. The main focus is to build connections between volunteers.While area (1) in Figure 3.22 shows recommended friends by the iVol-unteer Application, which a volunteer can connect to, area (2) displaysrecently connected friends. In area (3), opportunities for group connec-tions are displayed. Besides, each volunteer’s profile image in area (1),(2) and (3) is linked to the public profile page of the selected volunteer.

Figure 3.22: Volunteer - Get Connected

3.2.7 Task Details

The page task details is reachable after selecting a task of a project onthe pages (i) your engagements, (ii) your achievements or (iii) get engaged.For better clarification, this pages is divide into three parts - (1) the taskdescription, (2) the task interactions and (3) the task workflow control(all areas are displayed in Figure 3.23).

3.3 help seeker functionalities 38

Figure 3.23: Volunteer - Task Detail

(1) task description In this area of this page, all information (e.g.name, description, start date, and end date, ect.) about the selected taskare displayed. Besides, the required and acquirable competencies arelisted.

(2) task interactions In this area, all task interactions of the selectedtask are displayed. This area should provide the volunteer information’sabout the co-worker and potential contributors etc.

(3) task workflow control This area represents the task workflowcontrol. Dependent on the status of the task (3) this area changes. E.g ifthe task was started, a button to finish the task is present. While if thetask is published, a volunteer has the opportunity to reserve for thistask. More about the task-workflow is described in Section 5.3.3.

3.3 help seeker functionalitiesThe user interface of the help seeker is divided into four main pages- (i) start page, (ii) project list including the project form, (iii) task list in-cluding the task form and task details, (iv) task-template list including thetask-template form. All pages are fully implemented. The page start pageis a blank page, so this page is not included in the upcoming sections.The full navigation flow is displayed in Figure 3.24 and shows, thatall of the four main pages are accessible after the login was successfuland once the volunteer logs out, the navigation flow ends and can bestarted again after another login.


Figure 3.24: Help Seeker - Navigation Flow

3.3.1 Project List

The page project list is used by a help seeker to list all projects of amarketplace (shown in area (1) of Figure 3.25). While the edit-button inarea (1) edits a selected project, the add-button in area (2) creates a newproject. Both buttons uses the page project form to perform the creationor edit process.Projects are part of the task management. Depending of their task status,a project is displayed in the volunteer’s page (i) your engagements, (ii)your achievements and (iii) get engaged.

Figure 3.25: Help Seeker - Project List

3.3.2 Project Form

The page project form allows to create or edit a project (shown in Figure3.26). These projects are created or edited by help seekers only and arenon-executable elements, their purpose is a grouping of tasks only.Therefore volunteers are not able, for example, to reserve for projects,but only for tasks, which belong to a certain project. Created or modifiedprojects are stored in the respective marketplace database. Once created,no properties of projects are editable anymore since this would confusevolunteers, because the description of the project could have changedand the volunteer, therefore, does no longer agree.


Figure 3.26: Help Seeker - Project Form

3.3.3 Task List

The page task list is the second page and the most used page for a helpseeker. In opposite to the grouping object, the project, a task is the onlyexecutable instance in our marketplace workflow component.Analogous to the page project list, area (1) of Figure 3.27 displays anoverview of all tasks, which are created on this marketplace. Differentto the previous page, area (1) does not contain an edit-button to selecta task for editing. For this action, a help seeker has to select a table row,which allows to navigate to the page task details. Area (2) displays anadd-button to create a task via the page task form.

Figure 3.27: Help Seeker - Task List

3.3.4 Task Form

On the page task form, help seekers are creating and editing tasks. Acreated or edited task is stored in the respective marketplace database.A volunteer is not able to see the created or edited task; for this, thetask creator has to publish the task first.Area (2) in Figure 3.28 visualizes the form of a task. To support helpseekers in the creation of new tasks, a help seeker can fill up theproperties of the task with a selected task-template (see area (1)). Laterthe properties are adaptable in the form.The properties of tasks are only editable as long as the task was notpublished by a help seeker, because before publishing, the task is notyet visible to volunteers. As soon as the task is published, no changes


are possible anymore. That is because the hash of any published taskis written into the blockchain for later verification purposes, so thevolunteers can be sure that no secret changes happen, date changesor even worse, the change of requirable or acquirable competences.Any change would lead to a different hash and would therefore bedetectable. A detailed description of the task workflow implementationis provided in Section 5.3.3.

Figure 3.28: Help Seeker - Task Form

3.3.5 Task Details

The page task details for help seeker is reachable after selecting a taskon page task list. Similar to the page task details for volunteers, in area(1) of this page, all pieces of information (e.g name, description, startdate, and end date) about the selected task are displayed and area (2) inFigure 3.29 displays the timeline about all task interactions. Also, area(3) displays the current task-workflow step of the task, which changesdepending on the status of the task. As previously mentioned, theediting of a task is available on clicking the edit-button in area (4).

Figure 3.29: Help Seeker - Task Detail

3.4 platform administrator functionalities 42

3.3.6 Task-Template List

The last page task-template list displays all task-templates available onthe respective marketplace (shown in area (1) of Figure 3.30). Similar tothe other help seeker functionalities, area (2) presents the add-buttonto create a new task-template.

Figure 3.30: Help Seeker - Task-Template List

3.3.7 Task-Template Form

In general, a task-template is a pattern to create multiple tasks withthe same or adapted base information. Therefore the page task-templateform provides the functionality to create and edit a task-template. Acreated or edited task-template is stored in the respective marketplacedatabase.

Figure 3.31: Help Seeker - Task Template Form

3.4 platform administrator functional-ities

The user interface for the platform administrator (= administrator) con-tains only one main functionality, which is available on the page market-place list including marketplace form. Due to the requirement multitenancy(described in Section 2.2.2), a platform administrator is marketplaceindependent. That means, the administrator is responsible to registernew marketplaces. Furthermore, the administrator is allowed to updateand delete already existing marketplaces. Therefore the administrator


has to be neutral and not assigned to a volunteering organisation.All pages are fully implemented. The page start page is a blank page, sothis page is not included in the upcoming sections.

The full navigation flow is displayed in Figure 3.32 and shows, thatanalogous to the volunteer and help seeker the administrator has tologin first and once the administrator logs out, the navigation flow endsand can be started again after another login.

Figure 3.32: Platform Administrator - Navigation Flow

3.4.1 Marketplace List

The page marketplace list displays an overview about all marketplaceson the platform (see (1) in Figure 3.33), on which the administratoroperates. Only the platform administrator is able to create and edit amarketplace. Therefore the platform administrator uses the edit-buttonin area (1) and for the creation of a marketplace, the administrator usesthe add-button, which is shown in area (2). Both actions navigate to thepage marketplace form.

Figure 3.33: Platform Administrator - Marketplace List

3.4.2 Marketplace Form

The page marketplace form allows to create or edit a marketplace on theplatform, which is shown in Figure 3.34. A created or edited market-place is stored in the respective cross-marketplace database. After amarketplace is created, volunteers are able to subscribe for this market-place (see Section 5.1.3).


Figure 3.34: Platform Administrator - Marketplace Form

4 A R C H I T E C T U R E

Contents4.1 Conceptual Architecture . . . . . . . . . . . . . . . . . . . . 45

4.1.1 Blockchain . . . . . . . . . . . . . . . . . . . . . . 454.1.2 Client . . . . . . . . . . . . . . . . . . . . . . . . . 464.1.3 Cross-Marketplace . . . . . . . . . . . . . . . . . . 474.1.4 Marketplace . . . . . . . . . . . . . . . . . . . . . 474.1.5 Marketplace Trustifier . . . . . . . . . . . . . . . . 474.1.6 Local Repository . . . . . . . . . . . . . . . . . . . 47

4.2 Run-time Architecture . . . . . . . . . . . . . . . . . . . . . 484.2.1 Blockchain Server . . . . . . . . . . . . . . . . . . 484.2.2 Client Computer . . . . . . . . . . . . . . . . . . . 494.2.3 Cross-Marketplace Server . . . . . . . . . . . . . . 494.2.4 Marketplace Server . . . . . . . . . . . . . . . . . 49

Chapter Architecture provides an overview about the developed com-ponents for the proof-of-concept prototype. This chapter is dividedinto two parts - (i) Conceptual Architecture and (ii) Run-time Architecture.While the Conceptual Architecture summarizes the obligations of the indi-vidual components, the Run-time Architecture describes the deploymentstructure of iVolunteer.

4.1 conceptual architectureThe Conceptual Architecture describes the obligations of each individ-ual component. iVolunteer is a web-based client platform, which con-tains multiple components - (i) Blockchain, (ii) Cross-Marketplace, (iii)Marketplace, (iv) Marketplace Trustifier (shortname: Trustifier), (v) LocalRepository and (vi) the Client, which enables different views for all userroles (see Section 2.1). Figure 4.1 illustrates the data flow between thearchitecture components.

4.1.1 Blockchain

The Blockchain component manages the persistence of contracts in animmutable form (see 2.4.1.2). Additionally, the Blockchain componentensures the verifiability of the contracts, which means that nobody,neither the involved volunteers nor any volunteer involving organiza-tion, can alter or distort contracts unnoticedly. The only way to interactwith the blockchain is through the trust-management by the marketplaceTrustifier.

45

4.1 conceptual architecture 46

Figure 4.1: Component Diagram of the Architecture (based on [19])

4.1.2 Client

The Client is an web applications for users, as present in Chapter 3.The client offers for each user different respective views by consumingthe data from the cross-marketplace, marketplace and marketplace workflowcomponent. Additionally, all views are in general spanning over allregistered marketplaces and offer an aggregated view as demanded(see Section 2.2.4).Regarding the functionalities of Volunteer, there exists three types ofClients - (i) volunteer, (ii) help-seeker and (iii) administrator clients -which have different views.

4.1.2.1 Volunteer Client

The volunteer client application allows a volunteer to search and reservefor tasks. Furthermore, with the volunteer client a volunteer can managetheir local repository containing their achieved competences and detailsregarding all tasks they participated in. Additionally, the volunteerclient enables the volunteers to choose, which competences and detailsof previously finished tasks they want to make public within eachmarketplace.

4.1.2.2 Help-Seeker Client

On the other side, the help-seeker client application enables them tocreate new tasks, to manage the assignment of reserved volunteers totasks, as well as to handle the starting and finishing process of eachtask.

4.1.2.3 Platform Administrator Client

For each marketplace, there has to be at least one administrator, whichis responsible for initially registering the marketplace at the market-place management service and therefore publishing the marketplaceto volunteers and help-seekers which can then register for this mar-ketplace. Additionally, the admin can develop new task workflows or

4.1 conceptual architecture 47

change existing ones which are then used by the help-seekers whencreating a task.

4.1.3 Cross-Marketplace

The cross-marketplace is the central component in iVolunteer and man-aged by the Platform Administrator (see Section 2.1.4). Because of therequired data storage decentralization, the management componentitself does not store any information besides (i) the user and roles, (ii)the marketplaces as well as information about which user is registeredto which marketplace.

4.1.4 Marketplace

The marketplace is responsible for the administration of a marketplace.From the view of the administration, the marketplace is a client, whichprovides all data for the task-management (project, task, task interac-tions, task template). Each marketplace holds information of all regis-tered help-seekers and volunteers along with their public profiles andinformation of all the running and completed tasks.Additionally included is the marketplace workflow, which is obligatedfor controlling task-management operations and is responsible forexecuting the steps of the task’s workflow in the correct order. Gen-erally speaking, the task workflow prescribes the steps a task has togo through from creation to completion and therefore makes the taskexecution configurable.

4.1.5 Marketplace Trustifier

The marketplace trustifier is the only interface to the blockchain. Theobligation of the trustifier (trust-management) is to draft a contractbetween a volunteer and a marketplace regarding a task. It functionsas a third, neutral party to volunteers and marketplaces. On accountof this, volunteers do not need to rely solely on the sovereignty of themarketplaces or the management when it comes to the validity of theirtasks.Besides, the trustifier is used as the verification instance to guaranteethat the local repository of a volunteer is correct. This functionality willbe discussed in the Master’s thesis of my colleague Philipp Starzer.

4.1.6 Local Repository

The local repository represents the volunteer’s Private Volunteer Profile,where their achievements (finished tasks and achieved competences)are stored. The local repository is a file stored at a location of thevolunteer’s choice. The single entries in the file are stored in JSONformat, with which it is possible to recreate the hashed versions storedin the blockchain for later verification (see Listing 4.1). In the example,the private volunteer profile of the volunteer pstarzer is presented.

4.2 run-time architecture 48

Currently the volunteer has synchronized one completed task and oneachieved competence.

Listing 4.1: Example of a Local Repository (based on [19])

1 {2 "repository": [3 {4 "id": "1",5 "volunteer": {6 "username": "pstarzer"7 },8 "taskList": [9 {

10 "id": "5af7e2ee-379b-b359-3ceb-041b74de8711",11 "taskId": "5af7e28a379bb3593ceb0415",12 "taskName": "Task 1",13 "taskDescription": "Task 1 Description",14 "marketplaceId": "Marketplace1",15 "timestamp": 152619492635016 }17 ],18 "competenceList": [19 {20 "id": "939c6ca3-1375-424e-816a-369e04465384",21 "competenceId": "5af7e227379bb3593ceb0412",22 "competenceName": "Flexibility",23 "marketplaceId": "Marketplace1",24 "timestamp": 152619492635025 }26 ]27 }28 ]29 }

4.2 run-time architectureThe Run-time Architecture describes the deployment of the previouslydescribed components. Figure 4.2 shows the structure of the run-timesystem, the physical hardware elements on which the componentsare running on and the communication paths between them. Thesecommunications take place over the internet via HTTP calls usingTCP/IP.

4.2.1 Blockchain Server

As the name suggests, the Blockchain Server hosts the blockchain, namelyan implementation of the Hyperledger Fabric1 Network. For productiveusage, later on, several other blockchain nodes need to be organized,e.g, on servers of VIOs to ensure trust across all participants.

1 https://www.hyperledger.org/projects/fabric


Figure 4.2: Deployment Diagram of the Architecture (based on [19])

4.2.2 Client Computer

The Client Computer is a device of the user’s choice, where the userscan interact by using an installed web browser with the iVolunteerplatform. The web browser running on the client computer downloadsthe web application and allows for authentication and utilization ofthe functionalities described in Chapter 2. The client computer furtherhosts the local repository application, allowing to publish the privatevolunteer profile and grant the client access to footprint entries thereof.

4.2.3 Cross-Marketplace Server

The Cross-Marketplace Server hosts the Client of iVolunteer. In addition,the Cross-Marketplace component and the trustifier component are hostedthere. The management component operates a MongoDB2 databasefor holding the following entities: Marketplace, Volunteer, Help-Seeker,Marketplace Administrator and Dashboard.

4.2.4 Marketplace Server

The Marketplace Server represents one instantiation of an arbitrary VIO.Every other marketplace would have the same configuration. Each VIOis responsible for hosting their marketplace server by themselves.

2 https://www.mongodb.com


Same as the cross-management component, the marketplace componentoperates a MongoDB database holding the following entities: Project,Task, Task Interaction, Task Template, Competence and Users. Further-more, the Marketplace workflow component is hosted there as well. Theworkflow component operates a MySQL3 database for storing the taskworkflow definitions.

3 https://www.mysql.com/

5 I M P L E M E N TAT I O N

Contents5.1 Cross-Marketplace . . . . . . . . . . . . . . . . . . . . . . . 51

5.1.1 User-Management . . . . . . . . . . . . . . . . . . 515.1.2 UI-Management . . . . . . . . . . . . . . . . . . . 545.1.3 Multitenancy-Management . . . . . . . . . . . . . 55

5.2 Marketplace Trustifier . . . . . . . . . . . . . . . . . . . . . 575.2.1 Trust-Management . . . . . . . . . . . . . . . . . . 58

5.3 Marketplace . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.3.1 Competence-Management . . . . . . . . . . . . . 605.3.2 Task-Management . . . . . . . . . . . . . . . . . . 605.3.3 Task Workflow Control . . . . . . . . . . . . . . . 69

In this section, the implemented API for the UI-functionalities in Chap-ter 3 are described, based on the requirements (see Chapter 2) andthe architecture (see Chapter 4). Starting with the main architecturalcomponents - (i) cross-marketplace, (ii) marketplace trustifier (shortname:trustifier) and (iii) marketplace.

5.1 cross-marketplaceThe cross-marketplace is the central communication point in iVolun-teer and responsible for (i) user-management, (ii) ui-management, (iii)marketplace-management and (iv) social-management. The cross-marketplacecomponent is managed by the platform administrator (see Section 2.1.4).Because of the required data storage decentralization, the cross-marketplacecomponent itself stores only the information of (i) login data for usersand their roles, (ii) the marketplace identifier as well as (iii) the dash-board configurations for volunteers.The social-management as described in Section 2.2.3 would be responsiblefor handling social interactions between volunteers, but these featuresare beyond the scope of this thesis and therefore not implemented (seeSection 6.3).

5.1.1 User-Management

User-management covers currently the implementation of the authen-tication and the authorization of a user, either as a volunteer, as ahelp-seeker or as a platform administrator, as described in Section 2.2.1.Therefore the following domain models - (i) user, (ii) userRole, (iii) mar-ketplaceUser and (iv) marketplace are designed. Additionally displayedin Figure 5.1 is that each user has to be assigned at least to a user roleand has to be subscribed to a marketplace.

51

5.1 cross-marketplace 52

Figure 5.1: Cross-Marketplace - User-Management (based on [19])

Generally, the authentication of a user is done once at the cross-marketplace component, which stores the user credentials in the cross-marketplace DB. In opposite, the authorization has been done at eachcomponent separately. Another big part of the user-management, theregistration of the user is currently not supported by iVolunteer. Moredetails are described in Section 6.2.

authentication At the beginning of the authentication process, a usersends a request with the entered credentials at a predefined endpointof the security framework. As next step the so-called JWTAuthentication-Filter is executed. This filter parses and passes the credentials to theAuthenticationManager. The authentication manager is responsible forchecking whether the user in the cross-marketplace DB exists and theircredentials are correct. If the credentials are correct, the JWTAuthentica-tionFilter is building a JSON Web Token1 consisting of the claims (i) sub(= subject; this is typically the user id), (ii) username, (iii) authoritiesand (iv) exp (= expiration time). An example content of a decoded JSONWeb Token is presenting in Listing 5.1. On a negative outcome of thecredentials check, the user retrieves no token, and the authenticationprocess fails. The introduced process is displayed in Figure 5.2.

Listing 5.1: User-Management - Decoded content of a JSON Web Token

1 {2 "sub": "1234567890",3 "username": "pstarzer",4 "authorities": [ "HELP-SEEKER", "VOLUNTEER" ],5 "exp": 15754479286 }

1 https://jwt.io/


UserAuthenticationFilter AuthenticationManager

Cross-Marketplace DB

login(username, password)

authenticate(username, password)

searchUser(username)

return user

verify(...)

return true

return token

return false

return unauthorized

alt [verification positive]

[verification negative]

Figure 5.2: User-Management - Authentication

authorization As described previously, each component has to se-cure that no unauthenticated user can use the API. Therefore the autho-rization process checks whether a request includes a valid JWT Token.At the beginning of the authorization process, a user sends a request.This request has to include a JWT token in the header of the request. TheJWTAuthorizationFilter (see Listing 5.2), checks if the request includes avalid token. On a successful outcome, the filter sets the SecurityContex-tHolder, which holds the context (= username, authorities) of the passedJWT Token. On a negative outcome, the user is not authorized.

Listing 5.2: User-Management - JWTAuthorizationFilter.java

1 public class JWTAuthorizationFilter extendsBasicAuthenticationFilter {

2

3 @Override4 protected void doFilterInternal(HttpServletRequest req,

HttpServletResponse res, FilterChain chain) throwsIOException, ServletException {

5 if (validateHttpServletRequest(req)) {6 SecurityContextHolder.getContext().setAuthentication(

getAuthentication(req));7 chain.doFilter(req, res);8 } else {9 res.sendRedirect(SC_UNAUTHORIZED);

10 }11 }12


13 private UsernamePasswordAuthenticationToken getAuthentication(HttpServletRequest req) {

14 String token = extractTokenFromRequest(req);15 String username = parseUsernameFromJWTToken(token);16 Collection<GrantedAuthority> authorities =

parseAuthoritiesFromJWTToken(token);17 return new UsernamePasswordAuthenticationToken(username, null

, authorities);18 }19 }

5.1.2 UI-Management

The UI-management mainly includes the dashboard-management featuresand the user interface functionality of an adaptive user interfaces, whichare currently available for volunteers only. More details about therequirement are described in Section 2.2.4.In the upcoming section, only the dashboard management feature isdescribed. The UI-functionality of an adaptive user interface was partof the feature in Chapter 3. Therefore the adaptive user interface is usingonly collectors to get the data, which are provided by the marketplacecomponent.

5.1.2.1 Dashboard-Management

In general, a dashboard is a visual display presenting important infor-mation in the form of UI elements (called dashlets). Each volunteershould be able to create their own user-defined dashboards with theirpreferred UI elements (called dashlet).As shown in Figure 5.3, a dashboard belongs to a user, which canconfigure a certain set of dashlets that can be arranged. Therefore aDashboard comprises a name and a list of Dashlets. On the outer side aDashlet wraps a Widget and creates a customizable widget, which canbe displayed on a User’s Dashboard. The respective Dashlet is referencedby the widgetType and is then placed at the xPosition and yPosition ofthe Dashboard. The height and width represent the displayed size ofthe Dashlet. The widgetType is the connection between the designedview-element and the implementation behind the view-element.


Figure 5.3: Cross-Marketplace - UI-Management

In the upcoming paragraphs, the implementation details of the API,which entails the functionality (i) search, (ii) create, (iii) update and (iv)delete of a dashboard are described.

search for a dashboard Search for dashboard is required, in or-der to provide the prerequisite for UI-functionality of the dashboardmanagement. In general, each user is allowed to search these entriesfrom the cross-marketplace DB. The search for a dashboard includes alldashlet configurations of the searched dashboard.

create a dashboard As seen in the user interface, volunteers areable to create new dashboard configurations. Therefore volunteers areable to create a new dashboard with the dashlet configuration in thecross-marketplace DB.

update a dashboard In order to remove and add new dashlets, thisfunctionality was implemented. Same as the create a dashboard, the up-date dashboard configuration will be updated in the cross-marketplace DB.

delete a dashboard If a volunteer decides to delete a dashboard,the included dashlets are also deleted on the cross-marketplace DB.

5.1.3 Multitenancy-Management

This section covers the implementation details of the multitenancy re-quirement defined in Section 2.2.2, which states that iVolunteer has tobe able to have multiple marketplaces, which entails the functionality of(i) search, (ii) create/registration, (iii) update, (iv) deletion and (v) subscribeas well (vi) unsubscribe of a marketplace.As shown in Figure 5.4, a domain model for an marketplace representingby a name, a shortname (as unique identifier) and a URL, where thedata of the marketplace component is provided. In addition, each mar-ketplace provides a collection of task-workflow processes (see Section5.3.3).


Figure 5.4: Cross-Marketplace - Multitenancy-Management

search for a marketplace Search for marketplaces is required,in order to provide the prerequisite for the subscribe or unsubscribefunctionality of a marketplace. In addition, the search for a marketplaceis needed to display them for the configuration purpose of a platformadministrator (see Section 3.4.1).Generally, all users are allowed to search these entries from the cross-marketplace DB, but only volunteers and help-seekers can read theirsubscribed marketplaces.

registration of a marketplace The registration of marketplacesis necessary to add new tenants (e.g. VIOs like Red Cross) to iVolunteer.This process (see Fig. 5.5) is typically done by the platform administrator(see sect. 2.1.4) and is started when the platform administrator receivesthe request to create a new marketplace. Then the Platform Admin-istrator checks the requested marketplace, whether it is accessible orwhether the naming of the marketplace complies. Afterwards, if thecheck was successful, the administrator creates the marketplace bysending a request to the cross-marketplace component, which inserts themarketplace to the cross-marketplace DB.

User Platform AdministratorCross-Marketplace

Cross-Marketplace DB

create_marketplace(mp_data)

mp_data:user, name, short name, url

check(mp_data)



Figure 5.5: Multitenancy-Management - Register Marketplace (based on [19])

update of a marketplace The platform administrator can change thename and URL of an existing marketplace, by sending a request to thecross-marketplace component, which then changes the marketplace in thecross-marketplace DB.

5.2 marketplace trustifier 57

deletion of a marketplace If a VIO decides to delete the market-place, the platform administrator deletes the marketplace by sending arequest to the cross-marketplace component, which deletes the market-place from its cross-marketplace DB.

subscribe a marketplace Volunteers can subscribe to a market-place, allowing them to participate in it, by creating tasks (as help-seeker) or reserve for tasks (as a volunteer) on the marketplace. Theprocess of subscribing to a marketplace, as displayed in Fig. 5.6 forthe subscription as a volunteer starts with the request for unsubscribedmarketplaces, which will be retrieved from the cross-marketplace DB. Forany of these unsubscribed marketplaces, the user can send the requestto subscribe to it. The cross-marketplace component first creates thesubscription in the cross-marketplace DB and then passes through therequest to the respective marketplace, which creates the user in themarketplace DB.

VolunteerCross-Marketplace

Cross-Marketplace DBMarketplace

Marketplace DB

retrieve_unsubscribed_marketplaces()

read_unsubscribed_marketplaces()

return marketplaces

return marketplaces

subscribe(marketplace)

create_subscription(volunteer, marketplace)

subscribe(volunteer)

create(volunteer)

Figure 5.6: Multitenancy-Management - Subscribe Marketplace

unsubscribe a marketplace The opposite to subscribe to a mar-ketplace is to unsubscribe a marketplace. If a volunteer decides tounsubscribe a marketplace, the process of unsubscribing starts withthe request for subscribed marketplaces. The cross-marketplace componentdeletes the subscription in the cross-marketplace DB.

5.2 marketplace trustifierThe marketplace-trustifier component is the only interface to the Blockchainand therefore responsible for the trust-management between the par-ties. Due to the requirement footprint verification management in Section2.4.1, the marketplace-trustifier is the only API caller to the Blockchaincomponent; it functions as a third, neutral party to volunteers andmarketplaces. On account of this, volunteers do not need to rely solelyon the sovereignty of the marketplace or the cross-marketplace, when itcomes to the validity of their earned achievements. The same thingis not only true for writing, but also for reading from the Blockchain,because all entries are hashed and therefore rendered illegible for all

5.2 marketplace trustifier 58

other blockchain participants, which do not have the plaintext of thehash.

5.2.1 Trust-Management

As mentioned, the trust-management drafts a contract between twoparties, mainly between a volunteer and a marketplace regarding tasksand achievements. The execution class of this implementation is theso-called Trustifier. This class is controlling the request flow between thecomponent for (i) writing a HashableObject (e.g. a task or achievement)into the Blockchain as well as (ii) verifying this object by looking this upin the Blockchain. The class diagram in Figure 5.7 provides an overviewabout the relationships of this objects.The upcoming paragraphs describe the control flow of the executionclass called Trustifier.

Figure 5.7: Marketplace Trustifier - Trust-Management (based on [19])

write a contract hash Figure 5.8 shows the process of writing aHashableObject into the Blockchain component.This process is initiated by an external instance by calling the trust-management service’s contractor (1). The contract is then cryptographi-cally hashed by the hasher (2). Finally, the hash and additional metainformation are written into the blockchain (3).

MarketplaceContractor Hasher Blockchain

write(hashable_object)

generate_hash(hashable_object)

return contract_hash

write(contract)

Figure 5.8: Trust-Management - Write a Contract Hash

5.3 marketplace 59

verify a contract hash The use case (see Figure 5.9) illustrates theprocess of verifying a contract in detail.The process starts by calling the trust-management service’s contractor(1) or by the marketplace workflow component. The provided contract isthen cryptographically hashed by the hasher (2). This hash is passedto the verifier (3), who checks whether exactly this hash is in theBlockchain or not (4). On a positive verification, the process continues.On a negative verification the process has to terminate because thecontract between the marketplace and the contractor is invalid. Theresult is returned to the calling instance (5).

MarketplaceContractor Hasher Verifier Blockchain

verify(hashable_object)

generate_hash(hashable_object)

return contract_hash

verify(contract)

read(contract)

return entry

return true

return true

Error: entry not found

return false

return false

alt [verification positive]

[verification negative]

Figure 5.9: Trust-Management - Verify a HashableObject

5.3 marketplaceThe marketplace component is responsible for the requirements competence-management (see Section 2.3.3) and task-management (see Section 2.3.2).Additionally the marketplace is as well responsible for a sub-part of therequirement footprint. This sub-part is called achievement-management.Due to this requirement, volunteers are able to share their achievementswith the marketplace. This part is out-of the scope of this thesis.The responsibilities of the marketplace component (called competence man-agement and task management) are described in the upcoming sections.

5.3 marketplace 60

5.3.1 Competence-Management

Within the marketplace component, competence-management covers cur-rently only implementation of searching for competencies. Based onour current implementation, all marketplace components are retrieving thecompetences that are currently stored in the marketplace DB. The fourcompetences - (i) CREATIVITY, (ii) FLEXIBILITY, (iii) LEADERSHIPand (iv) MOTIVATION are retrieved.Other operations like create, update, and delete, except the search oper-ation, are currently not supported. More details are described in Section6.4.

search of competencies A search for competencies is needed toassign those to a task. Therefore, the API provides an interface forvolunteers and help-seekers to search those entries from the marketplaceDB.

5.3.2 Task-Management

In general, the implementation of the task-management (see Figure 5.10)is closely related to the implementation of the marketplace workflow.While the marketplace component generally creates and manages tasks forspecific projects, marketplace workflow is controlling the task workflowof the predefined task actions - (i) publish, (ii) reserve, (iii) assign, (iv)start, (v) finish and (vi) abort. This means that the marketplace workflowdefines the execution order of the task-management actions.This section covers implementation details of the task-management re-quirement defined in Section 2.3.2, which states that Marketplaces havedifferent ways to handle their procedures regarding projects and tasks.In addition, the implementation of task-templates are also covered in thissection.The class diagram in Figure 5.10 should provide an overview aboutthe relationship between the domain models for - (i) project, (ii) task,(iii) task-template and (iv) task-interaction. In the upcoming section,first the API for the domain models and later the task-managementlife-cycle are explained.

5.3.2.1 Project

Projects are the only structural elements within the task-management im-plementation. Their purpose is a grouping of tasks only. These projectsare created, edited or deleted by help-seekers only.The functionality of (i) search, (ii) create, (iii) update and (iv) delete aredescribed in the upcoming paragraphs.

search for a project This functionality is needed by all authenti-cated users, except the platform administrator. All project data are storedand will be retrieved from the respective marketplace DB.The implementation covers the provision of (i) available, (ii) engaged and(iii) finished projects (see Listing 5.3). The Rest-API for available projectsretrieves all those tasks which have been published and the volunteerscan register for. This includes all projects, who the volunteer does not

5.3 marketplace 61

Figure 5.10: Marketplace - Task-Management (based on [19])

have a task that has been reserved or assigned. On the other, side theRest-API for engaged projects retrieves all projects with at least onetask, which are not finished and where a volunteer is involved in anyway (reserved or assigned). Finished projects are those projects with atleast one task, whom the volunteer was assigned to and finished by ahelp-seeker.

Listing 5.3: Task-Management - Project - Search for by Status

1 public List<Project> findAll(2 @RequestParam(value = "status") String status) {3 Volunteer volunteer = loginService.getLoggedInVolunteer();4 if (AVAILABLE.equals(status)) {5 return findAvailableProjectsByVolunteer(volunteer);6 }7 if (ENGAGED.equals(status)) {8 return findEngagedProjectsByVolunteer(volunteer);9 }

10 if (FINISHED).equals(status)) {11 return findFinishedProjectsByVolunteer(volunteer);12 }13 return projectRepository.findAll();14 }15

16 private List<Project> findAvailableProjectsByVolunteer(Volunteervolunteer) {

17 Set<Project> projects = new HashSet<>();18 taskRepository.findByStatus(PUBLISHED).forEach(task -> {19 TaskInteraction taskInteraction = getLatestTaskInteraction(

task, volunteer);20 if (!isReservedOrAssigned(taskInteraction)) {21 projects.add(task.getProject());

5.3 marketplace 62

22 }23 });24 return new ArrayList<>(projects);25 }26

27 private List<Project> findEngagedProjectsByVolunteer(Volunteervolunteer) {

28 Set<Task> engagedTasks = new HashSet<>();29 engagedTasks.addAll(taskRepository.findByStatus(RUNNING));30 engagedTasks.addAll(taskRepository.findByStatus(PUBLISHED));31 Set<Project> projects = new HashSet<>();32 engagedTasks.forEach(task -> {33 TaskInteraction taskInteraction = getLatestTaskInteraction(

task, volunteer);34 if (isReservedOrAssigned(taskInteraction)) {35 projects.add(task.getProject());36 }37 });38 return new ArrayList<>(projects);39 }40

41 private List<Project> findFinishedProjectsByVolunteer(Volunteervolunteer) {

42 Set<Project> projects = new HashSet<>();43 taskRepository.findByStatus(FINISHED).forEach(task -> {44 TaskInteraction taskInteraction = getLatestTaskInteraction(

task, volunteer);45 if (isReservedOrAssigned(taskInteraction)) {46 projects.add(task.getProject());47 }48 });49 return new ArrayList<>(projects);50 }

create a project The creation of projects is only available for help-seeker. So volunteers can store a specific project in the respective mar-ketplace DB.

update a project Updating a project is possible until no task of theproject is published. After a volunteer publishes a task, the project isnot editable anymore.

delete a project If a help-seeker decides to delete a project, theincluded tasks and task interactions are also deleted from the respectivemarketplace DB). This process is possible until none has started a task ofthose project.

5.3.2.2 Task

Tasks are implemented as life-cycle configuration object (see Figure 5.11,which represents the only executable object).In the upcoming paragraphs, the functionality of (i) creating, (ii) search-ing, (iii) editing, (iv) publishing, (v) assigning, (vi) starting, (vii) finishingand (vii) aborting are described. Please consider that the task-management

5.3 marketplace 63

of the marketplace is very closely related to the task-workflow implemen-tation of the marketplace workflow component and also to the verificationand write operations of the marketplace trustifier (see Section 5.2.1) intothe Blockchain component.

Figure 5.11: Task Management - Life-Cycle

create a task First, the creation of a task on the respective market-place is only possible for help-seekers. Therefore, the help-seeker sends arequest to the cross-marketplace component, which passes it through tothe respective marketplace creating the task in the marketplace DB. Foreach task, the help-seeker needs to select a so-called workflow type toassign a workflow process to this task. The workflow type identifiesthe workflow process by a unique key. More details are described inSection 5.3.3.

search for a task The search functionality of tasks always dependson the status of the task. Therefore the implementation supports theretrievement of tasks depending on their state.

edit a task When a task is created and not yet published, help-seekers can edit those task. After publishing, the task is no longerchangeable because the publishing process inserts the task definitioninto the blockchain component. That means since a task is published, thecontract between the volunteer and the marketplace has to be agreed (seeSection 5.2.1).

publish a task After a task was created, it can be published bya help-seeker, who writes the task in the form of a contract to theBlockchain component and thus makes it available for volunteers toreserve for it.As displayed in Figure 5.12, the help-seeker first retrieves tasks fromthe marketplace and selects the one which should be published. Forthis task, the respective workflow-step is retrieved and executed bythe marketplace workflow component, which sends the publish requestfrom the marketplace workflow to the Marketplace. This, in turn, calls theTrustifier to write the created task to the Blockchain, see Section 5.2.1 fordetails on that process. Finally, the task status in the marketplace DB isupdated, and the task is visible to volunteers.

5.3 marketplace 64

Help-SeekerMarketplace Workflow Marketplace Marketplace Trustifier

retrieve_tasks()

return tasks

select_task

retrieve_workflow_step(task)

return workflow_step

execute_workflow_step(workflow_step, task)

publish(task)

create(task_interaction)

write(task_interaction)

ref


Figure 5.12: Task-Management - Publish a Task

reserve for a task If a volunteer is interested in a certain task,they have the opportunity to reserve themselves for this task. The usecase of reservation is shown in Figure 5.13.First, all available tasks are loaded. Then a volunteer is choosing atask to reserve, which has to be verified to ensure that the contractbetween the volunteer and the marketplace is valid (see Section 5.2.1).On a positive verification result, the marketplace is called to initiatethe reservation of the volunteer. During the process, the volunteer-taskreservation is sent to the Trustifier to write into the Blockchain component,described in Section 5.2.1. Finally, the marketplace’s database is updatedwith new information.

assign to a task The default task workflow is designed so that ahelp-seeker has to assign reserved volunteers to a task. The use case ofassignment is shown in Figure 5.14.In the beginning, the help-seeker retrieves a list of tasks which havebeen already reserved by volunteers. If the help-seeker wants to assignthe volunteer to a task, this task has to be verified again. Thus, it isensured that the contract is not broken by the marketplace. Thereforethe task will be verified via the Trustifier (see Section 5.2.1). On apositive outcome, the assigned procedure at the marketplace begins.The volunteer-task assignment is sent to the Trustifier to record it inthe blockchain, described in Section 5.2.1. Finally, the marketplace’sdatabase is updated with the volunteer-task assignment.All in all, the Reserve for a Task and Assign to a Task of the task workflowlooks similar, but the difference between these workflow steps is thewritten contract hash of the task interaction.

5.3 marketplace 65

VolunteerMarketplace Workflow Marketplace Marketplace Trustifier

retrieve_available_tasks()

return tasks

select_task




reserve_volunteer(task)

verify(task)

ref

verify(task)

return result



ref


Figure 5.13: Task-Management - Reserve a Task



return tasks

select_task




assign_volunteer(task)

verify(task)

ref

verify(task)

return result



ref


Figure 5.14: Task-Management - Assign a Task

5.3 marketplace 66



return tasks

select_task




start(task)

verify(task)

ref

verify(task)



ref

write(task-interaction)

Figure 5.15: Task-Management - Start a Task

start a task Since a help-seeker has assigned their favourite vol-unteers for a task, the task can start. The use case of starting a task isshown in Figure 5.15.Starting a task is very similar to assigning a volunteer. The difference isthat in this case, a start interaction is written by the Trustifier. For this,help-seekers can start the process only. The Trustifier is notifying themarketplace to update their database and to send them the start taskinteraction.

finish a task Finishing off a task as it is implemented in the defaulttask workflow is shown in Figure 5.16. Finishing is an action that isperformed by the help-seeker.Finishing a task works similar to the other cases. In the beginning,the help-seeker retrieves a list of started tasks. Again the selectedtask, which has to finish, has to be verified (see Section 5.2.1; thisensures the task’s integrity. Therefore the task is sent to the Trustifier.On a positive outcome, the finish procedure at the marketplace starts.The task interaction with the status FINISHED will be created in themarketplace DB and is later send to the Trustifier, who is storing theinteraction. During this process, the marketplace sends the earnedcompetencies and completed task entry to a non-blocking thread of theTrustifier to write a competence entry as well as a task entry into theblockchain. More details on the Trustifier write process are describedin Section 5.2.1. Before sending the entries into the Blockchain, themarketplace’s database is updated.

5.3 marketplace 67


retrieve_started_tasks()

return tasks

select_task




finish(task)

verify(task)

ref

verify(task)

return result

create(finished_task)

write(finished_task)

ref

write(finished_task)

create(achieved_competence)

write(achieved_competence)

ref

write(achieved_competence)



ref


Figure 5.16: Task-Management - Finish a Task

5.3 marketplace 68


retrieve_started_tasks()

return tasks

select_task




abort(task)

verify(task)

ref

verify(task)

return result



ref


Figure 5.17: Task-Management - Abort a Task

abort a task The last possible step in the task workflow is the abortprocess of the task. The process is shown in Figure 5.17.All in all, aborting a task results in finishing the workflow-process,similar to finishing a task, but earned competencies, entry or finishedtask entry are written into the Blockchain. There is one further differ-ence between Finish a task and Abort a task. Instead of writing a finishinteraction, the Trustifier writes an abort task interaction to documentthe process.

5.3.2.3 Task-Template

Other than tasks and projects, task-templates are not visible in the userinterface (UI). A task-template is only a simple pattern for creating atask. The purpose of a task-template is to help those seeking help tocreate several similar tasks. The functionalities of (i) search, (ii) create, (iii)update and (iv) delete of a task-template are described in the upcomingparagraphs.

search for a task-template The search of task-templates is per-formed by reading all data from the marketplace DB.

create a task-template The creation of task-templates is only avail-able for help-seekers. So help-seekers can store a certain task-templatein the respective marketplace DB.

5.3 marketplace 69

update a task-template Within the functionality of task-templates,there are no restrictions regarding their editing. If a help-seeker decidesto edit a task-template, all changes are saved in the Management DB.

delete a task-template If a help-seeker decides to delete a task-template, a request is sent to the marketplace component. This finallyresults in deleting the corresponding task-template from its marketplaceDB.

5.3.3 Task Workflow Control

The task marketplace workflow (=marketplace workflow) is the controlcomponent for the task-management functionality of the marketplace com-ponent. This control component is mandatory for the task’s life-cycleoperations.Within the requirements, the workflow implementation covers the re-quirement of task life-cycle configuration (included in requirement task-management, which is described in Section 2.3.2).In the upcoming sections, first, the workflow definition, then the function-ality of the workflow API are described. While the workflow definition’scovers the implementation of the workflow-step and the workflow-process,the workflow API wraps the workflow execution by Activiti2 for anuser.

5.3.3.1 Workflow Definition

Additionally to the domain models in Figure 5.18, the workflow definitioncovers two basic workflow constituents within the marketplace component,namely workflow steps (a combination of an user-task and service-task)and workflow processes (in the figure called task workflow).

2 https://www.activiti.org

5.3 marketplace 70

Figure 5.18: Task Workflow - Workflow Definition (based on [19])

(1) workflow-step A workflow-step defines one task-management life-cycle operation (e.g., to assign a volunteer). Each workflow-step repre-sents a sequences of so-called user-tasks followed by a service-task. Whilea user-task is representing a waiting point for a user interface operation,a service-task executes the defined task life-cycle operation.Typical for such a sequence is that each user-task has to be triggered bya request to the workflow API. Before executing the user-task, the work-flow implementation checks, who is able to execute the workflow-step.The executor is the so-called workflow-step executor, which is defined foreach workflow-step.

(2) workflow-process The Workflow-Process designed in Figure 5.19,shows the default workflow of the marketplace workflow component. Thisworkflow-process is designed based on the task Life-Cycle Configuration(see Figure 5.11) as a BPMN 2.0 Process.

5.3 marketplace 71

Publish(User-Task)

Publish(Service-Task)

Start(User-Task)

Start(Service-Task)

Finish(User-Task)

Finish(Service-Task)

Assign(User-Task)

Assign(Service-Task)

Unassign(User-Task)

Unassign(Service-Task)

Unreserve(User-Task)

Reserve(Service-Task)

Unreserve(Service-Task)

Reserve(User-Task)

Figure 5.19: Task-Workflow-Control - Workflow-Process

As shown in the Figure, the workflow-process consists of two pro-cesses. First the main process with the workflow-steps (i) publish, (ii)start and finish of a certain task is available. Afterwards if the task is pub-lished, the main process starts multiple sub-processes for (i) reservingfor a task and (ii) assigning to a task. While the main process of a taskis executable by help-seekers only, each sub-process is executable byvolunteers (reserving & unreserving) as well as help-seekers (assigning& unassigning). This depends on the workflow-step executor of the task.To handle the multiple sub-processes, the previous service-task of themain process defines those volunteers, who can reserve for this task.This leads to the workflow-steps for reserving for a volunteer or/andassigning a volunteer. After the task was started, the workflow-controlcompletes all open user-tasks of the sub-processes. That is necessary inorder to deactivate all workflow-steps for the reservation and assign-ment of the already started task.

5.3.3.2 Workflow API

The Workflow API wraps the Workflow-Process to be accessible for theuser interface of a user. The workflow API generally supports all usersfor (i) Search for Workflow-Types, (ii) Start a Workflow-Process, (ii) Searchfor upcoming Workflow-Steps, (iii) Execute a Workflow-Step and (iv) Abort a

5.3 marketplace 72

Workflow-Process. The implementation of the functionality is describedin the upcoming paragraphs.

search for workflow-types As previously mentioned, each workflow-type has a unique identifier of an workflow-process. Listing 5.4 showsthat the workflow-type will be retrieved from the process-definition of theworkflow-process. The process-definition is the structural definition of aworkflow-process and defined as BPMN File. This BPNM File definesthe structure, as well as the name and unique identifier of a workflow.As shown in Listing 5.4, the functionality is encapsulated into a separateservice, which is called WorkflowTypeService. This service retrieves theworkflow-type from the provided BPNM File of the marketplace. Ithas to be noted, that only the latest version of the provided process-definition is retrieved.

Listing 5.4: Task-Workflow-Control - Search for Workflow-Type

1 @Service2 public class WorkflowTypeService {3

4 @Autowired5 private RepositoryService repositoryService;6

7 public List<WorkflowType> getWorkflowTypes() {8 List<ProcessDefinition> processDefinitions =

repositoryService9 .createProcessDefinitionQuery()

10 .active()11 .latestVersion()12 .list());13 return processDefinitions.stream()14 .map(definition -> new WorkflowType(definition.getKey(),

definition.getName())15 .sorted((w1, w2) -> compare(w1.getName(), w2.getName()))16 .collect(toList());17 }18 }

start of a workflow-process Within iVolunteer, the Start of aWorkflow-Process could be executed by help-seekers only. Thereforea help-seeker sends a request to the API, which is starting the ActivitiWorkflow based on the workflow-type.

search for upcoming workflow-steps The Search for a Workflow-Step of a task evaluates the upcoming steps, which the user can take.In general, we have to implement a general search within the workflow,traversing it and looking for the next executable activity (see Listing5.5). Since a workflow can branch into several paths, we have to lookinto all of them and search for each of them until we find the nextexecutable activity, which is in our case, a service-task. We aggregate allexecutable activities and process them further by displaying them inthe UI.

5.3 marketplace 73

Please not that the implementation in Listing 5.5 depends on the versionof the used Activiti Framework.

Listing 5.5: Task-Workflow-Control - Search for upcoming Workflow-Step

1 @Service2 public class WorkflowStepService {3

4 static final String SERVICE\_TASK = "serviceTask";5 static final String EXCLUSIVE\_GATEWAY = "exclusiveGateway";6 static final String PARALLEL\_GATEWAY = "parallelGateway";7

8 @Autowired9 private RuntimeService runtimeService;

10 @Autowired11 private RepositoryService repositoryService;12

13 /**14 * Searching for upcoming workflow steps15 **/16 public List<WorkflowStep> getNextWorkflowSteps(Task task) {17 // determine the current Execution18 Execution execution = findExecutionForTask(task);19 // determine the Activity Flow of the current Execution20 Activity activity = findActivityByExecution(execution);21 // determine the labels for the Activity Flow22 Set<String> labels = findLabelsForActivity(activity);23 // building a workflow step24 return labels.stream().map(label -> return new WorkflowStep(

task.getId(), label).toList();25 }26

27 /**28 * Search for labels by traversing through the Activity Flow29 **/30 private Set<String> findLabelsForActivity(Activity activity) {31 Set<String> labels = new HashSet<>();32 List<PvmTransition> transitions = activity.

getOutgoingTransitions();33

34 for (PvmTransition transition : transitions) {35 String typeProperty =36 transition.getDestination().getType();37 if (typeProperty.equals(EXCLUSIVE_GATEWAY)){38 labels.addAll(determineWorkflowLabelsForActivity(

transition.getDestination()));39 } else if (typeProperty.equals(PARALLEL_GATEWAY)) {40 labels.addAll(determineWorkflowLabelsForActivity(

transition.getDestination()));41 } else if (typeProperty.equals(SERVICE_TASK)) {42 labels.add(transition.getDestination().getName());43 } else {44 throw new UnsupportedOperationException("Type not

supported");45 }46 }47 return labels;

5.3 marketplace 74

48 }49

50 /**51 * Find the current Execution of a task52 **/53 private Execution findExecutionForTask(Task task) {54 ExecutionQuery executionQuery = runtimeService.

createExecutionQuery();55 return (ExecutionEntity) executionQuery.executionId(task.

getExecutionId()).singleResult();56 }57

58 /**59 * Find the Activity Flow of an Execution60 **/61 private Activity findActivityByExecution(ExecutionEntity

executionEntitiy) {62 ProcessDefinitionEntity processDefinition = (

ProcessDefinitionEntity) repositoryService63 .getProcessDefinition(executionEntitiy.

getProcessDefinitionId());64 return processDefinition.findActivity(executionEntitiy.

getActivityId());65 }66 }

execute workflow-step for task The Execution of a Workflow-Step(see Section 5.3.3.1) is triggered by a user request. To complete thata workflow-step, the first step of the sequence (= user-task) must becompleted. That completes the service-task.

abort of a workflow The last functionality of the Workflow API isthe Abort of a Workflow-Process. If a help-seeker decides to abort a start,the workflow-processes (main process and sub-processes) are deletedfrom the Marketplace Workflow DB. Since the workflow is aborted, theworkflow couldn’t start again.

6 F U T U R E W O R K

Contents6.1 UI Management . . . . . . . . . . . . . . . . . . . . . . . . . 756.2 User Management . . . . . . . . . . . . . . . . . . . . . . . 756.3 Social Management . . . . . . . . . . . . . . . . . . . . . . . 766.4 Competence Management . . . . . . . . . . . . . . . . . . . 76

Chapter future work describes functionalities, which appeared to be,during the realization of the iVolunteer prototype, useful further exten-sions of the current system.These possible additional functionalities are further on described ac-cording to the main functional categories of iVolunteer, spanning fromUI Management and User Management, to Social Management andCompetence Management.

6.1 ui managementThe UI-management, especially for the volunteer’s dashboard, coverscurrently only a few small proof-of-concept dashlets. The next step toimprove the UI-management of iVolunteer should be building moreattractive and informative dashlets for all kinds of users. That includesthat the dashboard management feature should not be limited to volun-teers only, since also help-seekers could benefit from using this feature.

6.2 user managementCurrently, the implementation of the user-management of iVolunteercovers the authentication and authorization of a user. However, besides,the registration of volunteers is essential. That requires that iVolunteer,at the time of the registration checks if a volunteer is trustworthy ornot to have the verification that no malicious machinations arise.Another possible improvement of the functionality will be the assign-ment of multiple roles to a user. Currently, a user, e.g., a volunteer, isassigned to the role of a volunteer only. However, to work as a volunteerfor Marketplace M1 as well as help-seeker for Marketplace M2, it isessential to assign a user to multiple roles.

75

6.3 social management 76

6.3 social managementThe social-management focuses on social needs and therefore, the socialconnections between volunteers. Also, the liveliness of the iVolunteer-App requires the highest priority because volunteers are willing to getanimated to check the iVolunteerApp to be up to date permanently.Currently, the implementation of the social-management covers only aprototype implementation of the proposed user interface (UI). Withinthis prototype implementation, specifically the your profile (see section3.2.2 and the get connected page (see section 3.2.6) target on the socialneeds of volunteers. Additionally missing is the (i) chat and (ii) groupfunctionalities for volunteers.The social-management part of iVolunteer is an essential part of iVolun-teer. Therefore, our proposed UI-Functionality is just a small piece ofthe essential functions.

6.4 competence managementLast, the competence-management implementations is currently coveringthe retrievement of competencies, the idea for improving the competence-management is organizing competencies based on a global ontology.Within this ontology, a set of concepts and categories of competenciesshould be provided together with the relations between the compe-tencies. That opens up new volunteer opportunities in competence-management - for instance, the suggestion of competencies to increasethe competency profile of a volunteer. Also, competence recognition ofother marketplaces would be improved.

B I B L I O G R A P H Y

[1] Cravens, J., and Jackson, R. Survey of software tools usedto track and manage volunteer information. http://www.coyotecommunications.com/tech/volmanagesoftware.pdf, 2012.Accessed: 2020-01-01.

[2] Freeman, A. Using Web Storage. Apress, Berkeley, CA, 2011,pp. 987–996.

[3] Institut für anwendungsorientierte Wissensverarbeitung

(FAW), Johannes Kepler University Linz. MultidisziplinäreUnterstützung kooperativer Aktivitäten in Kooperationsnetzw-erken. https://www.ffg.at/sites/default/files/allgemeine_

downloads/strukturprogramme/coinnet_7as_crac.pdf, 2014. Ac-cessed: 2020-01-01.

[4] Institut für anwendungsorientierte Wissensverarbeitung

(FAW), Johannes Kepler University Linz. Eine DigitalePlattform zur Nutzbarmachung informeller Kompetenzen imFreiwilligenbereich. https://www.ffg.at/sites/default/files/allgemeine_downloads/strukturprogramme/kurzfassung_

ivolunteer.pdf, 2018. Accessed: 2020-01-01.

[5] Kappel, G., Rausch-Schott, S., and Retschitzegger, W. Coordi-nation in workflow management systems - a rule-based approach.In Coordination Technology for Collaborative Applications - Organiza-tions, Processes, and Agents [ASIAN 1996 Workshop] (London, UK,UK, 1998), Springer-Verlag, pp. 99–120.

[6] Kapsammer, E., Kimmerstorfer, E., Pröll, B., Retschitzegger,W., Schwinger, W., Schönböck, J., Dürk, N., Rossi, G., and

Gordillo, S. iVOLUNTEER: a digital ecosystem for life-longvolunteering. In Proceedings of the 19th International Conference onInformation Integration and Web-based Applications & Services (2017),pp. 366–372.

[7] MERRILL, M. V. Global trends and the challenges for volunteering.International Journal of Volunteer Administration 24.1 (2006), pp. 6–14.

[8] Mundbrod, N., Beuter, F., and Reichert, M. Supportingknowledge-intensive processes through integrated task lifecyclesupport. In 2015 IEEE 19th International Enterprise Distributed ObjectComputing Conference (Sept. 2015), pp. 19–28.

[9] Mundbrod, N., and Reichert, M. Configurable and executabletask structures supporting knowledge-intensive processes. In 36thInternational Conference on Conceptual Modelling (ER 2017) (Nov.2017), no. 10650 in LNCS, Springer, pp. 388–402.

77

http://www.coyotecommunications.com/tech/volmanagesoftware.pdf

http://www.coyotecommunications.com/tech/volmanagesoftware.pdf

https://www.ffg.at/sites/default/files/allgemeine_downloads/strukturprogramme/coinnet_7as_crac.pdf

https://www.ffg.at/sites/default/files/allgemeine_downloads/strukturprogramme/coinnet_7as_crac.pdf

https://www.ffg.at/sites/default/files/allgemeine_downloads/strukturprogramme/kurzfassung_ivolunteer.pdf



bibliography 78

[10] Mundbrod, N., and Reichert, M. Flexible task managementsupport for knowledge-intensive processes. In 21st IEEE Int’lEnterprise Distributed Object Computing Conference (EDOC 2017)(Oct. 2017), IEEE, pp. 95–102.

[11] Raab, M. A prototypical approach for a competency-based task al-location system in the context of voluntary organizations. Master’sthesis, University of Applied Science Upper Austria Hagenberg,2016.

[12] Salamon, L. M., and Sokolowski, W. Beyond Nonprofits: In Searchof the Third Sector. Springer International Publishing, 2018, pp. 7–48.ISBN: 978-3-319-71473-8.

[13] Salamon, L. M., and Sokolowski, W. The Size and Composition ofthe European Third Sector. Springer International Publishing, 2018,pp. 49–94. ISBN: 978-3-319-71473-8.

[14] Salamon, Lester M. and Sokolowski, S. Wojciech and Had-dock, Megan A. and Tice, Helen S. The state of global civil societyand volunteering. Johns Hopkins University Center for Civil SocietyStudies, 2013. ISBN: 1-886333-63-7.

[15] Schönböck, J., Altmann, J., Kapsammer, E., Kimmerstorfer, E.,Pröll, B., Retschitzegger, W., and Schwinger, W. A SemanticMatchMaking Framework for Volunteering MarketPlaces. In Trendsand Advances in Information Systems and Technologies (2018), SpringerInternational Publishing, pp. 701–711.

[16] Schönböck, J., Raab, M., Altmann, J., Kapsammer, E., Kusel,A., Pröll, B., Retschitzegger, W., and Schwinger, W. A surveyon volunteer management systems. In 49th Hawaii InternationalConference on System Sciences (HICSS) (2016), pp. 767–776.

[17] Statistics Canada. Volunteering in canada. https://www150.statcan.gc.ca/n1/en/pub/11-008-x/2012001/article/11638-eng.pdf?st=RB8dZYBf, 2012. Accessed: 2020-01-01.

[18] United Nations Volunteers. State of the World’s VolunteerismReport. https://www.unv.org/sites/default/files/UNV_SWVR_

2018_English_WEB.pdf, 2018. Accessed: 2020-01-01.

[19] Weißenbek, M. Towards decentralized Volunteer ManagementSystems – Conceptual Approach & Architecture. Master’s thesis,JKU Linz, Dept. of Cooperative Information Systems, 2019.

https://www150.statcan.gc.ca/n1/en/pub/11-008-x/2012001/article/11638-eng.pdf?st=RB8dZYBf



https://www.unv.org/sites/default/files/UNV_SWVR_2018_English_WEB.pdf

https://www.unv.org/sites/default/files/UNV_SWVR_2018_English_WEB.pdf

iVolunteer - Towards a Multitenant and Trustable Volunteer ...

Documents

Transcript of iVolunteer - Towards a Multitenant and Trustable Volunteer ...