SID Q&A - Question 3

This is the third of a series of questions from SO4IT a Swedish IT consultancy company who are using GigaSpaces technology to build a SID based Order Management system for Communications Service Providers.

SO4IT submitted a file full of questions to which I responded by putting my replies (labelled "Andrew:") into the text.

So4It:  How are the *SpecificationRelationship entities used in the domain model (where * could be Product or Service or Resource)?

As I understand it from the SID the *SpecificationRelationship is:

EITHER exists for a Composite*Specification and specifies how the containing Atomic*Specification are related to each other. That is the relationship itself never keeps a reference to the entities it is describing a relationship between it just says *Specification of type A has to be unique in this composite product specification" or something similar?

OR it is intended to express order, priority etc between Atomic*Specifications.  If this is the case it seems natural that they either are *Specification or that the Composites*Specification has them instead of the AtomicSpecificaiton as reference dependency.  

In the Order Management "Provisioning Conductor" I will detect if it is a Composite*Specification and then check for other Atomic*Specifications either directly in the list of Atomic*Specification or in the list of  *SpecificationRelationship. Or do you always keep them in a list of *SpecificationRelationship and just have a "no-meaning" relationship if there is no relationship between the atomics?  Or is there always an "order" relationship between child specifications in a composite specification.

Andrew:   Let’s focus on Product:  the ProductSpecificationRelationship is what is called in UML an association class and as such it is used to resolve the recursive (self) many to many relationship (association) on ProductSpecification (see the data model below).

For example if you have 3 ProductSpecs (atomic or composite) A, B, C

• A can be related to B and C through this relationship while
• B can be related to C and A and
• C can be related to A and B

So each of A, B and C has multiple relationships with each other.

The ProductSpecificationRelationship could hold

• A - B
• A - C
• B - A
• B - C
• C - A
• C - B

The attribute ProductSpecificationRelationship.type holds information on the type of relationship that each ProductSpecification has with the other

To extend my example imagine that B was an upgrade option for A but it is then replaced by C

• A - B, "upgrade to",01-Jan-2010 to 31-Jan-2012
• B - A, "downgrade to" 01-Jan-2010 to 31-Jan-2012
• A - C, "upgrade to", 01-Jan-2013 to null
• C - A, "downgrade to", 01-Jan-2013 to null
• B - C, "replaced by", 01-Jan-2013 to null
• C - B, "replaces", 01-Jan-2013 to null

Note:  The ProductSpecificationRelationship has nothing to do with the Atomic/Composite structure of ProductSpecification and is probably not of direct us in the Provisioning Conductor unless there are some issues to do with availability of Products

For example if we introduce ProductSpecification D which is an alternative for C then this would be recorded in the ProductSpecificationRelationship as follows

• D-C, "alternative", 01-Jan-2013 to null
• C-D, "alternative", 01-Jan-2013 to null

then during provisioning the instances of C is found to be out of stock then the Provisioning Conductor could provision D which is in stock in its place.

Reading the documentation I see that it says for ProductSpecificationRelationship "Some examples of such ProductSpecificationRelationships would be migration, exclusivity, dependency and substitution" i.e. B is replaced by C (migration), if you have product X you cannot have product Y (exclusivity) but to have product Z you must have product W (dependency) and if you have got C you can swap it with D (substitution).

Of course there is no limit set by the SID for the use of the type of ProductSpecificationRelationship and these are just examples of how you can use it

So4It:  OK I understand that, but do you know how these would be represented in the real domain model?  For example when I display the ProductOffering on the web page I need to display these relationships, but where are they stored?  

I mean in the ProducOffering instance I need to get hold of these when I generate the XML or JSON, so I guess I get it from the product Management API and then generate the response.  

But wouldn't that then say that yes there it is a CompositeProductSpecification that has all these, old and new in the relationship, ProductSpecifications and then the relationship explains what the relationships are.  That is why I say that somehow, I need to store, a list of ProductSpecificationRelationships when I generate the XML. 

Andrew:  We are getting into application architecture here - which is OK.

I imagine you would have some sort of Product Catalogue app that is used to set up the ProductSpecs and ProductOfferings.  In that app you would define the ProductSpec hierarchy using Composite and Atomic ProductSpecs and navigate through the hierarchy using the association ProdSpecCompositeComprisedOf.  

Another thing you need to do in a Product Catalogue is to say which products are compatible or incompatible and which are being replaced by what - this is what the ProductSpecificationRelationship is for.

I would expect the Product Catalogue app to provide a number of services - the simplest would be "get current products" - this would read the ProductOffering and ProductSpecs checking lifecycleStatus attribute (The condition of the product specification, such as active, inactive, planned.) is equal to "active".  Another service might be "Check compatibility(product1,product2)" or "Get compatible products(product1)" these 2 apps would use ProductSpecificationRelationship to check compatibility.  Another service might be "Upgrade options(product1)" etc etc.

All these services would return ProductSpec and ProductOffering information.