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.

SID Q&A - Question 9

This is the ninth 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 blog we discuss Buckets and Quotas, extensions need for the SID to support prepay and other complex forms of payment and allowances.

So4It:  My CTO has told me about buckets and is proposing to use these to allow us to manage allowances.  What does the SID have to say about Buckets?

Andrew:  This is an interesting area and I’ve been doing a lot of thinking and work on it over the last 8 or 9 years.

The fact is that most telcos BSS’s are far behind on technology - many are still using billing systems that were developed in-house in the 1990's or earlier and rdbms is everywhere in the BSS side of the business.  On the OSS side things are very different.  The industry has been fast to adopt new technologies and devices like the IN use very hardware and software to deal with the high volumes.

Below is an excerpt of a document I am working on in my spare time, a “A Rough Guide to SID Implementation for SOA Integration” which together with another document I’ve started writing “A Rough Guide to Using the SID for Application Integration” could, one day, form a sort of “SID for Dummies”.

As you will see from the description and model your CTO is on the right track.  The model below (at the moment) doesn’t include Usage classes, but that I believe is fairly straight forward.  The Rating and Guiding process first of all examines the UDRs and turns them into CFS Usages with basic pricing information applied and then attaches them to the relevant CustomerAccount(s) and applies the ProductPricing applying the quotas/allowances and product specific rating/discounting to create what the SID calls ProductUsage.

The deduction of the cost of these Usages from the Buckets can either happen in real-time as with IN/PAYG products or monthly as part of the Pay Monthly billing cycle.

----------------------Excerpt begins-----------------------

Prepay classes

The SID has nothing to help with “Pay as You Go” (PAYG, or Prepay).  This is a little shocking considering how long SID has been in use in mobile phone companies.  There is a little philosophical issue about whether it is the CustomerAccount that it is prepaid or the Products under the account; I favour the latter as this will support convergent billing in the future, or rather the present as it is perfectly technically possible for a Customer to have a monthly postpaid subscription for say talk time, and have a PAYG subscription for data (though few CSPs offer this).  Unfortunately most CSPs cannot get their heads around the idea of having just “Customers” (or rather CustomerAccounts) and having the prepaid/postpaid label associated with the Product rather than with Prepaid Customer and Postpaid Customer.

To handle Prepaid (PAYG) customer (accounts), or even better, Product, you need to consider the kind of “refill”/“reloads”/”top-ups” the customer can make.  The simplest reload is just money to be credited to the account; however most CSPs offer a range of reloads or “packs”:

• Data packs that offer, say 500Mbytes, 1Gbyte or 2Gbytes
• Message packs that offer, say 500 messages
• iTunes packs that buy a fixed number of downloads from iTunes store
• Combinations of the above

Some CSPs have certainly considered prepay packs for post pay customers for example I think some offer overseas calls that pre-pay for calls while roaming abroad.

Each of these types of reloads has its own balance associated with it.  A customer can be out of money for talking (a balance of 0 in minutes, or money) but still be able to browse the internet or send messages because he/she has a non-zero balance on these services.  In fact some CSPs even let their prepaid customer go “into the red” on some services if they for example pay by credit card.

Each refill/reload/top-up is added to a specific “bucket” that holds the balance for a given service or set of services.  This balance, be it in Money, Mbytes, or a count of units is then debited by use of the appropriate service.  Some buckets can be very specific; for example if a customer has a “Message” bucket then when he/she sends a SMS or MMS its balance is debited until it gets to zero.  Once this balance is exhausted another bucket or balance – say the general “Money Bucket” takes over and it too is debited for messages (and calls) until it also reaches zero.  So there can be a precedence or preference between using one bucket over the other.

The SID has introduced the idea of Allowances in a complex structure (see SID class AllowanceProductPriceAlteration) which is OK (if a little clumsy) for postpaid but does not work well for Prepaid or real-time billing where topups would credit the AllowanceProductPrice and usage would debited it.

In line with industry thinking on convergent billing I have introduced the concept of CustomerAccountBuckets.  These buckets are used to hold the balances which can be associated with either a Product or set of Products or CustomerFacingService or set of CustomerFacingServices.

Here is a class diagram I created for my new ABE, Customer Account Bucket.

The other new class is an extension class for CustomerAccount, CustomerAccount_AMCF to hold the prepaidPostpaidIndicator a flag to show the type of account (but I still don’t like it).

Eagle eyed readers may have also noticed that I have added a direct link between CustomerAccount and Product that shows which account owns the “subscription”.  There is still of course the more generic method of linking the two classes through the CustomerAccountProductInvolvementRole class which this does not replace, but rather ‘specialises’ for the most common relationship between these classes – “ownership”.
----------------------Excerpt ends-----------------------