iweroulsdjf

又读完了一个系列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的具体实现又贴近了一步，更加丰富自己这方面的知识。继续努力吧！