不同厂商或个人对SOA有着不同的理解，但是我们仍然可以从上述的定义中看到SOA的几个关键特性：

一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。
 

SOA的基本特征

1可从企业外部访问

通常被称为业务伙伴的外部用户也能像企业内部用户一样访问相同的服务。业务伙伴采用先进的B2B协议（ebXML或RosettaNet）相互合作。当业务伙伴基于业务目的交换业务信息时，他们就参与了一次会话。会话是业务伙伴间一系列的一条或多条业务信息的交换。会话类型（会话复杂或简单、长或短等）取决于业务目的。

除了B2B协议外，外部用户还可以访问以Web服务方式提供的企业服务

2 随时可用

　　当有服务使用者请求服务时，SOA要求必须有服务提供者能够响应。大多数SOA都能够为门户应用之类的同步应用和B2B之类的异步应用提供服务。同步应用对于其所使用的服务具有很强的依赖性。

　　许多同步应用通常部署在前台，其最终用户很容易受到服务提供者短缺的影响。很多情况下，同步应用利用分布式服务提供者，这样可以响应更多的用户请求。但是，随着提供特定服务功能的服务器数量的增长，出现短缺的可能性也呈指数级上升。

　　当相比之下，异步应用要更为稳健，因为其采用队列请求设计，因此可以容许出现服务提供者短缺或迟滞的情况。异步应用大多数情况下部署在后台，用户通常不会觉察到短暂的短缺。大部分情况下异步应用能够稳健应对短时间短缺，但是长时间短缺则会引发严重问题。在服务短缺解决、队列引擎将罕见的大量工作推到共享的应用资源中时，可能会出现队列溢出甚至服务死锁。

　　服务使用者要求提供同步服务时，通常是基于其自身理解或使用习惯。在多数情况下，采用异步模型可以达到同样的效果，但更能够体现SOA的最佳特性。

　　当然，并不是所有情况下都应当采用异步设计模式。但大多数情况下，异步消息可以确保系统在不同负荷下的伸缩性，在接口响应时间不是很短时尤其如此。

　　3  粗粒度服务接口

　　粗粒度服务提供一项特定的业务功能，而细粒度服务代表了技术组件方法。举个例说明最为清楚??向计费系统中添加一个客户是典型的粗粒度服务，而你可以使用几个细粒度服务实现同一功能，如：将客户名加入到计费系统中，添加详细的客户联系方式、添加计费信息等等。

　　采用粗粒度服务接口的优点在于使用者和服务层之间不必再进行多次的往复，一次往复就足够。Internet环境中有保障的TCP/IP会话已不再占据主导、建立连接的成本也过高，因此在该环境中进行应用开发时粗粒度服务接口的优点更为明显。

　　除去基本的往复效率，事务稳定性问题也很重要。在一个单独事务中包含的多段细粒度请求可能使事务处理时间过长、导致后台服务超时，从而中止。与此相反，从事务的角度来看，向后台服务请求大块数据可能是获取反馈的唯一途径。

　　4 分级

　　一个关于粗粒度服务的争论是此类服务比细粒度服务的重用性差，因为粗粒度服务倾向于解决专门的业务问题，因此通用性差、重用性设计困难。解决该争论的方法之一就是允许采用不同的粗粒度等级来创建服务。这种服务分级包含了粒度较细、重用性较高的服务，也包含粒度较粗、重用性较差的服务。

　　在服务分级方面，须注意服务层的公开服务通常由后台系统（BES's）或SOA平台中现有的本地服务组成。因此允许在服务层创建私有服务是非常重要的。正确的文档、配置管理和私有服务的重用对于IT部门在SOA服务层快速开发新的公开服务的能力具有重要影响。

　　5  松散耦合

　　SOA具有“松散耦合”组件服务，这一点区别于大多数其他的组件架构。该方法旨在将服务使用者和服务提供者在服务实现和客户如何使用服务方面隔离开来。

