迁移到 GUI，而不丢失用 COBOL 编写的业务逻辑
我们维护的系统拥有超过一百万行 COBOL 代码。 有人对如何迁移到 GUI（可能基于 Windows）而不丢失我们用 COBOL 编写的所有业务逻辑提出建议吗？ 是的，一些业务逻辑隐藏在当前的用户界面中。
We maintain a system that has over a million lines of COBOL code. Does someone have suggestions about how to migrate to a GUI (probably Windows based) without losing all the business logic we have written in COBOL? And yes, some of the business logic is buried inside the current user interface.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
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 的方法。
Microfocus provide a tool called Enterprise Server which allows COBOL to interact with web services.
If you have a COBOL program A and another COBOL program B and A calls B via the interface section, the tool allows you to expose B's interface section as a web service.
For program A, you then generate a client proxy and A can now call B via a web service.
Of course, because B now has a web service any other type of program (command line, Windows application, Java, ASP etc.) can now also call it.
Using this approach, you can "nibble away at the edges" to move the GUI to a modern, browser based approach using something like ASP while still utilising the COBOL business engine.
And once you have a decent set of web services, these can be used for any new development which provides a way of moving away from COBOL in the longer term.
如果是我，我会研究这样的内容：
NetCobol for Windows
使用公开功能的接口包装 COBOL 应该相当容易（如果尚未以这种方式编写），然后从 .NET 应用程序调用它。
我们花了大约 15 年的时间才摆脱我们的大型机，因为我们没有做这样的事情。
If it was me I would look into something like this:
NetCobol for Windows
It should be fairly easy to wrap your COBOL with an interface that exposes the functionality (if it isn't already written that way) and then call it from a .NET application.
It took us about 15 years to get off of our mainframe, because we didn't do something like this.
编写屏幕抓取工具可能是您最好的选择。 一些主要的 ERP 系统在从基于服务器的应用程序到三层应用程序的过渡过程中已经这样做了很多年。 我使用过的一款具有大量有趣的功能，例如常用字段的下拉列表、日期弹出窗口，甚至是基于抓取输入的基于客户端的宏语言。
这些虽然不是很好，但对客户来说效果很好，并确保应用程序仍然以可靠的方式运行。
有很多不同的方法可以将它们组合在一起，但是如果您花点心思，您可能可以使用 java 或 .net 创建一个基于桌面的应用程序，并通过一些额外的努力来制作一个基于 Web 的实现。
Writing a screen scraper is probably your best bet. Some of the major ERP systems have done this for years during a transition from server based apps to 3-tier applications. One i have worked with had loads of interesting features such as drop down lists for regularly used fields, date pop ups and even client based macro languages based on the scraping input.
These weren't great but worked well for the clients and made sure the applications still worked in a reliable fashion.
There is a lot of different ways to put this together, but if you put some thought into it you could probably use java or .net to create a desktop based application and with a little extra effort make a web based implementation.
您可以使用 ESB 公开后端遗留服务，然后将 GUI 编码为通过 ESB 调用服务。
然后，您可以开始用您选择的新平台上的实现替换旧服务。
只要服务的接口不改变，GUI 就不需要知道后端服务实现的切换——ESB 可能对 GUI 隐藏微小的变化。
驻留在遗留用户界面层中的业务逻辑需要通过提取业务逻辑并将其公开为新平台上的新服务来重构，以便通过 ESB 由新 GUI 使用。
至于新 GUI 的平台选择，为什么不考虑基于 Web 的 UI 而不是本机 Windows 平台，那么至少 UI 的更新只需要应用于 Web 服务器，而不必滚动 -对每个单独的工作站进行更改。
You could use an ESB to expose the back-end legacy services, and then code your GUI to invoke the services via the ESB.
Then you can begin replacing the legacy services with implementations on your new platform of choice.
The GUI need not be aware of the cut-over of back-end service implementation, as long as the interface to the service does not change - minor changes may hidden from the GUI by the ESB.
Business logic that resides in the legacy user interface layer will need to be refactored by extracting the business logic and exposing it as new services on the new platform to be consumed by the new GUI via the ESB.
As for the choice of platform for the new GUI, why not consider a web-based UI rather than a native windows platform, then at least updates to the UI will only need to be applied to the web-server rather than having to roll-out changes to each individual work-station.