Managing Vocabularies in Multiple Policies Development
I follow "BizTalk Technical Discussion" distribution list and I found mails bouncing around two very interesting topics - how to manage vocabularies in BizTalk rule engine for multi-policy development and how to create automated build scripts for BizTalk. I thought to talk about these two in my coming entries. This one goes to vocabularies in BizTalk.
Question was - In a team development environment, when multiple developers are building rule policies in their individual development machines, how should the development of vocabularies be managed?
At first glance, there are two approaches -
1. Same Vocabularies for All Policies -
You develop single set of vocabularies and let all policies use it in their rules. This approach is simple and straight. You develop some small number of master vocabularies which can be used across all policies. But, the problems would be the management of the versions of the vocabularies and the associated rule sets that use these vocabularies. If a vocabulary is changed or is updated, the rule sets will somehow have to be updated, either by creating a new version of the policy and updating the vocabulary. ****
2. One Vocabulary per Policy -
In this approach, you create one vocabulary for each policy. When you change any vocabulary it does not affect any policy other than the one using it. The drawback would be that you would have multiple vocabularies and could quite possibly have the same vocabulary defined multiple times (repetition of work).
Both are practical and working solution with some pros & cons. Question is which one to use and where?
In any development, purpose should be to use fine balanced decouple development so that changes/maintenance in one component does not affect other. Now, Policies use facts and vocabularies are defined over facts. Keeping this in mind, I prefer to develop vocabularies based on relationship between facts and policies. Here is how I propose my opinion about these approaches and reader please feel free to jump with your opinions.
Approach-1 (Same Vocabularies for All Policies)
- We should avoid to have same set of vocabularies because changes in vocabularies will affect all associated policies. However, if all policies use same set of facts then there is no harm in using single vocabulary set (aggregating all facts) because due to usage of the same fact set, all policies need to be modified/updated when vocabularies or associated facts change. However, keeping extensibility and maintainability in radar, this is not a preferred solution at all unless you have a simple rule sets or a real compelling situation. ****
Approach-2
(One Vocabulary per Policy) - This approach is the preferred. When, we create vocabularies, we can make it fact driven. We can use following guidelines -
- If some facts are used by multiple polices, Then create a single common vocabulary (aggregating all common facts) over them. If common vocabulary/facts changes, it will definitely affect all policies.
- For policy specific facts, create policy specific vocabulary (aggregating all policy specific facts together). Now if any policy specific vocabulary/facts changes, it will affect only associated policy not others.
- For long term facts, we can create a separate vocabulary.
We can have a fine balanced decoupled implementation of vocabularies to get efficient management of rules.