云南大学软件学院Byter团队专栏

SOA学习笔记之SOA第一感

leobamb — 5/31/2006 7:09:00 AM

SOA第一感
------学习SOA后的一点点认识

    SOA是英文Service Oriented Architecture的简写，中文意思是面向服务架构，网络上关于SOA方面的说明不是很多，对于SOA到底是什么没有很明确的定义，毕竟这个词汇太新了，这里我引用网络上一篇文章对SOA下个简单的定义：
    SOA是指为了解决在Internet环境下业务集成的需要，通过连接能完成特定任务的独立功能实现的一种软件系统架构。
    分析这个定义我们可以得出结论：为了解决在Internet环境下业务集成的需要是目的，连接完成特定任务的独立功能实现是手段。
    首先，SOA产生的目的是为了解决在Internet环境下业务集成的需要。需求决定同时也限制功能，不同的业务需求造成了软件系统的不同；SOA最主要的应用场合在于解决在Internet环境下的不同商业应用的业务集成问题。SOA是Internet发展到一定阶段的必然产物，Internet环境下大量异构并存，即计算机硬件工作方式不同，操作系统不同等等；大量、频繁的数据传输仍然速度缓慢并且不稳定。SOA的出现就是为了解决对这些不同商业应用系统的整合，来满足大规模企业对大而复杂应用系统的需求。
    其次，SOA不是一种语言，也不是一种具体的技术，而是一种软件系统架构，分析“软件系统架构”这个词的时候，我们首先应该理解架构的概念，其次才是软件系统。如果把软件开发分层，软件系统就属于技术层面上的，包括独立完成特定任务的各个子模块的代码实现；而系统构架属于整合、集成层面上的。构架应该是发生在软件系统的具体实施之前，它不关心每个子模块的具体实现，只关心每个子模块与别的模块发生作用时提供的接口，只要各个模块达到足够程度的松耦合，就能最大效率的实现重用的目的，以使软件系统达到最大的开发效率与作用。
    在SOA中，还有一个概念是不能忽视的，那就是面向服务，一个应用程序的业务逻辑或某些单独的功能模块，都可以模块化作为服务呈现给消费者或者客户端，这些消费者或者客户端可以分别指另一个程序员或者另一个系统，而服务的关键是它们的松耦合特性以及接口与实现相互独立。
    SOA的三大特征：
    构架中提供服务的功能实体的完全独立自主的能力，为解决在松散Internet环境下进行控制所面临的稳定性问题提供保障。
    采用大数据量的方式一次性进行信息交换，解决传统系统函数调用所带来的响应速度和稳定性问题。
    基于文本的消息传递解决Internet环境下，不同语言、不同平台对数据格式统一的依赖，最大限度达到兼容性。

soa学习认识

summer — 5/29/2006 6:19:00 AM

XML认识
背景
Xml是一种可扩展的标记性语言，它使用一种更加精确，更加灵活，更加适合的标记信息的方法而提高Web的功能。
XML和HTML的区别
XML和HTML都来自于SGML，它们都含有标记，有着相似的语法，HTML和XML的最大区别在于：HTML是一个定型的标记语言，它用固有的标记来描述，显示网页内容。比如

表示首行标题，有固定的尺寸。相对的，XML则没有固定的标记，XML不能描述网页具体的外观，内容，它只是描述内容的数据形式和结构。
这是一个质的区别：网页将数据和显示混在一起，而XML则将数据和显示分开来。
扩展性使用XML你可以为你的文档建立自己的标记(tags)
XML的第一个词是"扩展性"，这正是XML强大的功能和弹性的原因。
在HTML里，有许多固定的标记，我们必须记住然后使用它们，你不能使用HTML规范里没有的标记。而在XML中，你能建立任何你需要的标记。你可以充分发挥你的想象力，给你的文档起一些好记的标记名称。

显示
单独用XMl不能显示页面，我们使用格式化技术，比如CSS或者XSL，才能显示XML标记创建的文档。 XML文档本身不知道如何来显示，必须有辅助文件来帮助实现。(XML取消了所有标识，包括font,color,p等风格样式定义标识，因此XML全部是采用类似DHTML中CSS的方法来定义文档风格样式。)，XML中用来设定显示风格样式的文件类型有：
XSL
XSL全称是Extensible Stylesheet Language(可扩展样式语言), 是将来设计XML文档显示样式的主要文件类型。它本身也是基于XML语言的。使用XSL，你可以灵活的设置文档显示样式，文档将自动适应任何浏览器和PDA(掌上电脑)。
XSL也可以将XML转化为HTML，那样，老的浏览器也可以浏览XML文档了。
CSS
一种用得最多的HTML的显示样式，也可以用于XML的显示样式。

.DOM
DOM全称是document object model(文档对象模型)，DOM是用来干什么的呢？假设把你的文档看成一个单独的对象，DOM就是如何用HTML或者XML对这个对象进行操作和控制的标准。
它规定了HTML/XML文档对象的命名协定，程序模型，沟通规则等。在XML文档中，我们可以将每一个标识元素看作一个对象---它有自己的名称和属性。
XML创建了标识，而DOM的作用就是告诉script如何在浏览器窗口中操作和显示这些标识
DTD
DTD是一种保证XML文档格式正确的有效方法，可以比较XML文档和DTD文件来看文档是否符合规范，元素和标签使用是否正确。一个DTD文档包含：元素的定义规则，元素间关系的定义规则，元素可使用的属性，可使用的实体或符号规则。
调用DTD文件的方法有两种：
1.    直接包含在XML文档内的DTD
2.    2.调用独立的DTD文件
Schema(规划)
schema是数据规则的描述。schema做两件事：
a.它定义元素数据类型和元素之间的关系；
b.它定义元素所能包含的内容类型。
DTD就是关于XML文档的一个schema。

Web Service
Web Service
Web Service 技术是一种基于标准的Web 协议的可编程组件a programmable
application component accessible via standard web protocols 我们可以把Web Service 看作
Web 上的组件Web 服务提供者开放一系列API 开发人员通过调用这些API 来集成Web
服务构建自己的应用程序这种调用和从前的本地服务调用是很接近的不同在于调用
的服务存在于某个远程系统上我们不关心这个远程系统是在地球的另一端还是在隔壁的
屋子里因为本质上来讲我们使用域名和IP 来访问这些系统这种调用也和从前的组件对
象调用很接近不同在于这些调用是基于消息机制和标准的Web 协议之上的如HTTP
SMTP 等基于消息的异步技术因此它们可以轻易的穿过企业的防火墙并具有相当大的可
扩展性
Web Service 包含了服务发现Discovery 服务描述Description 连接格式Wire
Format 三个阶段服务发现阶段指的是发现和定位某个服务并获取关于其能力的信息
服务发布者通过一个XML 格式的disco 文件来提供给服务使用者在程序中发现服务的能
力服务描述阶段使用某些语言例如基于XML 的WSDL Web Services Description
Language 语言来获取该服务的调用规范等信息根据WSDL 语言中描述的连接格式采
用标准的Web 协议如HTTP-POST HTTP-GET SOAP MIME 等来实现服务提供者和使
用者之间的通讯包括描述服务请求服务和相应服务
WSDL
WSDL（Web Service Description Language）。当Web service建立起来后。你会怎样向别人介绍你的Web service有什么功能，以及每个函数调用时的参数呢？你可能会自己写一套文档，你甚至可能会口头上告诉需要使用你的Web service的人。这些非正式的方法至少都有一个严重的问题：当程序员坐到电脑前，想要使用你的Web service的时候，他们的工具(如Visual Studio)无法给他们提供任何帮助，因为这些工具根本就不了解你的Web  service。解决方法是：用机器能阅读的方式提供一个正式的描述文档。Web service描述语言(WSDL)就是这样一个基于XML的语言，用于描述Web service及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的，这将是一个很大的好处。一些最新的开发工具既能根据你的Web service生成WSDL文档，又能导入WSDL文档，生成调用相应Web service的代码。
SOAP
SOAP（Simple Object Access Protocol ）简单对象访问协议是在分散或分布式的环境中交换信息的简单的协议，是一个基于XML的协议，它包括四个部分：SOAP封装(envelop)，封装定义了一个描述消息中的内容是什么，是谁发送的，谁应当接受并处理它以及如何处理它们的框架；SOAP编码规则（encoding rules），用于表示应用程序需要使用的数据类型的实例; SOAP RPC表示(RPC representation)，表示远程过程调用和应答的协定;SOAP绑定（binding），使用底层协议交换信息。
UDDI
统一描述、发现和集成（Universal Description, Discovery, and Integration，UDDI）项目继续丰富企业用于在 UDDI 业务注册中心表示 Web 服务并建立其模型的工具集。UDDI 提供了一组基于标准的规范用于描述和发现服务，还提供了一组基于因特网的实现。UDDI 基于现成的标准，如可扩展标记语言（Extensible Markup Language，XML）和简单对象访问协议（Simple Object Access Protocol，SOAP）。UDDI 的所有兼容实现都支持 UDDI 规范。公共规范是机构成员在开放的、兼容并蓄的过程中开发出来的。UDDI 构建于网络传输层和基于 SOAP 的 XML 消息传输层之上。诸如 Web 服务描述语言（Web Services Description Language，WSDL）之类的服务描述语言提供了统一的 XML 词汇（与交互式数据语言（Interactive Data Language，IDL）类似）供描述 Web 服务及其接口使用。您可以通过添加分层的功能搭起整个基础，比如使用 Web 服务流程语言（Web Services Flow Language，WSFL）的 Web 服务工作流描述、安全性、管理和服务质量功能，从而解决系统可靠性和可用性问题。
SOA
SOA（Service Oriented Architecture）面向服务架构。是一种为了整合多个异构的组件（也可以不是组件，可以是更大的功能单位）为了实现他们的低耦合。并且能够动态的增加，删除服务组件而采取的一种构架模式。

