Abstract - Technology growth is increasing rapidly and becoming very agile. Billing, the main core of the telecommunication industry, is one of the example domains. Many applications are developed and delivered to meet the target line of marketing programs. This application, called Satellite, cannot be measured by its visibility and performance. Service-oriented architecture implementations are mitigating all challenges that occur in these applications into manageable services so it can be measured and extrapolated for the next projection. Implementing these concepts involves the design of the front end channel (north bound interfaces), business services itself, and adapter (south bound interfaces) to communicate with all billing service providers or other sub systems. This article will discuss about how to design a service-oriented architecture solution to be implemented in the billing domain.
Telecommunication is a critical industry in any geographical area. Technology is rapidly developing, especially in voice and data services. Currently, voice services are becoming ordinary products with more becoming free of charge. All telecommunication providers are competing to deliver these services with promotions into product packages which give free additional voices/data services or another free package. This effort been made to increase the number of subscribers, and maintain the subscriber’s loyalty. Meanwhile, internet expansion and the simplicity of access make the data services growth rapid, even if it has more usage than short message services. Most telecommunication subscribers use data services daily, especially for those professionals that have high mobility and high demand of fast information retrieval. Several subscribers still use short message services, but the traffic is not higher than the data services. We can say that short message services have reached their saturation point because there is no additional technology that can be adopted and developed on this service.
Delivering a high-availability application on a revolutionary business process is recommended. The high demands from any marketing department to fulfill subscriber needs makes all delivered applications become partially segmented on their own business process. Eventually, it will lack manageability and reusability. Every time an application is developed it will need the same costs, it can be double from the existing budget. The capability to intensify revenue and the number of transactions becomes unclear. Resources being used almost every day reach their maximum capacity on delivering applications.
Service-oriented architecture is the first step in answering this challenge. By imposing an application as a service, things become more transparent and measureable, hence giving higher availability and reusability which can leverage all business processes. Yet, there are big costs in setting it up the first time, but it can then accelerate the next development for the revolutionary business requirement that comes from marketing or other business units. In this article, writers will discuss strategies to enable service-oriented architecture with the telecommunication industry by giving less impact with current running services on production.
Satellite Application in Billing
Besides the core network, the billing unit is the backbone in every telecommunication company. All supporting business applications are built and run by the billing unit. These applications are separately built by different developers and run in different environments, although sometimes different applications have similar micro functionality. Because of its heterogonous kind we call it a satellite application.
Currently the satellite application in billing is not transparent. We cannot measure its usability, resource usage, and end-to-end process performance. The main purpose of the satellite application developed is to support the business processes as fast as it can to make revenue on the right time schedule of product launch. Developers build their own functions even though there are existing ones. This behavior makes development become costly, there is such unneeded repetitive development. On the other hand, it will take more resources for the applications that are run.
Most satellite applications are connected to the billing back end system. Satellite applications are connected through Sempena. Sempena is the application that has capabilities to invoke API of the back end system. However, the more satellite applications that are connected, the more the cost will be paid. Moreover, it will be bottlenecking on Sempena. Resizing of the Sempena instances cannot equally offset the growth of the back-end system demands that are coming from satellite application. Sempena itself does not have capabilities to make the requests. The service-oriented architecture approach is a solution that was proposed, exposing satellite applications as services and introducing Sempena as a south bound interface on a monolithic platform.
Designing Service Architecture of Billing
The first step to design a new architecture solution is by identifying the current running system. Almost all satellite applications have very similar patterns. Receiving requests from the request provider, processing it according to certain business processes, sometimes involving several back end systems, and give the response synchronously/asynchronously. By looking at this pattern, we can now have vertical-slice figures of the main component:
- Request providers (north-bound system) are components that send requests to the application or the consumer of the services.
- Services Providers (south-bound system) is a component where customer profiles and charging systems are held.
Between those components, we define business services, where the business process logics are run.
Designing Request Providers Handler (north bound interfaces)
Request providers are the components which deliver the traffic to the services. To be able to understand the language of the request providers we need to define interfaces that have capabilities translating the requests into defined standardized services language. We call this component a north bound interface. Its main responsibility is translating requests into parameterized elements according to standardized service contracts, acting as a router to corresponding business services, and encapsulating responses to be able to be understood by request providers. North bound interfaces interact with three different request providers:
- USSD Menu Browser, or widely known as UMB. UMB is the component that gives us accessibility to navigate menus through USSD commands. UMB uses predefined XML to represent menus and communicate with other components through HTTP Request. Every telecommunication enterprise may have different XML structures to presents the menus. UMB’s XML elements consist of two main components, which are the menu title, and URL address definition of the child menus. UMB maintains transaction sessions with a certain amount of time configuration. It will send the timeout and ends the session when exceeding the time configuration. This parameter become the SLA of all services that use UMB as their request providers.
- MMX is a network element that delivers SMS messages. It communicates directly through SMSC, translating data packets into SMPP packets. It has responsibilities delivering requests of P2P communication into P2A communication and A2P communication. P2A communication is coming from the MMX to all SMPP clients that connected to it. A2P communication is initiated from all SMPP clients to the MMX.
- Clarify is a billing tool for displaying customer profiles and for doing provisioning. This tool is used by customer services for handling customer complaints. Clarify can talk via HTTP Request and API Invocation to other system/sub system. It’s connected directly to the billing end system and other Web tools that are connected to the cross domain end system.
From the way it communicates, we can design the north bound interfaces into two types of handlers which are the HTTP Event Listener and SMS Event Listener. The HTTP Event Listener will be responsible for handling all request/response communication that used http protocol. This listener can be separated again based on the messages type:
- XML/HTTP (XML over HTTP)
This event listener is used for handling all XML-based requests that use http as its transport layer. Extracting the XML requests into standardized services contracts and route it to the business services to be processed. On the other hand, it will encapsulate the business services responses into particular XML format response based on defined XML that are being used. Business services invocation can be in synchronous mode and asynchronous mode. When XML/HTTP Event Listener is used in the synchronous mode, it will block the process, waiting acknowledgement from the business services or until certain SLA is reached. Meanwhile, asynchronous mode will give an immediate response to request provider and finish the request in a separate process. This mode can ensure the transaction will not exceed the SLA defined by the request provider. However, it will give invisibility of the transaction results on the requester. Requester must wait the notification from other channels (i.e. SMS or push USSD).
- Plain/HTTP (Text over HTTP)
Plain text is often used by Web-based transactional applications to displays responses. For example a Web form, that displays messages when we successfully register on events or forums. A Plain/HTTP Event listener is used for this transaction. We do not need certain structured formats for displaying the response after the transaction is finished. This listener must be able to distinguish HTTP methods being used by the requester to send the requests whether POST or GET since it is quite different on the query parameters parsing process. A defined URI is the routing translation into certain business services. For example we have:
All incoming requests to the HTTP Handler will be then routed into Internet Allowance Business Services as defined in the URI and invoke check-allowance operations. The URI and query parameter are translated by the HTTP Handler into standardized service contracts that can be understood by all business services.
- SOAP/HTTP (SOAP over HTTP)
This listener is most widely used with service-oriented architecture. Most of the services are in Web-services form. Web-services often used SOAP/HTTP as its transport protocol. Unlike the other two, SOAP/HTTP, the event listener only routes the requests to the end system defined in the query parameters. It translates some of the parameters into standardized service contracts that can be understood by the end system.
The implantation of the SMS Event Listener is quite difficult since it talks via SMPP Protocol, which is a peer to peer connection. SMPP packets that deliver by the MMX need to be extracted into standardized service contracts so that it can be understood by the defined business services. It also applies for the outbound traffic, but it transforms the XML response into a SMPP packet. We can define this event listener into two types:
- Inbound Event Listener (P2A listener): Requests are coming from the MMX that are initiated by the handset: MO (Mobile Originating). To be able to do MO communication, the P2A listener must bind a connection to the MMX communication channel first. As defined in SMPP specification v3.4, MMX will send bind receiver response messages to indicate that the connection has been successfully established. Afterwards, MMX will send real short messages encapsulated in deliver_sm PDU data until it receives unbind command or FIN flags on the TCP data initiated from the P2A listener. This communication runs in synchronous mode or asynchronous mode depending on the mode used by the MMX.
- Outbound Event Listener (A2P listener): Requests are initiated by the business services that used the A2P listener. It consists of the outgoing SDC definition, and the message will be in XML format. These two components talk via the Messaging Bus. The A2P Listener will listen to a certain defined bus to consume the requests, then translate it into SMPP PDU packets. To send the SMPP PDU packets, consisting of the business services message, the A2P listener must also bind a connection to MMX. Afterwards, the listener will send it as a submit_sm packet, and it will be acknowledged by MMX by sending submit_sm_resp packet. Unlike the Inbound event, Outbound event communication is only established when there is a message request in the bus.
Figure 1 – North Bound Interfaces Architecture
Designing Services Providers Adapter
Service providers are the components where customer profile and provisioning data are kept. Services providers of a billing unit commonly consist of AMDOCS and databases. AMDOCS is a system that holds all subscriber profiles and handles subscriber provisioning, whereas databases contain other information of the subscribers and business logs of when the transactions are happening (i.e. first activation of a SIM card).
Connections through AMDOCS are made via API and method invocations, like EJB. Applications that previously managed this connection are called Sempena. It invokes AMDOCS API and returns corresponding results. However, this method is not transparent since we cannot measure the performance, and we do not know when the AMDOCS are getting slowed down because of heavy traffic. Secondly, a current interface (Sempena) is not able to handle heavy incoming requests with any throttling capabilities and proper scalability. It always becomes a bottleneck on any transaction.
The first challenge is managing the traffic to keep the AMDOCS in its performance and exposing scalability and transparent-ability for interface. One of the solutions is by designing a connection pool mechanism to do traffic load balancing. Hopefully it can divide traffic weight equally to each AMDOCS instances.
Figure 2 – Load Balancing in AMDOCS Adapter
Even though the number of threads configured in the AMDOCS instance is 50 (or 25 in some cases), only one socket connection (max 2 socket connections) can be connected to AMDOCS and invoke Amdocs APIs. Making too many connections at the same time would not be good practice; there will be a network connection overhead cost to be paid on both sides. Throttling in certain service level agreements is one of the best ways to limit incoming traffic when AMDOCS performances start degrading.
AMDOCS connection cannot be established as it is, it has ticketing mechanisms. Every operation that needs to be invoked must hold a ticket to go through. Each ticket will be valid for 36000 seconds (10 hrs) until it is in use. But if the ticket has not been used since its retrieved, it will automatically expire within 3600 seconds (1 hour). By this condition, most optimum session timeout configurations are at 36000 seconds, while idle timeouts wait 3600 seconds for a valid security ticket. The ticket recycle process needs to be managed by someone. This person will initiate ticket creation by the time the process is started, and periodically replenish tickets based on maximum ticket lifetime.
Designing the Business Domain Services
Design consideration for business domain services are time and costs. To deliver services according to a defined timeline given by a marketing unit, or other a business unit requester there is a need to have standard implementation specifications. Business domain services are specific implementations, while general ones are the application framework. Application framework templates are designed to handle various types of business processes. There are five building blocks that need to be considered when building business domain services:
- Logging Proxy, is a framework proxy for handling all errors or recording transaction logs that happened during the business processing. We can configure whether it needs persistent logging or log files with various types of logging levels (DEBUG, ERROR, FATAL, INFO, and WARNING).
- Identifiers are a unique ID generator for each transaction request; an ID is generated specific with the components that use it.
- Patterns are the main building blocks that can be used to form design solutions. There are several service patterns such as Publish-Subscribe, Request-Reply, Content-based Router and others. Almost all billing domain cases are synchronous Request-Reply, since the front end channels have requirements to get the response instantly once invoked. All business errors and faults are handled by the pattern (Service Engine). Therefore, in the business services implementation there is no need to define how to handle an exception. Each request is routed to its services group and operation name using the process dynamic override.
Figure 3 – Content Based Routing on Framework Pattern
The next article will continue this series.