微软《SOA in the Real World》笔记03——第一章

来源:互联网 发布:java编写简易计算器 编辑:程序博客网 时间:2024/06/10 20:57
 

微软《SOA in the Real World》笔记03——第一章

 
SOA 神话与事实
在进一步深入了解SOA之前,理解一些与SOA有关的神话是非常重要的。下表中列出了SOA周围一些排名前列的神话及其事实,以帮助来戳穿这些神话。
神话
事实
SOA是一种技术。
SOA是一种独立于任何厂商、产品、技术和产业趋势的设计哲学。没有厂商能够提供完整的一站式SOA,因为不同的组织SOA的需求是不同的。从单一厂商那里购买SOA基础设施会让SOA的投资目标失败。
SOA需要Web服务。
SOA可以通过Web服务实现,但实现SOA并不一定需要Web服务。
SOA是全新的、革命性的。
EDI、CORBA和DCOM是面向服务(SO)的概念化例子。
SOA保证了业务和IT的一致。
SOA不是一种方法论。
SOA参考架构能够降低实现的风险。
SOA就像是雪花——没有两片是相同的。一个SOA参考架构未必能够给组织提供最好的解决方案。
SOA需要进行技术上的和业务流程上的全面更新。
SOA应该是递增的,并建立在当前投资的基础上。
我们需要建造SOA。
SOA是一个途径,而不是终点。
 
把重点放在交付解决方案上的做法,不是SOA。SOA是一个交付解决方案的途径,而不是最终的目标。
 
SOA的演化
面向服务(SO)是当前开发模型自然演化的结果。80年代是面向对象模型,90年代则进入了组件式开发模型,现在则是面向服务(SO)。面向服务保留了组件式开发的优点(自描述、封装、动态发现和加载),但是放弃了基于对象的远程调用方法,转为了在服务间传递消息。样式不但描述了消息的结构,而且也描述了行为契约,用于定义可接受的消息交换的模式,以及策略,用于定义服务的语义。这提高了互操作性,进而提供了适应性方面的好处,因为消息可以从一个服务传送给另一个服务而不用去考虑处理消息的服务是怎样实现的。
 
面向服务提供了一种创建分布式软件的演化式的方法,该方法有利于松耦合集成和易于变更。随着WS-* Web服务的出现,同时由于主流开发工具支持和大范围业界的互操作性,使得面向服务的软件开发变得可行。尽管最常见的实现采用了产业标准Web服务,但是面向服务是独立于技术和它的架构模式,也能够用于连接遗留系统。
 
不幸的是,面向服务提供的好处和SOA已经因为围绕着这些术语的过度宣传和混乱而变得不再清晰。随着对SOA的认知和兴奋的膨胀,曾经的定义面向服务的清晰界线也变得模糊起来。但是,只要用于正确的目的,SO确实能够提供某种特定的好处。以下是与SO有关的三个重要方面的说明:
 
 
1、 SO是演化而来的。面向服务开发的原则是建立在数十年开发现实中的分布式应用的经验的基础之上的。SO结合了诸如自描述应用、显式封装以及运行时动态加载功能等概念——这些原则最初是由80年代和90年代的面向对象和组件式开发方式而引入的。SO发生的变化是开发人员获得这些好处的隐喻。取代通过对象引用上的方法调用,面向服务转为通过消息传送建立会话——这是一个已经证实的隐喻,该隐喻可应用在可伸缩的分布式软件的集成方面。
2、 SO不是一项产品或者技术。它是一组独立于任何产品的架构原则。就像多态和封装等开发概念是独立于技术一样,SO也是如此。尽管在近年来Web服务为面向服务应用的开发提供了许多便利,但是这些应用却不一定需要Web服务。
3、 SO是渐进的。最后,面向服务能够也应该是一个渐进的过程——通常可以在内部完成的过程。不应该要求客户戏剧性地重构他们的业务来获得面向服务的好处。相反,客户应该能过有效利用已有的IT资产。使用可以目前已经拥有的技术和技能常常也能够达到面向服务开发的目标。
 
面向服务架构的基本构建块是服务。服务是可以通过定义良好的消息交换进行交互的程序。服务的设计必须具有可用性和稳定性。创建的服务需要长时间保持,而服务的配置和组合则可以更改。敏捷常常被称为SOA的最大好处——在松耦合基础设施上实现了业务流程的组织对变化有更高的开放性,那些被限制在单一应用程序下的组织,即时最小的修改也需要几周的时间。松耦合系统导致了松耦合的业务流程,因为业务流程不再受到基础设施的限制。服务和它们的接口必须保持稳定,以便能够重新配置或重新组合它们来满足已经改变了的业务需求。服务可以通过基于标准的接口和定义良好的消息来保持稳定——例如,使用SOAP和XML样式作为消息的定义。那些设计用来执行简单的、细粒度的功能的服务,只需要那些消息如何传送和恢复的有限知识,这些服务更多可能是在更大的SOA基础设施中进行重用。
 
面向服务不需要从头重新软件功能。按照四个原则(见下文)能够使现存的IT资产获得重用,这是通过把它们包装成模块化的服务实现的,这些服务能够插接到设计的任何业务流程中。这样做的目的如下:
  • 连接到已有系统中——现存IT资产的之上分层的业务流程管理、协同工作流以及报表。
  • 从已有系统中获得更多价值——用新的方式重用现存的应用程序。
  • 扩展和优化已有系统——为新的跨职能业务流程创建IT支持,这种扩展超出了已有应用程序设计时的功能边界。
 
面向服务的一个关键的好处是松耦合。No discussion of Web services seems complete without some reference to the advantages of looser coupling of endpoints (applications) facilitated by the use of Web service protocols.原则是使用一个资源时只通过它发布的服务,而不是直接指向它背后的实现。通过这种方式,服务提供者对实现做的更改就不会影响到服务的消费者。通过维护一个一致的接口,服务消费者可以选择相同服务类别的替代实例(例如更换服务提供者)而不用修改调用程序,而且也从新的实例的发布中分离出来了。当使用Web服务时(即使双方都倾向于使用相同的Web服务协议),服务的消费者和提供者不需要使用相同的实现技术、接口技术和集成技术。