SOA是面向服务的架构，所以对于企业的业务的敏捷性要作出必要的响应。它随着业务的更新而更新，一个成功的SOA是处于不断的变化当中的。

SOA中的一种互为生产者与消费者的关系，有的组件提供服务，同时又得使用别的组件提供的服务。而他们都同过一种低层的接口，一个定义好的统一接口模式进行交互。

一些专家的看法（转自IBM网站）

yundazyx — 5/28/2006 5:56:00 AM

何时采用 SOA，何时不采用 SOA
IBM 的目标之一是在其产品内开发和采用开放标准。通过这样做，就能在您公司的 IT 基础结构中实现 SOA 的价值主张。SOA 能够优化业务需求与 IT 的一致性，能够将业务流程活动从服务实现中分离出来，还能够降低操作成本。只有在不固定供应商的情况下才能真正实现这些功能，此时面向 SOA 实现的技术可以无缝集成（考虑：“开放标准”），以构造全面的端到端解决方案。

不可轻易决定实现 SOA。这与改变生活方式有些类似，因为开发和操作团队遵循的 IT 控制模式将完全不同。
——Holt Adams

当考虑了策略业务目标和活动时，理论上的 SOA 概念非常具有吸引力，更加容易得到支持。不过，不可轻易决定要实现 SOA。这与改变生活方式有些类似，因为开发和操作团队遵循的 IT 控制模式将完全不同。我提倡进行业务驱动开发。此过程涉及到将业务需求细化为 IT 要求，然后将 IT 要求细化为 IT 功能，以确定满足这些需求所需的技术。根据我过去四年开发基于 Web 服务的解决方案和更为成熟的基于 SOA 的解决方案的经验，以下这些相关因素通常会让我建议采用面向服务的体系结构：
•    集成成本持续增长，而并未因为可提供真正投资回报 (ROI) 的新业务机会而得到缓解。
•    兼并和收购是您公司扩大市场份额和获得新发展机会的业务模式的核心。
•    解决方案要求对来自异构系统和编程模型的业务功能进行集成。
•    业务的生存依赖于根据市场变化快速调整或即时响应竞争威胁的能力。
•    全球经济的影响要求您的公司事半功倍地开展业务，而且有必要依赖业务合作伙伴提供非核心业务功能。
•    就提高收益而言，与业务合作伙伴协作的效率对您的公司十分关键。
•    您公司业务资产的价值在减少，因为不能对其进行评估，以在最初用途之外的其他地方使用。
•    您公司员工的效率出现了问题，因为他们的大部分时间并没有花在提供公司业务模型的核心功能和服务上。
•    您公司的业务充满了机会型的业务工作。
•    您公司从头开始开发新应用程序。（我认为 SOA 应当作为定位将来的新应用程序的缺省体系结构样式，业务条件有其他限制时除外。）
在理想情况下，您和您的业务合作伙伴间没有预算限制、计划期限、技能差距和优先级差异，我想，此时完全可以说每个人都会采用 SOA，或者至少会考虑采用 SOA。不过，我们的选择实际上经常受到过去的决策的影响和限制（例如，技术投资、编程模型采用、服务的合同协定等）。因此，我们并不能总是自由地采用看起来能满足某个业务需求或技术要求的最佳选项。以下的注意事项会让我不建议采用面向服务的体系结构或说明现在实现 SOA 的边际收益：
•    您公司只将小部分 IT 预算用于集成活动。
•    您公司的大部分流程都是手动的或以文档为中心的，自动化的机会几乎为零。
•    您公司的大部分应用程序开发都使用相同的编程模型。
•    您公司的操作由一个或两个客户关系管理 (CRM) 和企业资源规划 (ERP) 应用程序管理，几乎没有集成要求。
•    您公司的现有技能库与实现支持 SOA 的基础结构所需的技能库之间存在重大差异。
•    未发现可从 SOA 提供的功能受益的业务需求或机会。
•    新业务服务的可用性将对现有的收益流带来负面影响。
•    您公司依赖的业务合作伙伴对公司间流程的自动化采用了不同的优先级。
•    您公司的主要业务的开展涉及到海量且同步性和实时性要求非常高的事务。
前面的列表只是一个示例，用以说明 SOA 是否是您公司最佳选择的原因。当然，每个合同或项目都具有唯一的要求，因此关于何时采用 SOA 的决策取决于您公司的业务状况。SOA 的价值主张十分诱人，但选择何时让您的公司采用 SOA 必须考虑业务环境的实际情况。采用 SOA 不一定要跨一大步，而通常是采用循序渐进的方式进行的。首先找到可以利用 SOA 概念和原则的项目，然后使用主要性能指标测定其价值，这是一种让大家受益的好方法。

回页首

将业务与 IT 结合起来
SOA 不仅是一个开发范例。该体系结构用于在业务和 IT 之间构建中间地段，其中包含双方都同意的一组与业务一致的 IT 服务，这些服务结合在一起，以实现组织的业务流程和目标。此范例提供了前所未有的灵活性：它允许将业务流程的结构化组成从为流中每个活动提供功能的服务中分离出来。它还允许将业务实现与其描述分离开来。进行了此分离后，公司能以增量的方式更改其后端遗留系统，并添加新功能来支持新需求，而不用受到供应商选择的限制。因此，可以在最小化对业务流程和 IT 系统的影响的前提下对软件包和自定义应用程序进行替换。
将访问功能从其实现分离的下一步工作就是 SOA。而且，除了此功能方面外，我们还可以将非功能方面外部化。例如，我们可以根据建立的业务策略确定哪些人应该可以访问特定的功能。我们还可以定义如何管理希望以灵活的、可重构的方式访问的技术资源。

使用 SOA 技术时，实时或被动系统通常不是进行实现的最佳选择，因为当前的技术不支持将 SOA 用于有大量并发使用情况的实时系统。不过，这些系统的建模也可以从 SOA 提供的分离和独立概念获益。
——Ali Arsanjani

软件工程发展的下一步就是此体系结构。它使我们从结构化对象转向分布式对象和组件，然后以一组公共服务为中心来将业务和 IT 加以结合（这些服务结合在一起，可以实现组织的流程和目标）。SOA 还允许将公司的部分业务流程向生态系统中的合作伙伴公开。
当需要支持业务灵活性的 IT 灵活性时，就可以使用 SOA。因此，对于两个程序需要进行通信并访问组合业务流程的行业应用程序而言，就非常适合选择 SOA。
使用 SOA 技术时，实时或被动系统通常不是进行实现的最佳选择，因为当前的技术不支持将 SOA 用于有大量并发使用情况的实时系统。不过，这些系统的建模也可以从 SOA 提供的分离和独立概念获益。
SOA 非常适合用于消除冗余及将业务与未紧密耦合到特定服务实现的 IT 功能相结合。它可以允许服务使用者选择后备服务提供者（不仅基于功能进行选择——我需要类似的功能，但不要此版本的服务中的额外依赖项，还可以基于设计及运行时策略和 Web 服务管理功能进行选择）。
企业体系结构基于 SOA 的公司具有稳定的基础，能从现有系统概念地抽象业务功能。它们还具有允许随着新软件包、系统和资产的提供和新需求的出现以增量的方式进行业务驱动的 IT 转换的基础。

回页首

