Condividi tramite

Exploring the Party Model with Oslo’s System.Identity – Part 2

  • Articolo

In Part 1 of this series we discussed the basics of the Party Model using Oslo’s System.Identity schema. Specifically, we discussed the System.Identity constructs for Party, Role (including the Employee and Customer specializations of Role), and TaxonomyEntry (to allow for assigning a “Kind” to Parties and Roles). We also put these System.Identity constructs to use in modeling some real world scenarios and illustrated how the power of the Party Model stems from the composition of rich object graphs that model the real world.

For this post we’re going to expand on our previous work and illustrate how the Party Model can accommodate even richer real world scenarios than we have seen up to this point.

 

The Scenarios

For the purposes of this post we will be using the following scenarios to put System.Identity through its paces:

  1. Dave’s younger brother is Jason
  2. Dave is married to Brenda

 

Analyzing Scenario #1

Since we already have an understanding of the fundamental pattern of the Party Model, we can start with an initial model that could fulfill the scenario of “Dave’s younger brother is Jason”:

Scenario3.1

While the above model captures the essence of the relationship between Jason and Dave, it doesn’t necessarily capture the totality of the scenario. For example, from the model above we explicitly know that Dave takes the Role of Brother vis-a-vis Jason, but we don’t know explicitly know the opposite. While this seems trivial, it really isn’t from a system/application perspective. If we modeled a system this way to understand Jason’s relationship with other Parties we would have to not only query for all the Roles where ForPerson = Jason we would also need to query all the Roles where Context = Jason.

While an argument can be made that this situation is inelegant, but workable, there is another aspect to the scenario we haven’t fully captured – the potential semantics of the Brother-to_Brother relationship. Once upon a time being the older brother had a lot of significance in terms of the laws around inheritance. In some countries this may still be the case. Let’s take a look at a refined System.Identity instantiation incorporating these ideas:

Secnario3.2  

The ability for the Party Model to support asymmetric relationships (e.g., Dave is Jason’s older brother and Jason is Dave’s younger brother) provides a powerful mechanism for modeling the real world where relationships can have fine-grained semantics.

 

Analyzing Scenario #2

For Scenario #2 let’s start by employing some proper semantics in our System.Identity instantiation. As with the previous scenario, we’ll leverage the Party Model to instantiate an object model with fine-grained relationships between the Parties. The good news is that modeling “Dave is married to Brenda” is pretty intuitive:

Scenario4.1

In addition to Roles System.Identity also supports a structure that is common in Party Model implementations – a structure for modeling high-level relationships between Parties in addition to Roles. In the System.Identity model this construct is the PartyToPartyType. The use of the PartyToPartyType allows us to add the final semantic relationship to our model:

Scenario4.2

Instantiating the scenario “Dave is married to Brenda” in this fashion affords the benefits of attaching fine-grained semantics to the relationships between Dave and Brenda. Specifically:

  1. Our object model allows the distinct relationship of “Marriage” to be tracked and assigned to Dave and Brenda
  2. Within the “Marriage” relationship we know that Brenda plays the Role of “Wife”
  3. Within the “Marriage” relationship we know that Dave plays the Role of “Husband”

The list above is another illustration of how the Party Model composes a model of the real world by layering relationship upon relationship – and as we all know composition in software is a “Good Thing”.

 

Bonus Scenarios

In this bonus scenario I wanted to illustrate the power of the Party Model in the context of the temporal nature of relationships. The first post in this series alluded to this capability in terms of employee relationships, but unfortunately using marriage as the frame of reference is a better illustration.

At the risk of offending the “Family Values” crowd, let’s consider the following scenarios:

  • John Doe was married to Jane Doe from 03/24/1998 to 10/13/2005
  • Jane Doe married John Q. Public on 07/18/2008 and is still married to John

Oslo’s System.Identity, like many Party Model implementations, has a mechanism for denoting the effective time span of relationships. Within System.Identity this takes the form of “StartDate” and “EndDate” fields on many of the System.Identity classes. Using these fields we can instantiate the following object model to handle our bonus scenarios:

BonusScenario

The scenarios depicted above illustrate that while the Party Model object graphs get more complicated, they are nothing more than the iterative composition of a few basic patterns. As you might imagine, the ability for a system to accurately model the fine-grained relationships that are initiated, and terminated, over time as wide range of applications across a number of software domains.

 

Next Time

OK, the next post in the series will explore another powerful feature of the Party Model – the ability to model hierarchical relationships, especially with Organizations.

Stay tuned!

 

SkyDrive Files

Comments

  1.  You have a typo in your diagram.  Role ID 758909 should have a start date of 3/24/1999, not the 2009 date depicted.
  2.  This diagram doesn't show the changes in Party Attributes; are those relevant and how are they represented. That data relates strongly to role, and isn't at all anecdotal.  How does the party model handle that?  i.e. Jane Doe had a different last name prior to marriage to John Doe, perhaps a different last name after marriage to John Doe, and perhaps a different last name after marriage to John Q. Public.  That attribute change is a direct result of the relationship change.
  • Anonymous
    October 03, 2009
    @David Merrill Thanx for the comments! You're spot-on about the changes in name over time. You're also correct that names can be more optimally handled using PartyAttributes in the System.Identity schema. This allows for attributes to be timeboxed - potentially in alignment with Role changes over time. Arguably the key is to represent core "Jane-ness" in Party and abstract the transient aspects of Jane (e.g., her last name) into timeboxed entities. You may be interested to know that the TM Forum's Shared Information/Data Model (SID) implementation of the Party Model addresses this problem directly by abstracting PartyName into its own class that has allows for timeboxing. Am I in the ballpark in answering your question? Thanx for reading! Dave