.NET vs J2EE——面对SOA的荒谬与误解_.Net教程

推荐：ASP.NET多频道网站架构实现方法
各频道分别位于不同的Web Project(具有独立的二级域名)，并将所有的业务逻辑以及数据访问功能封装成Class Library，所有频道共用这个Class Library。 下面详细介绍实现方法。 假设网站有三

·.Net与J2EE在金融行业愈来愈呈势均力敌之势，二者均宣称提供了不同于对方的、听起来很迷人的个性化应用服务。

·理性的IT执行官们已经深刻的认识到这样的一个事实：无论是.Net还是J2EE，将来必将在SOA理念的应用中占有各自的一席之地。

·Microsoft的.Net技术在今天的金融市场面前，显得商机无限。

·从前，荒诞与误解依然在.Net与J2EE平台之间萦绕着：似乎没有一个IT决策者能够看透了这层迷雾，继而在两个平台之间做出理性的决择。

·今天，技术执行官们已经能够很好的把握需求动机，进而在这两种平台架构上做出正确的选择。

涉及主题

SOA(Service-Oriented Architecture，面向服务的架构)已经在全球业界日益成为核心的技术议题，那么实现SOA的技术标准问题则成为了严格关注的核心问题。在这个领域中，所有的IT经理们将不得不面对一个古老的问题：J2EE和.Net，我们选择谁？

我并不愿意试图去回答“Yes or No”，在特定企业的特定应用环境下的选择，也不在讨论范围之内;但是本文的确广泛搜集了当今金融领域内IT专家们的普遍性思维以及他们选择技术架构的方法论。IT经理和软件提供商将能从本文关于技术架构的讨论中发现一些令人诧异的结论，并且了解金融IT专家们在这场关于J2EE和.Net技术架构争议中的思维方法。因此，自从J2EE和.Net诞生以来，那些弥漫在你脑海中关于这两个平台的“荒谬论点和神话故事”很可能从此销声匿迹。

背景

上个世纪90年代，面向对象的编程(OOP)引发了诸多的软件开发标准。首当其冲的是Microsoft的组件对象模型(COM)，这是一个模块(组件)化的技术开发架构，它源自于微软早期的对象链接与嵌入技术(OLE)。稍微资深一点的技术人员应该知道，今天互联网应用中最常见的ActiveX技术就是构建在COM框架之上。

2002年微软全面的用.Net从逻辑层上置换了COM，作为新的软件开发框架(COM仍然被支持)。.Net技术的全面推进，统一了微软的不同技术理念和平台。作为一个战略品牌，.Net为Web Service提供了原生的解决方案，并且成为提升不同应用和系统之间互操作性的标准。

在1993年微软引入COM之后，Sun公司于1995年推出了Java平台。Java平台由一套应用开发语言(Java)、API和Java虚拟机(JVM)构成，JVM允许用Java编写的程序运行在不同的操作系统上。事实上，Sun引入Java的初衷是使得程序员能够开发可移植的应用程序，而不关心硬件和操作系统。在1999年末，Sun提出了Java平台企业版(J2EE---Java to Enterprise Edition)，该规范被应用在主要的IT提供商以构建稳健的应用系统框架，如IBM、Oracle和BEA，等等。

2003年Sun公司发布了J2EE 1.4版，除了增强更加稳固的企业级应用之外，还增加了Web Services支持。Sun把这个最为流行的版本称为Java EE。

由于.Net和J2EE各自的初衷，使得二者之间的竞争常常掺杂着一些莫名其妙的荒诞。但是最近IT专家及IT决策者们关于这个问题的争论却更加注重于从业务实践的客观角度考察二者技术上的优劣，因为这将有助于他们的正确选择。

一些数据

几乎每一个IT技术经理都听说过“.Net应用的延展性匮乏或者J2EE架构不易开发”的故事，的确，对这两个平台认知上的误解在业界普遍存在。

就在最近的两年以前，许多的IT经理们常常带着个人偏见对其中某个平台情有独钟，而刻意的排斥另一平台。他们仅仅因为一个毫无依据的个人预想而拒绝部署某个平台，或者其依据甚至是来源于杂志上的某篇技术文章。这种情况非常的普遍，因此围绕着.Net和J2EE谁优谁劣的讨论相当多。

