发一些关于SOA的帖子,供大家学习

Kenniu

[B]尝试用SOA去思维 [/B]
项目架构师刚刚把新的面向服务的架构（SOA）交给您（企业开发人员），以供系统实现业务实践。现在，您只需构建系统即可。SOA方法在设计和组织业务功能以及IT基础架构方面极佳。SOA模型有助于确保系统的灵活性、可重用性和互操作性，使现在和将来进行管理和修改更容易。它也能节约成本。它只是可能不像光芒四射的新SOA一样容易实现。

考虑一个类似的例子——建造一所房子。设计者可能非常优秀，但是那并不意味着他们设计的房子是可以信赖的。担任建筑师的一位朋友讲述了他的第一项任务的故事：落实一个公司的新办公室计划，它占用了一座巨大办公楼的整个一层。新的入口处看起来富丽堂皇——直到我的朋友意识到前任建筑师忽略了一根承重柱子，这根承重柱子直接矗立在地板中央。现在他有三个选择：切段柱子，大楼也就破坏了；逐渐习惯于有一根柱子立在地板中央破坏美观；或者更改计划以反映现实。

开始之前

设计一个系统的架构也与此相同。如果在别人将SOA交给您的时候您才第一次了解SOA，那么您可能从一开始就遇到了麻烦。开发人员必须从业务流程的开端就参与业务流程的设计。对于保证真实性是SOA的一部分，开发人员的看法是非常宝贵的。这个看法来自技术、将来的发展以及特别的考虑等通用领域。

例如，在技术方面，开发人员与架构师的看法可能会不同。当然，在我们的房子上面搭上凉棚很好，但是我们将怎样拉回屋顶呢？与此类似，写下过程A将与过程B进行通信是容易的。但是，实际上，要使过程A与过程B通信良好可能需要能够获奖的——而且费用最大的——编程技巧。

灵活性也是SOA的目标之一，但是它可能会走得太远。认为家庭办公室有一天会被用作卧室——但是或许不是用作厨房——可能是聪明的想法。同样，比如说，要求某种服务来处理所有的输入可能没有意义。调整SOA，反映出什么是难以做到的以及什么是很可能做到的，就能够确保得到一种较好的结果。

开发人员不只是在规划过程中令人扫兴的人。他们往往了解不久后将成为可能并且会在SOA里出现的技术。在建造一所房子时，您可以预期某一天完成地下室，并且包括简单的基础结构。同样，一家公司现在可能不提供无线服务，但是开发人员可以将它作为未来的可能性，这很可能带来全新的业务面貌——以及SOA的重要部分。另外，开发人员可能知道SOA必须处理的特殊问题。例如，采用在Web上分布的组件服务模型时，通信的安全性可能比现有的内部应用需要更多的关注。

最后，在设计期间的信息流不应该仅仅是单向的。开发人员应该从架构师那里获悉业务的结构——以及未来的方向。在以后的开发过程里，了解并且保持这个观点对于指导决策将是至关重要的。

为开始做好准备

在开始开发过程之前，您需要从SOA的角度考虑技能、标准和工具等的特殊方面。这一部分是一种新SOA思维倾向。例如，既然整个服务思想是创造多个可重用组件，开发人员就必须超越一个应用程序的界限进行思考。您必须开始重用现有的服务，并且想像您的同事如何重用您的服务。打破旧的习惯，并且通过将服务链接在一起而不是通过编写新代码来构建应用程序，这可能是困难的。正确的态度将走向成功。

开发人员应该拥有面向服务的开发的正确技能。在业务流程、数据和元数据管理、消息传递和事务，以及安全性等方面，可能需要一些训练。因为这应该是一个迅速的过程，在必要时，您希望人们已经为开始做好了准备。

将您的开发过程流线化。从一开始就使应用程序的生命周期标准化——包括交付阶段——能够缓解以后的麻烦。早早建立您的标准。这些标准可能是结构化信息标准促进组织（OASIS）的接口标准（比如WSDL）、协议标准（比如SOAP）、传输标准（例如HTTP和JMS），等等。要注意这些标准可能在现有的基础设施和环境中遇到问题。

您可能需要面向Web服务的工具和一个SOA。不仅要考虑开发的特征，而且要考虑在企业内与其他成员通信的特征。如果您的可视化界面能够将您的工作表达为非技术类型，那么您就可以节省很多工作量。您的工具应该能够处理细节，例如元数据库、XML索引和规则引擎。

烦恼的时刻

即使有了正确的培训、态度、标准和工具，SOA开发也可能是困难的，这不足为奇。大多数业务流程基于实际的程序，这些程序复杂并且要求多个异步步骤。例如，一个简单的采购订单，可能涉及几天的复杂工作流，并且要求几个负责人签署意见。您将面对无意义的副本，乱七八糟的数据，以及缺少集成。虽然您一次只能开发一种服务，但是您必须专注于整个系统：保持灵活性是困难的。即使您从实现一些高使用率的服务开始，您也必须知道它们将如何与其他服务交互。您一层一层地进行开发——核心应用程序基础、公用服务层以及定制门户层——但是您必须知道所作的更改是否真的没有干扰其他层。

