jms 概序和接口与抽象

本文探讨了消息传递系统在构建分布式应用中的作用,重点介绍了Java消息服务(JMS)及其特性和使用方法,包括消息类型、发布/订阅模型、点对点模型等内容。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

消息传递系统用于构建高可靠、可伸缩及灵活的分布式应用程序。本文从大体上讨论了消息传递系统,简要叙述了它们的特性及类型,然后描述开发人员如何可以使用 Java 消息服务(Java Message Service ,JMS) 编写基于消息的应用程序。

正如许多以前在同步、可靠性、可伸缩性和安全性方面的未知问题一样,分布式应用程序潜在的问题也是不断增长的。一种解决方案是建立在松散耦合组件基础上的消息传递系统,这些组件之间通过消息进行通信。

Java 消息服务提供了一致的 API 集合,让开发人员可以访问许多消息传递系统产品的公共特性。

什么是消息传递系统?
从它的本质上讲,消息传递系统允许不同的非耦合应用程序以异步方式进行可靠通信。消息传递系统体系结构一般用各个组件间的点对点关系代替客户端/服务器模型,其中每个点可以发送消息到其他点,或从其他点接收消息。

相对于更加传统的分布式计算模型,消息传递系统提供了许多强大的优势。首先,它们倡议在消息消费者和消息生产者之间进行“松散耦合”。在生产者和消费者之间存在着高级匿名:对于消息消费者,它不关心 谁 产生消息,在网络上生产者在 哪里,或者消息是 何时 产生的。

这使得可以构建动态、可靠和灵活的系统,由此可以修改子应用程序的整体组合,而不会影响到系统的其余部分。 消息传递系统的其他优势包括高可伸缩性(商业实现鼓吹可以支持好几万个客户端,以及支持每秒进行好几万个操作)、容易集成到异构网络以及由于减少了单点故障而提高了可靠性。

由于消息传递系统固有的可靠性和可伸缩性,所以它们用于解决许多商业和计算科学问题。例如,它们是这样的一些不同的应用程序的基础:工作流、网络管理、通信服务(通过 IP 的语音、有声邮件、寻呼机和电子邮件)、客户服务、天气预报和供应链管理等系统。此外,消息传递系统是无价的,因为它作为“glue”(胶水)把完全不同的系统联系在一起,使之能够合并和获取消息。

消息系统类型
通常使用两种消息传递系统模型。

发布/订阅
发布/订阅 (pub/sub) 消息传递系统支持事件驱动模型,在这种模型中,信息消费者和生产者参与消息的传输。生产者“发布”事件,而消费者“订阅”感兴趣的事件并消费事件。生产者把消息把与特定主题关联起来,然后消息传递系统根据消费者所注册的感兴趣主题,把消息路由给消费者。

点对点
在点对点消息传递系统中,消息是被路由到各个消费者的,该消费者维护“传入”消息队列。消息传递应用程序发送消息到指定队列,然后客户端从队列中检索消息。 供应商经常会支持点对点模型或发布/订阅消息传递模型,或者同时支持这两种模型。

既然已经从大体上认识了消息系统,现在让我们来看一下 Java 开发人员是如何可以利用它们的能力的。

Java 消息服务
Java 消息服务是 J2EE (Java 2 Enterprise Edition) 套件的一部分,它提供了标准 API,Java 开发人员可以使用这些 API 来访问企业消息系统的共同特性。JMS 支持发布/订阅和点对点模型,并允许创建由任意 Java 对象组成的消息类型。

设计目标
JMS 的基本设计目标是为了提供一组一致的接口,消息传递系统客户端可以独立地使用这些接口,而不必关心基础消息系统的提供商。 这样,客户端应用程序不仅可以跨计算机体系结构和操作系统进行移植,而且也可以跨消息传递产品进行移植。写到 JMS 的客户端应用程序将正常工作,而不用在所有符合 JMS 的消息传递系统上做修改(这可以与组件所运行的基础中间件上的 Enterprise Java Beans 组件的独立性进行比较)。

JMS 也设计成:

最小化消息传递系统提供商为其产品实现 JMS API 所需的工作量。
提供了普通消息传递系统的大多数功能。
许多消息系统提供商已经为它们的产品实现了 JMS,允许 Java 访问它们系统的功能。

JMS 客户端可以使用 Java 设施
由于 JMS 客户端是基于 Java 的,因此它们可以利用现有的 Java API,比如:用于数据库访问的 JDBC、JavaBeans 组件模型、用于命名服务的 JNDI、用于客户端事务控制的 JTA 或用于企业应用程序服务的任何 J2SE 和 J2EE API。

JMS 细节
现在,我们从消息开始,来看一下使用 JMS 构建消息传递系统客户端的细节。

什么是消息?
在消息传递系统中,应用程序之间的通信点是消息本身,因此使用 JMS 的开发人员必须理解消息。

尽管消息传递系统之间消息定义区别甚大,但 JMS 提供了统一的方式用于描述和访问消息。JMS 消息由三部分组成:

消息标题
用于消息标识。例如,标题用于确定指定的消息是否适合于“订阅者”。
属性
用于特定于应用程序、特定于提供商及可选的标题字段。
消息体
保存消息的内容。支持几种格式,其中包括:TextMessages——用于包装简单的 String; 和 ObjectMessages——用于包装任意的 Java 对象(它们必须是可序列化的)。也支持其他的格式。
TextMessages
TextMessage 用于包装简单的 String 对象。在只传递字符串的情形下,这是有用的。期望许多消息传递系统将以 XML 为基础,TextMessages 是它们的自然容器。

创建 TextMessage 对象是简单的,如下面两行代码所指出的那样:

TextMessage message =
session.createMessage();
message.setText("hello world");

(在下一节,我们将看到 session 对象)。

以这种方式创建的 TextMessage 准备发布到消息传递系统中。

ObjectMessages
顾名思义,ObjectMessage 是包装了 Java 对象的消息。任何可序列化的 Java 对象均可用作 ObjectMessage。如果多个对象必须在单个消息中传输,那么可以使用包含几个可序列化对象的 Collection 对象(比如 List 或 Set)。

下面展示了如何创建 Object 消息:

ObjectMessage message = session.createObjectMessage();
message.setObject(myObject);

关于 JNDI
像许多 J2EE API 一样,JMS 利用了 JNDI(Java 命名和目录接口)来发现所需资源。详细讨论 JNDI 超出了本文的范围,但可从如下地址找到更多的进一步信息:Java 命名和目录接口 (JNDI)。

构建 JMS 客户端
可以遵循下面的基本步骤来构建典型的 JMS 客户端:

创建到消息传递系统提供商的连接。
创建会话用于发送和接收消息。
创建 MessageProducers 和 MessageConsumers 来创建或接收消息。
一旦这些步骤执行完毕,消息生产的客户端将创建消息,并把它们发布到主题,而消息消费的客户端将侦听与主题有关的消息,并在它们到达时消费它们。

为了详细展示它是如何工作的,我们研究了典型的消息生产者,它用于在 pub/sub 消息传递系统中把消息发布到特定的主题。注意,为简洁起见,省略了所有异常处理代码。

创建连接
连接为客户端提供了对基础消息传递系统的访问,并执行资源分配和管理。连接是使用 ConnectionFactory 创建的,而 ConnectionFactory 通常是使用 JNDI 查找的。

下面这些代码展示了创建连接过程中涉及的一些步骤:

Context messaging = new InitialContext();
// get JNDI context
TopicConnectionFactory topicConnectionFactory =
(TopicConnectionFactory)
messaging.lookup("TopicConnectionFactory");
TopicConnection topicConnection =
topicConnectionFactory.createTopicConnection();


创建会话
会话是轻量级 JMS 对象,它提供了用于生产和消费消息的上下文。会话用于生成消息生产者和消息消费者,以及用于生成消息本身。

TopicSession session =
topicConnection.createTopicSession(false,
Session.CLIENT_ACKNOWLEDGE);

createTopicSession() 的两个参数控制事务和消息的确认。

查找主题
主题(也称标题、组或频道)是通过 JNDI 来查找的。主题标识了发送中或接收中的消息。在发布/阅系统中,订阅者订阅了指定的主题,而发布者把主题与它们发布的消息关联。

