Our 3.0 version made some basic design choices regarding relationships between services. That is, our service relationships would always be composite, which means that certain services will share a tight-coupling with each other in a parent-child relationship. For example, our picking service would be a composite of location management, item master management and administration services. In this way, it would have direct access to product and location information. Since these services were still discrete, we could easily choose which location or item master management service to request the data from, giving us great flexibility in delivery for customers where they have multiple systems storing this information.
The downside to an all-composite architecture is that you start to develop switch-mania, which is the act of defining switches to control behavior of a service when it is being used as a composite versus when it is being consumed in a standalone fashion.
Our next generation will break these relationships using a publish/subscribe messaging model. This will allow the receiving service to decide how it wants to behave versus dictating this through complex switch management. For example, we can disable auto reservation of items in inventory simply by ignoring the ReservationRequest messages, which can be turned off at the pump or at the service.
This, however, is not the focus of this entry. The focus of this entry is what I learned about modeling relationships when thinking about which relationships I wanted to break since I was moving to this model.
What I learned is that there are certain composite relationships that make sense. For example, our picking service is a composite of our ticketing service. This relationship continues to make sense as a composite because a pick ticket is a specialized version of a ticket. This realization led me to understand that there are two key types of relationships: composite and business service.
A composite relationship is one in which the aggregating service is a superset of the service being consumed. It should follow a generalization/specialization rule for those that model using UML. The business service relationship is one that is based on the context in which the services are to be used. Hence, the relationship between picking and location management are totally contextual as to when is an item considered removed from inventory. In some shops, its when it's picked and in others, its when it's shipped. Controlling this is now as simple as telling location management service which notifications to pay attention to and which ones to ignore, but both picking and shipping publish events that could impact inventory counts.
[ 1 comment ] ( 28 views ) | [ 0 trackbacks ] | permalink
