基于面向构件的应用架构，一个完整的应用系统的开发可能涉及到6个层次的开发，形成展现构件、业务构件、基础构件、数据构件、流程构件、页面构件，这些构件在引擎（展现引擎、业务引擎、数据引擎）的支撑下实现运转，整个应用的表现形式如下图所示：

应用的具体执行过程如下：
1.页面的表单（Form）通过提交（Submit）后，通过HTTP通讯协议传到WEB服务器上，WEB容器将获得的表单数据以及调用对象传递给展现引擎

2.展现引擎将表单（Form）数据转换为数据总线上的RequestContext数据区的内容，其中表单输入域(Input)的Name以xpath的形式映射成RequestContext数据区的节点路径，输入域的值（Value）则成为节点的值。同时，展现引擎将根据表单（Form）的Action获得对应的展现逻辑调用路径，根据展现逻辑的逻辑调用顺序找到第一个处理节点进行处理，如果处理的节点是调用一个业务逻辑，则将业务逻辑路径以及业务逻辑需要的数据传递给业务引擎

3.业务引擎将展现引擎传递的信息产生BizContext数据区，根据对应的业务逻辑的运算逻辑进行依次的调用，调用过程中，只能对BizContext的数据进行操作

4.当业务逻辑中执行某些进行数据库处理的运算逻辑时，将由数据引擎根据指定的数据区某个位置（通过Xpath指定）的数据和指定的操作动作(如分页查询)结合对应的数据实体的定义实现对数据的存取。

5.运算逻辑完成数据库的处理或者计算处理后，相关的信息将在BizContext数据区中得到体现，执行权将交回给业务引擎，业务引擎将根据业务逻辑的调用关系执行接下来的其他运算逻辑，直到最后执行完成，在整个业务逻辑运行过程中，是共享一个BizContext的数据区的，也就是前一个操作对数据发生改变后，后一个操作就可以直接使用。业务逻辑调用完后，如果要将某些信息输出到展现逻辑的数据区，必须对业务逻辑进行输出的接口设置。

6.业务逻辑执行完成后，又将执行权交回给展现引擎，由展现引擎判断展现逻辑接下来的执行动作，直到最后定位到一个页面。同样，在整个展现逻辑执行过程中，共享一个RequestContext的数据区，前一个业务逻辑调用后如果存在返回，将改变RequestContext的数据区内容，后一个操作就可以直接使用，最后，RequestContext的数据区内容都将输出到页面JSP页面通过Tag的方式将数据呈现到浏览器客户端的用户界面上。

整个流转调用过程可以从下图中清晰看到：

那么，面向构件的应用怎么支持分布式应用的特性呢？概念上，一个面向构件的应用中，构件包是开发和部署的基本单元，也是分布式处理的基本单元。一个面向构件体系的技术实现，应该支持构件包的分布式部署。

在具体实作上，例如在EOS中，是基于底层J2EE提供的分布式特性来实现的。在EOS中开发的面向构件应用，部署时会为每个构件包配置相应的数据源和JNDI的协议、地址和端口，如下图：

这些配置信息被保存在EOS的系统表EOSEjbRegister中。例如有以下配置记录：

【说明】jnp是JBOSS提供的JNDI协议，iiop是WebSphere提供的JNDI协议，t3是Weblogic提供的JNDI协议。

一个构件包和对应的一个部署单元标示确定了一种部署方式，譬如BNOM构件包配置了2中部署方式，分别部署在JBOSS和WebSphere上。一般构件包缺省的部署单元标志为0，表明部署在本地。数据源是通过应用服务器配置的，通过此处设置完成构件包与数据源的映射。需要说明的是，开发时为降低复杂程度，可以不采用数据源的连接方式，而是直接使用JDBC配置（参见安装注意事项章节），如果采用JDBC配置方式，则上面的设置将无效。

部署时完成了以上的配置后，运行时业务引擎在对业务逻辑进行调用时，将会根据相应构件包的配置信息，决定是采用远程的EJB调用，还是本地调用，保证以构件包为单元的分布式部署和运行。另外，部署后的业务逻辑，通过EOS业务引擎提供的对外接口，使得外部应用可以基于EJB、WEB Service、JMS等方式对业务逻辑进行调用。所以，在基于EOS开发应用时，并不需要考虑EJB实现以及分布式处理的问题，这些工作都通过EOS Server实现了封装，大大简化了应用开发的技术细节。