卷烟零售客户是烟草行业最宝贵的资源，在日常的服务过程中，信息沟通的准确性和及时性是工作的难点。因此，如何创新服务方式，提升服务水平便成为了落实精准服务，全面推进营销工作上水平的思考方向。通过微平台传递特色服务，提高信息沟通的准确性，达成新型客我关系。作为烟草商业企业，面对众多经营能力各异，服务需求不同的零售客户，仅仅通过常规的拜访落实服务工作，客户经理的服务水平与营销效率难以得到提升，服务同步也就无从谈起。
烟草公司、零售户、消费者等众多参与者构成了一个生态系统，我们相信在这个系统中，再小的个体也有服务需求，而庞大的个体数量让服务具备个性化和差异化等特点。微平台通过消除烟草公司和服务对象之间的沟通距离，进行实时的交流和反馈，从而满足不断增长和变化的服务需要，达到全面提升服务质量和水平的目的。微平台基于以下几点进行设计：
一、进行有价值的服务
零售户和消费者是烟草行业最核心的资源，每个客户都有着自己的需要，给客户提供有价值的服务，才能够真正的打动客户，进而促成和谐双赢的伙伴关系。微平台通过收集和分析，制定相应的服务策略，服务模式由单一的服务内容向分类分层服务提升，实现服务从无目标、无重点、履行任务式的客户拜访向目的明确、重点突出的客户提升式的服务转变，提升客户的满意度和忠诚度。
二、消除地理上的限制
地理曾经是过去的一个商业上的一个重要因素，但从移动互联网以来，所有的人都能够卷入到一种跨越时空的一种交流里面。烟草公司很难和消费者直接对话，微平台通过公众账号采集消费者的需求和回馈，从而收集市场信息和市场波动，这在过去是难以想象和实现的。
三、用户价值第一底线
微平台通过集结零售客户和消费者，加深相互之间理解和信任，加强相互间的黏度和互动，通过“微会员”、“微点评”、“微留言”、“微活动”、“微客服”等“互联网+”时代的沟通方式，保护和坚守用户价值第一的底线。
综上所述，微平台通过不断满足卷烟经营的新需求，不断满足零售户和消费者的服务需要，推行主动式的服务和覆盖式的服务，打好“服务”这张牌。
一、全省统一设计原则
二、先试点、后推广原则
三、需求全面规划、分步实施原则
从需求规划上充分考虑各个业务部门、各个服务主体的需求，全面覆盖烟草工业、烟草商业、零售户和消费者的需求点，及未来发展可能存在的需求。
在项目实施中，建设的全过程中应当在整体需求规划的指导下进行，先期完成的项目内容在完成本部分功能要求的同时要为后期实施的项目留出必要的接口，保证项目的整体完整性。
按照短平快的要求，完成工商零消服务平台的建设，投入使用。
四、不断探索、不断优化原则
另外鉴于本项目与安徽现有项目的密切关联的重要性，系统设计将重点在以下原则进行考虑：
1.安全性
系统具有实时的数据备份功能，自我校验和纠错功能，可以保证数据的存储及读取的安全，以及数据交换的安全和一致性，并对网络中传输的数据采取必要的加密措施。
2.可靠性
3.实时性
4.扩展性
系统有很好的扩展功能，有良好的兼容性、可移植性，能够通过功能扩展以适用业务发展的需要。
5.先进性
系统设计应采用先进的、成熟的且可持续发展的技术方法，并充分体现先进的管理思想和理念，与实际相结合。
6.合理性
在系统设计时，充分考虑系统的容量及功能的扩充，方便系统扩容及平滑升级。系统对运行环境(硬件设备、软件操作系统等)具有较好的适应性，不依赖于某一特定型号计算机设备和固定版本的操作系统软件。
7.可行性
软件系统的开发设计，应确保技术上的可行性，适合招标人的核心需要，满足主要功能需求，适应需求变化时的系统的免代码自定义和功能模块加减、调整。
8.规范性
遵循国家局、烟草行业及安徽烟草商业企业有关标准要求及业务管理规范，信息分类编码标准化、信息接口标准化。
9.整体性
10.经济性和冗余性
系统设计紧贴客户需求，同时为可能的增值服务留有空间，具有良好的性价比。系统留有适度的冗余，既可满足近期业务发展的需求，又不会过多增加系统负荷。
11.操作简便性
系统人机界面友好，操作简便，可以使用快捷键完成部分操作。
12.可管理性和可维护性
系统充分考虑了应具有的良好的可管理性和可维护性。
总体架构分为展现层、应用层、支撑层、数据层四个层次：
1、系统的总体结构采用B/S/D浏览器/服务/数据库的三层结构，系统中采用B/S结构，遵循J2EE体系架构。内外部应用均按照J2EE规范，使用java、jsp、servlet等技术，实现系统所需管理功能。
2、系统采用面向服务的架构（SOA），符合WebService标准的访问接口，应用软件要使系统模块化、构件化，以适应管理、业务流程的变化和使用权限的再分配。
商业通过承担平台运营成本和提供各种便捷服务，可以获得，消费者的消费信息、采集到市场的数据，提供客户满意度，同时通过公众号，实现品牌的网上营销。
本系统在技术架构上将完全符合安徽烟草信息化建设的总体技术框架。与安徽烟草目前已建的统一门户、营销、物流、三项工作等信息系统采用相同的技术平台,后台与门户系统进行有效集成和整合，保持技术的延续性和一致性，实现业务系统的统一身份管理、统一权限管理和统一界面管理，前端采用HTML5开发，支持各种智能手机。
J2EE应用服务器（ApplicationServer）采用目前国际最先进的开发理念、拥有许多适合基于Web的应用系统需求的特点：
三层结构体系——最适合Internet/Intranet网络环境，可以使系统有很强的可扩展性和可管理性。
分布式环境——可以保证系统的稳定性，同时拥有较高的性能。
面向对象的模块化组件设计——可以提高开发速度，降低开发成本。
采用JAVA技术——完全跨平台，适应Internet需要，并能得到大多数厂商支持，保护用户投资。
为了降低成本，并加快企业应用程序的设计和开发，J2EE平台提供了一个基于组件的方法，来设计、开发、装配及部署企业应用程序。J2EE平台提供了多层的分布式的应用模型、组件再用、一致化的安全模型以及灵活的事务控制。使用户不仅可以比以前更快的速度向市场推出创造性的客户解决方案，而且，平台独立的、基于组件的J2EE解决方案不会被束缚在任何一个厂商的产品和API上。
J2EE提供了一个企业级的计算模型和运行环境用于开发和部署多层体系结构的应用。
J2EE的应用模型图
客户层（ClientTier）
J2EE应用可以是基于Web的，也可以是不基于Web的。
在基于Web的J2EE应用中，用户的浏览器在客户层中运行，并从一个Web服务器上下载WEB层中的静态HTML页面或由JSP或servlets生成的动态HTML页面。
Web层
J2EEWeb组件可以由JSP页面、基于Web的applets以及显示HTML页面的servlets组成。
调用servlets或者JSP页面的HTML页面在应用程序组装时与Web组件打包在一起。就像客户层一样，Web层包括一个JavaOraclens类来管理用户输入，并将输入发送到在业务层中运行的EnterpriseOraclens类来处理。
运行在客户层的Web组件依赖容器来支持诸如客户请求和响应及EnterpriseOraclen查询等。
业务层
作为解决或满足某个特定业务领域（比如山西烟草、银行、或零售业）需要的逻辑的业务代码由运行在业务层的EnterpriseOraclens来执行。一个EnterpriseOraclens从客户程序处接收数据，对数据进行处理（如果需要），再将数据发送到企业信息系统层存储。一个EnterpriseOraclens还从存储中检索数据，并将数据送回客户程序。运行在业务层的EnterpriseOraclens依赖于容器来为诸如事务、生命期、状态管理、多线程及资源存储池等提供通常都是非常复杂的系统级代码。
业务层经常被称作EnterpriseJavaOraclens（EJB）层。业务层和Web层一起构成了3层J2EE应用的中间层，而其它两层是客户层和企业信息系统层。
企业信息系统层
企业信息系统层包括企业的各种业务系统和数据库。
什么是SOA（ServiceOrientedArchitecture，SOA）？许多销售商、应用程序供应商、系统集成商、架构师、作者、分析公司和标准机构对SOA都提供了定义。SOA的定义是多种多样的，实际上更多的是对SOA定义的补充，且众多定义相互之间是不冲突的。面向服务代表在商业和IT环境下关于服务的一种思考方式，SOA拥有各种各样的定义是因为定义通常要针对一个特定的对象，如给一个CEO解释SOA与给一个程序员解释SOA是不同的。SOA是一个范式、一种思考方式，SOA对于架构和设计是一个有价值的系统。SOA是一种帮助系统发展过程中保持可扩展性和灵活性的方法，也是解决业务与IT缺口的桥梁。
SOA是一种应用架构思想，它着眼于日常的业务应用，并将它们划分为单独的业务功能和流程，即所谓的服务。SOA使用户可以构建、署和整合这些服务，且无需依赖应用程序及其运行计算平台，从而提高业务流程的灵活性。这种业务灵活性可使企业加快发展速度，降低总体拥有成本，改善对及时、准确信息的访问。SOA有助于实现更多的资产重用、更轻松的管理和更快的开发与部署。在当今的业务环境中，变化是毫无疑问的，因此快速响应客户需求、市场机遇和外部威胁的敏捷性比以往任何时候都更显重要。
面向服务的SOA体系架构的特点：
1、以业务为中心
2、灵活适应变化
IT系统围绕用户业务构建，用户业务在实现层通过表现为一系列松散耦合的”服务“来实现，这些服务可以根据用户需求随需组合，使得IT系统对于业务的适应能力明显提高。
3、重用IT资源，提升开发效率
SOA强调对”服务“的重用，对原有IT资源的重用度提升是SOA带来的关键效果之一，大量具有高重用的服务资源，为快速构建新的业务功能和业务系统奠定基础，使得IT系统的开发和软件生产效率得到提升。同时，重用过程有利于保护用户前期的信息化投资和IT资产积累，节省IT系统开发成本，实现用户信息化的可持续性建设与发展。
4、更强调标准
SOA的实现强调基于统一的标准，SOA系统建立在大量的开放标准和协议之上，以实现系统及信息的互联互通和互操作。因此，SOA系统从规划到实施，标准都至关重要。
SOA使得应用系统的设计清晰化而且促进组件的重用。应用系统中所有的接口的定义与信息模型――包括数据及其语义、对象与过程模型――都高度一致。很多的企业应用由于缺乏同一的长远的规划，通常情况下很少共享数据，几乎从不共享程序逻辑。但很多的服务具有通用性，而非某一应用独有，一个通用服务架构（CommonServiceArchitecture）能帮助企业在上述的原则下共享部分数据和程序逻辑。通用服务的概念是企业架构中的一个重要的有机部分，主要包括下面的通用服务：
1）通用应用服务：如通用的数据模型访问，数据的转换等等。
2）通用基础设施服务：包括应用的管理与诊断、日志、安全、系统的操作与维护。
3）通用系统服务：包括对不同的操作系统、网络平台以及其它的系统层的功能提供与平台独立的接口。
典型的企业SOA平台连接许多企业应用资源，应用用户，并且负责许多服务提供者和服务消费者。通过把服务划分为相同服务的组来得到管理效果。一个普通服务组使后台系统（BES）资源对于服务消费者可用。另一个普通服务组连接应用用户或者前端系统（FES）到SOA平台。
编排服务连接基本服务到复合服务。将服务分组的做法可以有效的利用SOA平台每层统一的特点。适当领域的技术，开发模式，测试装置，部署配置，系统管理制度等，能为每层具体开发。
分层架构是最灵活强大的实现方法。简单来说，SOA的服务来自于由后台系统（BES）直接封装后提供的一组接口，也就是存取服务。
整合逻辑也将被看作一组服务，此服务有良好定义的已发布接口。这些服务是更高水平的服务，它利用更低水平的后台系统（BES）存取服务。这些服务实现被称作编排或协调的功能。
最后，在一个企业整合环境中，这些更高水平协调或更低水平存取服务的大多数用户应用将不直接支持服务接口。因此，另一组服务被要求组织服务具体到每个服务用户前端系统（FES）。
这给出了分成架构的基础，如下图所示：
SOA平台层次图
这个架构中有三层。每层有唯一一组技术需求和唯一的作用。
存取服务层负责发布一组BES（后台系统）的接口作为一个标准的服务。
协调服务层重新分组服务来实现整合逻辑。
用户服务负责使FES（前端系统）可以访问其它两层发布的服务，这些服务通常是FES（前端系统）不能直接进行调用的。
存取服务层提供由集成平台其余部分执行的终端服务。这层的关键架构的中心是设计和管理服务的重用。设计和开发存取服务需要应用资源域的技术，适配器开发和设置技术和消息组模型技术。
存取服务层是被发布的服务来提供单一后台系统（BES）的接口，主要目标是在平台上实现最大化的重用。其它层通过控件或通过一个发布接口来存取这些服务。它最简化的形式仅仅是一个通过控件来暴露的后台系统（BES）。例如一个J2EE连接架构适配器（J2EECA）数据库适配器被安装和设置来把一个特殊的系统和每个需要的SQL语句所产生的服务连接到一起。然后这能够通过整合应用视图控件来存储。
协调服务层主要是完成传递新的服务的功能，这些新的服务是对存取服务层提供服务的一个重新组织。本层的主要架构特点是灵活性。协调服务层通过正确实现数据集中、流程定义、以及创建理想服务的MessageFlow工具实现了这种灵活性。
在这层中需要实现各种的集成逻辑，并发布成为一个完整的服务。本层利用访问存取层向前端系统（FES）提供有意义的服务。
任何利用多于一个EIS系统的服务都需要纳入到这一层中来。对于通过worklist实现人为交互的服务也需要纳入到本层中来。正如上文中对于访问存取层的描述，一些协作层中的服务可能仅访问一个后台系统（BES）系统。如果这些服务需要完成功能包含集成的需求而不仅仅是来自单个后台系统（BES）系统，他们也同样应台包含在协作服务层中。适用于本层的一个简单原则：任何不属于消费层或访问存取层的服务都属于协作服务层。
独立的数据集成服务，如提供数据转换、数据映射（包括主键映射）、数据依赖路由的服务需要驻留在协作层。
请求服务层的主要目的是负责平台和应用服务请求者（例如前端系统（FES）系统）之间的连接，本层服务提供：
协议映射－映射为服务发布接口协议：JMS和WebServices。
Paradigm映射－同步到异步以及vice-versa。
数据映射－数据格式映射，聚集等。
服务请求者包括基于多种架构的应用，还有包括胖客户端、消息系统、套接字协议等在内的遗留系统服务请求者。一般都需要协议解释服务。对于支持诸如Portal，B2B服务，多渠道等平台协议，paradigm和数据格式的请求者，可以与平台直接接口。
值得指出的一点是在审视从前端系统（FES）到后台系统（BES）系统之间的端到端通信时，这些层次都不是强制必须实现的。正如前文所讲述的，请求服务层仅当需要提供对SOA平台的标准接口技术进行访问时才是必要的。若一个前端系统（FES）本身支持SOA平台的标准，那么前端系统（FES）就可以直接访问其提供的服务，而跳过请求服务层。同样的，对于一些简单的集成需求，如查询独立系统中的可用数据就不需要进行服务的重组。当然，推荐的方式是永远不要忽略访问存取层，它保证了后台系统（BES）提供的各种服务在整个平台中保持一致性和灵活性。它还避免了跳过所有层次的设计场景的出现，因此可以保证满足平台管理原则。
端到端的视角
还有一点值得一提，在一个集成场景中，很多系统既是后台系统（BES）又是前端系统（FES），当然也不排除一些纯前端系统（如Portal）和固有后端系统（如数据库）的存在。当进行双向松耦合通信（如使用JMS）时，一个双向的集成需求可以转为实施两个单向的通信。这是一个在相同业务流程中既作前端系统（FES）又做后台系统（BES）系统的例子。
存取访问层和请求访问层中以基本的服务居多，而协作层中多为复合类型的服务。
作为一个一般的规律，服务最好以无状态的方式展示以获取最佳的性能，采用异步模式调用来保持与其客户端的松耦合状态。
无论如何，已经确证若访问存取层的双向服务是异步的，协作层服务将变为有状态的。因此拥有无状态、异步服务的期望是不能在所有层中得到满足的。作为一种权衡考虑，对于双向通信场景来说，在松耦合和性能之间最好的折中方式是在低层次的访问存取层中尽可能实现同步服务（例如后台系统（BES）系统中的服务都实现同步调用），而在较高层次的协作层中实现异步服务。
高层次的设计架构
更进一步的细节
双向访问存取层的服务应尽可能的使用同步方式。
协作层服务服务通常应采用异步方式。
这样可以最大限度的做到松耦合。
上述两点可以保证包含一个请求服务层服务，一个协作层服务，以及多个访问存取层服务的双向调用典型场景的最佳性能。在这类情况中，只要后台系统（BES）接口允许，所有的除请求服务层之外的服务都采取无状态方式。
上表中第二条标准（异步协作层服务）在屏蔽后端系统实施更改方面有着突出的优势，使后端的变化对协作服务层客户端来说是透明的。无论是访问存取层服务提供同步抑或异步接口，它都可以在协作层中保留一个异步接口。
有些场景很适合同步交互模式－Portal对SOA平台服务的访问就是其中一种。通过以下的标准可以做出是否合适与上述场景的判断：
对于请求者的最初响应取决于由目标后台系统（BES）发出的响应。
目标后台系统（BES）在峰值负荷下可以提供更快的响应。
目标后台系统（BES）需要更高的可用性。
在这些场景中，建议以同步方式实现服务，但是要借助非同步模式来为协作层服务提供异步接口。因此，那些不需要高吞吐量的客户端可以使用异步接口。
为了更高的性能，尽可能使用同步服务。
一些用例的非功能需求需要更快的响应和更高的容量。
为同步协作层服务提供一个异步接口，提供更多的松耦合特性。
第二个接口的实现需要利用非异步模式。
在某些场景中，访问存取层服务需要异步耦合方式，例如，需要访问一个复合协作服务，而不是一个事务性、非XA的资源。在这种情况下，最佳的方式为保持访问存取层服务的同步模式，且需要以非同步模式进行实施。
高层次设计架构更进一步的细节
如果需要异步调用一个同步存取访问层服务，保持服务的同步模式，但是以非同步方式实施。项目特定的需求不应阻碍访问存取层服务的可重用性。
在如今的企业信息化应用系统的开发中，应该采用通行的MVC模式来构建应用。这种结构解决了前面所述的所有问题，可以完全地支持它的实现。MVC的逻辑图如下：
MVC模式
通过这种方案，可以迅速地实现整个业务，其优势和特点如下：
Model层由EJB组件来实现，EJB将具体的业务封装在组件内部，具备安全、高性能、可重用等优秀的特征。
Controller是非常重要的一层，这一层是连接View和Model的纽带，同时也是将这两层进行最大限度分离的工具。通常由Servlet来实现，Servlet和JSP虽然同样都属于页面展示工具，但分属两层。主要在于JSP以脚本语言的形式存在，它的主要优势是进行动态数据的Web展示，而Servlet是一个完整的Java程序，进行业务的调用和流程的处理是它的长处。
通过这种模型的建立，的应用系统具备了非常好的性能和可扩展性。将业务组件和展示页面进行分离，并通过Controller来描述调用关系，一方面可以提高效率，另一方面也可以增加系统扩充的能力，使的系统可以适应最快速度的业务扩展。
典型的J2EE三层结构，分为表现层、中间层（业务逻辑层）和数据服务层。三层体系将业务规则、数据访问及合法性校验等工作放在中间层处理。客户端不直接与数据库交互，而是通过组件与中间层建立连接，再由中间层与数据库交互。
表现层是传统的JSP技术，自1999年问世以来，经过多年的发展，其广泛的应用和稳定的表现，为其作为表现层技术打下了坚实的基础。
中间层采用的是流行的Spring+Hibernate，为了将控制层与业务逻辑层分离，又细分为以下几种。
Web层，就是MVC模式里面的“C”（controller），负责控制业务逻辑层与表现层的交互，调用业务逻辑层，并将业务数据返回给表现层作组织表现，该系统的MVC框架采用Struts。
Service层（就是业务逻辑层），负责实现业务逻辑。业务逻辑层以DAO层为基础，通过对DAO组件的正面模式包装，完成系统所要求的业务逻辑。
DAO层，负责与持久化对象交互。该层封装了数据的增、删、查、改的操作。
PO，持久化对象。通过实体关系映射工具将关系型数据库的数据映射成对象，很方便地实现以面向对象方式操作数据库，该系统采用Hibernate作为ORM框架。
Spring的作用贯穿了整个中间层，将Web层、Service层、DAO层及PO无缝整合，其数据服务层用来存放数据。
在传统的程序结构中，只要有一点小的需求发生改变，将意味着放弃整个页面。或者改写。虽然前期的开发速度快，除非可以保证以后永远不会改变应用的结构，否则不要采用这种结构。
采用Hibernate作为持久层技术的最大的好处在于：可以完全以面向对象的方式进行系统分析、系统设计。
DAO模式需要为每个DAO组件编写DAO接口，同时至少提供一个实现类，根据不同需要，可能有多个实现类。可以用Spring容器代替DAO工厂。
通常情况下，引入接口就不可避免需要引入工厂来负责DAO组件的生成。Spring实现了两种基本模式：单态模式和工厂模式。而使用Spring可以完全避免使用工厂模式，因为Spring就是个功能非常强大的工厂。因此，完全可以让Spring充当DAO工厂。
由Spring充当DAO工厂时，无须程序员自己实现工厂模式，只需要将DAO组件配置在Spring容器中，由ApplicationContext负责管理DAO组件的创建即可。借助于Spring提供的依赖注入，其他组件甚至不用访问工厂，一样可以直接使用DAO实例。
Struts跟Tomcat、Turbine等诸多Apache项目一样，是开源软件，这是它的一大优点。使开发者能更深入的了解其内部实现机制。
除此之外，Struts的优点主要集中体现在两个方面：Taglib和页面导航。Taglib是Struts的标记库，灵活动用，能大大提高开发效率。另外，就目前国内的JSP开发者而言，除了使用JSP自带的常用标记外，很少开发自己的标记，或许Struts是一个很好的起点。
关于页面导航，我认为那将是今后的一个发展方向，事实上，这样做，使系统的脉络更加清晰。通过一个配置文件，即可把握整个系统各部分之间的联系，这对于后期的维护有着莫大的好处。尤其是当另一批开发者接手这个项目时，这种优势体现得更加明显。
软件行业的技术更新很快，虽然软件行业的发展不快，但小范围的技术更新特别快。一旦由于客观环境的变化，不得不更换技术时，如何保证系统的改变最小呢？答案还是选择优秀的架构。而SSH开发框架正是这样一种优秀的框架。
它可以让开发人员减轻重新建立解决复杂问题方案的负担和精力；它可以被扩展以进行内部的定制化；并且有强大的用户社区来支持它。它的好处主要表现以下两个方面：
1、开发效率
2、需求的变更
一般来说，很少有软件产品的需求从一开始就完全是固定的。客户对软件需求，是随着软件开发过程的深入，不断明晰起来的。因此，常常遇到软件开发到一定程度时，由于客户对软件需求发生了变化，使得软件的实现不得不随之改变。当软件实现需要改变时，是否可以尽可能多地保留软件的部分，尽可能少地改变软件的实现，从而满足客户需求的变更？答案是——采用优秀的解耦架构。这种架构就是J2EE的分层架构，在优秀的分层架构里，控制层依赖于业务逻辑层，但绝不与任何具体的业务逻辑组件耦合，只与接口耦合；同样，业务逻辑层依赖于DAO层，也不会与任何具体的DAO组件耦合，而是面向接口编程。采用这种方式的软件实现，即使软件的部分发生改变，其他部分也尽可能不要改变。
组件化是企业信息化应用系统建设的一个整体趋势。由于组件所具有预制性、封装性、透明性、互操作性、通用性的特征，这使得“Writeonce，Runeverywhere”成为技术上的可能。
组件化的整体架构一个最明显的好处就是组件的开放只涉及到业务逻辑的开发和将业务逻辑的接口用标准的接口进行封装，而那些重要和复杂的系统基础服务（infrastructureservice），如状态管理（StateManagement）、交易（Transaction）、安全、资源池（ResourcePooling）等等。
采用组件技术可以实现灵活的接口定义、执行代码运行时刻的联编/载入以及通讯网络协议，支持异构分布应用程序间的互操作性及独立于平台和编程语言的组件重用。
组件化的整体架构具有下面这些优势：
1）多功能容器，对外部屏蔽了复杂度；
2）适合于大量并行开发；
3）“黑盒”组件的实现鼓励了更多的灵活性；
4）可进行针对接口的测试；
5）封装后的组件在可以在内部修改业务逻辑，而保持同样的接口，形成一个屏蔽变化的“防火墙”；
6）在使用上有更好的一致性；
以组件为基础的应用架构大大简化多层（Multi-tier）和Web应用的开发，利用应用服务器来避免应用客户端和数据库及其它企业信息系统（EntepriseInformationSystem，EIS）的连接。客户端使用高层（high-level）的与平台独立的调用方式通过应用服务器访问数据库及其它企业信息系统。这样不仅屏蔽了企业内部IT架构的复杂性和异构性，也使得这样开发的应用具有良好的可移植性。
系统分层模型
1、不得跨层调用，每一层都只与直接相临的层进行通信。
2、上面各层都建立在下层的基础上，隐藏下层的信息并为上层提供服务。
3、各层要封装自己的实现，向前一层提供访问接口。
4、各层支持分布式的部署，即可部署于不同的容器实例中。
客户层
系统最终用户的使用界面和设备。包括基于浏览器的瘦客户端和基于GUI的胖客户端应用。
1、尽量减少与后台的交互。
2、界面符合用户的使用习惯。
2、是客户层的统一接入点。
业务逻辑的接口，实现业务流程的控制，是业务领域层的服务接口。
1、可以使用类似Session的模式实现。
2、启动事务控制。
3、公共的业务逻辑要集中处理。
根据业务需求进行抽象的业务对象模型，包括业务规则和逻辑处理的实现。
对系统的各种资源和外部系统统一的访问逻辑的实现。不作语义转换，只实现纯粹的资源访问。
各种信息系统资源，例如：RDBMS、文件系统、原有系统、消息服务、邮件服务、交易服务中间件等。
本系统支持的中间件包括weblogic、webspere在内的等主流中间件，以及包括Oracele/DB2/SqlServer等在内的业界主流大型数据库。