Natural Access organizes services and their associated resources around a processing object known as a context. Each instance of an application binding to a TCAP service access point is a unique Natural Access context. Contexts are created with ctaCreateContext.
All events and messages from the TCAP service are delivered to the application through a Natural Access queue object. Queues are created with ctaCreateQueue. Each context is associated with a single queue through which all events and messages belonging to that context are distributed. More than one context can be assigned to the same queue.
Different application programming models are possible depending on how many TCAP service access points (how many TCAP subsystems) are implemented by the application and how the application is organized.
An application that uses a single TCAP service access point uses a single-context, single-queue model as shown in the following illustration:
For a single-threaded application that uses multiple TCAP service access points (implements multiple subsystems), a multiple-context, single-queue model is recommended (as shown in the following illustration). In this case, the application has a single event loop with events from all service access points delivered through the same queue. The application determines which service access point a particular event is associated with from a service user ID (suID) value returned with each event.
For multiple-threaded applications using multiple TCAP service access points (one per thread), a multiple-context, multiple-queue model is recommended (as shown in the following illustration). In this case, each thread has its own event loop and receives only the events associated with a service access point on its Natural Access queue.
Note: For this programming model, each thread or event queue must be assigned its own entity ID. The entity ID must be unique among all applications on that host accessing any of the SS7 services.
