软件架构学习小结

软件架构设计系统总体架构，从需求到设计的每一个细节都要考虑到，把握整个项目，使设计的项目尽量效率高，开发easy，维护方便，升级简单。本文从架构师职责、软件架构定义、设计架构、评估架构、架构管理等方面来描写叙述了解软件架构的含义和如何设计软件架构。

 

一、软件架构师的职责

架构师分为下面几大类：业务架构师、主题领域架构师、技术架构师、项目架构师（J2EE架构师、.NET架构师等）、系统架构师。

1、架构师的职责主要体现

架构师的职责就是设计一个公司系统的基础架构，并提供关于如何建立和维护系统的指导方针。详细来讲，架构师的职责主要体如今下面几方面：

1）、负责公司系统的架构设计、研发工作。

2）、承担从业务向技术转换的桥梁作用。

3）、协助项目经理制定项目计划和控制项目进度。

4）、负责辅助并指导系统分析开展设计工作。

5）、负责组织技术研究和攻关工作。

6）、负责组织和管理公司内部的技术培训工作。

7）、负责组织及带领公司内部员工研究与项目相关的新技术。

8）、管理技术支撑团队并给项目、产品开发实施团队提供技术保障。

9）、理解系统的业务需求，制定系统的总体框架（包含、技术框架和业务框架）。

10）、对系统框架相关技术和业务进行培训，指导开发者开发。并解决系统开发、执行中出现的各种问题。

2、构架设计师必须具备的技能

经验：既包含在问题领域的经验（通过彻底了解需求），也包含在软件project领域的经验。对于一个构架团队，这些素养要求可由各团队成员来分别承担，但当中至少要有一名构架设计师可以把握项目的全局。

领导才干：可以推动各个团队的技术进展，并能在压力下作出关键性的决策然后将其贯彻究竟。要提高效率，构架设计师和项目经理必须紧密协作。构架设计师主要负责解决技术问题，项目经理主要负责解决行政管理问题。构架设计师必须有权在技术问题上作出决定。

沟通：可以赢得他人的信任，以对其进行说服、激励和指导。构架设计师不能靠命令进行领导，而必需要赢得项目中其它人员的赞同。为了提高效率，构架设计师必须赢得项目团队、项目经理、客户、用户群体以及管理团队的尊敬。

以目标为中心、积极主动：不懈地追求成效。构架设计师是推动项目发展的技术动力，而不是空想家。在其职业生涯中，成功的构架设计师一直都要在捉摸不定和承受压力的情况下作出折衷决定。构架设计师仅仅有将注意力集中在该做的事情上，才干在项目中取得成功。

专业：精通构架设计的理论、实践和工具，并掌握多种參考构架、基本的可重用构架机制和模式（比如J2EE架构等）。具备系统设计员的全部技能，但涉及面更广、抽象级别更高。

 

二、软件架构、架构模式、參考模型、參考架构

1、对于软件架构定义有非常多种，通用的定义是：某个软件或计算机系统的软件架构是该系统的一个或多个结构，他们由软件元素，这些元素的外部可见属性以及这些元素之间的关系组成。

这里所说的某个元素的“外部可见属性”是指其它元素对该元素所做的如果，如它所提供的服务、性能特征、错误处理、共享资源的使用，等等。

其它的定义包含：架构是一种高层设计。架构是系统的整体结构。架构是一个软件或系统的组件、组件之间的相互关系以及管理其设计和演变的原理和方针的结构。架构是组件和连接器。

2、架构模式是对元素和关系类型以及一组对其使用方式的限制的描写叙述。

3、參考模型是一种考虑数据流的功能划分。

4、參考架构是映射到软件元素（它们相互协作，共同实如今參考模型中定义的功能）及元素之间数据流上的參考模型。

5、软件架构、架构模式、參考模型、參考架构之间的关系：

