内容


Jt —— 面向 Java 模式的框架

消息传送设计模式应用

Comments

概述

Jt 是一种用于快速实现 Java 应用程序的设计模式框架。Jt 在许多大的任务关键型系统中有应用。该框架实现以下目标:

  1. 框架架构基于一个消息传送设计模式:框架组件能够交互信息并通过发送、接收和处理消息执行计算。一个消息传送 API 具有简易性、强大的封装性和松耦合特性;可以使用一个 “lego/messaging” 架构将框架组件交换地插入复杂的框架应用程序中。可对框架消息执行同步或异步处理。框架充分利用消息设计模式/API 的功能和简易性。
  2. 设计模式框架使用消息传送来实现和/或促进 Gang Of Four (GoF) 和 J2EE 等知名设计模式的实现。框架本身已基于设计模式被完全创建和实现。框架还基于设计模式促进和加速应用程序的实现。
  3. 框架 lego/messaging 架构提供对远程组件的透明和安全访问;可将远程框架对象看作是本地对象。由框架(消息传送、适配器、远程代理和外观)实现的设计模式隐藏与远程 API 相关的复杂性,从而实现透明和安全访问。用于消息加密和身份验证的内置组件也会予以提供。
  4. 框架通过框架适配器、代理和相关设计模式的实现提供与其他技术的透明集成。这些技术包括 BPM、Data Access Object 实现(DAO)、Model View Controller 实现(MVC)、EJBs、JSP、AJAX、ESB、JMS、XML、REST 和 Web 服务。
  5. 该框架设计为轻量级和快速特性(开销小/占用内存少)。
  6. 框架 messaging/lego 架构提高和简化了设计/开发工作。UML 设计图与实现所需的基于消息传送的框架应用程序和组件之间有一个紧密的对应关系。框架提供生成框架应用程序所需的向导和自动化功能。可将框架组件轻松添加到 BPM/BPEL 流程图。在未来版本的框架中,应该可以直接从 UML 设计图生成应用程序模块。该目标仍在发展中。
  7. 框架消息传送架构促进测试和调试工作。框架可将组件分为独立单元进行测试,方法是发送消息到组件并验证回复消息。

消息传送设计模式(MDP)

意向(Intent):消息传送设计模式支持组件与应用程序之间的信息交换(例如,消息)。

动机(动力):该设计模式可用于在许多不同的场景中解决各种各样的问题。一个消息传送范式在模式和现实世界中被广泛使用。我们周围到处都有消息的交换。实体在不断发送、接收和处理消息。例如:当我们看电视、听音乐、接听电话或通过互联网通信时。现在,您在阅读这个书面消息。由于计算机应用程序寻求建模现实世界,而使用消息传送方法设计和编写应用程序是最自然的。我们可以说这个方法提供一个对现实世界更复杂和准确的呈现(例如,模型)。结果,通过使用消息传送设计模式,软件工程设计流程得到显著改进。

参与者:

消息发送方:发送消息的组件。

消息接收方(Reciever):接收输入消息的组件,它在处理消息之后可能会生成一个回复(输出消息)。一般来讲,输入消息可能包含任何类型的信息。组件可能还要基于输入消息执行计算。

信使(Messenger):将信息从发送方传输到接收方的中介。发送方和接收方不需要关心信息的传输方式(通信协议、消息格式、加密/安全机制等)和沿途对消息执行的转换。这是信使的用途和责任。类似于现实世界,经常不需要用到信使。可以将消息直接发送给接收方。通信模式包括:同步、异步和双向消息传送。

消息:需要在发送方与接收方之间交换的任何信息(例如,数据)。通常涉及两种消息:输入消息和输出消息(或回复消息)。回复消息不是必需的。

图 1. 消息传送接口
消息传送接口
图 2. 消息传送设计模式(同步模式)
消息传送设计模式(同步模式)
消息传送设计模式(同步模式)
图 3. 消息传送设计模式(没有信使的同步模式)
消息传送设计模式(没有信使的同步模式)
消息传送设计模式(没有信使的同步模式)

