J2EE体系结构

核心提示：与.NET平台相比，Sun公司的标准定义的J2EE体系结构有很少可以讨论的空间，J2EE体系结构，因为就没有什么可讨论的，假如一个人注重某个具体开发商的产品，Java消息服务) 1.0 – 是用于异步工作流的Java API ，这在功能上与Microsoft Message Queue API相当，如IBM公司的Web

　　与.NET平台相比，Sun公司的标准定义的J2EE体系结构有很少可以讨论的空间，因为就没有什么可讨论的。假如一个人注重某个具体开发商的产品，如IBM公司的WebSphere，那么就会看到其技术的最大的一部分是WebSphere专用的。比较所有开发商对J2EE的具体改进，已经超出了本文的范围，在我的经验中，大多数对J2EE作为一个平台感爱好的公司对该标准的可移值性感爱好。任何对可移值性感爱好的人都会需要将他们自己局限于Sun公司所定义的标准。
　　J2EE体系结构可以被分为5部分：
　　
　　· java语言系统
　　
　　· 客户端程序设计模型
　　
　　· 中间层基础结构
　　
　　· 程序员企业级API
　　
　　· 非程序员可见API
　　
　　最后一部分，非程序员可见API，包括定义了如何将其他产品插入到J2EE中的API，如连接器API，以及J2EE模型中被最近的改进有效替代的API，如JTA（Java Transaction API）。由于从比较微软和Sun公司计划的角度来说，非程序员可见API并不重要，因此在笔者的概述中将不涉及这些方面 (就如同笔者在.NET平台概述中并没有涉及功能相当的API一样)。
　　
　　Java语言系统
　　
　　在高层次上，Java语言系统看起来与.NET Framework类似。在这两种情况中，源代码都是被翻译成一种中间语言。但是，在.NET平台中，这种中间语言是MSIL，而在Java系统中，是Java Byte Code。在这两种情况中，中间语言被带入到运行环境中。在Framework中，运行环境是Common Language Runtime。对于Java，运行环境是Java虚拟机（Java Virtual Machine）。总体而言，Common Language Runtime和Java虚拟机有类似的功能，并且在技术进步方面，都无可置疑地在发展和彼此交互跃进。
　　
　　这两种系统之间最重要的区别与源代码到中间语言的翻译有关。在.NET平台中，中间语言设计用来适应各种语言的需求。在Java中，中间语言设计用来满足Java的需求。虽然从理论上，从除Java外的语言生成Java Byte Code是可能的，但是实际上这还没有在任何一种商业产品中证实。
　　
　　客户端程序设计模型
　　
　　J2EE客户端程序设计模型重点集中在与浏览器的交互上。客户端程序设计模型有3部分：Java Applets，Java Servlets和Java Server Pages。
　　
　　Java Applets用来对在浏览器内运行的Java代码进行打包。在.NET平台空间中，这在功能上与ActiveX相当。在笔者的经验中，applets或ActiveX组件使用的相对较少。电子商务体系结构一般都是以向表示层发出请求的浏览器为基础，然后表示层使用Html页面进行响应。这种系统并没有使用ActiveX或Java Applets，因此笔者在本白皮书中并没有讨论这些技术的任何一种。
　　
　　处理HTTP请求和HTML响应的重要技术是Java Servlets 和Java Server Pages 。这两种技术与微软空间中的asp.net（Active Server Pages）类似。
　　
　　.NET平台与Java表示层中间的主要区别在于处理不同的客户端功能的方式。Java表示层沿用了以前的Microsoft ASP (PRe .NET)模型，它使得表示层程序员的责任是决定最终的目的浏览器（或其他瘦客户端系统），瘦客户端系统的功能，以及如何生成HTML来充分发挥瘦客户端系统的优势。
　　
　　中间层基础结构
　　
　　对于J2EE，中间层基础结构是Enterprise Java Beans (EJB)。该规范的当前版本是2.0，可以从网上获得 。与J2EE相当的.NET平台是COM+。
　　
　　在EJB和COM+之间，体系结构的差别非常少。这两种体系结构本质上是从MTS（Microsoft Transaction Server）派生出来的，是由微软公司在1996年引入的最初的面向组件的中间层基础结构。由MTS最先引入，然后合并到EJB和COM+中的重要想法包括：
　　
　　· 通过组件示例的共享所实现的高可伸缩性
　　
　　· 以中间层为中心的安全性
　　
　　· 自动事务处理边界治理
　　
　　EJB加入了一种新的体系结构想法，一项自动治理组件状态的技术。这项技术被称为entity beans（实体豆）。虽然这种想法具有吸引力，但是当前的实施却依靠于独立于数据库缓存的中间层数据缓存。很不幸的是，在这两种缓存之间没有保持一致性的机制。这意味着对实体豆的任何使用都会带来数据库损坏的高风险。在缓存一致性问题解决之前，在最佳试验技术方面，必须得不断考虑实体豆技术。
　　
　　要连接EJB和COM+的深入比较，请参阅笔者最近的著作 。
　　
　　程序员企业级API
　　
　　我们调用Java Enterprise API 时的最重要部分如下：
　　
　　· Java Database Connection (JDBC，Java数据库连接) 2.0 – 是用于从Java中访问关系型数据库的API 。这与.NET平台空间中的ADO.NET相当。
　　
　　· Java Naming and Directory Interface (JNDI，Java命名与目录接口) – 是用于从Java中访问企业名称与目录服务的信息的API 。这与.NET平台空间中的Active Directory Services Interface (ADSI，活动目录服务接口)有点类似。
　　
　　· Java Message Service (JMS，Java消息服务) 1.0 – 是用于异步工作流的Java API 。这在功能上与Microsoft Message Queue API相当，这个API已经被排队组件所替代。