Transport channels
Messages which are enclosed in files, must be transported from one node or location in the replication schema to another. Basically, Frext has only one transport channel: by file. However, on each system where Frext will operate, we can make use of several scripting tools like Python or bash and achieve two other (extra) channels, mail and FTP, Frext handles only files natively. Each on one of them has advantages and disadvantages, so how to choose between them?
File
If you want a quick connect between databases for demo or educational purposes, file is your choice. By far this is the most easy to setup and easy to understand, just point to a common folder and you're done. But, it's not cross-platform by nature: if the server is running on Linux, messages are written on a Linux file system. It is unlikely that other operating systems (OS) like Microsoft Windows can read and understand these files directly. For this to work, a common denominator have to be chosen so that both OS's can read and write messages. In this case, the use of Samba (SMB implementation for Linux for reading MS Windows network shares) comes in handy. It's doable, but other aspects like file rights management have to be looked at. Both other channels, mail and FTP are cross-platform by design. But, in a environment where you have one server (Linux or Windows) and multiple databases which have to replicate to each other, cross-platform issues don't play, and the file channel is very handy and easy to use.
The biggest problem for the file channel, is that physical contact is needed; this makes is unsuitable for pure mobile solutions where you like to replicate when you're in the field, anytime, anywhere. But if you take a step down and only want to replicate when the mobile machine is back on the office, where replication actions can take place directly to the main server, file is an option. It is just that you're quite limited in possibilities of synchronizing your data, you have to plugged in in the office network. An alternative can be found is accessing files through the SSH-protocol (tunneling), this can also be done over the internet so it is relatively well suited for mobile solutions.
File messaging can be used as a base for a completely customized transport channel. Imagine two servers reading and writing messages to a local file folder. An other channel (not the ones built in into Frext) are transporting messages between the to local folders. These servers (the Frext engine to be precise) are unaware where these messages come from, but that is of no importance, so long the transported messages are valid. So what's this customized transport channel have to be: anything reaching from a simple usb-stick to a batch- or bash-file or a complete message queue system like Java JMS or Microsoft MSMQ or anything in between, as for as your imagination reaches.
What do you need for this thing to work: a working and reachable smtp- and pop3-server. It happens to be that (almost) everybody can meet these requirements though their internet provider! So, whenever the mail-servers are reachable, either by LAN or WLAN or through a Wifi-hotspot or through GPRS/3G, this system always works!
Are there any downsides of using mail in a mobile solution? Maybe the fact that even when you're connected on a local LAN, all replication communication have to go from the LAN to the Internet and back to the LAN. Does it bother you? I don't think so: there are just a small amount of messages which are sent to each other and they are not quite big. It looks overkill, but mail is so handy for pure mobile solutions that this shortcoming is easy to overcome with.
Mail is like ftp cross-platform by nature: the server may be running another OS as the remote machine.
FTP
For this to work, you have to have a FTP-server. In contrary to the smtp- and pop3-server, this one is not very common. You have to set it up yourself, which is of course not so difficult, but normally these servers are not reachable from the internet (except when you place it explicitly on the internet). An exception is when you can make use of a FTP service from a hosting provider or expose your local FTP-server to the internet..
But beware, the FTP-protocol is not as safe as you want it to be because password are sent unencrypted. It is possible to use SFTP but this complicates matters a bit. The FTP channel can be used in mobile solutions, but not as easy as a mail channel due to the visibility aspect of the FTP server through the internet which requires some setup or configuration.
There is a specific situation where FTP comes to value: multiple servers each running multiple databases, maybe each one running under a different OS. Because FTP is multi-platform by design, it doesn't matter that different servers are running under different OS's. Just built up a internal FTP-server and route all you're replication communication through that server.
Both mail and ftp channel can be
secured through a virtual private network (VPN) or tunnel , e.g. SSH.
This requires extra software and/or software is is not always easy to
setup. But, if a tunnel is already preset in a mobile situation, ftp
can be used without the formerly mentioned security hazards.
Recommendation sheet
- Demo & educational purposes: file
- Server-to-server: single server: file
- Server-to-server: multiple servers, single OS: file
- Server-to-server: multiple servers, multiple OS: ftp (file + Samba)
- Mobile solutions, anytime, anywhere: mail (ssh)
- Mobile solutions, limited to office network, single OS: file
- Mobile solutions, limited to office network, multiple OS: ftp (file + Samba/ssh)
Do
not take this an absolute value, feel free to experiment and mix and
match different channels to achieve your own implementation goals;
Frext does not limit you to only use one channel at a time...