SOA的一些认识
SOA很早以前就听说过，但是不是很熟，最近有时间研究下，给出一些自己的认识和知识的总结。
SOA：面向服务架构。其本质上是一种将系统模型和系统实现相分离。为什么会分离呢？引导分离的因素就是需求(众所周知，在项目中需求的变更无疑是给项目增大了很大的风险)。SOA本身是一个组件模型，它将应用程序的不同功能单元---服务（service）。通过服务间定义良好的接口和约定联系起来。接口采用中立的方式定义，独立于具体实现服务的硬件平台、操作系统和编程语言，使得构建在这样的系统中的服务可以使用统一和标准的方式进行通信。这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。
SOA不是一种具体的技术，也是一种产品更不是一种语言，它是一种软件系统架构。更确切的说它是一种架构理念。
SOA中强调的是服务(Service)它的基本元素也是服务。很多时候你可以将设计和实现出来的软件称为服务品。SOA指定一组实体(服务的提供者、服务消费者、服务注册、服务条款、服务代理等)这些实体详细的描述了如何来提供和消费服务。而这些服务是可互操作、独立、模块化、位置明确、松耦合并且可以通过相关途径查找得到。
以下是在一些资料找看到和学习到的SOA的三种角色的关系。
服务时一个自包含的、无状态的实体，可以由多个组件组成。它通过事先定义的界面响应服务请求。它也可以执行诸如编辑和处理事务等离散任务。服务本身并不依赖其他函数和过程的状态。
服务提供者(serviceprovider)提供符合约定的服务，并将它们发布到服务代理。
服务请求者(serviceconsumer)它发现并调用其他的软件服务来提供解决方案。
服务代理者(servicebroker)产生由服务提供者发布的软件接口。
这三种SOA参与者：服务提供者、服务代理者以及服务请求者通过3个基本操作：发布（publish）、查找（find）、绑定（bind）相互作用。服务提供者向服务代理者发布服务。服务请求者通过服务代理者查找所需的服务，并绑定到这些服务上。服务提供者和服务请求者之间可以交互。
所谓服务的无状态，是指服务部依赖任何事先设定的条件，是状态无关的(state-free)。在SOA架构中，一个服务不会依赖于其他服务的状态。它们从客户端接受服务请求。因为服务时无状态的，它们可以被组合、编排、序列化成多个不同序列，来执行逻辑。
SOA的一些特征：
服务的封装(encapsulation).将服务封装成用于业务流程的可重用组件的应用程序函数。它提供信息或简化业务数据从一个有效的、一致的状态向另一个状态的转变。封装隐藏了复杂性。服务的API保持不变，使得用户远离具体实施上的变更。
服务的重用（reuse）。服务的可重用性设计显着地降低了成本。为了实现可重用性，服务只工作在特定处理过程的上下文（context）中，独立于底层实现和客户需求的变更。
·服务的互操作（interoperability）。互操作并不是一个新概念。在CORBA、DCOM、webservice中就已经采用互操作技术了。在SOA中，通过服务之间既定的通信协议进行互操作。主要有同步和异步两种通信机制。SOA提供服务的互操作特性更利于其在多个场合被重用。
·服务是自治的（Autonomous）功能实体。服务是由组件组成的组合模块，是自包含和模块化的。
SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术，如。NETRemoting，EJB，COM或者CORBA，都需要有一个宿主（Host或者Server）来存放和管理这些功能实体；当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问题的时候，在该宿主上运行的其它应用服务就会受到影响。
SOA架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术，比如事务处理（Transaction），消息队列（MessageQueue），冗余部署（RedundantDeployment）和集群系统（Cluster）在SOA中都起到至关重要的作用。
·服务之间的松耦合度（LooslyCoupled）。服务请求者到服务提供者的绑定与服务之间应该是松耦合的。这就意味着，服务请求者不知道提供者实现的技术细节，比如程序设计语言、部署平台，等等。服务请求者往往通过消息调用操作，请求消息和响应，而不是通过使用API和文件格式。
这个松耦合使会话一端的软件可以在不影响另一端的情况下发生改变，前提是消息模式保持不变。在一个极端的情况下，服务提供者可以将以前基于遗留代码（例如，COBOL）的实现完全用基于Java语言的新代码取代，同时又不对服务请求者造成任何影响。这种情况是真实的，只要新代码支持相同的通信协议。
·服务是位置透明的（locationtransparency）。服务是针对业务需求设计的。需要反应需求的变化，即所谓敏捷（agility）设计。要想真正实现业务与服务的分离。就必须使得服务的设计和部署对用户来说是完全透明的。也就是说，用户完全不必知道响应自己需求的服务的位置，甚至不必知道具体是哪个服务参与了响应。
[b]三个抽象级[/b]
从概念上讲，SOA中有三个主要的抽象级别：
·操作：代表单个逻辑工作单元（LUW）的事务。执行操作通常会导致读、写或修改一个或多个持久性数据。SOA操作可以直接与面向对象（OO）的方法相比。它们都有特定的结构化接口，并且返回结构化的响应。完全同方法一样，特定操作的执行可能涉及调用附加的操作。
·服务：代表操作的逻辑分组。服务可以分层，以降低耦合度和复杂性。一个服务的粒度（granularity）大小也与系统的性能息息相关。粒度太小，会增加服务间互操作通讯的开销；粒度太大，又会影响服务面对需求变化的敏捷性。
·业务流程：为实现特定业务目标而执行的一组长期运行的动作或活动。业务流程通常包括多个业务调用
在SOA中，业务流程包括依据一组业务规则按照有序序列执行的一系列操作。操作的排序、选择和执行称为服务或流程编排。典型的情况是调用已编排服务来响应业务事件。从建模的观点来看，由此带来的挑战是如何描述设计良好的操作、服务和流程抽象的特征以及如何系统地构造它们。这些涉及服务建模、特征抽取的问题已经成为现阶段人们关注的焦点。