Appeon for PowerBuilder常见问题

Appeon for PowerBuilder常见问题

2005-12-19 初稿 2006-1-17 完善

主要内容

Q: APB是一个什么产品？

Q: 只有EXE和PBD，或者部分是PBD，可否用APB转换？

Q: PB转换后的程序是Java代码或JSP吗？

Q: 用APB转换后的Web应用和JSP开发的Web应用，技术上有什么区别？

Q: 转换后的代码是否可以直接编辑？

Q: 转换后的代码，能否在JSP或Java中调用？

Q: 前后台数据是XML传递的吗，可否在其它JSP程序中使用这些XML数据？

Q: PB程序中用到的DLL和OCX怎么办？

Q: 现有控件是用Javascript实现的吗？

Q: 为什么要采用IE插件的技术？不要插件行吗？

Q: ActiveX插件有多大，会不会每次都下载？

Q: 转换后应用的性能如何？例如运行速度？我担心速度会慢。

Q: 转换后的东西是个黑盒子，我怎么才能相信或保证转换后的程序或功能的绝对正常？是否可以对转换后的应用进行调试？

Q: 安全性问题，会不会有程序截取或假冒是Appeon客户端，访问AppeonServer提供的数据和信息？

Q: APB开发的Web应用，如何与基于纯Java的Web应用集成？

Q: Appeon的解决方案能带给客户什么价值？我现在的PB程序都可以通过远程自动更新解决维护的问题。

Q: 为什么需要架构调整和性能优化？

Q: 使用APB迁移PB应用的工作量到底有多大？

Q: APB是一个什么产品？

A: APB是Appeon for PowerBuilder的缩写。
Appeon公司专注于实现C/S架构的PowerBuilder应用迁移到B/S架构的完整解决方案。
Appeon for PowerBuilder是这个解决方案的核心，是一套平台型软件产品。

Q: 只有EXE和PBD，或者部分是PBD，可否用APB转换？

A: APB需要分析和翻译PB源程序。如果部分或全部是可执行文件，是无法转换的。

Q: PB转换后的程序是Java代码或JSP吗？

A: 转换后的文件格式包括：HTML、XML、JavaScript、Image文件。不是Java代码，也不是JSP。

Q: 用APB转换后的Web应用和JSP开发的Web应用，技术上有什么区别？

A: APB在客户端使用的是ActiveX技术，服务器端使用的是J2EE技术，包括Servlet、EJB、JDBC。APB综合使用了ActiveX技术和J2EE技术。

JSP则主要是服务器端的技术，给客户端传来的是HTML标记的文档，用于表现用户界面。对于一些要求复杂用户交互的应用，用JSP实现起来很困难。

Q: 转换后的代码是否可以直接编辑？

A: 转换的代码和文件我们不建议直接编辑，重新翻译和发布时会自动覆盖。事实上，维护Powerbuilder代码，要比直接修改翻译后的JS代码容易而且高效。

Q: 转换后的代码，能否在JSP或Java中调用？

A: 转换的代码和文件目前无法在JSP或Java中直接调用。转换后代码的主要形式是JavaScript，是在客户端的IE浏览器内运行的，而JSP是本质上是服务端运行的Java程序。因此目前二者无法直接调用。

Q: 前后台数据是XML传递的吗，可否在其它JSP程序中使用这些XML数据？

A: 前后台之间数据传递是二进制格式。前后台的调用和数据传输都是基于http的RPC。调用格式和传输的数据都是二进制的。这样做主要是出于安全和性能的考虑。

APB早期的技术里，曾采用过XML来传输数据，但由于XML的解析和装配需要一定的时间，会影响运行的速度。

Q: PB程序中用到的DLL和OCX怎么办？

A: PB中DLL和OCX在发布应用程序时自动发布到Web Server，运行时会被浏览器自动下载到客户端机器上，并进行注册。这一切对用户而言都是透明的，用户感觉不到这些工作。

Q: 现有控件是用Javascript实现的吗？

A: PB中的控件，如DataWindow、Treeview、Tab等都是用ATL技术实现的，Javascript难以实现这么复杂的控件。还有如Blob的类型，JavaScript也难以实现。

Q: 为什么要采用IE插件的技术？不要插件行吗？

A: 使用ActiveX插件是为了最大程度上，支持PowerBuilder的各种控件、对象和功能特性。例如Datawindow控件、TreeView控件、Dragdrop等。这些功能在一般的Web应用中很难实现。

APB在迁移Web应用时，具有两种发布方式，一种是AX方式，也就是插件的方式，可以支持PB中各种复杂的控件和对象。另一种方式是JS方式，也就是纯JavaScript方式，这种方式只能支持有限的PowerBuilder特性。

Q: ActiveX插件有多大，会不会每次都下载？

A: Appeon的插件有点类似于我们常见的IE 的Flash插件。大约1M左右的Cab包。IE会自动下载，并且只是在头一次使用的时候去下载。多个Appeon Web应用会使用一个插件，不会去下载多个插件，除非其版本不一样。

Q:转换后应用的性能如何？例如运行速度？我担心速度会慢。

A: 转换后的应用，在没有网络带宽限制的情况下，例如局域网或单机环境下，运行速度和PB差不多。对于局域网来说，带宽100M现在是很普遍的。

