总览
PE框架的结构图如下：
首先，所有的请求都转化为与渠道(如web,app,wx等)无关的的上下文(context)，这是通过连接适配器(Connection Adapter)完成的。然后请求交给责任链(Chain of Responsibility)，完成字段验证，权限验证，规则验证等安全策略。再交给业务逻辑(Business Logic)处理，由业务逻辑调用底层服务(Service)完成逻辑处理。
包含各模块的细节组成的细节图如下：
应用场景
这样一套框架是用于某类业务的，只有放到实际项目中，才能深入理解它的工作原理。
通常PE框架的应用从部署上来讲是以下架构：
一个典型的PE项目通常至少包括PWEB,MWEB,MCA,MCM,Schedule等5个应用。其中PWEB负责提供用户Web支持;MWEB提供后台管理Web支持;MCA提供用户业务逻辑服务;MCM提供后台管理业务逻辑服务;Schedule提供定时任务支持。
PWEB,MWEB部署在Weblogic或Websphere这类支持OSGI的J2EE Web容器上。而MCM,MCA,Schedule则部署在公司自行提供的J2EE容器上。
从开发角度来讲，通常PE框架的应用的源码分为3层：
- WEB层 负责前端，包含了PWEB,MWEB中的大部分bundles
- MCA层 负责业务逻辑，以及提供服务。包含了MCA,MCM,Schedule中的大部分bundles
- ROUTER层 负责与Other System通信的路由层。包含了MCA,MCM,Schedule中需要与银行其他系统通信的bundles。
虽然源码进行了分层，也进行了分应用独立部署，但我认为并没有很好的体现SOA思想，原因两点：
- PWEB应用与MCA应用,MWEB应用与MCM应用之间虽然采用了RPC，但MCA/MCM应用提供的服务是“伪服务”，一个前端的Action直接映射一个后端的ActionService，并通过父类和配置的方式间接调用其
service方法，导致ActionService中是混乱的业务逻辑流，而非清晰抽象的服务，抽象程度不够。 - MCA层中的bundles在MCA应用、MCM应用、Schedule应用中重复的使用了，因此这些服务仅局限应用中OSGI服务的存在，而非以独立的服务应用存在。