soa个人理解

1,在SOA架构风格中，服务是最核心的抽象手段，业务被划分（组件化）为一系列粗粒度的业务服务和业务流程。业务服务相对独立、自包含、可重用，由一个或者多个分布的系统所实现，而业务流程由服务组装而来。一个"服务"定义了一个与业务功能或业务数据相关的接口，以及约束这个接口的契约，
2,接口和契约采用中立、基于标准的方式进行定义，它独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在不同系统中的服务可以以一种统一的和通用的方式进行交互、相互理解。除了这种不依赖于特定技术的中立特性，通过服务注册库（Service Registry）加上企业服务总线（Enterprise Service Bus）来支持动态查询、定位、路由和中介（Mediation）的能力，使得服务之间的交互是动态的，位置是透明的。技术和位置的透明性，使得服务的请求者和提供者之间高度解耦。这种松耦合系统的好处有两点：一点是它适应变化的灵活性；另一点是当某个服务的内部结构和实现逐渐发生改变时，不影响其他服务
3,将SOA的主要优点概括为：IT能够更好更快地提供业务价值（Business Centric）、快速应变能力（Flexibility）、重用（Reusability）
4,从演变的历程来看，SOA在很多年前就被提出来了，现在SOA的再现和流行是若干因素的结合。一方面是多年的软件工程发展和实践所积累的经验、方法和各种设计/架构模式，包括OO/CBD/MDD/MDA、EAI和中间件；另一方面是互联网的多年发展带来前所未有的分布式系统的交互能力和标准化基础。与此同时，企业越来越重视业务模型本身的组件化，以支持高度灵活的业务战略
5,
第一，SOA是架构风格，是方法；而不是具体架构具体实现技术（如Web Service）、具体架构元素（如企业服务总线，Enterprise Service Bus，ESB）。
第二，SOA的首要目标是IT与业务对齐，支持业务的快速变化；其次是IT架构的灵活性和IT资产的重用。
第三，在工程上，SOA的重点是服务建模和基于SOA的设计原则进行架构决策和设计




























>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
由于业务需求比较简单，所有这些东西都在一个J2EE的应用服务器上，有些要素不是那么突出，不过随着系统规模的扩大，要解决的业务问题更复杂、范围更大的时候，SOA的各种架构要素就会变得越来越重要。




经常有人认为只要用了Web Service，就是SOA了。这是不对的，Web Service只是实现服务的一种具体技术表现形式。同样，认为搞SOA，就是买点软件，建个ESB，这也是不对的，ESB只是SOA架构风格中的一部分。首先，ESB是一种从实践中总结出来的架构风格元素，即BUS（总线模式）；其次，ESB的主要功能是负责连通性和服务中介（Service Mediation），解耦服务的请求者和服务的提供者。


从建模和设计的角度来说，SOA更多地侧重在业务层次上，也就是通过服务建模将业务组件化为服务模型，它是业务架构的底层，是技术架构的顶层，承上启下，是灵活的业务模型和IT之间的桥梁，保证二者之间的"可追溯性"。从这里往下，是基于已有的方法，比如OO/CBD来进行的。从架构的层次上，SOA更多地侧重于如何将企业范围内多个分布的系统（包括已有系统/遗留系统）连接起来（ESB，Adapter/Connector），如何将它们的功能、数据转化为服务，如何通过服务中介机制（ESB，Service Registry）保证服务之间以松散耦合的方式交互，如何组装（集成）服务为流程，如何管理服务和流程等。从这往下，对于实现服务的一个具体应用，它的架构、设计和实现是可以基于已有的实践和方法的，比如J2EE或.NET。


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
SOA主要技术和标准


Web服务作为实现SOA中服务的最主要手段。我们首先来了解跟Web Service相关的标准，它们大多以“WS-”作为名字的前缀，所以统称WS-*。
Web服务最基本的协议包括UDDI，WSDL和SOAP，通过它们，我们可以提供直接而又简单的Web Service支持，如图1-7所示。
但是基本协议无法保证企业计算需要的安全性和可靠性，所以我们需要增加这方面的协议，比如WS-Security，WS-Reliability和WS-ReliableMessaging；对于复杂的业务场景，我们需要WS-BPEL和WS-CDL这样的语言来将多个服务编排成为业务流程；管理服务的协议如WS-Manageability，WSDM等。跟Web服务相关的标准，还在快速发展当中。目前在SOA产品和实践中，除了基本协议外，比较重要的还包括BPEL，WS-Security，WS-Policy和SCA/SDO






OOAD和SOA
面向对象的分析和设计告诉我们使用Use Case捕获需求，并设计类、对象及对象间交互来满足Use Case定义的需求。但是面向对象的分析和设计往往只是局限在单个应用内部，它不会缺乏业务蓝图和企业架构蓝图的指导。从SOA方法学看，在原理层面上，OOAD中的很多设计原则，如抽象、隔离关注等被SOA继承和发扬，并应用于服务的定义和实现中。而在操作层面上，服务模型为OOAD进行类和对象设计提供了业务蓝图和企业架构蓝图，与此同时，Use Case作为对业务流程的补充说明被用于服务的发现和定义中