我们承认.Net平台的延展性会因为其特殊的基于Intel的硬件平台而受到约束，但是我们也不应该忽视.Net平台诞生的那一天起，就有着比J2EE平台更强的互操作性，并且允许开发者利用现有的.Net组件构建更加复杂的解决方案，而不用花费太多的成本。

J2EE得到了大部分供应商的支持，包括Sun，IBM等，所以J2EE的最大灵活性和可移植性不用置疑。另一方面，.Net平台被微软独家全面支持，因此有着更为一致性的行为方式和可预见性。

令人遗憾的是，两种技术平台的第一手测试资料的匮乏总是使得人们的主观臆想常常凌驾于技术本身的发展之上。 对.Net和J2EE认识的模糊也导致了IT执行官们在关键时刻的优柔寡断，甚至又回到了本世纪最初几年的状态，那个时候的平台分布如下所示。

Net 22%

J2EE 26%

不确定 15%

都没有 30%

都有 7%

全球.NET and J2EE技术的跨行业调查(2002)

资料来源：Merrill Lynch & Co.

上表为2002年Merrill Lynch对全球100个CIO关于Web Service在两种平台的应用分布数据。对100个CIO的问卷调查显示出他们的公司缺乏清晰的Web Service应用战略。

下表显示了2002年.Net和J2EE平台在美国最大的100家银行的应用分布。

Net 15%

J2EE 36%

不确定 24%

都没有 5%

都有 20%

上表为美国最大的100家银行2002年的平台分布

资料来源：全球金融咨询及顾问公司TowerGroup的评估报告

几年之后的今天，IT经理们的决策渐渐变得更加理性，他们开始更多的基于业务需求和技术因素做出选择。我们终于发现，在同一家银行常常同时存在着.Net和J2EE两种技术架构，更为重要的是，Web services已经成为这两种平台整合的共同桥梁。

回到本来

哪个平台更加适合新的应用?或者我们应该升级到那个平台?必须做出决定。在过去的6年中，.Net和J2EE平台在全球范围里都未能保持着对对方的绝对优势，他们各自有着自己的特色。

2006年，全球著名的金融顾问咨询公司TowerGroup在与金融行业CIO和IT架构师们的一次研讨中，发现他们对于这两个平台的选择有着更为清晰的目标和期望值，这的确是一个消除误解的好机会。

这次讨论中至少有两点值得我们注意：企业似乎并没有固有的倾向性;也没有明确的迹象表明那一个平台更加具有延展性和可靠性。

(1)对于.Net和J2EE并没有特别的偏好

经过广泛的调查，TowerGroup公司发现，企业从前对某一个技术平台的偏好完全是基于个人的爱好和浮躁的“一窝蜂”心态。这种态势目前渐渐变得理性，当然不排除仍然有某些IT经理存在着个人的嗜好。

但是企业对于Web Service和SOA的强烈关注，则意味着对于某种平台的个人嗜好不再成为平台选型的可接受的依据。

(2)没有证据表明那一个平台更具延展性和可靠性

虽然有许多关于.Net和J2EE平台性能的研究报告，但是这些报告大部分要么来自于Microsoft，要么来自于J2EE的厂商，使得他们的公平性令人怀疑。也许他们的研究结果是真实的，但是这种供应商自身的性能测试本身就冲淡了研究结果的价值。另外，设计好的Test Case具有很大的复杂性，至多只能有一到两个比较全面的测试用例，其他的用例则显得十分的苍白与简单，极大地限制了测试范围的适应性，从而与实际应用场景距离甚远。

差异的必然性

虽然对于.Net和J2EE平台的个人偏好显得毫无理由，但是IT经理们承认这样的一个事实：两个平台的差异性常常成为他们在开发、选型和维护升级时的重要参考依据。

(1)在硬件和操作系统之间的可移植性

.Net和J2EE之间最大的差异性成为金融企业做技术选型的重要依据：在数据中心的数百台服务器之间移植应用的能力。由于J2EE原本就是一套跨平台应用的规范，所以对于那些需要部署到不同服务器上的应用，J2EE似乎是更好的选择。

但是，J2EE的上述优势却遭到两个因素的严重挑战。

