iweroulsdjf

5 月 1 日 ~6 月 30 日 分为三个阶段

一、 5 月 1 日 ~5 月 21 日。完成初期文档

1-2  需求分析阶段

说明：用于了解 SOA 及项目的具体要求

3-5  讨论并形成系统构架的雏形

说明：这三天时比较关键的三天，主要是基于前 2 天对项目的理解，大家行进大量的讨论。讨论的主要目标应该是项目的主体框架，主要的功能，最终形成一个框架图和功能列表（功能可能会不全，应尽力去想）。注意及时做笔记。

6-7        形成系统构架的初稿

说明：因为这两天是周末，时间比较集中，可以三个人在一起研究并把系统架构形成文档的形式，并对各个组件进行分工。

8-9        收集并研究各组件的资料

说明：这两天的任务是收集所设计组建方面的资料。包括：组件所需技术，实现所需软件列表，更主要的是组件的设计。关键是怎样设计的，其他人可以提出意见。

10-11       形成组件设计的文档

说明：把前两天的东西形成文档的形式。

12-13        把系统构架和组件设计两个文档放到一起加工、整合、修改，形成设计文档。

14       解释 SOA 思想和方法在本系统开发中的应用。

15-19        分工进行业务模式分析和设计，服务模型分析和设计。

说明：这几天的任务要重一些，而且要分头进行，因为这个是可选的交付件，我想我们还是把它做了吧。主要是搜集资料，明确定义，并做笔记。

20        形成前面的文档

说明：这一天是周末，一天的时间写一个文档，应该不累吧。

21        最终的审核，第一阶段结束。

二、 5 月 22 日 ~5 月 31 日。第二阶段 开发工具的学习

三、 6 月 1 日 ~6 月 27 日。第三阶段 做出演示版，形成系统的雏形。（这两个阶段等到具体时间再细化）

判定树是判定表的变种，也能清晰地表示复杂的条件组合与应做的动作之间的对应关系。判定书树的优点在于，它的形式简单到不需任何说明，一眼就可以看出其含义，因此易于掌握和使用。

结构化的最后一部份就是实现了，通常把编码和测试成为实现。在测试中分黑盒测试和白盒测试。如果已经知道了产品应该具有的功能，可以通过测试来检查是否每个功能都能正常使用；如果知道产品内部工作过程，可以通过测试来检验产品内部动作是否按照规格说明书的规定正常进行。前一个方法称为黑盒测试，后一个方法称为白盒测试。另外测试的时候还要遵守测试准则：

l         所有的测试都应该能追溯到用户需求。

l         应该在测试开始之前的相当长时间，就制定出测试计划。

l         把Pareto原理应用和软件测试。

l         测试应该从“小规模”开始，并逐步进行“大规模”测试。

l         穷举测试是不可能的。

l         为了达到最佳的测试效果，应该由独立的第三方来从事测试工作。

在设计测试方案时，往往需要仔细分析程序的控制流。为了突出表示程序的控制流，可以使用流图。流图仅仅描绘程序的控制流程，它完全不表现对数据的具体操作揖及分支或循环的具体条件。在流图中用圆表示节点，一个圆代表一条或多条语句。程序流程图中的一个处理框序列和一个菱形判定框，可以映射成流图中的一个节点。流图中的箭头线称为边，它和程序流程图中的箭头线类似，代表控制流。在流图中一条边必须终止于一个节点，即使这个节点并不代表任何语句。由边和节点围成的面积称为区域，当计算区域数时应该包括图外部未被围起来的那个区域。