一个重要但略显不足的机制
在企业范围中，大量的创新都出现在以下两个方面：企业边缘和企业之间。在边缘上，我们可以看到在中间件之上的框架投入了很多精力（独立于领域的框架，如 Ajax，以及特定于领域的框架，以特定行业为中心进行结合），也投入了很多精力进行与设备相关的工作 [ 典型的移动设备和具有无线频率识别（Radio Frequency Identification，RFID）标记的设备 ]。而在企业之间，我们可以看到系统（遗留系统和新系统）的系统的形成。

在边缘，服务提供超越基础技术的行为。而在企业之间，服务提供了各种系统间语义丰富的强大通信方式。
——Grady Booch

在此类以 Web 为中心的系统中，服务已被证实为这两个方面的重要机制。在边缘，服务提供超越基础技术的行为。而在企业之间，服务提供了各种系统间语义丰富的强大通信方式。
虽然这样说，但在系统的构造中，服务是一个重要却略显不足的机制。这样说有些过于简单化，但总的说来，服务对于高频率或非常小粒度的连接而言，并不非常适合。而且，服务当然不是唯一适合各个系统的体系结构的分解机制。

回页首

SOA、Web 服务与优势保持
SOA 是一个使用得有些过量的首字母缩写，被从高级管理人员到开人员等各方面的人用（滥用）来传达多种（有时候是不一致的）语义。在我看来，面向服务的体系结构是一个框架，用于将业务流程和支持技术基础结构作为标准化且管理良好的组件——服务——进行集成，可以对服务进行组合、重用和调整以满足不断变化的业务优先级。
SOA 新手认为 SOA 和 Web 服务是等效的。可能存在不使用任何 Web 服务，而使用现有 IT 资产（从大型机事务到基于对象的系统）的基于 SOA 的有效解决方案。而且，我曾经看到过几个从部门级别发展出来的不是有效 SOA 应用程序的 Web 服务实现。这些 Web 服务岛通常并不完全遵循所有的核心 SOA 原则和特征——它们可能不是松散耦合、未抽象、不可重用、未组件化或不是独立于平台和协议的，最重要的是，它们可能不提供真正的业务价值。
由于 Web 服务提供了一个 Level 字段，供基础结构和应用程序供应商进行创新和互操作，很多规范、概要、术语都使得这一混淆扩大化了。Web 服务仅是一个标准和技术的集合（还有很多其他技术支持选项），用以实现基于 SOA 的解决方案。
在快速发展的全球经济环境中，企业要保持竞争优势，必须保持足够的灵活性。通过使用 SOA 原则将 IT 基础结构与核心企业流程结合，可以提供和保持这个优势。因此，理解和采用 SOA 所面临的问题不是如何或为什么，而是什么时候？基于 SOA 的企业解决方案已被证实能简化业务操作、提高效率、降低成本及消除冗余。

我们正处在对解决方案生命周期的每个方面进行改革的浪尖上，而 SOA 则是关键的催化剂。不过，从长远来看，如果我们不谨慎的话，这个抽象和易用性可能会使 IT 架构师或开发人员和计算机科学与技术的根本基础脱离联系。
——Sanjay Bose

