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