逻辑覆盖式设计白盒测试方案的一种技术。设计测试方案时测试阶段的关键技术问题。所谓测试方案包括具体的测试目的，应该输入的测试数据和预期的输出结果。通常又把测试数据和预期的输出结果称为测试用例。覆盖标准大概有以下几种：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖。语句覆盖式含义是，选择足够多的测试数据，使被测试程序中每个语句至少执行一次。判定覆盖又叫分支覆盖，它的含义是，不仅每个语句必须至少执行一次，也就是每个判定的每个分支都至少执行一次。条件覆盖的含义是，不仅每个语句至少执行一次，而且使判定表达式中每个条件都取到各种可能的结果。既然判定覆盖不一定包含条件覆盖，条件覆盖也不一定包含判定覆盖，自然会提出一种能同时满足这两种覆盖标准的逻辑覆盖，这就是判定/条件覆盖。它的含义是，选取足够多的测试诗句，使得判定表达式中的每个条件都取到各种可能的值，而且每个判定表达式也都取到各种可能的结果。条件组合覆盖式更强的逻辑覆盖标准，它要求选区足够多的测试数据，使得每个判定表达式中条件的各种可能组合都至少出现一次。

基本路径测试是一种白盒测试技术，它的步骤如下：

l         根据过程设计结果画出相应的流图

l         计算流图的环形复杂度

l         确定线性独立路径的基本集合

l         设计可强制执行基本集合中每条路径的测试用例

结构化部分介绍完了，下面开始介绍面相对象的设计。通常需要建立三种形式的模型，它们分别是描述系统数据结构的对象模型，描述系统控制结构的动态模型和描述系统功能的功能模型。对象模型表示静态的、结构化的系统的“数据”性质。它是对模拟客观世界实体的对象以及对象彼此间的关系的映射，描述了系统的静态结构。面向对象方法强调围绕对象而不是围绕功能来构造系统。对象模型为建立动态模型和功能模型，提供了实质性的框架。

动态模型表示瞬时的、行为化的系统的“控制”性质，它规定了对象模型中的对象的合法变化序列。功能模型表示变化的系统的“功能”性质，它指明了系统应该“做什么”，因此更直接地反映了用户对目标系统的需求。

最近正在猛看软件工程，发现这门学科真的很有用，尤其是对于企业级别的软件的开发作用巨大。下面我就写一些关于软件工程方面的东西，就当作总结一下所学的内容吧。

我想这个问题应该从软件危机开始讲起吧，软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重的问题。具体来说：

l         对软件开发成本和进度的估计常常很不准确。

l         用户对“已完成的”软件系统不满意的现象经常发生。

l         软件产品的质量往往靠不住。

l         软件常常是不可维护的。

l         软件通常没有适当的文档资料。

l         软件成本在计算机系统总成本中所占的比例逐年上升。

l         软件开发生产率提高的速度，既跟不上硬件的发展速度，也远远跟不上计算机应用迅速普及深入的趋势。

　　而软件工程这门学科的出现也是为了从宏观的角度来观察软件，解决危机。软件工程师把系统化的、规范的、可度量的途径应用于软件开发、运行和维护的过程，也就是把工程化应用于软件中；研究中提到的途径。

软件工程的过程可以用软件生命周期来表示，生命周期的具体内容为：问题定义、可行性研究、需求分析、概要设计、详细设计、编码和单元测试、综合测试、软件维护。生命周期模型又分为以下几种：瀑布模型、快速原型模型、增量模型、螺旋模型、喷泉模型。

E-R 图、数据流图、状态转换图是结构化分析中的重点图。 E-R 图中包含了实体、关系和属性等三种基本成分。通常用矩形框代表实体，用连接相关实体的菱形框表示关系、用椭圆形或圆角矩形表示实体的属性，并用无向边把实体与其属性连接起来。数据流图有四种基本符号：正方形表示数据的源点或终点；圆角矩形代表变换数据的处理；开口矩形代表数据存储；箭头表示数据流，即特定数据的流动方向。在状态图中，初态用实心图表示，终态有一对同心圆表示。中间状态用圆角矩形表示，可以用两条水平横线把它分成上、中、下 3 个部分。上面部分为状态的名称，这部分是必须有的；中间部分为状态变量的名字和值，这部分时可选的；下面部分是活动表，这部分也是可选。

