0

我们有一个旧的遗留 Web 应用程序。该架构包括：

  1. （经典）为客户浏览器提供服务的 ASP 页面；VB脚本，数以千计
  2. 由 ASP (IIS) 调用的进程外 DCOM 服务器；MFC、单例、exe
  3. 数据库; 一种或多种模式
  4. 调用 DCOM 服务器的补充 ASP.NET 应用程序

服务器的角色是：

  • 处理用户登录、注销和许可
  • 保留用户会话信息
  • 生成 UI
  • 保护/授权用户操作
  • 在数据库中检索和存储数据

由于服务器的角色众多，ASP（IIS）和DCOM服务器之间的调用接口相当广泛，并且在许多页面中被大量使用。
主要问题在于 IIS 调用 DCOM 服务器，并且随着更新的 Windows 服务器变得更大。从 Windows server 2008 开始，这种组合几乎完全不可维护。使用 UAC，即使是单例进程外 DCOM 服务器也无法工作（不同的进程在不同的安全上下文中启动）。

我想保留服务器的 MFC/C++ 代码并将其作为单例运行（尽管有所有缺点）。那些许多 ASP 页面是应用程序中最动态且始终在变化的部分，我希望它们保持不变。我可能会牺牲补充的 ASP.NET 应用程序。

服务器的单例进程外 DCOM 接口的最佳替代品是什么？我认为性能和未来的维护是最重要的。

（我可以看到一个相同的 .Net 接口作为 COM 替代品，但我主要关心的是在我的第一次迭代中保持它的单进程单例。）

4

1 回答 1

2

这个问题对于 SO 来说有点开放......但我很久以前使用了以下技术，做一个 Java-to-COM 桥。HTH...

我知道代码有效，因为您愿意保留大部分代码。您在缩放单例模式时遇到问题。

因此，将您的单身人士分成两部分。

首先，将您的单例作为服务（或在 COM+ 中）运行。向该进程添加一个小的 shim（在其自己的线程上运行），它接收 HTTP 请求并将它们转换为进程内 COM 调用。由于您已经在进程外工作，因此跨线程编组应该不是问题。看看Mongoose的 HTTP 部分。它是一个单一的 C 文件，可以让您立即运行概念证明。

其次，（从头开始）编写一个普通的、非单例的、进程内的 COM 对象，该对象实现与服务器相同的接口。该存根只会将它接收到的 COM 调用转换为对 HTTP 帖子的调用到真正的单例。

+确保您的 shim 不在公共接口上监听！

于 2013-03-23T01:57:02.190 回答