不过，为了获得这些好处，必须正确地应用 SOA。必须具有相应企业范围内的远景和转换路线图，必须有业务执行人员的财务支持和承诺，并由有经验的架构师以增量迭代的方式进行部署。这些增量步骤应该首先针对关键业务问题进行，最终的解决方案应该能提供业务价值。这样可以帮助保持和促进使用 SOA 进行端到端企业转换。在采用 SOA 的过程中，SOA 将不断遇到各种重大的挑战，其中包括政治和文化的多样性。
从纯技术角度而言，SOA 平台（包括工具和运行时）也在经历着巨大的转变。开发工具环境包含大量的建模工具、行业根深蒂固的场景、重用模式、方案和丰富的可视表示和控件以及模拟技术。运行时也同样在不断发展，从而提供增强的服务质量、声明性的和基于策略的管理和吸引人的管理和监视 Dashboard（针对 IT 事件和业务事件），并使用具有自我修复功能的自动工具进行检测。我们正处在对解决方案生命周期的每个方面进行改革的浪尖上，而 SOA 则是关键的催化剂。不过，从长远来看，如果我们不谨慎的话，这个抽象和易用性可能会使 IT 架构师或开发人员和计算机科学与技术的根本基础脱离联系。
[ 编者注：有关此主题的更多观点，可以参考 Sanjay Bose 最近与人合著的新书 SOA Compass:Business Value, Planning, and Enterprise Roadmap（此书是 IBM Press 和 Prentice-Hall 联合出版的 developerWorks 系列丛书之一）。

回页首

模型驱动的开发和虚拟企业
您可能已经选择使用 SOA 了。大部分中型和大型企业都在其应用程序设计中应用了 SOA 元素。结构良好的 CICS® 和 IMS™ 程序通常符合 SOA 的要求。很多公司已构建了由消息驱动的应用程序组成的分布式系统。会话 Enterprise JavaBean 就是“类 SOA 的”。很多 ISV 系统都采用类似于服务的构造；例如 SAP IDocs。SOA 将结构良好的分布式系统的指南系统化，是结构化编程、模型对象 (OO) 的概念的子集和消息驱动的处理的自然发展。

在很短的时间内，我们行业的运行时互操作性和开发工具间的互操作性就达到了前所未有的水平。这个互操作性降低了迁移到 SOA 的成本，从而更容易获得其带来的好处。
——Don Ferguson

Web 服务是一组用于构建 SOA 解决方案的标准。基础结构供应商 (IBM、BEA、Microsoft) 和应用程序供应商 (SAP、Oracle) 正像采用任何软件技术一样迅速地采用 Web 服务。在很短的时间内，我们行业的运行时互操作性 [简单对象访问协议（Simple Object Access Protocol，SOAP）、HTTP、WS-Security、WS-ReliableMessaging] 和开发工具间的互操作性 [Web 服务描述语言（Services Description Language，WSDL）、WS-Policy、Business Process Execution Language for Web Services (BPEL4WS) ] 就达到了前所未有的水平。这个互操作性降低了迁移到 SOA 的成本，从而更容易获得其带来的好处。
都有什么好处呢？此处将不详细讨论全部或任何单个好处。我将简要地提一下两个好处：
•    SOA 支持模型驱动的开发和从业务透视图进行解决方案监视。我们通过使用 WebSphere® Business Modeler 产生一个允许分析人员和业务专业人员进行推断和设计他们的业务流程的工具，从而有了很大进步。SOA 操作是流程中的任务或步骤的自然呈现，而组合服务的实现（BPEL4WS，业务状态机）则是流程的自然表示。根据简单业务规则（使用 WebSphere Process Server 启用），WS-Policy 和服务实现这两种方法都是业务策略的自然表示。
•    Web 服务支持“虚拟企业”。MQ 和 Common Object Request Broker Architecture (CORBA) 等以前的技术主要针对企业内计算进行了优化。Web 服务协议和 WSDL 在 Internet 和内部网络中均可工作。这样就能使用以前用于企业内部应用程集成的相同模型来在 Internet 上实现简单的、快速开发的机会型 B2B 了。

回页首

控制问题
SOA 与已在 IT 行业存在了 30 年甚至更长时间的其他软件模块化流程相似。SOA 所不同的硬件和网络已足够成熟，可以支持这项基于标准的技术。从任何方面而言，SOA 都不是过去行业内的风行的热潮技术，但包含了广泛的行业标准和支持。
SOA 为企业提供了一个机会，以标识其核心能力和决定是否将这些核心能力作为服务向其行业和业务合作伙伴提供。另一方面的事实是；企业可以对作为其核心基础结构（不是核心能力）一部分的流程和应用程序进行标识，然后确定进行购买。请注意，其中一些服务（提供的或购买的）可能仅为业务流程。企业架构师可以牵头开展相应的工作，以发现企业中具有公共功能集的业务流程和 IT 流程。可以将执行功能打包为外部依赖性很小的组件，并作为服务提供。这就使得业务流程创建者或应用程序开发人员的工作得到简化，以将精力放在能满足股东的业务动力的唯一功能上。

让 SOA 正常工作在很大程度上不是技术问题。让 SOA 正常工作是一个业务控制和 IT 控制问题。
——David K. Jackson

让 SOA 正常工作在很大程度上不是技术问题。让 SOA 正常工作是一个业务控制和 IT 控制问题。技术专家可以根据很多存在的成功模式构造一个 SOA 实现。然后让企业使用这些服务，而不再自己进行创建，这是另一个问题。恰当的体系结构控制将对其服务可供新应用程序使用的项目进行标识。要使得 SOA 投资最终能物有所值，唯一的办法就是让高级管理人员承诺控制预算，或采取某种方式保证业务线能不受干扰。IT 架构师还需要向执行股东报告业务从其 SOA 投资和投入方面获得的价值。
为了让 SOA 与业务合作伙伴协作，需要涉及企业已经建立的关系。现在，很少（如果有）客户在其建立的合同关系之外为合作伙伴提供或购买服务。服务级别协议和争议解决的相关事项要求配备封闭的协作系统。有关信任和安全的结构化信息系统发展组织（Organization for the Advancement of Structured Information Systems，OASIS）标准在过去两年中取得了长足的发展，但在等式的法律和业务一边，仍然更倾向于和企业已经了解的伙伴开展此类业务。

回页首

这里没有神话
关于为什么应该考虑 SOA 有三个简单的理由：
1. 这是目前最热门的领域之一；不要落后于时代的步伐。
2. 工具、基础结构和标准经过组合，可为整个 SOA 生命周期提供全面支持。了解我们的端到端编程模型。按照其中提供的详细步骤开展工作，亲身体验成功。
3. 如果您和我们一样不断地追求事半功倍，那么 SOA 可以为您提供帮助。寻找您可以再次利用的东西；不要所有东西都自己从头做起。寻找现有服务，对其进行调整，并加以使用。然后对其中一些服务进行共享。帮助创建一个生态系统，以便在将来能更快地装配更多有意义的解决方案。

可以通过常识来看这个问题。如果您的项目处于十分关键的位置，而您的团队必须投入大量精力学习工具和 API，SOA 就有可能是错误的选择。如果可以在小项目中试用 SOA，则是不错的选择。
——Christina Lau

开始采用 SOA 与采用任何其他技术或体系结构没有什么区别。可以通过常识来看这个问题。如果您的项目处于十分关键的位置，而您的团队必须投入大量精力学习工具和 API，它就有可能是错误的选择。如果可以在小项目中试用 SOA，则是不错的选择；利用这个经验，可以帮助您定义和扩展到下一个更大的项目。循序渐进，这里没有神话。

回页首

只是业务而已
SOA 的支持者不断不畏余力地宣传 SOA 的主要技术优势：松散绑定，能够通过组件封装可重用业务功能，最后（但没有像通常那样刻意强调）还能提供更好的集成。
包括我自己也是 SOA 的支持者之一，但我不断在问自己一个问题：客户真的对这种技术推论感兴趣吗？
在过去两年，我一直在与希望获得 SOA 产生的价值主张的客户全面合作。在与客户沟通时，我经常发现客户认为，有很多其他体系结构能提供比我所提到的更多的技术价值。有些客户可能一厢情愿地得出结论，认为非常有经验的架构师和开发团队可以通过使用传统企业应用程序集成 (EAI) 体系结构获得很大价值。很多客户会争辩说，这些方法经过验证，实现风险并没有直接采用 SOA 进行设计的风险大。

虽然我们不知道其解决方案到底是什么样的，但应当客观地看待每一个问题。请同时根据技术指标和业务指标来确定是否采用 SOA。
——Calvin Lawrence

这个观点可能会让架构师认识到在有些情况下，SOA 是错误的选择，或者，至少不是最好的选择。SOA 的技术可行性是否是选择其作为解决一系列业务问题的体系结构方法的原因？我会说不是：很多业务及 IT 相关的问题（例如缺乏有力的企业控制模型和策略）将减慢或阻碍任何构思良好的技术 SOA 活动的实现。
在最近一次为期三天的 SOA 研讨会上，一位汽车行业的首席技术官 (CTO) 告诉我下面的话：“我对 SOA 看法是‘只是业务而已’。”他告诉我他采用 SOA 的原因在于：
•    提高他和他的团队实现新产品和流程或更改现有项目的速度
•    降低实现和拥有成本
•    通过外包业务元素或从固定定价改为可变定价（根据业务量），从而支持灵活的定价模型
•    简化合并和收购所需的集成工作
•    实现更好的 IT 使用率和投资回报
这位 CTO 和他的团队仅关心如何使用其现有的技能（而不必放弃其现有的基础结构）在预算内按时达成这些目标。他们已经在其现有 EAI 基础结构中进行了大量投资。
这位特别的 CTO 的话与很多其他人的说法都不一样。他们只关心关键之处：我如何为股东提供回报？
当然，作为一个有经验的架构师（微笑），我知道一些解决此问题的体系结构备选方案：
1.    扩展其现有的 EAI 基础结构
2.    计划采用更多的事件驱动体系结构（完全分离的、发布/订阅，等等）
3.    或许可采用 SOA
由于这是一个 SOA 研讨会，而客户为此付费，因此我最初准备选择第三个选项。实际上，对于这个情况，我使用了一点 EAI，一点事件驱动和很多 SOA 方面的东西。SOA 允许在必要时包含 EAI 和事件驱动方法。
对于高速发展的汽车行业，为了保持竞争优势和按时在预算内提供产品，企业必须具有灵活性。这个客户的难点集中在对其业务流程进行管理和合并。正如我的同事在此讨论中指出的，将 IT 基础结构与核心业务流程结合，对于达成目标十分关键。SOA 相关的原则已被证明可以简化业务操作，能减少与实际代码关系很小而集中在人机交互和人员活动上的冗余项。在资金有限的业务环境中，几乎没有客户能为解决特定的业务问题无限制地投入资金，而有时间并愿意对其控制流程进行修整的客户则更少了。这样做听起来不错，但却不会实际这样做。
关键在于对现有基础结构、流程和现有控制模型加以利用和扩展。通过恰当地使用现有 SOA 原则，可以对整个设计和实现流程进行管理，如：
1.    标识问题。
2.    标识组成业务并是难点所在的流程。
3.    对这些流程进行建模，以对其进行简化。
4.    标识现有服务，并编写表示这些流程的其他服务。
5.    将这些服务部署到可提供运行时功能且操作效率高的环境中。
6.    监视这些服务和流程，以获得更高的效率。
那么，网络呢？虽然我们不知道其解决方案到底是什么样的，但应当客观地看待每一个问题。请同时根据技术指标和业务指标来确定是否采用 SOA。如果合适，就使用它。如果不合适，就不用它。SOA 概念和原则将始终可以通过某种方式应用到您的体系结构中。

回页首

康庄大道
我们现在都应该知道了整个行业对 SOA 的 ROI 和采用的赞颂之词——松散耦合、重用更好、推向市场的时间更短、易于集成以及互操作性更好。不过，务必了解，我们目前对 SOA 的关注只是实现即插即用企业（或者说是按需企业）的历程中重要的一步而已。
随着我们进入下一个十年，我们将开始着手大幅度减少将来自不同 IT 供应商的产品或组件组合成可行的有价值的端到端解决方案所需的工作量。供应商提供的业务组件将不依赖于基础结构，可以在各种平台上执行。因此，软件开发人员会将更多的精力放在有效集成供应商组件和确保有效的互操作性上。

IT 业务操作部门所属的人员将是业务和企业体系结构专业人士。无论您是如何定义业务或企业架构师的：为了实现这个远景，整个行业将需要更多的具有 IT 和企业体系结构背景的人士。
——Andras Szakal

客户的 IT 操作部门将主要负责选择最适合业务需求的运行时平台；即提供恰当部署和管理业务组件所需的必要服务质量和运行时支持的平台。
相反，IT 业务操作部门将主要关注如何通过定义业务组件（将由其对应的操作人员部署和管理）中包含业务规则实现组织的业务策略。这将通过 WebSphere Business Process Server 之类的业务流程管理系统完成。
IT 业务操作部门所属的人员将是业务和企业体系结构专业人士。无论您是如何定义业务或企业架构师的：为了实现这个远景，整个行业将需要更多的具有 IT 和企业体系结构背景的人士。
虽然这个远景可能十分诱人，仍然存在很大的风险，在进入组件天堂之前，我们必须小心地减小这些风险。在开始进行实现模型服务的体系结构的任务时，最重要的减小风险方法可能就是要求有强有力的管理良好的控制流程和策略。只有通过强有力的企业服务控制策略才能够避免更改管理问题、服务间的语义不匹配和系统功能结合方面出现的难于调试的问题。IT 部门可以通过制定的控制策略来减少风险，这些控制策略由执行监督团队（其中包括 CIO、CTO 和业务线执行官）提出并加以支持。

回页首

改善信息
当然，您已经对 SOA 有所了解了。您也知道 Web 服务、业务流程的重要性、模型驱动的体系结构和所有这些让人诚惶诚恐的 WS-* 标准。
但或许您是一名信息人员。您需要负责组织的信息的完整性和对其进行分析。您关心表示业务状态的数据库的性能和稳定性。正如您所知的，真正重要的部分。因此，您可能会问：“为什么我应该关心 SOA？”

SOA 表示的不仅是服务提供者和使用者的协定，而且也是信息提供者和使用者间的协定
——Dan Wolfson

作为信息人员，我很关心 SOA。我之所以关心 SOA，是因为 SOA 具有直接和间接影响信息管理系统的能力——事实上可以影响信息本身。为了获得成功，我们需要在业务服务所涉及的信息的上下文中对其进行考虑。我们需要知道检索到的信息是准确的。被更新的信息经过了验证。交换的信息的意义对于服务提供者和使用者都是一样的。如果忽略了这些事情，服务的价值和可重用性就会减少。
直接来说，使用 SOA 时，我们需要在提供者和使用者之间形成一个信息协定，以便让各方知晓信息意义的内涵，并且仍然支持异构系统——换句话说，我们必须假定世界是杂乱无章的，必须对其进行整理，以提高信息的价值，了解不同的结构和意义之间的关系，并在可能的情况下就公共对象达成一致。
将信息作为服务公开还将让我们配备额外的信息服务器拓扑来容纳增加的信息负载。它还会要求我们建立可以对信息访问进行虚拟的点（这样用户就无需知道信息的真正位置以及其组织方式）。它还引入了一些方法，允许我们有效地对这些信息进行组合——通过集合或联合。如果没有建立更多的公共机制或引入经过改进的清除机制，则我们稍后很可能被迫投入巨额的额外资金和资源进行清除，从而导致将来的灵活性下降。
可以采用很多办法实现信息协定。其中一个变得越来越重要的就是主数据管理 (MDM) 领域。MDM 系统可为业务应用程序或服务提供经过清除、整合且特定于域的信息。最常见的 MDM 系统是作为客户和产品信息的信息集线器使用的系统。每个集线器都作为中心点使用，可以在此对信息进行添加、更新、审核、清除、搜索和查询。集线器放置于可以将更改传播到相关数据库或可以生产相关服务的事件的位置。MDM 系统可以是事务型的（在操作业务流程的主线中更新），也可以是引用型的（提供业务流程所引用的信息的一致来源）。但最重要的是，我们可以将 MDM 系统看作其本身提供了一个一致的服务集，以供在各种业务流程内使用和进行重用。
通过 MDM 等方法显式地实现信息提供者和使用者之间的协定，可以帮助我们实现 SOA 所承诺的灵活业务流程和服务可重用性，并同时为我们提供提高所管理信息的质量的机会。

回页首

适合与不适合的场合，以及需要注意的地方
SOA 是一种组织化的方法，用于应用到由面向服务和分布式对象计算组合而成的应用程序体系结构中。让我们来将这个定义分为几部分进行分析。应用程序体系结构是应用程序各部分的宽泛组织，通常作为层实现。体系结构指定包含哪些部分以及它们如何一起工作。面向服务将功能封装为服务——宽泛的可重用任务，可以在没有任何前一上下文（除承载服务的系统的当前域状态外）的情况下运行。服务的上下文是作为从调用方传递的参数提供的，和函数调用的参数非常相似。分布式对象以特定方式运行在独立进程中，通过这种方式，一个进程中的对象可以调用另一个进程中的对象上的方法。

服务支持对访问通过宽泛任务的经过良好定义的 API 公开的已良好封装的功能，从而可以通过低频率的调用实现功能的高重用性。SOA 或许是所有方法中最好的一个。
——Bobby Woolf

SOA 向分布式对象添加面向服务，从而可以在进程之间调用服务。它是一种用于设计应用程序体系结构的方法，以便应用程序的各个部分可以在不同的进程中运行，而且还允许不同的应用程序共享和重用正在运行的部分。它是分布式对象计算的演变，用以在多个对立方之间获得更好的平衡：需要访问彼此功能的应用程序；需要封装自己功能的应用程序；需要限制在其应用程序编程接口 (API) 中描述的对外公开的功能的应用程序；需要限制分布式调用的交互应用程序。服务支持访问通过各种任务定义良好的 API 公开的封装良好的功能，从而可以通过低频率的调用实现功能的高重用性。SOA 或许是所有方法中最好的一个。
以下给出了一些简单的技巧，用以确定何时采用 SOA 和何时不应采用 SOA 以及需要提高警惕的情况。
首先，适合采用 SOA 的情况：
•    当数据分布程度非常高时，使用 SOA。将操作数据的代码放置在与数据较近的位置，然后将其包装为服务，以供在任何地方进行访问。
•    希望功能具有高可用性时，使用 SOA。将功能作为服务部署在多个冗余的提供程序中，以在其中一些不可使用时，可以使用其他的对等服务。
•    当应用程序的各个部分需要独立开发、维护和更新时，使用 SOA。只要保持各个部分之间的接口，每个团队（如两个不同的 B2B 公司）就可以使用其喜爱的技术按照自己的计划实现各自的部分。
•    当多个应用程序需要重用功能和数据时，使用 SOA。共享的代码仅重用功能；服务则允许各个独立应用程序重用一组共享的企业数据，而无需将数据分发给所有应用程序。
以下是不适合使用 SOA 的情况：
•    当希望开发尽可能简单时，不要使用 SOA。使用一种语言实现，在单个线程中运行，且没有远程访问问题的应用程序复杂性较低一些，因此构建和调试更为方便。
•    当希望操作环境尽可能简单时，不要使用 SOA。要对松散耦合、事件驱动的分布式应用程序进行故障排除要困难得多，要求对应用程序实现细节和操作环境配置细节及其当前状态有全面的了解。
•    当网络不可靠或网速慢时，不要使用 SOA。服务组件运行于独立的计算机上，通过网络进行通信，因此，其速度和可靠性依赖于这些计算机及连接这些计算机的网络。
（注：分布式冗余服务可以帮助减少硬件不可靠和网络延迟的影响。）
•    进行原型设计时，不要使用 SOA。原型开发应该简单，而 SOA 并不简单。
对于何时需要提高警惕的问题，坦白地说，随时都要提高警惕才行。以下是一些需要谨慎行事的具体情况：
•    当服务接口不确定时，使用 SOA 需小心。服务接口允许使用者和提供者独立地进行更改，但接口本身必须稳定。SOA 中的接口变化比在单个应用程序（特别是非分布式应用程序）中复杂得多，因为有很多在其他情况下不相关的开发团队必须就接口的更改进行合作。
•    当安全性极为重要时，使用 SOA 需小心。每个服务都是一个新的易受攻击的点，必须保证其安全性。可以轻易访问服务的人越多（如在公共 Internet 上的服务），可以尝试攻击该服务的人就越多。
•    当性能极为重要时，使用 SOA 需小心。进程之间的每个服务调用都比进程内的方法慢得多。
•    希望功能具有高可用性时，使用 SOA 需小心。正如所指出的，冗余服务可以提高可靠性；但同时，活动部分越多出现故障的可能性就大。SOA 应用程序只与其服务一样可靠。

前两天在IBM网站上找的一些资料

yundazyx — 5/28/2006 5:53:00 AM

对于SOA，尤其是像开发人员和CIO等仍有若干关键问题需要回答。Web 服务以及越来越多的面向服务架构(Service Oriented Architecture，SOA)已经在市场上投放了大量广告。两者都可以给企业带来广泛的短期和长期利益。但对于SOA，尤其是像开发人员和CIO等仍有若干关键问题需要回答。
　　问:SOA的前提是能够使应用程序像服务那样工作。软件如何像服务一样工作呢?
　　答:没有SOA，软件包是被编写为独立的(self-contained)软件，即在一个完整的软件包中将许多应用程序功能整合在一起。实现整合应用程序功能的代码通常与功能本身的代码混合在一起。我们将这种方式称作软件设计"单一应用程序"。与此密切相关的是，更改一部分代码将对使用该代码的代码具有重大影响，这会造成系统的复杂性，并增加维护系统的成本。而且还使重新使用应用程序功能变得较困难，因为这些功能不是为了重新使用而打的包。
　　SOA旨在将单个应用程序功能彼此分开，以便这些功能可以单独用作单个的应用程序功能或"组件"。这些组件可以用于在企业内部创建各种其他的应用程序，或者如有需要，对外向合作伙伴公开，以便用于合作伙伴的应用程序。
　　"服务"的概念是要使用与实施细节无关的标准化接口来构建这些"组件"。针对一套应用程序服务的Web服务描述语言文档，描述需要作为请求特殊服务(例如，"检查库存"功能可能需要零件数)输入来传输的数据名称和类型，并描述服务响应的细节(它可能返回表示库存中零件数量的一个整数)。
　　这些详细信息看上去好像与 Java、C++、COBOL 等中实施的功能相同，因此，服务的请求程序无需知道使用的何种语言，而且可以使用任何语言来编写请求程序。这就使一个平台上的服务可以和为另一个平台编写的应用程序集成。互操作性的关键是请求和响应消息，例如，使用SOAP消息发送，其消息使用 XML 编写代码。
　　问:请举例说明 SOA 如何使企业受益。
　　答:关键的优势是互操作性，可以使用任何平台之间的功能，而与编程的语言、操作系统和计算机类型等等无关。在上述示例中，"检查库存"功能可能已经编写为一个应用程序要求的服务，例如，监控库存并在需要时自动重新定购的服务，但我们后来发现，同样的服务无需修改即可用于支持由员工使用的基于 Web 的库存监控工具。
　　就内部而言，应用程序的重复使用是一项关键优势，因为它可以降低开发成本。服务的重复使用，其长期作用在于减少企业中冗余的功能，简化基础架构，从而降低维护代码的成本。通过按服务的使用者来组织应用程序，与传统的编程技术相比，我们获得一个要灵活敏捷得多的集成模型，使我们可以迅速修改业务流程模型。
　　就外部而言，为服务交互而详细定义的"合同"使业务合作伙伴之间的交互"自由联合"，提供集成所必需的稳定性，并提供更改基层软件(underlying software)问题的一个解决方案。当保留了相同的消息格式时，支持该格式的软件只要仍然支持消息合同，则可以按需进行更改。只要它支持相同的消息格式，甚至可以使用另一种编程语言的实施来完全替换系统，请求程序无需更改。当消息合同不断发展而必须更改时，与相当困难的任务，即支持多个版本的程序 API 和文件格式相比，它使用版本控制(versioning)，更容易作为过渡策略支持多个版本的应用程序。
　　这些是部分关键益处，还有许多其他益处。
　　问:SOA与Web服务以及SOA和网格计算之间是何关系。
　　答:SOA是一种面向业务应用程序系统的体系架构设计风格，但可以应用于其他系统，包括中间件技术，例如网格计算。
　　Web服务是可以用于创建SOA的一套标准。尽管没有Web服务标准也可能创建SOA(例如，在SOAP之前，人们已经在HTTP或JMS上使用XML来实现相似的结果)，但运用Web服务标准却是我们目前针对与外部软件交互的最佳方法。
　　网格计算是一种系统管理策略，其目标是最大限度地减少硬件资源的使用。例如，当突然的需求溢出指定的服务器时，它可能临时将一些请求转向相对没那么繁忙的服务器。网格计算设计为一种面向服务架构(用于调整网格计算的服务叫做网格服务)。
　　随着我们转向SOA，我们将看到该方法用于支持各种其他新的系统功能。另外一个示例是自主计算伙子管理系统。事实上，SOA是Web服务高级功能的基础，例如WS-Trust和联合身份识别管理规范。
　　问:因为还没有通用互操作性标准，SOA最大的问题不仍然是供应商中心性(vendor-centricity)吗?
　　答:有一些基本标准正好适用于Web服务，它们可以用于实施面向服务架构。XML和XML方案分别自1998年和2001年就已成为标准。SOAP 1.2自2003年6月成为标准。UDDI在2003年夏天标准化。WS-Security在2004年4月成为标准。
　　除了著名标准机构(例如W3C和OASIS)支持的这些正式标准以外，许多"技术建议书规范"也被广泛接受，并作为事实标准得到充分支持。例如，直到 W3C完成WSDL 2.0为止，要求在其产品中支持Web服务的大多数供应商都支持WSDL 1.1规范。
　　事实上，目前大部分软件供应商对Web服务标准的支持，已导致使用Web服务来广泛实施SOA。

　　问:SOA如何影响SLA?而您如何让SLA适合您的SOA?
　　答:当前企业之间的SOA实施通常侧重于改善合作伙伴之间现有业务的效率。同样，性能保证的概念并不是像方便的互操作性和自由联合集成那样的问题，它们可以借助Web服务标准来实现。
　　当服务成为企业付费的产品时，对特定水平的性能或可用性的保证，以及其它服务质量注意事项具有更为重要的作用。我们可以想象这在将来会成为一个常见要求，正在进行这方面的工作以支持该模型。
　　问:我如何着手构建 SOA?
　　答:最佳的方法时开始构建较小的SOA，侧重于提高当前缺乏效率的交互性。例如，假设使用一个系统上需要重新键入到另一个系统的打印报告，将两个计算机系统紧密联系在一起，这会消耗时间、浪费成本，导致出错，而且数据无法保持罪行。可以设计一个简单的基于Web服务SOA项目，直接链接信息，将含更新的SOAP消息发送到合作伙伴系统，而不是打印报告。
　　开始简单的SOA使企业可以在作出大投资之前先衡量ROI，并在出现大的问题之前获得小改善的经验。
　　CIO在购买软件时应该询问供应商关于对Web服务和SOA的支持，作为一个重要的注意事项。应该检查新应用程序的开发，以便考虑是否某些应用程序功能可能需要用于其他目的，以及可以嵌入对Web服务标准的支持以支持重复使用。
　　最终要完成大规模的企业转型，可能需要通过建立企业服务总线(形成SOA的骨干网或神经系统)来开始该工作。然后以企业合理的节奏，将服务提供商何服务请求程序逐渐添加到ESB。随着IT的SOA的增长，ESB成为在服务水平上连接应用程序，并调节消息流量以提高效率和可靠性的一种有力方式。
　　问:管理SOA需要哪些新的服务管理技能?
　　答:在运用Web服务之前，因缺乏标准和自由联合的策略，合作伙伴整合受到严重限制。随着我们开始使用Web服务和SOA来整合合作伙伴，我们可以发现，使用业务合作伙伴所提供的功能的IT系统已经开始依赖于这些功能的可用性。我们从内部管理我们自己服务的可用性转向要求监视和管理(可能有许多)企业之间的可用性。这明显大大增加了管理IT系统的复杂性，但它也带来了巨大的价值，这就是为什么许多企业要转到这个方向的原因。
　　Web应用程序系统正在不断发展以支持Web服务标准。"Web服务分布式管理"或WSDM标准正在由OASIS开发，对Web服务管理提供标准化的支持，通过使用Web服务来实现对不同平台的管理，满足涉及独立业务实体的大规模SOA对分布式管理的要求。

大赛时间表

leobamb — 5/24/2006 9:09:00 PM

大赛时间从2006年4月6日到2006年11月14日截止。详细时间表如下：

      日期                                         主要工作和交付成果
2006年3月底                   大赛相关信息在网上发布并开始校园宣传
2006年4月6日                 大赛开幕式在清华召开，同时校园宣传和巡讲正式展开
2006年5月31日               校园宣传和巡讲结束，大赛报名截止
2006年6月30日               初赛截止日期，停止收取参赛队伍的方案
2006年7月15日               初赛审核和评选完成，评出参与复赛的20个队伍
2006年7月21日               复赛审核和评选完成，评出参与决赛的5至8个队伍
2006年7月28日               dwLive活动在北大举办，公布决赛队伍
2006年9月30日               决赛队伍最终作品交付
2006年11月10日             最终作品调试/决赛答辩/发布，优胜名单确定
2006年11月14日             在IBM SOA大会举行颁奖典礼

更详细内容请点击
http://www-900.ibm.com/cn/software/websp ... s/soacontest/index.shtml

大赛题目详细介绍

leobamb — 5/24/2006 8:57:00 PM

题目背景描述

凤凰医疗设备有限公司（以下简称"凤凰"，虚构的名字，便于讲解）是一家专门制造和营销专业医疗器械和实验仪器仪表等仪器的民营企业，其购销客户和网络遍布全国各地。凤凰成立于2000年，现有员工750名。公司领导一直非常重视企业信息化建设，投入大量的资金支持，并制定"把握趋势、兼顾现实、统一规划、逐步实施"的发展策略。

2004年凤凰公司引进并在公司内部成功实施了某ERP系统（部署在凤凰企业内部的Web应用），主要用于凤凰公司的财务管理，其中包括产品库存及订单管理等。ERP的实施大幅度地提高了公司的管理效率。

随着公司业务规模的扩大和产品质量的提升，凤凰公司的客户数量越来越大。凤凰公司有一批精干的销售队伍，他们经常出差和客户打交道。虽然销售人员都配备了笔记本电脑，使他们能够方便地和公司通过email发送和接受文档，但是竞争的压力使得凤凰公司不得不考虑使用客户关系管理系统（CRM）来进一步提高销售人员的工作效率。于是，2005年8月份凤凰公司引进并成功应用了某在线客户关系管理系统（On Demand CRM）。CRM通过订阅的方式来提供客户关系管理服务，凤凰公司不需要提供任何硬件、软件和空间资源，而只需要每月向服务供应商支付65美元。凤凰的销售人员在任何时间和地点只需要通过普通的Web浏览器就可以使用和管理客户及销售信息，包括客户信息，商机，业务机会，以及客户及销售信息分析图表等。

现在凤凰公司的财务和销售人员分别在ERP和CRM系统上工作，工作效率有很大提高。但是公司目前也面临挑战。一方面，ERP和CRM中分别维护产品和客户信息，而公司规定ERP必须作为这些信息的主数据源，ERP中的这些信息需要随时同步到CRM中去；另一方面，CRM中维护的业务机会和ERP中维护的销售订单有着非常紧密的关系，凤凰公司希望能够把业务机会和销售订单有效地整合起来，而进一步提高业务运作的效率。

凤凰公司通过招标的方式与一家信息技术咨询公司（万合信息技术有限公司，以下简称"万合"）签署这个项目。下面是万合公司了解到的凤凰公司的相关业务需求。

业务机会与销售订单整合的相关业务描述

凤凰公司的销售人员通过CRM管理业务机会（Opportunity）。每当一个商机（Lead）或者其他来源导致产生一个新的业务机会时，销售人员就会在CRM中创建新的业务机会。假如新业务机会对应的帐户不存在，销售人员首先在CRM中增加新的客户帐户（以及此帐户对应的联系人）再创建此业务机会。销售人员会根据和客户的商谈状况随时更改业务机会的状态。

要判断业务机会的可能性，销售人员需要了解当前最新的产品目录以及相关产品的库存和价格信息。这些信息随时从ERP更新到CRM供销售人员使用。销售人员会基于和客户的谈判，在业务机会中指定并随时修改此业务机会对应的产品列表，包括每个产品的名称、代码、价格、以及相应的数目。

当销售人员将业务机会的状态改为"赢"（Closed-Won），即表示此业务机会已经成功。此时，销售人员需要通知财务人员（工作在ERP上）来创建销售订单。销售人员只需要在CRM相应的业务机会中点击"生成销售订单（Place Order）"链接即可提交创建销售订单的请求。

虽然销售人员事先已经查看了产品库存情况，但某些突发事件可能导致创建销售订单时库存不足。只有当订单中的产品库存满足要求时，创建销售订单的请求才能被发送给财务人员处理。如果不满足要求，则订单被冻结。销售人员被通知不能提交订单。当产品库存满足要求时，系统会发短信通知销售人员重新提交订单。

创建销售订单的请求被发给财务人员等待处理。财务人员会收到一个手机短信告知他有一个销售订单需要处理；同时，为了保证订单请求能够及时处理（例如没有收到短信），财务人员的日程表中被自动添加一项新的事务，要求他处理这个销售订单。财务人员的日程表是集成在ERP上的一个小巧的日历应用，每个财务人员都可以创建和跟踪每天的工作（To-Do List）。

财务人员在收到短信或者看到日历上的工作项后及时地登陆ERP系统，财务人员会仔细地审查这个订单，并可能会修正某些数据项（如价格、数目等）。检查完毕，财务人员会点击"确认"来创建订单。

如果财务人员认为这个订单不合理，他可以写下退回理由并点击"退回"按钮来拒绝这个订单请求。销售人员会收到一个手机短信获悉他的销售订单请求是否被通过，如果被拒绝他会被告知拒绝的理由。

如果财务人员通过了订单处理请求，ERP系统会创建一个新的销售订单。但是在此之前，ERP可能会发现这个订单的客户在ERP中不存在（新客户），此时ERP会和财务人员核实。财务人员核实后（可能会有客户信息修正），ERP会在系统中创建此新的客户及其联系人记录信息。财务人员核实的一项重要信息就是客户联系人的Email地址。财务人员通过点击"验证Email地址"按钮来确认这个联系人的Email地知是否存在。如何不存在，则财务人员需要修正后才能核实通过。

如果成功地创建了销售订单，ERP里的客户信息、订单信息（例如订单号）都及时地更新到CRM中。从业务机会生成销售订单的业务流程结束。

万合公司的目标就是帮助凤凰公司实现这个业务流程。

扩展的业务需求

1) 可视化的信息聚合需求

