The middle and front tiers have to be downloaded and built in order to use the CMW. The files needed to build these tiers on Linux, Mac OS X and Windows are here -- direct.tar.bz2 -- md5 checksum: ad30409175fd75c9bdc1ed488ca740b2.
An account is needed to use the CMW. This form helps set up accounts. After setting up an account, update your cmwAmbassador.cfg file accordingly. Accounts help improve the performance of requests by minimizing the number of files that have to be sent to the CMW.
Links to some of the files in the archive:
Readme
cmwAmbassador.cc middle tier.
cmwAmbassador.cfg input file read by the CMW Ambassador.
cmwAmbassador.hh
direct.cc front tier.
cmw.req input file relayed to the ambassador.
lil_string.hh throws an exception if an operation would result in a string of length > 255
remote.mdl middle file that cmw.req refers to.
remote_messages_middle.cg.hh
computer-generated output based on cmw.req and remote.mdl.
File.hh
Formatting.hh
MarshallingFunctions.hh
ReceiveBuffer.hh
ReceiveBufferUDP.hh
ReceiveBufferTCPCompressed.hh
SendBuffer.hh
SendBufferCompressed.hh
Linux specific files:
Makefile
Windows specific files:
makefile.mcr
Why use a 3-tier architecture?
Originally we used a 2-tier system. We switched to a 3-tier architecture for performance, network administrative and security reasons. In the 2-tier architecture, the front tier had to establish a long distance connection to the back tier each time it ran. In the 3-tier architecture, the middle tier keeps a long distance connection and uses it for all requests coming from front tier instances. The front tier still has to make a connection but it makes it with the relatively local ambassador (middle tier).
In the 2-tier architecture, every front tier user had to be given permission to get through your firewall in order to communicate with the remote back tier. With the 3-tier architecture, all requests are mediated by the ambassador so only the machine the ambassador is running on needs attention from a network administrator.