Openlaszlo中代理模式（Proxied）和标准模式（solo）的差异

Openlsazlo中代理模式（Proxied）和标准模式（solo）的差异

WYQ

 

 

    在“在线教室”应用开发的过程中，我们碰到了这种情况：使用solo模式编译出来的SWF文件，在进入教室后，点击白板左侧的文件缩略图时，白板上的flash文件并没有跳到指定的页面，但是文档属性中的页号确实已经更新了；在换成了Proxied模式后，同一套代码未做任何修改的情况下，再点击白板左侧的页面，白板上的flash却可以正常换页。经过对比，两种模式下代码执行的步骤和输出的信息是一模一样的，但是结果却出现了不同，为此，我们查找相关资料，找出了原因所在，以下介绍该种现象出现的原因：

     

 

    首先，我们来介绍Openlazlo的两种编译方式：

 

    SOLO部署：简单灵活

  

    SOLO（standalone OpenLaszlo output 的简称）部署方式产生的文件可以部署在任何支持web服务的容器中。为了将 Laszlo 应用程序转换成一个 Flash 文件，可以调用编译器（例如 lzc file.lzx —— .lzx 是 Laszlo 文件的扩展名或者直接在URL中添加lzproxied=solo的参数）来产生一个输出文件（swf格式），就可以播放该文件。这样就非常简单了：将生成的文件放在 Web 服务器上，然后将它包括在一个 HTML 文档的主体中就可以了。OpenLaszlo 编译器会负责所有底层的工作（资源组合，代码生成，等等）。但是，SOLO 部署方式有一个限制，有些非常强大的特性（例如 Web 服务调用、RPC 和某些类型的媒体流）SOLO 部署方式不能提供支持。

 

 

     

（solo模式）

 

 

 

    Proxied 部署：支持所有特性。

 

    使用 proxied 部署方式，可以得到 OpenLaszlo 系统所能提供的所有特性。这是这种部署方式的一个优点，但是：为了使用这种部署模型，必须在服务器上安装一个 OpenLaszlo Server 环境。这种服务器环境是位于 J2EE 应用程序或 servlet 容器之上的一个 Web 应用程序，负责为 .lzx 文件处理所有请求。OpenLaszlo Server 的一个很棒的特性是，您只需将 Laszlo 文件和 OpenLaszlo Server 组件放在一个服务器上，便可以浏览页面并看到结果，因为它是由服务器动态编译和缓存的。OpenLaszlo Server 另外一个主要的优点是它位于所部署的应用程序与应用程序需要访问的其他资源之间，执行各种所需的转换。因此 Laszlo 支持 XML-RPC 之类的特性。由于在 SOLO 部署方式下媒体请求不是代理的，因此 SOLO 应用程序只支持 Flash、JPG 和 MP3 媒体类型。而且，由于不存在数据的代理，SOLO 部署中也不支持 RPC、SOAP 和持久连接之类的项.

    

（proxied模式图解）

 

    两种方式的对比：

 

    solo方式优点是：不需要绑定openlaszlo的开发环境，它直接生成一个swf的文件，可以部署在任何的web容器中，而且用户是不可见应用程序的源文件代码的；缺点在于它不支持对openlaszlo高级特性，像跨服务器访问其他主机上的资源时，会产生资源无响应的情况，如跨主机播放在源服务器上发布的视频时，产生了无法play的情况；（这对于集群环境下数据访问服务的影响将是很严重的）

 

    proxied模式的优势在与，它访问数据的速度比较快（相较于solo模式），支持RPC调用和远程主机上数据的访问，如我们可以直接访问源服务器上的swf文件并控制swf在不同frame之间的跳转（这点solo无法做到），但是缺点也比较明显：绑定了openlaszlo的环境，高耦合度使的在部署程序时必须要带上开发环境，另外它无法隐藏源代码文件，这会使情况变的不太安全，如果在客户机器上安装的话，会有可能泄漏我们的源代码资料。

 

    我们当前在线教室的模型是：一台flash服务器直接与用户连接，两台边服务器负责接受来自于flash的连接访问，一台源服务器负责接受边服务器转发的请求并进行数据处理服务。如果flash直接去访问源服务器上发布的资源文件时，solo模式下出现了无法调度资源的情况，即白板中文档无法换页，这对于我们的应用来说是无法接受的，因此，在目前没有更好解决办法的情况下，只能采用proxied的模式，在flash服务器中部署openlaszlo的环境，并将源代码拷贝到工作区中，编译后就可以有效解决白板换页的问题。