在描绘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数据总线完成运用的数据流通，使得运用各个层次耦合度愈加松懈，愈加便于与外部体系完成集成，而体系却在数据处理上具有了很强的扩展性。这些优势将在后续的培训内容中以详细的事例进行验证。