在带宽有限制的环境里，比如ADSL接入的情况下，Appeon Web应用也有自己的优势。我们知道，在纯J2EE应用中，服务器需要不断把刷新的页面发给前台的浏览器，数据校验的工作有时也需要发给服务器做。在低带宽网络中，前后台之间这种不停的界面和状态的传输，实际上效率是很低的。

在Appeon Web应用中，对于用户交互、数据展现和数据校验这样的工作完全是浏览器端完成的。只有像数据检索、数据更新这样的操作才会和服务器打交道。从原理上讲，Appeon Web应用在架构上更为合理，因为合理利用了服务器端和客户端的各自的处理能力。

对于同样界面复杂度的Web应用，Appeon Web应用的运行性能是要好于纯J2EE的Web应用的。

Q: 转换后的东西是个黑盒子，我怎么才能相信或保证转换后的程序或功能的绝对正常？是否可以对转换后的应用进行调试？

A: APB翻译PB源程序的过程，完全类似于PowerBuilder将源程序编译为可执行文件的过程。对APB当前版本支持的每个PB特性，翻译前后功能的正确性是由Appeon来保证的。

Powerbuilder提供的各种控件和对象都是用Appeon的IE插件实现的，用户在控件里写的Powerscript代码翻译为相应的JavaScript代码。这些代码调用Appeon插件里的控件和对象的功能。

目前，可以使用Visual InteDEV或者Visual Studio .NET 2003来调试翻译后运行在IE中的JavaScript脚本。

Appeon正在实现一个自己的调试器，这个功能会包含在下一个主版本中。

Q: 安全性问题，会不会有程序截取或假冒是Appeon客户端，访问AppeonServer提供的数据和信息？

A: 当然不会。Appeon Web应用是真正的Web应用，用户运行APB Web应用时，在服务器端会生成一个Session，客户端和服务器端传输的所有信息都是基于这个Session的，这是标准的Web安全技术。

Appeon客户端与Web服务器之间完全是基于Http的RPC调用，通过Http传递的信息都是二进制的。

此外，Appeon Web应用也完全支持HTTPS协议，使用HTTPS协议可以对整个Http会话进一步加密。

Q: APB开发的Web应用，如何与基于纯Java的Web应用集成？

A: 一般来说，语言级的集成，也就是“语言之间的调用”，是一种深层次的、高度耦合的，也是低效的集成方法，不适合于独立的应用系统之间的集成。应用系统集成的重点目前已发展到用户界面的集成、安全集成、数据的集成、业务流程的集成。

APB Web应用与纯Java Web应用的集成主要可以通过Portal技术实现用户界面的集成。通过第三方的安全产品（例如Site Minder），也可以实现企业多个应用的安全集成（Single Sign-On，单点登录）。

Q: Appeon的解决方案能带给客户什么价值？我现在的PB程序都可以通过远程自动更新解决维护的问题。

A: 将PB应用迁移到Web上，带给用户的价值不仅仅是绝不仅仅是客户端自动更新这一项。

首先，APB Web应用是真正的Web应用。可以运行在低带宽和网络不稳定的环境中。而PB应用无法运行在不稳定和低带宽网络环境中。

对客户端软硬件要求低，客户端不需要安装数据库客户端，只需要IE浏览器即可。

APB Web应用可以与企业现有的其它Web应用实现用户界面和安全的集成。PB应用与Web应用是完全不同的技术，在界面和安全上很难集成。

APB Web应用可以为用户在浏览器环境中提供丰富的界面组件和灵活的数据操纵性。可以提供热键和快捷键操作。可以轻易实现与Office软件集成，可以操纵本地目录和文件。

对于ISV而言，可以为用户提供界面非常复杂、具有很好操控性的Web应用。可以提高开发和维护应用的效率。如果是迁移老系统，甚至无需重新培训最终用户。

Q: 为什么需要架构调整和性能优化？

A: 我们用Powerbuilder开发的应用一般是两层应用，也就是C/S架构应用。绝大部分代码都是在客户端实现的，用户界面和业务逻辑基本上是交织在一起。

APB目前主要是实现语言的自动翻译工作，也就是PowerScript语言到JavaScript语言的翻译，还不能自动分离用户界面和业务逻辑相关的代码。因此，翻译后的应用如果要运行在Internet上，或者低带宽网络环境下，一般还需要进行一些手工调整，将数据存取密集代码和业务逻辑代码转移到数据库服务器或者应用服务器上。这就是所谓的对APB Web应用的架构调整和性能优化。

需要说明的一点是，如果翻译后的应用运行在带宽很好的网络环境中，例如带宽10/100M的企业网里，可以不做或只做少量的架构调整和性能优化工作。

Q: 使用APB迁移PB应用的工作量到底有多大？

A: 对于具有一定复杂度的真实PB应用系统，在APB自动翻译工作完成后，一般来讲，都还需要一定的手工调整工作。例如，APB当前版本不支持的PB特性，需要用通过修改代码的方式实现相同的功能。如果要运行在Internet上的话，还需要做一些性能测试和性能优化的工作。

另外，原来在C/S下的一些功能，在Web下可能不需要或者不适用，也需要调整。但是总的来说，迁移和调整的工作量要比使用J2EE或者.NET重新开发小很多。

随着APB对PB特性的支持，以及在可用性、可靠性和性能上的不断改善，会进一步降低PB应用迁移到Web上的工作量。