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.