软件结构	关系	适用环境
分解	是一个子模块；与之共享秘密	资源分配、项目结构化和规划；信息隐藏、封装；配置控制
使用	要求正确出现	设计子集；设计扩展
分层	要求正确的出现、使用服务、提供抽象	增量式开发；在“虚拟机”可移植性之上实现系统
类	是一个实例；共享訪问方法	在面向对象的设计系统中，从一个公共的模版中产生高速的、相近的实现
客户机-server	与之通信；依赖于	分布式操作；关注点分离；性能分析；负载平衡
进程	与之并发执行、可能会与之并发执行；排除；优先于等	调度分析；性能分析
并发	在同样的逻辑线程上执行	确定存在资源争用，线程能够交叉、连接、被创建或被杀死的位置
共享数据	产生数据；使用数据	性能；数据完整性；可改动性
部署	分配给；移植到	性能、可用性、安全性分析
实现	存储在	配置控制、集成、測试活动
工作分配	分配到	项目管理、最佳利用专业技术、管理通用性

注：在＜Pattern-Oriented Software Architecture (面向模式的软件体系架构) ＞中首次提出了8种体系结构模式： 层（Layers）、管道和过滤器(Pipes and Filters) 、黑板(Black board )、代理者（Broker）、模型-视图-控制器（Model-View-Controller）、表示-抽象-控制（Presentation-Abstraction-Control）、微核（Microkernel）、映像（Reflection）。

6、架构定义中指出系统由多种结构构成的，以下列出一些常见的结构。

 

7、质量属性

系统从设计、实现到部署的整个过程中考虑质量属性的实现。质量属性包含下列三类：

（1）、系统的质量属性。（可用性、可改动性、性能、安全性、可測试性和易用性）

（2）、受架构影响的商业属性。（上市时间、成本和收益、所希望的系统生命期的长短、目标市场、推出计划、与老系统的集成）

（3）、与架构本身相关的一些质量属性。（概念完整性、正确性与完整性、可构建性）

六个质量属性的战术列表：

 

 

三、设计架构

差点儿在我们遇到的全部成功的面向对象系统中都具有但失败的系统中缺少的两个特性是：存在一个强大的构架构想，应用管理良好的迭代式增量开发周期。功能、质量和商业需求的某个集合“塑造”了构架。我们把这些塑造需求称为“构架驱动因素”。

构架设计必须按需求分析进行，但不须要在需求分析完毕后在開始构架设计。实际上，在确定了关键的构架驱动因素后，就能够開始构架设计了。当设计了构架的足够多的部分后，就能够開始开发骨架系统了。该骨架系统在上面进行迭代开发（以及其在不论什么一个点交付的能力）的框架。组织结构对构架产生影响。

属性驱动的设计(ADD)是一个用于设计构架以满足质量需求和功能需求的方法。ADD把一组质量属性场景作为输入，并使用对质量属性实现和构架之间的关系的了解，对构架进行设计。

ADD步骤：

（1）       选择要分解的模块。

（2）       依据这些步骤对模块进行求精。

对须要进一步分解的每一个模块反复上述步骤。

在设计架构过程中能够重用架构，重用一些技术以方便来实现架构与设计。高层重用技术分类

 

高层重用

设计模式

框架

软件架构

架构风格

架构设计风格

架构框架

架构平台

设计模式：使用相互通信的类和对象可为常见的设计问题提供通用的解决方式。为了帮助用户掌握模式的概念并有效地设计模式，我通常为设计模式的描写叙述提供一个带有比喻性的抽象。常见的设计模式有：Fvacade（外观模式），它为子系统中的一系列动作提供一个统一接口；Ovbserver（观察者模式），详细的设计模式内容參考GOF23设计模式。

框架：提供一组相互协作的类及执行时对象，用于生成某些特定领域的应用软件。我们能够依据特定应用的需求方便地对框架中的抽象和类进行定制，以重用框架的设计和代码。

软件架构：编制软件也称为架构软件。一个可操作的软件内部应具有某种形式的架构。软件架构技术中可重用的实体能够进一步地分为4类：架构风格、架构设计风格、架构框架、架构平台。

架构风格给出了精心设计的软件全局的通用形态。比如，Shaw和Garlan提出了7种架构风格：管道和过滤器、面向对象的组织、隐式调用、分层系统、仓库、状态机、解释器，及过程控制。

架构设计风格给出了软件架构的设计方法论。Shaw将众多的设计风格分类为例如以下8种：功能分解、数据流、面向对象、状态机、面向事情、过程控制、数据结构及决定表。

