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 上的工作量。