软件架构学习小结

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

 

1、软件架构师的职责

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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）、与架构自己相关的一些质量属性。（概念完整性、正确性与完整性、可构建性）

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

 

 

3、设计架构

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

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

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

ADD步骤：

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

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

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

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

高层重用

设计模式

框架

软件架构

架构风格

架构设计风格

架构框架

架构平台

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

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

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

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

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

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

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

 

4、架构评估方法

软件构架的评估方法：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步：结果表述。总结评估结果，评估负责人展现该结果。

 

5、软件架构风险管理

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

（1）需求的不断变化

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

（3）缺少对行业的研究

（4）经验不足

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

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

（7）架构可运行性差

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

固化需求

无缺的业务原型

完整架构规范

验证架构的可运行性

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

 

6、有用软件体系结构

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

4种视图+全局分析

1、4种视图

1）、一个软件体系结构有4种大相径庭的视图：概念视图、模块视图、运行视图、代码视图。

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

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

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

系统怎样知足需求？

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

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

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

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

怎样支持产品线？

怎样将由需求或领域中所作的变更引发的影响最小化？

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

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

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

怎么支持測试？

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

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

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

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

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

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

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

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

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

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

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

怎样减小构造时间？

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

怎样支持集成与測试？

 

2、全局分析

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

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

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

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

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

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

总结策略：

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

 

7、特定领域框架

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

 

8、企业应用架构模式

作企业应用开发需要了解一些企业应用开发基础知识，比方分层架构、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等消息服务产品，而后利用它们能开发企业集成系统，特别是金融业、保险业企业集成系统。

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

■网络是不可靠的。

■网络速度慢。

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

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

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

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

二、  ）共享数据库——多个应用共享一样的数据库，这个数据库位于独立的物理数据库中。由于不存在反复保存的数据资料，所以没必要将数据从一个应用传给还有一个应用。

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

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

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

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

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

二、  ）应用server。好比JMS、IBM WebSphere、BEA WebLogic

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

四、  ）Web服务工具集。好比WS-Reliability、WS-ReiableMessaging、ebMs

 

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

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

 

10、几种常见架构

软件架构通用的服务模式

类工厂服务

缓存服务（内存服务）

配置服务

异常处理服务

日志服务

加密服务

验证服务和受权服务

消息队列

部署服务

事务处理服务

帮助服务

数据验证服务

 

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