架构框架是来为具体而完整的框架，它为开发特定领域的应用系统使用了一系列多种架构设计风格。一个採用了某些设计风格的软件架构制品，仅仅有当它具有完备的文档，并具备包括一个特定的应用领域所须要的充分灵活性时才干够作为软件框架来重用。

架构平台提供了一个能够适应多种应用系统的灵活的底层结构，架构平台的设计目的即是为了应用软件的互操作性提供硬件平台及操作系统平台无关环境。我们能够将它们用做底层结构，以促进对象级的协作和重用。对象管理组织(OMG)的通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA）即是一个演示样例。

 

四、架构评估方法

软件构架的评估方法：SAAM和ATAM。这里仅仅具体说明ATAM方法。

ATAM一种进行构架评估的综合方法，ATAM是评估软件构架的一个健壮的方法。在该方法中，项目决策者和涉众要清晰地阐述一个准确的质量属性需求列表（以场景的方式），并说明与实现每一个高优先场景相关的构架决策。然后，把这些决策确定为有风险决策或无风险决策，以找到构架中不论什么存在问题的地方。

ATAM不是需求评估。

ATAM不是代码评估。

ATAM不包含实际的系统測试。

ATAM不是一个准确的手段，但它识别了构架中可能存在风险的区域。这些风险包括在敏感点和权衡中。

ATAM活动的4个阶段：

在第0阶段（合作关系和准备）确定细节：人员名单，时间，地点；评估小组获取资料并进行初步了解分析。

第1阶段，评估阶段，决策者參与，小组開始信息收集与分析；耗时约1周。1～2周中断期，评估小组进一步以非正式方式了解构架。

第2阶段，评估阶段，涉众參与，分析继续；约2天。

第3阶段，兴许阶段，生成终于报告，进行评估活动总结；1周。

评估阶段的步骤：

第1步：ATAM方法的表述。评估负责人向决策者表述ATAM方法，使大家理解其过程，了解角色布局。

第2步：商业动机的表述。决策者介绍系统商业动机、重要功能、各种限制（不论什么相关的技术、管理、经济和政治限制）、商业目标和上下文、基本的涉众、驱动因素等。

第3步：构架的表述。首席设计师或架构小组介绍构架，技术限制、所用模式等。

第4步：对构架方法进行分类。评估小组利用全部已知信息对构架方法进行分类。

第5步：生成质量属性效用树。生成质量属性效用树，捕获具体的需求信息，为每一个场景分配一个级别，如（高，中），前者为重要度，后者为实现难易度，重点放在（高，高）的场景；此处场景具备刺激、环境、响应三要素就能够了。

第6步：分析构架方法。评估小组分析全部重要场景，设计师解释怎样支持该场景，检查所用构架方法，分析风险点、权衡点、敏感点。

经过一段中断期，第2阶段開始，此时涉众開始參与；首先仍然须要一个对ATAM方法的介绍，并使涉众了解已有的成果。

第7步：集体讨论并确定场景的优先级。集体讨论并分析场景的优先级，以了解更广泛的涉众的想法；该过程可能产生新的场景；使用“有限票数法”投票确定每一个场景的优先级——此处不考虑实现难度。

第8步：分析构架方法。分析新的高优先级的场景，构架师解释构架是怎么满足各场景的。

第9步：结果表述。总结评估结果，评估负责人展示该结果。

 

五、软件架构风险管理

1、怎样识别软件架构的风险

（1）需求的不断变化

（2）架构师对于技术理解不足

（3）缺乏对行业的研究

（4）经验不足

（5）创造性的架构比重比較重

（6）没有形成一套构架的规范

（7）架构可运行性差

2、怎样规避软件架构风险

固化需求

完好的业务原型

完整架构规范

验证架构的可运行性

80%的经验架构+20%的创新架构

 

六、有用软件体系结构

本部分是提供有用的指南和技术，以更快地得到好的系统结构设计。我们的哲学是不应该致力于设计理想化的系统结构，而是应该细致地评估和权衡全部技术、市场、人员、成本方面的问题，从而获取一个好的解决方式。

4种视图+全局分析

1、4种视图

1）、一个软件体系结构有4种截然不同的视图：概念视图、模块视图、运行视图、代码视图。

使用这个4种视图提供了一种设计软件系统结构的系统化方法，帮助架构师设置优先级，分析权衡，并保证没有缺漏。

2）、不同视图强调的不同project关注点：