牢牢记住SOA的目标是重要的：灵活性、可重用性和互操作性。的确，对于给定的服务，有时看起来您只能挑选其中两个，或者可能只能挑选其中一个。但是那些是目标。事实上，有时精练而灵活的组件的想法好像自相矛盾。如果它是精练的，它又怎能灵活地完成全部的工作？如果它足够灵活，能够处理所有事务，难道它会不复杂吗？难道它会是精练的吗？是的，要达到那个美妙的结合点，需要一些折衷。服务必须可供多个应用程序使用，因此，必须正确地开发。此外，我们需要维护并增强服务，因此，它们必须简单。

这是不是听起来全部不可能？不是的。它只需要一个更大的视角。考虑一下房子的例子。您能仅仅挂起那扇门而完全不考虑到其他任何事情吗？不，因为如果门不在这个位置，这里将开一扇窗。如果门在这里，它会影响墙里的布线。如果门在那里，它就影响了另一扇门的设置。您将找到合适的位置，但不是仅仅专注于那扇门：您必须查看它周围的一切。利用SOA进行开发的情况也是一样的。

为目前的需求进行开发是艰难的；为将来的需求进行开发则是一项更大的挑战。除了观察其他所有组件以外，您还需要留心观察将来的可能性。如果您的服务是考虑到将来的需求而创建的，那么它们就可能用于将来的应用程序。这里有一个技巧：如果服务完全与当今业务实践相匹配，那么它可能不支持对业务实践的更改。如果服务接收特定的输入，就使输入通用化。如果该服务处理五个进程，那就让它处理十个进程。如果它将结果传输给另一个服务，那么使另一个服务是可以选择的。您需要的不是一套扳钳，而是一把月牙扳钳。

将来会出问题吗？试着想像从现在起三年后，您正在将这种服务转换到一个新职能。您希望它如何简化您的工作？请记住，该代码直接将转换重用于为企业提高劳动生产率和节约成本，并且为您节省了开发时间。

节拍在继续

尽管最初几个服务不是流程的结束，但是它在不断进行的过程中是一个有价值的里程碑。在执行了这些最初的组件之后，您应该能够判断它们是否达到了您的目标。其他服务能否容易地使用这些服务？如果能的话，那很好。如果地板不是水平的，那么现在就弄平，然后在上面进行建造。

在这个过程中，开发人员在某处发现意外的困难不足为奇。例如，因为种种原因，事实可能证明两个业务流程终究不能使用同一个组件。在开发过程中，您应该有一种适当的机制，与架构师交流需要进行哪些更改。SOA不是青铜铸成的：它是某台机器上的一些小东西，正如您所使用的其他一切事务一样。从假定更改是必不可少的开始，构建您需要加入任何所需更改的触点。

您如何发出某些任务不能执行的调用？在不可能与“我们不能完成”之间有很大的差别。如果您陷入了这样的困境，不要不战而降。首先，进行一些研究。在讨论区中询问如何处理这样的情况。如果有人已经解决了您需要执行的任务，那就表明您可能能够完成它。即使他们的情况只是有点类似于您的情况，您也可以在这个有价值的问题上获得一个看问题的角度。

如果那样不能产生一个答案，那就回去找架构师协商。向架构师解释困难。SOA可能需要修改。但是也可能是架构师们对此有设想，而您没有。请记住他们是解决方案的一部分：如果他们有解决方案，那就使用它。

因为这是一个企业开发项目，因此，让企业知道情况将如何发展是很重要的。您应该经常报告成果。解释已完成的每个服务的意义，展示它在整个开发中所处的位置。当整个应用程序完成时，证明它们的商业价值。您应该使用一种方法来衡量投资收益：让每个人都了解它。

这不仅对于企业来说是重要的，而且对于开发人员来说也是重要的。所有为脑海中的大图——以及未来——所作的特殊的编码工作都将获得补偿。并且企业会承认这种工作的价值。现在该是举行庆功宴的时候了。

SOA的未来

在2002年，Gartner Group称SOA为“现代应用程序开发过程中惟一非常重要的主题”。执行SOA方法能够帮助您更迅速地完成项目，并且更快地兑现投资收益率。不过，它仍是一种新方法，并非每个人都是这方面的专家。随着时间的流逝，您和您的同事将能更熟练地实现面向服务的架构。您可以利用更多、更好的工具。那时将出现改进的策略，并且成为标准问题的标准解决方案。在正确的计划和观点指导下，您精心打造的服务将能够在许多年内不断运作、发展和改善。

Kenniu

我仍就继续关注此项技术的发展;我也会试图找到一些更通俗易懂的文章给大家,也反馈自己学习使用的情况;
         继续,快速地学习,这是"挨踢"毕经之路,愿意和大家分享

softbaddog

非常感谢提供这样详细的资料，如果能够有具体技术上的案例，会更好！

Kenniu

面向服务架构（SOA）的原则

[2003/3/20]

