在较传统的基于EJB或者XML-RPC的分布式计算模型中，它们的服务提供都是通过函数调用的方式进行的，一个功能的完成往往需要通过客户端和服务器来回很多次的远程函数调用才能完成。在Intranet的环境下，这些调用给系统的响应速度和稳定性带来的影响都可以忽略不计，但如果我们在基于SOA的架构中使用了很多Web Service来作为服务提供点的话，我们就需要考虑性能的影响，尤其是在Internet环境下，这些往往是决定整个系统是否能正常工作的一个关键决定因素。因此在基于SOA的系统中，推荐采用大数据量低频率访问模式，也就是以大数据量的方式一次性进行信息交换。这样做可以在一定程度上提高系统的整体性能。
架构的生命期构成
整体架构设计过程组
架构分解结构(五横三纵架构)
知识领域:服务参考模型
架构侧面系(生命周期模型和4+视图)
一.7
应用架构分解结构中的基础支撑层中的系统软件尽量按照RA标准实现，如不能满足，架构上应考虑松耦合的互连互通，保障符合RA标准的服务库和应用系统能够和本应用架构协同。
另外RA为应用架构分解结构中的服务开发运行体系提供支撑机制，如ESB等。
6．可维护性
指在不影响系统其他部分的情况下修改现有系统功能中问题或缺陷的能力。
当系统刚被部署时，你很难判断一个系统是否已经具备了很好的可维护性。当创建和设计系统架构时，要想提高系统的可维护性，你必须考虑下面几个要素:低耦合、模块性以及系统文档记录。在企业系统可扩展性中我们已经提到了SOA架构能为系统中暴露出来的各个子功能模块也就是服务带来低耦合性和很好的模块性。关于系统文档纪录，除了底层子系统的相关文档外，基于SOA的系统还会引用到许多系统外部的由第三方提供的服务，因此如果人力资源准许的话，应该增加专职的文档管理员来专门负责有关整个企业系统所涉及的所有外部服务相关文档的收集、归类和整理，这些相关的文档可能涉及到第三方服务的接口(可以是WSDL)、服务的质量和级别、具体性能测试结果等各种相关文档。基于这些文档，就可以为SOA架构设计师构建企业SOA架构提供很好的文档参考和支持。
良好做法，指一致认为，正确应用这些技能、工具和技术能够增加范围极为广泛的各种不同架构设计成功的机会。良好做法并不是说这些知识和做法一成不变地应用于或应当应用于所有的架构设计：
架构设计团队负责架构的裁剪和扩展。
本指南还旨在作为该职业和实践一个共同的术语汇编，为讨论、书写和应用架构设计方面的问题提供便利。这种术语汇编是一种职业必不可少的组成部分。
7．可管理性
指管理系统以确保整个系统的可升级性、可靠性、可用性、性能和安全性的能力。
具有可管理性的系统，应具备对服务质量需求(QoS)的系统监控能力，通过改变系统的配置从而可以动态地改善服务质量，而不用改变整体系统架构。一个好的系统架构必须能够监控整个系统的运行情况并具备动态系统配置管理的功能。在对复杂系统进行系统架构建模时，SOA架构设计师应该尽量考虑利用将系统整体架构构建在已有的成熟的底层系统框架(Framework)上。
8．安全性
指确保系统安全不会被危及的能力。
目前，安全性应该说是最困难的系统质量控制点。这是因为安全性不仅要求确保系统的保密和完整性，而且还要防止影响可用性的服务拒绝(Denial-of-Service)攻击。这就要求当SOA架构设计师在构建一个架构时，应该把整体系统架构尽可能地分割成各个子功能模块，在将一些子功能模块暴露为外部用户可见的服务的时候，要围绕各个子模块构建各自的安全区，这样更便于保证整体系统架构的安全。如果一个子模块受到了安全攻击，也可以保证其他模块相对安全。如果企业SOA架构中的一些服务是由WebService实现的，在考虑这些服务安全性的时候也要同时考虑效率的问题，因为WS-Security会为Web Service带来一定的执行效率损耗。
5．可扩展性
指在不影响现有系统功能的基础上，为系统添加新的功能或修改现有功能的能力。
当系统刚配置好的时候，你很难衡量它的可扩展性，直到第一次你必须去扩展系统已有功能的时候，你才能真正去衡量和检测整个系统的可扩展性。任何一个架构设计师在构建系统架构时，为了确保架构设计的可扩展性，都应该考虑下面几个要素:低耦合，界面(interfaces)以及封装。当架构设计师基于SOA来构建企业系统架构时，就已经隐含地解决了这几个可扩展性方面的要素。这是因为SOA架构中的不同服务之间本身就保持了一种无依赖的低耦合关系;服务本身是通过统一的接口定义(可以是WSDL)语言来描述具体的服务内容，并且很好地封装了底层的具体实现。
一.4
SOA电子政务总体应用架构设计就是把各种知识、技能、手段和技术应用于架构活动中，以达到系统建设和系统整合的要求。
架构设计必须权衡质量、时间、范围和费用等方面的要求。
其中：
下面介绍几个通常会在系统设计中涉及的质量属性。
1．性能
指系统提供的服务要满足一定的性能衡量标准，这些标准可能包括系统反应时间以及处理交易量的能力等。
高质量的架构设计还考虑了技术风险应对的因素。
应对变化，权衡不变与变化是架构设计永恒的主题。
架构设计中还必须考虑SOA的独特性,例如：服务分类方法等。
[1]按服务在系统建设中的用途划分：
[2]按服务的功能划分：
基本服务：数据中心的服务和逻辑中心的服务
中介服务：技术网关、适配器、外观、装饰服务
以流程为中心的服务
高层管理人员
项目发起人
项目经理
架构设计师
需求人员
开发人员
测试人员
客户
一.10
第二章
二.1
二.1.1
SOA设计方法并非全新的方法论，而是继承了传统的面向对象的设计方法以及面向过程的设计方法，同时又增加了SCA,，SDO，BPEL等技术，融入了面向服务的设计方法，服务参考模型OASIS RM里的内容映射，具体内容包括服务定义、服务设计、服务管理、服务开发、服务测试和服务部署。
本指南还提供了一个参考的电子政务应用架构，并结合一个具体案例讲解如何在电子政务领域进行基于SOA的应用架构设计。
本指南用来指导电子政务领域政务系统建设和政务系统之间的整合任务的架构设计。
而附录B列出了架构设计资料的其他来源。
一.2
SOA-RA-TF制定的《SOA参考架构白皮书》
SOA-AP-TF制定的《SOA电子政务总体技术架构与解决方案》
二.1.2
传统的数据建模方法学是面向一个应用系统内部的实体的建模方法学，而在当前数据整合、应用整合的需求下，数据建模还要考虑在不同系统间进行数据交换和数据共享的需求。基于业务效率的考虑，从业务流程出发的思路改变了数据模型。只有你从业务流程的角度来看待数据的时候，数据模型才能算真正完成。
二.1.3
阐述了一种以实现流程优化的流程系统设计思想。这种设计思想是面向业务流程的，不同于传统MIS系统面向部门职能的设计思想。首先把系统设计区分为原理层设计和技术层设计两个层次，然后从业务流程设计、数据模型设计和技术架构设计三个方面论述了原理层设计的基本思想。
3．可靠性
指确保各应用及其相关的所有交易的完整性和一致性的能力。
当系统负荷增加时，系统必须能够持续处理需求访问，并确保系统能够象负荷未增加以前一样正确地处理各个进程。可靠性可能会在一定程度上限制系统的可升级性。如果系统负荷增加时，不能维持它的可靠性，那么实际上这个系统也并不具备可升级性。因此，一个真正可升级的系统必须是可靠的系统。在基于SOA来构建系统架构的时候，可靠性也是必须要着重考虑的问题。要在基于SOA架构的系统中保证一定的系统可靠性，就必须要首先保证分布在系统中的不同服务的可靠性。而不同服务的可靠性一般可以由其部署的应用服务器或Web服务器来保证。只有确保每一个SOA系统中的服务都具有较高的可靠性，我们才能保证系统整体的可靠性能够得以保障。
一.3
长风联盟依据《国家电子政务总体框架》，遵循国家电子政务标准，参照《北京市电子政务总体技术框架》，结合长风联盟SOA电子政务解决方案的实际情况，制定出长风联盟SOA总统技术架构。目标是作为长风联盟企业实施SOA架构的电子政务系统的标准型、指导性框架，实现未来电子政务系统的互联互通、资源共享，并使联盟企业可以快速、流畅、高效地构建各类政务应用系统,保障以该架构为标准的各类政务应用通畅运行。该架构将成为未来电子政务实施的重要指导。该架构又称为“五横三纵架构”。
通常可以根据每个用户访问的系统响应时间来衡量系统的整体性能;也可以通过系统能够处理的交易量(每秒)来衡量系统的性能。对于架构设计师来说，无论采取哪种衡量系统性能的方法来构建系统架构，这些对于性能的考虑对系统设计开发人员来说都应该是透明的，也就是说对于系统整体架构性能的考虑应该是架构设计师的工作，而不是系统设计开发人员应该关注的事情。
一.8
本指南假定架构设计在项目环境下进行。
应用架构设计受到一定环境因素的影响和约束，并反过来对这些因素产生影响：
应用领域标准规范
组织过程资产
公司战略要求
技术环境
项目要求
管理因素
架构设计和项目管理和组织日常运作管理是密切相关的，但本指南不涉及相关内容，请参考相关书籍和文献资料。
一.9
架构设计要考虑架构设计干系人的要求。
二.1.4
大型IT系统的设计通常遵循七层架构的设计方法，包括：
界面层
该层是直接面向用户（包括公众、企业、业务人员、行政管理人员、领导等使用者）的统一的系统界面。界面层利用业界主流的IT技术支持多种渠道接入和交互（如互联网、电话、手机短信等接入方式），以及统一的身份认证及权限管理。
长风联盟电子政务
总体应用架构设计指南研究报告
长风开放标准平台软件联盟
二○○七年五月
第一章
一.1
基本目的是识别SOA电子政务领域应用架构设计知识体系普遍公认为良好做法的那一部分。
识别，指一般概括性介绍，而非详尽无遗漏的说明。
普遍公认，指介绍的知识和做法在绝大多数情况下适用于绝大多数的架构设计，其价值和实用性也得到了人们的广泛认同。