开发学院软件开发 Java J2ee与ASP.NET平台电子企业的两种构想(4) 阅读

J2ee与ASP.NET平台电子企业的两种构想(4)

　2007-12-23 12:38:57　来源：WEB开发网　　　

核心提示：J2EE体系结构与.NET平台相比，Sun公司的标准定义的J2EE体系结构有很少可以讨论的空间，J2ee与ASP.NET平台电子企业的两种构想(4)，因为就没有什么可讨论的，如果一个人注意某个具体开发商的产品，John Wiley and Sons2000年1月发行[5] 说明书可以在http://java.sun.c

J2EE体系结构

与.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[1]和Java Server Pages[2]。这两种技术与微软空间中的asp.net（Active Server Pages）类似。

.NET平台与Java表示层中间的主要区别在于处理不同的客户端功能的方式。Java表示层沿用了以前的Microsoft ASP (PRe .NET)模型，它使得表示层程序员的责任是决定最终的目的浏览器（或其他瘦客户端系统），瘦客户端系统的功能，以及如何生成HTML来充分发挥瘦客户端系统的优势。

中间层基础结构

对于J2EE，中间层基础结构是Enterprise Java Beans (EJB)。该规范的当前版本是2.0，可以从网上获得[3]。与J2EE相当的.NET平台是COM+。

在EJB和COM+之间，体系结构的差别非常少。这两种体系结构本质上是从MTS（Microsoft Transaction Server）派生出来的，是由微软公司在1996年引入的最初的面向组件的中间层基础结构。由MTS最先引入，然后合并到EJB和COM+中的重要想法包括：

通过组件示例的共享所实现的高可伸缩性
以中间层为中心的安全性
自动事务处理边界管理

EJB加入了一种新的体系结构想法，一项自动管理组件状态的技术。这项技术被称为entity beans（实体豆）。虽然这种想法具有吸引力，但是当前的实施却依赖于独立于数据库缓存的中间层数据缓存。很不幸的是，在这两种缓存之间没有保持一致性的机制。这意味着对实体豆的任何使用都会带来数据库损坏的高风险。在缓存一致性问题解决之前，在最佳试验技术方面，必须得不断考虑实体豆技术。

要连接EJB和COM+的深入比较，请参阅笔者最近的著作[4]。

程序员企业级API

我们调用Java Enterprise API 时的最重要部分如下：

Java Database Connection (JDBC，Java数据库连接) 2.0 ? 是用于从Java中访问关系型数据库的API[5]。这与.NET平台空间中的ADO.NET相当。
Java Naming and Directory Interface (JNDI，Java命名与目录接口) ? 是用于从Java中访问企业名称与目录服务的信息的API[6]。这与.NET平台空间中的Active Directory Services Interface (ADSI，活动目录服务接口)有点类似。
Java Message Service (JMS，Java消息服务) 1.0 ? 是用于异步工作流的Java API[7]。这在功能上与Microsoft Message Queue API相当，这个API已经被排队组件所替代。