Web service已经不再是新婚的娘子。众多企业都已经创建各种实验性Web Services 项目，事实证明，这项新兴的分布式计算技术确实能够降低集成和开发的成本。另外，一些关键的Web Services标准纷纷制定，强安全（robust security）和管理方面的产品也陆续问世。对于志向远大的企业来说，他们已经在考虑下一步了。

对大多数公司来说，下一步要考虑的不再是点对点的应用，而是Web services在企业间以及业务伙伴间更为宽广的应用。这种技术的变迁需要更松散耦合、面向基于标准的服务的架构。这样一个架构要求对IT在组织中的角色有新的观点和认识，而不仅仅是一种实现方法。通过对业务的敏捷反应，企业可以得到实实在在的回报，而要达到这一点，面向服务架构设计师的角色非常关键。除此之外，潜在的回报更是不可胜数－分布计算技术能够保证对业务需求足够灵活的反应，而这种业务上的敏捷正是各公司梦寐以求而目前还遥不可及的。

分布式计算将网络上分布的软件资源看作是各种服务。面向服务架构是一种不错的解决方案。但这种架构不是什么新思想；CORBA和DCOM就很类似，但是，这些过去的面向服务架构都受到一些难题的困扰：首先，它们是紧密耦合的，这就意味着如分布计算连接的两端都必须遵循同样API的约束。打比方说，如果一个COM对象的代码有了更改，那么访问该对象的代码也必须作出相应更改。其二，这些面向服务架构受到厂商的约束。Microsoft控制DCOM自不必说，CORBA也只是一个伪装的标准化努力，事实上，实现一个CORBA架构，经常都是在某个厂商对规范的实现上进行工作。

Web services是在改进DCOM和CORBA缺点上的努力。今天应用Web services的面向服务架构与过去不同的特点就在于它们是基于标准以及松散耦合的。广泛接受的标准（如XML和SOAP）提供了在各不同厂商解决方案之间的交互性。而松散耦合将分布计算中的参与者隔离开来，交互两边某一方的改动并不会影响到另一方。这两者的结合意味着公司可以实现某些Web services而不用对使用这些Web services的客户端的知识有任何了解。我们将这种基于标准的、松散耦合的面向服务的架构简称为SOA。

SOA的强大和灵活性将给企业带来巨大的好处。如果某组织将其IT架构抽象出来，将其功能以粗粒度的服务形式表示出来，每种服务都清晰地表示其业务价值，那么，这些服务的顾客（可能在公司内部，也可能是公司的某个业务伙伴）就可以得到这些服务，而不必考虑其后台实现的具体技术。更进一步，如果顾客能够发现并绑定可用的服务，那么在这些服务背后的IT系统能够提供更大的灵活性。
但是，要得到种强大和灵活性，需要有一种实现架构的新方法，这是一项艰巨的任务。企业架构设计师必须要变成“面向服务的架构设计师”，不仅要理解SOA，还要理解SOA的实践。在架构实践和最后得到的架构结果之间的区别非常微妙，也非常关键。本文将讨论SOA的实践，即：面向架构的设计师在构建SOA时必须要做的事情。

SOA的原则

SOA是一种企业架构，因此，它是从企业的需求开始的。但是，SOA和其它企业架构方法的不同之处在于SOA提供的业务敏捷性。业务敏捷性是指企业对变更快速和有效地进行响应、并且利用变更来得到竞争优势的能力。对架构设计师来说，创建一个业务敏捷的架构意味着创建这样一个IT架构，它可以满足当前还未知的业务需求。

要满足这种业务敏捷性，SOA的实践必须遵循以下原则：

* 业务驱动服务，服务驱动技术

从本质上说，在抽象层次上，服务位于业务和技术中间。面向服务的架构设计师一方面必须理解在业务需求和可以提供的服务之间的动态关系，另一方面，同样要理解服务与提供这些服务的底层技术之间的关系。

* 业务敏捷是基本的业务需求

SOA考虑的是下一个抽象层次：提供响应变化需求的能力是新的“元需求”，而不是处理一些业务上的固定不变的需求。从硬件系统而上的整个架构都必须满足业务敏捷的需求，因为，在SOA中任何的瓶颈都会影响到整个IT环境的灵活性。

* 一个成功的SOA总在变化之中

SOA工作的场景，更象是一个活的生物体，而不是象传统所说的“盖一栋房子”。IT环境唯一不变的就是变化，因此面向服务架构设计师的工作永远不会结束。对于习惯于盖房子的设计师来说，要转向设计一个活的生物体要求崭新的思维方式。如下文所写的，SOA的基础还是一些类似的架构准则。

SOA基础

在IT行业有两个越来越普遍的发展方向，一个是架构方面的，一个是方法学方面的，面向服务的架构设计师可以从中有所收获。第一个就是MDA（模型驱动架构），由提出CORBA的OMG模型提出。MDA认为架构设计师首先要对待创建的系统有一个形式化的UML（也是由OMG提出）的模型。MDA首先给出一个平台无关的模型来表示系统的功能需求和use cases，根据系统搭建的平台，架构设计师可以由这个平台无关的模型得到平台相关的模型，这些平台相关模型足够详细，以至于可以用来直接生成需要的代码。

