We will write a server, that does nothing more but redirecting standardized XML-input from communication modules to it's (next) destination module. So all real work is done by the modules. The server only has to check the input and find the correct output path.
Email sent through email-program to the GCS-Server |
POP/IMAP -----------> |
e-mail-input-module | XML-msg -----------> |
GCS-server | XML-msg -----------> |
SMS-output-module | SMS -----------> |
cell phone (SMS) |
You will be able to specify multiple, alternate and storage routes for the messages.
So you can send the same message to different recipients, the same recipient on different media, to another recipient if the first one ist not reachable or the message will be stored for delivery as soon as the recipient(s) is/are reachable.
The system will also allow users to specify times when which modules will be used and to send the server informations to reconfigure the settings for the moment, some time, for a specified amount of messages or until the setting is changed again.
Well. We looked at different message kinds and found that nearly all of them use almost the same kind of information. This information is not specific for a single format, but for messages in common.
This information includes such things as sender, recipient and message body. All kind of messages include these 3 elements. The more complex task will be to include and/or convert the transport information, which can be very specific to the transport system. Also the namespace will be a problem. How do I adress a cell phone from an e-mail-client? But thats where the module concept will help us. Every single module will be a server/gateway for the individual message format.
The generic XML-message-format (example message) and its DTD