Exploring the Party Model with Oslo’s System.Identity – Part 1
It occurred to me the other day that I asserted that the Party Model is a “Good Thing” without providing any proof whatsoever to back up my claim. While I would love to believe that everyone subscribes to my views and opinions because of their irrefutable wisdom, I have no illusions to the reality of the situation (although the wisdom is pretty good ;-).
As such, I thought I would put up a quick post aggregating links to other resources on the Party Model to back up my assertion.
Unfortunately, I didn’t really find any resources to link to.
Rather than again directing folks to the published works on the Party Model, I thought I might write up a little series exploring the power of the Party Model using Oslo’s System.Identity as the underlying implementation. Now there are many Party Model implementations (e.g., Silverston, Fowler, Arlow & Neustadt, TM Forum’s SID, etc) that I could’ve used for these posts, however System.Identity possesses the core constructs of the Party Model so all the ideas that I will be discussing are 100% transferrable to other Party Model implementations.
That and Oslo is new shininess, so it makes it a little more fun.
The Scenarios
What makes the Party Model so powerful is that it provides an elegant and flexible means for modeling the real world. For this series of posts I will draw on my own life to provide fodder for the scenarios that we will use to put System.Identity through its paces. Below is a list of our Party Model scenarios, which I may expand in subsequent posts as necessary:
- Dave is an employee of Microsoft
- Dave is one of Microsoft’s customers
- Dave works on the Enterprise Architecture team within Microsoft IT’s Technology Office
- Dave is married to Brenda
- Dave’s younger brother is Jason
The Diagrams
For the purposes of exploration, I’ll leverage the UML class model from my previous post on System.Identity. For our purposes, the class model represent the static structure of the System.Identity model. In this regard the classes in the model are analogous to SQL Server database tables. Since the class model diagrams have already been posted, I won’t repeat posting them here.
We’ll leverage the UML class model to allow us to create a UML object model. UML object models represent an instantiation of UML class models at runtime. For our purposes, the UML object model will represent in-memory object graphs of the System.Identity classes, illustrating how System.Identity can be used to model our real-world scenarios. In this regard, these object diagrams are analogous to records in SQL Server database tables.
NOTE – A link is provided below to my SkyDrive where a .ZIP can be downloaded containing HTML representations of both the UML class and object models.
Analyzing Scenario #1
Let’s take a closer look at our first scenario – Dave is an employee of Microsoft.
At one point in time the above scenario might have been modeled with a dedicated Employee class that had attributes such as Name, SSN, Employee Number, DOB, etc. A more advanced, but still old-school, OO design would have been to create an abstract base class of Person and then have a concrete Employee class inherit from Person. While neither of these OO designs are “bad” or “wrong”, we can reference the Gang of Four (GoF) for some advice on a potentially better way to address the problem:
“Prefer composition to inheritance”
So the question is, if the two OO designs mentioned above are classic examples of inheritance-centric design, how do we follow the GoF advice in terms of my employment at Microsoft?
The OMG specification on Party Management provides a hint as to the answer:
“By definition then, a Person or Organization has a lifecycle of its own, has state that can be externalized, has date aware behavior, and can participate in distributed transactions.”
This intuitively makes sense – I haven’t always worked for Microsoft, and I likely won’t always work at Microsoft (unless I die in my office ;-), therefore Dave should be modeled as a distinct object. This allows Dave to have a lifecycle independent from his current employment situation. Reflexively, Microsoft should also be modeled as a distinct object with its own lifecycle.
OK, now that we have object representations for the two participants in the scenario, the next step is pretty easy. Taking the OMG view, the employee relationship between Dave and Microsoft is literally the “temporal glue” that links Dave and Microsoft together – for a period of time Dave will work for Microsoft.
If one takes a mental step back and thinks about the employment relationship (at the risk of stating the patently obvious), there are two distinct aspects to the relationship – the employee and the employer – where each aspect has defined semantics (e.g., IRS responsibilities) that are assumed by the participant fulfilling the aspect. As these semantic aspects are temporal in nature, it can be argued that a participant is “playing a role” within the relationship for a certain period of time.
Now to save keystrokes, I’ll stop using the word “participant” when talking about our scenario. I’ll use a shorter word that means the same thing - “party”. From dictionary.com:
- a person or group that participates in some action, affair, plan, etc.; participant: He was a party to the merger deal.
Arguably we not only save keystrokes by using the term “party” instead of “participant”, but “Party Model” just sounds much cooler than “Participant Model”.
Nice. We now have two parties (Dave and Microsoft), where one of the parties (Dave) is playing a particular role (employee) for a particular span of time.
Viola!
We have now preferred composition to inheritance and we have capture the essence of the Party Model – the real world is modeled as relationships between parties where at least one of the parties plays a role in the relationship.
Modeling Scenario #1 in System.Identity
As will come as no surprise, System.Identity has a class for Party. While many Party Model implementations employ a Party base class and derive classes like Individual and Organization from the Party base class, System.Identity takes a different approach through the use of the TaxonomyEntry class. Essentially, every instance of Party in System.Identity can have an associated TaxonomyEntry instance that defines the Party’s “Kind”. As such, for Scenario #1 we can instantiate System.Identity for Dave and Microsoft in the following manner:
In terms of roles, System.Identity offers a dedicated Role class, just as one would expect. However, System.Identity also offers some classes that are derived from Role that represent very common roles that exist in the real world. This is common design in Party Model implementations. Specifically, there is a derived class for the Employee role which we can leverage in our instantiation of System.Identity for our first scenario. The following UML object diagram illustrates the rest of our scenario:
Like Parties, Roles can also have a Kind in System.Identity (although we skipped that here). The diagram above illustrates how Dave is playing the role of Employee in the context of Microsoft. Using these UML object diagrams it is very easy to see how we use the classes in System.Identity to compose object graphs that model the real world. As with other Design Patterns, the heart of the Party Model’s power and flexibility is its emphasis on composition over inheritance.
Modeling Scenario #2 in System.Identity
If we take a look at the second scenario – Dave is one of Microsoft’s customers – we can quickly compose another relationship using the System.Identity Customer class (which derives from Role):
The diagram above illustrates a trend we will see more as we explore the Party Model – rich object graphs.
Next Time
So for my next post in the series will explore how System.Identity, and the Party Model in general, can support more semantically rich relationships between parties, including asymmetric relationships between parties.
Stay tuned!
SkyDrive Files