在大多数情况下，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 服务器是昂贵的和重量级的，并且由于我们不需要像持久性、分布式、事 务和验证这样更重量级的功能，构建自己内存中的消息层，只提供所需要的功能 会更容易。
虽然这在一般情况下是正确的，但是应用程序需求通常会随着时间而增加， 在开始时不需要的一些消息功能在以后可能会变得更重要了。
面向消息的应用程序的开发人员在开发过程的初期就必须做出选择--选择一 个商业消息产品，或者构建自己的更便宜的、更轻量级的解决方案。Somnifugi JMS 包结合了这两种方式--一个基于高性能的 util.concurrent 库的非持久内 存中消息队列服务，和一个符合 JMS API 的接口。与传统 JMS 提供者相比较， Somnifugi 是相当轻量级的，不管是功能上还是性能上。它只限于在一个 JVM 中使用（尽管可以取消这种限制），并缺少持久性、事务和验证功能。另一方面 ，它特别快--它比传统 JMS 实现快得多，以至于可以在因性能原因可能无法使 用消息的地方使用它。为了表明 Somnifugi 到底有多轻量级，在它的分发中包 含了几个用 JMS 主题取代 Swing/JavaBean 事件框架的例子。
增加的灵活性
Somnifugi 还提供了另一项重要的优点：现在可以开发使用 JMS 接口的组件 ，然后在部署应用程序时决定是使用更快的、内存中的 Somnifugi 提供者还是 更重量级的、但是更可靠的提供者，如 WebSphere MQ。可以将这种选择推迟到 部署时的好处非常巨大--特别是因为需求可能会在项目的开发过程中变化时--并 提供了代码重用的机会，对于自已开发的消息层来说这是不太可能做到的。