数据字典是所有与系统相关的数据元素的有组织的列表，并且包含了对这些数据元素的精确、严格的定义，从而使得用户和系统分析员双方对输入、输出、存储的成分甚至中间计算有结果有共同的理解。简而言之，数据字典是描述数据的信息的集合，是对系统中使用的所有数据元素的定义的集合。大多数数据字典都包含以下信息：名字、别名、使用地点与方式、内容描述、补充信息。

说完了结构化分析，该说说结构化设计了。其中模块是很重要的概念。模块是由边界元素限定的相邻的程序元素的序列，而且有一个总体标识符来代表它。有五条标准来评价一种设计方法定义有效的模块系统的能力：模块可分解性、模块可组装性、模块可理解性、模块连续性、模块保护性。有效的模块化的软件比较容易开发出来。这是由于能够分割功能而且接口可以简化，当许多人分工合作开发同一个软件时，这个优点尤其重要。独立的模块比较容易测试和维护。这是因为相对说来。修改设计和程序需要的工作量比较小，错误传播范围小，需要扩充功能时能够“插入”模块。模块的独立程度可以由两个定性标准来度量，这两个标准分别成为内聚和耦合。耦合衡量不同模块彼此间互相依赖的紧密程度；内聚衡量一个模块内部各个元素彼此结合的紧密程度。最好能做到松耦合、高内聚。

表示软件结构的图形工具有层次图、 HIPO 图和结构图，通常使用层次图描绘软件的层次结构。在层次图中一个矩形框代表一个模块，框间的连线表示调用关系。在自顶向下逐步求精设计软件的过程中，使用层次图很方便。 HIPO 图是美国 IBM 公司发明的“层次图加输入 / 处理 / 输出图”的英文缩写。为了使 HIPO 图具有可追踪性，在层次图里除了顶层的方框之外，每个方框都加了编号。结构图和层次图类似，也是描述软件结构的图形工具，图中一个方框代表一个模块，框内注明模块的名字或主要功能；方框之间的箭头（或直线）表示模块的调用关系。因为按照惯例总是图中位于上方的方框代表的模块调用下方的模块，即使不用箭头也不会产生二义性，为了简单起见，可以只用直线而不用箭头表示模块间的调用关系。

之后应该是过程设计了。过程设计的工具有：程序流程图、盒图（ N_S 图）、 PAD 图、判定表、判定树、过程设计语言（ PDL ）。程序流程图又成为程序框图，它是历史最悠久的使用最广泛的描述过程设计的方法，然而它也是用得最混乱的一种方法。盒图有下述特点：

l         功能域明确，可以从盒图上一眼就看出来。

l         不可能任意转移控制。

l         很容易确定局部和全程数据的作用域。

l         很容易表现嵌套关系，也可以表示模块层次结构。

PAD 图是问题分析图的英文缩写，自 1973 年由日本日立公司发明以后，已得到一定程度的推广。判定表能清晰地表示复杂的条件组合与应做的动作之间的对应关系。一张判定表由四部分组成，左上部列出所有条件，左下部是所有可能作的动作，右上部是表示各种条件组合的一个矩阵，右下部是和每种条件组合相对应的动作。判定表右半部的每一列实质上是一条规则，规定了与特定的条件组合相对应的动作。（未完待续）

从上图中可以注意到一个 IT 难题，那就是大多数应用程序之间直接相互通信。当应用程序需要修改或淘汰时，这种依赖便成为一个实际问题。任何修改都可能会按其自身的方式更新每条唯一的通信线路。因此，这种变更可能代价高昂。这种情况被称为应用程序间的紧耦合，也逐渐成为让一些企业头疼的问题。

另一方面，SOA 将松耦合作为成功的企业级应用程序集成的一个主要原则。与紧耦合相反，松耦合是：

