Coupling and persisting/presenting the data

After the data has been abstracted and gathered, it still needs to be processed. It is useful to have already assigned some properties to users (such as: “is expert on”) and to have made connections between users.

Making connections between users is relatively simple, for example in an email the sender and recipient can be connected, but deciding when a user is an expert for example is a lot different. There is no obvious way to decide when a user is an expert, there is some sort of rule required to decide when this is the case.

Thus, to achieve this goal some sort of rule handling is required. In this chapter we will discuss two methods to do this, one in which the rules are hard-coded into the business logic layer and one which uses a business rules engine.

Hard-coded rules

The simplest way to achieve this goal is by hard-coding the rules in some service in the business logic layer. When data is being processed, the service is called to decide what properties to give the user. Advantages and disadvantages are listed in the appendix under section:Hard Coded rules

Business rules engine

Another possible solution is the implementation of a business rules engine, which according to the Wikipedia page about it (http://en.wikipedia.org/wiki/Business_rules_engine) “executes one or more business rules in a runtime production environment”. Advantages and disadvantages are listed in the appendix under section:Business rules engine

Data storage

After coupling the data and drawing some conclusions from it, the data needs to be stored in some sort of database.

After storing this data in the database, we will be able to query it in order to ask questions such as: “Which developers communicate with each other?” or “Who operates as a bridge for communication?” or “Is anyone completely isolated?”. Answering these types of questions is the main goal of the application. In order to conform to the one of the key quality attributes the stakeholders requested, performance, these types of queries need to be able to answer such questions as rapidly as possible.

A database type that is by far the most popular one around is the relational database. These types of databases have been around since the 1970s and are proven technology with a large community.

Another option is graph databases, which are relatively new in the field though the graph theory that preceded it is quite a bit older. These are more oriented towards objects and their inter-relationships. This is interesting as getting insight in relations between entities is basically what this application is required to do.

Therefore we researched these two possibilities for storing the data processed in the Business Layer. First we’ll briefly explain how both the relational database and the graph database work. Next, we’ll discuss its advantages and disadvantages and finally conclude by saying how well fit either approach is for this problem and which solution we recommend.