软件架构学习小结
软件架构设计系统整体架构，从需求到设计的每个细节都要考虑到，把握整个项目，使设计的项目尽量效率高，开发容易，维护方便，升级简单。本文从架构师职责、软件架构定义、设计架构、评估架构、架构管理等方面来描述了解软件架构的含义和怎样设计软件架构。 一、软件架构师的职责 架构师分为以下几大类：业务架构师、主题领域架构师、技术架构师、项目架构师（J2EE架构师、.NET架构师等）、系统架构师。 1、架构师的职责主要体现 架构师的职责就是设计一个公司系统的基础架构，并提供关于怎样建立和维护系统的指导方针。具体来讲，架构师的职责主要体现在以下几方面： 1）、负责公司系统的架构设计、研发工作。 2）、承担从业务向技术转换的桥梁作用。 3）、协助项目经理制定项目计划和控制项目进度。 4）、负责辅助并指导系统分析开展设计工作。 5）、负责组织技术研究和攻关工作。 6）、负责组织和管理公司内部的技术培训工作。 7）、负责组织及带领公司内部员工研究与项目相关的新技术。 8）、管理技术支撑团队并给项目、产品开发实施团队提供技术保障。 9）、理解系统的业务需求，制定系统的整体框架（包括、技术框架和业务框架）。 10）、对系统框架相关技术和业务进行培训，指导开发人员开发。并解决系统开发、运行中出现的各种问题。 2、构架设计师必须具备的技能 经验：既包括在问题领域的经验（通过彻底了解需求），也包括在软件工程领域的经验。对于一个构架团队，这些素质要求可由各团队成员来分别承担，但其中至少要有一名构架设计师能够把握项目的全局。 领导才能：能够推动各个团队的技术进展，并能在压力下作出关键性的决策然后将其贯彻到底。要提高效率，构架设计师和项目经理必须紧密协作。构架设计师主要负责解决技术问题，项目经理主要负责解决行政管理问题。构架设计师必须有权在技术问题上作出决定。 沟通：能够赢得他人的信任，以对其进行说服、激励和指导。构架设计师不能靠命令进行领导，而必须要赢得项目中其他人员的赞同。为了提高效率，构架设计师必须赢得项目团队、项目经理、客户、用户群体以及管理团队的尊敬。 以目标为中心、积极主动：不懈地追求成效。构架设计师是推动项目发展的技术动力，而不是空想家。在其职业生涯中，成功的构架设计师一直都要在捉摸不定和承受压力的情况下作出折衷决定。构架设计师只有将注意力集中在该做的事情上，才能在项目中取得成功。 专业：精通构架设计的理论、实践和工具，并掌握多种参考构架、主要的可重用构架机制和模式（例如J2EE架构等）。具备系统设计员的所有技能，但涉及面更广、抽象级别更高。 二、软件架构、架构模式、参考模型、参考架构 1、对于软件架构定义有很多种，通用的定义是：某个软件或计算机系统的软件架构是该系统的一个或多个结构，他们由软件元素，这些元素的外部可见属性以及这些元素之间的关系组成。 这里所说的某个元素的“外部可见属性”是指其他元素对该元素所做的假设，如它所提供的服务、性能特征、错误处理、共享资源的使用，等等。 其他的定义包括：架构是一种高层设计。架构是系统的总体结构。架构是一个软件或系统的组件、组件之间的相互关系以及管理其设计和演变的原理和方针的结构。架构是组件和连接器。 2、架构模式是对元素和关系类型以及一组对其使用方式的限制的描述。 3、参考模型是一种考虑数据流的功能划分。 4、参考架构是映射到软件元素（它们相互协作，共同实现在参考模型中定义的功能）及元素之间数据流上的参考模型。 5、软件架构、架构模式、参考模型、参考架构之间的关系：
软件结构 关系 适用环境 分解 是一个子模块；与之共享秘密 资源分配、项目结构化和规划；信息隐藏、封装；配置控制 使用 要求正确出现 设计子集；设计扩展 分层 要求正确的出现、使用服务、提供抽象 增量式开发；在“虚拟机”可移植性之上实现系统 类 是一个实例；共享访问方法 在面向对象的设计系统中，从一个公共的模版中产生快速的、相近的实现 客户机-服务器 与之通信；依赖于 分布式操作；关注点分离；性能分析；负载平衡 进程 与之并发运行、可能会与之并发运行；排除；优先于等 调度分析；性能分析 并发 在相同的逻辑线程上运行 确定存在资源争用，线程可以交叉、连接、被创建或被杀死的位置 共享数据 产生数据；使用数据 性能；数据完整性；可修改性 部署 分配给；移植到 性能、可用性、安全性分析 实现 存储在 配置控制、集成、测试活动 工作分配 分配到 项目管理、最佳利用专业技术、管理通用性 注：在＜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）、不同视图强调的不同工程关注点： 在概念视图中，问题和解决方案主要通过领域术语来考虑的。对于特定的软件及硬件技术，它们应当是相对独立的。概念视图的工厂关注点包括： 系统如何满足需求？ 商用构件怎样组装成整体，怎样在功能层上与系统的其他部分交互？ 领域特定的硬件和软件如何融入系统？ 功能是如何被分割并进入产品个版本的？ 系统如何与之前版本的产品合并？它如何支持未来的版本？ 如何支持产品线？ 如何将由需求或领域中所做的变动引起的影响最小化？ 在模块视图中，概念视图中的构件和连接子被映射为子系统和模块。在这里，架构师强调的是如何用现有的软件平台以及技术实现概念的解决方案。主要的工程关注点有如下几点： 产品是如何映射到软件平台的？ 使用了什么样的系统支持或系统服务？具体是在什么地方？ 怎么支持测试？ 如何降低模块间的依赖性？ 如何将模块与子系统的复用最大化？ 当商用软件、软件平台或标准发生变动时，采用何种技术在封装产品时可以将它们与产品进行隔离？ 执行视图描述模块如何映射到运行时平台说提供的元素，以及这些又如何映射到硬件体系结构。执行视图定义系统的执行时实体及其属性，比如内存使用和硬件分配。对于执行视图，其工程关注点如下： 系统如何满足性能、恢复及重新配置方面的需求？ 如何平衡资源的使用（例如：负载平衡）？ 如何达到必需的并发、复制及分布，而不过度增加控制算法的复杂度？ 如何使运行时平台的改变所引起的影响到达最小？ 在代码体系结构视图中，架构师决定执行视图中的执行时实体如何映射到部署构件（例如：可执行构件），决定模块视图中的模块如何映射到源构件，以及部署构件如何从源构件生成。代码视图中重要的工程关注点如下： 如何降低产品升级的时间和费用？ 如何管理产品版本及发布？ 如何降低构造时间？ 需要什么工具支持开发环境？ 如何支持集成与测试？ 2、全局分析 全局分析是在定义概念、模块、执行和代码系统结构视图之前进行的，并贯穿整个系统结构的设计过程。 全局分析从识别影响体系结构设计的因素来分成3类：组织因素、技术因素、产品因素。 组织因素分成5类：管理；员工技能、兴趣、能力、缺点；过程与开发运行环境；开发进度；开发预算。 技术因素包括：通用和专用的硬件；操作系统、用户界面、设计模式等软件技术；模版和框架等体系结构技术；图像、数据库、数据格式、算法和技术之类的标准。 产品因素是描述了产品的功能需求、用户可见的特征和产品的性能等质量方面的需求。比如：功能特征；用户界面；性能；依赖性；错误监测、报告、修复；服务和价格等。 全局分析是在每一种体系结构设计视图中都要进行的一种行为。在全局分析过程中建立的问题卡片要用在每一个视图设计的核心设计任务中。在进行核心设计任务时，做出的决策应当可以返回到全局分析，以增加和修改因素、问题和策略。 总结策略： 问题 应用策略 进度紧迫 复用内部已有的、领域特性构件 购买而不是建立 使元素容易添加和删除 技能不足 避免使用多线程 封装多进程 通用和领域特定硬件的改变 封装领域特定硬件 封装通用硬件 软件技术的改变 使用标准 为外部构件开发产品特定的接口 资源有限 限制活动线程个数 用动态的内部线程见通信联系 易用增加和删除特性 按关联尺度分离构件和模块 特性封装到分开的构件 分离用户交互模块 易用增加和删除采集过程和算法 为图像处理使用灵活的流水线模块 为采集和图像处理引入构件 分离用户交互模块 高吞吐量 把独立的控制线程映射到进程 使用新增的CPU 实时采集性能 从没有临界时间构件中分离出有临界时间的 为模块行为开发准则 灵活的分配模块到进程 使用单速分析来预言性能 使用共享存储进行流水线阶段之间通信 实现恢复 引入操作的恢复模块 把全部数据放到恢复稳定和容易达到的地方 实现诊断 制定一个错误处理策略 减少错误处理的工作 封装诊断构件 使用标准日志服务 体系结构的完整性 保护模块间的继承 分离公共接口构件 并发的开发工作 从源构件中分离开发构件 保护执行视图 采用阶段开发 通过静态库来发布层 限制可使用的采集图像类型 采用适当的抽象开发一个脱机的探测模拟器 使用一个灵活的建立过程 多样性开发和目标平台 分离和封装依赖目标平台的代码 七、特定领域框架 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、 ）应用服务器。例如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 •客户端向服务器发送数据请求 •服务器返回数据 •客户端处理数据的展示 •服务器需要处理通讯、并发等等 服务器 •一个线程用来监听来自客户端的连接 •用一个独立的线程来处理一个客户端的连接 •线程池、线程重用 •并发控制 •负载均衡 进程间通讯 •TCP/UDP进程间通讯 •命名管道 •共享内存 •命名事件 •命令行参数传递（用于父子进程） 3、B/S •Web服务器 •应用服务器 •数据库服务器 Web服务器 •标准的Web服务器 •简化了应用服务器的开发 Web服务器架构 •JAVA (JSP) •.NET (ASP) •LAMP Linux+Apache+Mysql+Perl/PHP/Python,一组常用来搭建动态网站或者服务器的开源软件,本身都是各自独立的程序,但是因为常被放在一起使用,拥有了越来越高的兼容度,共同组成了一个强大的Web应用程序平台。 HTTP •基于TCP •客户端发送HTTP Request •服务器处理后，发送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 客户端展示技术: •标准Windows控件界面（MFC、.NET、WinForm） –复杂性：界面受局限，很难把程序员与美工的工作分离 •内嵌WebBrowser •用本地HTML来描述界面（美工） •采用脚本进行操作 •从容器调用脚本的函数 •从脚本中调用容器的函数（.NET可以直接支持） •内嵌Flash控件 •界面使用swf描述 •Swf中使用ActionScript进行控制 •与容器的交互 •SliverLight
