|
|
|
One of the many large mosques in
Timbuktu.
|
|
|
Six hundred years
ago, Timbuktu was a mighty city at the crossroads of the main Saharan
trade routes for gold, ivory, salt and slaves. Great mosques, universities,
schools and libraries were built. The Sankoré Mosque and university alone
had 25,000 students.
|
Today Connection
Software's Timbuktu is an Information crossroads
collecting information from multiple sources and delivering it worldwide.
|
| Timbuktu is
uniquely placed to collect and distribute
information in industry specific formats including: |
- Messages to Mobile Phones and Pagers
- Stock exchange transactions
- Press Releases
- Disaster alerts - for a Company or a Country
- Any form of message based information
|
|
|
- Timbuktu accepts information from multiple sources in a range of
protocols, processes that information and then delivers it to appropriate
recipients, again in a range of protocols and using a wide range of
networks and links.
- Timbuktu is modular, redundant, fault
tolerant, distributed and highly scalable. The core system uses TCP/IP
Inter-Process Communication (IPC) and integrates with dial-up, leased-line,
X.25, ISDN and broadcast connections providing the widest possible choice
of receipt and delivery routes. You can select just those that you require
and add others later.
- Timbuktu routing is based on Rules
that you define. Your Rules can reference, and generate, a database
of historical information. If required, Timbuktu
can route information to mobile phones and pagers worldwide.
- Timbuktu understands a wide range
of industry-specific protocols. It's modular design allows new protocols
to be integrated as they emerge.
- Timbuktu can be scaled up and down
to meet your changing requirements. Timbuktu
can be installed at one location. Alternatively it can be run as a global
integrated network providing multiple, and possibly redundant, local
delivery points on different continents.
- Your customers can configure Timbuktu,
via a Website, to control the information that they receive and how
that information is delivered to them - within parameters that you can
specify. Timbuktu supports cost-per-message
charging.
- A TCP/IP based API is provided to enable you to input information
directly into Timbuktu thus making it
easy for you to evolve your current system. PC applications are also
available, in multiple languages, to input information into Timbuktu
– these are designed to be tailored and branded as required.
- Timbuktu can be configured and administered
locally or remotely with equal ease.
- Timbuktu provides extensive traffic
logs that can be used for billing and analysis.
- Timbuktu units are rack-mount "black
boxes" normally with 3 to 5 units per location to ensure redundancy.
|
|
|
You do not need to know
how Timbuktu works to use it. This
information is provided to help those evaluating Timbuktu,
or integrating Timbuktu with other
systems, and who wish to understand more about its technical design.
All components communicate using TCP/IP sockets and can thus be run
on the same unit or on one on another continent.
|
|
| The
Database and System Monitor perform specialised tasks and one of each
is required in all Timbuktu systems. |
| System Monitor |
The System Monitor monitors all the other
units. It generates alarms if a unit malfunctions and provides Interactive
Screens which display the performance of each unit, and component,
in real-time. |
| Database |
Often one unit hosts a dedicated Timbuktu
Oracle database, though any Oracle database can be used. All logs
are written to the database and may be accessed by user defined Rules.
A Windows User Interface provides access to the database. MySQL will
be supported in future. |
|
| The
other components combine to meet your specific needs. |
| Input Connections |
You may wish to use several Input Connection
Components, for example Dial-up, Leased Line, ISDN, TCP/IP, X.25 and
broadcast. |
| Input Protocols |
You may need several Input Protocol Components
to enable you to receive information from various sources. You might
provide UCP for Mobile phone input, TAP for pager messages, FOX for
financial exchange transactions, NewsML for News etc. |
|
| Lookup
and Validation, are written to reflect your business requirements
and give each system its' unique personality. |
| Lookup |
Database lookup - often to convert one
address to another, or to perform some calculation of the supplied
message / data. |
| Validation |
Validation checks the information against
Rules and data. Validation can accept, reject, delay or reroute information
- including sending to multiple recipients. Rules are hard coded but
may rely on changing data in the database. This gives great flexibility. |
|
| Once
the information has been processed, the Dispatcher sends it to the
required destinations. |
| Dispatch |
The Dispatcher queues information and
selects the best available route for delivery. Dispatch passes the
message to the required Output Protocol and Output Connection. |
| Output Protocols |
The message are "wrapped" in
an appropriate protocol. For example TNPP, CTC-2, SMTP (e-mail), fax,
FTP, WAP or HTTP Post |
| Output Connections |
Provide the connection to the outside
world selecting from TCP/IP, Leased Line, X.25, Dial-up, ISDN, file,
broadcast or Website |
|
| Five
of these component groups; the Input and Output Connections, Input
and Output Protocols and Dispatcher, change little. Once a Protocol
has been written, it can be used with any existing or future Connection. |
|
| Each
unit runs a Machine Supervisor that repeatedly confirms that the executables
running on that unit agree with those specified in the database. The
Machine Supervisor can start, stop or restart anything. Whenever it
does so, it reports its actions to the System Monitor. |
|
In
a 5-unit cluster, one unit would provide the Database service and
another the System Monitor. The other three units would probably all
run Input and Output Connection Components and Protocols as well as
a copy of the Lookup and Validation Components. Since Timbuktu knows
what Components are running on each unit and which unit is least busy,
it is able to choose which component to use from the available pool.
|
|
|
|
Whilst most of the Timbuktu
system is well established and available off-the-shelf, the system will
be configured to meet your specific business needs. The following checklist
provides an indication of the information required to define and implement
a new system.
It cannot be over emphasised that the system is designed to be configured
and reconfigured as required. It is expected that the system will develop
and grow, as your business needs change. Thus you should base your answers
to the following mainly on your short-term needs. This checklist will
assist planning discussions between yourselves and Connection Software. |
- Consider the required topography of the system. Do you need to deliver
information from a number of sites? This is normally required for one
of two reasons – Disaster Planning or where information needs to be
delivered locally from distant locations.
- List the Protocols that you require for both input and output connections.
E.g. TAP, UCP, NewsML, FOX, FTP, e-mail, fax, voice.
- List the "connections" that you wish to use. E.g. Dial-up,
leased-line, Internet – TCP/IP, broadcast.
- Considering the Input Protocols that you have suggested, list the
data elements that you might wish to base your Rules on. These will
be very specific to your industry and many of the following will not
apply. E.g. source address (IP, telephone number etc.), date and time,
message contents, day high or low of value, language etc.
- Specify the Rules that you wish to apply to incoming information.
Here are two examples of possible Rules:
"If the user is a subscriber to "Service C" then deliver
keywords and the first 100 words of message."
"If the data contains any of the words listed in a specific table
(the content of which may be changed by a user) then add
1 to the Message Count for that user. If the Message Count for that
user is less than 300 since midnight then deliver the
message to the user by their preferred means otherwise hold for 1 hour
and then deliver."
- Consider whether you need to "lookup" any incoming values
in tables – for example to automatically translate addresses, words,
phrases or abbreviations. Outline your requirements – it being probable
that the exact list of translations is likely to change on a day-to-day
basis.
- Outline your requirements for data analysis and archiving. For example
you may wish to let your users use a linked Website to search, browse
and retrieve certain data from your database.
- Consider carefully your requirement for system availability. Whilst
the system is itself highly resilient and fault tolerant it relies on
database access. Providing a High Availability database may or may not
be appropriate for your needs.
- Consider carefully whether Oracle is, or is not, the most appropriate
and cost-effective solution to meet your database needs. You may wish
to use an existing Oracle system as your database engine.
|
|
|
 |
| These descriptions are also
available for download in PDF format. |
|
