WINGS Communication Server
WINGS Communication Server (WCS) is a highly reliable industrial platform for fast application building and services based on SMS, MMS, USSD, Email technologies. The product enables to create and expand mobile applications and services of any complexity in the shortest time possible; using for it system settings and not using programming.
WINGS Communication Server is a carrier-class solution implementing all necessary fault tolerance and reliability securing mechanisms, platform upgrade, replacement / renovation of hardware without customer service interruption. Solution architecture provides high carrying capacity, scalability level and load balancing. The system has an open architecture based on industrial standards; it enables to add quickly own components (agents), define message processing rules. By its architecture WCS is an integration server that enables to integrate easily with external systems.
Key Features
- Exceptional configuration flexibility, rapid development of applications and services of various complexity, without any programming
- The business logic is independent of the telecommunication technologies that you use
- Easy integration with any information systems (JMS, database management system, HTTP(S), command line, e-mail, XML files, etc.)
- Allows you to use a single system with a variety of communication channels and terminal equipment
- High reliability and fault tolerance
- Scalability up to large distributed systems
- Open expandable system
- Cross-platform system (developed completely in Java)
- Flexible capabilities to distribute SMS traffic between the available communication channels (depending on channel load and priority, content-based message routing, etc.)
- Supports all database management systems (via JDBC)
Architecture
WINGS Communication Server is a standalone application built on SOA (Service-Oriented Architecture). WCS is a multi-agent distributed system consisting of independent agents (modules) with direct data processing.
Interaction between modules is based on asynchronous XML-message exchange. JMS (Java Message Service) is used as message bus.
The system enables to filter, to route, to convert messages and also to generate messages according to the set schedule (by definition, it is a content based router). Depending on the message content the system takes decision on its further processing way. It is possible to define the initial system structure (system configuration, data flow hierarchy, message processing graphs, message processing rules, different system responses to events and etc.) as well as dynamic changes of system structure (without reset, real- time) by user defined scenarios. For instance: dynamic changes of system settings as a response to certain events, start/stop/temporary stop of any components of the system without reset and data loss.
The key element of the system is its module. All the components of the system can be combined in different ways and be performed on one particular computer as well as on the network.
Message exchange among modules is not performed directly it is done through queus. There are different queues for the system modules:
- input queue – a queue where the module takes the message;
- output queue – a queue where the module puts the message,
- information queue – a queue where the module inserts information about its events.
The queues can be stored in a memory, in a file system and in a data base. It is possible to use cluster queues; it will allow balancing load between servers. For instance, 30% of messages will be sent to one server and 70% to the other.
The messages can be addressed to the whole module, the rule group or the definite rule. Message addressing can be defined by message attribute as well as by system configuration. Some messages may need only partial rule processing. Use of target addressing allows to optimize considerably the module work; it allows not to check admittedly irrelevant rules and avoid needless checkout.
The System configuration setting defines:
- activated module samples;
- interaction rules among module samples.
The current architecture allows:
- Message piping: the System module takes the message from input queue, processes it, puts it into output queue and without waiting for the addressee’s answer, continues processing the next message.
- Fail-safety support: if one or several modules fail the messages are stored in input queue and can be processed by other module samples.
- Updating/adding modules of the System without interrupting the whole System work.
- System scalability by adding module samples for message processing from one input queue. Handler samples can be located on one server as well as on different ones.
- Actualizing the System behavior by using: XSL, SQL, PHP, PERL, JSP, C++, Java and etc.
System modules
Rule Engine. It is a kea module of the system, a connecting link allowing integration of all modules in a single entity, definition of work system logic without programming. Module work logic is completely defined by means of accepted XML and XSL standards and is based on the rules. The module is supported by two types of rules: plain rules and timer-rules. Plain rules define processing rules of input messages and contain application terms and set of operations. The rule applies in case it satisfies the term and carries out an action. Timer-rules allow sending messages by the set schedule (a simple example: database queries with a certain interval).
HTTP-Broker. The primary task is to process HTTP(S) queries. HTTP Broker is a WEB application. The module receives incoming HTTP(S) query, converts it into XML message and puts the message into output queue. Reply status-messages are transferred to HTTP(S) client as an answer to initial query.
SMPP-server. The primary task is ESME connecting with a possibility to send/receive SMS by SMPP protocol over TCP/IP.
SMTP-server. The primary task is to process incoming e-mails. SMTP-server receives an incoming email, converts the message into XML format and sends it to the System.
Manager. An integrated system module aimed to manage the system.
HTTP-module. The primary task is data query to HTTP-servers, receiving data from web- sites (open/protected), integration with external systems.
SQL-module. The primary task is SQL-data query to DBMS. It uses JCBC mechanism supported by most DBMSs. Connection options, access and etc are defined by module settings. SQL queries are formed dynamically by Rule Engine module.
Command Line module. The primary task is external program run and its execution result return to the System.
File Interface module. The primary task is message sending/receiving to the System by using xml-files. Message send to the system is realized by copying xml-file with the message into input module directory located in the file system.
SMTP-module. The primary task is to send e-mails. SMTP- module receives XML message from the System, converts it into an email message, sends it to SMTP -server and returns a status-message to the System.
POP3-module. The primary task is to get access to POP3 accounts in order to receive and delete emails. POP3-module converts received e-mail messages into XML format and sends it to the System.
Router. The primary task is to perform adaptive and dynamic routing of incoming messages among accessible transmitting channels (instances of communicative modules).
SMPP-module. The primary task is sending and receiving SMS-messages using direct SMSC connection by SMPP protocol.
UCP/EMI-module. The primary task is sending and receiving SMS-messages using direct SMSC connection by UCP/EMI protocol.
MM7-module. The primary task is sending and receiving SMS-messages using direct SMSC connection by MM7 protocol.
CIMD-module. The primary task is sending and receiving SMS-messages using direct SMSC connection by CIMD protocol.
Modem SMS. The primary task is sending and receiving SMS-messages using GSM equipment (GSM modem and a mobile phone).
Architecture Benefits
- System flexibility:
- System operation logic depends on the module communication scheme and message processing rules
- Easy integration with any information system:
- Supports various integration methods such as JMS, DBMS (Database Management System), HTTP(S), command line, e-mail, XML files, etc.
- Scalability up to large distributed systems:
- Distributed structure (you can install system components on different machines)
- System components location transparency
- Cross-platform system (developed completely in Java)
- Load balancing
- Unlimited scalability
- Open system
- Open architecture based on XML and JMS standards (Java Message Service, supported by leading middleware vendors)
- Enables you to rapidly add custom components (agents)
- System components are completely independent and don't rely on each other's availability; adding new components doesn't impact the existing ones
- Flexible configuration of message processing rules
- Enables to develop message processing rules with Java
- Enables to connect external applications and operation system tools
- Dynamic system configuration
- Remote system management and administration