我们维护一个拥有超过一百万行COBOL代码的系统。有人建议如何迁移到GUI(可能是基于Windows的)而不会丢失我们用COBOL编写的所有业务逻辑吗?是的,一些业务逻辑隐藏在当前用户界面中。
答案 0 :(得分:2)
如果是我,我会调查这样的事情:
使用暴露功能的接口(如果它尚未以这种方式编写)将COBOL包装起来然后从.NET应用程序中调用它应该相当容易。
我们花了大约15年的时间才离开我们的大型机,因为我们没有这样做。
答案 1 :(得分:1)
撰写screen scraper可能是您最好的选择。在从基于服务器的应用程序到3层应用程序的过渡期间,一些主要的ERP系统已经做了多年。我曾经使用过的一些有趣的功能,例如常规使用字段的下拉列表,日期弹出窗口甚至是基于抓取输入的基于客户端的宏语言。
这些并不好,但对客户来说效果很好,并确保应用程序仍以可靠的方式运行。
有很多不同的方法可以将它们组合在一起,但是如果你考虑一下,你可以使用java或.net来创建一个基于桌面的应用程序,并且需要额外的努力才能实现基于Web的实现。
答案 2 :(得分: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业务引擎。
一旦你拥有了一套不错的网络服务,这些服务就可以用于任何新的开发,从长远来看,它可以摆脱COBOL。
答案 3 :(得分:0)
您可以使用ESB公开后端旧版服务,然后对GUI进行编码以通过ESB调用服务。
然后,您可以开始使用您选择的新平台上的实施替换旧服务 只要服务接口没有改变,GUI就不需要知道后端服务实现的切换 - ESB可能会隐藏微小的更改。
驻留在旧用户界面层中的业务逻辑需要通过提取业务逻辑并在新平台上将其作为新服务公开,以便通过ESB由新GUI使用来重构。
至于新GUI的平台选择,为什么不考虑基于Web的UI而不是本机Windows平台,那么至少只需要对Web服务器进行更新,而不是将更改推广到每个工作站。