EIO方法与框架--软件开发的一种新途径

EIO是一种软件开发方法及支撑环境.EIO是面向抽注的意思，该方法重点用于开发包括B/S模式在内的C/S模式的应用程序，是Struts、 SpringMVC、Tapestry、ASP、JSP、PHP及一些Python Web框架等方法与框架的一种替代品，目标是简化开发工作，提高软件质量。

EIO的特点，简言之是“面向抽注、基于服务”。EIO将一个应用系统的构造，看做是通过交互视图与数据资源的抽取与注入操作实现的。抽注操作以服务模式进行，基于客户与服务端的消息传递，使程序的构成机制由“控制”转变为“服务”，舍弃流行的MV*(MVC、MVP, MVVM等）模式，解决了以Struts为代表的一类MV*模式的以控制为核心所带来的编程复杂、运行效率低下的问题。

EIO的效益目标是社会效益，采用开源与免费策略，使软件开发环境与工具的国产化，大幅度提高软件开发生产率。

一、EIO基本思想

EIO是由华南理工大学计算机系统研究所齐德昱教授提出并主持实现的一种面向客户/服务器模式的应用系统的编程框架。2015年3月26日发布浏览器版的试用版，是继“格件”(Gridjack)和格文档(GriDoc)后，在软件开发方法/框架与数据处理模型领域的另一个研究成果。

EIO是英文“ Extract and Injection Oriented ”的缩写，意为面向交互组件的数据抽取与注入。EIO的核心思想是交互视图与资源视图的数据的抽取与注入。它主要通过数据的抽取与注入来描述应用系统的逻，亦即将一个应用系统的构造，看做是由面向交互视图与资源视图的数据抽取与注入的行为实现的。
   EIO的抽取与注入（简称“抽注”）的对象是交互视图和资源视图。交互视图对象是传统意义上的用户界面，而资源视图是数据模型，描述数据结构与内容的模型，可以基于我们的GriDoc。

基于EIO的软件开发，所做的工作分为两大类：

■数据抽注：交互视图与资源视图的数据抽注；

■EIO对象构造：交互视图构造与资源视图构造；

这里，交互视图的构造是指交互视图的组成与展示；资源视图的构造，是指数据的基于模型的提供。这两项工作，都可以采用传统的方法实现，如基于浏览器的交互视图可以采用HTML+JavaScript的技术构造，而资源视图的构造，可以采用关系数据库技术、分布式文件技术以及大数据管理技术实现，也可以更方便地采用GriDoc。因此，EIO的重点是两种对象的数据抽注。
   EIO的抽注是一种数据交互模型，交互的对象是交互视图中的交互组件（一般系统称为“控件”）与数据资源。EIO抽注根据抽注的对象不同，分为“组件-资源”抽注、“组件-组件”抽注与“资源-资源”抽注三种。抽注的对象不局限与本进程与本地，可以是网络节点上的任意的符合EIO规范的视图与资源。

EIO的数据抽注属于数据流模型。由于数据流模型是图灵完备的，所以，EIO的抽注模型对于应用开发也是图灵完备的。

EIO的两种对象（交互视图与资源视图）间的两种操作（抽与注）的实现，是基于一种服务器实现的。在EIO中，这种服务器称为“抽注消息路由器”（ME）。

ME的主要功能是传递抽注指令与数据，它本身不包含用户程序的业务逻辑，亦即，对所有的EIO应用，ME都是不变的，应用程序自己的业务逻辑可以挂接在ME上（并不是集成到ME代码中），这点类似与Web Server.

支撑基于EIO方法的软件开发环境与工具称为“EIO框架”。EIO框架分运行环境（Run Time）与编程接口(API)。这些工具与环境又分为客户端与服务端两个方面。而客户端含浏览器客户端与OS客户端两类。OS客户端又根据OS的不同分为MS Windows、Android、iOS、Linux等，EIO的服务端也可以有多种实现，如基于Web server与ServLet的、基于TCP/IP的，等等，这些只涉及性能的不同，对于编程方法没有影响。

二、EIO的特点与比较

EIO方法走的是与传统的MVC（含MVC的衍生模型，如MVP、MVVM等，记为MVX）完全不同的路线。支撑MVX的方法.模式的典型的框架有Struts、SpringMVC、Python Django及ASP、JSP等。为了便于分析与比较，这里列出几个典型的MV*模型的体系示意图：

MVC的核心是通过控制器C协调与控制用户视图V和业务模型M。业务模型M可以是数据模型，也可以是一种其他的计算逻辑。V是普通的用户界面。

MVC中，C的角色是最为模糊的，它的职责没有严格的或者公认的具体规范，只是范范地规定用于协调M与V的工作，通常的理解是全面控制V与M的对接，有时也受V委托负责组织业务逻辑的实现。

例如， MVC的最典型的实现Struts框架，将用户界面映射为编程语言可以操作的结构（具体是Java Bean），然后，通过用户自己编写的Action（Java程序）实现视图与数据的交互，也实现视图委托的业务逻辑的实现。这种Action实际是通过操作视图的映射(Java Bean)实现业务逻辑。如果再加上Hibernate，将关系数据库也映射为Java Bean，则控制器C承担更多的功能：通过数据库映射访问数据。这种模式带来的问题之一是，C被大大的复杂化了。

这种模式并没有真正实现视图与控制及模型的分离。很显然，控制器C的工作，一直需要对视图了如指掌，只是有一点点改善：不需要直接了解视图，而是通过视图的映射了解视图。这个改善，对于一般的软件开发，并不能带来真正意义上的高效。

事实上，我们认为，MVC其实是一个理想化的模型，因为，一般的应用系统，很难线性地划分为M-V-C的结构。实际的情况是，M、V、C中的每个成分，都可能包含其他两个成分。典型的情况是，V中包含着控制成分与业务模型。这样，一个实际的系统的结构，可能是MVC的复合结构，如:

M(MVC)V(MVC)C(MV(C)C)

等等，因此，任何支持MVC的框架，事实上都不能真正地将业务逻辑、交互视图、视图控制三个方面完全独立出来，开发者辛辛苦苦地在MVC框架下组织代码，但得到的代码大多不是MVC的，因此，基于MVC的开发也是一种被误用了几十年的技术。这问题结论，也在MVP和MVVM中得到印证：这两个模型，都试图改善控制器的功能，使他更好地支持业MVC的分离。注意，这里说的是更好的支持，不是真正的完全支持。

MVP是可能是在发现了MVC的这些困难所作出的改进。MVP中的表示器P类似于MVC中的C，但它移到更接近V的位置，重点是受理V的请求，代理V与M交互。与MVC中的C相比，P对V的控制/受理更加细致，还作为V的事件响应器。此外，P还承担MVC中的C的其他工作。也就是说MVP将V的功能剥离了一部分，加到了MVC中的C形成的。另外，P是通接口与C通信的。

在MVC的struts实现中，组件的事件处理/响应是有视图自己处理的，视图检测到交互事件后，响应该事件，将事件提交给C（即Action）进行处理。显然，MVP可以减轻V的负担。在实际的框架中，Tapestry应该是比较接近MVP模式的一种框架。

至于MVVM（Model-View-ViewModel），与MVP十分类似，主要区别是，MVP 的P通过接口与V交互，而MVVM中的VM是通过绑定技术（标签）与V交互。

MVVM是微软的技术，其起初的名称为MVPM。MVVM的典型代表是ASP。其实，JSP之类的也属于MVVM。

EIO不沿着MVC方向发展，其着眼点不是MVC中视图、模型与控制的关系划分，而是采用一种的新的软件成分划分，其目的是简化开发工作。

从软件成分看，EIO包括交互引擎VE、消息路由器ME和资源引擎RE，但我们并不认为EIO是RE-VE-ME模式，因为，EIO还引入了抽注与抽注对象的概念，在EIO中起主导作用的是抽注，RE-VE-ME只是抽注的一种实现模式。

从广义讲，RE-VE-ME都属于控制器范畴，但与MVX中的控制器不同，首先它是服务，不试图主动控制其他部件，只是按照其他部件的服务请求去执行；其次，EIO是消息监听机制，它不主动观察V与M的状态与行为；另外，也是很重要的一环，RE-VE-ME中的三个部分都与具体应用无关，是通用于所有的应用程序的，相比之下，MVX中的控制逻辑，都是用户硬编码实现的,例如，在Struts中，用户的Action实现，必须扩展(extends)struts的Action基类，并且与struts本身的支撑代码一同编译与运行。

更重要的是，EIO将软件成分间的交互规范化了；都统一到抽取与注入操作，优点是成分间操作模型化了，可以简化编程工作量，保障软件质量。相比之下，MVX的成分间的通信是无规范的，任意的操作都可以使用。这种方式的好处是灵活性，但这种灵活性对软件开发不能带来好处，带来的是无模型的编程，编程工作量扩大。那么，EIO将错限定在抽注是否会给应用开发带来限制？我们的研究表明，抽注加消息通信也是完备的逻辑，不会因为这个限制就会使EIO不完备。

EIO也可以归为是一种 SOA。EIO中，以“服务”取代“控制”， EIO 的所有的对象都服务员，而服务员的工作也需要其他服务员（此时前者就是客户）。EIO方法中，各种成分只需要做好自己的本职工作，不存在一个集中的“控制”机构。在这种意义下，EIO也可以称为MVS模型。这种SOA体系，如同一个社会，如果人人都把自己当做服务员，做好自己的本职工作，则这种社会就是一种和谐的社会、有序的社会、高效的社会，无需庞大复杂的管理机构也能高性能地运作。事实上，一个运行着的软件，也相当于一个动态运行的社会。

SOA是公认的优秀体系结构，但遗憾的是，SOA提出后一直没有合适的框架支持这种体系，Web Service的无序、ESB的集中控制，都导致SOA不能很好贯彻。而目前的云计算应用，也局限在提供软硬件的虚拟化的服务，没有真正的实现云计算的资源的基于SOA的构造。

三、C/S模式的演变与EIO的意义

要从原理上阐明EIO的重要意义，需要分析一下C/S模式的本质与演变。

C/S的本质是将一个应用系统分成客户端与服务端两大部分。不同C与S的功能分配，可能导致不同的模式，如B/S，多层C/S与多层B/S,以至于目前的云计算模式。

（1）初期的C/S

初期的C/S中，S重要承担单纯的数据访问与处理功能，典型的是S端是数据库服务器，剩余的任务由C端负责。这样，C端除了负责用户交互界面（我们称其为“控制面板”）的功能外，还负责数据库服务器不便进行的一些数据的加工处理，如数据转换、数据重组与装配，这些功能是对从数据提取出来的数据或者是需要送往服务端的数据的加工处理，我们将这种数据处理称为“数据再处理”，当然，也可能包含其他一些业务逻辑，所以这部分统称为“应用逻辑”。

当数据的再处理任务和应用逻辑更繁重的时候，C端就会显得很“胖”，所以这种模式也称“胖客户端”模式。这种模式不仅多客户端的处理能力要求较高，而且客户端的管理与比较复杂。

（2）B/S

B/S是为了解决胖客户的问题引入的。它的理念是，将应用系统的尽可能多的功能都分配到服务端，所以称为“瘦客户”模式。从应用功能上看，所谓尽可能多的提取到客户端，也就是将初期C/S模式中的“应用逻辑”移到S端。

由于“数据再处理”的功能往往不便由数据库服务器承担，所以，这部分功能一般是与数据库服务器分离的，在服务端设置另外一个服务器，统称“应用服务器”，因此，这种结构称为三层”B|C/S”，如果进一步划分应用逻辑，则为多层模式。

这种模式的优势是减轻了客户端负载，但问题也因此产生：原本与客户端中的“控制面板”密切联系的“应用逻辑”中的成分，也被分离到远端，本来应该就地处理的东西，变成了网络通信与远端处理的，显然增加了处理的复杂性与处理代价（总体性能下降）。

目前类型的Web框架，大多属于这种模式，；例如，struts将“应用逻辑”用Action实现。由于这种模式人为地割裂了本地处理到远端，所以，struts之类的框架天生不足。

（3）云计算模式

尽管没有谁为云计算制定公认的规范，但云计算的本质可以看做是C|B/S的演变与SOA的应用。

那么，云计算是如何演变C|B/S的？从目前被声称为云计算的系统的几个典型系统看，演变重点是发生在S端：S端可以是一个对用户而言透明的分布式系统。所以，目前的面向云计算的开发框架，仍然存在上述问题。

（4） EIO模式的改变

EIO正是针对这种问题提出的。Web技术发展到今天，已经于初期有了质的变化。事实上，B/S模式的“瘦客户”是B/S的“副产品”，提出B/S的初衷是方便客户端维护，这样导致了“瘦客户”这个副产品。目前的硬件技术发展，如果再不问其他情况一味追求瘦客户，是没有进步意义的。客户端适当加肥顺应就睡觉觉软硬件的发展方向。

EIO的目标主要是降低开发复杂度、提高软件性能，为此，主要引入下列几点措施：A)以抽注描述业务逻辑；B）控制的服务化与模型化；C)适当加肥客户端；D)支持多服务端协调。