结果:

  • 封装。消息传送设计模式最大化封装。每个组件是一个自包含/独立单元。与其他组件和应用程序的惟一通信机制是通过消息传送。
  • 解耦。MDP 最小化耦合。同样,每个组件是一个自包含单元,可独立于系统其余部分执行。
  • 可重用性。MDP 提高可重用性。这类似于 “Lego” 集中的构建块。可以基于共享一种简单互联方式的简单片段(例如,公共接口)构建复杂模型。该方法的功能来自于这些片段组装的组合数。可将使用消息传送设计模式的组件交换地插入复杂应用程序中。组件可随意以任何配置进行组装。一个组件的用户需要知道组件处理的输入/输出消息。应用程序也能够重用来自其他组件级应用程序的组件:如果使用消息传送设计模式,就可从另一个应用程序中提取一个组件。
  • QA/测试流程。MDP 促进测试和调试工作。通过发送消息到组件并验证回复消息(黑盒测试),可将组件作为独立单元进行测试。一般而言,可以通过一个测试装置执行单元测试。无需在组件代码内包含测试代码,因为这很耗时且容易引发意外的软件问题。
  • 设计流程。MDP 提供和简化设计流程。多半设计工作就是,定义满足系统需求所需的组件集和每个组件需要处理的输入/输出消息。UML 设计图与实现所需的组件之间有一个紧密的对应关系。由于所有组件共享同一个消息传送接口,可以将它们轻松添加到 BPM/BPEL 图。如前所述,这类似于构建块,可通过多种方式重用和连接。
  • 开发流程。由于依赖于消息传送的每个组件都是自包含的,一个团队中的成员可以协作进行开发,无需介入其他人的代码/工作。在理想情况下,一个组件/包可由一个人专门负责。团队其余成员需要知道其他人要处理的输入/输出消息。无需更改其他人的代码。而且不需要或很少需要创建、维护和合并多个版本的代码。测试/QA 工程师可以通过一个测试装置独立执行其测试。总而言之,无需添加测试代码。
  • 日志记录和调试。由于所有组件使用相同的消息传送接口,消息会被自动记录。这降低了在代码中添加 print/logging 语句的需求,这个工作很耗时且容易出错。看一下记录的消息,用户通常就能够快速查出引起问题的消息/组件(只需少量工作或无需额外工作)。
  • 开发速度和成本。基于上面概括的所有原因,消息传送设计模式能够极大地提高开发速度并降低成本。
  • 质量和软件维护。质量和软件维护工作也由于上述原因得到改进。
  • 为了充分利用这个设计模式,人们在建模、设计和构建软件应用程序时需要考虑消息传送方面:独立的实体(例如,组件)相互交换消息。这可能需要学习和培训。尽管一个消息传送方法自然、直观且与现实世界一致,传统方法基于库和方法/程序调用(包括本地和远程)。
  • MDP 如同一个状态机。因此可以通过复制组件并通过 consensus 算法协调其交互对其进行扩展,从而以一种更自然、直观的方式提供容错功能。一般来说,向一个不使用 MDP 的程序添加容错特性是一项很困难的任务。

实现和代码示例:

消息传送设计模式是使用 Jt 消息传送接口(JtInterface)实现的。该接口包括一个方法:

清单 1. 消息传送接口
public interface JtInterface  {

/**
  * Jt messaging interface used for the implementation
  * of the messaging design pattern.
  * Process an input message and return a reply (output message). 
  */

  Object processMessage (Object message); 
}

消息传送接口(JtInterface)简单而功能强大。该接口的简易性具有欺骗性。所需要的只是一个方法。它充当一个通用消息传送接口,适用于远程和本地框架组件。该接口处理任何类型的消息(对象类)。尽管这里提出了一个 Java 实现,不过 MDP 和相关框架可以使用任何计算机语言或技术予以实现。

设计模式实现

