我们维护一个拥有超过一百万行 COBOL 代码的系统。有人有关于如何迁移到 GUI（可能基于 Windows）而不丢失我们用 COBOL 编写的所有业务逻辑的建议吗？是的，一些业务逻辑隐藏在当前的用户界面中。
Thayne
问问题
1262 次
4 回答
2
如果是我，我会研究这样的事情：
使用公开功能的接口（如果尚未以这种方式编写）来包装您的 COBOL，然后从 .NET 应用程序调用它应该相当容易。
我们花了大约 15 年才摆脱大型机，因为我们没有做这样的事情。
于 2008-09-06T01:49:08.843 回答
1
编写屏幕刮板可能是您最好的选择。在从基于服务器的应用程序过渡到 3 层应用程序的过程中，一些主要的 ERP 系统多年来一直在这样做。我使用过的一个有很多有趣的功能，例如常用字段的下拉列表、日期弹出窗口，甚至基于抓取输入的基于客户端的宏语言。
这些不是很好，但对客户来说效果很好，并确保应用程序仍然以可靠的方式运行。
有很多不同的方法可以将它们组合在一起，但是如果您考虑一下，您可能可以使用 java 或 .net 创建基于桌面的应用程序，并通过一些额外的努力来实现基于 Web 的实现。
于 2008-09-06T01:15:19.223 回答
0
您可以使用ESB来公开后端遗留服务，然后编写 GUI 代码以通过 ESB 调用服务。
然后，您可以开始用您选择的新平台上的实现替换旧服务。
GUI 不需要知道后端服务实现的切换，只要服务的接口没有改变 - ESB 可能会从 GUI 中隐藏微小的变化。
驻留在遗留用户界面层中的业务逻辑将需要通过提取业务逻辑并将其公开为新平台上的新服务来重构，以供新 GUI 通过 ESB 使用。
至于新 GUI 的平台选择，为什么不考虑基于 web 的 UI 而不是原生 windows 平台，那么至少 UI 的更新只需要应用到 web-server 而不必滚动-对每个单独的工作站进行更改。
于 2010-03-11T14:01:19.630 回答
0
Microfocus提供了一个名为 Enterprise Server 的工具，它允许 COBOL 与 Web 服务进行交互。
如果您有一个 COBOL 程序 A 和另一个 COBOL 程序 B 并且 A 通过接口部分调用 B，则该工具允许您将 B 的接口部分公开为 Web 服务。
对于程序 A，然后生成客户端代理，A 现在可以通过 Web 服务调用 B。
当然，因为 B 现在有一个 Web 服务，任何其他类型的程序（命令行、Windows 应用程序、Java、ASP 等）现在也可以调用它。
使用这种方法，您可以“蚕食边缘”，将 GUI 移动到使用 ASP 之类的现代、基于浏览器的方法，同时仍然使用 COBOL 业务引擎。
一旦你拥有了一套不错的 Web 服务，它们就可以用于任何新的开发，从长远来看，它提供了一种远离 COBOL 的方式。
于 2008-10-28T20:46:41.930 回答