限制请求者应用程序代码和提供者应用程序代码的相互了解。如果耦合的服务任何方面有所变化，那么，请求者或提供者的应用程序代码（更可能是两者同时）必须改变。如果任何一方（请求者、提供者或中介基础架构）对解耦的服务任何方面作出改变，那么其它几方不必随之改变。

连续两次的发邮件都被返，理由是IBM没有soacontest这个邮箱！我们都快崩溃了。幸好我们是实习生，有IBM内部的通讯工具。在报名的网站找到了叫王婷婷的负责人的email，但是不幸的事又发生了，那个email也不好用。最后只能搜索人名了，找到了3个叫王婷婷的人。第一个，第二个都不是。终于第三个找到了她，但是她还是让我往那个邮箱里发信，我解释了一下。说我已经发了两次了，都不好使。faint~,最后她只能用I will check来结束我们的对话，我也只能等待她的消息了。希望能够早些把名报上吧。唉！

又读完了一个系列7篇文章，感觉对SOA有个更深的理解，我总结之！继续！
第一部分：
编程模型的定义为：
程序员构建的一套部件类型。部件类型包括多种编程模型构件：超文本标记语言（HTML）文件、数据库存储过程、Java 类、可扩展标记语言（XML）Schema 定义、定义 MQSeries 消息的 C 结构，等等。
一系列角色，将具备相似技能和知识的开发和管理人员分组。用这种方式对开发人员分类有助于生产适应于角色的工具，使非程序员可以实现服务并将服务组装为解决方案。业务分析人员定义业务流程，销售专家定义顾客分类的策略并计算产品折扣。每一种角色包含：
1.角色所具备的技能。例如，用户界面开发人员开发界面，用来呈现应用程序或者解决方案的功能构件。假设这个角色了解正在开发的应用程序和它的业务目标，充分了解应用程序的用户及他们的任务，精通一些用户界面设计方法，能够通过为每个任务选择恰当的类型来创建易于使用的用户接口。
2.角色交互（消费或者生产）所用的部件类型和应用程序接口。例如，动态页面设计人员 -- 角色 -- 生产 JavaServer Page（JSP）并消费 EJB-- 部件类型 -- 包装现有的信息资源和应用程序。
3.角色使用的工具。例如，Web 开发人员所用的适合于角色的工具是所见即所得的页面设计工具，用来构建动态页面，使用与 HTML 和 JSP 标签库相关的控件，并将控件连接到 EJB。
第二部分：
这部分提出了一个很重要的概念-----服务对象数据（Service Data Object，SDO），它使用统一的抽象代替了各种各样的数据访问模型来创建、检索、更新和删除供服务实现使用的业务数据。SDO 定义了一种单一的、统一的方法来访问和操作来自异构数据源的数据，包括关系型数据库、可扩展标记语言eXtensible Markup Language，XML）数据源、Web 服务以及企业信息系统 (EIS)。它们是基于数据图（data graph）的概念。数据图就是一组可以从数据源中分离出来的树形结构的对象。SDO 可以在整个应用程序体系结构中使用。
这部分还给出了许多的示例:
示例 1. 使用 XML 的 SDO 类型定义

<? xml version="1.0" encoding="UTF-8" ?>
< schema  xmlns ="http://www.w3.org/2001/XMLSchema"  
                xmlns:tns ="http://www.myvalue.com"
        targetNamespace ="http://www.myvalue.com" >
     < element  name ="customer"  type ="Customer" />
     < complexType  name ="Customer" >
         < sequence >
             < element  name ="customerID"  type ="string" />
             < element  name ="firstName"  type ="string" />
             < element  name ="lastName"  type ="string" />
             < element  name ="stockSymbol"  type ="string" />
             < element  name ="stockQuantity"  type ="int" />
         </ sequence >
     </ complexType >
</ schema >

示例 2. 使用 Java 的 SDO 类型定义

