在描述EOS的技术路线和产品内容时，都会重点提到数据总线的概念。的确，如果在开发中真正理解了基于数据总线的数据传递机制，开发起来将会得心应手游刃有余。这个神秘的数据总线在EOS中到底是什么东西呢？为什么要在EOS中引入这样一个东西呢？
总所周知，标准的J2EE应用中数据传递是基于对象传递的，一个实例化后的对象既包括数据，同时也包括一些操作，执行过程是通过调用对象的方法，同时将包含数据的对象作为调用方法的参数传递进去进行相应的操作。在EOS应用中，结合J2EE WEB应用的特点，将运行时的数据根据不同层次和作用范围以XML格式被独立封装到3个不同的内存数据区中。分别为会话数据区（SessionContext）、请求数据区（RequestContext）和业务处理数据区（BizContext），这几个数据区就构成了EOS的数据总线。
RequestContext数据区是根据HTTP Request对象建立的，封装了HTML页面上通过post或者get方式提交的表单数据以及一些系统信息（如客户端IP、请求的URI等），这个数据区能够被表单中的Action对应的展现逻辑直接进行读取，也能通过EOS提供的JSP页面TAG读取数据显示在页面上，系统为每一次客户端请求建立一个专有的RequestContext数据区，当系统完成响应（Respone）后该数据区失效。
SessionContext数据区是根据HTTP Session对象建立的，封装了WEB容器中的用户的会话信息，这些Session信息是通过展现逻辑的数据设置接口写入的，也可以通过数据设置接口获得SessionContext的数据后写入到RequestContext数据区中。JSP页面通过TAG可以直接获取SessionContext的数据。SessionContext的数据区在一个WEB会话建立时创建，在会话保持期间可以存取其中的内容（一般通过展现逻辑实现），当会话结束或超时后，该数据区失效。
BizContext数据区在调用某个业务逻辑时为该业务逻辑实例建立的数据区，展现逻辑调用业务逻辑时可以将RequestContext的部分数据通过接口设置传入到业务逻辑的数据区，业务逻辑执行过程中也可以通过调用不同的运算逻辑改变BizContext数据区的内容。当业务逻辑执行完返回到展现逻辑时，可以将BizContext数据区的部分内容通过接口设置传回到展现逻辑的数据区中，与此同时，BizContext数据区的生命周期失效。
以下是各个数据区的数据传递关系图：
由图可见，SessionContext的数据不能直接传递到业务逻辑的BizContext数据区中。如果在业务逻辑中需要使用SessionContext数据，需要在调用业务逻辑的展现逻辑中先将SessionContext的数据传入到RequestContext数据区中，再由展现逻辑将传入到RequestContext数据区的Session信息传入到业务逻辑对应的数据区BizContext中。通过以下图示，我们可以看到开发的各个构件逻辑是怎样通过各种引擎实现数据的转换或者传递的。
由上图我们可以看到，假定页面1的表单（Form）提交时，调用展现逻辑1，表单数据将会形成数据区实例RequestContext1，展现逻辑分别调用了业务逻辑1和业务逻辑2，在调用业务逻辑1时，指定传入了部分数据给业务逻辑1，在业务逻辑1的实例启动后，同样会建立业务逻辑实例1的数据区实例BizContext1，在处理完成后，返回部分数据到RequestContext1，BizContext1的生命就结束了，展现逻辑实例1以同样方式调用业务逻辑实例2，调用结束后，业务逻辑实例2的数据区实例BizContext2也可能返回了部分信息到RequestContext1中，这样RequestContext1通过调用业务逻辑后数据与之前有了变化，这些数据又可以显示到用户页面2上，然后RequestContext1的生命周期就结束了。页面2上进行一次新的调用，又开始了新的执行过程，可见，不同数据区是根据不同的实例产生的，并随着实例执行的结束而结束，每种实例都拥有响应类型的数据区实例。
通过以下表格对各个数据区的特点进行总结：
基于XML数据总线实现应用的数据流转，使得应用各个层次耦合度更加松散，更加便于与外部系统实现集成，而系统却在数据处理上具有了很强的扩展性。这些优势将在后续的培训内容中以具体的案例进行验证。