在概念视图中，问题和解决方式主要通过领域术语来考虑的。对于特定的软件及硬件技术，它们应当是相对独立的。概念视图的工厂关注点包含：

系统怎样满足需求？

商用构件如何组装成总体，如何在功能层上与系统的其它部分交互？

领域特定的硬件和软件怎样融入系统？

功能是怎样被切割并进入产品个版本号的？

系统怎样与之前版本号的产品合并？它怎样支持未来的版本号？

怎样支持产品线？

怎样将由需求或领域中所做的变动引起的影响最小化？

在模块视图中，概念视图中的构件和连接子被映射为子系统和模块。在这里，架构师强调的是怎样用现有的软件平台以及技术实现概念的解决方式。基本的project关注点有例如以下几点：

产品是怎样映射到软件平台的？

使用了什么样的系统支持或系统服务？详细是在什么地方？

怎么支持測试？

怎样减少模块间的依赖性？

怎样将模块与子系统的复用最大化？

当商用软件、软件平台或标准发生变动时，採用何种技术在封装产品时能够将它们与产品进行隔离？

运行视图描写叙述模块怎样映射到运行时平台说提供的元素，以及这些又怎样映射到硬件体系结构。运行视图定义系统的运行时实体及其属性，比方内存使用和硬件分配。对于运行视图，其project关注点例如以下：

系统怎样满足性能、恢复及又一次配置方面的需求？

怎样平衡资源的使用（比如：负载平衡）？

怎样达到必需的并发、复制及分布，而只是度添加�控制算法的复杂度？

怎样使执行时平台的改变所引起的影响到达最小？

在代码体系结构视图中，架构师决定运行视图中的运行时实体怎样映射到部署构件（比如：可运行构件），决定模块视图中的模块怎样映射到源构件，以及部署构件怎样从源构件生成。代码视图中重要的project关注点例如以下：

怎样减少产品升级的时间和费用？

怎样管理产品版本号及公布？

怎样减少构造时间？

须要什么工具支持开发环境？

怎样支持集成与測试？

 

2、全局分析

全局分析是在定义概念、模块、运行和代码系统结构视图之前进行的，并贯穿整个系统结构的设计过程。

全局分析从识别影响体系结构设计的因素来分成3类：组织因素、技术因素、产品因素。

组织因素分成5类：管理；员工技能、兴趣、能力、缺点；过程与开发执行环境；开发进度；开发预算。

技术因素包含：通用和专用的硬件；操作系统、用户界面、设计模式等软件技术；模版和框架等体系结构技术；图像、数据库、数据格式、算法和技术之类的标准。

产品因素是描写叙述了产品的功能需求、用户可见的特征和产品的性能等质量方面的需求。比方：功能特征；用户界面；性能；依赖性；错误监測、报告、修复；服务和价格等。

全局分析是在每一种体系结构设计视图中都要进行的一种行为。在全局分析过程中建立的问题卡片要用在每个视图设计的核心设计任务中。在进行核心设计任务时，做出的决策应当能够返回到全局分析，以添加�和改动因素、问题和策略。

总结策略：

问题	应用策略
进度紧迫	复用内部已有的、领域特性构件 购买而不是建立 使元素easy加入�和删除
技能不足	避免使用多线程 封装多进程
通用和领域特定硬件的改变	封装领域特定硬件 封装通用硬件
软件技术的改变	使用标准 为外部构件开发产品特定的接口
资源有限	限制活动线程个数 用动态的内部线程见通信联系
易用添加�和删除特性	按关联尺度分离构件和模块 特性封装到分开的构件 分离用户交互模块
易用添加�和删除採集过程和算法	为图像处理使用灵活的流水线模块 为採集和图像处理引入构件 分离用户交互模块
高吞吐量	把独立的控制线程映射到进程 使用新增的CPU
实时採集性能	从没有临界时间构件中分离出有临界时间的 为模块行为开发准则 灵活的分配模块到进程 使用单速分析来预言性能 使用共享存储进行流水线阶段之间通信
实现恢复	引入操作的恢复模块 把所有数据放到恢复稳定和easy达到的地方
实现诊断	制定一个错误处理策略 降低错误处理的工作 封装诊断构件 使用标准日志服务
体系结构的完整性	保护模块间的继承 分离公共接口构件
并发的开发工作	从源构件中分离开发构件 保护运行视图 採用阶段开发 通过静态库来公布层
限制可使用的採集图像类型	採用适当的抽象开发一个脱机的探測模拟器 使用一个灵活的建立过程
多样性开发和目标平台	分离和封装依赖目标平台的代码

 