因为CRM和ERP系统中维护有大量的企业数据，而且这两个系统之间有着非常密切的联系。凤凰公司希望在本次业务整合中能够同时提供可视化的信息聚合方式，以方便销售人员或财务人员浏览和使用企业数据。关于如何可视化，聚合哪些数据，都要看万合公司的创新了。凤凰公司期望更有创意的可视化信息聚合。

2) 使用信息智能服务

英特网上有一个信息智能服务社区（Information Intelligence Service Community，简称IISC，虚构的名字，便于讲解）越来越收到业界的关注。IISC作为信息处理服务的集中营，本质上是一个信息处理服务的创建和运营平台。任何一个注册的机构都可以把自己的信息处理服务发布到这个平台上（必须遵守平台规定的发布标准），经社区委员会评审通过后可以由这个平台来管理和运行所发布的服务。任何第三方如果要使用此项服务，需要向服务提供方交纳一定的服务费（通常为订阅的方式），社区委员会从中按比例收取佣金。注册的机构也可以使用平台上已有的信息处理服务来创建自己的增值服务，包括将已有的服务组合成新的特色服务，新的服务也可以发布到平台上去。

目前，IISC提供了一些基本的信息处理服务，例如中文智能检索、文本自动分类、文章相似检索、摘要自动生成、命名实体自动识别、网页文本抽取等服务。凤凰公司对IISC提供的服务及其运营模式非常感兴趣，希望万合公司能够在其ERP和CRM的整合业务中使用IISC的服务。例如销售人员或财务人员可以通过上面提供的信息智能服务浏览某个客户在Internet上的摘要信息。但是凤凰公司希望万合公司能够帮助他们最大化地、最有效地使用信息智能服务社区上的服务。

