Java理论与实践: 让J2EE脱离容器 - 编程入门网

Java理论与实践: 让J2EE脱离容器

在大多数情况下，Java 应用程序要么是 J2EE 应用程序、要么是 J2SE 应用 程序，并且在这一点上是泾渭分明的。J2EE 应用程序需要 J2EE 容器的服务， 容器要实现一长串的 J2EE API，包括 Enterprise JavaBean (EJB)、JTA、JNDI 、JMS、JCA 和 JMX。J2EE API 设计为协同工作；毕竟，J2EE 设计是从多年来 数百人开发企业应用程序的经验中提取出的公共需求。像所有框架一样，J2EE API 的主要目的是“不重新发明轮子”。

有一些 API 属于 J2EE 规范的一部分，但是可以很容易地在 J2SE 应用程序 中使用，如 JDBC、JSP 和 servlet，但是对于大多数 J2EE API，J2EE 是一个 要么是要么不是的命题--大多数 J2EE API 需要全功能的 J2EE 容器。不过，有 一些服务器应用程序开发为 J2SE 应用程序而非 J2EE 应用程序，这通常都有很 好的理由。为什么这些应用程序的开发人员必须重新发明轮子呢？J2EE 中是否 有部分内容可以容易地被 J2SE 应用程序借用来提供同样的优点呢？什么组件可 以同时用于 J2EE 和 J2SE 应用程序的组件呢?

松散耦合

J2EE 的一个主要设计原理是 J2EE 应用程序可以松散地耦合--用组件组装， 在组装或者部署应用程序时而不是在组件开发时定义或者改变这些组件的相互连 接。J2EE 组件使用 JNDI 相互查找和查找所需要的资源，如 JDBC 和 JMS 连接 。JMS 这样的技术鼓励松散耦合，允许灵活地为工作流程建模、容易分配处理任 务、可伸缩性和容错性。很多 J2SE 服务器应用程序也可以从这些技术和原理中 受益。

像 JDBC、JMS 和 JNDI 这样的 API 基本上是“中间件”--它们作为应用程 序与不同的服务提供者之间的统一接口。几乎每一个数据库服务器都有 JDBC 驱 动程序，有大量的免费数据库服务器，所以几乎每一个希望利用数据库的 Java 应用程序都可以容易地做到这一点。不过，对于 JMS 就不是这样了。消息队列 服务器远没有数据库这样常见，特别是在小型商店中。但是有大量的应用程序可 以通过使用消息队列而极大地受益。

Somnifugi JMS

消息队列是一个功能强大的范例，它用于构建健壮的、灵活的、松散耦合的 、可伸缩的应用程序。有一些商业消息队列产品，如 WebSphere MQ、Sonic、 Fiorano、JBossMQ 和 SpiritWave。就像 JDBC 对于数据库一样，JMS 是消息的 中间件--它使得应用程序可以通过统一的接口访问不同的消息队列产品，这个接 口提供了像 Connection 、 Topic 和 Message 这样的抽象。

许多 J2SE 应用程序使用某种形式的消息队列，但是不使用 JMS--而是使用 线程池、工作队列、任务管理器等。AWT 和 Swing 框架使用消息（事件）在模 型与视图层之间通信，JavaBean 组件利用监听器支持一种基于主题的消息。消 息队列提供了很多结构上的优点--它固有的松散耦合有利于采用灵活的、基于组 件的方法，并提供了有助于简化设计和减少互连的天然抽象边界。一个附带的好 处是，MQ 范例使得分布式的、可伸缩的和容错的设计变得更容易了，因为消息 生产者和使用者不一定需要运行在同一 JVM 中，大多数生产者/使用者任务的本 性是允许并发处理的。

J2SE 服务器应用程序的开发人员经常开发他们自己的消息层，或者从零开始 ，或者以 util.concurrent 这样的库为基础构建。通常这么做的理由是：

MQ 服务器是昂贵的和重量级的，并且由于我们不需要像持久性、分布式、事 务和验证这样更重量级的功能，构建自己内存中的消息层，只提供所需要的功能 会更容易。

虽然这在一般情况下是正确的，但是应用程序需求通常会随着时间而增加， 在开始时不需要的一些消息功能在以后可能会变得更重要了。

面向消息的应用程序的开发人员在开发过程的初

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!