七、特定领域框架

1、框架：一组类或组件的集合，它们为一个特定领域提供了一组服务和功能。软件架构的一种实例，它能够使设计的组件具有良好的互操作性。

2、框架分类

依据作用域能够将框架分为系统基础结构框架、中间件集成框架、企业应用框架。

系统基础结构框架是一组能够支持系统基础结构领域的高校可移植框架，比如能够支持操作系统、用户界面、通信及语言处理等，它们一般是由内部开发和使用的，有时也用作供其它应用使用的通用应用。

中间件集成框架的作用是增强软件对基础结构的模块化处理能力、重用能力及扩展能力，从而可以在分布式环境中无缝执行。中间件集成的样例有OmniBuilder框架和对象请求代理(ORB)。

企业应用框架处理的应用领域非常广，如银行、电信、制药等，它们是领域应用的基石。企业应用中著名的实例有IBM SanFrancisco、企业资源规划（ERP）。

框架类别	框架实例
企业应用框架	Amulet，IBM SanFrancisco，Asyn，LAMA，CORTAN，OMAC框架
中间件集成框架	GUI,QC Services Layer，PFC/Open，OmniBuilder，PFX,FrameData Feed Handler框架
系统基础结构框架	Protocol Layer，ACE,OPTF,DynaFind，ARES,DORB框架

3、框架比較

应用框架调查的比較參数包含操作系统、程序设计语言、领域范畴等。

1）、操作系统：Windows、UNIX、Linux

2）、语言：C++、Java

3）、领域范畴

拥有框架最多的两个领域是商务/金融和电信/网络。

框架领域范畴

编号	领域范畴	框架列表
1	通用（无领域）	MaccApp，G++
2	通用GUI	GUI,Amulet，Visible Properties and Actions Framework
3	数据库和数据管理	FRAMEWARE,PFX（持久性框架），ROA’D，QC Services Layer框架，Advanced Software Architecture Platform
4	商务和金融	Asyn，SanFrancisco,BOOF,PFC/Open Frame，Omni Builder，Rule Parsing，File Parsing，CSFramelets
5	保险	Asyn，SanFrancisco
6	医疗	HBOC应用框架，Medical Business Object框架，Advanced Software Architecture Platform,Philips New York Project（开发中）
7	教育和娱乐	Multimedia框架
8	电信和网络	适应性面向对象事件过滤框架，Advanced Software Architecture Platform，CORTAN,Protocol Layer框架，ACE,SIGAL,DORB,Jadve
9	工业和制造业	OMAC,PrismTech BOF和CORBA服务
10	软件开发	CLOS Meta Object Protocol，G++,OPTF,LAMA

 

八、企业应用架构模式

做企业应用开发须要了解一些企业应用开发基础知识，比方分层架构、WEB表现、业务逻辑、数据库映射、并发、会话、分布策略等等。通过使用场景、解决方式、UML等手段具体介绍了设计模式（包含一些经常使用的设计模式GOF23）。以下这些模式是干什么的、它们解决什么问题、它们是怎样解决这个问题的。这样，假设你碰到相似的问题，就能够从中找到对应的模式。能够为你节约成本、缩短项目周期时间、避免风险，以确保项目能够完美的完毕。

1、三个基本层次：表现层、领域层、数据源层

层次	职责
表现层	提供服务，显示信息（比如在Windows或HTML页面中，处理用户请求（鼠标点击、键盘敲击等），HTTP请求，命令行调用，批处理API）
领域层	逻辑，系统中真正的核心
数据源层	与数据库，消息系统、事务管理器及其它软件包通信

关于依赖性的普遍性原则：领域层和数据源层绝对不要依赖于表现层。

一旦选择了处理节点，接下来就应该尽可能使全部代码保持在单一进程内完毕（可能是在同一个节点上，也可能拷贝在集群中的多个节点上）。除非不得已，否则不要把层次放在多个进程中完毕。由于那样做不但损失性能，并且添加�复杂性，由于必须添加�相似以下的模式，如远程外观和传输数据对象。