　　服务提供者和服务使用者间松散耦合背后的关键点是服务接口作为与服务实现分离的实体而存在。这是服务实现能够在完全不影响服务使用者的情况下进行修改。

　　大多数松散耦合方法都依靠基于服务接口的消息。基于消息的接口能够兼容多种传输方式（如HTTP、JMS、TCP/IP、MOM等）。基于消息的接口可以采用同步和异步协议实现，Web服务对于SOA服务接口来讲是一个重要的标准。

　　当使用者调用一个Web服务时，被调用的对象可以是CICS事务、DCOM或CORBA对象、J2EE EJB或TUXEDO服务等，但这与服务使用者无关。底层实现并不重要。

　　消息类Web服务通常是松散耦合和文档驱动的，这要优于与服务特定接口的连接。当客户调用消息类Web服务时，客户通常会发送的是一个完整的文档（如采购订单），而非一组离散的参数。Web服务接收整个文档、进行处理、而后可能或者不会返回结果信息。由于客户和Web服务间不存在紧密耦合请求响应，消息类Web服务在客户和服务器间提供了更为松散的耦合。

　　6  可重用的服务及服务接口设计管理

　　如果完全按照可重用的原则设计服务，SOA将可以使应用变得更为灵活。可重用服务采用通用格式提供重要的业务功能，为开发人员节约了大量时间。设计可重用服务是与数据库设计或通用数据建模类似的最有价值的工作。由于服务设计是成功的关键因此，因此SOA实施者应当寻找一种适当的方法进行服务设计过程管理。

　　服务设计管理根本上讲是服务设计问题，服务设计需要在两点间折衷??走捷径的项目战术与企业构建可重用通用服务的长期目标。

　　超越项目短期目标进行服务接口的开发和评估是迈向精确定义服务接口的重要一步，同时还需要为接口文档、服务实现文档及所有重要的非功能性特征设立标准。
在大型组织中实现重用的一个先决条件是建立通用（设计阶段）服务库和开发流程，以保证重用的正确性和通用性。此外，对记述服务设计和开发的服务文档进行评估也是成功利用服务库的关键。

　　简言之，不按规则编写服务将无法保证可提供重用性的SOA的成功实施。在执行规则的过程中会产生财务费用，需要在制定SOA实施计划时加以考虑。

　　7  标准化的接口

　　近年来出现的两个重要标准XML和Web服务增加了全新的重要功能，将SOA推向更高的层面，并大大提升了SOA的价值。尽管以往的SOA产品都是专有的、并且要求IT部门在其特定环境中开发所有应用，但XML和Web服务标准化的开放性使企业能够在所部署的所有技术和应用中采用SOA。这具有巨大的意义！

　　Web服务使应用功能得以通过标准化接口（WSDL）提供，并可基于标准化传输方式（HTTP和JMS）、采用标准化协议（SOAP）进行调用。例如，开发人员可以采用最适于门户开发的工具轻松创建一个新的门户应用，并可以重用ERP系统和定制化J2EE应用中的现有服务，而完全无须了解这些应用的内部工作原理。采用XML，门户开发人员无须了解特定的数据表示格式，便能够在这些应用间轻松地交换数据。
你也可以不采用Web服务或XML来创建SOA应用，但是这两种标准的重要性日益增加、应用日趋普遍。尽管目前只有几种服务使用者支持该标准，但未来大多数的服务使用者都会将其作为企业的服务访问方法。

　　8  支持各种消息模式

　　SOA中可能存在以下消息模式。在一个SOA实现中，常会出现混合采用不同消息模式的服务。

　　﹡无状态的消息。使用者向提供者发送的每条消息都必须包含提供者处理该消息所需的全部信息。这一限定使服务提供者无须存储使用者的状态信息，从而更易扩展。

　　﹡有状态的消息。使用者与提供者共享使用者的特定环境信息，此信息包含在提供者和使用者交换的消息中。这一限定使提供者与使用者间的通信更加灵活，但由于服务提供者必须存储每个使用者的共享环境信息，因此其整体可扩展性明显减弱。该限定增强了服务提供者和使用者的耦合关系，提高了交换服务提供者的服务难度。