EIO首先做的是，将“应用逻辑”中的处理中不涉及服务端的逻辑“拉回”客户端；第二，将应用的主要逻辑模型化，包括数据的抽注、服务器的协同等；第三，应用服务端的共性抽取，形成可以通用的服务端。

目前流行的B|C/S模式的框架，基本上都不具备上列指出的四点。

四、EIO模式的支撑体系

EIO的实现框架，由EIO运行时、EIO-API及规范组成。

（1）EIO模式体系

EIO框架是EIO模式（方法）的支撑环境与工具。支撑体系是支撑环境与工具的体系结构，其示意图如下。

图中各主要部分说明如下：

n交互视图：是用户交互界面。包含EIO交互组件（图中带箭头的方框）。对于基于浏览器的实现，交互视图是HTML+JavaScript；对于OS-APP实现，是OS界面描述加高级语言代码。

nVE：视图抽注引擎，一般位于视图一侧，实现支撑视图的抽注操作、抽注消息传递机相关的API。

nME：抽注消息路由器，在VE与消息处理器之间传递抽注消息，同时也负责加载调用挂接在自己上面的用户某些的信息处理器。

n信息处理器MP：信息处理器负责解释与处理信息，现在形式上它是挂接在ME上的用户自定义程序，它的加载与启动由ME负责,ME充当它的容器。MP分系统预定义处理器与用户自定义信息处理器两类。系统预定义处理器一般是处理一些领域公用的业务逻辑，而用户自定义处理器是处理用户自己的应用特有的逻辑。MP的工作一般都依赖于资源引擎RE，通过与RE 通信实现对资源的抽注。

