I'm considering using XData for adding a remoting layer to an existing application but I need it to work as a IIS component (ISAPI or CGI) so it can be integrated with the rest of the system.
How can I go about it ?
Hello Stephane, since XData and Sparkle uses http.sys under the hood, we never felt the need to provide an ISAPI interface for IIS. Is there any specific need you have with ISAPI that could not be accomplished with TMS Sparkle http.sys approach?
Thanks for answering.
Yes, there are many general reasons for this:
- Easy integration with IIS-based authentication systems
- Request tracing
- IIS URL rewrite (and, basically, all IIS ISAPI filters).
- Easy configuration (and, above all, visibility for system administrators about how their server is setup)
- Installer integration
- Much easier configuration of multiple applications
- Can be deployed as an Azure Web App (instead of a VM) which lowers the costs by several orders of magnitude.
- Support for SNI (I'm not sure http.sys doesn't somehow supports this)
In my case, I need SNI, URL rewrites and IIS authentication integration.
I see. Http.sys does support SNI. I'm not expert in other features of IIS to be honest, but isn't it possible to integrate both (like forwarding requests from IIS to http.sys module)?
But well, I understand your request, but unfortunately we don't provide an ISAPI module for TMS Sparkle. What does exist right now is a WebBroker adapter so that you can build a WebBroker module (for Apache) and forward the requests to a Sparkle module. Adapting it to an ISAPI module should be relatively easy, but we never had such request before. That would allow you to build an ISAPI module using WebBroker and forward the requests to the Sparkle module in-process. More info about this WebBroker + Apache integration here: http://www.tmssoftware.biz/business/sparkle/doc/web/apache-based-server.html
Thank you for your answer.
I'm afraid that forwarding IIS calls to http.sys would not solve any of the issue I mentioned: the caller's identity would be lost to the application (which would still run under its own identity) and it would make the configuration more complex and brittle.
Using the web broker framework, however, will work perfectly: that is indeed an ideal solution. I didn't realize that Apache support was implemented this way: silly me :)
Thank you again,