The TeleMessage architecture has been designed from the ground up in UML and adheres to the 'Object Oriented' paradigm. Its components and services are mainly Java and these interact through strictly defined interfaces. In addition, all internal component and service interaction is achieved through dedicated objects. Our goals are two-fold:
A lasting, robust and dependable architecture that is fully scalable & redundant and can provide the same reliable level of service to a small local ISP as to a global telecommunications operator with millions of customers.
To always stay one step ahead of technological developments in the communications arena. The architecture delivers a "plug & play" platform, enabling click on functionality or devices and seamless integration in existing infrastructure and (large) solutions.
So how does it work?
Click on the image to enlarge
The TeleMessage architecture is built on three tiers:
Access and Input tier
The Access and Input tier provides 'log on' entrance into the system. Integration with third party systems - be it partial or complete - is done through interfaces defined in this tier (POP3, IMAP4, SMTP, SMPP, SMS, MMS or XML / HTTP-Post for application level integration). All servers are fully monitored and load balanced.
Management and Storage tier
The Management and Storage tier is the heart and brains of the system. It includes the database (Oracle) & storage vault (EMC2 for example) where all messages going through the system are locked away, message queue management and deployment, 24x7 monitoring services (Supported SNMP traps), maintenance & administration functions and finally, the billing engine. The whole tier is carefully shielded and well protected (Checkpoint Firewall VPN shield , for example).
Delivery tier
The Delivery tier ensures that all messages leaving the system are passed by the Message Management Server(s) to the applicable Dispatcher(s) for fail safe delivery. Each Dispatcher is responsible for transforming the generic multimedia message to the specific format of the recipient device, delivering the message, handling local resend and retry logic, and reporting the exact status of delivery back to the database for the user to view.
Messages to be sent are placed in the databases' message queue, which are continuously polled by the Message Management servers. Next, the Message Management servers ask the Service Broker for the best available dispatcher. The broker is designed to find the "best": taking into account server type, CPU power, availability, least cost routing, load balance and bandwidth statistics. The message is then handed to the Dispatcher and the Message Management server is free to pull the next message from the queue. The Dispatcher is responsible for the translation of the generic message into the format required by the specific delivery device, and for the successful delivery of the message.
Technology Highlights
Open, multi-layered, fully distributable architecture.
Full adherence to open standards to enable building onto any platform.
The product has been written in Java with some specific components using C++.
IP-Based Remote Method Invocation (CORBA hierarchy) for location independence enables physical global server roll-out (local telephony hosting sites for least cost routing, or local data centers).
Rapid implementation for a solid partnership
We can manage it for you: VPN connections between all global and local telephony and / or data centers for secure remote management.
Standard interfaces for fast partial or complete customer set-up and integration.
Billing integration with customers or Billing services through own Billing Engine(s).
Modular set-up: you decide what you do and do not want.
If you'd like to know more about our messaging, billing, throughput, redundancy or other technical aspects: contact sales@telemessage.com