Endjin - Home

Endjin.Licensing – Part 2: Defining the desired behaviour

by Howard van Rooijen

header-endjin-licensing-pt2-defining-p1-1024px

We’ve open sourced a lightweight licensing framework we’ve been using internally over the last couple of years. In a 5 part series I’m covering the motivation behind building it, how you can use it, how you can extend it for your own scenarios and how you could use it in a real world situation:

I’ve been an advocate of BDD for a number of years, and have tried most of the frameworks, but in the last 18 months have established a monogamous relationship with Specflow. I find that writing higher level specifications, in English, really helps me focus on the behaviour of the system I’m creating but doesn’t suffer from the brittleness & fragility that traditional unit test suffer from, when it comes to refactoring the underlying code. I started by writing a specification that covered the main scenario I wanted to support in Vellum:

At this point I had the epiphany that what I needed to build was not a complete licensing platform (like Rhino.Licensing), but a framework that would allow me to easily create custom validation rules; notions like a website address or product SKU are not the concerns of the licensing framework, they are concerns of the product consuming the licensing framework – in this case Vellum.

So, I deleted the specification and wrote a second draft, which covered the more intrinsic requirements of a licensing framework:

The intrinsic data the license should contain is a license Id, so that we can make the license uniquely identifiable, a date of issue, a date of expiration (when the license should invalidate), a license type (subscription, annual, perpetual) and a collection of user definable key / value pairs to act as an extensibility point for users to build their own validation logic on.

Once the initial success path was apparent, a failing scenario then became immediately obvious:

The next desired behaviour for a licensing system is to detect that a license may have been tampered with (for example manually modifying the expiration date):

Once the specifications were fleshed out it didn’t take long to create the initial implementation of the framework in order for the specifications to execute successfully. Once that was done, it was then possible to create a new project to contain the Vellum specific validation rules. Having had a few more days to mull over the licensing behaviour we wanted to implement for Vellum, it was quite simple to recreate and elaborate my very first specification:

Once this was completed, it was very straightforward to flesh out another 8 features containing a total of 47 different scenarios, covering off all of the different permutations we could think of.

In the next part, I’ll take you through a step by step guide for creating and validating a license.

@HowardvRooijen

Sign up to Azure Weekly to receive Azure related news and articles direct to your inbox every Monday, or follow @azureweekly on Twitter.

About the author

Howard spent 10 years as a technology consultant helping some of the UK's best known organisations work smarter, before founding endjin in 2010. He's a Microsoft Accelerator Mentor, and a Microsoft Azure MVP. You can follow him on Twitter via @HowardvRooijen