如前所述,MDP 用于实现和/或促进 Gang of Four (GoF)、DAO 和 J2EE 等知名设计模式的实现。为了解释如何完成该实现,要用到几个模式。同样的概念适用于其他模式的实现。Jt 框架运用这些模式实现高级功能。

Proxy

消息传送设计模式促进 Proxy 的实现。在消息传送范式下,Proxy 主要负责将输入消息转发到真实主体。

图 4. Proxy 的 MDP 实现
Proxy 的 MDP 实现
Proxy 的 MDP 实现

Adapter

消息传送设计模式促进 Adapter 的实现。Adapter 的主要用途是实现接收方和发送方之间的消息转换,从而使这些组件互相连接。

图 5. Adapter 的 MDP 实现
Adapter 的 MDP 实现
Adapter 的 MDP 实现

Web 服务和透明访问

注意,MDP 发送方和接收方不需要在同一个主机上运行。可以将消息发送到远程组件上。MDP 在这方面不加以限制。使用一个现实类比法,您可以通过电话/互联网对话与同屋内或千里以外的朋友进行通信。MDP 能够处理所有这些场景。您和您的朋友无需关心对话的传输方式(技术、通信协议、安全机制等)。当然,这些对您应该是透明的。

如图 6 所示,消息传送设计模式和前面讨论的其他几个设计模式可联合使用,来实现对远程组件的访问。不管使用的协议和通信技术是什么,MDP 都能够提供对远程组件/服务的透明和安全访问:远程组件被看作本地组件。消息可以通过 Web 服务、REST、EJBs、RMI、HTTP、Sockets、SSL 或任何类似的通信接口进行传输。上面讨论的设计模式通过隐藏与远程 API 相关的复杂性实现该透明和安全访问。

图 6. 对分布式组件/服务的 MDP 透明访问
对分布式组件/服务的 MDP 透明访问
对分布式组件/服务的 MDP 透明访问

为清晰起见,将信使组件和内部 processMessage() 方法从下面的 UML 图中删除。尽管异步消息传送受支持,这里只显示同步消息传送。

  1. 代理:消息通过代理被发送到远程组件。
  2. 远程适配器:适配器负责通过转化消息与远程 API 连接。
  3. 外观:将消息转发到合适的远程组件。它通常也提供安全功能。

再回到我们的现实类比法中,电话公司保留的框架需要某种注册(电话薄)才能定位其他参与者。每个实体都有一个相关的电话号码或 ID。所需要的是一个简单的命名机制。在某些情况下,我们可能需要提供一个城市编码和/或国家编码。邮政服务和您的互联网服务提供商也使用一个相对简单的命名方案。

其他服务提供者利用框架并使用定制的身份验证/授权 机制。例如,您的银行机构利用电话系统且使用 Access Management 机制进行身份验证和授权。我们在获准访问一个账户之前需要提供身份验证信息。

所需的其他框架组件不同于上面概述的那些组件。Facade 组件通常负责安全性(消息传送授权和身份验证)。在将消息转发给接收方之前,Facade 在其上执行解密、授权和身份验证。

图 7. 对分布式组件/服务的 MDP 安全访问
对分布式组件/服务的 MDP 安全访问
对分布式组件/服务的 MDP 安全访问

下面是所涉及的组件:

MessageCipher:负责解密输入消息并加密回复消息的组件。可配置该组件来使用一个特定加密方案。

Component Registry:允许系统注册并根据 ID 查询组件。

AccessManager:负责授权/拒绝对远程组件的访问。它对收到的每个消息授权并进行身份验证。如果访问管理器不能认证消息,消息就永远不会到达接收方。

框架安全

MDP 可以自然、直观的方式处理安全难题。它提供端到端、不可否认的消息层安全性(与传输层安全相反)。它还可用于选择性加密,因此只有敏感消息被加密。知名的安全机制很适合于 MDP。另一方面,我们的模型不局限于某个消息格式(XML、SOAP 等)。它提供任何消息格式和 REST 式服务。这包括专用和自定义消息格式。