首先，没有两个厂家的J2EE规范是完全一致的。这种在部署、存储和安全性规范上的微妙差别意味着在两个平台之间的应用移植需要因为这种差异性的存在而付出代价。因为对于很多应用而言，应用的可移植性远比可维护性还要重要。

其次，银行从前为了克服应用能力的瓶颈，总是存在着升级到具备高端处理能力服务器的需求。但是随着基于Windows-Intel的机器处理能力越来越强大，这种需求被最小化。Unisys公司在6年前就推出了基于windows的主机(Mainframe)，IBM也推出了64位的windows兼容的系统，而CPU层叠技术也允许基于SMP(对称多处理)的Windows 服务器系统拥有四个CPU。进一步，.Net操作系统(Vista和Longhorn)将进入高端处理市场，尤其是网络计算机的出现，使得大量的单机分布式处理能力足以胜任目前大型机的工作负荷。

(2)易开发性和可拆卸性

.NET的易用性、效率和成本均领先于J2EE。使用.Net，IT专家们比使用J2EE更加不用关心底层细节。因此能快速捕捉商机，成本也更低。

.Net比J2EE灵活得多，它允许开发者使用多种语言在同一个平台上开发，因而能够利用广泛的开发资源。总而言之，使得开发团队的运作更加高效。

重要的是，.Net的可用资源相对较多。对于金融行业而言，Windows平台占据绝对数量，而且几乎所有的ISV(独立软件供应商)都支持Windows平台。

另外，IT执行官们大多数只关心解决方案，而并不关心平台本身。他们并不要求ISV帮助他们从.Net平台移植到J2EE平台，因此金融行业常常维护着不同的应用环境。

两个因素也严重挑战了.Net平台易用、高效和低成本的优势(虽然.Net程序员相对于Java程序员而言，总是更快更高效)。

参与TowerGroup公司调查的IT执行官们透露了这样的信息，对于一个大型的项目而言，J2EE和.Net之间的TCO(总的拥有成本：包括资源、时间和财力)仅仅相差不到10%。同时，很多IT经理认为J2EE更适合性能调优，这两个因素严重削弱了.Net的优势。

(3)企业内部可用的资源

影响.Net和J2EE选型的最大因素来自企业内部的可用资源。

如果大部分的程序员擅长J2EE，那么企业会很自然的选择J2EE平台，而免除了再次培训的开销;相反，企业会选择.Net平台。

TowerGroup公司的调查认为，将来纯代码开发人员将会渐渐的转向Windows平台，因为.Net支持多语言开发，并且远离系统底层。但是，J2EE将在那些关注性能调节和特定领域的定制开发的企业里继续发展。

基于这样的发现，TowerGroup对今天的.Net和J2EE的市场作了评估，结果如图3所示。

Net 11%

J2EE 17%

不确定 15%

都没有 2%

都有 55%

上表为美国金融企业的平台分布

资料来源：TowerGroup评估报告

虽然前100家银行中很多继续支持其中一种平台，但是大部分的银行开始实施SOA架构，同时维护两个平台。

(4)更远的商机

无论银行的IT机构对这两个平台的看法如何，但是接受TowerGroup调查的IT执行官们一致认为，J2EE平台已经大范围的被广泛采纳。在这场赛跑中，J2EE领先于.Net，而这种领先的优势会随着时间的推移而不断的弱化。好几个IT经理同时也认为，J2EE比.Net的生命周期更长，平台更加成熟，技术专家更多。

在TowerGroup公司最近的一次对欧洲银行IT经理的调查中，参加者被问到“是否大量部署.Net平台”时，居然没有一个人抬头或者举手;但是所有人都证实了他们部署了J2EE平台。无论如何，看来这种领先的趋势很难改变。

不过，在与他们的讨论过程中，有一点共识很明显：微软的确有机会提升.Net在银行业的应用市场，填补太多的空白。

(5)桌面应用和企业级应用之间的差异

大多数人认为，在.Net和J2EE之间最为显著的区别之一，就是.Net平台常常被部署在客户端，而J2EE平台(如WebLogic/WebSphere/JBoss/TomCat)则更多的被部署在服务器端。事实上这是一个不伦不类的误解，.Net是一种技术框架，不是一种产品，更不是Windows客户端;而J2EE只是一种协议，或者说是遵从J2EE协议的应用架构。

