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应用中很常用的一组和数据库进行交互的功能：
· 查询数据；
· 精确查找数据；
· 查询相应的明细数据；
使用APB进行WEB发布后的用户界面如图 1 所示，使用J2EE进行重写后的WEB应用用户界面如图 2 所示。
<shapetype id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f"><stroke joinstyle="miter"></stroke><formulas><f eqn="if lineDrawn pixelLineWidth 0"></f><f eqn="sum @0 1 0"></f><f eqn="sum 0 0 @1"></f><f eqn="prod @2 1 2"></f><f eqn="prod @3 21600 pixelWidth"></f><f eqn="prod @3 21600 pixelHeight"></f><f eqn="sum @0 0 1"></f><f eqn="prod @6 1 2"></f><f eqn="prod @7 21600 pixelWidth"></f><f eqn="sum @8 21600 0"></f><f eqn="prod @7 21600 pixelHeight"></f><f eqn="sum @10 21600 0"></f></formulas><path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"></path><lock v:ext="edit" aspectratio="t"></lock></shapetype><shape id="_x0000_i1031" style="WIDTH: 431.25pt; HEIGHT: 313.5pt" type="#_x0000_t75" wrapcoords="-38 0 -38 21548 21600 21548 21600 0 -38 0"><imagedata src="file:///C:%5CDOCUME~1%5CMSC%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image001.png" o:title=""></imagedata></shape>
图1 使用APB 进行WEB发布后的应用界面截图
<shape id="_x0000_i1030" style="WIDTH: 431.25pt; HEIGHT: 5in" type="#_x0000_t75" wrapcoords="-38 0 -38 21555 21600 21555 21600 0 -38 0"><imagedata src="file:///C:%5CDOCUME~1%5CMSC%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image003.png" o:title=""></imagedata></shape>
图2 J2EE重写出的WEB应用界面截图
开发过程分两部分：案例准备和案例开发。案例准备包括准备好案例需要使用的数据库，和撰写设计说明书。案例开发阶段，由一名精通PowerBuilder技术和另一名精通J2EE技术的开发人员分头用PowerBuilder和Java开发工具进行编码、调试、发布和部署WEB应用。
下表统计了整个过程的工作量：
| 方案 |
WEB Deployment （PowerBuilder + APB） |
J2EE Rewrite （Eclipse） |
| 案例准备（小时） |
4 |
|
| 案例开发 (小时) |
4 |
24 |
| 代码规模 (行) |
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所示)。
<shape id="_x0000_i1025" style="WIDTH: 426.75pt; HEIGHT: 204pt" type="#_x0000_t75" wrapcoords="-41 0 -41 21513 21600 21513 21600 0 -41 0"><imagedata src="file:///C:%5CDOCUME~1%5CMSC%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image005.jpg" o:title="杂志图片1"></imagedata></shape>
图 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内存。
<shape id="_x0000_i1026" style="WIDTH: 324pt; HEIGHT: 182.25pt" type="#_x0000_t75" wrapcoords="-38 0 -38 21533 21600 21533 21600 0 -38 0"><imagedata src="file:///C:%5CDOCUME~1%5CMSC%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image007.jpg" o:title="structure 02 no webserver"></imagedata></shape>
图 4 性能和伸缩性测试网络架构图
2.6.1 响应时间
从图 5中可以看出，JSP和APB的差距并不明显，二者非常接近。而且保持相同的趋势。可见，JSP和APB应用的性能非常接近。
<shape id="_x0000_i1027" style="WIDTH: 426.75pt; HEIGHT: 237.75pt" type="#_x0000_t75" wrapcoords="132 393 132 21129 21380 21129 21380 393 132 393"><imagedata src="file:///C:%5CDOCUME~1%5CMSC%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image009.emz" o:title=""></imagedata></shape>
图 5 APB和J2EE WEB应用的响应时间对比
2.6.2 CPU占用
从图 6中可以看出，J2EE WEB应用 的CPU占用率要略低于APB，但非常接近。
<shape id="_x0000_i1028" style="WIDTH: 426.75pt; HEIGHT: 238.5pt" type="#_x0000_t75" wrapcoords="132 393 132 21129 21380 21129 21380 393 132 393"><imagedata src="file:///C:%5CDOCUME~1%5CMSC%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image011.emz" o:title=""></imagedata></shape>
图 6 APB和J2EE WEB应用的CPU占用率对比
2.6.3 内存使用
从图7中可以看出，用APB发布后的WEB应用的内存使用量要比J2EE WEB应用多了少许，差距为5 – 20 Mb之间，这种差距在实际应用中几乎可以忽略不计。从图上看，两种应用的内存使用量都很平稳，这与为应用服务器预先分配了1280M内存有一定的关系。
<shape id="_x0000_i1029" style="WIDTH: 426.75pt; HEIGHT: 237.75pt" type="#_x0000_t75" wrapcoords="132 393 132 21129 21380 21129 21380 393 132 393"><imagedata src="file:///C:%5CDOCUME~1%5CMSC%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image013.emz" o:title=""></imagedata></shape>
图 7 APB和J2EE WEB应用的内存使用量对比
2.6.4 小结
从上面的数据可以看出，在WegSphere应用服务器上，用APB发布后的WEB应用和与用J2EE技术重写后的WEB应用相比，在响应时间、CPU占用以及内存占用三个方面都非常接近。因此，可以看出在同等条件下，两种方案产生的WEB应用在性能上并不存在差距。同时，由于APB采用的是Rich Client技术，可以充分利用客户端的计算能力。因而当应用的UI和逻辑非常复杂时，APB发布后的WEB应用会拥有更好的性能和伸缩性。
2.7 安全性
从安全性角度看，两种解决方案都有十分完善的措施保障应用的安全性，都支持SSL/HTTPS、LDAP验证、应用会话超时管理、WEB业务逻辑加密、数字签名等安全措施。除此之外，APB还内置了专门的用户组群去管理应用的发布和运行。
2.8 综合比较
上面已经从各个方面对两种方案进行了比较。下表是一个总结：
| 比较项 |
APB WEB Deployment Solution |
J2EE WEB Application Rewrite |
| PB应用的用户界面改动 |
几乎没有 |
大量 |
| PB应用的功能丰富程度和客户端的集成性 |
<p cla
分享到：
发表评论
wsql
最新评论
|
评论