复杂性增压器：分布、显式多线程、范型差异、多平台开发以及极限性能要求（如每秒100个事务以上）。

 

2、领域逻辑

领域逻辑的组织能够分成三种主要模式：事务脚本、领域模型、表模块。

三者之间的差别：

事务脚本是一个过程来控制一系列动作逻辑的运行。

领域模型不再是由一个过程来控制用户某动作的逻辑，而是由每个对象都承担一部分相关逻辑。这些对象能够看成是领域的不同组成部分。

表模块仅仅有一个公共的合同类实例，而领域模型对数据库中每个合同都有一个对应的合同类的实例。

3、映射到关系数据库

在使用领域模型的时候，它的读取应该把相关联的对象也一块读出来。比如，读取一个合同，应该把合同涉及到的产品和定购厂商的对象载入到内存中。由时候为了避免这些没有必要的连带读取，我们能够使用【延迟载入】模型。

读取数据的时候，性能问题可能回变得比較突出。这就导致了几条经验法则。

1）、尽可能一次查询多个记录，不要一次查询一个记录，然后进行多次查询。能够一次查询多条相关的记录，比如使用联合查询。或者使用多条SQL语句。

2）避免多次进入数据库的方法是使用连接（Join），这样就能够通过一次返回多个表。能够制作一个入口，让入口完毕相关数据的一次性读取。

3）数据库中进行优化。DBA来优化数据库。

映射到关系数据库的时候，通常会遇到三种情况：

1）  自己选择数据库方案。

2）  不得不映射到一个现有数据库方案，这个方法不能改变。

3）  不得不映射到一个现有数据库方案，但这个方法是能够考虑改变的。

最简单的情况是自己选择数据库方案，而且不用迁就领域逻辑的复杂性。当已经存在一个数据库方案的时候，应该逐步建立领域模型并包含数据映射器，把数据保存到现有的数据库中。

 

4、并发

并发问题：更新丢失和不一致读。

并发问题，人们提出了各种不同的解决方式。对于企业应用来说，有两个很重要的解决方式：一个是隔离，一个是不变性。

隔离是划分数据，使得每一片数据都可能被一个运行单元訪问。比方文件锁。

不变性是识别那些不变的数据，不用总考虑这些数据的并发问题而是广泛地共享它们。

当有一些可变数据无法隔离的时候，会发生什么样的情况呢？总的来说，我们能够使用两种形式的并发控制策略：乐观并发控制和悲观并发控制。

假设把乐观锁看作是关于冲突检測的，那么悲观锁就是关于冲突避免的。

假如Martin和David同一时候都要编辑Customer文件。假设使用乐观锁策略，他们两个人都能得到一份文件的拷贝，而且能够自由编辑文件。假设David第一个完毕了工作，那么他能够毫无困难地更新他的改动。可是，当Martin想要提交他的改动时，并发控制策略就会開始起作用。源码控制系统会检測到在Martin的改动和David的改动之间存在着冲突，因而拒绝Martin的提交，并由Martin负责指出如何处理这样的情况。假设使用悲观锁策略，仅仅要有人先取出文件，其它人就不能对该文件进行编辑。因此，假如是Martin先取出了文件，那么David就仅仅能在Martin完毕任务并提交之后才干对该文件进行操作。

 

多种技术处理死锁：一种是使用软件来检測死锁的发生。还有一种是给每个锁都加上时间限制，一旦到达时间限制，所加的所就会失效，工作就会丢失。

 

软件事务常常使用ACID的属性来描写叙述。

原子性（Atomicity）：在一个事务里，动作序列的每个步骤都必须是要么所有成功，要么所有的工作都将回滚。部分完毕不是一个事务概念。

一致性（Consistency）：在事务開始和完毕的时候，系统的资源都必须处于一致的、没有被破坏的状态。

隔离性（Isolation）：一个事务，直到它被成功提交之后，它的结果才对其它全部的事务是可见的。

持久性（Durability）：一个已提交事务的不论什么结果都必须是永久性的，即“在不论什么崩溃的情况的能保存下来”。