从某种程度上讲，人们对.Net平台的认知误解也诞生了一个笑话：因为微软把自己的产品触角延伸到了企业应用的每个角落，从低端的桌面应用到高端的企业应用，几乎都看到了.Net平台的身影;那么那些IT执行官们免不了会把他们在低端产品上的感受推而广之到其他的微软高端平台上。当一个IT经理在忙碌了一天之后回答家里，打开电脑却还要耗费好几个小时去面对PC机上的病毒干扰，那么Windows平台将会给他们留下“深刻的印象”。事实上微软的高端和低端产品(如Win2k Pro/windows XP/Win2K Server与 Vista/Windows Server 2003/Longhorn)不可同日而语，但是这种主观上的联系则很难避免。

也许微软需要有不同的产品以分别面对家庭应用环境和强健的、基于关键业务的商业平台。

(6)强力宣传与培训

许多银行对.Net平台在企业应用上的技术一概无知，这种对.Net平台认知的匮乏延伸到了培训领域。一些金融机构抱怨微软从来没有提供过如何利用.Net架构满足业务需求的培训。如果这种抱怨是真实的，那么微软也许只剩下对金融应用说“拜拜”的机会了。

鉴于这种来自用户的抱怨，微软需要在金融行业提供与其他竞争对手同样的培训。

(7)不要单纯的只提.Net技术

总之，微软应该认识到那些试图购买.Net平台的技术专家都是些老谋深算的高手，如果微软一味的单纯化.Net技术，则会让这些“高手”们感觉这简直就是一个别具一格的玩具，从而对.Net技术构建强大解决方案的能力表示怀疑。

每当那些满脑子都是SOA的架构师们在回答关于.Net平台是否适合他们的应用需求时，总是这么回答：“哦，用到了，因为.Net已经被嵌入在微软的产品中了”。

在较早的调查中，我们看到J2EE受欢迎的一个原因就是它的弹性。如果.Net需要在金融领域取得同样的成功，势必需要和它的竞争对手一样的增强弹性和可配置特性。

(8)J2EE需要简化

当.Net这匹黑马开始活跃在企业级应用，并且愈来愈让决策者们刮目相看的时候，迫使J2EE平台必须在既有的高端应用上有所作为。

Sun公司正在努力的简化J2EE开发规范，使得Java开发者们也享有.Net开发者的快捷和愉悦。一个典型的例子是Java Studio Creator的出现，它允许开发者们采用Drag & Drop的方式拖放组件以产生一个Web应用系统。开源组织也在极力的考虑如何简化J2EE的开发，使得采用J2EE的开发能够更加快速和廉价。

另外，被移植到Java虚拟机上的程序语言的数量也在增加，现在不仅仅是Java语言才能运行在JVM上了。所以.Net在这方面的优势开始削弱。

总结

.Net vs. J2EE不再显得那么不可琢磨，今天的IT执行官们已经能够使用更客观的标准来决定使用那一种平台，以及在什么时候使用它。尤其在SOA的时代，技术架构师们常常乐于接受这两个平台的并存，并且采用Web Service互联互通。

今天，.Net技术愈来愈占据了显著的地位。虽然在成熟度等优势上与J2EE还有一段距离，不过微软可以采取策略迅速弥补这个鸿沟。

J2EE也有机会“跟上”.Net平台易用和高效的步伐，J2EE的信徒们正在努力。

微软在高端市场的受挫，不是因为技术，而是因为其一贯的市场策略，因为.Net本身就是企业级的平台技术。

最终，.Net和J2EE技术都在朝着相互融合的态势发展，Web Service、SOA、开发速度、更低的成本和柔性是它们必然的选择。

将来，在这场竞争中幸免遇难的唯一途径是：基于SOA的“.Net 与 J2EE”————而不是“.Net vs. J2EE”。

分享：ASP.NET 2.0高级数据处理之数据绑定
在前面的"模板中的数据绑定"部分中我们论述过，ASP.NET包含了一种宣告式的数据绑定语法，用于在数据绑定模板中把数据源字段与控件的属性相关联。你也可以在代码中使用＜%# ... ＞语法