Using Azure, Office 365, C# and Xamarin to Make a Multiuser, Multiplatform Extensible Law Practice Management Cloud Application
The Harvard community has made this article openly available. Please share how this access benefits you. Your story matters
Citation Migkiros, Pavlos. 2016. Using Azure, Office 365, C# and Xamarin to Make a Multiuser, Multiplatform Extensible Law Practice Management Cloud Application. Master's thesis, Harvard Extension School.
Citable link http://nrs.harvard.edu/urn-3:HUL.InstRepos:33797318
Terms of Use This article was downloaded from Harvard University’s DASH repository, and is made available under the terms and conditions applicable to Other Posted Material, as set forth at http:// nrs.harvard.edu/urn-3:HUL.InstRepos:dash.current.terms-of- use#LAA
Using Azure, Office 365, C# and Xamarin to make a Multiuser, Multiplatform extensible Law Practice Management Cloud Application
Pavlos Migkiros
A Thesis in the Field of Information Technology
for the Degree of Master of Liberal Arts in Extension Studies
Harvard University
May 2016
Abstract
Besides the strictly legal duties and tasks of legal professionals, law practice requires also management; keeping track of cases and their related resources, such as files, deadlines, clients, and tasks. Managing these resources can be simplified with specialized software, which also provides collaboration and resource sharing capabilities to support working groups and organizations. The scope of this thesis is to design and implement a low cost law practice management software prototype. While such software solutions already exist, we will show that there is still room for improvement by integrating it with some of the most commonly used productivity tools and technologies, namely Microsoft
Office 365. Many users and organizations use Outlook for their emails, OneDrive for their file system, and probably more such tools. So, the objective of this thesis is to allow them to keep using these tools along with a specialized law practice management tool, instead of creating an entirely new platform.
To achieve this goal, we leverage cloud development. We integrate Office 365, using Microsoft Graph API, with a custom PaaS (Platform as a Service) service implemented on Microsoft Azure, to provide a unified cloud backend service. Cloud services, design patterns and the relatively recent technological advances, such as Xamarin, simplify multiplatform development. We also provide two client applications, a Windows
Desktop (WPF) client that offers full functionality, and an Android mobile client that offers lightweight functionality, as well as a basic ASP .NET website.
Dedication
Switching paths from geology to software engineering through this degree was a gamble that required courage, drive, determination and a lot of hard work. None of this would be possible without Foteinis’ love, inspiration, encouragement and support.
Therefore, I want to dedicate this work to her.
I also want to deeply thank my parents, Eirini and Petros, who have always been there for me in so many ways.
Thank you…
iv Acknowledgments
I would like to express my gratitude to my thesis advisor Paul Holley for his contribution, his valuable ideas, his guidance, for being reachable and direct, and for allowing me the freedom to explore by my own. I would also like to thank Dr. Jeff Parker for his great advice and cooperation, especially during the process of forming this thesis and for his great contribution on the write-up section.
v Table of Contents
Table of Contents ...... vi
List of Figures ...... ix
List of Tables ...... xii
Chapter 1 Introduction ...... 1
Goals & Motivation ...... 1
Law Practice management & LPMS ...... 1
Overview of this document ...... 5
Chapter 2 Technology choices & the cloud ...... 6
Chapter 3 Prior work ...... 10
Chapter 4 Azure Active Directory & Office 365 ...... 14
Active Directory ...... 14
Office 365 - Office 365 API - Microsoft Graph API ...... 18
Chapter 5 LPMS Functional Requirements ...... 21
Law Practice Management Model & Core Functional Requirements ...... 23
Resource Location (Azure SQL & Office 365) – Authentication, Authorization & the
Registration Process ...... 27
Collaboration ...... 32
Collaboration Modes ...... 33
Roles ...... 35
Real Time Updates ...... 37
Communication ...... 38
vi Complete Description of Resources, System Requirements & Permissions ...... 39
Client Applications ...... 45
Windows Desktop (WPF) Client Application ...... 45
Android Mobile Client Application ...... 50
ASP .NET Website ...... 52
Chapter 6 Design Specifications ...... 55
Design Specification Choices – Discussion & Objectives ...... 57
Accessing Resources Azure SQL O365 & Microsoft Graph API ...... 60
Web API ...... 65
Live chat & Real Time Updates using SignalR 2 ...... 68
LPMS Sequence diagrams ...... 70
Client Applications ...... 74
Windows Desktop Client Application ...... 74
Android Client ...... 77
Chapter 7 Summary and Conclusions ...... 78
Glossary ...... 83
References ...... 85
Appendix I ...... 89
Azure AD ...... 89
SignalR 2 – Live updates & live chat ...... 91
Additional Sequence Diagrams ...... 95
Sample request, and response of a user of LPMS to update his profile ...... 97
Appendix II - External software libraries used in the thesis ...... 99
vii
viii List of Figures
Figure 1. Evolution of law practice management ...... 3
Figure 2. Comparison of responsibilities of on-premises and cloud service categories
(Greiner, 2014) ...... 7
Figure 3. High level system architecture diagram ...... 9
Figure 4. Azure Active Directory integration and capabilities, (Vilcinskas, 2016) ...... 14
Figure 5. Azure AD basic authentication flow, (Baldwin, 2016) ...... 16
Figure 6. LPMS communication flows from client to Web API and Office 365 ...... 16
Figure 7. LPMS configuration of permissions to other applications, in Azure portal ...... 17
Figure 8. Azure AD consent page for LPMS ...... 18
Figure 9. Office 365 Unified groups, image from (Patel, 2015)...... 20
Figure 10. Conceptual basic law practice and case management model ...... 23
Figure 11. Case management use-case diagram. The different colors on the diagram highlight the different resources ...... 24
Figure 12. Possible workflow for creating a new case and adding resources ...... 25
Figure 13. Windows desktop screenshot of the Case UI ...... 26
Figure 14. Location of LPMS resources ...... 27
Figure 15. LPMS organization and user registration process flow diagram ...... 29
Figure 16. Registration and profile use case diagram ...... 31
Figure 17. Sample workflow of a lawyer to create a new case and share it with another participant ...... 32
Figure 18. Role hierarchy diagram for the available roles in LPMS ...... 36
ix Figure 19. Windows desktop client screenshot of the case live chat ...... 39
Figure 20. Windows desktop screenshot showing the application toolbar ...... 47
Figure 21. Login and Registration UIs of the Windows Desktop client application ...... 47
Figure 22. Screenshot of the Windows desktop client showing the profile UI ...... 48
Figure 23. Windows desktop screenshot of the Client UI ...... 48
Figure 24. Windows desktop screenshot of the Tasks UI ...... 49
Figure 25. Screenshot of the details and edit form dialog, of the Windows client application for Case Events Windows ...... 49
Figure 26. Screenshot of the wizards for creating a new case, a new event and a new task
...... 50
Figure 27. Mobile Android client screenshots (1) ...... 51
Figure 28. Mobile Android client screenshots (2) ...... 51
Figure 29. LPMS website - Home page ...... 52
Figure 30. LPMS website - registered lawyers ...... 53
Figure 31. LPMS website cases of a registered lawyer ...... 53
Figure 32. LPMS website case details, for a case of a registered lawyer ...... 53
Figure 33. LPMS website case details, for a case of a registered lawyer ...... 54
Figure 34. LPMS Architecture ...... 55
Figure 35. LPMS communication flows ...... 57
Figure 36. SQL DB ER diagram showing the core entities and their relationships ...... 62
Figure 37 Complete SQL Database diagram...... 63
Figure 38. Microsoft Graph API REST calls to the, to create an O365 group, and obtain group resources ...... 65
x Figure 39. Sequence diagram showing the process of creating a new case ...... 71
Figure 40. Sequence diagram showing the process of accepting pending invitations and adding new case members to the O365 group for the case ...... 72
Figure 41. Sequence diagram showing the process of adding new resources to a case ... 73
Figure 42. Windows Desktop client architecture ...... 75
Figure 43. LPMS communication flows from client to Web API and Office 365 ...... 89
Figure 44. Native Application to Web API, (Baldwin, 2016) ...... 90
Figure 45. Web Application to Web API, (Baldwin, 2016) ...... 91
Figure 46. SignalR high-level architecture ...... 92
Figure 47. Sequence diagram for connecting to the SignalR hub, logging in the client, and registering to case SignalR groups ...... 92
Figure 48. Sequence diagram showing the flow of operations when a resource is deleted with respect to SignalR ...... 94
Figure 49. Sequence diagram showing the flow of the chat messages with respect to
SignalR ...... 94
Figure 50. Sequence diagram for registering a new organization with LPMS ...... 95
Figure 51. Sequence diagram showing the login process in LPMS ...... 96
xi List of Tables
Table 1. Core functional requirements of LPMS at a glance ...... 4
Table 2. Summary of cloud advantages and disadvantages ...... 6
Table 3. Features comparison of some of the available law practice application, including
LPMS ...... 11
Table 4. Sample features of Office 365 ...... 19
Table 5. LPMS high-level functional specifications...... 21
Table 6. LPMS supported platforms ...... 22
Table 7. Example of cost of a case based on the tasks that have been performed ...... 24
Table 8. Resource persistence after users’ unregistration ...... 30
Table 9. LPMS roles ...... 35
Table 10. List of live update support features...... 38
Table 11. LPMS resources ...... 39
Table 12. List of available operations for users ...... 42
Table 13. List of available operations for administrators ...... 45
Table 14. User interfaces of the Windows Desktop client application ...... 46
Table 15. Functionality ot the Android mobile application ...... 52
Table 16. LPMS core system components description ...... 56
Table 17. LPMS API REST controllers ...... 66
Table 18. Android client application, glimpse of tech specs ...... 77
xii Chapter 1 Introduction
Goals & Motivation
The goal of this thesis was to create a productivity tool to help law practitioners with the administration and management tasks of their work, such as managing their cases, their case files, and case deadlines. In addition, we tried to simplify collaboration and resource sharing to facilitate team projects, and integrate it with commonly used technologies like the Office 365.
The motive behind this selection was very simple. As in most cases, everyday needs determine technology solutions. Such a need for low cost law management tool from a friend of mine, and my fascination with productivity tools urged me to create this application.
Motivated by modern technologies and their capabilities, and interested in .NET, we wanted to leverage the power of the cloud, REST development, and multiplatform development by building a cloud service, along with its client applications, using C#.
Law Practice management & LPMS
Law practice management can be defined as the administrative process of managing the relevant resources to law practice. It can be applied both on an individual level, as well
1 as on a business level. Some typical resources associated with law practice management are: cases, clients, documents, and deadlines.
We are no experts in law practice, so we will not be giving formal detailed law practice definitions and routines. Instead, let’s see what law practice management looks like in practice, and how a law practice management application can assist, based on a fictional example.
Imagine that you are a lawyer, and within the past 5 years, you had 15 clients and
20 cases. For each case you had on average 20 documents, and 15 deadlines/meetings.
Now, you are working in three different cases, on the first one alone, and on the other two with two different groups of lawyers and paralegals. This is already a lot of information, many names, tons of paperwork, many dates, and you have to keep track of all. On top of that, and because you are very meticulous, you also want to keep track of what you have done for each case, when, for how long, and what did you charge.
This is only getting bigger…
But, you have tools to help you, such as your computer. You can keep track of your cases, their details and the work you have done on Microsoft Excel spreadsheets, perhaps you use Microsoft Outlook to store your contacts, clients and communicate with others, you use your calendar for the deadlines, and of course you have your file system to store your documents.
This is getting better, but still it is up to you to set this up, organize and maintain it properly. If you work alone, and you are well organized, this is fine, but what about those team cases you are working on at the moment? What if your colleagues are not like you well organized? And what about sharing documents, synchronizing calendars and keeping
2 track of all of your work on a team level? Finally, what if you are not a freelancer and you are working in a law firm? The law firm would certainly want to be able to keep track and administer all of these resources for all its employees.
Well, it seems that at this point, it would be nice to get a law practice management application to help you with your work. This is the goal of the Law Practice Management
System (LPMS), implemented for this thesis. It wants to get you from tons of files, notes and independent unrelated applications, to one integrated solution with which you will manage your cases easily and effectively, and collaborate with others.
Figure 1. Evolution of law practice management
So, why build one more law practice management application if there are many already other out there that do a great job? First and foremost, LPMS is a sort of a prototype application, not a commercial product, so we are not trying to compete with these software packages. What we tried to do different, is producing a low cost alternative that uses the modern cloud Software as a Service approach to its advantage. This allows users to keep using their general tools, with which they are already familiar with, along with a specialized application for their law practice management needs. This is achieved by integrating LPMS with the increasingly popular Office 365, referred to as O365 from now on, (Office, n.d.).
Many people use Microsoft Office productivity tools, either using the MS Office suite installed on a computer, or using the cloud based version. So, by integrating these tools to
3 the custom law practice management applications, users and organizations will use common storage and calendar for both the application and other business or personal files.
The requirements for LPMS, have been assembled as a combination of strictly law practice management functional requirements, and technological choices, like the use of the newly released Microsoft Graph API (Microsoft Graph - Home, n.d.), which provides access to O365. The law practice management requirements have been determined from discussions with lawyers regarding their needs, along with research on the available law practice management applications. The core requirements of LPMS at a glance are shown in Table 1:
Table 1. Core functional requirements of LPMS at a glance
Manage clients ˗ Client profiles ˗ Keep track of payments
˗ Case details ˗ Case cost Manage cases ˗ Case files ˗ Case deadlines ˗ Case tasks (work done) ˗ Case to-do-items
˗ Share case resources Collaborate ˗ Invite new team members ˗ Assign team roles ˗ Communicate effectively (case-based live chat)
LPMS targets three categories of users: (1) individual users that want to work alone,
(2) individual users that want to collaborate with others, and (3) organizations.
Unfortunately, the limitations of O365 and Microsoft Graph API at the moment pose
4 certain restrictions on the individual user collaboration mode. However, we propose a temporary solution for these users, until O365 extends its functionality according to their roadmap.
Overview of this document
This document describes the design and implementation of LPMS. It starts with a short description on the technological choices, next acknowledges the existing law practice management application, including a short comparison to LPMS, and finally it delves into the functional and design specifications of the system. The outline of the chapters is given below:
˗ Chapter 2 describes the technology choices made for LPMS
˗ Chapter 3 cites prior work in law practice management applications
˗ Chapter 4 is a short introduction on two key technologies used in LPMS (Azure
Active Directory, Azure AD from now on, (Vilcinskas, 2016) and O365)
˗ Chapter 5 describes the functional specifications of LPMS
˗ Chapter 6 describes a big part of the design specifications of LPMS
˗ Chapter 7 describes some conclusions and future work suggestions
5 Chapter 2 Technology choices & the cloud
The technology choices were made based on the functional requirements, and personal preferences on technologies that we wanted to explore deeper.
Based on the collaboration functional requirements of the application, it was chosen to build the system as a client-server, using the cloud for the service backend, where access to resources is authenticated and authorized. Having all users’ resources stored on the cloud, facilitates resource sharing and any time access. Table 2 below summarizes some of the cloud advantages and disadvantages, as documented in several books, publications and blogs (Delaney, n.d.), (Miller, 2008), (Sean, Subhajyoti , Juheng , & Anand, 2011):
Table 2. Summary of cloud advantages and disadvantages
Advantages Disadvantages Almost unlimited storage It requires a constant internet Computer power connection Cost efficiency It is limited by internet connection Backup and recovery speed Scalability and performance Security and privacy (sometimes) Accessibility to resources Collaboration made easy
It was preferred to use a cloud PaaS (Platform as a Service) instead of an IaaS
(Infrastructure as a Service), or an on-premises installation, because the first requires the least effort to implement, manage and maintain, (Greiner, 2014). In the PaaS, contrary to
IaaS, the cloud platform providers handle all low-level tasks, like computer hardware and specifications of virtual machines, so developers can focus on the application rather than
6 the infrastructure. Furthermore, the on-premises installation has an additional disadvantage, which is the higher infrastructure cost. Figure 2 below summarizes very well the differences among these services, (Greiner, 2014). We also discuss our choices on this subject, in Chapter 6 .
Figure 2. Comparison of responsibilities of on-premises and cloud service categories
(Greiner, 2014)
O365 is SaaS (Software as a Service) service that offers many features, like cloud storage, email, calendar and groups. By exposing programmatic access, through the Office
365 APIs and the Microsoft Graph API, O365 can also be treated as a PaaS service, which can be integrated to other applications. We chose to integrate O365 with LPMS for two reasons:
1. Its powerful features for files and calendars (LPMS is currently using just a
glimpse of O365 capabilities)
2. To give flexibility and ease of use to the users.
7 Along with Office 365, comes Azure AD, which is handling authentication and authorization for O365. Using Azure AD in LPMS also gives great power for authentication, authorization and integration with other Azure AD applications.
Finally, we chose to develop two native client applications, a Windows Desktop
WPF application, that entirely consumes the service, and a lightweight Android mobile application using Xamarin. Taking advantage of the ease of implementation of an ASP
.NET along with the Web API using the Visual Studio templates, a basic ASP .NET application has also been implemented. The cloud component, ASP .NET, Web API, and a SQL database, has been implemented on Microsoft Azure (Microsoft Azure: Cloud
Computing Platform & Services, n.d.).
To summarize, the technologies that have been used for the implementation of
LPMS are the following, shown also in the system architecture diagram of Figure 1:
Azure SQL database, (Structured Query Language (SQL), n.d.), (SQL
Database - Relational database service | Microsoft , n.d.)
Azure ASP-.NET Web API, (The Official Microsoft ASP.NET Site, n.d.),
(Learn About ASP.NET Web API, n.d.)
Azure AD, (Vilcinskas, 2016)
Office 365 - Microsoft Graph API, (Microsoft Graph - Home, n.d.)
Windows Desktop WPF application, (Windows Presentation Foundation,
n.d.)
Native Android mobile application, implemented with Xamarin, (Mobile
App Development & App Creation Software, Xamarin, n.d.)
8
Figure 3. High level system architecture diagram
9 Chapter 3 Prior work
A law practice management software is not a new category of software; many commercial law practice management software solutions already exist. This section acknowledges the existing law practice management software and, compares the features of some selected software against LPMS. Also it outlines the different perspective LPMS tries to give in designing and developing this type of software.
Currently, there is a large number of available commercial law practice management software offering a wide and complete range of features, which proves that there is a need and a robust market. These come in many flavors, from locally installed, to web based, and/or mobile, supporting single user and/or collaboration, as well as businesses. The Capterra website (Top Law Practice Management Software Products, n.d.) has performed a very thorough search on the available law practice management software, providing a unified feature checklist that covers effectively the law practice management software requirements and offerings, as well as user ratings and reviews. This is a great starting point to find and evaluate the available software, and much of the information provided in this section is based on it. We have selected two of these software to evaluate
(Clio and HoudiniESQ), which have been proven worthy, providing the required functionality and a user friendly interface. Briefly, LPMS compared to these provides a low cost alternative integrated with commonly used tools giving flexibility and ease of use to the end users. The difference is described in more detail at the end of this section.
Table 3 shows the features of some selected law practice management software, based on the information provided by Capterra website, and verified by the software
10 providers’ websites. The selected software solutions have been chosen based on the number of users, the users’ reviews, and the available information. Software that do not have a description and purchasing website have not been included, and software that do not expose pricing information have not been included also. Finally, Table 3 includes LPMS in order to have a direct comparison of the proposed software features.
Table 3. Features comparison of some of the available law practice application, including
LPMS
Houdini Abacus Legal Pc My Feature Clio LPMS ESQ Law Trek Law Case Billing & Invoicing Calendar Management Case & Client History Case Management Client Management Client Portal Conflict Management Contact Management Contract Management Document Management Email Management Financial Management HR Management Records Management Task Management Time Tracking Trust Accounting
Web and/or Cloud Based Mobile Version Installed (PC or MAC version)
As it can be seen from Table 3 all of the software cover the basic functionality related to case management, which comes down to creating the law cases, associating them
11 to clients, time tracking, document management, and calendar management. Some provide a more complete range of features, like HoudiniESQ that offers also a client portal and HR management. Others can be integrated with products either from the same company or from
3rd party companies. For example, Clio can work with a number of other applications like
Agile Law, ClickToFile, and DropBox; PCLaw can synchronize with Microsoft Outlook,
Google Calendar and Microsoft Exchange. Their price range fluctuates significantly, from
33$ to 65$ per month, and it has to be noted that the price includes support, and may include other service services like courses.
Building Project Management or CRM (customer relationship management) software is not an easy task, and especially when it has to deal with sensitive data like those used in law practice, where security and safety have a primary role. Therefore, it would be exaggeration to claim that a software which includes all of the above can be designed and built within the context of a thesis. On the other hand, this does not mean that LPMS cannot provide a new perspective, using currently trending development concepts on building this type of software for law practice management.
A huge trend in IT is shifting from local premise installations to the cloud, with the small businesses being at the top of the list (Politis, 2015). Within this context the adoption of Office 365 and similar services/software like Google for Work is also increasing, so why not build systems that are integrated with those technologies, if it is worthwhile? This is the concept that LPMS relies on, and in the case of law practice management Office 365 can cover a large number of requirements. From the research performed on the available law practice management software none of them is natively integrated with Office 365, or
Google for Work. Doing that with LPMS not only gives the already mentioned advantage
12 of users using these “universal” platforms integrated with applications specific to their needs, but it also reduces the cost per user since the end user obtains both a law practice management application and an Office 365 product.
Finally, as a pricing indication for LPMS, the current infrastructure cost per month according to the Azure pricing calculator, i.e. for hosting the service on Azure, is 74$.
Assuming now that there are 10 users who share this cost equally, the cost per user per month would be 7.4$. If the number of users increases to 100, then this cost reduces to 0.74 per user, which is negligible. However, in order to use the system, they would first have to have an O365 license which costs between 8-15$. So, the total cost for a user would be between 15.4-22.4$, which is not that expensive considering that at the same time they will have purchased an O365 license and all its benefits.
13 Chapter 4 Azure Active Directory & Office 365
LPMS relies heavily on O365 and Azure AD services. Both have already been mentioned, and they will be mentioned several more times in the functional and design specifications. Therefore, before proceeding further, this section gives a brief introduction to both services, focusing primarily on the components used in LPMS.
Active Directory
“Azure active directory is Microsoft’s multi-tenant cloud based directory and
identity management service” (Vilcinskas, 2016).
Both LPMS and O365 use this service to authenticate, authorize users, and for single sign-on (SSO).
Figure 4. Azure Active Directory integration and capabilities, (Vilcinskas, 2016)
This section does not elaborate on what Azure AD is and what it offers, it rather references some basic terms and processes relevant to this thesis.
14 Tenant
A tenant is an instance of Azure AD that is dedicated to an organization. A tenant contains the users’ credentials and profiles, it can contain groups, and also applications,
(Strockis, 2015). If you have an Office 365 subscription you already have a tenant, and all the users in that subscription belong to this Azure AD tenant. The administrator of the subscription can view the users both from the Azure AD portal on Azure and from the
Office 365 Admin Portal. If an organization is using Azure AD for authentication and authorization, it can register and authenticate applications under its tenant, which can be accessed by all its members.
Single Tenant VS Multitenant Applications
There are two types of applications with respect to tenancy: single tenant applications and multitenant applications. Single tenant applications can be accessed only by the users of one tenant, the tenant they belong to. Multitenant applications on the other hand, can be accessed from many tenants, regardless of the tenant they belong to. LPMS is a multitenant application, and therefore, although it is registered under a specific tenant, it can be accessed by any other O365 tenant.
Authorization flow with Azure AD
The authentication process against Azure AD is based on two standard protocols:
OAuth 2.0 (Hardt, 2012), and OpenId Connect (Welcome to OpenID Connect, n.d.).
Although there are variations on the authentication flow depending on the setup of the components, the general scheme of this process at a high level is shown in Figure 5. What this diagram shows, without getting into detail, is that to access a Web Application on which access is authenticated with Azure AD, the users must first authenticate with Azure
15 AD and then call the application. Azure AD provides much more flexibility than that, like for example integrating the on-premises identities, but these services are out of the scope of this thesis.
Figure 5. Azure AD basic authentication flow, (Baldwin, 2016)
In the case of LPMS the authentication flow can be similar to the above, but it can also be more complex because it has an additional component, as shown in Figure 6. Both the Web API and O365 use Azure AD to authenticate access to their resources.
Figure 6. LPMS communication flows from client to Web API and Office 365
In case A of the above figure, the native client requests data from Azure only. This case is similar to the general authentication flow as shown in Figure 5. In B the native client
16 requests O365 resources through the Web API. So in this situation the Web API accesses
O365 on behalf of the user.
We provide some additional details on Azure AD authentication, and the authentication flows used in LPMS, in Appendix I.
Permissions to other applications and users consent
Enabling Azure AD applications to obtain permissions to access other Azure AD applications is a simple process done in the Azure Portal. The example below is a screenshot from the Azure Portal, which shows the configuration of the LPMS service to request permissions to access the Microsoft Graph API, or in other words Office 365. In this case LPMS is registering for permissions to access the directory as the signed in user, access users’ calendars, and users’ groups.
Figure 7. LPMS configuration of permissions to other applications, in Azure portal
Now that the application has its permissions configured, the last step is users consent. Today with the use of smartphones, most of us are familiar with concept of giving permission - consenting to a mobile application to access personal information or
17 resources, like contacts. A similar approach is also followed by Azure AD. To enable the application to access users’ resources on other applications, like O365, it requires the users consent. The screenshot below shows the consent page, as shown the first time a user authenticates with LPMS, according to the permissions to other applications of Figure 7 above.
Figure 8. Azure AD consent page for LPMS
Office 365 - Office 365 API - Microsoft Graph API
Office 365 is a cloud SaaS service offered by Microsoft, which includes a wide range of productivity software and subscriptions. For those that are not familiar with it the table below lists a few of its features. For more information, visit (Office 365 Service
Descriptions, 2015).
18 Table 4. Sample features of Office 365
Feature Description One Drive Cloud storage service Outlook calendar on the cloud. Outlook calendars can be easily Outlook Calendar shared, distributed and viewed among users One Note Cloud note taking application Skype for business Professional version for Skype integrated with O365 apps
O365 is one of the available modern tools for easy collaboration and any time access to resources. It is still not perfect, but very powerful, and constantly evolving. It offers out of the box high end security, reliability, it requires no on premises installations, it handles all low level tasks, requires minimal IT effort, and provides great flexibility to administrators including an easy to use administrator portal. These reasons constitute it a great candidate for small to mid-sized businesses, hence an increase on its usage during the last years, as mentioned earlier in this document.
Sharing data with Office 365 is very easy, and in fact, there are at least the following three ways to do it:
I. users can share a specific resource either with users of the same tenant, or
external users by changing the resource permissions
II. create a shared link and share the resources by shipping this link with
anyone,
III. and last but not least create working groups, O365 Unified groups, that
enable their participants to share groups of resources.
Since Office 365 uses Azure AD, each subscription has a corresponding Azure AD tenant. Resource sharing capabilities for users of the same tenant are more powerful than
19 those among users of different tenants. For example, it is not possible to add external users, i.e. users of other Azure AD tenants, to an O365 Unified group.
LPMS uses these Unified Groups for collaboration, allowing users to share case files and case events. Unified groups are a layer on top of several resources, which include files, calendars, conversations and more, as shown in Figure 9. As mentioned above, the drawback of using these groups is that at present it is not possible to add external users to the group. This limits the resource sharing capabilities of LPMS for now, but fortunately this feature is under development and will be available from Microsoft in the near future.
Figure 9. Office 365 Unified groups, image from (Patel, 2015)
It is possible to access O365 programmatically using either the individual Microsoft
REST APIs like Outlook and One Drive APIs (Office 365 APIs platform overview, 2015), or using the Microsoft Graph API, which is a unified endpoint that includes the already mentioned APIs and other Microsoft APIs. LPMS is using Microsoft Graph API.
20 Chapter 5 LPMS Functional Requirements
LPMS is a cloud-based solution for law practitioners that is designed to help individual lawyers as well as law firms. It supports project management both for single user projects as well as team projects. The system will allow its users to:
keep track and organize all of their cases along with their associated
resources,
enable them to collaborate easily and effectively by making resource
sharing trivial,
provide any time access to their resources by storing them on the cloud,
and enable them to use O365 along with LPMS.
LPMS achieves this by using a web service integrated with Office 365, as a cloud service backend, which can be accessed using:
1. A Windows Desktop (WPF) client application that provides complete
functionality
2. A lightweight Android mobile client application, and
3. An ASP .NET website providing minimal functionality
At a high-level LPMS offers a number of law practice management services as shown in Table 5, and a supports many platforms as listed in Table 6.
Table 5. LPMS high-level functional specifications
Functional Requirements
21 Billing & Invoicing Create PDF reports for the cases based on the tasks of each case Calendar Create edit and delete case events using the Outlook Calendar Management of the O365 Group associated with the case Case & Client Maintains the data for all cases and clients until explicitly History deleted Creation and case management for single user and collaboration Case Management modes Client Management Create, edit and delete clients Conflict Check whether the case owner has any other case against the Management client, or represents the opponent in any other case Document Store, upload, download and delete case-related documents, Management these are stored in the One Drive of O365 groups Case Deadlines / Create events and deadlines and associate them with a case, Events these are created in Outlook Calendar of O365 groups Records Register submitted payments for cases Management Task Management Create, edit and delete tasks for each case Tasks have a start and end time and rate/hour ($), where LPMS Time Tracking computes the total time spent on each task and the total time for a selection of tasks To-Do-Items Create and edit a list of To-Do-Items related to each case Management Offers a case-based live chat feature, for communication among Live chat case participants
Table 6. LPMS supported platforms
Supported Platforms
Cloud Based / Web Web API, ASP .NET with limited functionality Mobile Version Lightweight Android client Windows Desktop (WPF) application, offering complete Installed (PC or MAC) functionality
22 Law Practice Management Model & Core Functional Requirements
In order to provide support for case management, we first defined a high-level case management model shown in Figure 10, that addresses the following questions:
I. What are the resources needed for law practice management?
II. How are these resources related to each other?
The model shows that the central resource is the Law Case and it is related to 4 groups of resources: (1) deadlines, (2) case files, (3) tasks, and (4) to-do-items.
Figure 10. Conceptual basic law practice and case management model
Each law case has a specific profit or cost, which is determined from the tasks that have been performed. This cost is the sum of all the work - the tasks - that has been completed for the case. The cost of each task is calculated simply as the time spent on it
23 multiplied by the hourly rate the lawyer charges for this task, as shown in the example below.
Table 7. Example of cost of a case based on the tasks that have been performed
Task Rate/hour ($) Duration (hours) Cost ($) Attend court 50 1 50 hearing Draft pleadings 60 2.5 150
Total: 3.5 200
In order to give a better insight on the requirements, we provide below a use case diagram, Figure 11, which highlights the functionality of LPMS, showing a large number of the available operations.
Figure 11. Case management use-case diagram. The different colors on the diagram
highlight the different resources
24 While the functionality shown in the diagram is self-descriptive, there are the following worth mentioning points on how resources are accessed and what is their relationship with each other:
All resources are associated with the lawyer
The Clients are independent resources accessed directly, and which can be
associated with cases
The lawyer can see all of the Clients’ cases through the Client
Law Cases are associated both with a Lawyer and a Client. They can be
accessed directly or viewed through the client
All other case resources are associated to the Law Case directly, to the client indirectly, and are accessed through the Law Case with the only exception being the tasks which can be viewed and edited independently, without this meaning that they lose their association to the case.
The diagram of Figure 12 shows a possible workflow followed by a lawyer to create a Law Case add Tasks, edit To-Do-Items and print an invoice.
Figure 12. Possible workflow for creating a new case and adding resources
25 Finally, we end up this section with a screenshot from the WPF client application, which shows the Case View that includes the details for the case, to provide a concrete visual example.
Figure 13. Windows desktop screenshot of the Case UI
26 Resource Location (Azure SQL & Office 365) – Authentication, Authorization &
the Registration Process
The resources shown in Figure 10 are stored in two separate locations: An Azure
SQL database and O365, as shown in the schematic diagram of Figure 14 below.
Specifically, each law case is associated with an O365 Unified Group, and utilizes the groups’ One Drive and Outlook Calendar resources to store case files and events/deadlines respectively.
Figure 14. Location of LPMS resources
Storing resources on Office 365 gives flexibility and more power to LPMS, but also imposes certain restrictions on the requirements. One such limitation has already been mentioned, which concerns the sharing capabilities of O365 groups.
As mentioned above, all resources are bound to a specific Law Case. While it is possible to create a hard link for the Law Case related resources stored in the SQL database using relational constraints, it is not possible to do so for the resources stored on Office
365, since these can be accessed from outside of LPMS. Therefore, a soft link is created
27 for the Case Files and Case Events instead. This poses another limitation on LPMS which is that users cannot be notified for changes to the O365 resources, that have been modified from outside of LPMS.
Storing resources on the cloud, Azure and O365, dictates that access to resources must be authenticated and authorized for data integrity and association of data to users.
Thus, to start using LPMS one must first register with the system and then sign in.
Since LPMS is integrated with O365, it uses Azure AD and the O365 credentials to authenticate users. Consequently, the users that want to register with the system must first have a valid Office 365 license, but this is not enough by itself. LPMS requires users consent to access the O365 resources, but typically in an organization the resources belong to the organization and not the user. Therefore, it is the administrators’ responsibility to grant consent to the application instead of the user. In order to comply with this requirement, LPMS requires the Global Administrator of the O365 tenant to register its organization/tenant first. From this point, the users of the tenant will be able to register individually and further decide for themselves whether they want to give consent to the application or not. A visualization of the registration process, as described in this paragraph is shown in Figure 15.
28
Figure 15. LPMS organization and user registration process flow diagram
Tenant Registration (assumes that the user is Global O365 Admin, otherwise registration fails)
1. Select whether the tenant and subsequently the users of this tenant can be
visible from users of other tenants
2. Sign in with Office 365 credentials
3. Consent to allow LPMS access O365 resources, (automatically redirected
to consent page by Azure AD). Note that no consent is required for the
tenant to where the application belongs.
4. From that point and on:
a. The tenant is successfully registered
b. The admin that registered the tenant is also successfully registered
29 User Registration (assumes that the tenant of the user is already registered, otherwise registration fails)
1. Fill in form (select role, add gender and description)
2. Sign in with O365 credentials
3. Consent to allow LPMS access the O365 resources (automatically
redirected to consent page by Azure AD). Note that if the user trying to
register belongs to the same tenant as LPMS, consent is not shown.
4. User is registered, but cannot use the system yet
5. When a user registers, the registration status is set to pending, but the user
can only use the system if his status is set to active. Therefore, the final step
is that the administrator of the tenant changes it to active.
Since tenants and users register with the system, they also have to be able to unregister from it. Unregistering follows certain rules that are described below. User unregistration leads the deletion of almost all users’ data from the system, as well as the deletion of the O365 groups that he owns, as listed in Table 8:
Table 8. Resource persistence after users’ unregistration
Deleted resources Persisted resources The cases owned by the user The users’ tasks for cases not owned The following case related resources, by the user for the owned cases: The tasks that belong to the cases ˗ O365 Unified group (files & owned by the unregistering user, events) which have been performed by other ˗ To-Do-Items users ˗ All tasks owned by the unregistered user The users’ clients The chat messages of the owned cases The users profile
30 Tenant unregistration leads to the deletion of all users, according to the rules shown in Table 8 above, including the removal of the tenant from the system. The tenants’ consent to the application is not removed since it is not within the responsibility and power of LPMS. Consent to the application can be removed from the O365 portal.
Global Admin unregistration follows the same process as the users unregistration, but there is one restriction. A global admin can unregister only if there is another global admin of the same tenant registered with an active registration status in the system. If there is no other global admin then the only available option to unregister is unregistration of the entire tenant.
Figure 16 shows a use case diagram that illustrates the functional specifications with respect to authentication and authorization as described here.
A. register organization B. unregister organization C. register user D. unregister user E. maintain the organizations profile F. maintain users profile
Figure 16. Registration and profile use case diagram
31 Collaboration
Working alone is rarely the case for most professions, and this is no different in law practice. For example, it is usual to create working groups for cases that include lawyers and paralegals, either within a company or among freelancers.
To support this, LPMS extends case management as described earlier by enabling the formation of groups from registered users. In these groups resource sharing for the case related resources is simple and efficient. It is easier to describe this with an example.
Figure 17, shows a possible workflow diagram illustrating the process followed by a lawyer to create a new law case and add participants to it.
Figure 17. Sample workflow of a lawyer to create a new case and share it with another
participant
In the above example lawyers “A” and “B” are already registered with the system and they belong to the same tenant. Lawyer “A” has already a list of clients and a list of
32 law cases. At this point lawyer “A” wants to create a new case for a new client and invite lawyer “B” to participate. The steps followed to achieve this are the following:
First, lawyer “A” creates a new client who is added to the list of clients
Then, creates a new law case, case “X”, setting the law case resources
accordingly and associates the law case to the new client
The next step is to find and invite lawyer “B” to the newly created case
To complete this process, lawyer “B” accepts the received invitation
From this point on, both lawyers have access to the case resources.
Collaboration Modes
As mentioned, resources live in two locations, an Azure SQL database and Office
365, and configuring resource sharing is different in each. Resource sharing for the data on the Azure SQL database is handled entirely by LPMS and it can be very flexible. On the other hand, resource sharing for the Office 365 relies on O365 Unified Groups, which imposes certain restriction.
The Ambitious Plan
LPMS is intended to be used from (1) users that want to collaborate with any other registered user - cross-tenant collaboration, (2) from companies that want to allow collaboration with any other registered user or organization - cross-tenant collaboration again, and (3) from companies that want to restrict collaboration only within their organization - intra-tenant collaboration.
This is fairly simple to do in LPMS both at a tenant level and at a user level. At the tenant level, you only have to specify whether your tenant is publicly visible or not, which
33 determines whether its users can be retrieved, and subsequently get invited or invite to cases, from or by users of other tenants. At the user level, users have also the freedom to set their profile to public or private, without this meaning that they can override the general tenants setting. For example, if a company does not want their users to work with users outside its tenant, then they can simply set the visibility of the organization to private and they can only view users of their own tenant.
In practice however complete cross-tenant collaboration for the LPMS needs is not yet possible due to the present capabilities of the O365 Unified groups, as described below.
The Problem – O365 Groups
O365 Unified groups, for now, do not allow the addition of external users to the group. This means that even if users of other tenants are retrievable from within LPMS, they cannot get invited to the O365 unified group associated with the case, and therefore they will not be able to get the Case Events and the Case Files. So, for now collaboration is available only to users of the same tenant.
O365 offers also other resource sharing mechanisms that could have been used instead of the O365 groups, but both have been rejected. One way would be to share individual resources, but the problem with this approach is that at the time it is not available to create new permissions for a drive item programmatically using O365 APIs or Microsoft
Graph API. It is only available to update or delete existing permissions. Another way would be to create and ship shared links for resources, which does not fit to LPMS requirements because the users want to see their resources and not to be redirected.
Temporary Solution for Individual users
34 To support individual users that do not belong to an organization and want to collaborate with any other individual user, a temporary solution is to use a common public
O365 subscription with licenses for the different users. For example, for the needs of
LPMS, an Enterprise Office 365 subscription can be purchased and all individual users that want to register can request a license for this subscription.
Permanent Solution
A permanent solution to this problem can only be given once the O365 Groups support the addition of external users, which is under development according to the Office
365 team. LPMS is designed in a way that when O365 groups cross-tenant functionality becomes available, it will most probably need no changes to incorporate it.
Roles
In a collaboration scenario, and in organizations, delegation of responsibilities and hierarchy are important. For this reason, a critical feature to add is support for different roles. LPMS supports two levels of roles, (1) system level roles – the role of the user with respect to the system, and (2) case level roles – the role of the user with respect to a specific law case.
Table 9. LPMS roles
System level roles Case level roles define the role of a user in a shared general purpose business roles case Global Administrators Case owner Administrators Case Administrator Lawyers Case participant Paralegals System Level Roles
35 Two groups of system roles are supported: Administrators and Users. The difference between these groups is that Users have access only to those resources associated with them, while Administrators can access resources of other users too. For example, an Administrator can change the role of a user, and delete or edit a task of a user.
Note that system roles are confined within premises of each tenant. The supported system level roles are 4, as shown in Figure 18.
A. Global Administrators
B. Administrators
C. Lawyers
D. Paralegals
Figure 18. Role hierarchy diagram for the available roles in LPMS
A detailed list of the responsibilities of each role has been provided in the Complete
Description of Resources, System Requirements & Permissions section of this chapter, at
Table 12 and Table 13.
Administrators
The need to support two different administrator roles arises from the use O365.
Global Administrators can only be users who are also global administrators of the O365 tenant. What distinguishes Global Administrators from Administrators is that the former
36 can access and modify the O365 Groups on behalf of other users, without being part of the group, while the later cannot because they lack the required O365 permissions. For example, Global Administrators can delete a group, or add files to the Groups Drive, without being members of the group, while simple admins cannot.
Since a case is associated with an Office 365 group, when a case is deleted the O365 group should also be deleted. A simple administrator could not do this because of the lack of the required O365 permissions.
Users
Users are either Lawyers or Paralegals. There is only one difference between these two roles, which is that Paralegals cannot create a Law Case.
Case Level Roles
It is fairly usual in teams to have different roles in team projects, and LPMS supports this concept by providing the following case level roles:
1. Case Owner
2. Case Administrators
3. Case Participants
Each case has only one Owner, but it can have any number of Case Administrators and Case Participants.
Real Time Updates
Another important feature in a collaboration scenario is getting notified and updated for remote changes to shared resources at real time. For example, when a lawyer is invited to a new case he wants to get this invitation automatically in real time without having to refresh the page multiple times in case one arrives. Respectively, when he accepts or rejects
37 the invitation the other party would want to see the response immediately. It is also very important when a user works on the case resources to always have the latest updates, for example that a new event, or a new to-do-item has been remotely added.
LPMS supports real time updates and notifications for any shared resource in the system, as listed in Table 10. These updates, though, are only consistent when the resources are modified through LPMS. O365 resources, namely events and files or folders, which are edited from outside of LPMS, do not push any updates to LPMS since O365 does not provide a mechanism for notifications yet.
Table 10. List of live update support features
User invited to case User accepts/rejects invitation New member added to case Member removed from case New task added to case Task deleted from case Task updated New event created Event deleted Only if modified within LPMS. If Event updated modified through O365 Event updated / notifications and data updates New File or folder / are not pushed. File or folder deleted / New to-do-item To-do-item deleted To-do-item updated
Communication
Finally, communication in team projects is very important. For this purpose, LPMS provides a case-live-chat feature, which the participants of each case can use to
38 communicate with each other. Figure 19 shows a screenshot from the WPF client for the chat of a logged in lawyer who has two cases, “Case for company X” and “… Test Case”.
From the list on the right the lawyer can pick a case chat room, and on the right he/she can view and send messages to the participants of the case.
Figure 19. Windows desktop client screenshot of the case live chat
Complete Description of Resources, System Requirements & Permissions
Now that the main idea for the requirements has been provided, we show below, in
Table 11, what each resource is in more detail. This table includes a description of each resource, its properties, as well as its association to the other system resources. The properties formatted with italics are references to other resources of the system.
Table 11. LPMS resources
Tenant Profile
39 The tenants represent an organization or group of people. The tenant is the same tenant of the O365 subscription. A tenant holds a number of registered users that belong to it. Native Properties Associated LPMS resources . Is company public . User Profile . Name (O365)
User Profile User profile holds a number of information, some of which are obtained from the users’ profile on Office 365, marked with (O365) in the list. Native Properties Associated LPMS resources . Username (O365) . Mail (O365) . Tenant Profile (O365) . Given Name (O365) . Mail Nickname (O365) . Law Case . Surname (O365) . User Mails . Law Task . Description . Areas of expertise . Clients . User Role . Gender . To-Do-Items . Is Profile Public
Clients Clients can be either individuals or companies. If a client is a company, then the company’s representative name can also be given. A client belongs to a specific user and can have a number of cases Native Properties Associated LPMS resources . Full Name . Is company . Owner . Mail . Representative full . Law Cases . Phone name
Law Case The law case is the resource that encloses all the other resources. For example, law suit against the pigeons for bird droppings on the car. Native Properties Associated LPMS resources . Name . Owner . Clients . Description . Administrators . To-Do-Items . Status . Participants . Office 365 Group . Client Cases (files, events) . Tasks
Law Task Law Tasks represent the work that has been done for the case. There is no restriction on the type of the tasks, but usually these will be some kind of legal tasks such as attend court hearing, and draft pleading. As shown later in the cost calculation example the tasks determine the cost of the case.
40 Associated LPMS Native Properties resources . Type . Description . Case . Start (date-time) . Rate per hour . Owner . End (date-time)
To-Do-Items / To-Do-List The to do items are intended to be simple checklist items or a loose project plan. Native Properties Associated LPMS resources . Description . Case . Is Done . Last user modified it
Case Files Case files are any type of electronic file associated with the case. There is no restriction on the content of these files; they could be anything from court decisions, presentations and notes, to love letters.
Case Deadlines / Events This resource represents any type of date-time related activity such as a deadline or a meeting event, like for example court hearing at 5/5/2016 at 13:00. The type of this activity can be described by the Category property of the event. LPMS supports the distinction between deadlines and simple events. Properties . Date . Start Time . Category (deadline, . End Time meeting etc.)
Here, we provide a detailed list of all the available operations and services offered by LPMS. These operations are grouped in two tables:
Table 12 that lists the user operations, and Table 13 that lists the additional operations available to administrators, i.e. the operations admins can perform on other users’ resources. Note that administrators and global administrators can perform all the operations a Lawyer can perform, as shown in
Table 12.
Table 9 and Table 10 abbreviations
41 GA: Global Administrator A: Administrator System Level Roles L: Lawyer P: Paralegal CO: Case Owner CA: Case Administrator Case level roles CP: Case Participant : allowed operation : not allowed operation -: not applicable operation
Table 12. List of available operations for users
General Case specific permissions for permissions participants of shared cases L P CO CA CP Registration Register Company Only Global Admins Register Unregister Company Only Global Admins Irrelevant to case roles. Unregister Accept Users Registration Only Global Admins
Authentication Login Irrelevant to case roles. Logout
Profile Management View Edit general info Irrelevant case roles. Edit role Only Global Admins Edit registration status Only Global Admins
Client Management View Create Irrelevant to case roles. Clients belong to a user, and cannot be Edit shared, or edited from other users. Delete
42 Only lawyers are allowed to create cases. The right side of the Case Management table shows the permissions of users regarding their participation to a shared case. CAs can edit only some info. View Create The case is already created Edit ~ Delete Unregister from case
Only lawyers are allowed to create cases, and therefore only Case O365 Group Management lawyers can create and manage the related group. Only the group owner (i.e. the case owner) can manage the group. Add group Delete Group (done implicitly when case owner deletes the case)
Paralegals are implicitly not allowed to manage participants since they cannot be case owners. Participants can be invited Case Participants Management by either the owner of the case or the administrator, but can only be added to the group and removed from that by the case owner, who is also the owner of the group. Invite new members Remove member Add pending O365 group member Remove member from O365 group Delete pending invitations
All users can add, edit and delete their own tasks, so the right Case Task Management side of the table here shows permissions with respect to other case members tasks. View Create Case Tasks are already created Edit Delete
To-Do-Items belong to the case and can be created, edited and Case - To-do-items Management modified by any case member. View Create Update
43 Delete
Case files belong to the case and specifically to the O365 group associated with the case. The O365 permissions are that any Case Files & Folders group member can upload, download and delete files, so this has been followed also in LPMS View Files & Folders Upload Files Download Files Delete Files &Folders Create Folders
Case Events The same as with Files and Folders apply for Case Events View Create Edit Delete
Case chat View Send message Receive message
Real-time updates for remote changes New case invitation Invitation accepted/rejected Case updated/deleted Task created/updated/deleted To-do-item created/updated/deleted Event created/updated/deleted Files created/uploaded/deleted Text notifications New case invitation message Invitation deleted Invitation accepted Unregistration of case participant Event created/updated/deleted
44 Administrators can work as simple users, with the same permissions as lawyers but they are also provided with some additional functionality, shown in Table 13 below.
Table 13. List of available operations for administrators
GA A Register Company Unregister Company View all user profiles of the tenant Accept Users Registration Edit user profiles View all cases owned by the users of the tenant Edit law cases details Delete law case View all tasks of the users of the tenant Edit law tasks Delete law tasks
Client Applications
For the purpose of this thesis two client applications have been developed, with which the users of LPMS will be able to view, edit, and modify their resources. These are a Windows Desktop WPF application, that provides complete functionality, and a lightweight Android mobile application, which provides limited functionality.
Additionally, a very basic ASP .NET website is created which offers minimal functionality.
Windows Desktop (WPF) Client Application
The desktop application is the main access point to the users’ resources. It provides complete functionality meaning that it utilizes almost all the available operations. We have presented two screenshots from the WPF client until this point, one for the Case UI, and
45 one from the Live Chat. Here we will present some more screenshots of the UIs offered in the desktop application, which are listed below:
Table 14. User interfaces of the Windows Desktop client application
Login & Registration UI Profile UI o Register Company o View profile o Register User o Edit profile o Login o View tasks
Cases UI Clients UI o Select Case o View clients o View Case o View client details o Edit Details o Edit client o Delete case o Delete client o View tasks o Delete tasks Tasks UI o View deadlines o View tasks o Delete deadlines o Filter tasks o View files o Edit tasks o Upload files o Delete tasks o Download files o Delete files Chat UI o View chat rooms o View messages Wizards for new resources o Send messages o Create case o Create event Admin UI o Create task o Cases - view, filter, edit and delete o Create to-do-item users’ cases o Create clients o Tasks - view, filter, edit, and delete o Register payment users’ tasks o Profiles - view, filter, edit, and delete users’ profiles
Figure 20 shows the toolbar that holds A: the navigation controls to change UIs, B: controls that open the wizards and C: logout and notification controls.
46
Figure 20. Windows desktop screenshot showing the application toolbar
The screenshots of Figure 20 show the login and registration UI, illustrating the registration form for a new organization a new user.
Figure 21. Login and Registration UIs of the Windows Desktop client application
Figure 22 below is a screenshot of the Profile UI in which users can view and interact with their profile, as well as with some resources associated to their profile.
47
Figure 22. Screenshot of the Windows desktop client showing the profile UI
Figure 23 below is a screenshot of the Client UI, with which users can view and interact with all of their clients.
Figure 23. Windows desktop screenshot of the Client UI 48 Figure 24 below is a screenshot of the Tasks UI with which users can view and interact with all of their Tasks, and view the Tasks of all the cases they participate in.
Figure 24. Windows desktop screenshot of the Tasks UI
Finally, the majority of the creation and update operations on the resources are performed using dialog windows. Figures 25 and 26 show some of these windows.
Figure 25. Screenshot of the details and edit form dialog, of the Windows client application for Case Events Windows
49
Figure 26. Screenshot of the wizards for creating a new case, a new event and a new task
Android Mobile Client Application
The android application is a lightweight application that performs the following operations, with the UIs shown in Figure 27 and Figure 28:
1. View a part of their profile and edit their given name, surname and
description (Profile UI)
2. View their cases as a list (Cases UI)
3. View of some the case details and edit the case description (Case UI)
4. View the case events, where they can select also the case from a drop
down menu (Events UI)
50 5. View the case tasks as a list, where they can also select the case from a
drop down menu (Tasks UI)
6. View some of the task details, edit the tasks type, rate and description, and
delete the task (Task UI)
Figure 27. Mobile Android client screenshots (1)
Figure 28. Mobile Android client screenshots (2)
51 ASP .NET Website
Finally, a very basic Azure website has been implemented with which users can do the following tasks:
Table 15. Functionality ot the Android mobile application
Publicly available Available to registered, authenticated users View the lawyers in the system, Figure View cases, Figure 31 30 View case details, and case tasks, View all the API endpoints and Figure 32 payloads, Figure 33 (auto generated documentation)
Figure 29. LPMS website - Home page
52
Figure 30. LPMS website - registered lawyers
Figure 31. LPMS website cases of a registered lawyer
Figure 32. LPMS website case details, for a case of a registered lawyer
53
Figure 33. LPMS website case details, for a case of a registered lawyer
54 Chapter 6 Design Specifications
LPMS is a cloud service integrated with O365, which is accessed from two client applications: A Windows desktop (WPF) and a mobile Android client, as well as an ASP
.NET website. The resources of the service are stored on an Azure SQL database and O365.
Access to resources is controlled and coordinated by a Web API that exposes a number of
REST endpoints. The system architecture diagram below summarizes the most important components, and Table 16 provides a summary of these components.
Figure 34. LPMS Architecture
55 Table 16. LPMS core system components description
Azure AD is the glue of the system. The entire system is “wrapped by” it. It configures the application permissions, performs the users’ authentication and authorization (not entirely). The Azure SQL database is not explicitly under Azure AD, but since it is only accessed by the Web API, it is implicitly also wrapped by Azure AD Azure AD. The components that are registered under Azure AD are: Office 365 / Microsoft Graph API Web API Client applications
The Web API is the main contact and coordination point of the Web API system. It controls almost all requests, CRUD operations, and notifications.
Microsoft Graph API is the REST endpoint for accessing O365. All Microsoft requests for O365 resources are REST requests made by the Web Graph API API only.
SignalR 2 is a hub service, which runs along with the ASP .NET – Web API service. It pushes notifications and data updates to the SignalR 2 client applications when triggered by the Web API. It is also the live chat engine.
SQL & O365 The O365 resources are associated with the SQL database, Groups specifically with the Law Cases, by storing the ID of the O365 group Relation along with the Law Case.
There are three communication technologies used: REST: from the clients to the Web API and from Web API to Communication Microsoft Graph API. Technologies WebSocket: used by the SignalR, (it may fall back to other transport mechanisms if web sockets are not available). The Web API calls the SQL database directly.
Communication flows in the system follow certain pathways that are not bidirectional. These pathways are enumerated below and visualized in Figure 35.
The client apps contact only the Web API and SignalR directly and they never contact the SQL database or O365 directly. 56 The Web API never calls the client explicitly. It only contacts it implicitly for pushing updates, through SignalR 2 hub that runs on the service, (not present in this figure). The SQL DB is accessed only by the Web API. O365 is accessed directly either by the Web API or using other O365 applications. O365 never calls the Web API.
Figure 35. LPMS communication flows
Design Specification Choices – Discussion & Objectives
The high level architecture of the system – client/server – was purely driven by the collaboration and any time access to resources functional requirements. For this reason, we chose to store the data for all users in one remote location and authenticate and authorize access to the resources on server side.
Minimizing the up-front cost, and handling efficiently scalability and elasticity of the system were the critical factors that directed us to choose a cloud service over a custom server implementation. LPMS is an open system in the sense that there is no limit on the
57 number of users. It has to be able to handle 20 and 500 users equally well, without significant fluctuations on performance. The cloud, specifically Microsoft Azure cloud in this case, offers a wide range of ways to manage and improve scalability and elasticity of the system. Although optimizing performance was out of the scope of LPMS as a thesis project, we propose some ways to improve these properties in Chapter 7 .
The PaaS cloud model is probably the best option for developers who want to create cloud services focusing on the service development rather than the configuration, management and maintenance of the infrastructure. This is the primary reason for which we chose to use this model instead of the IaaS model. We have to note though, that optimizing pricing and performance might require some lower level configurations.
A few additional goals were to build a system that is maintainable, extensible, and which facilitates multi-platform development. To achieve these three goals, we made certain choices regarding the architecture of the system, the technologies that we used, and we implemented certain design patterns.
Decoupling of the system components was one of our first priorities to facilitate maintenance and extensibility. Using O365 already gives two decoupled components/services, O365 and Azure AD, which we integrate and use in LPMS, but which are managed and maintained by third parties, the Azure AD and O365 teams respectively. Next, we decided to proceed with the implementation of the business logic and access control of resources on a Web API, which uses the REST-full architecture and works with JSON data. This facilitates maintenance since changes to the business logic need only to be made on this component. In addition, REST services requires looser coupling between the service and the client, which makes the service more flexible to
58 changes and additions of new functionality. This is one of the main reasons that we favored
REST architecture over a SOAP (WCF) service.
Having the core business logic and access control to resources implemented on the
Web API offloads the client applications from these tasks. This makes the client applications lightweight with the primary role being how to present the data to the users, which facilitates multi-platform development. In addition, several technologies, practices and design patterns can further assist to cross-platform development increasing code sharing among these applications, like Xamarin, portable class libraries (PCL) and the
MVVM design pattern (The MVVM Pattern, n.d.). Increasing code sharing reduces also the maintenance effort needed.
Xamarin allows developers to implement native Android and iOS applications using only C#, which is an excellent tool for C# developers who want to implement applications for these platforms without being familiar with Java, Swift or Objective C.
But, it can be more than that for cross-platform development. Code sharing can significantly be increased among these platforms, by implementing the business logic on portable class libraries, which can be shared. For example, in our case, we have implemented the logic for consuming the Web API as a portable class library. Hence, once we decide to implement an iOS application we can reuse this portable library as is.
Taking code sharing a step further, it is possible to share not only strictly business logic, but also logic that is related to the data that we present to the users, using the MVVM pattern. With MVVM we could share the state of the views on the view models. If this is implemented properly we could use the same view models for the Android, iOS applications, and even for the Windows desktop application, as an extreme example. Then
59 the only difference among these applications would be the user interface, the controls, which of course have to be implemented separately since they are different on each platform.
Finally, it is worth noting that now with new technologies like the AngularJS framework (AngularJS — Superheroic JavaScript MVW Framework, n.d.) it is possible and straightforward to implement web applications that work with JSON data and which can consume Web APIs. Therefore, instead of building an MVC application, as we did in this case, we could have used AngularJS and consume the Web API. Using this technology, we would be able to use exactly the same service, the Web API, for all the client applications, including the web application.
Accessing Resources Azure SQL O365 & Microsoft Graph API
As it has already been mentioned plenty of times, resources are stored in O365 under unified groups, and on an Azure SQL database. All data stored in the database are related data; cases are related to users, tasks are related to cases and users, and so on. We wanted to enforce a strict schema on the data from the beginning, to increase data integrity, and to provide ease of use and a uniform schema for all users to facilitate collaboration between unrelated users. Of course this makes the application less flexible, since for example if we want to add a new field to Law Cases, we have to update the database structure, but this is a tradeoff that we are willing to accept. For these reasons, we proceed with the more traditional SQL database instead of other types of databases like NoSQL.
The integration of O365 and LPMS services is initially performed by Azure AD, which configures the required permissions and handles authentication and authorization,
60 as described in Chapter 4 section Active Directory. Then, the Web API is responsible for retrieving and associating the O365 resources with the SQL DB. The association of resources between O365 and the SQL database is done via the ID property of the O365 unified group, which is stored as a field in the Case table of the SQL DB. The communication between the Web API and O365 is done by consuming the Microsoft
Graph API, which is a REST API.
The two database diagrams of Figure 36 and Figure 37 show the structure and the relationships of the entities in the SQL database. Below we enumerate some of the key referential constraints to provide a better understanding of database structure, and the business logic of the system:
A Tenant has many Users, and Users belong to exactly one Tenant. A User can have many Clients, and a Client has exactly one owner – User. A User can own many Law Cases, and a Law Case can be owned by exactly one User. A User can participate in many Law Cases, and a Law Case can have many participants. A User can administer many Law Cases, and the Law Case can have many administrators. A User can perform many Law Tasks, and a Law Task can be performed by at most one User. A User can edit many To-Do-Items, and a To-Do-Item can be edited by exactly one User. A User can have many Case Invitations, and a Case Invitation is for exactly one User. A Law Case can have many Law Tasks, and a Law Task must belong to at most one Law Case. A Law Case can have many To-Do-Items, and a To-Do-Item belong to exactly one Law Case. A Law Case can have many Chat Messages, and a Chat Message belongs to exactly one Law Case. A Law Case can have many Case Invitations, and a Case Invitation belongs to exactly one Law Case. A Law Case is owned by exactly one Client, and a Client can own many Law Cases.
In addition to the above, LPMS keeps track of the logged in users in the system by storing them in the LogedInUserNew table. This is particularly useful for pushing notifications and updates to the currently connected clients.
61
Figure 36. SQL DB ER diagram showing the core entities and their relationships
62
Figure 37 Complete SQL Database diagram.
63
An interesting point worth discussing again, is that the only reference needed to associate O365 resources with the SQL database, and therefore integrate O365 to LPMS, is a varchar field: The O365GroupId field. This shows very well the decoupling of O365 and LPMS and the service oriented architecture of the system. The two services are able to interoperate as a system with minimum data sharing, data persistence and synchronization, which is excellent for maintenance. Instead of persisting the state of O365, we only implement, on the Web API, the required instructions on how to obtain O365 resources dynamically at request time, which is done by consuming parts of the Microsoft Graph
API.
One limitation with this approach is that if O365 resources are modified through
O365, then the logged in to LPMS users will not get an update for these changes. A solution to this problem could be given when O365 implements a notification mechanism, or we could implement some polling mechanism on the service that would be triggered from the client applications.
Finally, we end up this section by providing a simple sequence diagram in Figure
38 that illustrates how the O365 resources can be obtained by knowing only the ID property of the Unified group.
This diagram shows process of:
creating a new O365 unified group,
storing the ID of at the DB,
retrieving the group drives children
and creating a new Event.
64
Figure 38. Microsoft Graph API REST calls to the, to create an O365 group, and obtain
group resources
We provide some more sequence diagrams for these operations in Appendix I.
Web API
The Web API is the central point of the system; it coordinates and controls access to all resources, and it exposes a series of REST endpoints as shown in Table 17. The entire
API, including a complete documentation of the REST calls and the JSON objects, can be viewed at the projects website (https://microsoft- apiappd72b12d003fc4f5a90ef7022af544550.azurewebsites.net/Help).
Access to all controller actions is authenticated and authorized. The structure of the request URL is the following:
ACTION https://
Example: GET api/signup/login/ 65 Service base address:
https://microsoft-apiappd72b12d003fc4f5a90ef7022af544550.azurewebsites.net
In the Table 17 below, the
Table 17. LPMS API REST controllers
SignupApiController Register / unregister tenants and users, and log in / log out user. Sample calls o Login: GET api/signup/login/{deviceId} o Unregister: DELETE api/signup/unregisteruser
LpmsTenantController Read and update tenant information Sample calls o Get tenant details: GET api/LpmsTenantsApi/{id}
LpmsUsersApiController Read user profiles, update the current users’ profile and get the current users’ pending invitations. Sample calls o Get users: GET api/LpmsUsersApi?tenantId={tenantId}&role={role}& registrationStatus={registrationStatus} o Get user invitations: GET api/lpmsusersapi/invitations
ClientsApiController Perform all CRUD operations to the Clients of the calling user. Sample calls o Get client light payload: GET api/clientsApi/light o Delete client: DELETE api/ClientsApi/{id}
CasesApiController This is the most overloaded controller. Perform the basic Law Case operations and access almost all Law Case related resources. Sample calls o Get case: GET api/CasesApi/{id}
66 o Get case tasks: GET api/casesApi/{id}/tasks o Create new folder in OneDrive: POST api/CasesApi/{id}/drive/newFolder/{parentId} o Delete case member: DELETE api/CasesApi/{id}/member/{memberId}
CaseTasksApiController Perform CRUD operations to Law Tasks. Sample calls o Get all Law Tasks related to the users: GET api/CaseTasksApi o Get Law Task: GET api/CaseTasksApi/{id}
ToDoItemApiController Perform CRUD operations to To-Do-Items. Sample calls o Create To-Do-Item: POST api/ToDoItemApi (item passed in the payload)
CaseInvitationApiController Accept and reject case invitations. Sample calls o Accept Invitation: GET api/CaseInvitationsApi/{id}
AdministratorApiController Only available to Administrators. Access Users, Law Cases and Law Tasks for other users. Sample calls o Get all users of the tenant: GETapi/AdministratorApi/users?role={role}& registrationStatus={registrationStatus} o Update user: PUT api/AdministratorApi/users/{id} (user passed in the payload) o Get all cases owned by users of the tenant: GET api/AdministratorApi/cases?username={username} o Get all tasks owned by users of the tenant: GET api/AdministratorApi/tasks?caseId={caseId}&userId={userId}
A complete example of a successful REST call to the Web API is provided in
Appendix I.
67 Live chat & Real Time Updates using SignalR 2
Both the live updates and the live chat requirements are implemented leveraging the power, flexibility and rich functionality of SignalR 2, which is a fully managed lightweight hub service. In our opinion, this is one of the most interesting parts of the system, because of the combination of its simplicity of implementation, its lightweight nature, and the richness of the functionality that it adds to the application.
Our goal is to push notifications, updates, and chat messages only to the relevant logged in users. These relevant users are either the participants of a Law Case, or a new invited user. Below are some examples for clarification:
Notify all the logged in case participants for a newly added Law Task to the
case.
Notify an invited user, to a Law Case, for the new invitation, as well as the
other case participants.
Create case-based chat rooms where the users send chat messages directed
only to the case participants.
In the initial design it was intended to use Azure Notification Hubs (Notification
Hubs Overview, 2015) for the real time updates and some other technology for the live chat, like the Skype API (Skype Developer Platform, n.d.). However, because WPF applications do not work with Azure Notification Hubs, we had to find an alternative for notifications and updates. This alternative would be to implement long polling, or web sockets mechanisms ourselves. Fortunately, this is what SignalR does, and in addition, it offers a very rich functionality out of the box:
68 It configures automatically the transport technology depending on the
system capabilities, like web sockets and long polling
It supports various ways to direct messages, such as broadcasting, or direct
messages to individual users, and even send messages to groups of users
which is exactly what we needed to achieve the push behavior that we
described above.
In addition, implementing a live chat using SignalR is straightforward; especially the case-based live chat that we need, using its group feature. This group feature is also used for the vast majority of the messages that are sent, since most of the times we want to direct messages with updates to the relevant case participants. Therefore, SignalR and its groups solved two problems at once, notifications/live updates and chat, which simplified significantly the implementation, and gave us flexibility.
SignalR identifies the connection of the clients to the hub using the connection ID that is passed from the proxy client, when it connects to the hub. To be able to send directed messages to individual logged in users or groups of logged in users from the service, we first had to keep track of them along with their connection ID. This is done with the
LoggedInUsersNew table, which store pairs of Users and Connection IDs.
Since LPMS is a multiplatform system, users should be able to be logged in both from the desktop and the mobile client applications at the same time. To receive SignalR messages, each of these client applications should have its own connection ID. To address this requirement, we added a Device ID field to the User-Connection ID pair mentioned above, to be able to distinguish these multiple logins. As the device ID for the WPF
69 application we used the processor ID of the machine that it is running on, and respectively the Android device ID for the Android mobile application.
As mentioned above, in order to send messages to groups of users we used the groups’ feature of SignalR in the following straightforward way: A SignalR group is created for each case, and the case members register to this group. Then case notifications are send on a group basis.
A more detailed description of SignalR and its use, including some implementation details and diagrams, is provided in Appendix I. There, we also point out the difference between the use of SignalR for the live chat and the live updates.
LPMS Sequence diagrams
All of the important components have been described by now. So, here we present some indicative sequence diagrams that show some of the logic patterns followed in LPMS.
We describe the following cases:
Create new case and add participants
Accept case invitation and complete invitation process
Add resources to a case
In these diagrams we have deliberately excluded the Azure AD authentication and authorization flows to reduce their complexity. We only show the initial Authentication i.e. login of the client.
Create a new Case and add participants
Creating a new case and adding participants is a three-step process, which is described in Figure 39 and Figure 40. The first part of the process is to add the case details,
70 participants and group details, then create the case and send the invitations. If there are no participants other than the owner the process stops here. The second part is the acceptance of the invitations from the members. Finally, the third part that completes this process is that the case owner adds the accepted members to the O365 group of the case.
Part I: Create the case and invite members
Figure 39. Sequence diagram showing the process of creating a new case
1. The user using the WPF clients’ wizard for creating a new case, adds the case details 2. Calls the Web API to confirm that the case is unique for the case owner
71 3. Adds the members of the case (optional) 4. Sets the group details 5. Calls the Web API to check that the group is unique for the user 6. Calls the Web API to create the case 6.1. The Web API then Validates the case information are properly set 6.2. Checks for a simplified version of legal conflict. Either the case owner has another case where he represents the opponent of this case, or the lawyer has another case against the client, and returns the case 7. The WPF client calls the Web API to invite the case members 7.1. The Web API call SignalR to send an invitation to each member and returns 7.1.1. SignalR retrieves the users and pushes the invitations to their client applications 8. The update is added to the other WPF clients 9. The WPF client calls the Web API to create the group 9.1. Finally, the Web API creates the group on O365 and returns it
Parts II & III: invited members accept the invitation, and the case owner adds them to the O365 group
Figure 40. Sequence diagram showing the process of accepting pending invitations and
adding new case members to the O365 group for the case
1. The invited user, WPF client, accepts the invitation by calling the Web API 1.1. The Web API Deletes the invitation from the DB, adds the user to the case members list (either admins or participants) calls SignalR to push the notification for the case invitation 1.1.1. SignalR pushes the update to the other relevant clients 1.1.1.1. The case owner, WPF client who was notified for the acceptance of the invitation calls the Web API to add the new participant to the group
72 1.1.1.1.1. Finally, the Web API calls O365 and adds the member to the group, and returns.
Add resources to a case
Figure 41 below shows the flow for creating new resources. It covers both the creation of SQL resources and O365 resources. The flow for updating and deleting resources is the same as the one described above.
Figure 41. Sequence diagram showing the process of adding new resources to a case
1. A user, WPF client, Adds the Law Task details for the new task 2. Calls the Web API to create the new Law Task 2.1. The Web API validates the task details and adds the task to the DB 2.2. Calls SignalR to push the update to the other case members 2.2.1. SignalR pushes the update to the other relevant WPF clients 3. A user, WPF client, creates a new event adding the Event details, 4. Calls the Web API to create the new Event 4.1. The Web API calls Microsoft Graph API to create the new Event to O365. Note that the Web API here is not validating the Events details since this is done by Microsoft Graph 4.2. Calls SignalR to push the update to the other case members 4.2.1. Finally, SignalR pushes the update to the relevant WPF clients.
73
Client Applications
Windows Desktop Client Application
The Windows Desktop client application is implemented as a WPF application.
This application consumes almost entirely the LPM Service, as described above. The technical goals for this application are two: (1) make it modular, layered and testable, and
(2) maintain as little data as possible.
1. Modularity, Layered architecture and Testability
This goal is achieved using dependency injection and the Model View – View
Model (MVVM) design pattern, (The MVVM Pattern, n.d.). There are various packages and frameworks to achieve this, and the one we choose is the MVVM Light Toolkit along with the SimpleIoc dependency injection container (see the documentation at Codeplex https://mvvmlight.codeplex.com/), which are open source, do not have a steep learning curve, and of course are effective and efficient. Figure 42 below shows a simplified and generalized diagram of the applications architecture to highlight some of its components.
74
Figure 42. Windows Desktop client architecture
As shown in this diagram, the application relies on four services that implement the following interfaces:
1. IAppState: maintains the state of the application, holding data used from various ViewModels. For example, the users profile and a list of the users’ cases are used by most of the ViewModels 2. IDataService: makes all communications with LPM Service, including ADAL authentication 3. IDialogService: displays modal and non-modal dialogs (error, dialogs, confirmation dialogs, and wizards etc.) 4. IHubService: the implementation class of this interface, HubService, is the SignalR hub client.
All dependencies shown above, and view model life span are handled by the
SimpleIoc dependency injection container. Communication between ViewModels and between other components of the application, are done with messages by using the
75 Messenger class provided in the MVVM Light Toolkit. Finally, the View and ViewModels are connected with data bindings.
2. Maintain as little data as possible
LPM Service may contain a large volume of data associated with a user, like for example, all Law Cases the user participates in and all of their associated resources, Law
Tasks, Events, Case Files etc. It is highly unlikely that the user will need to access all of these resources simultaneously and therefore obtaining and persisting locally these resources at the client would be a waste of cloud, network, and local resources.
Web applications, mobile applications, and more modern applications than the
WPF, like Windows Store, use the concept of navigation and views. This allows the application to present a specific set of related data to the users, for example only the users profile in the profile page, which means that it has to persist only that amount of data at run-time. To view other data users can navigate to other views.
This is the approach we chose to follow for the implementation of the WPF client.
The application has a number of views, as shown in the screenshots presented in the functional specifications section, which are focused to do certain tasks and persist at runtime only the required data for these tasks. For example, the Case View provides the UI to manage a case and its resources. The ViewModel for this view holds only the list of the
Law Tasks of this case, not all the users’ tasks or clients.
This behavior is achieved by using the Main Window and its corresponding view model as a shell. The view has a content presenter, in which we load and unload the required view and their corresponding view model at runtime.
76 Android Client
The Android is a lightweight application that consumes very few of the LPM
Service resources. Probably what is most interesting about the implementation of this native Android application is that it is implemented entirely in C#. This has been achieved using Xamarin. Table 18 below shows the most basic technical and implementation details at a glance:
Table 18. Android client application, glimpse of tech specs
Targeted platform Android 5.0 API 21, Lollipop Minimum platform Android 4.4 API 19 KitKat Support library Android Support Library v7 AppCompat Navigation MVVM Light Toolkit NavigationService
What is worth mentioning regarding the Android client is that the communication with ADAL and the LPM Service is handled by a service library (DataService), implemented in a separate Portable Class library project. Doing so, not only works towards separation of concern and modularity, but it is also great for reusability. For example, if we decided to implement an iOS mobile application also, using Xamarin, we could reuse this library, and we would only have to implement the UI components and the controllers.
77 Chapter 7 Summary and Conclusions
Although this thesis is an applied project, rather than a research project, it uses some components that are new and underexplored yet. When we formed the initial thesis proposal, Microsoft Graph API was still in its prerelease form, named Office 365 Unified
API. It is interesting to note that through the period of the thesis implementation, the documentation of this API, and the API itself in a smaller extent, have been continuously evolving and changing, as they still do.
For this reason, integrating O365 to LPMS through the Microsoft Graph API has been one of the big challenges we faced during the design and implementation of this thesis.
It required extensive research both on the capabilities of O365 and the programmatic access to it. When we started the implementation we had to make changes to the initial design and accept some of its limitations. One such limitation has been already discussed, which is related to the sharing capabilities of the O365 unified groups. In addition, we had to replace the design for one functional requirement regarding the To-Do-Items. We were planning to address this requirement using OneNote files, which is a feature that is included in O365 unified groups. However, the problem was that programmatic access to this feature at the time is only available through the beta version of Microsoft Graph API, but because it is the Beta version, it is not well tested yet and it is subject to changes. For this reason, we replaced this specification with a custom implementation for the To-Do-Items on LPMS service.
As a short review regarding the integration of O365 using the Microsoft Graph API to LPMS, I consider it generally fulfilled our expectations and gave the richness to the
78 functionality that we were looking for. However, we have to note that this process required more work than we expected because this REST API may be powerful but it is also complex. Additionally, because it is new it requires a few bug fixes and improvements on the documentation. Finally, we anticipate the release of the SDK (Software Development
Kit) for .NET, which we think that it will significantly simplify the use of this service for any future development.
Finally, as it has already been mentioned, this project is a prototype of a law practice management application. Therefore, at the prospect of commercializing it, there are improvements that could be made, not only regarding the use of O365, but also regarding the functional requirements, as well as the design specifications. These would include performance improvements, extension and refinement of the functional requirements, and sophistication of existing features. So, we end up this section, and this thesis, with some proposals for future work.
Performance & Cost Improvements
The cloud has great capabilities in terms of scaling and performance. For the custom service implementation, this project used an Azure SQL database and a Web API, hosted on Microsoft Azure cloud. Improving scalability and performance on Azure can be achieved in two ways: (1) simply by using more expensive tiers of components, like using a Standard or Premium tier SQL database instead of a Basic tier, and (2) by changing the system architecture of the service and by handling lower level tasks to optimize performance. The first solution is the easiest to implement, but it will most probably be the least cost effective. Therefore, here we propose some modifications to the architecture of the system to improve the relationship of scalability, performance, and cost:
79 One improvement could be to split the service in more than one Web APIs or
components. For example, the functionality for the administrators could have
been implemented as a separate Web API, since the functional requirements for
the administrators are somewhat different to those of simple users. As the
functionality of the system becomes richer these differences would increase.
This separation would also give the flexibility to use the cost-optimal
components and configurations in terms of their usage. Administrators deal
with larger volume of data, compared to the volume of data for the simple users
that have to deal only with the data associated to them, but on the other hand
the administrators are significantly fewer in number compare to the simple
users.
Another improvement would be to uncover the abstraction of Azure Web Apps
(Web App Service | Microsoft Azure, n.d.) in terms of scalability and elasticity,
handling manually these tasks with the use of Worker Roles (Boucher Jr, 2016)
to manage the number of running instances according to traffic.
Caching database data using an Azure Redis cache (Danielson, 2016) could
improve the Azure SQL database performance.
Finally, taking the above technique a step further, we share here a post that we
noticed during the research on Azure performance and pricing optimizations,
which shows the inventiveness that can be applied on the system architecture
to perform such optimizations. This post by Guillermo Bellmann, which is on
a use case (Bellmann, 2015), illustrates how Azure Search along with an Azure
80 Radish Cache can be used to improve the performance of a database, and at the
same time reduce the total cost of the service.
Extend Functional requirements and O365 integration
There are many features that would be very useful towards implementing a complete law practice management system solution. For example, a complete interface for submitting payments, integrated with accounting tools, and a sophisticated financial interface would certainly add value to the service. In addition, more O365 components could be very useful. The list below enumerates some possible additions:
Create a client portal, where clients can make payments
Create a sophisticated financial interface for payments and profit
Allow users to view their O365 contacts and emails
Allow users to view all their O365 calendars
Sophistication of existing features
Some features of the service have a basic functionality, like conflict management.
Now conflict management checks only if the lawyer has a case against the client for the case, or has a case for the opponent of the case. This could be extended to work on an organization level with more sophisticated criteria. Here is again a list of improvements:
Improve conflict management and extend to organization level
When a user creates a case that is not shared with other users, it should not
create an O365 group for the case, but rather create individual resources, i.e. a
Calendar and a drive. When a user invites another user to the case, then it should
create a new group and move all the data there.
81 Improve the chat: show logged in users for each case and keep track of the
number of unread messages when the chat is closed.
82 Glossary
Android Operating system for mobiles and tablets provided by Google. Application Programming Interface. “A set of protocols, routines and tools for API building software applications”, after (Beal, n.d.). “ASP.NET Web API is a framework that makes it easy to build HTTP services that reach a broad range of clients, including browsers and mobile devices. ASP.NET Web ASP .NET API is an ideal platform for building RESTful applications on the .NET Framework.” (The Official Microsoft ASP.NET Site, n.d.) Azure Cloud computing platform and services offered by Microsoft. Azure Active “Microsoft’s multi-tenant cloud based directory and identity management service”, Directory (Vilcinskas, 2016) Cloud "A model for enabling ubiquitous network access to a shared pool of configurable Computing computing resources.", after (Mell & Grance, 2011) Infrastructure as a Service. A cloud service model where the consumer can directly IaaS manage resources on the cloud platform (VMs, specify OS, how much RAM etc.), (Ellis, 2015) JSON JavaScript Object Notation. It is a lightweight data interchange format. (Bray, 2014) “JSON Web Token (JWT) is a compact, URL-safe means of representing JWT claims to be transferred between two parties.” (Jones, Bradley, & Sakimura, 2015) Microsoft REST API offering programmatic access to O365, and its resources (Microsoft Graph - Graph API Home, n.d.) OAuth 2.0 The evolution of the OAuth authentication protocol (Hardt, 2012) A SaaS cloud service offered by Microsoft providing a set of software services, like Office 365 One Drive, Outlook, One Note etc. (Office 365 Service Descriptions, 2015) An application programming interface that allows development against the Office Office 365 API 365 service. One Drive Cloud storage offered by Microsoft One Note A note taking application offered by Microsoft OpenID “a simple identity layer on top of the OAuth 2.0 protocol”, (Welcome to OpenID Connect Connect, n.d.) Platform as a Service. It is a cloud service model, where the developer can PaaS implement and deploy applications on the cloud, without having access or maintain the underline infrastructure, (Mell & Grance, 2011). Representational State Transfer. It is an architectural pattern used for building web REST services, web sites etc. (National Security Agency , 2011) Software as a Service. A cloud service model, offering complete software that uses SaaS cloud resources. Consumers do not have any control on the underlying infrastructures, (Ellis, 2015) Skype A telecommunication application (live video, chat, VOIP) Structured Query Language. It is a type of relational database management system SQL Database using the structured query language to be managed. (Structured Query Language (SQL), n.d.) Web API is a framework to build HTTP services, used to build RESTfull applications. Web API (Learn About ASP.NET Web API, n.d.)
83 “A free web framework for building Web sites and Web applications using HTML, CSS Web API and JavaScript. Create Web APIs, mobile sites and use real-time technologies”, (Learn About ASP.NET Web API, n.d.) Windows Presentation Foundation, is a GUI framework for .NET desktop WPF applications, (n.d.) It is a platform that allows the implementation of applications for iOS, Android and Xamarin Microsoft applications which share the same C# codebase, (Mobile App Development & App Creation Software, Xamarin, n.d.)
84 References
AngularJS — Superheroic JavaScript MVW Framework. (n.d.). Retrieved from
AngularJS — Superheroic JavaScript MVW Framework: https://angularjs.org/
Baldwin, M. (2016). Authentication Scenarios for Azure AD. Retrieved from Microsoft
Azure: https://azure.microsoft.com/en-us/documentation/articles/active-directory-
authentication-scenarios/
Beal, V. (n.d.). API - application program interface. Retrieved from Webopedia:
http://www.webopedia.com/TERM/A/API.html
Bellmann, G. (2015). Improving performance with Azure Search and Redis cache |
Guillermo Bellmann. Retrieved from Improving performance with Azure Search
and Redis cache | Guillermo Bellmann:
http://en.blog.gbellmann.technology/2015/05/11/improving-performance-with-
azure-search-and-redis-cache/
Boucher Jr, R. (2016). Introducing Microsoft Azure. Retrieved from Microsoft Azure:
https://azure.microsoft.com/en-us/documentation/articles/fundamentals-
introduction-to-azure/
Bray, T. (2014). RFC7159. The JavaScript Object Notation (JSON) Data Interchange
Format. IETF.
Danielson, S. (2016). How to Use Azure Redis Cache. Retrieved from Microsoft Azure:
https://azure.microsoft.com/en-us/documentation/articles/cache-dotnet-how-to-
use-azure-redis-cache/
85 Delaney, L. (n.d.). 10 Benefits of Cloud Computing. Retrieved from
http://www.verio.com/resource-center/articles/cloud-computing-benefits/
Ellis, G. (2015). Microsoft Azure IaaS Essentials. Birmingham: Packt Publishing.
Greiner, R. (2014). Windows Azure IaaS vs. PaaS vs. SaaS. Retrieved from
robertgreiner.com: http://robertgreiner.com/2014/03/windows-azure-iaas-paas-
saas-overview/
Hardt, D. (2012, October). RFC 6749. The OAuth 2.0 Authorization Framework. IETF.
Jones, M., Bradley, J., & Sakimura, N. (2015, May). RFC7519. JSON Web Token (JWT).
IETF.
Learn About ASP.NET Web API. (n.d.). Retrieved from The Official Microsoft ASP.NET
Site: http://www.asp.net/web-api
Mell, P., & Grance, T. (2011). The NIST Definition of Cloud Computing. Retrieved from
National Institute of Standards and Technology:
http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf
Microsoft Azure: Cloud Computing Platform & Services. (n.d.). Retrieved from
Microsoft Azure: Cloud Computing Platform & Services:
https://azure.microsoft.com/en-us/
Microsoft Graph - Home. (n.d.). Retrieved from Microsoft Graph:
https://graph.microsoft.io/en-us/
Miller, M. (2008). Cloud Computing: Web-Based Applications That Change the Way You
Work and Collaborate Online. Indianapolis, USA: Que Publishing.
Mobile App Development & App Creation Software, Xamarin. (n.d.). Retrieved from
Xamarin:
86 http://xamarin.com/?_bt=44014802828&_bk=%2Bxamarin&_bm=b&gclid=CKO
BpOSghccCFTGWtAodhWoF8g
National Security Agency . (2011). Guidelines for Implementation of REST. Retrieved
from National Security Agency - NSA/CSS:
https://www.nsa.gov/ia/_files/support/guidelines_implementation_rest.pdf
Notification Hubs Overview. (2015). Retrieved from Microsoft Azure:
https://msdn.microsoft.com/en-us/library/azure/jj927170.aspx
Office 365 APIs platform overview. (2015). Retrieved from MSDN - Office:
https://msdn.microsoft.com/en-us/office/office365/howto/platform-development-
overview
Office 365 Service Descriptions. (2015). Retrieved from TechNet:
https://technet.microsoft.com/en-us/library/office-365-service-descriptions.aspx
Office. (n.d.). Office 365 product page. Retrieved from Office:
https://products.office.com/en/home
Politis, D. (2015). Trends in Cloud IT: Dissecting Adoption Across Thousands of
Organizations. Retrieved from BetterCloud.com:
http://blog.bettercloud.com/cloud-office-systems-adoption/
Sean, M., Subhajyoti , B., Juheng , Z., & Anand, G. (2011). Cloud computing — The
business perspective. Decision Support Systems, 176–189.
Skype Developer Platform. (n.d.). Retrieved from Skype Developer Platform:
http://www.skype.com/en/developer/
SQL Database - Relational database service | Microsoft . (n.d.). Retrieved from
Microsoft Azure: https://azure.microsoft.com/en-us/services/sql-database/
87 Strockis, D. (2015). How to get an Azure Active Directory tenant. Retrieved from
Microsoft Azure: https://azure.microsoft.com/en-us/documentation/articles/active-
directory-howto-tenant/
Structured Query Language (SQL). (n.d.). Retrieved from MSDN:
https://msdn.microsoft.com/en-
gb/library/windows/desktop/ms714670(v=vs.85).aspx
The MVVM Pattern. (n.d.). Retrieved from MSDN: https://msdn.microsoft.com/en-
us/library/hh848246.aspx
The Official Microsoft ASP.NET Site. (n.d.). Retrieved from The Official Microsoft
ASP.NET Site: http://www.asp.net/
Top Law Practice Management Software Products. (n.d.). Retrieved from Capterra:
http://www.capterra.com/sem/law-practice-management-
software?gclid=CK2Ww83DrcgCFaINcwod9xQByQ
Vilcinskas, M. (2016). What is Azure Active Directory? Retrieved from Microsoft Azure:
https://azure.microsoft.com/en-us/documentation/articles/active-directory-whatis/
Web App Service | Microsoft Azure. (n.d.). Retrieved from Microsoft Azure:
https://azure.microsoft.com/en-us/services/app-service/web/
Welcome to OpenID Connect. (n.d.). Retrieved from OpenId: http://openid.net/connect/
Windows Presentation Foundation. (n.d.). Retrieved from MSDN:
https://msdn.microsoft.com/en-us/library/ms754130(v=vs.110).aspx
88 Appendix I
Azure AD
In this section we provide some additional details on the authentication flow using
Azure AD. We show two diagrams, taken from (Baldwin, 2016), which cover the Azure
AD authentication flow for the two cases of LPMS communication, as discussed in Chapter
4 . Below Figure 43 is repeated, to remind the communication flows. In short, there are two cases for LPMS: A: the native client calls the Web API only, and B: the native client calls the Web API to obtain resources from O365. All three components are registered with
Azure AD, and the Web API and O365 require authenticated access to their resources.
Figure 43. LPMS communication flows from client to Web API and Office 365
Figure 44 shows the process of a native client application, which authenticates against Azure AD and then calls a Web API. When the user tries to log in, a browser window opens to the Azure AD sign in page. After a successful login it returns the authorization code. The native client then calls the Azure Token endpoint to obtain the
89 JWT token (JSON Web Tokens (Jones, Bradley, & Sakimura, 2015)), which it passes along with the request to the Web API. This diagram describes case “A” of Figure 43.
Figure 44. Native Application to Web API, (Baldwin, 2016)
Figure 45 describes the case where a browser authenticates against Azure AD to call a Web Application, which then calls a Web API on behalf of the user. The authentication flow here is similar to that described above, with one more step, which is the Web Application calling the Azure Token Endpoint to obtain a token, and then pass that along with request to the Web API. This example almost describes the authentication flow for case “B” of Figure 43, with the only difference that instead of a web application
LPMS has a native client.
90
Figure 45. Web Application to Web API, (Baldwin, 2016)
SignalR 2 – Live updates & live chat
In this section we provide some additional details on SignalR, and on how we used to implement the live chat and live data updates.
SignalR 2 setup
The setup for SignalR 2 is fairly simple. It needs a hub that is implemented at the service, and a hub proxy which implemented at the client, as shown in Figure 46. Once this is set up, both the server and the client can invoke methods on each other.
91
Figure 46. SignalR high-level architecture
Connect to the hub and register to SignalR 2 case groups
Getting connected to the hub is the clients’ responsibility, the Windows Desktop client in LPMS case. The sequence of operations is shown in the sequence diagram of
Figure 47:
Figure 47. Sequence diagram for connecting to the SignalR hub, logging in the client, and
registering to case SignalR groups
1. First the client connects to the hub,
2. then logs in the user to the hub passing along the device ID,
92 2.1. the hub retrieves the user in the logged users table and assigns a connection ID to
that user, so it can push messages. At this point the user is ready to register to case
groups.
The device ID is important because the same user may be logged in from multiple devices at the same time, like the Android and the Windows Desktop clients, so the hub must know the specific connection ID for each one so as to push the messages.
3. the client requests to register for the case groups,
3.1. the hub retrieves the users’ cases, and accordingly, joins the user to the existing
case groups, and for the groups that do not exist it creates new.
Real-time updates, sending messages
When a creation, update, or deletion operation takes place through the Web API, the Web API calls the appropriate hub on the service side method to push these changes to the connected clients. Now that the logic for the groups is set, the invocation of a group hub method from the Web API using C# is very simple, as shown below:
// get the hub context to invoke the method var context = GlobalHost.ConnectionManager.GetHubContext
When using groups, it is possible to exclude certain connection IDs from the method invocation by passing an array of these connection IDs as shown above. This is useful in our case because we do not want to push the message/update to the client that triggered it, since this client gets the update directly from the Web APIs response.
93
Figure 48. Sequence diagram showing the flow of operations when a resource is deleted with
respect to SignalR
Live Chat
The live chat works in a different way than the real-time updates. Although it also works with the same SignalR 2 groups as real-time updates, in this case the clients call the hub directly, as shown in Figure 49 below. The hub then pushes the message to the group members, and then accesses the DB to store the message.
Figure 49. Sequence diagram showing the flow of the chat messages with respect to SignalR
94 Additional Sequence Diagrams
In this section we provide two additional interesting sequence diagrams, which show the registration process for an organization, and the second shows the login process.
Register Organization
The registration process involves both the Web API and O365. The only information provided by the user in this process is whether the organization should be publicly accessible to other users.
Figure 50. Sequence diagram for registering a new organization with LPMS
1. The user, using the WPF client selects the organizations visibility, 2. authenticates against Azure AD, and gets the bearer token which passes along in all the requests, 3. then calls the Web API to register the organization 3.1. The Web API Checks if the user and the tenant already exist 3.2. If not, then gets the O365 profile of the user from O365
95 3.3. Ensures that the user is an O365 admin 3.4. Creates a new Tenant profile, and user profile from the information passed from the client, and the information obtained from O365
Login
The login process described here involves two unrelated actions. First login to the system and then connect to the hub.
Figure 51. Sequence diagram showing the login process in LPMS
1. The user, using the WPF client authenticates against Azure AD, and gets the bearer token which passes along in all the requests 2. The WPF client obtains a unique ID for the device 3. Calls the Web API to login passing along the device ID 3.1. The Web API Retrieves the user from the DB 3.2. Adds the user to the logged in users table, and returns the profile 4. The WPF client Connects to SignalR Navigates to the Cases UI
96 Sample request, and response of a user of LPMS to update his profile
Request PUT api/LpmsUsersApi Authorization: Bearer eyJ0eX… Content-Type: application/json; charset=utf-8 Host:
{ "Id": "ba03a90c-XXX…", "UPN": "MMc…", "Username": "Some string", "GivenName": "Some string", "Surname": "Some string", "Description": "A specialized lawyer in robotics", "TenantId": "738…", "TenantName": "…", "UserMails": null, "Mail": "[email protected]", "MailNickname": null, "AreasOfExperties": null, "Gender": 1, "UserRole": 1, "ProfileImageUrl": null, "RegistrationStatus": 0, "CasesParticipating": null, "CasesOwned": null, "CasesAdministering": null, "PendingInvitations": [
], "IsProfilePublic": true, "IsO365Admin": false }
Response HTTP/1.1 200 OK Cache-Control: no-cache Pragma: no-cache Content-Length: 2014 Content-Type: application/json; charset=utf-8 Expires: -1 Server: Microsoft-IIS/8.0 Set-Cookie: ProxiedARRAffinity=ad24…;Path=/;Domain=
97 Date: Sat, 13 Feb 2016 12:30:47 GMT
{ "id": "ba03a90c-7598-4942-bb63-da0f9353fc48", "upn": "MMcD8zDM7JOUdxRD9e_iWbMPs1ADI5plf49Zm5t8JzY", "username": "Claire…", "givenName": "Claire", "surname": "Passa", "description": "A specialized lawyer in robotics", "tenantId": "738e52d6-b00e-4704-bfa6-0cd2c1f962b3", "tenantName": "Migir", "userMails": null, "mail": "[email protected]", "mailNickname": null, "areasOfExperties": null, "gender": 1, "userRole": 1, "profileImageUrl": null, "registrationStatus": 0, }
98 Appendix II - External software libraries used in the thesis
A large number of packages and external libraries has been used for the implementation. Almost all packages have been added through NuGet, and are enlisted in the subsections below.
LPMService project (ASP .NET – Web API) Antlr AutoMapper EntityFramework Microsoft.AspNet.Mvc Microsoft.AspNet.Razor Microsoft.AspNet.SignalR Microsoft.AspNet.SignalR.Core Microsoft.AspNet.SignalR.JS Microsoft.AspNet.SignalR.SystemWeb Microsoft.AspNet.Web.Optimization Microsoft.AspNet.WebApi Microsoft.AspNet.WebApi.Client Microsoft.AspNet.WebApi.Core Microsoft.AspNet.WebApi.HelpPage Microsoft.AspNet.WebApi.Owin Microsoft.AspNet.WebApi.OwinSelfHost Microsoft.AspNet.WebApi.WebHost Microsoft.AspNet.WebPages Microsoft.Azure.ActiveDirectory.GraphClient Microsoft.Data.Edm Microsoft.Data.OData Microsoft.Data.Services.Client Microsoft.Graph Microsoft.IdentityModel.Clients.ActiveDirectory Microsoft.IdentityModel.Protocol.Extensions Microsoft.OData.Client Microsoft.OData.Core Microsoft.OData.Edm Microsoft.OData.ProxyExtensions Microsoft.Office365.Discovery Microsoft.Office365.OutlookServices-V2.0 Microsoft.Owin Microsoft.Owin.Host.HttpListener Microsoft.Owin.Host.SystemWeb Microsoft.Owin.Hosting
99 Microsoft.Owin.Security Microsoft.Owin.Security.ActiveDirectory Microsoft.Owin.Security.Cookies Microsoft.Owin.Security.Jwt Microsoft.Owin.Security.OAuth Microsoft.Owin.Security.OpenIdConnect Microsoft.Spatial Microsoft.Web.Infrastructure Modernizr Newtonsoft.Json nuget-bot.Microsoft.VisualStudio.Services.Common nuget-bot.Microsoft.VisualStudio.Services.WebApi Owin Respond Swashbuckle Swashbuckle.Core System.IdentityModel.Tokens.Jwt System.Spatial WebActivatorEx WebGrease
LPMClient project (WPF Client) AutoMapper CommonServiceLocator Extended.Wpf.Toolkit iTextSharp jQuery MahApps.Metro MaterialMenu Microsoft.AspNet.SignalR.Client Microsoft.Graph Microsoft.IdentityModel.Clients.ActiveDirectory Microsoft.OData.Client Microsoft.OData.Core Microsoft.OData.Edm Microsoft.OData.ProxyExtensions Microsoft.Office365.OutlookServices-V2.0 Microsoft.Owin Microsoft.Owin.Host.SystemWeb Microsoft.Owin.Security Microsoft.Spatial MvvmLight MvvmLightLibs Newtonsoft.Json
100 Owin System.Net.Http System.Net.Http.Formatting.Extension
Common project (library) Microsoft.Graph Microsoft.OData.Client Microsoft.OData.Core Microsoft.OData.Edm Microsoft.OData.ProxyExtensions Microsoft.Office365.OutlookServices-V2.0 Microsoft.Spatial Newtonsoft.Json
Contract project (library) Microsoft.Graph Microsoft.IdentityModel.Clients.ActiveDirectory Microsoft.OData.Client Microsoft.OData.Core Microsoft.OData.Edm Microsoft.OData.ProxyExtensions Microsoft.Spatial
LPMSAndroidClient & LPMSPortableLib projects (Android Client & PCL Lib) Microsoft.IdentityModel.Clients.ActiveDirectory CommonServiceLocator Microsoft.Practices.ServiceLocator Microsoft.IdentityModel.Clients.ActiveDirectory MvvmLightLibs Newtonsoft.Json Xamarin.Android.Support.v4 Xamarin.Android.Support.v7.AppCompat com.alliance.calendar
101