我们维护的系统具有超过一百万行的COBOL代码。有人在不丢失我们用COBOL编写的所有业务逻辑的情况下，有关于如何迁移到GUI(可能基于Windows)的建议吗？是的，一些业务逻辑埋在当前用户界面中。

解决方案

回答

编写屏幕抓取工具可能是我们最好的选择。在从基于服务器的应用程序过渡到3层应用程序的过程中，一些主要的ERP系统已经这样做了很多年。我曾经处理过的其中一个有趣的功能，例如用于常用字段的下拉列表，日期弹出窗口，甚至是基于抓取输入的基于客户端的宏语言。

这些不是很好，但是对客户来说效果很好，并确保应用程序仍然可以可靠地运行。

有很多不同的方法可以将其组合在一起，但是如果我们对此有所考虑，则可以使用Java或者.net来创建基于桌面的应用程序，并花费一点额外的精力来进行基于Web的实现。

回答

如果是我，我会调查这样的事情：

适用于Windows的NetCobol

用公开功能的接口包装COBOL(如果尚未以这种方式编写)，然后从.NET应用程序中调用它应该是相当容易的。

我们花了大约15年的时间才能脱离大型机，因为我们没有做这样的事情。

回答

Microfocus提供了一个称为Enterprise Server的工具，该工具允许COBOL与Web服务进行交互。

如果我们有一个COBOL程序A和另一个COBOL程序B，并且A通过接口部分调用B，则该工具允许我们将B的接口部分公开为Web服务。

然后，对于程序A，我们将生成一个客户端代理，并且A现在可以通过Web服务调用B。

当然，由于B现在具有Web服务，因此任何其他类型的程序(命令行，Windows应用程序，Java，ASP等)现在也可以调用它。

使用这种方法，我们可以"蚕食边缘"，使用ASP之类的工具将GUI迁移到基于浏览器的现代方法，同时仍然利用COBOL业务引擎。

并且，一旦有了一套不错的Web服务，便可以将其用于任何新开发，从而从长远角度提供摆脱COBOL的方式。

回答

我们可以使用ESB公开后端旧版服务，然后对GUI进行编码以通过ESB调用服务。

然后，我们可以开始在所选的新平台上用实现替换旧服务。
GUI不必知道后端服务实现的切入点，只要服务的接口不变即可，ESB可能会将微小的更改隐藏在GUI中。

驻留在旧用户界面层中的业务逻辑将需要通过提取业务逻辑并将其作为新平台上的新服务公开，并由ESB通过新GUI进行使用来进行重构。

至于为新GUI选择平台的原因，为什么不考虑基于Web的UI而不是本机Windows平台，那么至少对UI的更新仅需要应用到Web服务器，而不必滚动-列出每个工作站的更改。