MDA的核心就在于在设计阶段系统就已经完全描述，这样，在创建系统的时候，几乎就没有错误解释的可能，模型也就可以直接生成代码。但MDA有一些局限性：首先，MDA假设在创建模型之前，业务需求已经全部描述，而这一点，在当前典型的动态业务环境中几乎是不可能的。第二，MDA没有一个反馈机制。如果开发人员对模型有需要改动的地方，并没有提供给他们这么一个途径。

SOA的另一个基础是敏捷方法（AM），其中非常有名的方法是极限编程（XP）。象XP这样的AM提供了在需求未知或者多变的环境中创建软件系统的过程。XP要求在开发团队中要有一个用户代表，他帮助书写测试来指导开发人员的日常工作。开发团队中的所有成员都参与到设计之中，并且设计要尽量小并且非形式化。AM的目标是仅仅创建用户想要的，而不是在一些形式化模型上耗费工作量。AM的核心思想就在于其敏捷性－处理需求变更的敏捷性。AM的主要弱点是其规模上的限制，例如，XP在一个小团队和中型项目中效果不错，但是当项目规模增大时，如果没有一个一致的清晰的计划，项目成员很难把握项目中的方方面面。

从表面看来，MDA和AM似乎是相对立的－MDA假定需求是固定的，而AM恰恰相反。MDA的中心是形式化的模型，而AM恰恰要避开它们。但是，我们还是决定冒险把这些不同方法中的一些元素提取出来，放入到一个一致的架构实践中。

在SOA中有三个抽象层次，按照SOA的第一条准则：业务驱动服务、服务驱动技术。AM将业务模型直接和实践连接起来，表现在平台相关的模型之中。MDA并没有把业务模型和平台无关模型分开来，而是把平台无关模型做为起点。SOA必须连接这些模型，或者说抽象层次，得到单一的架构方法。我们将从五个视图的架构实现方法来实现这个连接。

SOA的五视图实现方法

企业架构设计师发现他们的职业非常有竞争力并且值得骄傲，因为他们要从很多方面来通盘考虑IT系统。Kruchten（RUP的开发负责人）将这些方面提取出来，在应用到SOA时，我们称为五视图实现方法（five-view approach）。

四个方框表示对一个架构的不同审视方法，分别代表不同的涉众（stakeholder）。弟五个视图，use-case视图涵盖了其它视图，在架构中扮演的是一个特殊的角色。部署视图将软件映射到底层平台和相关硬件上，是系统部署人员对架构的视图；实现视图描述了软件代码的组织，是从开发人员角度出发的视图；业务分析人员则利用过程视图进行工作，它描述的是软件系统的运行时特性。最后，逻辑视图表示的是用户的功能需求。在SOA中，面向服务的架构必须能够以use-case视图中的用例将用户连接到服务，将服务连接到底层的技术。

为了表示面向对象的架构是如何工作在这些视图之上，让我们将他们置于SOA元模型的上下文之中。SOA中两个领域存在重叠：由业务模型和服务模型表示的业务领域和由服务模型及平台相关模型表示的技术领域（两个领域共享服务模型）。业务用户通过逻辑视图和过程视图处理粗粒度的业务服务，根据变化的业务需求，按照需要将它们安排在过程之中。另一方面，技术专家的工作是创建并维护服务和地层技术之间的抽象层。表示这些服务的中间模型，起到的是轴心的作用，业务以它为中心进行。

SOA元模型从MDA中继承平台无关模型和平台相关模型，但是添加了AM和用户交互以及敏捷的反馈这两部分，后者通过椭圆之间的双向箭头来表现。类似地，元模型通过引入由中心的服务模型提供的中间层抽象解决了AM在伸缩性方面的问题。这样，服务模型中的任何需求的变化，都会反映到用户每天的业务处理中。同样，由于底层技术是模型驱动的，技术专家也可以根据这些变化的需求迅速而有效地作出应变。

SOA实践和过去解决企业架构传统方式的不同之处就在于其对敏捷性的支持。如前所说，SOA的第三条原则就在于它总在变化之中。这种恒在的变化性环境是SOA实践的基石。如图所示，涉众（stakeholders，译者注：RUP中也有这个词，表示软件开发中涉及到的各种角色如：用户、设计人员、开发人员乃至测试人员等等。）在一个必需的基础上影响到整个架构的变化。在当技术专家在每天的日常工作中不断对变化的业务需求作出响应的这种情况下，设计阶段和运行阶段之间的界限变得模糊起来，很难清晰地分离这两个阶段。

剩下的部分

我们已经为面向服务的架构提供了一个高层次的框架，其中MDA和AM的元素帮助工具的使用者来创建和维护SOA。但是，SOA中还缺少一些内容－那就是软件开发商和专业的服务组织必需提供的。理想情况下，开发商必需提供面向服务的业务流程、工作流以及服务的协调工具和服务；另外，能够以一种敏捷的、平台无关的方式充分反映业务服务的建模工具也是必须的；技术专家必须配备可以从模型中自动生成代码，并在代码变化时更新模型的工具，最后，开发商必须提供支持SOA的软件，帮助面向服务的架构设计师以一种可信并且可伸缩的方式创建位于服务和底层技术之间的抽象层次。幸运的是，这方面的产品即将上市。

