PB应用走向WEB的技术方案选择——Appeon for PowerBuilder WEB 发布和J2EE WEB应用重写方案的比较

PB应用走向WEB的技术方案选择

—Appeon for PowerBuilder WEB 发布和J2EE  WEB应用重写方案的比较

 

1         概述

大多数企业已经认识到，将现有基于Client/Server架构的PB应用转换为成熟的N-Tier WEB架构会给企业带来诸多的优势。其中最显著的一点是在延伸企业应用到WEB架构之后，将会有更多的人如员工、合作伙伴、客户以及其他相关人员，能通过使用该WEB应用来运行相关的业务流程。当他们在获得授权之后，可以通过互联网(Internet)随时随地访问WEB应用，让企业的运转更加方便、高效而有序。另一方面，WEB应用和C/S应用比较而言，会更具伸缩性、更安全、更加易于维护，同时能有效地降低企业的总体拥有成本。最为重要的是，应用转到WEB架构之后，能为企业带来可持续增长的利润和长期的竞争优势，保证企业在未来的日子里立于不败之地。

1.1      可行的解决方案

由于 J2EE平台的稳定性、安全性、平台无关性，以及许多基于J2EE平台的成功案例，使得很多企业更加关注J2EE平台。因此本文侧重于介绍基于J2EE平台的解决方案：

方案一、利用J2EE技术重写出一个全新的WEB应用。重写以后，将在J2EE开发环境中维护新的应用。

方案二、使用Appeon for PowerBuilder（以下简称APB）产品对原有PB应用程序在PowerBuilder（以下简称PB）开发环境中进行WEB发布 [注：APB不仅可以将应用发布到基于J2EE平台运行，也可以将应用发布到基于.NET运行]。

1.1.1      利用J2EE技术进行WEB应用重写

重写是指利用J2EE技术按照原有的业务规则开发出一套新的WEB应用程序。因此，整理出原有PB应用的业务规则和数据结构是所有重写活动的起点，同时也是重点。原有PB应用的业务规则和数据结构的整理质量对于项目是否成功将起到决定性的作用。然后再使用HTML、CSS、JavaScript、Jsp、Servlet、 EJB等技术去实现这些已经整理出来的业务规则和数据结构。同继续使用PB开发应用相比，J2EE开发技术难度高，花的时间多，各种不确定因素较多，风险大。

企业可以选择自己重写，也可以选择外包给另外的公司。不管是企业自己重写还是外包，由于PB技术和J2EE技术本身的差异，企业将要使用全新的应用开发和维护流程，这意味着发生巨大的变化，而这些变化会导致非常多的风险。重写会在一定程序上改进原有PB应用程序的不良设计和编码，但是也可能会带来许多新的隐患，新写的代码通常都是需要在运行一段时间并不停地修复Bug后才能稳定。

1.1.2      使用Appeon for PowerBuilder产品进行WEB发布

APB以企业原有的PB应用的源代码为基础，自动生成一个映射原有PB应用功能的基于多层架构的WEB新应用。APB生成的WEB应用将精确地复制PB应用的用户界面和业务逻辑。

由于 APB是基于PB源代码进行地WEB发布。因此，企业可以让PB开发人员在PowerBuilder开发环境内完成企业原有应用的修改或添加新的功能，再由APB来完成PB应用程序生成WEB应用程序的所有事情。在整个过程中，PB开发人员不需要编写任何HTML、JavaScript、CSS、Java代码 —— PB开发人员只需运用标准的PB编程技术即可。

利用APB，企业能继续使用PB开发新的功能，然后再将其转化为WEB应用。因此APB可以帮助企业使用现有的PB技术有效的对原有的PB应用进行功能的扩展。

1.2      如何选择解决方案？

企业选择解决方案的时候，首先应当考虑的是解决方案本身是否和企业自身的发展策略方向一致；其次是解决方案是否能够支撑起企业的业务运转，同时能应付将来的业务扩展；最后需要考虑的是解决方案本身的成本以及会给企业带来的风险。下面列示的是企业在进行解决方案选择的时候必须谨慎考虑的主要因素：

·        由于企业策略原因需要的是使用Java开发工具去开发WEB应用还是继续使用PowerBuilder进行应用开发？

·        原有PB应用功能是否满足企业目前的业务需要？

·        原有PB应用是否能够有效的进行功能扩展，以满足企业新的业务需求？

·        原有PB应用程序的现状是代码质量很好、维护成本很低还是与之相反？

·        原有PB应用程序转换为WEB应用程序之后对于最终用户的影响是正面的还是负面的？通常表现在最终用户对于新的WEB应用程序在用户界面和操作方式上的适应性，以及是否能够高效率的对应用进行操作。

