EOS原理-FL.docVIP

EOS原理 EOS与J2EE EOS与J2EE的关系 J2EE：是提供了一套多层分布式计算体系规范 EOS：EOS可以看做是一个构件化的虚拟层，是对J2EE的每个层次做一个构件化的解析，EOS不是取代J2EE，而是对J2EE的各个层次进行翻译。如下图所示： EOS与J2EE Application Model J2EE Programming Tasks 页面展现端的工作 编写JSP页面 FORM请求的servlet或者action 修改web.xml或者其他xml配置文件 业务逻辑的编制工作 Session Bean Entity Bean SQL语句 EJB配置文件 J2EE Application Model如下图所示： EOS Application Model如下图所示： EOS与MVC的关系 EOS构件运行管理环境是基于MVC结构实现的，并在Model层做了扩展，把Moble层次封装成业务层（业务引擎）和数据层（数据引擎），实现业务与数据的分离，大大提高总体架构的复用性和可扩展性，EOS集成开发环境对EOS的MVC结构各层次构件提供了可视化构件开发和组装环境。具体如下图所示： EOS与Struts的关系 EOS 在展现层参考了Struts的结构，下图是标准的struts结构。 下图为EOS的结构 实现过程的对比 传统互联网应用的实现过程 普元EOS的互联网应用实现 构件技术对比 传统构件技术：传统的构件技术都是基于方法（函数）接口的构件技术，构件提供的接口方式都是基于对象的接口，这样各构件之间不具备任意相互连接的功能。构件之间的接口定义变的异常复杂，很难维护，复用度较低。如下图所示： EOS构件：EOS的构件的接口是数据式接口，每个构件与数据总线相连接，进行数据交换，这些就避免了构件间复杂的数据交换，使得构件接口变得非常简单。如下图所示： EOS总体结构图 EOS产品构成 EOS运行机制 EOS基本运行流程 1、页面的表单（Form）通过提交（Submit）后，通过HTTP通讯协议传到WEB服务器上，WEB容器将获得的表单数据以及调用对象传递给展现引擎 2、展现引擎将表单（Form）数据转换为数据总线上的RequestContext数据区的内容，其中表单输入域(Input)的Name以xpath的形式映射成RequestContext数据区的节点路径，输入域的值（Value）则成为节点的值。同时，展现引擎将根据表单（Form）的Action获得对应的展现逻辑调用路径，根据展现逻辑的逻辑调用顺序找到第一个处理节点进行处理，如果处理的节点是调用一个业务逻辑，则将业务逻辑路径以及业务逻辑需要的数据传递给业务引擎 3、业务引擎将展现引擎传递的信息产生BizContext数据区，通过是根据对应的业务逻辑的运算逻辑进行依次的调用，调用过程中，只能对BizContext的数据进行操作，每个运算逻辑实际就是一个java方法，例如取当前日期时间、设置数据区中节点的值等 4、当业务逻辑中执行某些进行数据库处理的运算逻辑时，将由数据引擎根据指定的数据区某个位置（通过Xpath指定）的数据和指定的操作动作（如分页查询）结合对应的数据实体的定义实现对数据的存取。 5、运算逻辑完成数据库的处理或者计算处理后，相关的信息将在BizContext数据区中得到体现，执行权将交回给业务引擎，业务引擎将根据业务逻辑的调用关系执行接下来的其他运算逻辑，直到最后执行完成，在整个业务逻辑运行过程中，是共享一个BizContext的数据区的，也就是前一个操作对数据发生改变后，后一个操作就可以直接使用。业务逻辑调用完后，如果要将某些信息输出到展现逻辑的数据区，必须对业务逻辑进行输出的接口设置。 6、业务逻辑执行完成后，又将执行权交回给展现引擎，由展现引擎判断展现逻辑接下来的执行动作，直到最后定位到一个页面。同样，在整个展现逻辑执行过程中，共享一个RequestContext的数据区，前一个业务逻辑调用后如果存在返回，将改变RequestContext的数据区内容，后一个操作就可以直接使用，最后，RequestContext的数据区内容都将输出到页面 7、JSP页面通过Tag的方式将数据呈现到浏览器客户端的用户界面上。 EOS构件引擎的运行原理 1、从浏览器发起HTTP请求，提交到展现引擎。 2、展现引擎将请求转换为XML，并根据HTTP请求（构件包.构件.构件逻辑.do）确定被调用的展现逻辑，转到处理展现构件描述的展现逻辑。 3、根据展现逻辑流程中定义的业务逻辑，传入业务引擎，并且送入相关的XML数据。 4、业务引擎根据调用的业务逻辑中的流程调用相关的运算逻辑。 5、对于需要访问数据库的操作通过数据引擎(Data Service)根据数据映射调用相关的数据库