另外，最重要的就是贯穿本文的自顶而下的SOA实现方法了。今天关于Web services的大部分思考都是自底而上的：“这是如何创建Web services的方法，现在，我们来使用它们集成吧”，对Web services技术的这种方法是伟大的第一步，因为它可以惊人地降低集成的开销，这是现在的技术管理人员最乐意见到的了。但当经济进一步发展，IT走出低谷，企业会寻求IT的帮助来提高组织战略意义上的核心价值。使用面向服务的架构，IT可以提供给企业实现业务敏捷性的这样一个框架。


[B]http://www.umlchina.com/News/Content/39.htm[/B]

Kenniu

SOA安全性解决方案

本文将描述松散耦合的SOA环境中的安全性解决方案。

　　既然在那篇文章中，我们已经谈及了SOA中的安全性问题，并且大家都需要这方面的信息，因此是时候考虑一些针对这些难题的解决方案了。简单地说，对于SOA安全性问题，您需要为您的SOA购买或开发一个安全性解决方案。详细来说则取决于具体情况，并且非常复杂。不过好在一个设计正确的SOA安全性解决方案可以解决SOA中的绝大部分安全性问题。解决方案本身可以包含多个分别解决SOA安全性中的某个特定方面的子解决方案。根据具体需求和现有的安全性基础架构，不同的企业需要不同的解决方案。

　　让我再重复一遍：我的目标是提供一种评估安全性如何影响SOA规划的方式。我是一个SOA安全性产品提供商。而且，您将会感觉到我对于解决方案的一些偏好。与此同时，您应该清楚，我正在与以相同方式实现SOA安全性的其他许多公司进行竞争。实际上，市场已经证明，某些SOA安全性解决方案要优于其他同类产品。

SOAP消息监控
　　基于SOAP侦听的SOA消息监控是构建高效SOA安全性解决方案基础的一种手段。SOAP侦听

Kenniu

继续...

图1 一个用于监控SOAP消息的SOAP拦截器用作这个SOA中的安全性基础。SOAP拦截器分析它监控的SOAP消息的标题头中包含的用户身份，并将其与保存在现有安全性基础架构中的名称相比较。结果就是对SOAP消息发送方和接收方进行了身份验证和授权。

　　就是在web服务消费者和web服务之间来回传递的SOAP消息的路径中放入一个叫做“SOAP拦截器”的特殊软件块。因为其分类、监控、复制和转发包含大量数据的SOAP消息的能力，SOAP拦截器可以在SOA安全性方面发挥重大作用。如图7所示，一个SOA安全性解决方案“监视”着到达web服务的SOAP调用消息和对这些服务调用的响应。当它“看见”一条消息时，SOA安全性解决方案就会进行检查，以确保发出请求的实体是经过身份验证和授权可以使用web服务的。SOA安全性解决方案通过检查SOAP消息标题头中包含的数据实现了这一点。

　　在大多数情况下，SOA安全性解决方案是对现有安全性解决方案的扩展，而现有安全性解决方案是在迁移到SOA之前为保护整个企业而部署的。因此，SOA安全性解决方案很可能不得不与现有安全性基础架构进行连接和通信。如图7所示，SOA中的用户身份验证和授权发生在基于企业的授权用户数据库检查用户证书的时候。侦听SOAP消息，并把消息标题头中列出的用户与保存在现有安全性基础架构中的用户进行比较，便可实现身份验证和授权。

SAML和联邦身份验证
　　当需要对企业外部的SOA用户进行身份验证和授权时，又会怎么样呢？SOA的开放性使得上述情况比以往任何时候都更可能出现。您可能会面临这样一个难题：在一组在现有安全性基础架构中没有记录的用户中，搞清楚每个用户的身份。为了解决保护第三方过程中固有的安全性问题，SOA安全性解决方案可以使用联邦身份验证。联邦身份验证是这样一个过程：通过这个过程，多方可以达成一致，使用一组给定的标准来对一组指定的用户进行身份验证。联邦身份验证方法的使用者可以创建一个联邦身份管理系统(Federated Identity Management System)，这是一个已验证用户的库。SOA安全性解决方案可以通过检查联邦身份管理系统来对某个用户进行身份验证。换句话说，一些相互通信的系统的“联邦”，可以一致同意某个用户是合法的。

　　在某些情况下，身份验证过程会导致在SOA安全性解决方案中创建安全断言标记语言（Security Assertion Markup Language，SAML）断言，用于以一种可为用户调用的web服务所接受的方式表达用户的真实性。SAML是一种基于XML的标准，它为以标准方式描述安全性信息提供了一个框架。WS-Security是迄今为止得到认可的安全性标准集合的总称。许多SOA安全性解决方案都利用了这些新兴的安全性标准。如图8所示，SOA安全性解决方案可以侦听SOAP消息，然后使其经过一个对用户进行身份验证的过程。接下来，SOA安全性解决方案把SOAP消息传递给目的web服务，但是会附加上一个SAML断言。注意：SAML断言不依赖于联邦身份验证过程。