这里我们创建了一个称为“WeatherData”的主题。

Topic weatherTopic = messaging.lookup("WeatherData");

启动连接
在上面的初始化过程中,为了防止初始化期间出现不可预知的行为,消息流是被禁止的。一旦初始化完成,必须告诉连接开始消息流。

topicConnection.start();

创建消息生产者
在发布/订阅领域中,生产者把消息发布到指定主题。下面代码展示了发布者的创建及后续的简单文本消息的生成和发布。

TopicPublisher publisher =
session.createPublisher(weatherData);
TextMessage message = session.createMessage();
message.setText("temperature: 35 degrees");

publisher.publish(message);


创建订阅者及点对点系统的 JMS 客户端遵循相似的过程。可以在 [1] 中找到这一过程的完整细节。

结束语
我们已经看到在使用 JMS 来构建基于消息传递的应用程序的过程中涉及的基本概念。在编写 JMS 代码之前,你将需要访问符合 JMS 的消息传递系统。可从如下地址获取符合 JMS 的供应商的列表:

JMS 供应商


创建和构建基于 JMS 的应用程序是简单的,可是它为构建强大、可伸缩和高可靠的分布式系统提供了基础。

注意,JMS 远远比本文讨论的要复杂,并为下面的这些提供了支持:管理、安全、错误处理和恢复、优化、分布式事务、消息排序和消息确认等。

有关 Java Message Service 的进一步信息和文档,请参阅:

Java Message Service 文档

_____________________________________________
简单来说:
接口是公开的,里面不能有私有的方法或变量,是用于让别人使用的,而抽象类是可以有私有方法或私有变量的,

另外,实现接口的一定要实现接口里定义的所有方法,而实现抽象类可以有选择地重写需要用到的方法,一般的应用里,最顶级的是接口,然后是抽象类实现接口,最后才到具体类实现。

还有,接口可以实现多重继承,而一个类只能继承一个超类,但可以通过继承多个接口实现多重继承,接口还有标识(里面没有任何方法,如Remote接口)和数据共享(里面的变量全是常量)的作用.

详细分析:
在Java语言中, abstract class 和interface 是支持抽象类定义的两种机制。正是由于这两种机制的存在,才赋予了Java强大的 面向对象能力。abstract class和interface之间在对于抽象类定义的支持方面具有很大的相似性,甚至可以相互替换,因此很多开发者在进 行抽象类定义时对于abstract class和interface的选择显得比较随意。其实,两者之间还是有很大的区别的,对于它们的选择甚至反映出对于问题领域本质的理解、对于设计意图的理解是否正确、合理。本文将对它们之间的区别进行一番剖析,试图给开发者提供一个在二者之间进行选择的依据。

理解抽象类

abstract class和interface在Java语言中都是用来进行抽象类(本文 中的抽象类并非从abstract class翻译而来,它表示的是一个抽象体,而abstract class为Java语言中用于定义抽象类的一种方法, 请读者注意区分)定义的,那么什么是抽象类,使用抽象类能为我们带来什么好处呢?

在 面向对象的概念中,我们知道所有的对象都是通过类来描绘的,但是反过来却不是这样。并不是 所有的类都是用来描绘对象的,如果一个类中没有包含足够的信息来描绘一个具体的对象,这样的类就是抽象类。抽象类往往用来表征我们在对问题领域进行分析、 设计中得出的抽象概念,是对一系列看上去不同,但是本质上相同的具体概念的抽象。比如:如果我们进行一个图形编辑软件的开发,就会发现问题领域存在着圆、 三角形这样一些具体概念,它们是不同的,但是它们又都属于形状这样一个概念,形状这个概念在问题领域是不存在的,它就是一个抽象概念。正是因为抽象的概念 在问题领域没有对应的具体概念,所以用以表征抽象概念的抽象类是不能够实例化的。

