基于业务类通讯的Http系统，只要由Http Server和Http Client组成。该系列讨论的是基于Delphi的实现方式，其实是可以拓展到其它语言平台上面去的。有兴趣的朋友可以尝试一下。在Delphi中，服务端可以直接使用TIdHttpServer，客户端则直接使用TIdHttp就能够完成通讯的过程。是的，就是这个简单，仅仅这两个控件就构成了一个业务量可以很庞大的业务系统。由于Http都是无状态的，直接由客户端请求服务端，再由服务端给客户端返回相关内容。此时如果不是长连接，会直接断开服务端的连接。所以对于常规业务处理，服务端还是能够应付有余的。
当然，上述俩控件仅仅是构成了数据通讯的基础，至于通讯传输的方式，不用我多说，大家应该很清楚最高效率的方式肯定是直接传输字节流了。那么既然业务类是该系统的基本单元，那么就要面临一个问题，业务类怎么由对象转成字节流呢？好了，醒目或者经验丰富的朋友们第一时间就会想到了Encode和Decode这些编码器和解码器上面去了。没错，就是编码器和解码器！
编码器和解码器对于服务端和客户端来都是共用的单元，编码的时候就可以直接用独立的单元实现，但是也可以直接写在业务类的基类上面去（这种方式不太符合面向对象的编程方法，推荐通过Factory类进行编码和解码，在后续的实现部分中会有相关的介绍）。他们的作用可以参考下图：
那么业务类的传输不成问题了，接着就是业务类的处理问题了。作为一个庞大的业务处理系统，业务类的数量肯定不是小数目，如果每个业务类都要去建立映射那么实在是一件太繁琐的事情。为了解决这个繁琐的问题，该系统用到了WEB中常见的IOC模式。
什么？IOC是什么？这个......我就简单的介绍一下，如果说的不明白，请自行度娘或者谷哥。IOC的英文全称是Inversion of Control，翻译成中文是控制反转，其实这样子还是不能正确描述该模式在本系统中起到的作用，为了更加直观的描述什么是IOC，我举个例子说明一下吧。
一般来说，在CS系统中，尤其是在Http系统中，都是命令与响应的模式。那么在客户端请求什么样的命令，就在服务器响应什么命令，这是最正常不过的了。然而，随着系统的功能增多，命令的定义就是一个很头疼的事情，命令越多，出乱子的几率就会越大，就是说越到后面就越难维护了。因为，要去维护命令与对应函数过程的关系，每一个命令对应一个函数过程，如果命令多了，这是不敢想象的。
那么IOC彻底并且完美的解决了这个问题，IOC其实就相当于将所有的命令分到了不同的业务类中进行维护命令与函数过程的对应关系和实现，这样子我们的修改和维护就更加的有目的性，不需要去维护一个庞大的对照关系表了。就相当于不用业务类是找对应的匹配对应的命令，而是通过程序解码后还原的业务类直接去找到相应的命令。再简单一点说就是不是你去找他，是他来找你（O(∩_∩)O~）。那么你可能会想，博主你在叽里呱啦的说了这么多还是没有明白IOC是啥东西呀？好吧，别急，在详细实现中，我还会详细的介绍一下他的实现和普通的命令映射孰优孰劣。不过话说回来，以我这文笔水平，如果你看到这里能偶理解IOC是什么东西，你肯定之前已经知道IOC是什么东东了。所以你如果看不明白不用着急，果断无视它。
通过了IOC解决了大量堆积命令的问题。接着就是业务的处理怎么做了。这一块说简单也有点复杂，说复杂也确实有点不简单。怎么说呢，首先为了可以更加快速的处理相关业务，有几个池子是必不可少的，一个是线程池，一个是内存池，还有一个是数据库连接池。但是一个池子可能说几天也说不完，我也没打算解说，这一块几乎网上一抓一大把，各位看官如果有兴趣可以参照以后发布的源代码参考参考。
本文主要是简单介绍该系统的服务端实现大概的方向，罗列几个关键术语，接着就一直在忽悠忽悠的。如果你没有被忽悠晕了，请多多关注今后这系列的新博文。