使用 Web 服务器的 Listener 架构建议书

http://dev2dev.bea.com.cn/techdoc/200407210.html

 

简介

目标
本文的目标是分析和设计可处理多种协议的 Listener 组件的高级视图。文中提供了一种构建 listener 组件的初始方法，并对比了使用 Servlet 与使用独立 Java 应用程序构建 listener 的设计。

使用 Servlet 与使用独立 Java 程序的 Listener 应用程序的对比
来自 Customer 的请求可能使用多种协议，像 FTP、TCP/IP、HTTP、SNA、SOAP、HTTPS 和 MQ。Customer Handler 负责处理请求并将控制传送到 Controller 以便进一步处理。

Listener 构成了 Customer （FTP/API/Web Customer） 和 Front controller 之间的接口。

Listener 组件处理来自 Customer 的请求，控制则被传送到 Customer Handler 以便进一步处理。

选项

选项 A： 通用 Servlet 架构

可以配置 Listener 组件为特殊的协议工作。Configurator 接受配置文件并根据配置参数来配置 Listener 组件。

“Generic Servlet”具有多种抽象服务方法，可以实现它们以处理多种协议。要处理 FTP、TCP/IP、HTTP 等协议，我们可以实现可扩展 Generic Servlets 的 Servlets。FTP、TCP/IP、HTTP Servlets 可实现多种服务方法以接受来自客户的采用了不同协议的请求。

优势

·                     无需单独的 GUI 来启动和停止 listener。可将 listeners作为一个 web 应用程序来部署，使其易于使用。通过 web 服务器管理控制台可以部署、撤销部署和重新部署 web 应用程序。

·                     各个组件将作为 WAR（Web 档案文件）来创建和打包。这些 listeners 将在 web 容器内作为 web 应用程序来部署。

·                     因为 Generic Servlet 能够处理多种协议，所以新的协议设计和实现将是基于标准的架构。

劣势

·                     代码的实现要花费很多时间。

·  即使我们实现了使用 java 类和从 Servlet/JSP 调用 java 类，被调用的 java 程序也将无法参与到群集环境中，并且也无法将对象保留在会话中，这就意味着如果我们需要类似于HTTPServlet而设计，开发会变得更加复杂，并且为了使其能在群集环境中运行还需要大量的测试工作。

注意：任何 web 服务器都没有这样的实现。

选项 B： Servlet Init 架构

在 web 服务器启动和 web 服务器shutdown期间的关机时将调用所有的 Servlets。每种协议的实现逻辑将被写入 Servlet 的 init 方法中。

优势

·                     web 服务器启动期间会调用 init 方法，并且在 web 服务器shutdown时会触发 destroy方法。

劣势

·                     启动 web 服务器的主线程也将加载所有的 Servlets（MQ、TCP/IP、HTTP）。这些协议 listener将作为其中一台 web 服务器的子线程来运行。我们需要仔细地分析性能，因为所有的 listener 都是作为给 web 服务器所配置的执行线程之一的子线程来运行的。

选项 C： 独立 Java 架构

Listener Component将为特殊的协议而配置。Config Loader接受配置文件并根据配置参数来配置 Listener 组件。

MQ Listener
客户端将请求消息发布到指定队列中，MQListener 将拾取该消息，并使用其 handler 调用 front controller 来执行任务。

这里客户端不必等待响应，所以它是异步的。客户端通过在另一个队列中等待也可以具有同步响应特性，而在另一个队列中将由 front controller 发布响应消息。

TCP/IP Socket Listener

TCP/IP socket listener 在指定端口不断地运行对传入请求的监听。客户端可以向该端口发送请求，listener 则拾取请求并将其发送到 front controller 以进行处理。front controller 在相同的端口给客户端发回响应。TCP/IP socket listener 可以同时接受多个连接（客户端），也就是为每个客户端建立单独的线程，所以多个客户端能够在同一时间发送请求。

TCP/IP Listener 还应该支持对话和非对话通信模式。
a) 在非对话模式中，客户端的请求被发送到应用程序并接收响应。
b) 在对话模式中，客户应用程序发送到我们的应用程序的请求消息被分割成小的数据包。这些消息需要具有某种指示符，指明是否还要发送或接收更多的数据包。数据包传送完后，应用程序会发送一个确认，发送完最后一个数据包后，应用程序则发送响应。

HTTP Listener
通过 HTTP 协议发送的所有请求都被该 listener 所接收。这里客户端要等待响应。该 Listener 将请求发送到 front controller 以进行处理并获取结果。响应将返回到同一线程。请求可以通过支持 HTTP 协议的任何方式发出。该 Listener 也可以处理同时在此发出的多个请求。

优势

·                     保持了实现的简单，并且使用硬件群集可以在（24x7）群集架构下工作。

劣势

·                     管理员需要 GUI 进行“部署”，也就是启动、关闭和重新启动单个listener。

·                     这些 listeners 将被分别部署和测试，并且将不是 web 容器的一部分。

建议
建议使用“选项 A”，因为 GenericServlet 常用于扩展特定于协议的子类，如 HTTPServlet、FTPServlet、MQServlet等，并且考虑到易用性和应用程序的可用性。

关于作者

Raghuram Bharadwaj C是位于印度真奈市的 Hexaware Technologies Limited公司的架构团队中的一名系统分析师。他曾在整个亚太地区以不同的咨询和讲授角色为 BEA Systems HK Ltd、India Liaison Office工作。Raghu 在客户项目上进行技术级咨询，涉及 Java、J2EE 和性能管理，同时精通 BEA WebLogic 的群集、安全和应用程序性能调优。

 

作者简介
	Raghuram Bharadwaj是Chennai Hexaware 技术有限公司架构小组的系统分析员。他在 BEA Systems HK Ltd，India Liaison Office工作，负责整个亚太地区多方面的咨询和教学任务。Raghu 在技术层次为客户项目提供咨询，包括 Java、J2EE 和性能管理，同时他也精通 BEA WebLogic 的群集、安全和应用程序性能调优。

转载于:https://www.cnblogs.com/kapok/archive/2005/10/15/255378.html