Exploring the Party Model with Oslo’s System.Identity – Part 3
In Part 1 of this series we covered the basics of how Oslo’s System.Identity implements the Party Model and how System.Identity can be used to model real world scenarios. We continued our exploration of System.Identity in Part 2 by modeling more complex real world scenarios and illustrating how System.Identity can handle asymmetric relationships and transient nature of real world relationships over time.
In this post we’re going to explore one of the most powerful features of the Party Model – the ability to flexibly model hierarchical structures.
The Scenario
For the purposes of this post we will be using the following real world scenario:
- Dave works on the Enterprise Architecture team within Microsoft IT’s Technology Office
Analyzing the Scenario
As we’ve seen in previous posts, System.Identity can support a limitless number of relationship types between Parties. This power allows for fine-grained modeling which is particularly useful for supporting relationships that have some sort of associated semantics. As an example, we saw how System.Identity could support the scenario of “Dave is married to Brenda” at three levels of semantics:
- There exists a PartyToPartyType relationship of type ‘Marriage’ between Dave and Brenda
- Dave plays the Role of ‘Husband’ vis-a-vis Brenda
- Brenda play the Role of ‘Wife’ vis-a-vis Dave
In looking at items #1-3 an argument could be made that item #1 represents the overall structural context of the relationship. This is easy to see when one realizes that items #2 and #3 could be taken away and there is still a lot of meaning that can be derived from the fact that there is a ‘Marriage’ relationship between Dave and Brenda.
The idea that some relationships provide structural context is a core concept within the Party Model. It allows the Party Model to handle a wide range of scenarios beyond just interpersonal relationships – especially for Parties that are not individuals.
As we saw in the first post, organizations are also Parties within the Party Model. This intuitively makes sense as organizations (e.g.,corporations) are entities that can enter into contracts and can also be sued.
Using these ideas, we can leverage the System.Identity schema to model the hierarchical structure of organizations, in this case a portion of Microsoft:
As is illustrated above, we’ve modeled the latter portion of our “Dave works on the Enterprise Architecture team within Microsoft IT’s Technology Office” scenario. Specifically, we’ve again leveraged System.Identity’s PartyToPartyType to represent a structural relationship between Parties – namely a ‘Parent Organization’ structural relationship.
It is important to note in the diagram above that the ‘MSIT Technology Office’ is required to be the ContextParty for the ‘Parent Organization’ relationship to allow the hierarchical structure to make sense conceptually. The party of ‘Microsoft IT’ is a ‘Parent Organization’ in the context of the ‘MSIT Technology Office’ Party – the reverse doesn’t make sense. However, it is also worthy of note that the following hierarchical structure is functionally equivalent to the structure above:
The point of illustrating these two diagrams is to underscore an important point of modeling hierarchies using the Party Model – hierarchical structures are inferred at runtime from the semantics of the relationships in question. Therefore, care has to be taken to ensure the semantic integrity of the hierarchical structures within the Party Model data store (documented standards may be of help here to help ensure consistency).
Using these concepts we can now instantiate MSIT’s Enterprise Architecture team and also instantiate Dave’s employment on the EA team:
Viola! A multi-level hierarchy within the Party Model!
Bonus Scenario
As cool as being able to model hierarchies (and everything else) is, the Party Model has yet another piece of goodness that it can provide us. The Party Model’s clean separation of Parties and relationships allows for an interesting capability – the simultaneous modeling of multiple hierarchies across a set of Parties.
Arguably this is a less intuitive application of the Party Model, but it can be a quite handy feature. In essence, the modeling of multiple hierarchies allows for various semantic views into a set of Parties. For example, let’s look at the scenario of “All expenses are billed to, and paid by, Microsoft IT”. We can model this additional hierarchy (let’s call it the ‘billing hierarchy’) using System.Identity in the following manner:
As the above diagram illustrates, the Party Model supports the concept of layering one hierarchy on top of another. In this specific case we’ve layered the ‘billing hierarchy’ for MSIT on top of the ‘organizational hierarchy’. As we’ve seen previously, any number of hierarchies can be layered on to a set of Parties by just repeating this pattern. As one can imagine, a software architecture based on the Party Model has a lot of power and flexibility.
Next Time
I’m going to take a small break for the next post in the series, but when I resume the subject of the post will be the application of the Party Model in terms of modeling access controls.
Stay tuned!
SkyDrive Files