Coming from a decade of licensed products on the Desktop, we are now planning a switch to a SaaS (Software as a Service) platform to let customers get more affordable conditions (pay-per-use).
Since our (10+ year) Desktop product is a mix of 700,000 lines of C and C++, we cannot afford to rewrite it with the ‘Web’ programming languages (C#, Java or PHP) supported by the mainstream Web servers (Apache, IIS, Nginx).
The HTTP overhead will stay minimal as only a few bytes are consumed by the HTTP request and headers, the rest of the traffic being encoded in binary form. And recoding our application’s OOP presentation layer for the Web is certainly less a problem than rewriting 700k lines of code in a different programming language.
Apache and Nginx support ‘modules’ but frankly the interface overhead is huge (speed penalty, learning curve). We have also explored C/C++ dedicated solutions like ACE, BOOST, POCO or TUXEDO but they do not perform as well as Nginx for static contents so they are not likely to do any better with dynamic contents.
Does anyone has faced this situation before, and how did you resolve it?
Any pointer is appreciated, even if you did not do it.
Disregarding the option of using HTTP as a delivery medium for a client program, there’s essentially 3 options for delivering interactive applications via a webserver:
1) as a webserver module
2) via CGI
3) via fastCGI
Option 2 is the probably the oldest – 1 and 3 are used to address its performance shortcomings. You’ve already discarded the option of using a module on the basis that “the interface overhead is huge” – however from a performance point of view this is massively faster than CGI, and comparable to fastCGI. If a module is too slow then give up now – you’re not going to find anything faster.
If the speed of the interface is a major determinant of the application performance then either you’ve got fantastic network and HTTP skills or you’re seriously lacking in this area – there can be no middle ground. But reading between the lines, it sounds like you’re coming at this with a lot of knowledge about C/C++ and very little knowledge of HTTP / webservers.
I don’t doubt you’ll find lots of people trying to sell you products to webify your legacy apps. Most (all?) of these will cause you as much grief as biting the bullet and implementing your code within a fastCGI server. And there are lots of frameworks / libraries available to do much of the heavy lifting for you.
OTOH it is also possible to implement a logic tier (e.g. using php, python, perl etc) which would bridge between the webserver and instances of the client program (if the latter can use stdio or a re-usable socket connection) but to avoid orphaned processes getting created left, right and center you’d need a programmer who really knows what they’re doing. Done right this is probably the least effort solution – but its also a very risky strategy.
update
On reflection, since you’ll likely have to implement HTML support (probably including templating) and session management then the right way to do this might be to port your app to a web-service with a thin access layer in a web-based language handling the rendering and the sesison management. NB just because I’ve used the term webservice it doesn’t have to use SOAP, xml, nor does it even have to use HTTP.
Check more discussion of this question.
