《真实世界中的SOA》
第一章翻译说明
微软发布了一个名为“真实世界中的面向服务架构（SOA）”的电子书。这本书表达了微软对面向服务架构的观点，并包括了数个展示如何用微软产品和技术实现SOA的真实案例。
前面的两个章节基本上是介绍性质的，引入了微软的四个基本原则，介绍了抽象SOA考模型以及ESOMM(Enterprise Service Orientation Maturity Model) SOA成熟度模型，讨论了服务生命周期，提供了一个服务分类方法和SOA场景。接下来的章节则介绍了SOA的各个方面：
工作流和流程
数据
用户交互
认证和访问
这本电子书基本上讨论了SOA的各个方面，并通过案例研究阐述说明，从而展示了如何在真实的世界里用微软的产品和技术进行实现。
第一章
“SOA和雪花一样——没有两片是相同的。”
- David Linthicum 顾问
SOA介绍
SOA大象
SOA已经变成一个为人熟知但又相当有争议的缩写词。如果让两个人给SOA下定义，很可能会得到两个非常不同的，甚至可能是相互冲突的的答案。一些人把SOA描述成驱动业务的IT基础设施，而另一些则认为SOA是用来提升IT的效率的。约翰.戈弗雷.萨克斯(John Godfrey Saxe）的诗中讲述了盲人和大象的故事，在很多方面，SOA都有点类似于诗中的情形。从印度斯坦(Indostan)来的六个盲人遇到了一头大象——因为他们受自己个人经验的影响，每个人对这头大象的描述都有所不同：
l 摸到象鼻的人相信它是一条蛇
l 摸到象牙的人相信它是一把长矛
l 摸到耳朵的人相信它是一把扇子
l 摸到象的一边身体的人相信它是一堵墙
l 摸到尾巴的人相信它是一条绳子
l 摸到象腿的人相信它是树。
图1：萨克斯的大象
盲人们接下来就开始了一系列的辩论，争辩他们所坚信的东西：
“因此这些印度斯坦人长久地和高声地争论者，
每个人都坚持自己的观点，
非常固执和强硬。
虽然每个人都部分正确，
但合在一起却是错的！”
从很多方面来说，Saxe先生的诗都成为了SOA的预言。产业分析家、学者、博客和记者都卷入了一场不断发展着的，永无休止的关于什么是和什么不是SOA的争论之中。就像Saxe先生诗中的盲人，人们已经正确地识别出了SOA的很多功能，但是在把SOA作为整个概念进行沟通时大都失败了。定义SOA 的挑战已经变得如此重要，所以不同的产业组织和标准组织都已经开始了尝试和解答这个问题的努力——什么是SOA？
SOA的简单定义
按照本书的意图，我们给SOA定义如下：
设计用来满足组织业务需求的松耦合架构。
乍一看这个定义似乎过于简单——SOAP、web服务、WSDL、WS-*和其他相关标准去了哪里？SOA并不一定需要web服务——对大多数组织来说，web服务是实现松耦合架构的最简单的方法。在过去，松耦合架构依赖于其他技术，比如CORBA 和 DCOM，或者是以文档为基础的方法，如用于B2B 集成的EDI。这些技术中很多还在大量使用，还在通过web服务进行增强、替换或者是扩展。对我们来说，我们的SOA定义工作不是因为我们的重点不在于SOA技术上，而是在于满足组织的需求上。简而言之，组织的SOA看起来除了一堆web服务（或其他技术）之外，什么也不是。除了可能都拥有一些
通用的诸如日志和验证等基础设施之外，用于一个组织的SOA的大部分会与另一个组织使用的SOA明显不同。
许多分析家和产业学者混淆了面向服务架构和面向服务实现的概念。这只会增加SOA及其相关概念的迷惑程度。这可能会导致灾难性的后果。
温切斯特神秘屋(Winchester Mystery House)是一个引人入胜的旅游地点，位于美国CA的San Jose附近。温切斯特神秘屋是温切斯特财产（通过卖温切斯特步而发迹）的女继承人的家。传说中的说法是，她去拜访一个灵媒，获知她受到了诅咒，她会受到每个死在温切斯特步下的灵魂的骚扰。避开这个诅咒的唯一方法是建造一座大厦——只要她不停地建造，鬼魂就不会来打搅她。她迅速地请了147个建筑工人（和0个建筑师），他们同时开始建造这座大厦。直到38年后这位女继承人过世，这些建筑工人一直在建造它。他们工作的结果最终成了一个缺少架构的经典案例：
·大厦有160个房间，40个卧室，6个厨房，2个地下室和950扇门
·在950扇门中，65个是开向墙的，13个楼梯造好后又废弃了，24个天窗开在不同的楼层上
·这个大厦没有制作过建筑蓝图
图2 温切斯特神秘屋
混淆架构与实现导致混乱和无法预料的结果——就像温切斯特神秘屋一样。那些试图讲解SOA而后跳
入构造Web服务的那些文章是，是在提供编码指导，而不是架构。这是如今SOA被这样误解的主要原因之一—匆忙设计到松耦合架构，是只见树木，不见森林。
与SOA有关的架构概念并不新——许多概念是从CORBA、 DCOM、DCE和其他技术的思想中演化而来的。与以前的这些技术相比，SOA的关键承诺是允许通过开放的、基于标准的互操作性使得业务流程变得敏捷。虽然这些标准至关重要，但我们还是要记住，标准不是架构，架构也不是实现。不管怎么说，基于设计良好架构的实现，而不是架构本身，能够创造商业价值。
SOA是一个从自治服务中构建系统的架构方法。通过SOA，集成是预先考虑的而不是在事后——最终的解决方案是由服务组成的，这些服务是用不同的编程语言开发的，部署在不
同的平台上，有着不同的安全模型和业务流程。虽然这个概念听起来及其复杂，但实际上并不新——有些人会说SOA是从设计和开发基于以前技术的分布式系统的经验中演化而来的。与SOA有关的很多概念，例如服务、发现和后绑定等，与CORBA和DCOM有关。同样，许多服务设计原则也与早期的OOA/OOD技术基本相同，都有着相同的基础，包括封装、抽象和明确定义的接口。
这些围绕着SOA和服务的嗡嗡争论意味着在过去IT不是面向服务的吗？不是的——IT（不管是否外包）的存在只是为了推动业务。没有IT，在执行和竞争力方面，业务都会变得特别困难。但是，如果IT不能足够快地响应业务需求和业务机会，IT就会变成业务的阻碍而不是推动力。
soa
虽然SOA承诺帮助It以更及时得多的方式来响应市场情形，但是它只是一种架构哲学，而不是一种实现概念。许多分析员和商业杂志混淆了架构与实现——这导致了人们相信实现实际上就是架构，而这会引发灾难性的后果。
由于业务需求和业务目标的极大不同，不同的组织对SOA有着不同的需求和期望。描述SOA是一个巨大的挑战，这一简单的事实正是其中原因之一。SOA，和其他的行动一样，必须为组织提供某种程度的价值——否则怎么想，它都毫无用处。对一个组织而言，要保证SOA投资回报，最好的方法是把SOA和业务驱动结合起来。尽管这是个显而易见的事实，但是关于SOA还有很多混淆。
SOA 神话与事实
在进一步深入了解SOA之前，理解一些与SOA有关的神话是非常重要的。下表中列出了SOA周围一些排名前列的神话及其事实，以帮助来戳穿这些神话。
关注于交付解决方案，不是SOA。SOA是一个交付解决方案的手段，而不是最终目标。
SOA的演化
面向服务（SO）是当前开发模型自然演化的结果。80年代是面向对象模型，90年代则进入了组件式开发模型，现在则是面向服务（SO）。面向服务保留了组件式开发的优点（自描述、封装、动态发现和加载），但是放弃了基于对象的远程调用方法，转为了在服务间传递消息。样式(模式)不但描述了消息的结构，而且也描述了行为契约，用于定义可接受的消息交换的模式，以及策略，用于定义服务的语义。这提高了互操作性，进而提供了适应性方面的好处，因为消息可以从一个服务传送给另一个服务而不用去考虑处理消息的服务是怎样实现的。
图3：简单的基于SOAP协议的Web服务间的通讯
面向服务提供了一种创建分布式软件的演化式的方法，该方法有利于松耦合集成和易于变更。随着WS-
* Web服务的出现，同时由于主流开发工具支持和大范围业界的互操作性，使得面向服务的软件开发变得可行。尽管最常见的实现采用了产业标准Web服务，但是面向服务是独立于技术和它的架构模式，也能够用于连接遗留系统。
不幸的是，面向服务提供的好处和SOA已经因为围绕着这些术语的过度宣传和混乱而变得不再清晰。随着对SOA的认知和兴奋的膨胀，曾经的定义面向服务的清晰界线也变得模糊起来。但是，只要用于正确的目的，SO确实能够提供某种特定的好处。以下是与SO有关的三个重要方面的说明：
1、 SO是演化而来的。面向服务开发的原则是建立在数十年开发现实中的分布式应用的经验的基础之上的。SO结合了诸如自描述应用、显式封装以及运行时动态加载功能等概念——这些原则最初是由80年代和90年代的面向对象和组件式开发方式而引入的。SO发生的变化是开发人员获得这些好处的隐喻。取代通过对象引用上的方法调用，面向服务转为通过消息传送建立会话——这是一个已经证实的隐喻，该隐喻可应用在可伸缩的分布式软件的集成方面。
2、 SO不是一项产品或者技术。它是一组独立于任何产品的架构原则。就像多态和封装等开发概念是独立于技术一样，SO也是如此。尽管在近年来Web服务为面向服务应用的开发提供了许多便利，但是这些应用却不一定需要Web服务。
3、 SO是渐进的（增量的）。最后，面向服务能够也应该是一个渐进的过程——通常可以在内部完成
的过程。不应该要求客户戏剧性地重构他们的业务来获得面向服务的好处。相反，客户应该能过有效利用已有的IT资产。使用可以目前已经拥有的技术和技能常常也能够达到面向服务开发的目标。
面向服务架构的基本构建块是服务。服务是可以通过定义良好的消息交换进行交互的程序。服务的设

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。