·        在原有PB应用程序转换为WEB应用程序的过程中，企业能否承受较长的开发周期、较多的成本及较高的风险？。

企业能准确的回答上面的问题之后，便可以选出最合适企业的解决方案。如果企业不打算继续使用PowerBuilder做为企业的主流开发工具，那么使用新的J2EE进行重写是最佳方案。反之，企业可以考虑另一种更加务实的方案——使用APB对原有的PB应用进行发布。因为APB可以帮助企业在进行PB应用程序向WEB应用程序转换的过程中缩短开发时间、减少开发成本、降低开发风险。后面的章节将对于上述两个解决方案做出更加详尽的分析和说明。

2         APB WEB发布和J2EE重写的综合比较

2.1      成本和风险

使用APB对PB应用进行WEB发布，不仅可以实现对原有程序代码的重用，还可以继续利用企业现有PB开发人员的开发技能和对应用商业逻辑的理解。用APB进行WEB发布之后的WEB应用不仅具有和利用J2EE 技术重写的WEB应用相同的架构优势，而且还保留了PB应用原来的业务逻辑和用户界面，最终用户无需经过培训即可使用发布后的WEB应用。并且企业可以继续让现有的PB开发人员对新的WEB应用进行维护以及添加新的功能。APB的这些特点将让企业的成本和风险降到最低。

而使用J2EE进行重写这种方式，需要支出更多的成本。第一，需要引进新的J2EE开发团队，或引进部分J2EE开发人员带领原有部分PB开发人员组建新的团队；第二，必需购置新软件和硬件去支持基于J2EE平台的开发；第三，新的成员必须要花时间适应新的工作环境；第四，需要对PB开发人员培训如何使用J2EE技术进行WEB开发，并且需要培训那些新加入项目团队的J2EE开发人员熟悉应用的商务逻辑。第五，现有PB应用源代码无法重用，需要全部重写。并且原有PB开发人员需要经过很长的时间才能达到熟练运用J2EE技术开发的水平，况且J2EE平台开发生产力本身就比PB差很多。所以开发成本相对直接进行WEB发布要高很多。

另外，重写这种方式还面临更多的风险。第一，由于部分成员对J2EE新技术的应用缺乏必要的经验，由他们写出的代码可能会存在较多的隐患或者不够高效；第二，久经考验的PB应用逻辑必须重新编写，由于这个过程是由人工完成地，因此，有经验的人知道，会不可避免的出现一些错误；第四，新的代码需要花大量的时间去测试，并且上线后还会逐渐出现各种错误(Bug)，这会对最终用户的工作造成影响，严重时会对企业整个业务流程造成影响。第五，由于新开发的WEB应用在界面上和流程上同以前的应用会有很多的不同，有可能会大大影响最终用户的工作效率。

不管是企业自己重写，还是选择某个外包公司重写，在项目进行过程中会一直伴随着需求、技术、成本和进度等诸多的风险。而采用APB解决方案，可以在大幅度地降低成本的同时有效的规避风险。

2.2      功能

APB在拥有将PB应用直接发布成WEB应用的能力，同时让用户界面、用户交互方式和原有PB应用一模一样。APB支持绝大多数的PB用户界面元素以及和它们相关联的事件机制，其中就包括掩码编辑器、菜单、工具条、标签页，MDI窗口等复杂的用户界面元素。正因为这些复杂用户界面元素和与之绑定的事件驱动机制，大大地丰富了WEB应用的用户界面，提供了最佳的最终用户的使用体验。最终用户再也不需要面对传统WEB应用中烦人的一次又一次的页面刷新，一个页面到另一个页面的链接和跳转。

APB另一个最重要也是最吸引人的地方是，它完全支持了PowerBuilder引以为傲的数据库访问功能和灵活实用的报表功能，包括Datawindow，DataStore，Embedded SQL以及与之相关的丰富的数据的更新、查询、过滤、查找功能。

APB的这些功能，让发布后WEB应用拥有了和原PB应用一样丰富的用户界面，强大的数据处理能力以及生成复杂数据报表能力，极大地提高了生产效率和最终用户的使用体验。

而使用J2EE技术重写的WEB应用，由于普通网页技术的局限性，大多数的界面相对简陋、交互性很差。这将直接导致用户界面的不友好，使得最终用户的体验很差，进而降低最终用户的工作效率。另外，在J2EE中实现类似APB的超强的数据处理功能有一定的难度，除非企业投入大量的资金去研究和开发。

2.3      生产力

本文以一个实际的案例来评估APB WEB发布和J2EE重写的生产力。案例实现了很多PB应用中很常用的一组和数据库进行交互的功能：