1.概述
Java，尤其是J2EE技术，在网络管理系统中的应用已经比较普遍。很多公司都将自己的新一代网络管理产品构建在J2EE技术平台之上，以便实现大型网络管理系统的分布式架构。一般的企业级或电信级网管系统都涵盖FCAPS等基础模块，同时在此基础上构建面向运营商的业务模块，如端到端的监控和管理、基于商业规则的告警处理、工作流等等。EJB很适合实现这类模块，很多公司的产品也已经这样做了。但是，本文要讨论的不是Java在网管服务器侧的应用，而是大家讨论比较少的客户端应用。
Java桌面技术一直饱受批评。而在选择了J2EE做网管后端后，客户端该如何选择呢？是选择简单灵巧的Web技术，还是选择复杂强大的Swing技术呢？
2.Web客户端
基于B/S结构的Web客户端技术现在几乎成为J2EE应用的主流。基于Web的应用系统优点很多，比如零安装、占用资源少、技术简单等。在加上Struts等优秀的开发工具支持，可以快速设计出结构合理、易于维护的程序界面。
由于B/S本质上是一个松散的、基于请求/响应机制的结构，它的缺点也很明显：对于后端信息的主动呈现、复杂的交互图形界面、实时监控图表等处理起来比较吃力。考虑电信网管的以下一些情况：
- 实时呈现服务器侧的告警、事件信息；
- 实时呈现某些资源的性能信息；
- 实时呈现整个被管理网络的拓扑结构图；
- 实时呈现单个设备的面板机架板位图；
- 客户端启动时需要加载大量数据；
由于基于B/S结构的客户端的某些局限性，使得它很难直接作为整个电信级网管系统的界面，所以它往往在一些小型的企业级网管、面向设备的EMS系统中出现，或者作为整个界面系统的补充，例如远程告警查询、计费信息查询等。一个最简单的例子是，我们常见的ADSL Modem或小型路由器中就内置了微型的基于Web的嵌入式网管（比如你可以直接通过地址http://192.168.1.1/登录到ADSL Modem中进行配置）。
3.Swing客户端
虽然大多数J2EE应用还是基于Web的，但Swing确实是Java标准的客户端开发包。大家对Swing的评论也很多。但Swing的桌面应用（例如JBuilder和NetBeans）确实不多。大致说来，造成Swing不那么流行的原因有：
- 开发Swing应用很花时间。制作Swing界面需要编写大量代码。JBuilder等工具确实可以自动完成一些代码，但还根本无法与Delphi等传统开发工具效率相比。
- 掌握Swing比较难。为了跨平台和性能等方面的考虑，Swing不得不采用Layout、LookAndFeel、非线程安全等特性。这使得对于初学者来说学习Swing门槛有点高，需要小心的处理很多底层细节，理解大量MVC概念和设计模式。
- 设计偏于复杂。Swing有着无与伦比的扩展性和灵活性。不过复杂的API使得即使某些简单的常规问题也不那么容易找到答案（你能正确的使用进度条控件吗？）。Swing是一个偏向理论化、学术化的工具包，它采用了很多现代的UI理论：工厂模式、渲染器、MVC、事件处理、国际化等等。但是对于大规模的常规界面开发来说，Swing的设计确实有点overkill了。
- 缺少Native特征。所以很多客户都觉得Swing界面在显示和使用上都有某些怪异之处，总之和本地的程序界面多少有些不同，例如速度、内存、拖拽、交点、字体甚至鼠标滚轮等都有一定的差异。
不过，使用Swing来做电信网管系统的界面还是比较合适的。Swing是Java的标准客户端开发包，它可以方便的和后台J2EE服务器交互，同时提供丰富的交互能力、实时告警/事件信息的通知、复杂网络拓扑图的呈现等。
SWT是另一个引人关注的客户端技术。SWT是IBM为它的Eclipse集成开发环境而开发的图形用户界面工具。SWT可以在Eclipse环境外使用，而且提供对操作系统本地图形用户界面的直接访问。因此，基于SWT的Java应用程序拥有本地的图形用户界面并且可以和本地别的应用程序和部件集成在一起。SWT的问题是，它还不是Java的标准技术，目前也尚在发展之中，变数很大。对于投入很大的电信网管系统来说，使用SWT似乎还有比较大的风险。
4.客户端的几个难点
我们的前提是，你已经决定采用J2EE和Swing技术来构建你的网管系统。对于客户端来说，此时还有以下一些技术难点需要考虑。
4.1 网络拓扑图
网络拓扑图应该是电信网管客户端的核心。网络是网管系统的被管对象，网管系统自然需要用最直观的方式呈现网络的拓扑结构、配置信息、运行状态等。客户端的各种功能一般以网络拓扑图为核心进行展开，如通过菜单、鼠标等提供FCAPS模块的各种功能入口。面对复杂的网络结构和大量网络运行信息，用图形化的界面来呈现和操作网络无疑是最直观、方便的方式。
用Swing来实现网络拓扑图的呈现不是一件轻松的任务。尤其面对复杂、大型的电信网络时，如何高效、直观的呈现数量众多、种类烦杂、有层次的各种设备、连接，以及各种告警/事件信息，确实是一个难点。我们要考虑的不光是Java和Swing技术，同时要掌握图形学的一些技术，以及大量电信网络知识。
解决问题的办法：一是自己开发，二是使用第三方组件产品。有实力的大公司会考虑投入人力物力开发自己的Swing网络拓扑组件，以便为自己众多的网管产品使用，节省长期费用。不过更多的公司还是考虑使用第三方组件包来实现网络拓扑图的呈现，减少在GUI上花费的精力，将力量集中在网管业务模块的设计和开发上。毕竟网管的任务是网络管理，而不是图形图像处理。
4.2 设备面板图
网络是由网络设备及其各种物理/逻辑连接构成的。用户关心网络中每一个设备节点的运行状况。网管界面需要提供每一个设备的面板图/机架板位图。设备面板图可以直观的展示设备的外观物理和逻辑结构，同时呈现各种告警、状态信息，使用户一目了然的了解设备运行和配置状况。
Swing来呈现设备面板图面临的困难和网络拓扑图一样。稍有不同的是，设备面板图中的物理/逻辑连接比较少，但设备的种类、样式、功能繁多，如何减少代码开发工作量是一个要仔细考虑的问题。毕竟网管系统需要持续的增加更多的被管设备类型，而开发却不能没完没了。
解决方法可以考虑自己开发或者外购第三方组件。
4.3 实时接收后端数据
简单来说，数据的走向有两种情况：客户端主动从后端获取数据；后端主动将数据通知客户端。假如后端系统模块以EJB的形式存在，则可以通过普通的远程调用来创建、使用EJB业务模块。而后端的运行信息如告警等如何主动、及时的“推”给客户端则需要仔细研究。尤其要考虑以下各种情况：
- 客户端数量很大时；
- 客户端断链时；
- 每个客户端需要接收的信息不同时（比如由于权限、角色的不同所致）；
有两种方案可以考虑：一是采用EJB回调（Callback）客户端的方式；二是采用JMS消息通知的方式。
4.4 加载启动数据
由于网管系统非常庞大复杂，客户端在启动时一般需要加载大量数据进行初始化。比如，加载用户个性化信息、网络拓扑数据、告警信息、设备信息等等。对于一个有1000个电信设备节点的网管系统，其物理对象（如网元、架、框、板、端口、时隙等）将非常多。再加上各种物理连接（光纤、电缆、电路等）和逻辑连接（各种虚电路、各种协议链路、连接、通道、路由等）数量将非常大。此外客户端还需要加载所有被管对象的告警、状态、权限等信息。很多大型网管系统的客户端，启动就需要数分钟，同时要求机器要有宽大的显示器和服务器般的CPU、内存。
如何解决客户端快速启动、快速加载数据并初始化是网管开发中一个难题。简化数据结构、实现按需加载（on-demand-load）可以有效缓解这类问题。
5.结束语
本文简要的探讨了Java客户端技术在电信网管系统中的应用及其面对的问题。后续文章将针对本文提出的一些技术难点进行深入探讨。下一次我们将讨论如何使用ILOG的JTGO与赛瓦软件的TWaver组件产品进行网络拓扑图、机架板位图的设计和开发。
参考文献：
- [1] Telecom Network Management With Enterprise JavaBeans Technology, A Technical White Paper. Sun Microsystems, Inc. 2001