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 应用中很常用的一组和数据库进行交互的功能：

· 查询数据；

· 精确查找数据；

· 查询相应的明细数据；

使用 APB 进行 WEB 发布后的用户界面如图 1 所示，使用 J2EE 进行重写后的 WEB 应用用户界面如图 2 所示。

图 1 使用 APB 进行 WEB 发布后的应用界面截图

图 2 J2EE 重写出的 WEB 应用界面截图

开发过程分两部分：案例准备和案例开发。案例准备包括准备好案例需要使用的数据库，和撰写设计说明书。案例开发阶段，由一名精通 PowerBuilder 技术和另一名精通 J2EE 技术的开发人员分头用 PowerBuilder 和 Java 开发工具进行编码、调试、发布和部署 WEB 应用。

下表统计了整个过程的工作量：

方案

WEB Deployment

（ PowerBuilder + APB ）

J2EE Rewrite

（ Eclipse ）

案例准备（小时）

案例开发 ( 小时 )

代码规模 ( 行 )

182

总代码行： 1950

重用代码行： 1185

手工编写： 765

表 1 生产力统计数据

从表上可以看出，案例开发过程中， J2EE 重写花的时间是 APB 方案的 6 倍，手工编码量是 APB 方案 4.2 倍，总代码量是 APB 方案的 10.7 倍。需要指出的是，此案例中并不是对一个已经存在的 PB 应用进行 WEB 发布和重写。当对一个已存在的 PB 应用进行 WEB 发布时， APB 方案的应用开发和发布时间将会更少。而且此案例非常简单，如果对一个界面和业务逻辑都异常复杂的应用进行 WEB 发布， APB 方案的生产力将会更高。

2.4 应用维护

使用 APB 对 PB 应用进行 WEB 发布的方案，能让原开发团队继续保持原有的开发习惯和遵循已有的开发流程。而且可以通过维护同一套代码来支持不同的部署方式：按传统的 C/S 方式运行或发布为 WEB 应用程序以 B/S 方式运行。另外，众所周知， PB 提供了强大的所见即所得以及事件驱动的编程方式，能非常容易地维护应用。

使用 J2EE 技术对 PB 应用进行 WEB 重写，则需要利用 Java IDE 如 Eclipse 来维护应用。 Java 开发工具的可用性在过去几年里得到了提高，但同那些 4GL 开发工具如 PB 、 VB 、 Delphi 相比，还有较大差距。同时，新开发的 WEB 应用中会包含各种类型的代码，如 HTML ， JavaScript ， CSS ， JSP ， Java 等等。这将直接导致了如上一节所描述的问题——新的 WEB 应用的代码规模将变得很大。因此，使用 J2EE 技术重写的 Web 应用不仅维护的量很大，而且 Java IDE 并不能帮助企业开发人员高效的维护应用。同时，在代码规模很大的情况下，调试和定位错误将变得非常困难。

2.5 集成能力

利用 J2EE 技术进行重写后的 WEB 应用能在服务器端和其他的组件进行集成，包括对 EJB 、 WEB Service 和 CORBA 调用。

APB 方案不仅提供基于服务器端的集成，还提供基于客户端的集成。例如在发布后的 WEB 应用中，可以和客户端的 OLE/OCX 集成，并且支持对客户端 DLL 及 Windows API 的调用 ( 如图 3 所示 ) 。

图 3 Appeon for PowerBuilder 集成能力示意图

（注：图中的星号 (“*”) 表示 CORBA 和 PB 的 NVO 对象需要特定应用服务器的支持）

2.6 性能和伸缩性

将生产力比较那一节中提到的 APB 和 J2EE 案例部署到相同的软硬件环境中，然后进行相应的性能和伸缩性测试：

为基于 APB 发布的 WEB 应用和基于 J2EE 重写的 WEB 应用采用同样的性能优化措施：对从服务器端传到客户端的内容进行 ZIP 压缩，并对界面进行局部更新，同时都按照分页的方式读取数据。

应用服务器采用的是 WebSphere 。数据库服务器则采用的是 Oracle 。

网络带宽为 100M 。测试工具为 LoadRunner 。测试中的思考时间为 20 秒，每隔 1 秒钟增加一个虚拟在线用户。利用 LoadRunner 统计如图 4 所示的第 1-4 步的响应时间（未包括界面更新的时间），以及 Application Server 上应用服务器的 CPU 占用率和内存占用情况。考虑到 WEBSphere 在配置好预分配内存之后的性能会更好，所以事先给 WebSphere 预分配了 1280M 内存。

图 4 性能和伸缩性测试网络架构图

2.6.1 响应时间

从图 5 中可以看出， JSP 和 APB 的差距并不明显，二者非常接近。而且保持相同的趋势。可见， JSP 和 APB 应用的性能非常接近。

图 5 APB 和 J2EE WEB 应用的响应时间对比

2.6.2 CPU 占用

从图 6 中可以看出， J2EE WEB 应用的 CPU 占用率要略低于 APB ，但非常接近。

图 6 APB 和 J2EE WEB 应用的 CPU 占用率对比

2.6.3 内存使用

从图 7 中可以看出，用 APB 发布后的 WEB 应用的内存使用量要比 J2EE WEB 应用多了少许，差距为 5 – 20 Mb 之间，这种差距在实际应用中几乎可以忽略不计。从图上看，两种应用的内存使用量都很平稳，这与为应用服务器预先分配了 1280M 内存有一定的关系。

图 7 APB 和 J2EE WEB 应用的内存使用量对比

2.6.4 小结

从上面的数据可以看出，在 WegSphere 应用服务器上，用 APB 发布后的 WEB 应用和与用 J2EE 技术重写后的 WEB 应用相比，在响应时间、 CPU 占用以及内存占用三个方面都非常接近。因此，可以看出在同等条件下，两种方案产生的 WEB 应用在性能上并不存在差距。同时，由于 APB 采用的是 Rich Client 技术，可以充分利用客户端的计算能力。因而当应用的 UI 和逻辑非常复杂时， APB 发布后的 WEB 应用会拥有更好的性能和伸缩性。