Endjin.Licensing - Part 2: Defining the desired behaviour
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:
- Part 1: Why build another licensing system?
- Part 2: Defining the desired behaviour
- Part 3: How to create and validate a license
- Part 4: How to implement custom validation logic
- Part 5: Real world usage patterns
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:
Feature: Create a License In order to run vellum As a user I want to be able to obtain valid licenses for my runtime requirements Scenario: Create a Vellum License for the Free Azure Website rate Given I want a license for my Azure Website http://mysite.azurewebsites.net And I have a staging slot configured at http://mysite-staging.azurewebsites.net And I want to run on a free subscription And my billing subscription commenced today And I have entered my Azure subscription details When I request my license Then it should be a valid license And it should have been issued today And it should expire on the last day of this month
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:
Feature: Validate License In order to allow users to only use my software with a valid license As a software provider I want to be able to validate the license based on its criteria Scenario: Validate a 'Subscription' License that was issued today Given they want a 'Subscription' license And their license was issued today And I generate their license When they validate their license Then it should be a valid license And it should have been issued today And it should expire on the last day of this month
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:
Scenario: Validate a 'Subscription' License that expired last month Given they want a 'Subscription' license And their license was issued a month ago And I generate their license When they validate their license Then it should be an expired license And it should have been issued last month And the license should have expired on the last day of last month
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):
Scenario: Tamper with the expiration date of a license Given the user is issued with a valid 'Subscription' license And the user tampers with the expiration date of the license When they validate their license Then it should be an invalid license
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:
Scenario: Free Azure Hosting Plan License that was issued today and is running on a Free Azure Hosting Plan License with a valid host name is valid Given they want a 'Subscription' license And their customer id is 'c8ca3109-6fbf-4b75-b6ee-67a1a0a56bd1' And their subscription id is '03c1b02b-7806-4e94-8044-140d95ff52d1' And their license was issued today And their SKU is 'Free' And their development host is 'localhost' And their site name is 'mysite' And they are running the site on a 'Free' Azure Hosting Plan And they are hosting on a website called 'mysite' And I generate their license When they validate their license Then it should be a valid license And it should have been issued today And it should expire on the last day of this month And the metadata should have a value of 'localhost' for the development host And the metadata should have a value of 'mysite' for the site name And the metadata should have a value of 'Free' for the SKU And the metadata should not have a value for instance size And the metadata should have a value of 'c8ca3109-6fbf-4b75-b6ee-67a1a0a56bd1' for the customer id And the metadata should have a value of '03c1b02b-7806-4e94-8044-140d95ff52d1' for the subscription id
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.
Sign up to Azure Weekly to receive Azure related news and articles direct to your inbox every Monday, or follow @azureweekly on Twitter.