Resources and Service – Part 2

In part 1 of this post I discussed the lifecycle of a Resource. Now I want to discuss the difference between Services and Resources and help you understand the beauty and elegance of the SID model in describing these things.

As I stated in Part 1 Services delivered by LogicalResources. If you are familiar with UML modelling this is very easy to understand, the LogicalResouceSpec is the “component” in a UML component diagram. The balls (or cups) on sticks that are drawn on the box representing the component in UML represent the Services that the component offers.

So, for example, if you have a low level component, such as a ActiveX component to handle, say Customer data and it supports two interfaces, GetCustomer() and SetCustomer() then it would look something like the picture at the start of this entry.

The two interfaces services this component offers other components in an application. These other components are themselves LogicalResourcesSpecifications (if they are on the UML diagram), so the services are ResourceFacingServicesSpecifications (RFS Specs).

When all the components are implemented they can be put together to support one or more Use Case, for example these RFSs could support a Use Case called “Process Customer Order”, or “Update Customer Details”. As I’ve argued before in this blog (I think), a Use Case is often a specification of a Customer Facing Service (CFS), so a UML Use Case (and/or Sequence Diagram) is a CustomerFacingServiceSpec.

When you code and build the component then you create an instance of the LogicalResourceSpec, a LogicalResource offering services, ResourceFacingServices.

“Hey Presto!” as the magicians say when they pull a rabbit out of a hat, I hope you can see how Resources, RFSs and CFSs all fit together... A CustomerFacingServiceSpec is a Use Case and/or Sequence. A ResourceFacingServiceSpec is the interface provided by LogicalResourceSpec, a component on a UML Component Diagram.

It was suggested in a Blog on the TMForum Community pages, by no less than John Reilly, that it might be a good idea to get rid of ResourceFacingServices at some time in the future. To quote John’s Blog:

The discussion often then leads to the difference between the two types (subclasses) of Service, Customer Facing Service (CFS) and Resource Facing Service (RFS). Some of us think that if the Service Configuration Aggregate Business Entity, for which there are two long-standing but unimplemented contributions, was developed, then RFS would meet its demise. This would then negate the need for a CFS since it would be a solitary subclass of Service, simplifying the SID quite a bit.
The reason for this thought is that those of us who work in the provisioning world believe there is a lot that must be added to RFS to support the configuration and activation of Services. Service Configuration would fit satisfy these requirements.

To be fair to John, and I did challenge him on this issue, he was intentionally being contentious.

However I can follow John’s argument: how a Resource behaves can be defined by a configuration that is applied to a Resource to tell it how to deliver a particular (Customer Facing) Service. For example, the HLR can be configured not to allow a given Product (subscription) to use the CFS ‘Make Voice Call’, but I would argue that the CFS itself has been disabled. There certainly will be a step in the sequence diagram for “Make Voice Call” where the status of this service is checked by the HLR, but surely this is just a RFS?

Anyway. For the time being RFSs and CFSs are safe and I hope they remain so, particularly if more people understand how they work!

As ever, comments, ideas, criticisms and calls for help or assistance are always welcome. I am trying to write this blog a little more frequently and external inspiration is always welcome.