we use the concept of a service catalog for integration with complex web services and more

Introductory

In this article, we will talk about a very specific architectural pattern that is used in narrow circles. On its basis such a wonderful thing as a “service catalog” is modeled. In this article, we'll look at examples of high-level objects and how they are “decomposed” into simple services. We will not delve into specific implementations of the directory; instead, we will look at it “from above” and work with its abstraction. If you read this paragraph and didn’t understand anything, that’s okay, now let’s put everything on the shelves using more or less real examples.

Start

Let's start with the fact that in our life we ​​often encounter typical situations in which there is a “User” subject and he interacts with the “Function” object. Examples could be a user and options in the personal account of a banking application, a subscriber and communication services of a mobile operator, or a network administrator activating options in the router’s web control panel.
Let's generalize these examples and formalize them a little. In each of them, imagine that the user presses a button, the action of which makes a request via a certain API and activates the service. This is quite a working story. At this step, we can identify the entities “User”, “Action” and “Service”.
The “Action” entity in some systems is not a simple operation, and it is associated with technical difficulties in implementation. We will not talk about how to register requests in queues, whether to use asynchronous execution, etc. We will now look at examples close to life and see what problems will lurk. Understanding the problem will prepare our consciousness to develop a solution: we detail the “Actions” into several layers and entities that are used in our pattern.

Preparing for the experiment

To understand the process, we will consider simple cases from the telecom sector with a certain degree of simplification. Let us be asked to implement an application that accepts requests from the user’s personal account to connect several services: “Telephony service”, “Roaming service”, “International call service”, “Outgoing call barring service”.
To make the process more understandable and closer to combat conditions, we will design a simple application that should connect to mobile communication equipment and execute requests there. In particular, we will work with HLR. The action of connecting/disabling services is called the clever word “provisioning”, but for us this is not important now, the main thing is that we understand what will be discussed next 🙂

Let's start work, of course, by studying the specification (API) of such a piece of hardware. You can find publicly available specs and support files from one of the HLR vendors on the web. here And here.

Many of you don’t have access to real hardware and most likely won’t for objective reasons, so let’s create a “mentally” simple emulator that will accept requests from us and change the state of the subscriber profile. Our HLR emulator, like its real brother, will use a TELNET-type interface for provisioning. Requests are simple text strings containing the subscriber ID, service name and some value. The value itself either enables or disables the service, or changes the behavior of the service. The equipment validates commands and prevents you from performing an incorrect sequence of actions, for example, activating a forwarding service for a subscriber who is prohibited from making voice calls.

Mental activity a la discovery

First, let's try to solve the problem head-on and see what happens as a result. The process of connecting services will be something like this: our application receives a request with the name of the service to be connected/disconnected. We can also request a list of previously connected services. Next, let’s check the name of the service in the request and compare it with the commands executed in the terminal.
For example, a subscriber wants to connect to the “Telephony Service”, then we need to execute the command in the terminal:

HGSDC:MSISDN=78001234567,SUD=TS11-1;
HGSDC:MSISDN=78001234567,SUD=OBO-2;

Everything is simple here, with the first command we activated voice communication. The second command sets a restriction on making outgoing calls to international destinations. Calls are only allowed within your home country. One may wonder, why set such a restriction?
When adding a voice service, the equipment would automatically set the “default” limitation, i.e. there would be no restriction, thus the subscriber could accidentally call an expensive paid international destination. We would not like to upset him, so the main telephony service allows calls to numbers within the country.
Of course, the subscriber has the right to call international destinations and can activate the corresponding service, and we will execute the command:

HGSDC:MSISDN=78001234567,SUD=OBO-0;

Now the lucky subscriber can call from anywhere in our country to any international number, but only while within the home network.
Our impromptu subscriber will most likely want to use calls while in another country. We will, of course, provide him with this opportunity; he has the right to activate a service that allows registration in roaming operator networks. We will unquestioningly execute the command on it:

HGSDC:MSISDN=78001234567,SUD=OBR-0;