Kenniu

继续16楼.

图2 要在SOA安全性中使用联邦身份验证，SOAP拦截器必须把传入的SOAP消息转发给安全性解决方案，该安全性解决方案再把SOAP消息标题头中包含的用户身份与联邦身份验证数据库中列出的用户进行匹配。如果匹配成功，SOA安全性解决方案就会创建一个安全“断言”，内容是用户已经在安全断言标记语言文档中通过了身份验证，该文档是在SOAP消息到达它要调用的web服务时附加给该SOAP消息的。

应用程序代理
　　一种非常有效的保护核心系统的方法是避免让任何人访问驻留平台的服务。可以通过为SOA中的web服务部署一个代理做到这一点。如图9所示，一个受保护的代理可以代表实际的web服务接收所有web服务请求，并对其做出响应，从而保护web服务免遭恶意的侵害。代理方法的另一个好处在于，它能够减轻企业安全性基础架构的负担。代理可以降低网络流量，具体方法是集中管理和缓存对web服务请求的身份验证和授权，而不是每次用户想调用web服务时，就在网络上使用大量消息对该用户进行身份验证和授权。代理还在消息中插入了身份验证和授权SAML断言，从而消除了实际web服务直接查询安全性系统的需要。

契约管理
　　在下一章中，我们将花大量时间来讲述这个主题，但是作为主要的SOA管理问题之一，契约管理同样在SOA安全性中起着举足轻重的作用。契约就是用于管理web服务使用情况的一组规则。例如，某个契约可能会规定，某个特定用户有权每天调用某个特定的web服务十次。而且在调用过程中，服务水平必须满足特定的参数，比如一秒钟的响应时间。

　　在安全性方面，契约有助于确定SOA是否运行正常，或者由于违反安全性规则而误用。如图10所示，SOA拦截器把web服务请求和响应数据发送给SOA安全性解决方案，然后该SOA安全性解决方案再确定是否满足契约。如果某个安全性问题（比如DoS攻击）使web服务的速度降低到契约规定的服务水平以下，SOA安全性解决方案就会警告管理方有问题存在。当然，一次足够严重的攻击可以导致整个网络崩溃，但是安全性解决方案至少可以发出有问题存在的通知。

下图是图三

Kenniu

图3 通过处理SOAP消息流量，降低企业安全性基础架构的负担，并保护web服务免于误用，web服务代理有助于保护SOA。
图4 SOA安全性解决方案监控服务水平，并在安全性问题导致web服务降低到契约规定的服务水平以下时发出警告。
证书、密钥和加密
　　这些年来，IT领域先后出现了很多消息级的安全性技术，包括密码术。现在，也可以对SOA应用这些技术。这些过程，包括数字签名、证书、密钥和加密，都可用来保护SOA。在这里我声明一点：对于这4种安全性技术中的每一种，都可以写出一本甚至是好几本著作。请把本节看作是对与SOA相关的基于加密的安全性的一个概述。

　　如果希望让SOA拥有健壮的安全性，保证web服务的用户都可以得到适当的身份验证，而未经身份验证的人无法读取在web服务及调用它们的应用程序之间往返的信息，那么无疑需要对SOA安全性解决方案应用功能强大的公钥/私钥加密工具。密钥是一个具有某种特殊的数学特性的大数（数百个数位）。尽管形式和大小各不相同，但密钥都有一个基本属性，即，可以与另一个密钥进行惟一关联。也就是说，当一个密钥遇到其惟一的匹配密钥时，双方都会说，“哦，就是你了，我惟一的匹配…不会再有其他的什么人了。”

　　惟一的密钥对具有如下两个基本功能：

因为它们是惟一的，所以它们是非常强大的身份验证工具。
由于它们的数学特性，它们可用于创建经过不可测知的过程进行加密的惟一消息，这些消息只能被拥有惟一的匹配密钥对的用户所读取。
　　下面讲述当两个用户想交换加密信息时的工作原理：用户A创建一个惟一的密钥对。然后，他在自己的系统中隐藏其中的一个密钥（“私钥”），却把另一个密钥（“公钥”）发送到用户B可访问的网络上某处。然后，用户B使用公钥来加密他想要发送给用户A的信息。实际过程涉及到大量让我想一想就头痛的数学知识，但是基本上，公钥和消息数据是通过一个加密算法来运作的，该加密算法生成一个没有私钥不可能打开的加密文件。接下来，用户B把经过加密的消息发送给用户A，而用户A则使用最初隐藏的私钥来对加密数据进行解密。结果，用户A是世界上惟一一个能够解密这些加密数据的人，因为（只有）他拥有与用户B的公钥匹配的惟一私钥。

　　现在，如果您像我一样爱刨根问底，您可能会想，但是用户A如何知道用户B真的是用户B呢？如果某位黑客侵入到用户B的系统中，并找到了他使用的公钥，那怎么办呢？为了回答这个有效性问题，人们使用了大量实体来确保特定用户的真实性，并授予他们证明其真实性的数字证书。这些实体叫做certificate authority (认证机构，CA)。CA的一个著名例子是VeriSign，它提供用于电子商务事务的证书。