在面向对象领域,抽象类主要用来进行类型隐藏。 我们可以构造出一个固定的一组行为的抽象描 述,但是这组行为却能够有任意个可能的具体实现方式。这个抽象描述就是抽象类,而这一组任意个可能的具体实现则表现为所有可能的派生类。模块可以操作一个 抽象体。由于模块依赖于一个固定的抽象体,因此它可以是不允许修改的;同时,通过从这个抽象体派生,也可扩展此模块的行为功能。熟悉OCP的读者一定知 道,为了能够实现面向对象设计的一个最核心的原则OCP(Open-Closed Principle),抽象类是其中的关键所在。

从语法定义层面看abstract class 和 interface

在语法层面,Java语言对于abstract class和interface给出了不同的定义方式,下面以定义一个名为Demo的抽象类为例来说明这种不同。

使用abstract class的方式定义Demo抽象类的方式如下:

abstract class Demo{
abstract void method1();
abstract void method2();



使用interface的方式定义Demo抽象类的方式如下:

interface Demo{
void method1();
void method2();

}

在abstract class方式中,Demo可以有自己的数据成员,也可以有非 abstract的成员方法,而在interface方式的实现中,Demo只能够有静态的不能被修改的数据成员(也就是必须是static final 的,不过在interface中一般不定义数据成员),所有的成员方法都是abstract的。从某种意义上说,interface是一种特殊形式的 abstract class。

从编程的角度来看,abstract class和interface都可以用来实现 "design by contract" 的思想。但是在具体的使用上面还是有一些区别的。

首先,abstract class 在 Java 语言中表示的是一种继承关系,一个类只能使用一次继承关系(因为Java不支持多继承 -- 转注)。但是,一个类却可以实现多个interface。也许,这是Java语言的设计者在考虑Java对于多重继承的支持方面的一种折中考虑吧。

其次,在abstract class的定义中,我们可以赋予方法的默认行为。但是在interface的定义中,方法却不能拥有默认行为,为了绕过这个限制,必须使用委托,但是这会增加一些复杂性,有时会造成很大的麻烦。

在 抽象类中不能定义默认行为还存在另一个比较严重的问题,那就是可能会造成维护上的麻烦。因 为如果后来想修改类的界面(一般通过 abstract class 或者interface来表示)以适应新的情况(比如,添加新的方法或者给已用的方法中添加新的参数)时,就会非常的麻烦,可能要花费很多的时间(对于派生类很多的情况,尤为如此)。但是如果界面是通过abstract class来实现的,那 么可能就只需要修改定义在abstract class中的默认行为就可以了。

同样,如果不能在抽象类中定义默认行为,就会导致同样的方法实现出现在该抽象类的每一个派生类中,违反了 "one rule,one place" 原则,造成代码重复,同样不利于以后的维护。因此,在abstract class和interface间进行选择时要非常的小心。

从设计理念层面看 abstract class 和 interface

上面主要从语法定义和编程的角度论述了abstract class和interface的区别,这些层面的区别是比较低层次的、非本质的。本小节将从另一个层面:abstract class和interface所反映出的设计理念,来分析一下二者的区别。作者认为,从这个层面进行分析才能理解二者概念的本质所在。

前面已经提到过,abstract class在Java语言中体现了一种继承关系,要想使得继承关系合理,父类和派生类之间必须存在"is-a"关系,即父类和派生类在概念本质上应该是相同的。对于interface来说则不然,并不要求 interface的实现者和interface定义在概念本质上是一致的,仅仅是实现了interface定义的契约而已。为了使论述便于理解,下面将通过一个简单的实例进行说明。

考虑这样一个例子,假设在我们的问题领域中有一个关于Door的抽象概念,该Door具有执行两个动作open和close,此时我们可以通过abstract class或者interface来定义一个表示该抽象概念的类型,定义方式分别如下所示:

使用abstract class方式定义Door:

abstract class Door{
abstract void open();
abstract void close();
}

使用interface方式定义Door:

interface Door{
void open();
void close();
}

其他具体的Door类型可以extends使用abstract class方式定义的Door或者implements使用interface方式定义的Door。看起来好像使用abstract class和interface没有大的区别。

如果现在要求Door还要具有报警的功能。我们该如何设计针对该例子的类结构呢(在本例中, 主要是为了展示 abstract class 和interface 反映在设计理念上的区别,其他方面无关的问题都做了简化或者忽略)?下面将罗列出可能的解决方案,并从设计理念层面对这些不同的方案进行分析。

解决方案一:

简单的在Door的定义中增加一个alarm方法,如下:

abstract class Door{
abstract void open();
abstract void close();
abstract void alarm();
}

或者

interface Door{
void open();
void close();
void alarm();
}

那么具有报警功能的AlarmDoor的定义方式如下:

class AlarmDoor extends Door{
void open(){…}
void close(){…}
void alarm(){…}
}

或者

class AlarmDoor implements Door{
void open(){…}
void close(){…}
void alarm(){…}


这种方法违反了面向对象设计中的一个核心原则 ISP (Interface Segregation Principle),在Door的定义中把Door概念本身固有的行为方法和另外一个概念"报警器"的行为方法混在了一起。这样引起的一个问题是那些仅仅依赖于Door这个概念的模块会因为"报警器"这个概念的改变(比如:修改alarm方法的参数)而改变,反之依然。

解决方案二:

既然open、close和alarm属于两个不同的概念,根据ISP原则应该把它们分别定 义在代表这两个概念的抽象类中。定义方式有:这两个概念都使用 abstract class 方式定义;两个概念都使用interface方式定义;一个概念 使用 abstract class 方式定义,另一个概念使用interface方式定义。

显然,由于Java语言不支持多重继承,所以两个概念都使用abstract class方式定义是不可行的。后面两种方式都是可行的,但是对于它们的选择却反映出对于问题领域中的概念本质的理解、对于设计意图的反映是否正确、合理。我们一一来分析、说明。

如果两个概念都使用interface方式来定义,那么就反映出两个问题:1、我们可能没有理解清楚问题领域,AlarmDoor在概念本质上到底是Door还是报警器?2、如果我们对于问题领域的理解没有问题,比如:我们通过对于问题领域的分析发现AlarmDoor在概念本质上和Door是一致的,那么我们在实现时就没有能够正确的揭示我们的设计意图,因为在这两个概念的定义上(均使用 interface方式定义)反映不出上述含义。

如果我们对于问题领域的理解是:AlarmDoor在概念本质上是Door,同时它有具有报 警的功能。我们该如何来设计、实现来明确的反映出我们的意思呢?前面已经说过,abstract class在Java语言中表示一种继承关系,而继承关系 在本质上是"is-a"关系。所以对于Door这个概念,我们应该使用abstarct class方式来定义。另外,AlarmDoor又具有报警功能,说明它又能够完成报警概念中定义的行为,所以报警概念可以通过interface方式定义。如下所示:

abstract class Door{
abstract void open();
abstract void close();
}
interface Alarm{
void alarm();
}
class Alarm Door extends Door implements Alarm{
void open(){…}
void close(){…}
void alarm(){…}
}

这种实现方式基本上能够明确的反映出我们对于问题领域的理解,正确的揭示我们的设计意图。其 实abstract class表示的是"is-a"关系,interface表示的是"like-a"关系,大家在选择时可以作为一个依据,当然这是建立在对问题领域的理解上的,比如:如果我们认为AlarmDoor在概念本质上是报警器,同时又具有Door的功能,那么上述的定义方式就要反过来了。

小结

1.abstract class 在 Java 语言中表示的是一种继承关系,一个类只能使用一次继承关系。但是,一个类却可以实现多个interface。

2.在abstract class 中可以有自己的数据成员,也可以有非abstarct的成员方法,而在interface中,只能够有静态的不能被修改的数据成员(也就是必须是 static final的,不过在 interface中一般不定义数据成员),所有的成员方法都是abstract的。

3.abstract class和interface所反映出的设计理念不同。其实abstract class表示的是"is-a"关系,interface表示的是"like-a"关系。

4.实现抽象类和接口的类必须实现其中的所有方法。抽象类中可以有非抽象方法。接口中则不能有实现方法。

5.接口中定义的变量默认是public static final 型,且必须给其初值,所以实现类中不能重新定义,也不能改变其值。

6.抽象类中的变量默认是 friendly 型,其值可以在子类中重新定义,也可以重新赋值。

7.接口中的方法默认都是 public,abstract 类型的
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值