BPM和SOA
业务流程建模是一个相当零散的领域，存在各种各样的方法和技术，有效的方法可以帮助企业对业务进行合理的划分，从而求得业务层面的灵活性。有些方法则侧重于流程建模本身，例如如何确定和定义业务流程中的业务活动、业务数据、业务规则、业务指标和业务事件等，但是BPM并不会帮助我们去发现和定义服务。从SOA的方法学来看，各种BPM的结果是面向服务的分析和设计的重要输入，如业务组件、业务流程和业务目标是服务发现的重要依据，而业务指标、业务数据、业务规则等是服务暴露的分析的重要依据。




EA和SOA
尽管和BPM一样，EA是一个零散的领域，但是当前的EA主要侧重于定义跨越业务单元边界的系统框架，企业范围内系统的主要构成元素，这些元素间的关系，以及将这些元素有机组合在一起的参考架构。但是，各种EA技术都缺乏业务领域的蓝图指导企业架构的设计。从SOA方法学来看，一方面，面向服务的分析和设计通过和BPM结合将业务分解为各种类型的服务，可以作为企业业务的蓝图指导企业架构的设计；另一方面，企业架构设计的结果，如参考架构，又是服务实现的重要依据。














>>>>>>>>>>>>>>>>>>>>>.


功能性服务，到原子服务和服务构件，到顶层的业务流程服务，目的是最大限度地封装不同的服务，从而达到复用的目的


1,可见SOA架构是一个分层的结构
2,SOA概念是企业服务总线（Enterprise Service Bus, ESB）。将服务组装成业务流程是目标，但是应该如何实现？点到点的连接是一个方式，可是这种方式增加了系统的复杂度，并降低了服务的可重用性。为了实现真正的SOA，我们需要一个中间层，来完成服务交互、组装、管理的功能。这就是ESB产生的缘由。ESB采用的是总线的概念，支持服务的即插即用，以消息流转为沟通方式，以标准为基础，可以跨平台、跨技术（如图1-3所示）。形象地来讲，ESB像一条流动的河流，承载着不同的船只（数据）到达相应的码头。




这样一个以服务为核心的体系架构可以提供松耦合、异构的企业级计算环境




SOA可能并非一场革命，而是一种转变，现有的系统也要参与其中，使现有资产合理重用是一个重要的考虑。


可见，SOA并非一蹴可就的，需要全局的思考和准备。但是SOA的实施是可以渐进式的，既有系统可以逐步改造，新的服务可以按需添加，这也是以服务为基础的架构的优点。从小处入手，从长远考虑，这些投资的回报是十分客观的。






SOA的技术必然建立在标准之上——只有做到了“书同文，车同轨”，才能够进行真正意义上的业务整合。在此基础上，有服务运行环境、企业服务总线（ESB）、服务注册和管理工具、流程引擎等SOA计算环境所需要的主要组件。同时，还会有业务活动监控（Business Activity Monitoring，BAM）和业务绩效管理（Business Performance Management，BPM）等方面


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
服务


搭建大厦的砖石，建造航空母舰的“乐高积木”，需要谨慎的选择。服务需要是标准化的，是可以自描述的，是可以组装的，并能够隔离业务功能和具体实现




数据/消息模型


大厦电路中的电流和水管中流动的水流，有了这些资源，一个现代化的大厦才能够真正“活”起来。数据就是客户的“钱”，是服务的目的——准确、迅捷地传送数据。因此，一个好的数据模型可以事半功倍。




服务编排和流程引擎


大厦的设计图纸，用来将已有的服务组装起来定义真正的业务流程。敏捷是对服务编排的一个重要要求。服务编排同时要提供相应的事务管理、流程状态管理、出错处理等支持功能。












>>>>>>>>.服务是可以独立操作的 服务是自描述的 >>>>>>>>>>>>>>>>>>>>
服务是可以独立操作的。每一个服务都能够提供相应的操作，能够很容易地被独立调用，其执行并不依赖于架构中的其他组件和服务。操作是通过标准方式封装和发布的。


服务是自描述的。其使用标准的描述格式定义了服务提供的操作和消息格式，无论调用者和被调用者都无需关心其他信息，如地址、实现技术等。


服务是松耦合和异构的。服务的使用者和提供者可以是分布部署的，可以位于不同的系统平台上，可以使用不同的技术实现。


服务是可组合的。使用相应的服务组装技术，例如流程编排技术，可以将多个简单的服务组装成一个更加复杂的服务。这一过程是可递归的。这一特性极大地提高了服务的灵活度和计算能力。


服务是动态的。已发布的服务是可以被动态发现和绑定。


服务是标准和开放的。只有在标准的基础上，企业中不同部门或者不同供应商的服务才能够动态地组织到一起提供业务流程。供应商的独立性和互通性是服务的目标。这样才能真正实现理想的“天下大同”。


服务可以包装已有的应用或组件。这一特性使得服务的领域变得更加广泛，并且可以使现有资产可被重用，保护已有IT投资。


服务是有质量保障（QoS）的。






服务是可以自描述并独立注册发布的。在一个服务请求者需要使用某个特定业务功能的服务时，可以先在服务管理者，即服务注册中心中发现符合要求的服务——可能得到一个服务列表，因为不同的供应商会提供同一服务（这也是一种竞争）。服务请求者可以根据需要决定使用哪一个服务，也就是服务绑定，然后就理所应当地使用选定的服务了。




参考：http://book.51cto.com/art/200805/74031.htm