哎诤

    其实仔细分析我们开发的各种软件，其实质可以说都是以一定的控制逻辑进行某种数据处理的过程，而数据处理不免涉及到数据的交互问题，一个系统内部当然需要进行数据交互，不同的系统之间也需要进行数据交互，否则就成了一个个的信息孤岛，以下就是分析不同的系统间数据交互的几种典型方式，以及演变过程。
    最早也是最通用的一种方式，就是通过文件方式进行系统间数据交互，通过定义好文件交互的格式，使双方的系统都能识别，来满足交互的要求。这种方式虽然很古老，但确实相当有用，不少的系统都是这么干的，而且这种方式有一个很大的好处，就是可以在异构系统间进行交互，甚至跨越平台的限制。不同的平台间通过文件交互的话，由于无法直接进行文件共享，所以通常采用FTP进行文件交互，但是这会带来一个问题，文件需要以阻塞方式进行读写，否则会引起冲突或者丢失。
    文件交互方式最大的缺点，就是交互不够实时，很难应付同步数据交互，socket方式的出现解决了这个问题，s ocket方式更准确的说应该是一种通信协议，不过确实可以用于数据交互，通过在双方系统指定IP和Port的套接字上进行数据传输。这种方式也是需要系统双方自己定义交互格式，而且是以字节的方式进行定义，发送方需要将数据组织成指定的socket报文，接收方又需要根据报文格式，进行相应的解析，才能转到相应的处理，这也是socket方式最大问题，实现起来相当繁琐。
    在socket基础上，引入成熟的HTTP、UDP等通信协议，作为数据交互的基础，利用这些协议的特点，定义交互格式相对就简单多了，无须纠缠于字节长度，只要按照通用的http报文格式组织数据即可。不过郁于通信层交互方式的特点，还是需要接受方先解析数据后，再转向自己的内部流程进行处理，那有没有一种机制，就是支持一个系统能够直接调用另一个系统提供的方法呢。
    这就是RPC--远程过程调用机制出现的原因，通过RPC一个系统能够直接调用另一个系统提供的方法，其核心就是将数据交互从通信层上身到表示层，让使用者无须关心具体的通信实现。最早的实现方式就是CORBA，然后是微软的COM/COM+机制。前几年ASP流行的时候，就曾经有一种很经典的开发模式:ASP+COM+数据库，在COM中实现对数据库的访问，以及逻辑控制，然后在ASP页面中调用COM提供的方法，这种方式在安全性和可重用性上有明显的提高。
    当JAVA时代到来后，当然不会忘记RPC机制，早先是RMI-远程调用接口，然后随着J2EE规范的成熟，其EJB技术也是大行其道，不过RMI和EJB都有一个显著的缺陷，只能在JAVA构建的应用系统间进行数据交互，对于非JAVA系统则无法使用了。
    因此早两年java开始推出WebSevices机制，引入服务方和客户方的概念，通过标准的服务发布方式，以及标准的调用方式，使得在异构系统间进行实时的数据交互不再有问题，其底层的通信方式还是采用的HTTP协议。
    关于WebServices的具体内容参见4月17日的描述。