Licenses and design rationale

[Marcel Offermans <ma...@luminis.nl>]

To keep this separate from the terminology thread, let's start a new  
one about the design rationale behind licenses.

On Nov 12, 2009, at 13:48 , Marcel Offermans wrote:

>> [License]
>> This is more about assigning bundle groups to gateways. Routhly  
>> speaking:
>> license is one possible implementation to archive this, but having  
>> license
>> as a core concept is really not necessary, and also confusing.
>> So, what i'm saying here is not just a renaming, its more about  
>> trimming the
>> core down and make the license concept an optional implementation  
>> "plugin".
>
> I would like to defer discussions about changing core concepts to a  
> different thread. There are a couple of good reasons to use the  
> structure we have now, but I'll start a different thread about it.

Okay, let me start with explaining the way the repositories are  
structured that are used to store the meta data we need for  
provisioning. In order to do that, I will first start by explaining  
the three major subsystems in ACE:

1) dependency management
2) deployment
3) feedback

Please also take a look at the slides of the presentation I did last  
week at ApacheCon US:

http://www.slideshare.net/marrs/dynamic-deployment-with-apache-felix

(slide 22 gives this overview above)

Anyway, when we talk about licenses, we are talking about the first  
subsystem. This deals with dependency management, which is a fairly  
broad term that basically means it deals with mapping components to  
targets in a way that makes sense to users.

Components are too fine-grained to make sense to non developers.  
That's why we need to group them. You can compare this for example to  
the IKEA catalog, which groups nuts, bolts, pillows and pieces of wood  
into fine pieces of furniture like "Ivar", "Knutsen" and "Sendvik".  
These are basically the "configurations" that make sense to users and  
they are also the things that a sales and marketing department "sells".

We implemented this in ACE as a repository which relates components to  
groups and groups to licenses. In essense, the thing we call license  
is a "deployable configuration" or "product" or ... (this goes back to  
the terminology thread).

In essence this repository can be seen as a kind of catalog of things  
you have to offer.

(see slide 24)

The second repository we use is the one that maps licenses to targets.  
This is almost like the sales process, where you record which products  
were bought by which customers.

(see slide 25)

Reasons for separating these two repositories, instead of just  
combining them into one that contains components, groups, licences and  
targets is that for a couple of scenarios you don't want that:

1) Let's say you want to integrate ACE with an external system that  
keeps track of your sales. In that case you want to feed the license  
repository with data coming from that external system. In such cases  
it's way more convenient to have a repository that only contains this  
information, instead of having to change only parts of a bigger  
repository.

2) Let's say you have an organization that develops a product in one  
location and has a couple of sales offices over the world. Where the  
product is developed, the "catalog" is maintained, which makes sense  
since the developers know how to do this mapping. For each sales  
office, you have a separate license repository, which contains just  
the "sales" this office made.

3) Let's say you have a product company that sells a product and has  
several third party developers that produce plugins. In this case you  
could have more than one "catalog" and you could combine multiple  
catalogs to configure targets. So you have a single license repository  
in this case that refers to licenses that exist in more than one  
catalog.

So essentially I would like to stick with this setup in general.  
However, for example if you look at the "catalog" or "store"  
repository, you could also implement it to have less or more grouping  
levels. The essence is that there are components on one side and  
licenses on the other, with zero or more levels of grouping in between.

You could in theory come up with a completely different system for  
mapping components to targets. Take a look at slide 32 which shows how  
these two repositories mentioned above are in the end combined into  
the deployement repository. The stuff left of the "=" sign can be  
completely replaced by another system if you want to use a different  
mechanism. That means a lot of work probably!

Greetings, Marcel