概述
2021SC@SDUSC
一. 核心组件
EventLoop 和 EventLoopGroup（已分析）
ChannelPipeline（ChannelPipeline中已分析）
ChannelHandler（ChannelPipeline中已分析）
ChannelHandlerContext（已分析）
Channel（已分析）
ChannelFuture（已分析）
二. ChannelHandler责任链模式的过滤链 (已分析)
三. 通信协议和私有协议栈开发（本节分析）
- Netty HTTP协议栈的应用——HTTP文件服务器（已分析）
- Netty HTTP+XML 协议栈开发（本节分析）
由于HTTP协议的通用性，很多异构系统间的通信交互采用HTTP协议。
在Java领域，最常用的HTTP协议栈就是基于Servlet规范的Tomcat等 Web容器。但是，很多基于HTTP的应用都是后台应用，HTTP仅仅是承载数据交换的一个通道，是一个载体而不是Web容器，在这种场下，一般不需要类似Tomcat这样的重量型Web容器。
我们今天主要分析的就是如何利用Netty提供的基础 HTTP协议栈功能，扩展开发 HTTP+XML协议栈。我们从使用 HTTP+XML协议栈的一个具体的应用程序入手来分析。
目录
一. 开发背景
二.HTTP+XML协议栈设计
1.分析Netty已有功能和需要拓展的功能
2.设计思路
三.高效的XML绑定框架JiBx
1. JiBX 初步了解
2. POJO对象定义
四. HTTP+XML编解码框架开发
1. HTTP+XML请求消息编码类
2.HTTP+XML请求消息解码类
3. HTTP+XML响应消息编码类
4.HTTP+XML应答消息解码
五. HTTP + XML 客户端 与 服务端 开发
六.小结
一. 开发背景
首先我们来看一下这个程序开发的背景。
我们先模拟一个简单的用户订购系统。客户端填写订单，通过HTTP客户端向服务端发送订购请求，请求消息放在HTTP消息体中，以XML承载，即采用HTTP+XML的方式进行通信。
HTTP服务端接收到订购请求后，对订单请求进行修改，然后通过 HTTP+XML的方式返回应答消息。双方采用HTTP1.1协议，连接类型为CLOSE方式，即双方交互完成，由 HTTP服务端主动关闭链路，随后客户端也关闭链路并退出。
我们再来看一下会用到的数据。
二.HTTP+XML协议栈设计
这部分的分析，我们通过商品订购的流程图，来观察订购的关键步骤和主要技术点，找出当前Netty HTTP协议栈的功能不足之后，通过扩展的方式完成HTTP+XML协议栈的开发。
流程图如下：
1.分析Netty已有功能和需要拓展的功能
对订购流程图进行分析 :
先看步骤1，构造订购请求消息并将其编码为HTTP+XML形式。Netty的HTTP协议栈提供了构造HTTP请求消息的相关接口，但是无法将普通的POJO对象转换为HTTP+XML的HTTP请求消息，需要自定义HTTP+XML格式的请求消息编码器。
再看步骤2，利用Netty的HTTP协议栈，可以支持HTTP链路的建立和请求消息的发送，所以不需要额外开发，直接重用Netty的能力即可。
步骤3，HTTP服务端需要将HTTP+XML格式的订购请求消息解码为订购请求POJO对象，同时获取HTTP请求消息头信息。利用Netty的HTTP协议栈服务端，可以完成HTTP请求消息的解码，但是，如果消息体为XML格式，Netty无法支持将其解码为POJO对象，需要在Netty协议栈的基础上扩展实现。
步骤4，服务端对订购请求消息处理完成后，重新将其封装成XML，通过HTTP应答消息体携带给客户端，Netty的HTTP协议栈不支持直接将POJO对象的应答消息以XML方式发送，需要定制。
步骤5，HTTP客户端需要将HTTP+XML格式的应答消息解码为订购POJO对象，同时能够获取应答消息的HTTP头信息，Netty的协议栈不支持自动的消息解码。
通过上面对每一个步骤的分析，我们可以了解到哪些能力是Netty原本支持的，哪些需要扩展开发实现的。
2.设计思路
下面给出设计思路:
（1）需要一套通用、高性能的XML序列化框架，它能够灵活地实现POJO-XML的互相转换，最好能够通过工具自动生成绑定关系，或者通过XML的方式配置双方的映射关系；
（2）作为通用的HTTP+XML协议栈，XML-POJO对象的映射关系应该非常灵活，支持命名空间和自定义标签；
（3）提供HTTP+XML请求消息编码器，供HTTP客户端发送请求消息自动编码使用；
（4）提供HTTP+XML请求消息解码器，供HTTP服务端对请求消息自动解码使用；
（5）提供HTTP+XML响应消息编码器，供HTTP服务端发送响应消息自动编码使用；
（6）提供HTTP+XML响应消息编码器，供HTTP客户端对应答消息进行自动解码使用；
（7）协议栈使用者不需要关心HTTP+XML的编解码，对上层业务零侵入，业务只需要对上层的业务POJO对象进行编排。
三.高效的XML绑定框架JiBx
这部分我们主要分析XML框架的选型和开发,它是 HTTP+XML协议栈的关键技术。
1. JiBX 初步了解
JiBX是一款非常优秀的XML数据绑定框架。它提供灵活的绑定映射文件，实现数据对象与XML文件之间的转换，并不需要修改既有的Java类。另外，它的转换效率是目前很多其他开源项目都无法比拟的。
XML已经成为目前程序开发配置的重要组成部分。使用JiBX绑定XML文档与Java对象需要分两步走:
第一步是绑定XML文件，也就是映射XML文件与Java对象之间的对应关系。
第二步是在运行时,实现XML文件与Java实例之间的互相转换。这时，它已经与绑定文件无关了，可以说是完全脱耦了。
在运行程序之前，需要先配置绑定文件并进行绑定，在绑定过程中它将会动态地修改程序中相应的 class文件，主要是生成对应对象实例的方法和添加被绑定标记的属性JiBX_bindingList等。
JiBx有两个比较重要的概念 : Unmarshal（数据分解）和 Marshal（数据编排)。从字面意思也很容易理解：Unmarshal是将XML文件转换成Java对象，而Marshal则是将Java对象编排成规范的XML文件。
JiBX在 Unmarshal/Marshal 上如此高效，这要归功于使用了XPP技术，而不是使用基于树型方式将整个文档写入内存，然后进行操作的 DOM (Document Object Model)，也不是使用基于事件流的SAX。XPP使用的是不断增加的数据流处理方式，同时允许在解析XML文件时中断。
2. POJO对象定义
我们先定义POJO对象，再生成XML和对象的绑定文件。JiBx对POJO对象没有特殊要求，只要符合Java Bean的规则即可，下面我们以订购例程为例，看下主要类的定义。
@Data
public class Address {
private String street1;
private String street2;
private String city;
private String state;
private String postCode;
private String country;
}
@Data
public class Customer {
private long customerNumber;
private String firstName;
private String lastName;
private List middleNames;
}@Data
public class Order {
private long orderNumber;
private Customer customer;
private Address billTo;
private Shipping shipping;
private Address shipTo;
private Float total;
}
public enum Shipping {
STANDARD_MAIL, PRIORITY_MAIL, INTERNATIONAL_MAIL, DOMESTIC_EXPRESS, INTERNATIONAL_EXPRESS
}
POJO对象定义完成之后，通过Ant脚本来生成XML和 POJO对象的绑定关系文件，同时也附加生成XML的Schema定义文件。
进行到这里我们先来测试一下JiBx类库的使用。
public class TestOrder {
private IBindingFactory factory = null;
private StringWriter writer = null;
private StringReader reader = null;
private final static String CHARSET_NAME = "UTF-8";
private String encode2Xml(Order order) throws JiBXException, IOException {
//关注1
factory = BindingDirectory.getFactory(Order.class);
//关注2
writer = new StringWriter();
IMarshallingContext mctx = factory.createMarshallingContext();
mctx.setIndent(2);
mctx.marshalDocument(order, CHARSET_NAME, null, writer);
String xmlStr = writer.toString();
writer.close();
System.out.println(xmlStr.toString());
return xmlStr;
}
private Order decode2Order(String xmlBody) throws JiBXException {
reader = new StringReader(xmlBody);
IUnmarshallingContext uctx = factory.createUnmarshallingContext();
Order order = (Order) uctx.unmarshalDocument(reader);
return order;
}
public static void main(String[] args) throws JiBXException, IOException {
TestOrder test = new TestOrder();
Order order = new Order();
order.setOrderNumber(123);
Customer customer = new Customer();
customer.setFirstName("ali");
customer.setMiddleNames(Arrays.asList("baba"));
customer.setLastName("taobao");
order.setCustomer(customer);
Address address = new Address();
address.setCity("南京市");
address.setCountry("中国");
address.setPostCode("123321");
address.setState("江苏省");
address.setStreet1("龙眠大道");
address.setStreet2("INTERNATIONAL_MAIL");
order.setBillTo(address);
order.setShipTo(address);
order.setShipping(Shipping.INTERNATIONAL_MAIL);
order.setTotal(33f);
String body = test.encode2Xml(order);
Order order2 = test.decode2Order(body);
System.out.println(order2);
}
} 首先看关注1，根据Order的 Class实例构造IBindingFactory对象。再看关注2，创建新的StringWriter对象,通过IBindingFactory构造Marshalling上下文,最后通过marshalDocument将Order序列化为StringWriter，通过StringWriter 的 toString()方法可以返回String类型的XML对象。
解码与编码类似，不同的是它使用StringReader 来读取 String 类型的XML对象，然后通过unmarshalDocument方法将其反序列化为Order对象。
执行结果如下图所示：
（图片来自《Netty权威指南》）
通过上面的执行结果我们可以发现，XML序列化和反序列化后的结果与预期一致，我们开发的JiBx应用可以正常工作。
四. HTTP+XML编解码框架开发
下面我们基于程序的源代码来进行分析：如何在 Netty 提供的HTTP基础协议栈上进行扩展和封装，实现HTTP+XML 协议栈的开发。
1. HTTP+XML请求消息编码类
对于上层业务侧，构造订购请求消息后，以HTTP+XML协议将消息发送给服务端，如果要实现对业务零侵入或者尽可能少的侵入，协议层和应用层应该解耦。
考虑到HTTP+XML协议栈需要一定的定制扩展能力，例如通过HTTP消息头携带业务自定义字段，所以，应该允许业务利用Netty的 HTTP协议栈接口自行构造私有的HTTP消息头。
和我们前面学习的一样，HTTP+XML的协议编码仍然采用ChannelPipeline中增加对应的编码handler类实现。
下面我们来一起看下HTTP+XML请求消息编码类的源码实现。
public class HttpXmlRequestEncoder extends AbstractHttpXmlEncoder {
@Override
protected void encode(ChannelHandlerContext ctx, Object o,List out) throws Exception {
HttpXmlRequest msg = (HttpXmlRequest)o;
//首先调用父类的encode0，将业务需要发送的POJO对象Order实例通过JiBx序列化为XML字符串
//随后将它封装成Netty的ByteBuf。
ByteBuf body = encode0(ctx, msg.getBody());
FullHttpRequest request = msg.getRequest();
//对消息头进行判断，如果业务自定义和定制了消息头，则使用业务侧设置的HTTP消息头，
//如果业务侧没有设置，则构造新的HTTP消息头。
if (request == null) {
//用来构造和设置默认的HTTP消息头，由于通常情况下HTTP通信双方更关注消息体本身，所以这里采用了硬编码的方式，
//如果要产品化，可以做成XML配置文件，允许业务自定义配置，以提升定制的灵活性。
request = new DefaultFullHttpRequest(HttpVersion.HTTP_1_1,HttpMethod.GET, "/do", body);
HttpHeaders headers = request.headers();
headers.set(HttpHeaders.Names.HOST, InetAddress.getLocalHost().getHostAddress());
headers.set(HttpHeaders.Names.CONNECTION, HttpHeaders.Values.CLOSE);
headers.set(HttpHeaders.Names.ACCEPT_ENCODING,
HttpHeaders.Values.GZIP.toString() + ','
+ HttpHeaders.Values.DEFLATE.toString());
headers.set(HttpHeaders.Names.ACCEPT_CHARSET,"ISO-8859-1,utf-8;q=0.7,*;q=0.7");
headers.set(HttpHeaders.Names.ACCEPT_LANGUAGE, "zh");
headers.set(HttpHeaders.Names.USER_AGENT,"Netty xml Http Client side");
headers.set(HttpHeaders.Names.ACCEPT,"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8");
}
//由于请求消息消息体不为空，也没有使用Chunk方式，所以在HTTP消息头中设置消息体的长度Content-Length，
//完成消息体的XML序列化后将重新构造的HTTP请求消息加入到out中，
//由后续Netty的HTTP请求编码器继续对HTTP请求消息进行编码。
HttpHeaders.setContentLength(request, body.readableBytes());
out.add(request);
}
}HTTP+XML请求消息编码类中，我们首先来看下面的代码：
ByteBuf body = encode0(ctx, msg.getBody());
这里首先调用父类的encode0，将业务需要发送的POJO对象Order实例通过JiBx序列化为XML字符串，随后将它封装成Netty的ByteBuf。
FullHttpRequest request = msg.getRequest(); 随后对消息头进行判断，如果业务自定义和定制了消息头，则使用业务侧设置的HTTP消息头，
如果业务侧没有设置，则构造新的HTTP消息头。在构造新的消息头的代码中，由于通常情况下HTTP通信双方更关注消息体本身，所以这里采用了硬编码的方式。
HttpHeaders.setContentLength(request, body.readableBytes());最后由于请求消息消息体不为空，也没有使用Chunk方式，所以在HTTP消息头中设置消息体的长度Content-Length，完成消息体的XML序列化后将重新构造的HTTP请求消息加入到out中，由后续Netty的HTTP请求编码器继续对HTTP请求消息进行编码。
下面来看一下父类AbstractHttpXmlEncoder的实现：
public abstract class AbstractHttpXmlEncoder extends MessageToMessageEncoder {
IBindingFactory factory = null;
StringWriter writer = null;
final static String CHARSET_NAME = "UTF-8";
final static Charset UTF_8 = Charset.forName(CHARSET_NAME);
protected ByteBuf encode0(ChannelHandlerContext ctx, Object body) throws Exception {
//在此将业务的Order实例序列化为XML字符串。
factory = BindingDirectory.getFactory(body.getClass());
writer = new StringWriter();
IMarshallingContext mctx = factory.createMarshallingContext();
mctx.setIndent(2);
mctx.marshalDocument(body, CHARSET_NAME, null, writer);
String xmlStr = writer.toString();
writer.close();
writer = null;
//将XML字符串包装成Netty的ByteBuf并返回，实现了HTTP请求消息的XML编码。
ByteBuf encodeBuf = Unpooled.copiedBuffer(xmlStr, UTF_8);
return encodeBuf;
}在 前面JiBx分析中，已经介绍了XML序列化和反序列化的相关类库使用。这里类主要是将Order实例序列化为XML字符串。最后将XML字符串包装成Netty 的 ByteBuf并返回，实现了HTTP请求消息的XML 编码。
再来看一下HttpXmlRequest是如何实现的:
public class HttpXmlRequest {
private FullHttpRequest request;
private Object body;
public HttpXmlRequest(FullHttpRequest request, Object body) {
this.body = body;
this.request = request;
}
}从上面的代码中可以看出，这个类包含两个成员变量FullHttpRequest和编码对象Object，用于实现和协议栈之间的解耦。
2.HTTP+XML请求消息解码类
HTTP服务端接收到HTTP+XML请求消息后，需要从HTTP消息体中获取请求码流，通过JiBx框架对它进行反序列化，得到请求POJO对象，然后对结果进行封装，回调到业务handler对象，业务得到的就是解码后的POJO对象和HTTP消息头。
下面是这个类的具体实现，代码分析直接注释在代码中：
public class HttpXmlRequestDecoder extends AbstractHttpXmlDecoder {
public HttpXmlRequestDecoder(Class clazz) {
this(clazz, false);
}
//HttpXmlRequestDecoder有两个参数，分别为需要解码的对象的类型信息和是否打印HTTP消息体码流的码流开关，码流开关默认关闭。
public HttpXmlRequestDecoder(Class clazz, boolean isPrint) {
super(clazz, isPrint);
}
@Override
protected void decode(ChannelHandlerContext arg0, Object o, List arg2) throws Exception {
FullHttpRequest arg1 = (FullHttpRequest)o;
//首先对HTTP请求消息本身的解码结果进行判断，如果已经解码失败，再对消息体进行二次解码已经没有意义。
if (!arg1.getDecoderResult().isSuccess()) {
//如果HTTP消息本身解码失败，则构造处理结果异常的HTTP应答消息返回给客户端。
sendError(arg0, BAD_REQUEST);
return;
}
//通过HttpXmlRequest和反序列化后的Order对象构造HttpXmlRequest实例，最后将它添加到解码结果List列表中。
HttpXmlRequest request = new HttpXmlRequest(arg1, decode0(arg0,arg1.content()));
arg2.add(request);
}
private static void sendError(ChannelHandlerContext ctx,
HttpResponseStatus status) {
//省略...
}
}继续看下它的父类AbstractHttpXmlDecoder的实现。
分析直接注释在代码中:
public abstract class AbstractHttpXmlDecoder extends MessageToMessageDecoder {
private IBindingFactory factory;
private StringReader reader;
private Class clazz;
private boolean isPrint;
private final static String CHARSET_NAME = "UTF-8";
private final static Charset UTF_8 = Charset.forName(CHARSET_NAME);
protected AbstractHttpXmlDecoder(Class clazz) {
this(clazz, false);
}
protected AbstractHttpXmlDecoder(Class clazz, boolean isPrint) {
this.clazz = clazz;
this.isPrint = isPrint;
}
protected Object decode0(ChannelHandlerContext arg0, ByteBuf body)
throws Exception {
//从HTTP的消息体中获取请求码流，然后通过JiBx类库将XML转换成POJO对象。
factory = BindingDirectory.getFactory(clazz);
String content = body.toString(UTF_8);
//根据码流开关决定是否打印消息体码流。
//增加码流开关往往是为了方便问题定位，在实际项目中，需要打印到日志中。
if (isPrint) {
System.out.println("The body is : " + content);
}
reader = new StringReader(content);
IUnmarshallingContext uctx = factory.createUnmarshallingContext();
Object result = uctx.unmarshalDocument(reader);
reader.close();
reader = null;
return result;
}
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause)
throws Exception {
// 释放资源
//如果解码发生异常，要判断StringReader是否已经关闭，
//如果没有关闭，则关闭输入流并通知JVM对其进行垃圾回收。
if (reader != null) {
reader.close();
reader = null;
}
}
}3. HTTP+XML响应消息编码类
对于响应消息，用户可能并不关心HTTP消息头之类的，它将业务处理后的POJO对象丢给HTTP+XML协议栈，由基础协议栈进行后续的处理。为了降低业务的定制开发难度，我们首先封装一个全新的HTTP XML应答对象，它的实现如下：
//它包含两个成员变量：FullHttpResponse和Object，Object就是业务需要发送的应答POJO对象。
public class HttpXmlResponse {
private FullHttpResponse httpResponse;
private Object result;
public HttpXmlResponse(FullHttpResponse httpResponse, Object result) {
this.httpResponse = httpResponse;
this.result = result;
}
public final FullHttpResponse getHttpResponse() {
return httpResponse;
}
public final void setHttpResponse(FullHttpResponse httpResponse) {
this.httpResponse = httpResponse;
}
public final Object getResult() {
return result;
}
public final void setResult(Object result) {
this.result = result;
}
}这个类主要包含两个成员变量：FullHttpResponse和Object，Object就是业务需要发送的应答POJO对象。
下面是应答消息的XML编码类实现：
public class HttpXmlResponseEncoder extends AbstractHttpXmlEncoder {
protected void encode(ChannelHandlerContext ctx, Object o, List out) throws Exception {
HttpXmlResponse msg = (HttpXmlResponse) o;
ByteBuf body = encode0(ctx, msg.getResult());
FullHttpResponse response = msg.getHttpResponse();
//对应答消息进行判断
if (response == null) {
response = new DefaultFullHttpResponse(HTTP_1_1, OK, body);
} else {
response = new DefaultFullHttpResponse(msg.getHttpResponse()
.getProtocolVersion(), msg.getHttpResponse().getStatus(),
body);
}
//设置消息体内容格式为“text/xml”
response.headers().set(CONTENT_TYPE, "text/xml");
setContentLength(response, body.readableBytes());
out.add(response);
}
} 这个类的实现比较简单，首先对应答消息进行判断，如果业务侧已经构造了HTTP应答消息，则利用业务已有应答消息重新复制一个新的HTTP应答消息。无法重用业务侧自定义HTTP应答消息的主要原因，是 Netty 的 DefaultFullHttpResponse没有提供动态设置消息体 content的接口，只能在第一次构造的时候设置内容。由于这个局限，导致我们的实现有点麻烦。
最后设置消息体内容格式为“text/xml”，然后在消息头中设置消息体的长度，把编码后的DefaultFullHttpResponsc对象添加到编码结果列表中，由后续Netty的HTTP编码类进行二次编码。
4.HTTP+XML应答消息解码
客户端接收到HTTP+XML应答消息后，对消息进行解码，获取HttpXmlResponse对象，源码如下。
public class HttpXmlResponseDecoder extends AbstractHttpXmlDecoder {
public HttpXmlResponseDecoder(Class clazz) {
this(clazz, false);
}
public HttpXmlResponseDecoder(Class clazz, boolean isPrintlog) {
super(clazz, isPrintlog);
}
@Override
protected void decode(ChannelHandlerContext ctx,Object o, List out) throws Exception {
//关注
DefaultFullHttpResponse msg = (DefaultFullHttpResponse)o;
HttpXmlResponse resHttpXmlResponse = new HttpXmlResponse(msg, decode0(
ctx, msg.content()));
out.add(resHttpXmlResponse);
}
}我们看关注部分，是通过DefaultFullHttpResponse和 HTTP应答消息反序列化后的POJO对象构造HttpXmlResponse，并将其添加到解码结果列表中。
五. HTTP + XML 客户端 与 服务端 开发
客户端的功能如下：
(1）发起 HTTP连接请求;
(2）构造订购请求消息，将其编码成XML，通过HTTP协议发送给服务端;
(3）接收HTTP服务端的应答消息，将XML应答消息反序列化为订购消息POJO对象;(4）关闭HTTP连接。
先来看启动类：
public class HttpXmlClient {
public void connect(int port) throws Exception {
// 配置客户端NIO线程组
EventLoopGroup group = new NioEventLoopGroup();
try {
Bootstrap b = new Bootstrap();
b.group(group).channel(NioSocketChannel.class)
.option(ChannelOption.TCP_NODELAY, true)
.handler(new ChannelInitializer() {
@Override
public void initChannel(Channel ch)
throws Exception {
ch.pipeline().addLast("http-decoder",new HttpResponseDecoder());
ch.pipeline().addLast("http-aggregator",new HttpObjectAggregator(65536));
// XML解码器
ch.pipeline().addLast("xml-decoder",new HttpXmlResponseDecoder(Order.class,true));
ch.pipeline().addLast("http-encoder",new HttpRequestEncoder());
ch.pipeline().addLast("xml-encoder",new HttpXmlRequestEncoder());
ch.pipeline().addLast("xmlClientHandler",new HttpXmlClientHandle());
}
});
// 发起异步连接操作
ChannelFuture f = b.connect(new InetSocketAddress(port)).sync();
// 等待客户端链路关闭
f.channel().closeFuture().sync();
} finally {
// 优雅退出，释放NIO线程组
group.shutdownGracefully();
}我们先来看一下，在channelPipeline上添加了哪些 “handler”:
首先在ChannelPipeline 中新增了HttpResponseDecoder，它负责将二进制码流解码成为HTTP的应答消息。
随后新增了HttpObjectAggregator，它负责将1个HTTP请求消息的多个部分合并成一条完整的 HTTP 消息。
然后将前面开发的 XML解码器HttpXmIResponseDecoder添加到ChannelPipeline中，它有两个参数，分别是解码对象的类型信息和码流开关，这样就实现了HTTP+XML应答消息的自动解码。
最后将HttpRequestEncoder编码器添加到ChannelPipeline中时，需要注意顺序，编码的时候是按照从尾到头的顺序调度执行的，它后面放的是我们自定义开发的HTTP+XML请求消息编码器HttpXmlRequestEncoder。
最后是业务的逻辑编排类HttpXmlClientHandle。
public class HttpXmlClientHandle extends SimpleChannelInboundHandler {
@Override
public void channelActive(ChannelHandlerContext ctx) {
HttpXmlRequest request = new HttpXmlRequest(null,OrderFactory.create(123));
ctx.writeAndFlush(request);
}
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
cause.printStackTrace();
ctx.close();
}
@Override
protected void messageReceived(ChannelHandlerContext ctx,Object o) throws Exception {
HttpXmlResponse msg = (HttpXmlResponse)o;
System.out.println("The client receive response of http header is : " + msg.getHttpResponse().headers().names());
System.out.println("The client receive response of http body is : " + msg.getResult());
}
}客户端的实现简单。首先构造HttpXmlRequest对象,调用ChannclHandlerContext的 writeAndFlush 发送HttpXmlRequest。
messageReceived用于接收服务端的应答消息，从接口看，它接收到的已经是自动解码后的 HttpXmIResponse对象了。最后将POJO消息打印出来，这里在测试的时候可以与服务端发送的原始对象进行比对，两者的内容将完全一致。
最后，来看看订购对象工厂类的实现：
public class OrderFactory {
public static Order create(long orderID) {
Order order = new Order();
order.setOrderNumber(orderID);
order.setTotal(9999.999f);
Address address = new Address();
address.setCity("南京市");
address.setCountry("中国");
address.setPostCode("123321");
address.setState("江苏省");
address.setStreet1("龙眠大道");
order.setBillTo(address);
Customer customer = new Customer();
customer.setCustomerNumber(orderID);
customer.setFirstName("李");
customer.setLastName("林峰");
order.setCustomer(customer);
order.setShipping(Shipping.INTERNATIONAL_MAIL);
order.setShipTo(address);
return order;
}
}HTTP服务端的功能如下：
( 1）接收HTTP客户端的连接;
(2）接收HTTP客户端的XML请求消息，并将其解码为POJO对象;(3）对POJO对象进行业务处理，构造应答消息返回;
(4）通过HTTP+XML的格式返回应答消息;
(5)主动关团HTTP连接。
服务端监听主程序和我们前面，在组件分析中，分析过的启动流程类似，这里不再赘述，直接看HttpXmlServerHandler的实现（省略异常处理代码）：
public class HttpXmlServerHandler extends SimpleChannelInboundHandler {
@Override
public void messageReceived(final ChannelHandlerContext ctx,Object o) throws Exception {
HttpXmlRequest xmlRequest = (HttpXmlRequest)o;
HttpRequest request = xmlRequest.getRequest();
//关注1
Order order = (Order) xmlRequest.getBody();
System.out.println("Http server receive request : " + order);
//关注2
dobusiness(order);
//关注3
ChannelFuture future = ctx.writeAndFlush(new HttpXmlResponse(null,
order));
if (!isKeepAlive(request)) {
future.addListener(new GenericFutureListener() {
public void operationComplete (Future future)throws Exception {
ctx.close();
}
});
}
}
private void dobusiness(Order order) {
order.getCustomer().setFirstName("狄");
order.getCustomer().setLastName("仁杰");
List midNames = new ArrayList();
midNames.add("李元芳");
order.getCustomer().setMiddleNames(midNames);
Address address = order.getBillTo();
address.setCity("洛阳");
address.setCountry("大唐");
address.setState("河南道");
address.setPostCode("123456");
order.setBillTo(address);
order.setShipTo(address);
}
//省略....
}我们专注messageReceived方法：
这里通过messageReceived的方法入参HttpXmlRequest，可以看出服务端业务处理类接收到的已经是解码后的业务消息了。
关注1 用于获取请求消息对象。随后将它打印出来，可以与客户端发送的原始消息进行对比。
关注2 对订购请求消息进行业务逻辑编排.
关注3 用于发送应答消息，并且在发送成功之后主动关闭HTTP连接。
最后的异常处理的代码没有给出，这部分代码主要负责在发生异常并且链路没有关闭的情况下，构造内部异常消息发送给客户端，发送完成之后关闭HTTP链路。
到此，HTTP+XML的协议栈开发工作全部完成。
我们来简单的看一下测试的结果：
服务端请求消息码流输出：
服务端解码后的业务对象输出：
客户端响应消息码流输出：
客户端解码后的业务对象输出：
测试结果表明，HTTP+XML协议栈功能正常，达到了设计预期。
六.小结
这两次的博客，第一篇关于协议的博客着重分析了HTTP协议以及如何使用Netty 的 HTTP协议栈开发基于 HTTP的应用程序。今天的这个博客主要通过对HTTP+XML协议栈的开发的源代码进行分析，研究了如何基于Netty提供的HTTP协议栈做二次定制开发。
第一次进行这个分析的时候，还是不是很清晰。通过两次的分析，感觉自己稍微有点“入门”了。关于协议的二次开发，主要思想是分析现在需要的功能和已经有的技术可以解决的部分，再来找出还需要做的部分，针对这部分进行开发。然后就是具体针对协议的请求响应的编码解码的实现，在这部分中，我们也看到了对前面基础的应用，尤其是责任链模式发挥了很大的作用，很大程度减轻了后期的工作，我们只需要将需要的handler添加到链上，后面的工作就不需要我们担心了。
关于协议这部分，目前还是比较基础的一个状态 ，后面的分析会更锻炼自己从上层往下看，可以把握整体的结构。
最后
以上就是粗心水壶为你收集整理的Netty之通信协议和私有协议栈开发(二)一. 开发背景 二.HTTP+XML协议栈设计三.高效的XML绑定框架JiBx四. HTTP+XML编解码框架开发五. HTTP + XML 客户端 与 服务端 开发六.小结的全部内容，希望文章能够帮你解决Netty之通信协议和私有协议栈开发(二)一. 开发背景 二.HTTP+XML协议栈设计三.高效的XML绑定框架JiBx四. HTTP+XML编解码框架开发五. HTTP + XML 客户端 与 服务端 开发六.小结所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复