nRE：资源引擎，负责按照抽注指令操作资源，实现资源抽注。RE接受MP的抽注消息，通过调用资源工厂实现抽注逻辑。

n资源工厂：挂接在RE上的资源操作程序，分系统与定义的资源工厂与用户自定义的资源工厂。系统工厂实现领域通用的资源抽注，如GriDoc。用户自定义工厂实现用户应用特有的抽注逻辑，如对应用系统的关系数据和文件的操作。

nextV()/IntV()：针对交互视图的数据抽注操作，形式上为通用API，实现交互组件的数据注入与抽取。

nMsgReq()/MsgRes()：传递抽注操作的消息，消息里描述具体的抽取逻辑，并携带抽注的数据。

（2）EIO抽注种类

EIO抽注包括下列几种类型：

nVR抽注：即“组件-资源”间的数据抽注，实现资源供给视图与视图供给/更新资源，是EIO中最常见的抽注类型；

nVV抽注：即“组件-组件”间数据抽注。抽注的双方可以位于同一个进程，也可以位于不同的进程与不同的节点，实现交互界面间的数据交换以及基于数据交换的业务逻辑；

nRR抽注：，即“资源-资源”间的数据抽注，实现不同数据资源间的基于数据抽注的数据处理与业务逻辑。

（3）EIO框架组成