public   interface  Customer  {
    String getCustomerID();
     void  setCustomerID(String customerID);
    String getFirstName();
     void  setFirstName(String firstName);
    String getLastName();
     void  setLastName(String lastName);    
        String getStockSymbol();
     void  setStockSymbol(String stockSymbol);
     int  getStockQuantity();
     void  setStockQuantity( int  stockQuantity);
}

还有一些示例，可以查看http://www.cppblog.com/zhangji198543/archive/2006/04/17/5702.html
第三部分：
这部分讲了业务流程和业务状态机。概要地列出了 BPEL 的一些特性以及 IBM 的 WebSphere Business Integration 中的 BPEL 实现所提供的扩展：
1.可以与多个合作伙伴交互的长时间运行的业务流程。
2.将人员整合到流程。
3.将流程嵌入到 Java™ 2 Platform, Enterprise Edition (J2EE)。
4.服务质量。
5.与 WebSphere 集成。
下图为表示订购单的业务状态机，很有启发性：

第四部分：
这一部分对IBM 企业服务总线做了介绍，IBM ESB 模式提供以下几方面的虚拟化：
1.位置和标识。
2.交互协议。
3.接口。
4.（交互）服务质量 (QoS)。
另外用户角色也是很重要的，对我们以后的开发人员分配有帮助。业务分析人员确定业务需求，并检查业务流程。他们将概括出解决方案的目标、涉及的业务流程、监视解决方案的运行状况和状态的关键指标，以及 IT 系统需要提供的业务服务的类型。
解决方案架构师确定哪些业务需求可以通过对现有 IT 资产进行重用、修改或组合得到满足，哪些需要编写或购买新的 IT 资产。他们定义 IT 资产间的交互，包括消息交换的内容。
开发工作在三个角色中分配。实现人员编写新的应用程序代码，这些代码将通过服务接口调用。适配器开发人员构建包装现有或新采购的应用程序和软件包的服务，从而为其他服务提供可访问性。集成开发人员使用 ESB 的相关工具和技术构建逻辑，以控制请求在这些服务间路由的方式。
最后讲了ESB模式:
1.交互模式：允许服务交互点将消息发送到总线或从总线接收消息。
2.中介模式：允许对消息交换进行操作。
3.部署模式：支持将解决方案部署到联合基础设施中。
模型-视图-控制器（Model-View-Controller，MVC）范例是现代大多数 UI 应用程序框架的基础。SOA 操作提供模型层，而 UI 位于视图层。UI 技术可以在各种设备上呈现信息，这些设备包括的范围很广，从窗口小部件和智能电话到浏览器和能够进行大量客户端处理的富客户机。中间件和工具将视图层 UI 技术连接到模型层 Web 服务和数据。
第五部分:

在 SOA 方法中，宿主组件的环境抽象成容器，它提供已知的服务集。从 UI 的角度来说，承载客户端 UI 组件的三个主要的容器是：

基本 Web 浏览器。
使用 Java™Script 和动态 HTML 增强的 Web 浏览器。
IBM Workplace™ Client Technology™——具有本地 IBM WebSphere® Application Server 客户机支持的 Eclipse 富客户机。
这些容器可以通过支持下列技术得以增强：Servlet、JavaServer Page (JSP) 和 JSP Tag；用于页面排序的 Struts；用于高级页面组合的 JavaServer Face (JSF)；以及合并在同一页面上的多应用程序视图的 Portlet 技术。

UI 开发框架可以简化创建面对用户的复杂应用程序的过程。通常使用下列的 UI 框架来创建 UI 组件：
1.Struts，
2.JavaServer Faces
3.Java Widget Library (JWL)

第六部分：
组件是这篇文章的重点。组件这个概念在其他方面的程序设计中也是经常用的到。而对 SOA来说良好定义的组件应该支持生态系统中的各种用户角色——例如业务分析人员、集成开发人员、适配器开发人员和解决方案管理员——通过实例化、使用、组装和自定义符合用户目标、技能和概念性框架的不同组件类型，来创建面向服务的应用程序。
SOA 是一种分布式组件体系结构。SOA 组件封装功能，并支持通过业务分析人员和业务模型建模的抽象级别的重用。声明性的、计算机可处理的约定允许第三方访问 SOA 组件提供的服务。可以动态地发现、选择、绑定（通过其声明性属性）和集成SOA 组件。

