SID Q&A - Question 10

This is the tenth in 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.

In this Q&A we discuss the practicalities of using ProductSpecification to record and manage the configuration of complex Products.

So4It:  I'm trying to grasp the correct way of mapping ProductSpecifications and ResourceSpecifications to each other.  For example, take SIM-card as the resource in question since this is the resource that creates the biggest challenge for me at this point, and for ProductSpecification I choose the MobileTelephony.

Here is the problem background:

A typical ProductOffering for the MobileTelephony-spec will be shown in external interfaces (webshop) as a Product where you can choose the form-factor of the SIM, since you want to make sure you get the correct form-factor that matches the terminal where you will use this SIM.

This means that somewhere in the ProductSpecification structure there will be a Characteristic and a number of CharacteristicValues that will be translated into an option for the webshop-user.

At the same time the ResourceSpecification holds a REQUIRED field called partNo.  And a SIM-card partNo will without any question point out a SIM-card of one specific form-factor.

Actual problem:

For me this means that I can't put a ResourceSpecificationCharacteristic holding a bunch of alternative form-factors on my ResourceSpecification for the SIM since each ResourceSpecification will contain one single partNo, and each partNo corresponds to just one form-factor.

So I can see no other alternative than to put the form-factor Characteristic on my ProductSpecification.  But once I've done that I can't see any use for the reference in the MobileTelephonySpecification to the SIMResourceSpecification, rather it just complicates things.

So how would you model this?  Skip the ResourceSpecification reference and by that completely sever the link between the Resource-Domain and the Product-Domain when it comes to Specifications (at least for SIM), or keep the link but by doing that be forced to create some kind of mock-up duplicate ResourceSpecification for the SIM, that doesn't contain any partNo that actually means anything and add ResourceSpecificationCharacteristics for the form-factor to this mock-up? Both ways seem kinda wrong to me, is there a third alternative?

Andrew: You have raised an interesting point; however it must be remembered that the relationship between Product Specification and Resource Specification is m:m so that there has to be an association class that "resolves" this m:m.  The association class will list for each product specification all the valid Resource Specs part numbers (probably with validity dates).  The association class therefore acts like the Product Spec Characteristics that you envisaged.

I do still see a problem though - if there is more than one "type" of ResourceSpec involved with the ProductSpec then you will see all the part numbers from both ResourceSpecs.

But the "terminal" is a Resource which has a ResourceSpec and that ResourceSpec "requires" a particular SIM type (ResourceSpec) given by the part number.  There is a m:m recursive (self) relationship on ResourceSpec that needs to be resolved by an association class that would have a "type" (Required, Forbidden, Optional).  So the Terminal type needs to be an input on the Product selection process (or part of the Product selection) which would be used to select the correct SIM type part number which would be to display the user.

So4It:  So this is what I have today

• In the ProductSpecification I have a ResourceSpecificationReference that contains the ResourceSpecificationId and the order (if any) it should be presented in.
• In the CompoundResourceSpecification I have a Set of ResourceSpecificationReference's that dictates what ResourceSpecification is included in the CompoundResourceSpecification

Andrew:  OK - so you have in data modelling language "denormalised the structure" - that's OK and sensible for an on-line app.

So4It:  So the association class sound like the ResourceSpecificationReference that I have. There I can put any information I want to be associated with the association between the ProductSpecification and the ResourceSpecification right?

Andrew:  Right.

So4It:  It sound like you are saying that in the ResourceSpecificationReference you should always have information about, what is valid to use in the ResourceSpecification it is pointing to.

Andrew:  Yes, but this is in addition to the Compound Resource you have created.  The new association class on that resolves the "m:m recursive" (self) relationship would say which Resource is compatible with other resources - for example which Terminal devices need Large SIMs and which need Small SIMs.

So4It:  So in the case we are talking about below we will have the following,

We have a compound resources specification for PhysicalSimCard that has 2 ReourceSpecification's, 1 for the SimCard with form LARGE and another for the  SimCard form SMALL. The compound ResourceSpecificationReference will specify that 1 of its ResourceSpecifications has to be selected but only 1.

Andrew:  OK - so you are saying that there are Large and Small SIMs and one must be selected, but the structure I am talking about (that resolves the m:m recursive relationship could be used to say which type of SIM should be used with what kind of Terminal, but of course you may have another way of enforcing this business rule.

So4It:  So what you are saying here is that in the CompundResourceSpecification we should have a class describing what included ResourceSpecifications are compatible with each other. How would we do this case?

CompoundResouceSpecification1
      |
      |-------CompoundResouceSpecification2
      |                    |
      |                    |-------------------AtomicResourceSpecification1
      |                    |-------------------AtomicResourceSpecification2
      |                    |-------------------AtomicResourceSpecification3
      |
      |-------AtomicResourceSpecification4


AtomicResourceSpecification4 can only be select together with AtomicResourceSpecification1so in the CompoundResouceSpecification1 I would have a class (what is a good name of r it?) that says AtomicResourceSpecification4 belongs with AtomicResourceSpecification1 for example?

Andrew:  To associate AtomicResourceSpec1 with AtomicResourceSpec4 you need a new class ResourceSpecCompatibility, it would have the following attributes

resourceSpec1.id
resourceSpec2.id
compatibiltyType (valid values = Required, Forbidden, Optional)
validFromDate
validToDate

So for your example:
resourceSpec1.id = AtomicResourceSpec4
resourceSpec2.id = AtomicResourceSpec1
compatibiltyType = Required
validFromDate = 01-Jan-2000
validToDate = 31-Jan-2099

and to make sure it can't be combined with others
resourceSpec1.id = AtomicResourceSpec4
resourceSpec2.id = AtomicResourceSpec2
compatibiltyType = Forbidden
validFromDate = 01-Jan-2000
validToDate = 31-Jan-2099

resourceSpec1.id = AtomicResourceSpec4
resourceSpec2.id = AtomicResourceSpec3
compatibiltyType = Forbidden
validFromDate = 01-Jan-2000
validToDate = 31-Jan-2099

So4It:  Where is this class stored on the CompositeResourceSpecification ?
In the case I explained where would it be stored in the hierarchy?  In CompoundResouceSpecification1 and if not then where?

Andrew: Your structure would remain unchanged - I am proposing an additional structure, but I guess it could be implemented as below
 
CompoundResouceSpecification1
      |
      |----CompoundResouceSpecification2
      |              |-----AtomicResourceSpecification1
      |              |                   |------Required, AtomicResourceSpec4
      |              |
      |              |-----AtomicResourceSpecification2
      |              |-----AtomicResourceSpecification3
      |
      |----AtomicResourceSpecification4
      |                 |------Required, AtomicResourceSpec1

So4It:  I'm sorry I don't understand what you mean ere. I understand the class you are proposing but I just have a hard time understanding where to store it. I guess the class

public class ResourceSpecCompatibility{
        private Integer resourceSpecificationId1;
        private Integer resourceSpecificationId1;
        private CompabilityType compabilityType;
        private Date from;
        private Date to;}

obviously has to exist.   What I am thinking is where to store it. There are a couple of options

1. We store it independent from the ProductSpecification structure and fetch it using the id of the ProductSpecification
2. We could store it on a CompositeProductSpecification  if we assume that compatibility will only exists between ProductSpecification that has a common CompositeProductSpecification parent but can we say that you think?

As I see it 1) is more flexible but makes it less performant when we need to collect  the data.

Andrew:    I'm not an expert on physical design, so I wouldn't like to comment further on how to implement the information.  I just know that the hierarchy you have defined needs to be augmented with a structure that defines how Resources in the hierarchy (or other hierarchies) can be related.