So far everything looks simple and clear.
Now imagine that the subscriber has activated the outgoing call barring service for exactly 10 minutes. Why he needs this service, we engineers don’t really want to know and don’t need to know. Basic rule: the desire of the subscriber is law for us. So let's run the appropriate command:

HGSDC:MSISDN=78001234567,SUD=OBO-1;

So, now it will be more interesting. What happens when the service is disconnected after 10 minutes?
Common sense dictates that you need to set OBO-0because Previously, our subscriber subscribed to the service for international calls and we need to continue to provide this service. I hope you agree with this too.

What if the subscriber suddenly wanted to turn off the international call service without waiting for the agreed 10 minutes to expire?

I hope you have already felt how with one small service and three services, some logic is born in our code with dependencies and priorities of services, and if you need to add new services that affect this service, you will have to work hard to build the correct command sending chain in the code in the terminal. Those. maintaining our code will steadily become more complex with the number of services being implemented, especially affecting related services. Also, the subscriber service department may want to change the operating logic of some of the services; in this case, we will have to revise the entire code.

Let’s look at another interesting case involving the same subscriber who managed to remove the “outgoing call barring” service. Suppose we allow the subscriber to disable such an important service as “voice communication”. In this case, in the absence of other basic services, we could remove the subscriber profile from the equipment. When the subscriber activates the voice communication service again, we will have to send commands like this:

HGSDC:MSISDN=79001234567,SUD=TS11-1;
HGSDC:MSISDN=79001234567,SUD=OBO-0;

Question: Well, well… why now OBO-0?

The fact is that our subscriber had previously connected to a service that allowed international calls, so it is not logical to execute the command first on OBO-2and then send the command to OBO-0. As you can see, the logic of our code should become more complicated. We need to not only connect services correctly, but do it optimally, without loading the equipment with unnecessary commands.

You could suggest another option for interaction between services: let the “international calls” and “outgoing call barring” services also be disabled when the “voice” service is removed. This option is quite workable, but the subscriber would have to reconnect these “additional” options when connecting a voice connection and remember what he used. In such a simple example, this does not look like a problem, but believe me, there are real cases in which forcing a subscriber to connect many options does not seem like a healthy idea, especially if the services cost money and are written off at the moment they are added.

Service catalog concept

How we would like to have a system in which we could:

• Easy to maintain, especially for people who are not involved in development/coding

• Declaratively assign rules of interaction between services

• Reduce the complexity of the final solution and simplify its introduction to the market

All the problems described are solved by the “service catalog”!

Question: So, wait! We have already realized that there is magic that will solve all our problems, but we still don’t know anything about the catalog. What is he like?

There are many implementations of directories, but they all have common principles, differing in details and capabilities. In general, a directory is an abstraction that consists of several layers/levels:

CFS (Customer Facing Service) – the layer contains objects that represent a user service. The user can be the end consumer, i.e. we are with you. Also, this object may not be the last link and be included in objects at a higher level, for example, on the product layer, which contains one or more user services within the product.
The user can “touch” such an entity with his hands, for example, by activating the “Static IP address” service for his home Internet and interacting with it in his personal account. For example, you can activate a service, disable a service, or change the “IP address” parameter.

RFS (Resource Facing Service) – the layer lies below the CFS layer and represents an abstract equipment service. In the future, we will call such a service the word “service” and it will be clear to us that we are now talking about objects of the RFS type. Each RFS is mapped to a certain atomic entity/flag/feature/capability of the end equipment.

Most often, a user service consists of several services. For example, we could model the CFS “Internet Service” and connect it with several RFS services: RFS to activate GPRS service on HLR (2G/3G Internet), RFS to activate registration in LTE (4G Internet), RFS to limit the default Internet on your home network, RFS to select standard speed, RFS to select APN access point.

In total, we have 2 types of abstractions, one of which is understandable to the user, and the other to the engineer. As already mentioned, a service can be associated with one or more services. Those. a complex service may require activation of several services on several different types of equipment.

