0

We have an old legacy web application. The architecture consists of:

  1. (classic) ASP pages serving client's browsers; VB script, thousands of them
  2. out-of-process DCOM server called by ASP (IIS); MFC, singleton, exe
  3. database; one or more schemas
  4. supplemental ASP.NET application calling the DCOM server

The roles of server are:

  • to handle user login, logout and licensing
  • to keep user session information
  • to generate UI
  • to secure/authorize user actions
  • to retrieve and store data in database

Because those many roles of the server, the calling interface between ASP (IIS) and DCOM server is rather wide and heavily used throughout those many pages.
The main problem lays in IIS calling DCOM server and becomes bigger with newer Windows servers. Starting with Windows server 2008 this combination is almost not maintainable at all. With UAC in place even singleton out-of-process DCOM server fails to work (different processes are started in different security contexts).

I'd like to keep the MFC/C++ code of the server and it running as a singleton (despite all the cons). Those many ASP pages are the most dynamic and always changing part of the application and I'd like to keep them unchanged. I might sacrifice the supplemental ASP.NET application.

What would be the best replacement of a singleton out-of-process DCOM interface of the server? I consider performance and future maintenance the most important.

(I can see an identical .Net interface as a COM replacement, but my main concern was keeping it one-process-singleton in my first iterations.)

Peter Ivan
  • 1,467
  • 2
  • 14
  • 27
  • Is it not possible to designate the correct identity to your server compoanent? With newer OSes, it's just different security accounts that are used to run IIS - oncce mathcing IIS security to component's security it should work as before, no? I will try to answer your direct question in an answer below – G. Stoynev Mar 24 '13 at 03:52
  • In Win2008+ it's based on both security accounts and on integrity level. That's why sometimes a second process is started. It depends on whether "DCOM SCM deems the existing DCOM server instance suitable for a particular client" or not: [see this discussion on Microsoft forum](http://social.msdn.microsoft.com/forums/en-US/windowscompatibility/thread/60c04b1d-eb28-485f-a9de-71e211a5097b/). And they discourage single-instance DCOM servers, which supports the relevance of my question. – Peter Ivan Mar 26 '13 at 07:28

1 Answers1

2

This question is a bit open-ended for SO... But I used the following technique quite a while ago, doing a Java-to-COM bridge. HTH...

I understand that the code works, since you are willing to keep most of it. You have a problem with scaling the singleton pattern.

So split your singleton in two parts.

First, run your singleton as a service (or in COM+). Add to that process a small shim (running on its own thread) that receives HTTP requests and converts them to in-process COM calls. Since you already are working out-of-process, marshalling accross thread should not be an issue. Have a look at Mongoose for the HTTP part. It is a single C file that will get you a proof of concept running in no time.

Second, write (from scratch) a ordinary, non-singleton, inprocess COM object that implements the same interface as the server. That stub will merely convert the COM calls it receives to calls to an HTTP post to the real singleton.

+Make sure that your shim does not listen on a public interface!

ixe013
  • 9,559
  • 3
  • 46
  • 77
  • Yes, the current state of application works well. But it's problem to support it on new OS-es. – Peter Ivan Mar 23 '13 at 21:06
  • 2
    I will echo ixe013's architecture, but suggest a Microsoft-based solution: "upgrading" the DCOM server to WCF hosted component, which gives you a choice on the communication protocol betyween the COM adapters and the server. – G. Stoynev Mar 24 '13 at 04:07