第一章
软件危机的表现：
1、软件成本日益增长
2、开发进度难以控制
3、软件质量差
4、软件维护困难
软件危机的原因：
1、用户需求不明确
2、缺乏正确的理论指导
3、软件规模越来越大
4、软件复杂度越来越高
如何克服软件危机：
人们面临的不光是技术问题，更重要的是管理问题，引入软件工程，标准化、流程化。
要提高软件开发效率，提高软件产品质量，必须采用工程化的开发方法与工业化的生产技术。
工业化：构件是核心和基础，重用是必需的手段
软件的重用：指在两次或多次不同的软件开发过程中重复使用相同或相近软件元素的过程。
软件元素包括程序代码、测试用例、设计文档、设计过程、需求分析文档及领域知识。
可重用的元素称作构件。可重用的软件元素越大，重用粒度越大。
使用软件重用技术的好处：
1、减少软件开发的重复性工作。
2、缩短开发周期
3、软件更标准化
4、改善软件质量
构件模型是对构件本质特征的抽象描述。
构件＝语义完整＋语法正确＋有可重用价值
目前比较流行的构件实现模型包括：
1、OMG的CORBA（通用对象请求代理结构）
2、Sun的EJB（Enterprise Java Bean）
3、Microsoft的COM/COM+/DCOM（分布式构件对象模型）
这些模型通常都定义了构件的实现方式、接口定义、访问方法等。符合这些标准的构件都有很高的重用能力。
青鸟构建模型由外部接口和内部结构两部分组成。
外部接口＝构件名称＋功能描述＋对外功能接口+所需的构件+参数化属性
内部结构=内部成员+内部成员之间的关系
构件实现是指具体实现构件功能的逻辑系统，通常也称为代码构件。
构件实现由构件生产者完成，构件重用者不必关心构件的实现细节。
构件获取可以有多种不同的途径：
1、从现有构件中获得符合要求的构件，直接使用或作适应性修改，得到可重用的构件。
2、通过遗留工程，将具有潜在重用价值的构件提取出来，得到可重用的构件。
3、从市场上购买现成的商业构件，即COTS（Commercial Off-The-Shell）构件。
4、开发新的符合要求的构件。
构件管理的内容：
1、构件描述：
A.构件模型是对构件本质的抽象描述。
B.主要是为构件的制作与构件的重用提供依据。
C.从管理角度出发，也需要对构件进行描述
2、构件分类与组织：
关键字分类法：从抽象到具体一层一层的细化。
思想：根据领域分析的结果将应用领域的概念按照从抽象到具体的顺序逐次分解为树状或有向无回路图结构。
刻面分类法 ：从不同方面对构件特征进行刻画。
思想：定义若干个刻画构件特征的“面”，每个面包含若干个概念，这些概念表述构件在面上的特征
超文本组织方法
思想：1、所有构件辅以详尽的功能或行为说明文档。
2、说明中的重要概念或构件以网状链接方式连接。
3、检索者在阅读文档过程中可任意跳转到包含相关概念或构件的文档。
4、全文检索系统将用户给出的关键字与说明文档中的文字进行匹配，实现构件的浏览式检索。
青鸟构件库就是采用刻面分类方法对构建进行分类，这些刻面包括：
1、使用环境：对该构件操作时必须提供的硬件、软件平台。
2、应用领域：构件可能被使用到的应用领域集合。
3、功能：提供的软件功能集合。
4、层次：如分析、设计、编码等。
5、表示方法：如编程语言等。
构件库系统包含5类用户：注册用户 公共用户 构件提交者 一般系统管理员 超级系统管理员
构件重用 软件开发的目的是重用，库的使用者必须完成以下工作：
1、检索与提取构件
检索方法：
a. 基于关键字的检索
b. 刻面检索法
c. 超文本检索法
d. 其他检索方法
2、理解与评价构件
构件库的文档中，全面、准确的说明以下内容：
a.构件的功能与行为
b.相关的领域知识
c.可适应性约束条件与例外情形
d.可以预见的修改部分及修改方法
3、修改构件 评估之后才做修改，不评估不做修改
理想的情形是对库中的构件不作修改而直接用于新的软件项目。但是，在大多数情况下，必须对构件进行或多或少的修改，以适应新的需求。为了减少构件修改的工作量，要求开发人员尽量使构件的功能、行为和接口设计更为抽象化、通用化和参数化。
4、构件组装
a. 基于功能的组装技术
b. 基于数据的组装技术
组装方式：传统的子程序调用与参数传递。
c. 面向对象的组装技术
构造法：在子类中引进基类的对象作为子类的成员变量，然后在子类中通过成员变量重用基类的属性和方法。
子类法：将新子类直接说明为库中基类的子类，通过继承和修改基类的属性与行为完成新子类的定义。
软件体系结构的定义：
软件体系结构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策的基本原理。
第二章
根据建模的侧重点不同，软件体系结构模型分为5种:
1、结构模型2、框架模型3、动态模型4、过程模型5、功能模型
4+1视图模型从5个不同的视角描述SA。包括：
逻辑视图：主要描述系统的功能需求，是从系统的构成的角度来描述所要开发的系统的功能。面向对象分解
进程视图：主要侧重于系统的运行特征，并关注一些非功能性特性。 过程分解
物理视图：关注“目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可申缩性等要求。
开发视图：主要侧重于软件模块的组织和管理。子功能分解 编码人员看
场景视图：可以看作是那些重要系统活动的抽象，它使四个视图有机联系起来
软件体系结构各阶段的关系：
1、需求分析阶段
任务：根据需求决定系统的功能
2、建立软件体系结构阶段
任务：选择合适的体系结构风格
3、设计阶段
能够对同一种问题，有多种设计结果。
4、实现阶段
在各种制约条件下，取得较好的折中办法。
软件体系结构的生命周期：
软件体系结构的非形式化描述。使用自然语言表示相关概念和原则；
软件体系结构的规范化描述与分析。使用合适的理论模型精确、无歧义描述软件体系结构；
软件体系结构的求精与验证。大型系统的体系结构总是从抽象到具体，逐步求精而得到的；
软件体系结构的实施。将求精后的软件体系结构应用于系统设计过程中，形成系统的设计框架；
软件体系结构的演化和扩展。系统需求变化引起体系结构的扩展和改动；
软件体系结构的评价和度量。对体系结构进行定性的评价和定量的度量，为体系结构重用提供依据；
软件体系结构的终结。系统的体系结构已不能满足软件设计要求。
软件体系结构风格的定义：
1、软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。
2、体系结构风格定义了一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
3、体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。
通用的体系结构风格的分类：
管道与过滤器风格：
构件：过滤器
连接件：管道
特点（优点）：
1、允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单叠加和组合。
2、支持功能模块的复用。
3、系统易于维护和升级，易于增强系统性能。
4、允许对一些如吞吐量、死锁等属性的分析；
5、支持并发执行。
6、使得软构件具有良好的隐蔽性和高内聚、低耦合的特点
不足：1、往往导致系统处理过程的成批操作。
2、在处理两个独立但又相关的数据流是可能会遇到困难 。
3、需要对数据传输进行特定的处理时，会导致对于每个过滤器的解析输入和格式化输出要做更多的工作，带来系统复杂性的上升。
数据抽象和面向对象系统：
构件：对象
连接件：过程调用
优点：1、因为对象对其它对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其它的对象；
2、设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。
不足：1、为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象；
2、必须修改所有显式调用它的其它对象，并消除由此带来的一些副作用。例如，如果A使用了对象B，C也使用了对象B，那么，C对B的使用所造成的对A的影响可能是料想不到的。
基于事件的系统：
原理：1、构件不直接调用一个过程，而是触发或广播一个或多个事件。
2、这种风格的构件是一些模块，模块既可以是一些过程，又可以是一些事件的集合。
3、这种基于事件的隐式调用风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响
隐式调用系统的主要优点：
1、为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时，只需将它注册到系统的事件中。
2、为改进系统带来了方便。当用一个构件代替另一个构件时，不会影响到其它构件的接口。
缺点：
1、构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其它构件是否会响应它。而且即使它知道事件注册了哪些构件的构成，它也不能保证这些过程被调用的顺序。
2、数据交换的问题。有时数据可被一个事件传递，但另一些情况下，基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下，全局性能和资源管理便成了问题。
3、既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理存在问题。
分层系统：
构件：虚拟机
连接件：过程调用
优点：支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解；
2、 支持功能增强，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层；
3、支持重用。
不足：
1、并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来；
2、很难找到一个合适的、正确的层次抽象方法。
仓库系统及知识库：
构件：中央数据结构
连接件：独立构件
C2风格：
系统组织规则如下：
◎ 系统中的构件和连接件都有一个顶部和一个底部；
◎ 构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；
◎ 一个连接件可以和任意数目的其它构件和连接件连接；
◎ 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。
特点：
◎ 系统中的构件可实现应用需求，并能将任意复杂度的功能封装在一起；
◎ 所有构件之间的通讯是通过以连接件为中介的异步消息交换机制来实现的；
◎ 构件相对独立，构件之间依赖性较少。系统中不存在某些构件将在同一地址空间内执行，或某些构件共享特定控制线程之类的相关性假设。
客户/服务器风格：
C/S体系结构有三个主要组成部分：数据库服务器、客户应用程序和网络。
服务器任务：
（1）数据库安全性的要求；
（2）数据库访问并发性的控制；
（3）数据库前端的客户应用程序的全局数据完整性规则
（4）数据库的备份与恢复
客户端任务：
（1）提供用户与数据库交互的界面；
（2）向数据库服务器提交用户请求并接收来自数据库服务器的信息；
（3）利用客户应用程序对存在于客户端的数据执行应用逻辑要求。
优点：
1、系统的客户应用程序和服务器构件分别运行在不同的计算机上，系统中每台服务器都可以适合各构件的要求，这对于硬件和软件的变化显示出极大的适应性和灵活性，而且易于对系统进行扩充和缩小。
2、 在C/S体系结构中，系统中的功能构件充分隔离，客户应用程序的开发集中于数据的显示和分析，而数据库服务器的开发则集中于数据的管理，不必在每一个新的应用程序中都要对一个DBMS进行编码。将大的应用处理任务分布到许多通过网络连接的低成本计算机上，以节约大量费用
缺点：
◎ 开发成本较高
◎ 客户端程序设计复杂
◎ 信息内容和形式单一
◎ 用户界面风格不一，使用繁杂，不利于推广使用
◎ 软件移植困难
◎ 软件维护和升级困难
◎ 新技术不能轻易应用
三层客户/服务器结构风格：比两层C/S多了一个应用服务器
优点：◎ 允许合理地划分三层结构的功能，使之在逻辑上保持相对独立性，能提高系统和软件的可维护性和可扩展性。
◎ 允许更灵活有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层；并且这些平台和各个组成部分可以具有良好的可升级性和开放性。
◎ 应用的各层可以并行开发，可以选择各自最适合的开发语言。
◎ 利用功能层有效地隔离开表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层，为严格的安全管理奠定了坚实的基础。
浏览/服务器风格 B/S
优点：
◎ 基于B/S体系结构的软件，系统安装、修改和维护全在服务器端解决。用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。
◎ B/S体系结构还提供了异种机、异种网、异种应用服务的联机、联网、统一服务的最现实的开放性基础。
缺点：
◎ B/S体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。
◎ B/S体系结构的系统扩展能力差，安全性难以控制。
◎ 采用B/S体系结构的应用系统，在数据查询等响应速度上，要远远地低于C/S体系结构。
◎ B/S体系结构的数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理(OLTP)应用。
公共对象请求代理体系结构 CORBA
底层是处理面向对象的，但是CORBA是处理分布式应用的。
CORBA技术规范：
◎ 接口定义语言（IDL）
◎ 接口池（IR）
◎ 动态调用接口（DII）
◎ 对象适配器（OA）
特点：
◎ 引入中间件作为事务代理，完成客户机向服务对象方（Server）提出的业务请求。
◎ 实现客户与服务对象的完全分开，客户不需要了解服务对象的实现过程以及具体位置。
◎ 提供软总线机制，使得在任何环境下、采用任何语言开发的软件只要符合接口规范的定义，均能够集成到分布式系统中。
◎ CORBA规范软件系统采用面向对象的软件实现方法开发应用系统，实现对象内部细节的完整封装，保留对象方法的对外接口定义。
正交软件体系结构：
特征：
◎ 正交软件体系结构由完成不同功能的n（n > 1）个线索（子系统）组成；
◎ 系统具有m（m > 1）个不同抽象级别的层；
◎ 线索之间是相互独立的（正交的）；
◎ 系统有一个公共驱动层（一般为最高层）和公共数据结构（一般为最低层）。
优点：
◎ 结构清晰，易于理解。
◎易修改，可维护性强。
◎可移植性强，重用粒度大
为什么要使用异构结构：
◎ 不同的结构有不同的处理能力的强项和弱点，一个系统的体系结构应该根据实际需要进行选择，以解决实际问题。
◎ 关于软件包、框架、通信以及其他一些体系结构上的问题，目前存在多种标准。即使在某段时间内某一种标准占统治地位，但变动最终是绝对的。
◎ 实际工作中，我们总会遇到一些遗留下来的代码，它们仍有效用，但是却与新系统有某种程度上的不协调。然而在许多场合，将技术与经济综合进行考虑时，总是决定不再重写它们。
◎ 即使在某一单位中，规定了共享共同的软件包或相互关系的一些标准，仍会存在解释或表示习惯上的不同。
异构结构的两个模型：
1、“内外有别”模型
“内外有别”模型的优点是外部用户不直接访问数据库服务器，能保证企业数据库的相对安全。企业内部用户的交互性较强，数据查询和修改的响应速度较快。
“内外有别”模型的缺点是企业外部用户修改和维护数据时，速度较慢，较烦琐，数据的动态交互性不强。
2、“查改有别”模型
“查改有别”模型体现了B/S体系结构和C/S体系结构的共同优点。但因为外部用户能直接通过Internet连接到数据库服务器，企业数据容易暴露给外部用户，给数据安全造成了一定的威胁。
第六章
XML定义：XML是一套定义语义标记的规则，这些标记将文档分为许多部件加以标识。它也是元标记语言，用于定义其它与特定领域有关的、语义的、结构化的标记语言的句法语言。XML与HTML一样，都来自SGML(标准通用标记语言)。
XML特点：1、简洁有效 2、易学易用 3、开放的国际化标准 4、高效且可扩充
XML作用：1、使得搜索更加有意义
2、开发灵活的应用软件
3、实现不同数据的集成
4、使用于多种应用环境
5、客户端数据处理与计算
6、数据显示多样化
7、局部数据更新
8、与现有web发布机制兼容
9、可升级性
10、压缩性能好
XML的应用：
1、应用于客户需要与不同的数据源进行交互时。
2、应用于将大量计算分布于客户端。
3、应用于将同一数据以不同的面貌展现给不同的用户。
4、应用于网络代理对所取得的信息进行编辑，增删以适应个人用户的需要
XML和HTML的区别：
HTML是一种格式化的语言，一个HTML文本可以看作一个格式化的程序
XML是一种元标记语言
XML定义了一套元句法，与特定领域有关的标记语言（例如，MusicML、MathML和CML等）都必须遵守
XML满足的基本规则：
（1）文档以XML定义<?xml version="1.0"?>开始。
（2）有一个包含所有其它内容的根元素，如上面例子中的<visit>和</visit>标记符。
（3）所有元素必须合理地嵌套，不允许交叉嵌套。
XML的优势：
1、XML模式使用XML语法
2、XML模式支持数据类型
3、XML模式是可扩展的
4、XML模式有更强的表达能力
CSS和XSL的比较：xsl是专门用于XML文档的样式单语言
CSS只能改变特定元素的格式，也只能以元素为基础。但XSL样式单可以重新排列元素并对元素进行重排序。
CSS的优越性在于具有广泛的浏览器支持。但是XSL更为灵活和强大，可更好地适用于XML文档。而且，带XSL样式单的XML文档可以很容易地转换为带CSS样式单的HTML文档。
如果只是要对一些固定数据进行排版，可以使用“HTML＋CSS”方式；如果这些数据是与某些应用程序相关，并且独立于程序存在的，并且要独立于程序来使用，则应该充分使用XML技术，采用“HTML＋XML＋XSL”。
广泛使用API的有：
1、DOM
DOM问题：1、DOM 构建整个文档驻留内存的树。如果文档很大，就会要求有极大的内存。
2、DOM 创建表示原始文档中每个东西的对象，包括元素、文本、属性和空格。如果用户只需关注原始文档的一小部分，那么创建那些永远不被使用的对象是极其浪费的。
3、DOM 解析器必须在代码取得控制权之前读取整个文档。对于非常大的文档，这会引起显著的延迟。
2、SAX
特征：
SAX 解析器向您的代码发送事件。
SAX 解析器根本不创建任何对象，
SAX 解析器在解析开始的时候就开始发送事件。
问题：
SAX 事件是无状态的。
SAX 事件不是持久的。意思就是这次解析了之后如果下次要用还要进行解析。
SAX 不是由一个集中管理的组织控制的。
3、JDOM
JDOM 的主要特性是它极大地减少了用户必须编写的代码数量，
4、JAXP
尽管DOM、SAX和JDOM为大多数常见任务提供了标准接口，但仍有些事情是它们不能解决的。例如，在Java程序中创建DOMParser对象的过程因DOM解析器的不同而不同。
XML建模：
描述具体数据
描述数据结构和模式
描述数据的表现
描述数据中的位置
描述数据中的链接关系
描述数据的应用关系
第八章
许多组织从不同角度和不同侧面对SOA进行了描述，较为典型的以下三种：
W3C：SOA是一种应用程序体系结构，在这种体系结构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成业务流程。
Service-architecture.com：服务是精确定义、封装完整、独立于其它服务所处环境和状态的函数。SOA本质上是服务的集合，服务之间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务之间需要某些方法进行连接。
Gartner：SOA是一种C/S体系结构的软件设计方法，应用由服务和服务使用者组成，SOA与大多数通用的C/S体系结构模型不同之处，在于它着重强调构件的松散耦合，并使用独立的标准接口。
在 SOA 的架构风格中，服务是最核心的抽象手段。 其目的是对外提供服务，并实现跨平台的可互操作性。
SOA概述：SOA并不是新鲜事物，而只是面向对象模型的一种替代。虽然SOA的系统并不排除使用OOD来构建单个服务，但是其整体设计却是面向服务的。
SOA特征：
◎ 松散耦合
SOA是松散耦合构建服务，这一点区别于大多数其他的构建体系结构。松散耦合旨在将服务使用者和服务提供者在服务实现和客户如何使用服务方面隔离开来。
◎ 粗粒度服务
服务粒度指的是服务所公开功能的范围，分为细粒度和粗粒度。设计中尽可能的进行粗粒度建模。
◎ 标准化接口
SOA通过被服务接口的标准化描述，从未使得该服务可以提供给任何异构平台和任何用户接口中使用。接口描述包括与服务交互需要的全部细节，如消息格式、传输协议和位置。该接口隐藏了实现服务的细节。
服务构件体系结构SCA与传统构件的主要区别在于：
服务构件往往是粗粒度的，而传统构件以细粒度居多；
服务构件的接口是标准的，主要是服务描述语言接口，而传统构件常以具体API形式出现；
服务构件的实现与语言是无关的，而传统构件常绑定某种特定的语言；
SOA设计原则：
明确定义的接口
自包含和模块化
粗粒度
松耦合
互操作性、兼容和策略声明
SOA关键技术：
1、发现服务层：用来帮助客户端应用程序解析远程服务的位置，通过UDDI实现。真正实现信息的一次注册到处访问。
2、描述服务层：描述层为客户端应用程序提供正确地与远程服务交互的描述信息，主要通过WSDL来实现。表达一个服务能做什么，它的位置在哪，如何调用它等信息。
3、消息格式层：用来保证客户端应用程序和服务器端在格式设置上保持一致，一般通过SOAP实现。
4、编码格式层：主要为客户提供一个标准的、独立于平台的数据交换编码格式，一般通过XML来实现。
5、传输协议层：主要为客户端和服务器之间提供两者交互的网络通信协议。
目前实现SOA的方法主要包括Web Service、服务注册表和企业服务总线。
Web Service 的三种角色：
1、服务提供者
服务提供者是服务的所有者，该角色负责定义并实现服务
2、服务请求者
服务请求者是服务的使用者。
3、服务注册中心
服务注册中心是连接服务提供者和服务请求者的纽带
Web Service 模型的操作：
1、发布 服务提供者发布服务的描述
2、查找 服务请求者这届检索服务描述或者在服务注册中心查询所要求的服务类型
3、绑定 服务请求者使用服务描述中的绑定细节来定位，联系并调用服务。
采用Web 服务作为SOA的实现技术时，应用系统大致可以分为6个层次。分别是底层传输层、服务通信协议层、服务描述层、服务层、业务流程层和服务注册层。
Web Service 的优点：
实现跨语言跨平台（实现协同工作）
软件和数据重用
Web 服务 是基于 XML 和 HTTP 的
应用程序集成
服务注册表：
服务注册。服务注册是指服务提供者向服务注册表发布服务的功能（服务合约），包括服务身份、位置、方法、绑定、配置、方案和策略等描述性属性。
服务位置。服务位置是指服务使用者，帮助它们查询已注册的服务，寻找符合自身要求的服务。
服务绑定。服务使用者利用查找到的服务合约来开发代码，开发的代码将与注册的服务进行绑定，调用注册的服务，以及与它们实现互动。
企业服务总线的功能：
提供位置透明性的消息路由和寻址服务
提供服务注册和命名的管理功能
支持多种的消息传递范型
支持多种可以广泛使用的传输协议
支持多种数据格式及其相互转换
提供日志和监控功能
企业服务总线的优势：
扩展的、基于标准的连接。
灵活的、服务导向的应用组合
提高复用率，降低成本
减少市场反应时间，提高生产率
服务语言描述：最成熟的三个协议是SOPA（在消费者和服务提供者之间传输数据） WSDL（描述服务） UDDI（管理，注册，查找服务）
WSDL :是基于 XML的用于描述 Web 服务以及如何访问 Web 服务的语言。
WSDL文档格式：
types（类型）：数据类型定义的容器，提供了用于描述正在交换的消息的数据类型定义，一般使用XML Schema中的类型系统。
message（消息）：通信消息数据结构的抽象定义。message使用types所定义的类型来定义整个消息的数据结构，由一个或者多个part组成。
part：消息参数。
operation（操作）：对服务中所支持的操作的抽象描述，一般单个operation描述了一对访问入口的请求/响应消息。
Port type（端口类型）：描述了一组操作，每个操作指向一个输入消息和多个输出消息规范。
binding（绑定）：为特定端口类型定义的操作和消息制定具体的协议和数据格式。
port（端口）：指定用于绑定的地址，定义服务访问点。
service：相关端口的集合，包括其关联的接口、操作、消息等
UDDI技术规范：
UDDI数据模型。一个用于描述企业和服务的XML Schema。
UDDI API。一组用于查找或发布UDDI数据的方法，基于SOAP。
UDDI注册服务。一种基础设施，对应着服务注册中心的角色。
建立UDDI条目时，需要确定以下事项：
确定Web服务的tModel（WSDL文档）。
确定组织（企业、事业单位、各类机构等，下同）名称、简介以及所提供的Web服务的主要联系方法。
确定组织正确的标识和分类。
确定组织通过UDDI提供的Web服务。
确定所提供的Web服务的正确分类。
调用Web服务的步骤：
编写调用Web服务的程序时，程序员使用UDDI注册中心来定位并获得businessEntity。
程序员可以进一步获得更详细的businessService信息，或是得到一个完整的businessEntity结构。因为businessEntity结构中包含了已发布的Web服务的全部信息，所以，程序员可以从中选择一个bindingTemplate待以后使用。
Web服务在tModel中提供了相关规范的引用地址，程序员可以根据引用地址获得规范并编写程序。
运行时，程序员可以按需要使用已经保存下来的bindingTemplate信息，调用Web Service。
SOAP协议：
SOAP主要包括以下4各部分：
SOAP封装。定义一个整体框架，用来表示消息中包含什么内容，谁来处理这些内容，以及这些内容是可选的或是必需的 。
SOAP编码规则。定义了一种序列化的机制，用于交换系统所定义的数据类型的实例。
SOAP RPC表示。定义一个用来表示远程过程调用和应答的协议。
SOAP绑定。定义一个使用底层传输协议来完成在节点间交换SOAP信封的约定。
REST的概念和准则：
网络上的所有事物都被抽象为资源
每个资源对应一个唯一的资源标识符
通过通用的连接件接口对资源进行操作
对资源的各种操作不会改变资源标识
所有的操作都是无状态的
第九章：
传统的Web应用程序的缺点：
1、操作复杂性
2、数据复杂性
3、交互复杂性
因为传统的Web应用程序不能表达高度的复杂性。所以提出RIA。
富的含义：丰富的数据模型和丰富的用户界面。
丰富的数据意味着客户端的用户界面能表现和应对更多更复杂的数据模式。
丰富也指RIA能提供更多的改良界面。
丰富的结果是用户可以创建一个客户端界面，这样更容易反映丰富性与复杂性共存的数据和逻辑
RIA的优点：1、RIA利用相对健壮的客户端描述引擎，这个引擎能够提供内容密集，响应速度快和图形丰富的用户界面。
RIA一般还允许使用SVG或者其他技术来随时构建图形，一些RIA技术甚至能够提供券活动的动画来对付数据变化来做出相应
数据能够被缓存在客户端，从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面。
RIA可以继续使用现有的应用程序模型（包括J2EE和.NET），因而无需大规模替换现有的Web应用程序
RIA可以帮助企业提供多元化的重要业务效益，
使用AJAX的最大优点：能在不更新整个页面的前提下维护数据，这使得Web系统更为迅速的回应用户动作，并避免了在网络上发送那些没有改变过的信息。
RIA客户端开发技术——1、Macromedia Flash和Flex
2、AJAX 3、Laszlo 4、Avalon 5、java SWT 6、XUL 7、Bindows 8、Oracle Forms
AJAX是由几种技术组合而成：
Mashup 实现技术：
Mashup聚合的内容可概括为服务和数据。
如果聚合的是服务，则通过调用API来获取各个源的功能，Mashup最常用的API类型一般有两种，分别是REST和SOAP；
如果聚合的是数据，则使用RSS或Atom来获取数据。
第十一章
软件评估的必要性：
1、体系结构评估可以减少后期测试和纠错的开销
2、评估是挖掘隐性需求并将其补充到设计的最后机会。
3、体系结构是开发过程的中心，不良的体系结构会带来一蹋糊涂的效果。
软件质量属性：
1、性能 简单来说，是系统对请求的响应时间。
2、可用性 是指系统的平均可使用时间，一般采用可用时间的比例进行描述。该质量属性描述系统在一段时间内，可正常提供服务的时间比例。
3、可靠性
可靠性的量化指标是周期内系统平均无故障运行时间。
平均故障间隔时间 顾名思义，是指相邻两次故障之间的平均工作时间，是衡量一个产品的可靠性指标。
一般提高可靠性的同时，也同时提高了可用性。
可靠性分为：
（1）容错：在错误发生时确保系统正确的行为，并进行内部“修复”。
如数据库系统的恢复机制。
（2）健壮性：保护应用程序不受错误使用和错误输入的影响，在遇到意外错误事件时确保应用系统处于已经定义好的状态。
4、安全性 指系统在向合法用户提供服务的同时，能够阻止非授权用户使用的企图或拒绝服务的能力。
安全性包括，系统接入安全性、鉴权安全性、数据安全性、共享安全性等，
5、可修改性 指能够快速的以较高的性能价格比对系统进行变更的能力，通过考察并更的代价衡量可修改性。如松散耦合的系统。
可修改性包括的四个方面：
（1）可维护性：在错误发生后“修复” 软件系统。
（2）可扩展性：使用新特性来扩展软件系统，以及使用改进版本来替换构件并删除不需要或不必要的特性或构件。
（3）结构重组：重新组织软件系统的构件及构件间的关系。如通过将构件移动到一个不同的子系统而改变它的位置。
（4）可移植性：使软件适用于多种硬件平台、用户界面、操作系统、编程语言或编译器。
6、功能性
7、可变性
8、集成性
9、互操作性
几个基本概念：
1、敏感点和权衡点
敏感点和权衡点是关键的体系结构决策。
敏感点:是一个或多个构件（和/或构件之间的关系）的特性。
作用：使设计人员分析员明确在搞清楚如何实现质量目标时应注意什么。
权衡点：影响多个质量属性的特性，是多个质量属性的敏感点。
2、风险承担者
3、场景 在进行体系结构评估时，一般首先要精确地得出具体的质量目标，并以之作为判定该体系结构优劣的标准。我们把为得出这些目标而采用的机制叫做场景。在体系结构评估中，一般采用刺激、环境和响应三方面来对场景进行描述。
刺激是场景中解释或描述风险承担者怎样引发与系统的交互部分。
环境描述的是刺激发生时的情况。
响应是指系统是如何通过体系结构对刺激作出反应的。
评估的主要方式：
基于调查问卷或检查表的评估方式
基于场景的评估方式
基于度量的评估方式
三种评估方式的比较：
ATAM评估的步骤：
1、描述ATAM方法：评估负责人
2、描述业务动机：项目经理或系统客户
3、描述SA：系统设计人员
4、确定体系结构方法：系统设计人员
5、生成质量属性效用树（utility tree）：说明构成系统“效用” 的质量属性（性能、有效性、安全性、可修改性、可用性） ，具体到场景层次，标注刺激/反应，并区分不同的优先级
6、分析体系结构方法
7、集体讨论并确定场景优先级
8、分析体系结构方法：针对步骤7的高等级场景
9、结果的表述：包括方法、场景、特定属性的问题、效用树、有风险决策、无风险决策、敏感点和权衡点
质量属性效用树：
但最重要的结果如下：
a. 文档化的体系结构方法
b. 若干场景及其优先级
c. 基于质量属性的若干问题
d. 效用树
e. 风险、无风险、敏感点、权衡点
f. 形成风险主题，根据某些常见的基本问题或系统缺陷将风险分组
SAAM ：主要分析体系结构的可修改性；
第十二章：
中间件是一种软件，处于系统软件（操作系统和网络软件）与应用软件之间。它能使处于应用层中的各应用成分之间实现跨网络的协同工作（互操作）。
中间件功能：
1．负责客户机与服务器之间的连接和通信，以及客户机与应用层之间的高效率通信机制。
2．提供应用层不同服务之间的互操作机制，以及应用层与数据库之间的连接和控制机制。
3．提供一个多层体系结构的应用开发和运行的平台，一集一个应用开发框架，支持模块化的应用开发。
4．屏蔽硬件、操作系统、网络和数据库的差异。
5．提供应用的复杂均衡和高可用性、安全机制与管理功能，保证交易的一致性。
6．提供一组通用的服务区执行不同的功能，避免重复的工作和使应用之间可以协作。
中间件分类：
中间件的发展趋势：
1、规范化。消息类的JMS，对象类的CORBA和COM、DCOM，应用服务器类的J2EE，数据访问类的ODBC和JDBC等。
2、构件化和松耦合。如基于Web Services和XML的中间件技术，使得不同系统、不同应用之间能够灵活的交互。Web Service提供了跨平台的能力，XML则是跨平台的数据交换标准。
3、平台化。一些大的中间件厂商在已有的中间件产品基础上，提出了完整的面向互联网的应用解决方案。
主要中间件：
1、过程远程调用
2、对象请求代理
3、远程方法调用
4、面向消息的中间件
5、事务处理监控器
基于体系结构的软件设计ABSD方法有三个基础：
(1) 功能分解：在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术；
(2) 通过选择体系结构风格来实现质量和业务需求。
(3) 软件模板的使用：利用一些软件系统的结构。
有关的术语：
1、设计元素 ABSD方法是一个递归细化的方法，软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类。
2、视角和视图
考虑体系结构时，需要从不同的视角来描述系统。如
逻辑视图
进程视图（并发视图）
实现视图、
配置视图
3、用例和质量场景
用例除了使功能需求具体化，还必须使质量需求具体化。
在使用用例捕获功能需求的同时，我们通过定义特定场景来捕获质量需求，并称这些场景为质量场景。
在一般的软件开发过程中，我们使用质量场景捕获变更、性能、可靠性和交互性，分别称为变更场景、性能场景、可靠性场景和交互性场景。
ABSD方法和生命周期：
ABSD方法的输入：
抽象功能需求：包括变化的需求和通用的需求。
用例（实际功能需求）。
抽象的质量和商业需求。
质量因素（实际质量和商业需求）。
体系结构选项。
约束。
ABSD方法的步骤：
1、ABSD方法定义的设计元素
2、设计元素产生顺序
3、设计元素活动
ABSD步骤：
1、功能分解
2、选择体系结构风格
3、为风格分配功能
4、细化模板
5、功能校验
6、创建并发视图
7、创建配置视图
8、验证质量场景
9、验证约束
基于体系结构的软件开发过程可以分为独立的两个阶段：
实验原型阶段：
在第一个周期结束时，形成了两个版本，一个是图形用户界面的初始设计，另一个是问题域模型。
第二个开发周期：任务是设计一个正交软件体系结构。此周期又可细分为以下六个小的阶段。
(1) 标识构件 第一步；生成类图 第二步：对类进行分组 第三步：把类打包成构件
(2) 提出软件体系结构模型
(3) 把已标识的构件映射到软件体系结构中
(4) 分析构件之间的相互作用
(5) 产生软件体系结构
(6) 软件体系结构正交化
演化开发阶段：
步骤：
(1) 需求变更归类。首先必须对用户的需求变更进行归类，使变更的需求与已有构件和线索对应。对找不到对应构件和线索的变更，也要做好标记，在后续工作中，将创建新的构件或线索，以满足新的需求。
(2) 制订体系结构演化计划：在改变原有结构之前，开发组织必须制订一个周密的体系结构演化计划，作为后续演化开发工作的指南。
(3) 修改、增加或删除构件。
(4) 更新构件的相互作用。
(5) 产生演化后的体系结构。在原来系统上所做的所有修改必须集成到原来的体系结构中。
(6) 迭代：如果在第(5)步得到的体系结构还不够详细，不能实现变更的需求，可以将(3)-(5)步再迭代一次。
(7) 对以上步骤进行确认，进行阶段性技术评审。
(8) 对所做的标记进行处理。重新开发新线索中的所有构件，对已有构件按照标记的要求进行修改、删除或更换。
基于体系结构的软件开发模型(ABSDM)将软件开发过程划分为体系结构需求、设计、文档化、复审、实现、演化等六个子过程。
基于体系结构的开发模型： 体系结构需求过程：
体系结构的需求过程：需求获取；标识构件；需求评审。
体系结构设计过程： 体系结构实现过程：
体系结构演化过程：