大赛题目说明

题目中描述的是凤凰公司要求万合公司最后能够帮助他们实现的业务目标，并不是凤凰公司当前的业务情况。
题目中描述的仅仅是凤凰公司业务整合的基本需求，本次大赛鼓励参赛团队依据凤凰公司信息化发展策略，发挥自己的创造力，为凤凰公司制定切实可行的发展计划，并根据自己的实施能力在大赛中实现发展计划的一个或者多个阶段。
SOA强调业务需求与IT的一致性。题目中对企业策略和业务方面的描述并不充分，参赛团队可以从业务的层面扩展基本需求，并使得扩展后的业务需求和题目中的需求（或者参赛团队修正后的需求）从SOA的角度相一致。
题目中描述的ERP很可能需要集成万合自己开发的服务组件，例如日历组件（但不限于此，依需求而定）。
虽然SOA可能并不是解决本大赛题目的最佳途径，但从本次大赛的目的出发，SOA的理解和应用程度将是本次大赛评判的重要标准之一。
题目中的IISC是一个虚拟的服务社区。设计参赛队伍可以最大限度地发挥创造力，将IISC的服务融入到凤凰公司的业务整合中。
更详细内容请点击:
http://www-900.ibm.com/cn/software/websp ... soacontest/subject.shtml