大多数企业应用是在数据库方面涉及到事务的，但还有非常多情况要进行事务控制，比方说哦消息队列、打印机和ATM等。为了处理最大的吞吐率，现代的事务处理系统被设计成保证事务尽可能短，尽可能不让事务跨越多个请求；尽可能晚打开事务。

 

5、分布策略

按类模型进行分布的方法不可行的主要原因与计算机的基本特点有关。进程内的过程调用很快。两个对立进程间的过程调用就慢了一个数量级。在不同机器间执行过程又要慢一两个数量级，取决于网络拓扑。

本地接口最好是细粒度接口。但细粒度不能非常好地用在远程调用中。分布对象设计第一定律：不要分布使用对象，大多数情况下是使用集群系统。

 

6、应用集成的四种主要方式：文件传输、共享数据库、远程过程调用、消息传递。利用文件传输和共享数据库，应用可以共享它们的数据，但不能共享功能。远程过程调用使应用可以共享功能，可是这会让应用紧耦合。消息传递使应用可以共享功能，让应用松耦合。执行消息传递，可以使用可定制的格式频繁地、马上地、可靠地、异步地数据传输包。本书主要是环绕消息传递方式来集成应用，完毕企业集成模式、设计、构建及部署。书中也介绍了消息是如何传递的，我们不须要全然理解，那个对我来说太难了。我们须要熟悉WebSphere MQ、MSMQ、JMS等消息服务产品，然后利用它们能开发企业集成系统，特别是金融业、保险业企业集成系统。

应用之间的集成解决方式必须应对下面几个基本挑战：

■网络是不可靠的。

■网络速度慢。

■不论什么两个应用都是不同的。集成解决方式须要在使用不同编程语言、不同操作平台和不同数据格式的系统之间传送信息。

■改变是难免的。应用会随着时间改变。

开发者使用下面四种主要方法克服上述挑战：

1、  ）文件传输——一个应用写文件，之后还有一个应用读这个文件。为此，应用之间须要协商文件名称、文件的位置、文件格式、文件读写的时间以及谁负责删除这个文件。

2、  ）共享数据库——多个应用共享同样的数据库，这个数据库位于独立的物理数据库中。因为不存在反复保存的数据资料，因此不必将数据从一个应用传给还有一个应用。

3、  ）远程过程调用——一个应用开放其部分功能，使得其它应用可以远程訪问这些过程。它们之间的通信是实时、同步的。

4、  ）消息传递—— 一个应用向公共消息通道中公布一个消息，其它应用能够在之后某个时间从通道中获得这个消息。应用之间必须协商建立通道以及消息的格式。这样的通信是异步的。

每种方法均有其独特的长处和不足。实际上，应用之间可通过多种方法集成，使得每一个集成点都能充分利用最合适的方法。

消息传递开发商的产品大致划分为下面四类：

1、  ）操作系统。消息传递已经成为开发商把必要的软件基础设施集成到操作系统或数据库平台中的共同须要。比如，Windows 2000和Windows XP操作系统包括了Microsoft消息排队（MSMQ）服务软件，通过COM组件和System.Messaging名字空间訪问，属于.NET平台的组成部分。Oracle提供了Oracle AQ.

2、  ）应用server。比如JMS、IBM WebSphere、BEA WebLogic

3、  ）EAI套件。比如IBM WebSphere MQ、Microsoft BizTalk、TIBCO、WebMethods、SeeBeyond、Vitria、CorssWolds。

4、  ）Web服务工具集。比如WS-Reliability、WS-ReiableMessaging、ebMs

 

九、UML、XML、.net/java平台

企业应用系统眼下业界流行和通用的就是.Net平台和Java平台（J2EE）；关于两者的差别參考：http://www.cnblogs.com/heilix/archive/2009/01/17/1377555.html

 

十、几种常见架构

软件架构通用的服务模式

类工厂服务

缓存服务（内存服务）

配置服务

异常处理服务

日志服务

加密服务

验证服务和授权服务

消息队列

部署服务

事务处理服务

帮助服务

数据验证服务

 

1、  MVC

•M表示模型

•V表示视图

•C表示控制器

 

2、C/S

•client向server发送数据请求

•server返回数据

•client处理数据的展示

•server须要处理通讯、并发等等

server

•一个线程用来监听来自client的连接

•用一个独立的线程来处理一个client的连接

•线程池、线程重用

