- VCL application
- FMX application
- Windows service
- Console application
- Apache server module
- Microsoft IIS ISAPI DLL
- Using a proxy webserver (Apache, nginx, lighttpd…)
- More to come (mORMot, Sparkle, …)
The demo shows how easy it is to share the same MARSEngine and MARSApplication setup through all the first five way of deploy listed above. Have a look at the Server.Ignition unit to see how a default (single) engine is created and configured while each project template has its own way to setup the environment (starting an http server or being a WebBroker application). There are some slight differences from one choice to the other, let’s see some details for each entry.
1) VCL application
It is a standard VCL (Windows) application using a custom http server (Indy). It may be handy while you are all busy in the development and you need to build/start/stop your application server often.
2) FMX application
Same as previous entry (VCL application) but this time it is a cross-platform (Windows, OSX, iOS, Android) FireMonkey application that holds the custom http server (Indy) alive. Choose your favorite platform 😉
This option and the previous one can be used in production but obviously you may want a better support in terms of availability of your application server outside a single user session and with respect to machine reboot when it happens.
See MARSTemplateServerFMXApplication project.
Services are the standard for deploying high-availability server software on the Windows platform and Delphi support them since a long time.
Once you have built your executable, simply install it using a shortcut (or command line) passing ‘/install’ argument (be sure to have proper rights to install a service) and it will be listed in the Windows Service console add-in. You will be able to start/stop the service from there and configure start mode (automatic/manual), user to run the service, and additional parameters (like the path to configuration file).
Uses WebBroker technology to run an http server.
May seems old fashioned but still has its value. Similarly to entry 1 and 2, it is handy during the development stages or while debugging your application server.
Uses WebBroker technology to run an http server.
See MARSTemplateServerConsoleApplication project.
Apache server module
Thanks to the WebBroker technology, you can compile your application server directly as an Apache module (for example to then map a virtualhost or a specific path to your module). The module will live into the Apache server process and this will make you available all the Apache server features with no effort. Think about security (SSL), load balancing, proxy features, url rewriting and so on (it is a long list!).
See MARSTemplateServerApacheModule project.
Microsoft IIS ISAPI DLL
Similarly to entry number 5 (Apache server module), you can decide to deploy your application server as an ISAPI DLL and load it into Microsoft IIS (Internet Information Server). The benefits again are about the features (and performances) of the webserver you plug your module in.
Using a proxy webserver (Apache, nginx, lighttpd…)
Entries 5 (Apache module) and 6 (ISAPI) are great but have some drawbacks. For example, if you have to deploy a new version of your application server and you deployed it as an Apache module, you will have to stop Apache server (meaning all virtualhosts offline for a while), replace the module with the new binary and restart Apache. Same applies to IIS (AFAIK).
This may not be a problem if the webserver is dedicated to your application server but this is not always the case. So another option is to have an instance of Apache/IIS/<other webserver> to act as a proxy toward your application server (deployed using entries from 1 to 4, or even 5 and 6 if this is not overkill).
You can have a look at Marco Cantù’s whitepaper about deployment of DataSnap applications as a reference about configuring Apache as a reverse proxy for DataSnap HTTP servers (different technology, same problem).
More to come (Android Service, mORMot, Sparkle, …)
One of the aim of the MARSTemplate demo is to show you how easy has been to plug the MARS-Curiosity library on top of different http layers (Indy + WebBroker, Apache, IIS).
There are some other options available (thanks to great projects/products like mORMot from Synopse and Sparkle from TMS Software) that may result in a performance boost for your MARS-Curiosity application servers.
I am going to try to use these well known and solid projects/products as other deploy opportunities for MARS-Curiosity technology. Just to name a benefit I could get from this, they both use http.sys based http servers which may mean a great boost in performance.
Finally, I’d like to add an example of a MARS-Curiosity server deployed as Android service.
5 platforms + ???
With these options you can deploy a MARS-Curiosity REST server to five platforms (Win32, Win64, OSX, Android and iOS). Of course not all entries applies to all platforms (for example Windows services and VCL applications are Win32 and Win64 only, obviously) but this is a nice range of options to deploy your REST server.
Also, when Linux will be added by Embarcadero to the supported platform list for Delphi, I will do my best to have it available ASAP!
Stay tuned! 🙂
PS: the Tetris lamp is a Christmas gift from my wife, thanks Marta! 😉