In a specific example with 4 services, we could create a model of their interaction, as in the picture below.

The picture, of course, will not be able to convey all the logic of the catalog model, but now let’s look at what’s happening here:
We have 3 RFS simulated. We gave the name RFS meaningful, just like in programming variables are called clear names for ease of working with them. The long name “RBARRING_OUTGOING_CALLS” means that this RFS must manage the barring service on some equipment and it concerns only outgoing calls. Those. This hints that in the future we might create RFS associated with limiting incoming calls, if the end equipment supports this feature.

This particular RFS also has a specific parameter (setting/property/characteristic/variable, whatever you call it), which can take one of the text values ​​“HOME”, “NO” or “ALL”. In essence, it will become clear to us that when RFS accepts the setting value as “NO”, then there should be no restriction in the subscriber profile on the equipment. In the case of “ALL” we must block all outgoing calls to the subscriber.

Next we see that all RFSs have several possible actions with them: “Activate” and “Modification”. It is worth noting that we cannot modify a service if it has not previously been connected. Those. When connecting with the first CMNCALLS service, nothing should happen to the subscriber, because Modification communication doesn't work on something that doesn't exist yet. If, after adding this service, they add CVOICECALLS, which activates 2 RFS, then the following will happen:
a) You need to activate “RTELESERVICE_VOICE”
b) You need to activate “RBARRING_OUTGOING_CALLS”, but take the value for the parameter from the CMNCALLS service, because it has higher priority than CVOICECALLS.
Because CMNCALLS was already connected previously, and it has a higher priority, and in order for the state of services to correspond to the state of activated services on the equipment, it is required that the parameter inside the RFS have a value specifically for this service.

Unfortunately, this picture does not show how exactly the CFS priority affects the choice of value for the RFS parameter, so for clarity, we will redraw it for RBARRING_OUTGOING_CALLS in a different form. Everything here is quite obvious and I think no explanation is required.

Algorithm for searching for changes

Previously, we were able to formulate a little rules for what the directory should do when connecting to the service. So the whole task of the directory comes down to the fact that it must understand what action needs to be performed or not performed with RFS when connecting/disconnecting CFS.

The directory performs the following steps:

1. Generates a list of CFSs that were connected to the subscriber before the request was executed

2. Generates a list of CFSs that will remain connected to the subscriber after completing a request to connect/disconnect services

3. For each from the list, it will receive a list of activated RFSs with set parameter values

4. Finds the difference between RFS lists and generates a delta of changes that needs to be performed

Let's try to formalize some rules for searching for such differences in a table:

Our example is quite simple, so the number of cases and rules is much less than in combat solutions with a catalog. Having read up to this part, I hope you have noticed the emerging theses in the formation of the rules:

• You cannot deactivate RFS if it has not previously been activated

• You cannot modify RFS if it has not previously been activated

• You cannot reactivate RFS if it was previously activated

• Modification of an RFS with a parameter is possible if a higher priority CFS is connected and the value of the parameter in the RFS differs from the current one

Actually, based on the results of executing the catalog processing rules, which is also the decomposition of high-level CFS objects into simple RFS objects, we receive a list from the RFS and actions with them. At this stage, we already have all the necessary information to execute the commands described at the beginning of the article. In this case, the sequence of commands will be linear to a large extent; all that remains is to check the action and name of the RFS in the application and compare it with a specific equipment command. The value of the RFS parameters will help with the correct formation of the request for equipment.

Instead of a conclusion

The article was more aimed at obtaining theoretical knowledge. Because Each solution using the catalog pattern will be individual and implement the specific needs of your business. For those who first encounter the situations described in the cases, it will be useful to know what possible solutions exist. And if you already knew everything, then that’s just wonderful! This means you will be able to implement a complex project and at the same time avoid making mistakes and miscalculations that can await you in the most unpredictable places…

Links:

¹ – The priorities of interaction between specific services working with the same service are determined not by the engineer’s intuition, but by the customer of such a product. For example, the customer could be a customer service department/product manager, etc.