　　﹡等幂消息。向软件代理发送多次重复消息的效果和发送单条消息相同。这一限定使提供者和消费者能够在出现故障时简单的复制消息，从而改进服务可靠性。

　　9  精确定义的服务接口

　　服务是由提供者和使用者间的契约定义的。契约规定了服务使用方法及使用者期望的最终结果。此外，还可以在其中规定服务质量。此处需要注意的关键点是，服务契约必须进行精确定义。

　　META将SOA定义为：“一种以通用为目的、可扩展、具有联合协作性的架构，所有流程都被定义为服务，服务通过基于类封装的服务接口委托给服务提供者，服务接口根据可扩展标识符、格式和协议单独描述。”该定义的最后部分表明在服务接口和其实现之间有明确的分界。

首先SOA更接近一种思想 而ejb更接近一种技术
就好像你可以说J2EE WITHOUT EJB 但是不你能说 J2EE without 设计模式 一样

基于SOA构建的系统号称是encapsulation, loose coupling, contract, granularity, reusability, composability, interoperability...

SOA其实就是"解耦"思想的延续, 只要你无法证明软件中的"解耦"是错误的,那么你就很难证明SOA是错误的
目前各大厂商忽悠的不是SOA本身. 而是因为这种思想本身可以说是无懈可击, 你喜欢小品的话,可以套用那句"EJB是一根筋, SOA现在是两头堵"

例如有的厂商鼓出ESB 有的鼓吹面向构件 ,另外SOA由于太正确 太宏观了,所以他下面又引出了很多名词术语 SDO DAS SOC ....等等,
而每个名词背后都蕴藏着一片很大的市场.所以厂商们忽悠的是那些市场 而不是SOA本身.

所以 我对SOA的观点是:
SOA是正确的伟大的但是不具体的.
它未来的命运决定于围绕SOA开发出的产品.而这个产品到底是出自IBM ORACLE 普元 还是其他,这个目前我们只能拭目以待.

我觉得任何技术的出现都必须体现出易用性，SOA的出现，概念上提出了以服务为中心的体系架构，
并从三大方面：前端整合(门户)，数据整合,还有流程整合加以阐述，但是根据我最近做的一个SOA的项目来说(姑且称之为SOA)，

SOA叫做面向服务的架构，从广义的概念上来说，是现在软件发展的趋势。
比方说Facebook的开放性平台，Rails提倡的REST架构，以及用Rails的REST提供开放API的twitter网站，
甚至Amazon，Google这些开放服务的平台等等，本质上都是“面向服务的架构”。

但是狭义的放到企业应用领域，可能特指的是企业各种异构系统的整合，
以及要求新系统能够以符合统一标准的方式来开发。从这个意义上来说，
从传统的EDI，到ESB，组件化，Web服务，到现在的SOA，
都是同一条路线走下来的，所不同者不过是引入了不同时代的技术方案和标准而已。
-------------------------------------------------------------------------
说到底是要异构集成，但为什么要异构集成？异构集成能解决多少问题？
一个非要说汉语，一个非要说英语，再加上个说日语的，效率再怎么也高不了。

为什么不能同构？
有了统一的TCP-IP，大家才可以舒舒服服互连互通；有了html，大家才可以舒舒服服照章办事。
数据可以用XML来统一，业务逻辑和服务调用呢？成百上千的语言和技术成天在瞎折腾呢。
于是什么SOA、SOAP、REST跳出来忽悠了，可忽悠到最后能解决多少问题？只怕是带来的问题更多。