summer

summer — 5/24/2006 10:48:00 AM

很高兴参加了SOA大赛，本着积极参与，认识ＩＴ最新的动态，学习新的知识，体验团队开发的心态，参加本次大赛．琢磨了半天，选了summer这个ID,热情如火，激情四溢更能体现我的性格．只要我决定做的事情，我就会尽自己最大的努力去把事情做好，用我的真诚去打动人，用我的激情去解决问题．

关于站点

leobamb — 5/24/2006 6:06:00 AM

今天天气不错,挺风和日丽的.
一如我们的心情,
因为我们团队的BLOG终于建立起来了,
正因为有了SOA大赛,才有了我们的团队,才有了这个BLOG
希望我们的BLOG越来越红火,
也希望所有的伙伴在这次大赛的旅程中得到自己想得到的东西,
努力吧,年轻的朋友们!!!!!
旅途愉快,合作愉快

soa学习的一些网站

summer — 5/17/2006 6:08:00 PM

拨开SOA的面纱

leobamb — 5/13/2006 10:04:00 AM

拨开SOA的面纱

内容简介

SOA是英文Service-Oriented Architecture，即面向服务架构的缩写。这个词汇最近一两年频频出现在各种技术期刊上。但是一直以来对于SOA到底是什么没有明确的回答；SOA有什么特点？适合用于解决哪些问题？与其他的技术有什么区别与联系？Web Service和SOA又是什么关系？SOA的出现对于软件架构设计有什么影响？本文将就上面提到的这些问题，尝试根据作者自己的理解给出SOA的定义；总结出SOA特有的三个基本特征；然后以HTTP协议为例对这些特征进行解释；最后简要的说明SOA对今后软件架构设计可能带来的影响。

