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 是这个解决方案的核心，是一套平台型软件产品。
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
上的工作量。
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 是这个解决方案的核心，是一套平台型软件产品。
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
上的工作量。
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 是这个解决方案的核心，是一套平台型软件产品。
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
上的工作量。
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 是这个解决方案的核心，是一套平台型软件产品。
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
上的工作量。
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 是这个解决方案的核心，是一套平台型软件产品。
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
上的工作量。
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 是这个解决方案的核心，是一套平台型软件产品。
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
上的工作量。
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 是这个解决方案的核心，是一套平台型软件产品。
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
上的工作量。
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 是这个解决方案的核心，是一套平台型软件产品。
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
上的工作量。
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 是这个解决方案的核心，是一套平台型软件产品。
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
上的工作量。
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 是这个解决方案的核心，是一套平台型软件产品。
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
上的工作量。
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 是这个解决方案的核心，是一套平台型软件产品。
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
上的工作量。
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 是这个解决方案的核心，是一套平台型软件产品。
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
上的工作量。