说的极端点，业务层就该统一用开发效率和运行效率达到最佳平衡的JavaBean重写了，天下也就太平了。
还想折腾的，表示层玩去吧。
----------------------------------------------------------------------------------------------
soa更多的是为了配合商业流程的快速重构和应对多变的商业环境的产物。这个事情企业的流程是柔性的，风格是多样化的，
服务的对象也是非格式化的。也就是说昨天的那种大规模生产，大规模铺货，大规模销售的模式，已经让位为——更加强调客户定制，
更加有针对性的小区域和小群体铺货，更加针对性的销售，一句话就是更加具有服务的针对性。在这样的情况下，
企业即便希望开发一套新系统来满足这样的要求，也会面临许多需要能够更多可以定制，可以快速伸缩性部署，
可以更加有效益的信息流转，更加紧密的多流程协调一致的新系统。这样的系统不仅仅需要健壮，也需要数据和部署以及维护和改变的更加灵活快速。
而实施soa的前提条件是必须具有强大的企业业务分析能力和再造能力，已经对支撑此应用对系统要求的测算能力。
只有具备了这样的业务分析能力，才能把握住企业运转的真实流程；只有具备这样的再造能力，才能形成一种柔性的企业生态系统；
只有具备这样的测算能力，才能把握住企业信息建设的关键环节的约束性指标。
而技术的实现仅仅是在前面这些关键性工作驱动下的一种实现的手段，具体的方式可以多种多样。
但是其成本构成和资源的配置必须要能够合乎关键环境的约束性指标。
可以说soa更加看重的是企业对信息系统的规划能力，是企业高层的战略考量的一种在信息系统建设方面的考量。
而其针对开发人员的内容相对较少，针对软件公司的技术内容也相对较少。
----------------------------------------------------------------------------------------------
就soa来说，不管如何搞，如何做，都是要以业务为主线，以流程为线索，以技术为辅助。
---------------------------------------------------------------------------------
soa95%以上的工作是在做业务流程的分析解构和重整，技术层面的支持只占5%不到。
这点同ERP类似，也就是你那个产品和开发能力在这个事情上根本就是最最不重要的那个部分，想靠这个打开局面简直就是开玩笑。
---------------------------------------------------------------------------------
soa的基础思想在技术上的要求是能够把各种异构的资源，以一种通用的形式展现和协调起来，
从而形成一种能够在技术上比较便宜的组织和部署方式。在这个领域只有那些有深厚用户基础的公司，才可能有机会进入
---------------------------------------------------------------------------------
其实soa所要求的不是首先你们去提客户考虑，而是要首先要客户有一种将业务流程解构为元流程要素和进行再工程重装的思想，
是一种客户思维方式的变革。也就是说首先要叫客户改变他们对业务的看法，对流程的看法，而不是叫他们给你们提需求。
这也就是为什么soa的重点在业务咨询，而不是技术实现的根本所在。而可以说如果你们能有这样的能力，你们这些做开发的就可有可无了。
---------------------------------------------------------------------------------
soa更多的是一种商业技术，而不是软件开发技术。
而就如同dlee那erp跟soa做对比，我认为今天的soa实际上是具有悠久历史的mis的一种发展。
而我们现在来分析一下真正推行soa见到成效的企业的例子，其实也就是IBM、甲骨文和SAP这些即有技术背景，
同时又有强大的商业咨询能力的公司。而普元之类的公司，只能算作跳梁小丑一样的二角色，在忽悠罢了。
而实际上如果你有时间重读我当初的话，里面就已经阐述清楚了，soa更多的是为了配合商业流程的快速重构和应对多变的商业环境的产物。
这个事情企业的流程是柔性的，风格是多样化的，服务的对象也是非格式化的。也就是说昨天的那种大规模生产，大规模铺货，
大规模销售的模式，已经让位为——更加强调客户定制，更加有针对性的小区域和小群体铺货，更加针对性的销售，
一句话就是更加具有服务的针对性。在这样的情况下，企业即便希望开发一套新系统来满足这样的要求，
也会面临许多需要能够更多可以定制，可以快速伸缩性部署，可以更加有效益的信息流转，更加紧密的多流程协调一致的新系统。
这样的系统不仅仅需要健壮，也需要数据和部署以及维护和改变的更加灵活快速。
而实施soa的前提条件是必须具有强大的企业业务分析能力和再造能力，已经对支撑此应用对系统要求的测算能力。
只有具备了这样的业务分析能力，才能把握住企业运转的真实流程；只有具备这样的再造能力，才能形成一种柔性的企业生态系统；
只有具备这样的测算能力，才能把握住企业信息建设的关键环节的约束性指标。
而技术的实现仅仅是在前面这些关键性工作驱动下的一种实现的手段，具体的方式可以多种多样。
但是其成本构成和资源的配置必须要能够合乎关键环境的约束性指标。
可以说soa更加看重的是企业对信息系统的规划能力，是企业高层的战略考量的一种在信息系统建设方面的考量。
而其针对开发人员的内容相对较少，针对软件公司的技术内容也相对较少。
---------------------------------------------------------------------------------
工作流的思想基础是静态的流程，而现在企业需要的是动态的流程。其实也正是因为流程的高度动态化，和高度的柔性，
才使得soa的必要性凸显出来。也就是现在的企业更加希望提供的是特异性的有针对用户自身情况的个性服务，极端的说就是一个客户一个服务
，一个服务一个流程。而工作流引擎的考虑是把企业现有流程能够更加容易的部署和分配到信息系统中去，是一种静态的思维方式。
------------------------------------------------------------------------------------
SOA中的三大核心技术——BPM/ESB企业服务总线/Webservice
----------------------------------------------------------------------------------------------

