远程控制Java

核心提示：——使用VNCj将你的java用户界面输出到VNC阅览器 摘要 目前，在地球的另一边运行一个图形终端并远程控制一台计算机是很普通的事情——这也是微软为什么将远程控制建立进Windows xp的原因，远程控制Java，这篇文章将向你显示如何轻松地使用通用虚拟网络计算机（VNC）协议和一个小型自由库将你的用户界面在网络上输

　　——使用VNCj将你的java用户界面输出到VNC阅览器
　　摘要
　　目前，在地球的另一边运行一个图形终端并远程控制一台计算机是很普通的事情——这也是微软为什么将远程控制建立进Windows xp的原因。这篇文章将向你显示如何轻松地使用通用虚拟网络计算机（VNC）协议和一个小型自由库将你的用户界面在网络上输出到一个远程计算机。　
　　现在Windows XP通过网络支持桌面远程控制，我们可以就近看一个循环，一个靠近我们很久的循环。选程控制不是新的。实际上，主机哑终端只不过是为一个中心计算机进行远程控制。小型机，象VAX（虚拟地址扩展），用分布式终端服务器网络使主机的精确终端控制层次更复杂。在两种情况里，一旦你从一个终端访问登录进一个计算机， 你就能在整个网络中用终端仿真连接到其它计算机上。用位于地球另一端的一个主机，远程控制忽然变得真正有力量。当ARPANet (高级研究项目代理网络) 变成Internet时，小型哑终端能够将你与世界连接。最后的技术发生在个人电脑变得可承受时，答应哑终端变成智能终端。随着图形终端的出现，你能够象在你的办公室一样轻松地控制你的远程计算机，唯一不同的是迟缓的性能。　
　　然而，网络带宽已成为一个极大的问题。在一个局域网中从主机到终端传输图形会工作得很好，但广域网不能操作站点间的图形远程控制。期间，虽然PC变成智能终端那样便宜，但当你在房间里拥有一台时控制一个远程计算机忽然变得毫无意义。　
　　但是远程控制不会消亡。公司发现给每一个职员提供一台电脑将在维护上花费巨大。PC操作系统仍还不是“启动以后就不管”。他们要求不断地调整以保持每一天能够继续工作。终端再次象是一个好的主意。微软抓住这一想法并引入了Windows终端服务器，这只不过是旧的X终端的一个克隆。最终将远程控制带进了家庭。在过去的几年里，高速连接到办公室和家庭变得很流行，并且我们现在看到许多专利产品不断地满足需求，答应我们通过我们的电话控制办公室或家里的电脑。　
　　微软实际上也将远程控制技术委托给我们这些在家里的傻瓜（记住，微软也不得不给我们提供用户支持！）代表一个20年旧模式的成功。用任意一台电脑作为主机和终端，你所需要的一切就是在世界的任何地方访问任何电脑的一个Internet连接。　
　　因为远程控制能力的所有刺激，你也应该拥有它。这篇文章介绍了一个自由的、百分之百的Java库VNCj，并向你显示了如何用它创建远程控制的Swing，AWT（抽象窗口工具包），和在Java中能够被任何VNC（虚拟网络计算机）阅览器访问的应用程序。VNC 是一个由Olivetti研究实验室最先开发的自由、超轻和流行的远程控制系统。这以后成为了剑桥AT&T实验室。它是微小终端，调用viewers，支持你所听说过的任何平台。包括一定数量的Java小程序。使用VNCj，用户能够从PDA、蜂窝式电话以及事实上所有的桌面访问你的Java服务器。通过象素模式（看下面）和JNI（Java本地界面），VNCj甚至能够服务非Java代码。　
　　远程控制应用程序
　　远程控制电脑比远程控制电视及烤箱设备有更复杂的特性。例如，从一开始，远程控制就答应多个终端同时工作，这要求多任务处理及安全系统。经常这些系统被设计进操作系统，其维护很轻松因为你能在中心治理所有安全特权。一个缺点是：假如你在操作系统级别提供访问，有人可能会通过“黑客”手段超出对他或她的约束，这已经发生过。另一个问题是远程控制层不是总拥有我们所需要的特性。例如，不是所有操作系统都支持并发多用户或能够与我们的终端通信。　
　　在应用程序级的远程控制能够解决这些问题。最差的安全漏洞可能带来对应用程序本身的黑客攻击。系统应该保持安全。当一个操作系统解决方案不得不是一般时，它们也能够为特定的目标被设计。　
　　在Java中写一个远程控制应用程序有许多优势。首先，显而易见是跨平台。你能够在任何服务器上运行你的应用程序，且用户并不需要明白这些。但是Java也在为远程控制方案提供自己的强大开发平台。你能够用Swing创建一个完全视窗化的界面并立即远程输出它因为Swing只使用了轻量级的Java产生的组件。同时，Java也包含一个强大的2D图形库能够在一个内存缓冲里对于终端工作。任何与Java图形附加的产品，如图形信息系统（GIS）及3D建模都将立即工作。　
　　假如你还没有考虑过它，那么将你的下一个应用程序设计成支持远程终端。你知道网络浏览的两个资源，用户和服务提供者都是安全的和零部署的。远程控制，象载入、共享这些特性使其为广阔的部署更完美。实际上，这两种部署方法能够互相弥补。当哑终端远程控制另一个版本时，智能终端将启动你的服务器的另一版本。有一点是图形远程控制使服务器严重超负荷，它必须处理每一个用户的界面。对于那些通常只有少数并发用户的应用程序，如治理模块，远程控制是完美的。并且，假如你的环境已经被terminalized，则用户可能期望从他们的终端获得所有服务。他们将问你为什么新的服务不是。　
　　用VNCj远程控制Java
　　VNCj为给VNC阅览器提供Java服务支持六种不同的模式：　
　　Swing模式
　　因为AWT必须服务于低端普通特性， 用百分之百的Java写Java的强大GUI（图形用户界面）是有意义的：它将被作为轻量级的AWT组件完全执行。副作用是尽管Swing模拟下面操作系统的外表，但在桌面上Swing仍显得古怪。它做它自己的事情，并且它有的无论何种特性都是非凡编排进去的。对于用户，这是不可思议的。在本地应用程序上工作的增强修正桌面不能与Swing工作。对于开发者，Swing象是一个多余和超重的（尽管是轻量级）已存在功能的复制。但是对于远程控制用户和开发者，Swing是一个祝福。　
　　因为所有Swing组件都是Java产生的，它们能通过线路立即传输。使用VNCj，你能创建一个JDesktop，用JInternalFrames将其组装，并将其发送至VNC阅览器。Swing答应一个真的虚拟桌面。假如那是你想要的，就可以松口气了。VNCj对于你设计Swing程序的通用技术没有更多要求。同时注重，因为组件永不在屏幕上画出，你能够使用你想要的任何分辨率和颜色模式，甚至服务器不支持的一个图形配置。较低性能的终端仍能访问你的服务器，因为VNC必须降低图形对阅览器的要求。图1显示了Swing模式范例
　　　
　　图1 Swing模式
　　AWT模式
　　我知道AWT通常由繁重的组件构成，但这并不是不得不作的。你能够用你自己的AWT同位体创建你的AWT。那是VNCj所作的：它使用Swing轻量级组件作为同位体。记住，我们的Swing组件是虚拟的。AWT模式是建立在Swing模式的上面，其又建立在VNC的上面。无论何处模式都没有繁重组件。你能够设计VNCj在缺乏AWT支持的机器上运行（VNCj 1.0，虽然，为了字体仍要求基础AWT)。AWT模式提供与传统代码或平台的兼容性。然而，对于GUI功能，应用Swing模式能做AWT能作的所有事情并且更多。而且，因为机载，模式对于用户看上去都一样，象图2所示。　
　　图2 AWT模式
　　　 点击查看大图
　　轻量级模式
　　你的应用程序可能不需要一个视窗化GUI或它可能提供一个你自己设计的GUI。没有问题，因为任何你创建的轻量级组件都能够立即与VNCj一起工作。你只需要继续java.awt.Canvas，调用getGraphics()，并作图。你能够完全访问Java 2D库以及任何服务AWT图形的库。包含在VNCj中的这个模式的演示创建了一个简单画线的画布。因为轻量级模式答应共享会话（一个VNC特性），画布是一个立即共享的白板（虽然你想避免鼠标指针冲突需要更多的工作）。图3显示了轻量级模式演示。　
　　　
　　图3 轻量级模式
　　象素模式
　　让我们从图片外得到AWT。象素模式让你对一个发送至用户的象素数组访问，意思就是你来进行绘图。但那可能正是你需要的。使用JNI，你能够用非Java代码填充这个数组并让VNCj进行服务。这是VNCj能够带给你的最快速度。对于这个模式的演示是一个七段数字时钟，通过在象素数组中填充绘图。图4显示了这个例子。
　　　
　　图4 象素模式
　　控制台模式
　　嗨，假如Swing能够侥幸在桌面上仿效一个桌面，为什么不用一个GUI仿真一个控制台呢？这个好主意可能对于你来说毫无意义。任何能够运行一个VNC阅览器的平台也能运行Telnet。但它真的能吗？假如你已经有一个建立好的VNC基础构造，运行一个测试VNC阅览器可以比胡乱设置Telnet模拟参数更简单轻易地证实，通过Telnet客户软件其是不一致的。VNCj的控制台模式答应你将一个控制台仿真成一个VNC终端。不可思议，但坦率地说，它工作了。并且这有一个额外补贴：你能够在一些用户中共享控制台，一个Telnet通常不能完成的任务。图5显示了一个控制模式。
　　
　　图5 控制模式
　　RFB模式
　　对RFB (远程帧缓冲)，VNC的有线协议，在VNCj内被作为一个独立库执行。假如即使象素模式对你来说还不够，RFB模式将取得成功。这个模式的演示使用AWT Robot类对客户服务在桌面下的一个图片，模拟VNC更多的普通用法：桌面远程控制。这个演示真的只是一个玩具。假如你想要那种功能，可以安装专用的VNC服务器。　
　　一个遥远的星球？
　　我希望我已经激发了你的好奇心，但现在让我给你泼点冷水。远程控制能够在许多情况下提供完美的解决方案，但是在其它方面只是一个折衷方案。远程控制加重了网络带宽和服务器CPU的负荷，假如客户能够自己完成工作这完全是没有必要的。究竟，我们的终端设备变得越来越智能，为什么不让它们运行用户界面呢？象越来越多的平台能够运行Java，真正的解决方案应该用JNLP（Java网络启动协议）启动Java。将一个应用程序设计成支持JNLP和使用VNCj一样轻易。因此，在我们到达完美的计算机世界之前