使过时的MFC银行业务应用程序敏捷，以便可以将其迁移到云中 [英] Making a stale MFC banking application nimble so that it can be migrated to cloud

问题描述

我们有一个庞大的银行应用程序，具有不同的可执行文件(核心执行程序相同，但每个客户端都有一些特定要求，因此需要进行一些更改)和每个客户端的硬件，因为客户端在增加，所需的硬件成本已增加到大约75％.总费用.

问题在于此应用程序是使用VC ++，C ++和Oracle 9i(带有大约4-5百万行代码)构建的.

我们如何将其迁移到nible应用程序，以便最终可以将其迁移到云.

我当时正在考虑使用Java，Java存储过程，Oracle和当然是瘦客户机将应用程序迁移到Web服务器，但这看起来并不十分有前景.

请指教

note-主要重点在于降低硬件成本并提高应用程序的效率和可伸缩性

Hi,

We have a huge banking application which has different executables(core executbales are the same but every client has some specific requirements so some changes) and hardware for each client, as the clients are increasing the required hardware cost has increased to around 75% of the total cost.

The problem is this application is built using VC++,C++ and Oracle 9i( with around 4-5 million lines of code )

How do we migrate it to a a nible application so that it can be migrated to cloud eventually.

I was thinking of migrating the application to a webserver using java, java stored procedures, oracle and ofcourse a thin client, but again this doesnt look very promising

Please advice

note - main focus is on decreasing the hardware cost and making the application more efficient and scalable

推荐答案

我同意您的项目规模庞大，应与专业开发人员签约坚决解决这样的问题.对于以前从未做过这样的事情的团队来说，这是一个很大的方法.

话虽这么说，我们是一家软件开发公司，并且我们正在(多年)做类似的事情.我们的一般方法是维护胖客户端(甚至对其进行改进)，以满足客户的需求，同时努力构建Web服务层和可互换的前端.就我们而言，我们正在处理构建Web服务和一个或多个前端实现的功能块.这些可以是ASP.NET(Web表单和MVC)或iOS或Silverlight或其他任何形式.结果是旧的胖客户端进行的直接调用在Web服务中被复制了……本质上公开了相同的功能.当新的东西准备好时，我们正在迁移部分思想客户.

结果是，当我们迁移到新的前端时，我们现在有一个混合的胖客户端和几个"webby"前端.最终将是所有Web服务和现代前端.提供的Web服务无处不在，随着UI技术的发展，我们应该会很好.

顺便说一句，该路径使我们能够将所有现有逻辑保留在Oracle 10后端中.在我们的例子中，Web服务是在连接到Oracle 10 Enterprise的WebLogic上运行的Java.我们正在处理医疗保健记录，因此从数据保护和管理的角度来看，这几乎和银行一样糟糕.

I agree that your project is massive and you should contract with a professional development firm to tackle something like this. It is way to big for a group that has never done something like this before.

That being said, we are a software development firm and we are in the (multi-year) process of doing something similar. Our general approach has been to maintain the thick-client (even improving it) to address customer demands while at the same time working to build out a web service layer and interchangeable front ends. In our case, we are tackling chunks of functionality building the web services and one or more of the front-end implementations. These could be ASP.NET (web form and MVC) or iOS or Silverlight or whatever. The result is that the direct calls the old thick-clients make are being duplicated in the web services... essentially exposing the same functionality. We are migrating parts of the think client when the new stuff is ready.

The result is that we have a hybrid thick client and several "webby" front ends right now while we migrate over to the new fronts. Eventually it will be all web service and modern front ends. Provided web services don''t go anywhere, we should be good as the UI technologies develop.

This path, by the way, allows us to keep all of our existing logic in the Oracle 10 backend. The web services, in our case, are Java running on WebLogic connecting to Oracle 10 Enterprise. We are handling health care records so it is almost as bad as banking from a data protection & management standpoint.

这篇关于使过时的MFC银行业务应用程序敏捷，以便可以将其迁移到云中的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！