由于J2ME和BREW功能的相似性，许多业界人士一直将这两个平台视为相互对峙的竞争对手。事实上，J2ME是BREW的有益补充，而不是它的竞争对手。具体说来，BREW是一个由客户机、服务器和商业模式解决方案组成的完整开放式超集，可满足所有无线应用相关厂商和消费者的需求。在这一框架内，J2ME应用仅为一个子集，在BREW环境中，J2ME能够更好地发挥作用。QUALCOMM和IBM正在将IBM基于J2ME的虚拟机环境（WME）移植到BREW，使Java和BREW两种平台相得益彰。本文旨在通过两种平台系统能力、客户端能力、服务器端能力和商务模式的比较，辅助无线运营商和制造 商制定具有竞争优势的无线数据平台策略。
两种平台系统能力的比较
无线运营商把握数据增值业务商机的关键在于选择恰当的技术平台，在整个网络中提供无缝一致的友好用户体验，并提供一整套商务模式，迅速取得规模经济的优势。传统意义上“基于标准”的增值数据平台解决方案由于规范松散，各厂商的设备由于硬件和软件的配置不同，运营商的互操作能力和漫游能力大打折扣，用户满意度也随之降低，从而限制了运营商规模经济优势和新业务培育。所以，无线应用解决方案必须是基于全球统一标准的开放式平台，它应独立于硬件，并能够部署于任何网络、无线标准或移动设备之上。它们还必须能提供端到端的系统能力，提供全面支持在用户端上发现、购买、下载和管理应用/内容的机制，为用户创造完美的体验。在提供系统端到端能力方面，BREW和J2ME的对比如图1所示。
从上述的对比可以发现，J2ME如果独立使用，很难胜任提供全面端到端的无缝操作，而且还要借助于第三方软件的支持。因此，除了WME和BREW之外，移动Java方案还远无法实现“一次写就，四海皆准”的适应性。这其中的原因在于MIDP在电话设计上乏善可陈，而实施方法变化众多。制造商必须为具体型号电话编写新的API，以获得适当性能，同时还需加载针对特定运营商的MIDP类库。MIDP不具有应用甄别、购买、计费或无线升级功能，这就需要更多的应用发现和管理软件，从而增加对电话内存的需要，这与J2ME最初的设计理想也是背道而驰的。最后，手机制造商（OEM）需要为不同型号的手机配备不同的虚拟机。
BREW平台在设计中，弥补了J2ME不足。在BREW的设计框架中，整个J2ME/CLDC/MIDP可以看作是BREW应用的扩展（WME），无须单独移植就可以在各种电话上运行，而且不必将设备返回给运营商就可进行升级或更换。如果使用BREW平台支持的虚拟机环境编写Java应用，Java应用的普及将会大大加速。这对于今天速度决定生存的无线通信业来讲，BREW的支持能够使开发Java应用的厂商获得更多的市场先机。除了设计的优势，BREW平台支持所有应用类型（如振铃音乐、图像、图形、多媒体、浏览器插件、及话音、J2ME或源程序等），从而可降低开发商、设备厂商和运营商的开发和部署成本。这样就无需为每项新推出的业务实施专有平台。WME可充分利用BREW在电话业务、GPS、SMS、TAPI和其它业务方面的深层芯片组接口发挥功能。
两种平台客户机端能力的比较
BREW平台和J2ME均通过使用电话的CPU和提供运行实时环境来简化移动应用的开发并提高应用质量，使程序员实现“一次写就，四海皆准”的适用性。基于客户机端处理的平台克服了在线浏览器平台（如WAP）速度慢、延迟时间长和浏览器需使用独立连接等缺点。BREW和J2ME通过提供抽象层的结构可使程序员从单调乏味的嵌入式系统编程工作中解脱出来，并确保了程序无须修改代码就可运行在不同设备之上。虽然BREW和J2ME解决这些问题的方法各不相同，但最终可实现互相兼容。J2ME运行于与设备其它部分隔离的“沙箱（sandboxed）”-虚拟机内。这虽然会提高性能成本，但它可以支持使用更简单的Java编程语言，并能够提供更好的安全性。通过拒绝沙箱外部的访问，沙箱可以保护本地CPU不受恶意Java应用的攻击。
尽管一些人认为沙箱可使J2ME应用无需进行广泛测试，但日本运营商NTT DoCoMo在推出基于J2ME的电话之后，却遭受了网络攻击。黑客利用J2ME的电子邮件功能将病毒发送给其它电话，从而导致这些电话关机、丢失数据和呼叫紧急服务。
QUALCOMM提供了一项可为运营商测试所有BREW应用的服务：即在运营商推出应用下载服务之前，由独立的第三方国家软件测试实现室来全面检查漏洞、病毒和质量。相比之下，J2ME电话制造商“证书”计划并没提供所有J2ME应用实施的统一标准。BREW应用（包括J2ME）由于得到了开发商、QUALCOMM和持有VeriSign证书的运营商的数字签名能提供更好安全性和可靠性。
从对客户机资源的占用上来讲，BREW占用约150kb的内存，并与芯片组紧密集成，可提供所有下载、安全交易、深层芯片组和电话业务接口、以及应用管理所必需的功能。BREW源程序是用C/C++编程语言编写，而且BREW可以运行在价格低廉内存空间最小的低端电话上，这是J2ME无法比拟的，因为MIDP需要在手机中占用约500kb的存储空间。即使最狂热的J2ME迷也承认源程序的运行速度比MIDlets要快得多。在中高档次电话市场中，BREW和J2ME可配合工作，提供最全面和标准的解决方案，以及精彩的最终用户体验。与某些要求使用有线计算机连接第三方基于J2ME的解决方案不同，BREW的“移动商店（Mobile Shop）”应用使用户可以通过手机以无线方式迅速查找并购买J2ME和其它应用。客户可以决定应用需要占用的内存空间、删除应用释放内存空间以及重新开始中断的安装工作。BREW提供一个完整解决方案所需具备的发现、购买、下载、计费和调试等功能。
J2ME的支持者通常认为BREW应用只能运行在QUALCOMM CDMA芯片组上。这又是一个误解。BREW最初被移植到QUALCOMM芯片组上，但现在已经被移植到TTPCom的GPRS芯片组和其它GSM/GPRS版本的芯片组中。此外，对于交换方式而言，BREW和WME J2ME也可与现有的2G和电路交换网络配合工作，从而可满足近期不准备扩建分组网或3G网络，或正准备部署类似网络的无线运营商的需求。
两种平台服务器端能力的比较
BREW后台软件被称为BREW分发系统（BDS）。BDS是一种全面可灵活升级的系统，由一台下载服务器、交易管理器、运营商和开发商外联网及应用管理器等模块组成。运营商可以从任何供应商那里购买BDS的硬件，以最佳的市场价格获得这些设备。部署BDS软件的成本也很低。运营商可按需自行控制软件系统的配置。运营商可用不足10万美元的造价即可支持400万用户的系统。BDS可与运营商现有的计费系统整合起来，提供一个无缝、灵活、便宜和全面的架构，实现BREW应用的分发。
BREW下载服务器软件只在验证一个应用具备合适的签名、手机具有适当的配置、并且有足够的内存下载后才会为用户提供这一应用。用户界面包括BDS的几个步骤：决定和显示价格和相关的信息（如有效期或免费试用），为用户提供下载的选择、提供一个与运营商现有计费系统一体化的计费记录。BDS还使运营商可以通过无线方式召回或更新应用，无需用户干预。
两种平台商务模式的比较
无线产业必须面临的一个挑战就是运营商、开发商和OEM厂商只能以有限的资源承载多种不同的技术，因此一种平台技术若想获得成功，必须最大程度调动起产业链各方参与和支持。一套缜密的商务模式和价值分配方案是激活整个产业链各方能够协同工作的关键。
BREW设计的精妙之处在于BREW不仅提供了一个高效的应用开发和下载技术平台，而且提供了一整套精心设计的商务模式。首先，BREW客户端软件的免费的授权和轻松移植使得所有的手机制造商可以随时提供BREW功
能。借助于BREW平台，新的数据增值应用推向市场的时间减少了，而且可以稳定地运行在所有的手机上。其次，开发商可以免费下载BREW软件开发工具箱（SDK）。不管应用是用C语言还是用J2ME编写，BREW开发商可以向数个开发商提供他们的应用，而无需修改原码，也不需要与运营商进行大量的谈判。运营商获得的好处也是显而易见的：运营商只需在大量经过验证的BREW应用中选择所需新的业务，从而降低应用采购成本。此外，BREW的商务模式确保运营商只有用户实际下载这些应用时才为这些应用付费。运营商还可以从无线连接时间、增值服务费、赞助费和内容中获得额外的收入。
分发、管理和销售BREW应用是BREW商务模式的核心。BREW系统构造一个为开发商和运营商购买和销售应用的虚拟市场。运营商可以低成本部署BREW系统，并自行选择可供下载的应用。当然，也包括J2ME应用，并与开发商直接谈判价格。针对特定应用和细分市场，运营商可以选择一个最为合理的零售定价模式，按需灵活进行差异定价。比方说，运营商可以对某些应用下载采用高定价策略，对那些有销售广告商赞助少收费，甚至免费。
在商务模式的设计上，相比BREW来说，J2ME存在明显的缺失。借助BREW环境和商务模式，J2ME的开发商可以分享应用下载的商机，运营商的数据应用业务也由于获得更多产业支持能取得更大进展。
增值电信 2002.11
本文地址：http://com.8s8s.com/it/it17740.htm