Generally, "service logic" and "interaction logic" are intertwined and together provide services. Most operators run many services (sometimes also referred to as "applications"), hosted on multiple Service Control points (SCPs). With operator consolidation and competitive sourcing of SCPs and services, commonly a single network will use both SCPs and services from several vendors.
Why not use "service chaining"?
To combine these disparate services — and get around the SS7 signaling system limitation of only a single service controlling a call — operators often use "service chaining". This method alters telephone numbers in signaling messages, to make a series of services appear as a single service to the switch.
This works, but puts a great load on core network elements. For simple interactions, the core network must trigger the service layer many times, using numbering plans for feature interaction. For example, for a particular service, the switch would call the service layer (the SCP). By reconfiguring the SCP, when the switch gets a resulting message back, the "dialed number" transfers to another number that prompts a look-up, which sends it back to the SCP again, invoking another service (and so on).
The drawbacks to service chaining include:
-
New application insertion is difficult, because it requires re-configuration and feature modification of core networks and any new SCPs.
-
Operators may have difficulty making changes, because interaction requirements mean SCP application logic is tightly coupled.
-
As you have more and more services, and more and more combinations, the whole thing gets harder and harder to change and maintain.
