J2EE开发人员所需掌握的技术列表是相当冗长的。在这篇文章里，我们不会讨论J2EE技术，甚至也不会讨论新技术。我们将要探讨的是它的一些主要的新特性，然后您就会知道要在J2EE项目中使用哪些特性。
J2EE 1.4带来了一些新的且很有趣的特性。他们始终围绕着三个主要的主题：Web 服务、消息传递和较容易的Web开发。要满足这些主题的需要，组成J2EE的所有主要规范都得到升级--大多数规范都很重要。最主要的（也是最多的）升级是JCA 1.5规范和JSP 2.0规范以及J2EE规范本身。此外，还有一些规范也是新的（或者对J2EE来说是新的）--例如：JAX-RPC、Web 服务以及J2EE部署和管理规范。
新规范
在J2EE 1.4中包含了一些新的规范和技术。总体来说，在对J2EE最重要的扩充内容中，绝大部分是用于支持Web 服务或XML的。其中最重要的几个是：
Web services for J2EE (JSR-109)
这个新的规范描述了Web 服务怎样作为servlet或EJB无状态会话Bean来部署。最引人注目的变化是增加了新的部署描述符，这种描述符将支持把组件作为Web 服务来部署。
JAX-RPC 1.1
JAX-RPC是用于使用SOAP进行远程过程调用的Java API。使用这些API，就可以用远程对象调用Web服务。在J2EE中使用JAX-RPC的方式和调用远程EJB非常相似。
JAX-RPC规范也定义了一个Web服务（通过其WSDL）映射到Java接口的方式。JAX-RPC的实现还包括一些工具，用于从WSDL生成接口、存根等等，或者从接口生成WSDL。
J2EE 在 Web 服务的服务器端和客户端都使用了JAX-RPC。在J2EE中实现的Web服务（作为servlet 或者 EJB）将会用到JAX-RPC 接口。而如果一个组件要远程调用Web服务，它就会把JAX-RPC用作远程接口。
SAAJ 1.2
SAAJ是SOAP with attachments API for Java（用于Java的带有附件API的SOAP），它允许那些在SOAP调用中传递的附件可以被Java访问。
JAXR
JAXR是用于XML注册表的Java API，这些API 用来访问Web 服务注册表，比如 UDDI、ebXML和OASIS。很不幸，J2EE不要求支持任一特定注册表，但可用使用API且实现该API。
XML支持
现在J2EE 1.4规范要求支持SAX 2、DOM level 2、XML架构和命名空间，还要求支持XSLT。如果您正在编写操纵XML的J2EE应用程序，则您现在必须支持最新的版本才能工作。
J2EE管理和部署API（JSR-77和JSR-88）
这两种API被工具和IDE供应商所关注。它们提供了一套供应商无关的API，用来控制J2EE应用服务器上的管理和部署活动。这使得IDE（或我们自己开发的工具）可以很轻松地同各种各样的应用服务器交互，而无需使用特定于供应商的大量API。
规范的变化
J2EE所包含的所有规范在J2EE 1.4中都不同程度上有了些变化。但有些变化很微小，但是J2EE的"四大件"（EJB、JCA、servlets和JSP）都增加了重要的的新特性。
下面对其中最重要的变化进行介绍：
Enterprise Java Beans 2.1
EJB 2.1规范的改进主要在于Web服务和消息传递。这将在下面详细说明。不过EJB 2.1还增加了计时器服务并增强了容器管理的实体bean的EJB-QL查询语言。
新的计时器服务允许任何EJB（除了有状态的会话bean）进行注册，以获得来自容器的基于时间的回调功能。EJB能够请求一个特定时间后（如10秒钟）的单个回调信号，或者也可以安排定期（如每10分钟）回调。这个特性在有些情况下会很有帮助，但是同时也存在着被大大误用的潜在可能--这只能让时间来告诉我们答案了。
对EJB-QL的增强是操作符ORDER BY、SUM、COUNT、AVG、MAX、MIN和MOD。大多数的应用服务器在他们的特定于提供商的扩展中都会提供这些操作符。而现在，他们最终被写入了规范。
Enterprise Java Beans 2.1--Web服务端点
对Web服务来说，EJB 已经加入了把无状态会话 bean 作为Web服务来使用的能力。这种能力可以被用来实现新的Web服务或者通过Web服务接口把先有的EJB公布出去。
把一个现有的无状态会话bean转化成一个Web服务端点是相对容易的。从远程接口生成WSDL（使用JAX-RPC工具），然后在ejb-jar.xml文件中加入一个service-endpoint元素。这个service-endpoint元素无论看起来还是用起来都像是访问您的EJB的另一个接口--这样您的EJB 现在就拥有了全部或部分的远程的、本地的和Web服务端点的接口。接着，添加一个部署描述符webservices.xml，文件中包含service-impl-bean 和ejb-link两个元素。这样就把WSDL连接到了EJB上并通知应用服务器通过Web容器把它公布出去。
同样，可以把现存的Web服务作为无状态会话 bean来实现，除非您使用JAX-RPC工具从WSDL来生成接口。
Enterprise Java Beans 2.1--Web 服务客户端
EJB 2.1规范现在明确允许任何一个EJB可以成为某个Web服务的客户端（通过JAX-RPC接口）。调用Web服务和调用另外一个EJB的方式极其相似。使用部署描述符中的service-ref元素，Web服务会被映射，这样您可以使用"java:comp/env/"的名字在JNNI中查询这个服务。
顺便说明，这一技术不仅在EJB中可以使用，而且可以在任何J2EE组件中使用--所以，您还可以在servlets 或者JCA适配器中来调用Web服务。
Enterprise Java Beans 2.1--消息传递
EJB对消息传递的改进是和Java Connector Architecture紧密联系在一起的。EJB 2.1规范改进了消息驱动的bean（MDB：message-driven bean），使之允许任意的（非JMS）消息类型。同样，一个消息连接工具也被添加到部署描述符中，用来指定组件发送消息的MBD或JMS目的地（这和ejb-ref允许您把EJB"勾"在一起的方式是很相似的）。
J2EE Connector Architecture 1.5
JCA 1.5规范有了很大的变化。JCA 1.5的新变化是入站源适配器，它允许一个外部服务（如一个EIS系统）给应用服务器发送消息。所以说JCA现在变成了双向的。伴随它的是一个消息连接工具，该工具把入站适配器和处理这个消息的MDB连接起来。在这里这个主要用例是和消息驱动的bean（MDB）联系在一起的，入站适配器接收信息，处理信息生成消息，再把消息进行排队以供MDB进行处理。这一特性的关键就在于MDB的变化使用非JMS的消息类型。
JCA其他方面的改进包括对管理所有实现异步入站适配器所需线程的工作管理系统的改进。工作管理器允许JCA使用线程，但不会与其线程的应用程序管理发生冲突。
Servlet 2.4
Servlet 2.4规范中Web服务方面的变化主要在于把JAX-RPC类作为servlet部署来实现Web服务端点的能力。这给实现Web服务提供了一种容易的方式。
编写一个基于servlet的Web服务端点和创建一个基于EJB的端点几乎毫无二致。使用JAX-RPC工具从WSDL创建接口（或者是从接口创建WSDL），再在一个普通的JAVA类中实现这个接口。然后用servlet元素（但不使用servlet-mapping）在web.xml中声明这个类，再创建一个包含service-impl-bean和servlet-link元素的webservices.xml描述符文件。
Servlet 2.4也增加了listener来取得属性（这就像现有的已经可用的会话属性监听器）。
SingleThreadModel也不赞成使用了。如果您用过这个接口，您一定已经知道实际上它并不能真正地解决Serverlet的实时并发问题。SingleThreadModel只能保护单进程Serverlet的域和方法，但是，毫无疑问，它没有保护其他资源的能力（像那些静态方法中的引用，或者HttpSession中的对象）。因此，SingleThreadModel将不赞成使用，同时必将会被一种好的、线程安全的编程实践所替代。
Java Server Pages 2.0
JSP规范终于成熟了。在JSP 2.0中，终于可以编写无脚本的页面（没有任何"<% … %>"之类属于Java的代码）。
第一个改进就是增加了表达式语言（expression language，EL），表达式语言来源于JSP标准标记库(JavaServer Pages Standard Tag Library，JSTL)。EL是一种简单、精致和易用的语法，这种语法不再需要大部分的 "scriptlet"。EL是基于ECMAScript (JavaScript) 和XPath的，所以，它的语法对于大多数Web开发者来说都会感觉似曾相识。
在JSP 2.0中也一样改进了标记库。现如今，我们有更简单的API来书写标记了。SimpleTag接口具拥有更简单简洁的生命周期--只有一个doTag 方法并且没有实例缓冲池和重用。SimpleTag和它的JSPFragment搭档（用来评估标记体）可以完成现如今大多数 "classic tags" 所做的事情，不过和以前相比，可要省力气多了。此外，这些更为简单的API意味着标记可以更容易地正确实现，这也就意味着bug更少。
另外一个对标记的改进在于编写标记文件的能力。这些标记是作为JSP文件而不是Java类来实现的。编写标记文件是简单的，而部署就更简单了--您只要简单的把这些文件以类似foo.tag的名字放入WEB-INF/tags就万事大吉了。不需要编写TLD描述符文件，因为所有的重要信息都在标记文件其自身中进行了声明。
标记文件最大的优势是在一些可视HTML元素需要标记之时。例如，对持续格式化bean的输出。以前，必须把HTML嵌入到Java代码或采取包含页面的方式。但是标记文件是这种类型的功能最自然的用法。这也向那些非Java开发者打开了自制创建标记的大门。 JSP 2.0 还改进了用于支持XML的语法，加入了对JSR-45的支持，以及对其他语言的调试支持。
JSTL
JSP标准标记库（JavaServer Pages Standard Tag Library，JSTL）是一个非常有用的标记的集合。这些标记和JSP2.0在其他方面的改进很好的融合了起来。不幸的是，JSTL并不是JSP 2.0规范的必需组成部分。不过，由于它是如此得有用，而且获得了广泛的支持（例如从Sun 到 Apache），实在值得我们在此提及一下。
总结
在新的版本中充满了新的内容，那么问题是如何来使用他们呢？
Web 开发
JSP规范的所有这些改变都极大地改进了Web开发体验。大家终于有可能编写不内嵌Java代码的JSP页面了。并且，简单标记和标记文件的可选性使标记变得更易编写且更易使用。在用户界面（视图）和后端（控制器）之间的分离也更好了。
消息传递
消息传递在MDB 和JCA方面的改进有很多意义。首先，显而易见的是--应用服务器和EIS之间的双向通讯会增进J2EE与现有企业的集成。
但是其他的好处还远远不止这些。首先，除了那些被容器（RMI、IIOP和HTTP）所拥有的socket外，入站适配器有"权"创建和监听socket。所以，比如说，您可以添加一个JCA适配器来使您能telnet到应用服务器来执行一些管理任务。或者，也可以将FTP服务器部署为标准的J2EE JCA组件，也可以实现邮件服务器。这种可能性是无穷尽的。
另外一种可能性（这在规范中已有明确说明）是JMS提供者。J2EE规范要求应用服务器必须实现JMS--但并没有指明对特定消息传递系统的任何要求。因此，每个消息提供商通常要实现他们自己的消息系统来支持JMS。并且，他们通常必须有外部系统与他们一同工作才能进行通讯。
有了J2EE 1.4，消息提供商现在已经有可能创建自制他们的JMS支持，像一个符合J2EE的标准、可移植的JCA适配器一样。适配器的入站一端可以处理消息使用者，而出站一端处理发布者。然后，这个JCA能够被部署到任何J2EE 1.4应用服务器中。这样就使其拥有了改进应用服务器之间的互操作性的潜在能力，至少对于JMS消息是这样的。
Web 服务
有了J2EE 1.4规范，J2EE已经和Web服务稳固的结合在了一起。这就有了多种选择。
首先，如果您有现有的基于EJB的系统，则只要简单地在部署描述符中添加JAC接口以及一些条目，任何无状态会话bean都可以当作Web服务来发布。这就打开了现有部署和Web服务的互操作性。
对于新的Web服务，您可以像上面一样编写EJB的实现，也可以编写简单的Java类（使用JAX-RPC）。不管采用哪种方式，您都可以通过一些部署描述符条目进行部署。
此外，您还可以利用J2EE应用程序中的任何Web服务，方法是，在执行任何其他远程调用时，使用JAX-RPC来调用Web服务。
结束语
对J2EE 1.4的增强都是不容置疑的，并且应增强J2EE平台的有用性和能力。JCA和MDB方面的改进用来增强企业后端。增加对Web服务的支持改进了J2EE的有用性和互操作性。而对于那些希望开发基于Web的用户接口的人员来说，JSP的改进则降低了他们使用的门槛。总之，这是一个很棒的组合。
现在，最困难的事情摆在了您--J2EE开发者--的面前，您需要判定，如何来在您的项目中对所有这些好东西加以选择取舍。这将是件乐趣无穷的事情。
本文地址：http://com.8s8s.com/it/it15739.htm