•并发控制

•负载均衡

 

进程间通讯

•TCP/UDP进程间通讯

•命名管道

•共享内存

•命名事件

•命令行參数传递（用于父子进程）

 

3、B/S

•Webserver

•应用server

•数据库server

 

Webserver

•标准的Webserver

•简化了应用server的开发

 

  Webserver架构

•JAVA (JSP)

•.NET (ASP)

•LAMP

Linux+Apache+Mysql+Perl/PHP/Python,一组经常使用来搭建动态站点或者server的开源软件,本身都是各自独立的程序,可是由于常被放在一起使用,拥有了越来越高的兼容度,共同组成了一个强大的Web应用程序平台。

 

HTTP

•基于TCP

•client发送HTTP Request

•server处理后，发送HTTP Response

•每次连接仅仅处理一个请求

•HTTP协议定义了Request和Response的内容格式（基于文本）

•HTTP是应用协议

•定义了GET、PUT、POST、REMOVE等操作

•操作的对象是资源，由URI定义

•无状态

HTTP作为传输协议来使用

•基于HTTP的Request和Response

•应用协议在Request和Response中定义

形式一

•http://...../update.php?version=1.0

•http://..../functioncall.php?method=xxx&arg=aaa&....

•能够使用GET和POST

•在Response中使用xml作为返回

 

形式二

•使用POST

•在Request中使用XML指定方法名和參数

•在Response中使用XML作为返回

•XML-RPC

 

形式三

SOAP, WebService

 

4、SOA

   SOA 是一种 IT 体系结构样式，支持将您的业务作为链接服务或可反复业务任务进行集成，可在须要时通过网络訪问这些服务和任务。这个网络可能全然包括在您的公司总部内，也可能分散于各地且採用不同的技术，通过对来自纽约、伦敦和香港的服务进行组合，可让终于用户感觉似乎这些服务就安装在本地桌面上一样。须要时，这些服务可以将自己组装为按需应用程序——即相互连接的服务提供者和使用者集合，彼此结合以完毕特定业务任务，使您的业务可以适应不断变化的情况和需求.

 

5、SaaS

   软件即服务,它是一种基于互联网提供软件服务的应用模式。随着互联网技术的发展和应用软件的成熟，SaaS作为一种创新的软件应用模式逐渐兴起。

    SaaS提供商为企业搭建信息化所须要的全部网络基础设施及软件、硬件运作平台，并负责全部前期的实施、后期的维护等一系列服务，企业无需购买软硬件、建设机房、招聘IT人员，就可以通过互联网使用信息系统。就像打开自来水龙头就能用水一样，企业依据实际须要，向SaaS提供商租赁软件服务。

    对于广大中小型企业来说，SaaS是採用先进技术实施信息化的最好途径。但SaaS绝不只适用于中小型企业，全部规模的企业都能够从SaaS中获利。

    眼下，SaaS已成为软件产业的一个重要力量。仅仅要SaaS的品质和可信度能继续得到证实，它的魅力就不会消退。

 

6、Open API

 

Open API实现技术

  •SOAP

  •XML-RPC

  •REST

 

7、开源框架

      Struts+Spring+Hibernate

        •Struts：实现UI层

        •Spring：实现业务层

        •Hibernate：实现数据持久层

   Jboss

Spring 详细资料參考：http://www.ibm.com/developerworks/cn/java/wa-spring1/

Struts详细资料參考：http://www.ibm.com/developerworks/cn/java/j-struts/

Hibernate 详细资料參考：http://blog.csdn.net/doodoofish/archive/2004/07/16/43207.aspx

Jboss 详细资料參考：http://www.hudong.com/wiki/JBoss

 

client展示技术:

 

•标准Windows控件界面（MFC、.NET、WinForm）

–复杂性：界面受局限，非常难把程序猿与美工的工作分离

•内嵌WebBrowser

•用本地HTML来描写叙述界面（美工）

•採用脚本进行操作

•从容器调用脚本的函数

•从脚本中调用容器的函数（.NET能够直接支持）

•内嵌Flash控件

•界面使用swf描写叙述

•Swf中使用ActionScript进行控制

•与容器的交互

•SliverLight

详细參考：http://blog.csdn.net/byxdaz/archive/2009/06/20/4284330.aspx