　　使用密钥、加密和证书来实现保密性和身份验证的SOA安全性解决方案如图11所示。在我们的制造商例子中，供应商系统想发送一条SOAP消息给制造商的web服务。为了做到这一点，制造商必须首先发送一个公钥给CA。然后，供应商系统从CA请求一个证书。供应商收到的证书包含与制造商系统中存在的私钥相匹配的公钥。然后，供应商使用证书的公钥加密其消息，然后再把消息发送给制造商。然而，和前面的例子一样，SOA安全性解决方案侦听消息，并使用CA检查证书的有效性。这可以验证供应商的身份。只有在通过身份验证之后，加密后的SOAP消息才能被发送给制造商。SOAP消息到达之后，制造商就使用它的私钥对消息进行解密和处理。

　　如果您觉得这听起来更多地像是在发送消息，那么您想得没错。就像在IT的其他领域中一样，SOA中的安全性会带来大量“开销”。在到达目的地之前，每条消息都必须经过好几个地方。证书文件可能会很大，从而给网络造成很大的负担，而且整个过程往往会降低性能。但是遗憾的是，它仍然是必不可少的。

下图是图四

Kenniu

　 图字：

制造商将公钥发送给认证机构，并将私钥隐藏在自己的域中
供应商从认证机构请求包含制造商公钥的证书
供应商向制造商发送使用公钥进行加密并包含证书的消息
SOA安全性解决方案向认证机构发送证书，以便对供应商进行身份验证
SOA安全性解决方案向制造商发送使用私钥进行加密的SOAP消息
　　为了保留SOA的开放性，同时制订严格的消息级的安全性标准，您很可能想在加密时使用XML。当SOA安全性解决方案使用密钥对消息进行加密时，它会把消息转换为一段经过加密的XML。消息是XML格式的，但是内容并不可见，因为使用加密算法将其隐藏起来了。这样做的好处在于，接收消息的系统可以把它当作XML来接收、解密和处理，而不依赖于定制或专有的消息传递标准。这样我们就获得了安全性，同时系统仍然基于开放标准。

数字签名
　　数字签名是另一种消息级的安全性形式，它是证书、密钥和加密等安全性方法的变体。数字签名就是附加给SOAP消息的证明真实性的数学语句。数字签名是一个基于密钥的数（同样是一个非常大的数），它对您的身份和消息内容进行惟一的处理，具体方法是对两组数据（密钥和消息）运行一个特殊的算法。举一个简单的例子，如果您的消息是“hello”而密钥是12345，算法将处理这两种输入——单词“hello”的数值和密钥数12345——并生成第三个数，这第三个数就是数字签名。当接收系统获得消息和附加的数字签名时，它可以使用密钥来验证以下内容：

您是消息的真正创建者（身份验证），
SOAP消息在传输过程中没有改变。
　　如果消息被改变了，那么惟一的数字签名将不再与密钥和用于创建密钥的原始消息相匹配。数字签名和先前描述的完整加密过程之间的区别在于，如果使用数字签名，不必对整条消息进行加密。因此，系统的性能得到了提升。只要您不介意别人可以看到您的纯文本格式的消息，那么数字签名就可以为SOA提供高度的数据安全性和完整性。

　　签名可以是一个不可否认性（nonrepudiation）组成部分，该特性是一个需要在SOA环境中解决的安全性重要方面。不可否认性是指一个组织的一种能力：验证发生了特定的处理，并从而不给发送方提供否定进行了处理的机会。例如，如果您针对某种商品下了一份电子订单，而该订单并没有以某种方式（比如使用数字签名）进行验证，那么对方就有可能否认收到该订单。如果批发商的系统提供不可否认性，那么批发商就可以肯定该订单已经送达。

重放攻击保护和审计
　　最后，SOA安全性解决方案应该提供一种用于跟踪SOAP请求的工具，从而降低DoS攻击带来损害的可能性。通常，跟踪特性将监控SOAP消息的发送方及其创建时间。在某些情况下，SOA安全性解决方案将使用一个惟一的识别码给SOAP消息打上印记。如果解决方案被设置为阻塞复制消息，那么同一条消息是不可能被发送两次的。消除这种可能性有助于降低黑客使用复制请求淹没SOA的可能性，这是DoS攻击中常用的一种手法。

　　审计是SOAP消息跟踪功能的进一步发展。如果SOA安全性解决方案被配置为跟踪消息，那么它应该能够生成特定时期中SOA消息流量的使用日志和审计报告。审计有很多用途，但是在安全性领域中，它用于记录所发生的事情，以便研究安全性问题并诊断潜在的安全漏洞。这类日志已经成为实现管理目标（比如对Sarbanes-Oxley法案的服从）所必不可少的。