我们的 SOA 是由以下规范定义的：

一、服务规范 以组件提供和使用的一组服务的形式提供了组件的视图。它由以下三组规范定义：
1.接口，通常是 WSDL portTypes。
2.策略，记录 QoS 属性，例如事务行为和安全性。
3.行为描述，例如 BPEL4WS 抽象流程。另一个例子可能是统一建模语言 V2 (UML2) 状态模型，该模型指定了哪些操作对不同的状态和操作所引发的状态事务是有效的。调用方可以通过状态模型计算有效的操作序列。
二、服务组件实现 是由以下四组规范定义的：
1.提供的服务规范。
2.需要的服务规范。
3.可以在组件上设置以调整或自定义的属性。
4.为此提供基本支持的属性；更复杂的方案使用可变点和对自定义组件的外部调用。
5.对所有实现实例都保持不变的容器指示（策略）。
6.定义组件实现的实现构件（例如 Java 类、BPEL 文档或 XSLT 规则集）。
三、服务组件（实例）由以下规范定义：
1.名称。
2.服务组件实现。
3.实现的任何属性的值，设置用于调整实例。
4.任何服务的规范，解析实现需要的服务规范。它们可以是连接组件实例的“网络”，也可以是在运行时执行以查找组件的“查询”，所查找的组件实现相关接口，具有相关的 QoS 策略，并且匹配指定的行为（例如抽象流程或状态模型）。

有两种定义 SOA 组件的基本方法。这些定义可以通过开发工具生成，也可以由开发人员手动创建。

第一种方法是控制文件，顾名思义，控制文件即关联或联接组件的所有部分的文档。例如，控制文件可以引用 WSDL 定义（提供的接口）、实现组件的 Java 类（实现构件）或相关的策略文档（策略断言）。 它们可以是对文件系统、类路径、源代码管理系统或 Web URL 的引用。控制文件方法将多个单独开发的构件聚合在一起组成组件。应用程序开发工具可以帮助定义控制文件。

第二种方法是使用 pragmas，指定相同信息的语言元素，但是包含在单个源文件的主体中。Java 方面的支持正在不断增加（例如，JSR 175 中的 XDoclet 标记），以用 Java 语言编写这些批注部分。但是这种方法尚不支持其他等同的有效 SOA 组件实现技术（如 SQL 或 XQuery 语句集）。每种组件类型都有用于其实现构件的相关源文件格式，例如 Java 文件、状态机或 SQL 文件。IBM WebSphere® Rapid Deployment 中的批注支持可以生成所有组成包含 pragmas 的源文件中的组件的单个元素。例如，Java 源文件中的结构化注释指示哪些 Java 方法将成为所生成的定义组件的服务接口中的 Web 服务操作。

第七部分：
次篇文章在安全性的角度讨论了SOA，尤其是如何去保护SOA应用程序。
总之，通过阅读这一系列文章，感觉到离SOA的具体实现又贴近了一步，更加丰富自己这方面的知识。继续努力吧！

1. 范围 <此架构适用于企业的哪个领域>
2. 操作系统层
   1. 打包的应用程序
   2. 自定义应用程序
   3. 架构决策
3. 企业组件层
   1. 企业组件支持的功能范围
   2. <这个企业组件支持业务领域、目标和过程>
   3. 关于控制的决策
      1. <作为这个客户端组织内部企业组件来选择某物的标准>
   4. 架构决策
4. 服务层
   1. 服务分类表
   2. 架构决策
5. 业务过程和合成层
   1. 业务过程可以表现为舞蹈编排（choreographies）
   2. 架构决策
      1. <哪一个过程需要编排在舞蹈编排里面以及哪一个镶嵌在应用程序里面？>
