I need to write some DataSnap “middleware” between Google Glass and a SwissLog ERP system, and I am trying to figure out if there are significant differences between running the DataSnap as a standalone service (or app, for debugging) – and running as a CGI ISAPI plugin for IIS on a standard Windows Server.
Will the CGI be invoked per http session – or will there be a shared session running continously? I’ve never worked with CGI ISAPI before, so this is definitively a learning “opportunity”.
Pointers to relevant documentation would be appreciated.
Based on other CGI stuff I have seen, I would assume “one instance per http request”.
According to the docwiki, DataSnap does not support CGI: docwiki.embarcadero.com – Types of Web Server Applications – RAD Studio though there seems a guy who has made it work with FastCGI: https://groups.google.com/forum/#!topic/extpascal/WnvAzDS2mks
I’d go for ISAPI and IIS resource pools (as that way it is way easier to make it support HTTPS).
May I ask why CGI? If I remember correctly, CGI are console applications, communicating with the web server via console input/output. If you’re integrating with IIS DataSnap already has the option to expose the appserver in an ISAPI extension.
I’d really recommend against CGI. I think we even dropped support for it. FastCGI is a different options, that might make sense. IIS library (ISAPI DLL) is what you might aim for.
Marco Cantù Doh – I meant ISAPI, not CGI! Not sure why CGI was stuck in my brain, but it was prolly because it came up in a verbal discussion I had just before writing this post.
Will an ISAPI DLL have a single “main thread” across multiple client sessions?
Where would an ISAPI DLL typically store it’s configuration data?
From your DLL’s perspective there’s nothing like the main thread. Your exported function will be called by the IIS host, passing you the information about the request so you can process it and generate a response. When your method gets called, it’s just running on the current thread (and possibly simultaneously on other threads, too). If you can, try to avoid creating or managing your own threads.
Hmm. That may be a problem, since the ERP system has connection sessions, user lists, vehicle lists, etc – which could be rather costly to establish and retrieve per access. Perhaps a pure Delphi service / app is preferable after all.
You can keep a pool of instances so after processing one request the instance is not destroyed immediately and stands by ready to serve the next request. Something like this: andreanolanusse.com – Sharing DB connection between multiples DataSnap Server Modules | Andreano Lanusse | Technology and Software Development
I should mention that I’m a bit rusty with Datasnap so before implementing anything I would first research if there’s something already available, either in Datasnap itself or by a third party. Datasnap has evolved since I’ve last used it…
The benefit to ISAPI is stability (though IIS can crash hard too). In theory your connections would be pooled by a database driver like ADO or ODBC so the pool would be outside the ISAPI. It also means Microsoft is responsible for security and HTTPS. Apparently you can pool FireDAC connections in an ISAPI too. forums.embarcadero.com – Embarcadero Discussion Forums: Firedac with FDManager in an ISAPI hangs …
Or you can compiled a ISAPI (WebBroker?) into a stand alone app as well with TIdHTTPWebBrokerBridge. https://github.com/rburgstaler/StandAloneDelphiWebServer/blob/master/WebServerUnit.pas
So far, I’ve implemented the JsonRPC interface in such a way that I can embed it in any of the variants that DataSnap offers. The next layers that I need to write, is the session manager and API communication interface, which is a TCP connection to the ERP server. The initial goal is to do it all without a local database, and isolate the APIs behind a layer that will allow a port to our other ERP/WMS variants as well, hopefully without changes to the Glass UI.