注意,在一个消息传送范式下,大部分安全方面对于消息发送方和接收方都可以是透明的。例如,发送方和接收方不需要过于关心是否使用了安全性且如何实现安全性。框架提供必需的安全性组件和机制(“管道”)。一般来说,使用我们的现实类比法,您和您的朋友就无需担心服务提供者是否出于隐私和安全原因对您的对话进行了加密。Jt 框架还使用声明安全性来避免编写易出错的安全代码。最后,可基于特定需求提供定制的安全机制。

异步消息传送、双向消息传送和多线程

现在以您的电子邮件或邮政信箱为例。可将消息异步发送并放置在一个消息队列或堆上,直至您准备 “处理” 它们。MDP 能够处理与异步消息传送和多线程相关的复杂性。框架组件能够在一个独立的线程中执行任务。这是对现实世界的一个自然表达:每个组件(实体)是一个自包含单元,能够独立于系统其余部分执行任务。使用组件自身的独立线程,可以异步处理消息。这个功能通过一个消息传送队列在 Jt 框架的上下文中实现。组件不需要添加独立逻辑来管理多线程,因为这很耗时、复杂且易于出错。

您也可以决定异步发送回一个消息,建立一个双向通信。MDP 能够建立双向异步消息传送机制,其中组件和应用程序相互通信。也可以将同步和异步消息传送结合起来。比如,在一个同事或主管来检查进度的同时,您正在阅读您的电子邮件消息。

性能、可伸缩性和容错问题

MDP 模型简单、通用、健壮。它能够处理与分布式应用程序相关的复杂问题。MDP 与通用的可伸缩性和可用性机制(集群、负载平衡、故障转移、缓存等)相兼容。例如,基于 MDP 的 SOA 和 ESB 应用程序能够在计算机集群上运行,从而提高可靠性和可用性。您也可以使用 MDP 灵活地选择和组合协议和技术。您不必局限于某一技术或协议。您的选择取决于具体性能和可用性需求。

MDP 也可通过一种很自然的方式予以扩展,以提供容错功能和技术。复制状态机方法是实现容错系统的一种通用方法,它复制组件并通过 consensus 算法协调其交互。框架组件的行为正好类似于状态机:输入消息、输出消息和组件状态是模型的组成部分。

企业服务总线(ESB)功能

Jt 设计模式框架也是一种消息传送引擎,提供企业服务总线(ESB)功能。它提供对运行在远程应用程序内部的组件的透明访问。框架组件(本地和远程)能够安全地交换消息。Jt 框架还允许您连接异构应用程序,而不管使用什么技术,这些技术包括 JMS、Web Services、EJB、REST, HTTP、EJBs 等。由框架(消息传送、适配器、远程代理、策略、外观等)实现的设计模式可实现该功能。Jt 企业服务总线包括以下主要组件:

  • Enterprise Service Bus Adapter
  • JMS Adapters (point-to-point and publish-subscribe)
  • EJB Adapter
  • EJB Proxy
  • RESTful web services Adapter
  • Secure web services Adapter (Axis)
  • Axis Proxy
  • Message Cipher
  • Message Authenticator
  • Access Manager
  • Data Access Objects
  • Java Mail Adapter
  • XML/Component transformer

可使用 “lego/messaging” 架构将这些组件交换地插入复杂的框架应用程序中。可通过各种配置装配它们来满足特定业务需求。在这种情况下,这些构件块被组合在一起来共同实现企业服务总线(ESB)功能。

框架 ESB 适配器将应用程序连接到 Jt 企业服务总线。可对 ESB 适配器进行配置,来使用任何交换消息策略:JMS、安全的 Axis Web 服务、EJBs、安全的 REST 式 web 服务、HTTP 等。定制/专用策略和协议可能也会用到。ESB 适配器和其他 ESB 组件也负责自动将消息转化为适当的格式/协议。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=555515
ArticleTitle=Jt —— 面向 Java 模式的框架
publish-date=10212010