6. 访问或者表现层
   1. <证明这层中 Web 服务和 SOA 的含意；即便要。例如，在用户接口级别上调用 Web 服务的 portlet 的使用，以及在此层机能上的含意。>
7. 集成层
   1. <包含 ESB 因素>
   1. <我们如何确保使用服务的客户端系统级的一致性（SLA）和服务质量（QoS）？>
   2. 安全问题和决策
   3. 性能问题和决策
   4. 技术和标准的局限性以及决策
   5. 服务的监控和管理
      1. 描述和决策

层 1：操作系统层。本层包含现有的自定义构建的应用程序，也叫做 遗留系统，包含现有的 CRM 和 ERP 打包应用程序，以及 较旧的基于对象的系统实现，还有业务智能应用程序。SOA 的复合层架构可以利用现有的系统并且用基于服务的集成技术来集成它们。

层 2：企业组件层。本层由那些负责实现功能和保持公开服务 QoS 的企业组件组成。这些特殊的组件是企业和业务单元级支持的企业资产的受管理和控制的集合。 同企业范围资产一样，他们通过架构最佳实践应用程序来负责确保 SLAs 的一致。大多数情况下，本层使用基于容器的技术，比如实现组件、负载均衡、高可用性和工作量管理的应用服务器。

层 3：服务层。业务选择来支持和公开的服务处在这一层。它们可以被 发现或者直接静态绑定，接下来被调用，或者可能的话，编排到合成服务中。这个服务公开层同样提供了获取企业范围组件，业务单元特定组件，以及有些情况下，特定项目组建的机制，并且以服务描述的形式具体化了他们的接口子集。因此，企业组件使用它们接口提供的功能在运行时提供服务实现。在这一层的接口公开为一个服务描述，在这层中他们被公开以提供使用。他们可以独立存在或者作为合成服务。

层 4：业务过程合成或编排层。第三层中公开的服务的合成和编排在这一层中被定义。通过配合、编排，服务被绑定成一个流程，并且从而作为单独的应用程序而共同作用。这些应用程序支持特殊的用例和业务过程。这里，可视的流程合成工具，比如 IBM® WebSphere® Business Integration Modeler 或者 Websphere Application Developer Integration Edition，都可以用来设计应用程序流程。

层 5：访问或表现层。尽管这一层经常超出了围绕 SOA 讨论的范围，但是它却变得越来越有意义。在这里我描述它因为标准越来越集中，比如用于 Remote Portlets Version 2.0 的 Web 服务和其他技术，这些技术追求在应用程序接口或者表现层来利用 Web 服务。你可以把它作为将来的层用来满足将来的解决方案的需求。注意到以下这两点是非常重要的：SOA 将用户接口从组件中分离出来；最终你需要提供从访问路线到服务或者合成服务的端到端解决方案。

层 6：集成（ESB）。这一层使服务可以集成，通过引入一系列可靠的性能的集合，比如智能路由，协议中介和其他转化机制，经常被描述为 ESB（参阅 参考资料）。Web Services Description Language（WSDL）制定了绑定，其包含提供服务的地址。另一方面，ESB 为集成提供了位置独立机制。

层 7：QoS。这一层提供了监视，管理和维持诸如安全，性能和可用性等 QoS 的能力。这是一个通过 sense-and-respond 机制和监测 SOA 应用程序健康的工具来进行的后台处理过程，包括 WS-Management 和其他相关协议的所有的重要的标准实现以及为 SOA 实现服务质量的标准。

好不容易到了个周六，疲惫的身躯可以暂歇了。不过下周六还有《软件工程》考试，抓紧学习了。
从学习SOA开始到现在，已经有6天了。文章也看了不少了，可是我们还是不知如何下手。那些文章都是理论上了，至少暂时并没发现有多少代码。面对这次比赛的医疗机械行业的实例来说还是有些棘手，哎，慢慢来吧，坚持就是胜利。