SOA定义

下面是作者给SOA下的一个定义：SOA是指为了解决在Internet环境下业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。从这个定义中我希望表达的前提有下面两点：

1) 软件系统架构：SOA不是一种语言，也不是一种具体的技术而是一种软件系统架构，它尝试给出在特定环境下推荐采用的一种架构，从这个角度上来说，它更像一种模式(Pattern)。因此它与很多已有的软件技术比如面向对象技术，是互补的而非互斥的。它们分别面向不同的应用场景，用来满足不同的特定需求。

2) SOA的使用范围：需求决定同时也限制功能。SOA并不是包治百病的万灵丹，它最主要的应用场合在于解决在Internet环境下的不同商业应用之间的业务集成问题。在下面我们会详细讨论Internet的各种特点如何决定SOA的特点，这里我们只需要先简单回顾一下Internet环境区别于Intranet环境的几个特点：

a) 大量异构系统并存，计算机硬件工作方式不同，操作系统不同、编程语言也不同；

b) 大量、频繁的数据传输仍然速度缓慢并且不稳定；

c) 版本升级无法完成，我们根本就无法知道互联网上有哪些机器直接或者间接的使用某个服务。

基于上面的前提，下面就让我们一起看一下SOA的基本特征。

SOA三大基本特征

1 独立的功能实体

在Internet这样松散的使用环境中，任何访问请求都有可能出错，因此任何企图通过Internet进行控制的结构都会面临严重的稳定性问题。SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术，如.NET Remoting，EJB，COM或者CORBA，都需要有一个宿主(Host或者Server)来存放和管理这些功能实体；当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问题的时候，在该宿主上运行的其它应用服务就会受到影响。

SOA架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术，比如事务处理(Transaction)，消息队列(Message Queue)，冗余部署(Redundant Deployment)和集群系统(Cluster)在SOA中都起到至关重要的作用。

2 大数据量低频率访问

对于.NET Remoting，EJB或者XML-RPC这些传统的分布式计算模型而言，他们的服务提供都是通过函数调用的方式进行的，一个功能的完成往往需要通过客户端和服务器来回很多次函数调用才能完成。在Intranet的环境下，这些调用给系统的响应速度和稳定性带来的影响都可以忽略不计，但是在Internet环境下这些因素往往是决定整个系统是否能正常工作的一个关键决定因素。因此SOA系统推荐采用大数据量的方式一次性进行信息交换。

3 基于文本的消息传递

由于Internet中大量异构系统的存在决定了SOA系统必须采用基于文本而非二进制的消息传递方式。在COM、CORBA这些传统的组件模型中，从服务器端传往客户端的是一个二进制编码的对象，在客户端通过调用这个对象的方法来完成某些功能；但是在Internet环境下，不同语言，不同平台对数据、甚至是一些基本数据类型定义不同，给不同的服务之间传递对象带来的很大困难。由于基于文本的消息本身是不包含任何处理逻辑和数据类型的，因此服务间只传递文本，对数据的处理依赖于接收端的方式可以帮忙绕过兼容性这个的大泥坑。

此外，对于一个服务来说，Internet与局域网最大的一个区别就是在Internet上的版本管理极其困难，传统软件采用的升级方式在这种松散的分布式环境中几乎无法进行。采用基于文本的消息传递方式，数据处理端可以只选择性的处理自己理解的那部分数据，而忽略其它的数据，从而得到的非常理想的兼容性。

HTTP协议：一个典型的SOA实现

每一项新技术都是在一些旧的技术基础上发展出来的。正如XML根本思想来自于在60年代就已经出现的早期标记性语言一样，SOA虽然这两年才出现，但是它所表达的观念应该说在网络这种分布式系统结构出现不久就已经广泛应用了。例如我们最熟悉的HTTP协议就是一个非常典型的SOA架构设计。HTTP协议的工作过程简单叙述如下：

1) 客户端，通常是通过浏览器，向服务器端以文本的方式发送一个请求，索取一个Web页面；

2) 服务器端接收到这个请求之后，根据请求的内容进行处理并且返回一个符合HTML语法的文本；

3) 客户端接收到服务器端的响应文本后调用本地的程序，通常还是浏览器，把返回的HTML文本的内容展现出来。

下面来看一下HTTP协议如何满足了SOA的特点：

* 独立的功能实体：作为服务器端的Web服务器是绝对不会因为客户端的状况变化而改变的，它总是非常稳定地按照自己的内在逻辑运行，响应外部的请求，管理自己的资源和数据。这里一个非常好的例子就是Web服务器对缓存(Cache)的处理，很多Web服务器为了提高性能都或多或少的对数据进行缓存，但是缓存数据、刷新数据这些于客户端完全无关的操作完全由服务器端独立完成，完全不受客户端的影响。

* 大数据量低频率访问：对于一个HTTP请求来说，客户端与服务器之间访问的边界非常简单：就是一个请求，一个响应，没有任何其它的信息往返。无论客户端申请的网页上除了文字之外还有什么信息，对于客户端来说，它发出的请求只是简单的告诉Web服务器它所需要的网页的位置；至于为了生成这个网页，服务器端是否需要访问数据库，执行Servlet或者其它的CGI程序对客户端而言，都是完全透明的。

* 基于文本的消息传递：迄今为止兼容性最好的系统可能就是HTTP协议支撑的大部分的web应用了，我们可以在Windows平台下用IE查看互联网上一个Linux＋Apache服务器上的由Perl脚本自动生成的网页。这里的关键就是所有内容都是以格式化的文本方式传递的，不管Perl脚本如何执行，只要它的输出是符合HTML规范的网页，就可以被客户端的浏览器解释。而由于不同的操作系统上对于相同的HTML的解释遵循相同的规范，因此不同操作系统下仍然能够看到一致的用户界面。

我们上面基本描述了SOA作为一种软件架构有哪些特点，下面让我们一起看看Web Service与SOA的关系。

SOA与Web Service

Web Service是就现在而言最适合实现SOA的一些技术的集合，事实上最近SOA的火爆在很大程度上归功于Web Service标准的成熟和应用的普及为广泛的实现SOA架构提供了基础。下面让我们看看Web Service中的各种协议是如何互相工作来满足SOA所需的特点的：

* 独立的功能实体：通过UDDI的目录查找，我们可以动态改变一个服务的提供方而无需影响客户端的应用程序配置。所有的访问都通过SOAP访问进行，只要WSDL接口封装良好，外界客户端是根本没有办法直接访问服务器端的数据的。

* 大数据量低频率访问：通过使用WSDL和基于文本(Literal)的SOAP请求，我们可以实现能一次性接收大量数据的接口。这里需要着重指出的是SOAP请求分文本方式和远程调用(RPC)两种方式，正如上文已经提到的，采用远程调用方式的SOAP请求并不符合这点要求。但是令人遗憾的是现有的大多数SOAP请求采用的仍然是远程调用(RPC)方式，在某些平台上，例如IBM WebSphere的早期版本，甚至没有提供文本方式的SOAP支持。

* 基于文本的消息传递：Web Service所有的通讯是通过SOAP进行的，而SOAP是基于XML的，不同版本之间可以使用不同的DTD或者XML Schema加以辨别和区分。因此只需要我们为不同的版本提供不同的处理就可以轻松实现版本控制的目标。

SOA对于软件架构设计的影响

无论您现在的系统是否牵涉到基于Internet的业务集成，采用SOA推荐的架构都对提高您系统的扩展性有很大帮助，下面是在系统中引入SOA后需要在软件架构方面做出的改变：

* 使用基于文本方式的SOAP调用，摆脱远程调用中出现的函数参数类型等与数据无关的信息，保证所有SOAP传递的都是有意义的商业数据。依赖于Schema，而不是类定义对这些数据进行解释。

* 传统的三层Web应用将可能变成四层结构：传统意义上的商业逻辑层将被进一步划分为存放每个会话(Session)信息的客户逻辑层和与状态无关Sateless的SOA层。