一个具体的EIO框架，主要包含下列成分：

n运行时：支撑EIO应用运行的软件成分，主要是VE、ME和RE。许多情况下，RE可以省略。这些运行时，VE位于客户端一侧，而ME都位于服务器节点上。

nAPI：支撑用户编程的程序库，分客户端与服务端两类。客户端API主要是实现抽注的API以及消息打包与解包的API。服务端API主要是服务端消息的打包与解包API。

五、EIO编程的一般过程

EIO的目标之一是简化开发技术、提高开发效率。

使用EIO只需掌握基本的程序设计语言，无需掌握其他开发框架，是JSP、ASP、PHP、Struts、SpringMVC、Tapestry以及基于Python的Web框架的一种替代品。

使用EIO开发一个应用系统，开发者所需做的主要的工作可以归纳为“3+1”：编写三种子程序和一种配置文件。三种子程序是客户端抽注请求子程序、客户端抽注响应子程序以及服务端消息处理器，一种配置文件是EIO配置文件。

客户端抽注请求子程序用于客户端向资源发出资源抽取或者注入请求，有服务端的消息路由器受理与调度。客户端抽注子程序形态根据客户端的种类确定，对于Web客户端，是采用HTML5+JavaScript编写；对于Android客户端，是采用Java编程；对Windows与Linux客户顿，采用Java和C++编程。

客户端抽注响应子程序用于响应服务端对“客户端抽注请求子程序”的抽注响应，即受理服务端消息处理器的回应消息，调用交互组件的注入操作实现交互组件的数据注入，编程方式与客户端抽注请求子程序的编写。

服务端的消息处理子程序（消息处理器）用于分析客户端抽注请求子程序发来的消息，调用相应的抽注服务，实现资源的数据注入，或者生成抽取结果，并且回送给客户端的抽注响应子程序。

EIO配置文件为XML文件，用于配置EIO的基本特性与EIO程序的调用关系。引入配置文件，旨在平衡软件开发的编码（程序设计语言程序设计，过程描述）与配置（说明性的描述）的有机结合，平衡二者的应用，简化软件开发。