1. X-Road pattern catalogue and reusable components catalogue
Anti Alman Quretec OÜ

2. Pattern catalogue purpose
Main question
How to design X-road services?
Intended audience
Systems architect
Developer
(Public sector)
Presentation focuses mostly on introducing the pattern catalogue
There will be a short overview of the reusable components at the end of the presentation
The X-Road pattern catalogue focuses on how to design X-Road services
There are few materials about designing X-Road services
The pattern catalogue aims to fill that void
The main topics of the pattern catalogue are
Defining inputs and outputs of X-Road services
Combining multiple services to gain extra value
Processing the X-Road messages
Initially the intended audience was new members form the public sector
During the project we moved away from focusing only on the public sector
(Public sector needs the materials for new employees)

3. Creating the pattern catalogue
Primary input
Existing X-Road materials
Interviews
X-road central server logs
RIHA
Discussions with RIA employees
Existing X-Road materials
Should mention X-Road technical integration patterns by Andres Kütt
Has the same purpose at initial glance
Actual overlap is small
Should be seen more as a complementary material
Interviews covered on next slides
X-Road central server logs were initially planned as one of the most important inputs
Unfortunately knowledge gained from the logs was not as much as we hoped
Details on the following slides
RIHA turned out to be an important resource
Service descriptions
Overview of information systems and companies
Descriptions of information systems
(Allowed better preparation for interviews)
RIHA dataset is partially out of date or incomplete
Discussions not covered in the presentation
(Main goal was to clarify the vision and overview of intermediate results)

4. Interviews Interviewees Purpose of interviews Mainly public sector
Mainly systems architects
Purpose of interviews
Overview of X-Road services
What to promote and what to avoid
Discovering patterns
Scope adjustments
Validation of data mining results
Interviewees both from private and public sector
Mainly systems architects
Focus was divided between the application guide and pattern catalogue
RIA was of big help for finding people to interview
Private sector was deemed important, because public sector tends to outsource the development from the private sector
The main goal of interviews was to identify patterns
Initial expectation was that the interviewees have their own cool solutions they want to promote
This expectation realized only partially
A lot of exploratory questions were needed to find the patterns
(Next slide – „Own interesting solutions seen as ordinary “)
During the interviews we presented log mining results that were related to the interviewee
To validate the methodology and results
To gain further insights – log mining shows us only a partial picture
Some of the interviewees were
Andmevara
Eesti E-tervise Sihtasutus
Eesti.ee
Cybernetica

5. Interview notes Very few „innovative“ solutions
Own interesting solutions seen as ordinary
Simple and task-specific solutions are preferred
„Unfair“ criticism of reliability
Problems of other systems attributed to X-Road
During the interviews it turned out that there were rather few innovative solutions
There is a tendency to keep the X-Road part of a system simple
Interviewees saw nothing special in their interesting solutions
This is part of the reason why they were unable to pint out innovative solutions
Interesting solutions were found mostly by leading questions
(For example the time consuming task pattern in population registry was found because we know to ask about it)
The things that stood out the most
Services are often created to solve a specific task
General purpose services are rather rare
(One good example would be the universal pull service in population registry)
Problems beyond ones security server are attributed to X-Road
If there is an error then it is mostly seen as an error of X-Road
Members do not differentiate if the error was in security server to security server communication or at the information system on the other end
(There are even instances where a faulty message is sent to security server and the flaw attributed to X-Road)

6. Logging in X-Road central server
Only service calls are logged
Not sufficient for data mining
Service responses?
Sessions?
Hardcoded user IDs?
Monitoring procurement will improve logs significantly
Only service calls are logged – for each call
Time
Service
Consuming company
Consuming person
Limits the log mining possibilities significantly
Parallel usage and nested service calls can not be detected wit certainty
Lack of session Ids limits the availability to see which service usages are a part of the same process instance
(Adding session Ids would place an extra requirement to the consumers)
User Ids are often hardcoded
Situation when all services are always consumed by the same information system using the same personal code
Makes it hard to derive sessions
Monitoring procurement will improve logs significantly

7. Data mining Human vs. automated system Log filtering Sessionization
Frequent item sets
Process map
The purpose is to analyse X-Road service consumption and derive patterns from that analysis
Our approach consisted of five main steps
Differentiating human users from automated users
Service consumption by humans tends to be more regular and during work hours
Service consumption by automated systems tends to be more irregular
Log filtering allows us to work with a smaller subset
Services of a specific system
Service consumption during a specific time period
Sampling
Sessionization aims to find out which service invocations belong to which process instances
Based on delays between two service invocations by the same user from the same company
We found the optimal delay to be ~16 minutes
Sessionization has some issues
Some process instances may merge together
Longer running process instances will be broken down into multiple processes
Frequent item sets
Sets of services often invoked in the same session
We rely on Apriory algorithm
We assume non frequent sets to be deviations from the normal workflow
Process map
Similar to how business processes are mapped
Shows the most frequent sequences of service invocations
Picture is a sub-map for information system „E-toimiku süsteem“

8. Patterns About 25 patterns Divided into three main groups
Primitives
Functional patterns
Processing patterns
Non-static resource
Number of patterns is approximate
Some patterns are described in multiple parts
For example long running task has two patterns for the same problem (problem is described under a separate pattern)
Three main groups of patterns
Primitives - Basic building blocks for X-Road services
For example push and pull
Functional patterns - Solutions that are based on primitives and offer some additional functionality
For example long-running task pattern
Compositional patterns - Consuming and processing of X-Road services
For example parallel and sequential usage or header based message routing
Detected based on
Interviews
Service descriptions in RIHA
Literature – Most business integration patterns are usable on X-Road
Data mining results
The pattern catalogue should not be seen as final
Current list of patterns is definitely not exhaustive
Existing pattern descriptions may change in time
Alternative solutions for the same problems may come up

9. Reusable components catalogue
What helpful tools are available for developing X-Road services?
Central overview
Short descriptions
Free and commercial components
Non-static resource
There is a significant amount of reusable components related to X-road
Descriptions are distributed and there is no central overview
It is difficult to find a reusable component for a specific task
I suspect that most private companies have their own reusable components internally
The main aim of the components catalogue is to provide a central hub that allows to find existing components
Component descriptions are rather light weight
Describing a component is kept simple
Detailed description, documentation and source code can be located somewhere else
If needed a repository will be provided for the component
The component catalogue contains both free and commercial components
Company may use it as a way to advertise it’s products („in good taste“)
It is intended to be a non-static resource

10. Summary X-Road not used to it’s full potential
Community is rather distributed
Begin with the „trivial“ when introducing patterns
Pattern catalogue and reusable components catalogue should be non-static
Instead of „Thank you for listening“ slide I decided to finish with some general thoughts
X-Road is not used to it’s full potential – Advertising more different service designs will hopefully be helpful
Community is rather distributed – knowledge does not seem to cross company boundaries easily
Start with the basics when describing the patterns
Something that is basic for an experienced X-Road developer might not be basic for a new developer
(If there is time then mention how one developer saw push service as some kind of odd reverse service hack and doubted if it is ok do develop something like that)
It is important that the pattern catalogue and component catalogue will be added to over time