明智的管理人员所给出的忠告：不要让安全性吓倒了您
　　SOA安全性是一个很大的主题。我可以就这个主题写一本书。（事实上，这是一个不错的主意…）在本章中，我的目的是提供一个概述，好让您可以评估自己对这个主题所掌握的信息。如果您是一位企业主管，我的建议是，要避免被安全性问题吓倒。人们很容易被安全性吓倒，安全人员也不例外，这阻止了他们做些实际工作以消除对于安全性问题的恐惧。实际上，我本来可以提出一个您正在考虑的IT解决方案，并让您了解到围绕该解决方案的大量安全性噩梦，这些噩梦足以使您远离该解决方案。

　　相反，我建议您寻求安全性方面的高质量建议，并探讨企业中已经实施了哪些。如果您这样做，那么您的企业就很可能会拥有一个（或一些）相当健壮的安全性系统。实施SOA的难点在于如何把现有的安全措施扩展成为由SOA构成的web服务。许多SOA安全性解决方案的设计目的就是为了与现有的安全功能有效互连。如果实现的话，安全性风险可能稍微易于管理一些，而您也可以继续实施您的计划了。

结束语
　　安全性是SOA中的一个焦点问题，因为SOA强调机器与机器的交互，而大多数IT安全性都是基于人与机器的交互。身份验证和授权在这个环境中变得更加富于挑战性。在未受保护的SOA中，想要阻止web服务的未授权使用实际上是不可能的；未授权用户可以非常轻松地访问web服务。Web服务不具备跟踪谁在使用它们或者谁被允许使用它们的固有功能。无法阻止不必要的监听和消息侦听。未受保护的SOA让黑客有机会监听SOAP消息并看到私密信息。此外，在未受保护的SOA中，侦听SOAP消息并（出于危害和欺骗的目的）重新发送消息或转换消息内容要相对容易一些。

　　由于SOA架构的开放性本质，您无法保护SOA中未知的第三方。第二级和第三级用户（例如您的合作伙伴的合作伙伴）是可以访问未受保护的SOA的。因此，未受保护的SOA很容易超负荷运转。如果没有访问控制，未受保护的SOA很容易被来自黑客的大量SOAP消息所“淹没”。结果可能导致DoS攻击损害系统的正常功能。最后，您还没有处理记录。未受保护的SOA无法跟踪其用户或消息。因此，没有可用于研究安全性问题或诊断安全性漏洞的可审计使用记录。

　　存在一些可以解决所有这些问题的预打包和定制的SOA安全性解决方案。在分析SOA安全性需求时，可以考虑实现一个支持SOAP消息监控、联邦身份验证、应用程序代理、契约管理、证书、密钥和加密以及审计记录的SOA安全性解决方案。这个清单似乎很长，但是事实上，如果缺少其中任何一项，SOA的所有优点都可能遭到破坏。

　　SOAP消息监控利用了一个SOAP拦截器模型，以便在将SOAP消息从调用系统发送给web服务时对其进行侦听和监控。SOAP消息监控是SOA安全性的基础，因为它让安全性解决方案能够停止和分析每条消息，以进行用户身份验证和授权。为了保护第三方，安全性解决方案可以利用联邦身份验证。应该通过一个联邦身份验证过程提供对系统中的用户进行身份验证的能力。最终将获得一个为web服务的用户提供可信身份验证的SAML断言。

　　Web服务应用程序代理在实际的web服务中接收和处理SOAP请求，从而对安全性有所帮助。它可以使所有的用户都远离实际的服务。代理不仅可以减轻网络的负载，还可以为SOA提供一个额外的安全性层。

　　契约管理是另一项对安全性有所帮助的SOA管理特性。契约确立了谁有权使用web服务以及何时可以使用它。契约通过消除非契约方的使用，提高了SOA的安全性。

　　对于一个真正安全的SOA来说，证书、密钥和加密同样是必不可少的。最健壮的SOA安全性都源于实现了使用来自认证机构的私钥/公钥进行身份验证的加密消息传递。XML加密允许web服务用户发送保留XML格式的加密SOAP消息。因此，系统实现了安全性，但却仍然基于标准。数字签名是加密模型的一种变体，它使得web服务的用户可以创建一个惟一确认的数字“签名”，其用途有二：验证用户身份和确保消息数据的完整性。

　　最后，为了跟踪SOA的使用，有必要采用可以保存所有SOAP消息请求和响应的动态审计日志的SOA安全性解决方案。审计日志对于在SOA中研究安全性问题和诊断安全性漏洞，以及实现管理规章服从性，都是必需的。

原文出处:http://www.developer.com/java/ent/article.php/3607471


作者简介
Hugh Taylor 是一位SOA营销主管，从事SOA和web services方面的著作编写和教学工作，并致力于向大公司宣传二者的商业价值。两位作者都居住在加利福尼亚州洛杉矶市。
Hugh Taylor 是软件和数字交互性行业中的先驱人物。他经常在世界各地的技术大会上发表公开演讲，并帮助建立了一些媒体管理、专业服务、语音系统和对等网络方面的顶尖技术公司。
下图是图5

Kenniu

转载说明:

从16楼到 19楼的资料来自于...http://dev2dev.bea.com.cn/techdoc/20060720848.html