SOA的工作流是指跨系统的业务流程，包括人工活动的长流程和自动运行的短流程，同步或异步的流程。SOA的工作流节点是细分到各系统的每一步的具体操作
---------------------------------------------------------------------------------
如果你面对的是成千上万系统的做业务整合的时候，我实在想不出来除了SOA，你怎么去比较合适的规划——不是小打小闹的让两个系统对接，
而是让成千上万个系统对接。（这里面可以问很多问题：比如为什么rpc需要改进，corba需要改进，
rmi需要改进?这些问题本来应该是那些对xmlrpc顶礼膜拜的人能够回答的，只是可惜他们不知就里）
记得dlee曾经就敏捷开发说个一个很让人佩服的话：“我几个月开发一个系统，然后修修改改倒腾3年，
3年以后，重新开发一个新的系统”，可惜这样的标准不能用在SOA的那个S上.
SOA本身就是一个谁都没有搞懂的东西，从最初的吧SOA的那个S当做WebService，到后来SCA,SDO的出现，
显示的都是大家认识上的不足。SCA是什么？他就是一个Spring for WebService,换句话说就是一堆按着Spring风格配置的Webservice,SDO更搞笑，
你甚至可以直接认为它就是基于数据库层的共享，当然安全，性能调谐等方面就无从谈起。
直到后来终于大家意识到服务分层的出现，意识到标准消息的问题，于是才有了点样子，有了个ESB（本人不保证技术出现的前后相续问题，
没有兴趣考古，也实在太乱了），但是也就仅限于此了，有那么比较关键的几点：业务分层原理，没有谁提出个标准包括IBM,BEA,ORACLE,
我知道国内倒是有几家公司各个各自的做法，靠谱，但是明显的理论修养不够，（当然不包括普元，我没有在普元工作过，也没有听到普元的某个人提起过，
于是我大胆的猜测，普元甚至连这里也没有），一个是业务的发布，UDDI那个东西被证明实际应用中用处不大，新的标准又没有出来
，有些公司采用的是业务路由，可惜仅仅是自己的实现，一个是标准消息的流通渠道，ESB是以总线方式布置的，但是总线方式是不是最好的，
能不能解决所有的问题，谁也说不准。（当然，这仅仅是本人的一些看法，不负任何责任）
说到spring+hibernate,SOA设计面对的原子对象是各层次级别的业务服务，根本就不直接和数据库打交道，你用hibernate干啥？
spring那个没有性能管理的东西，真的能够大小通吃么？
----------------------------------------------------------------------------------------------