‘壹’ 什么是SOA
面向服务的体系结构（service-oriented architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。
对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（On demand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。
虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA），它已经出现很长时间了，其定义的概念与 SOA 相似。
然而，现在的 SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（eXtensible Markup Language，XML）为基础的。通过使用基于 XML 的语言（称为 Web 服务描述语言（Web Services Definition Language，WSDL））来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前 CORBA 中的接口描述语言（Interface Definition Language，IDL）可比了。
Web 服务并不是实现 SOA 的惟一方式。前面刚讲的 CORBA 是另一种方式，这样就有了面向消息的中间件（Message-Oriented Middleware）系统，比如 IBM 的 MQseries。但是为了建立体系结构模型，您所需要的并不只是服务描述。您需要定义整个应用程序如何在服务之间执行其工作流。您尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。因此，SOA 应该能够将业务的商业流程与它们的技术流程联系起来，并且映射这两者之间的关系。例如，给供应商付款的操作是商业流程，而更新您的零件数据库，以包括进新供应的货物却是技术流程。因而，工作流还可以在 SOA 的设计中扮演重要的角色。
此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括与不为您控制的外部合作伙伴进行的操作。因此，为了提高效率，您需要定义应该如何得知服务之间的关系的策略，这种策略常常采用服务级协定和操作策略的形式。
最后，所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的条款来执行流程。因此，安全、信任和可靠的消息传递应该在任何 SOA 中都起着重要的作用。
我可以用面向服务的体系结构做什么？
对 SOA 的需要来源于需要使业务 IT 系统变得更加灵活，以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现，IT 系统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。
下面举一个具体的例子。一个服装零售组织拥有 500 家国际连锁店，它们常常需要更改设计来赶上时尚的潮流。这可能意味着不仅需要更改样式和颜色，甚至还可能需要更换布料、制造商和可交付的产品。如果零售商和制造商之间的系统不兼容，那么从一个供应商到另一个供应商的更换可能就是一个非常复杂的软件流程。通过利用 WSDL 接口在操作方面的灵活性，每个公司都可以将它们的现有系统保持现状，而仅仅匹配 WSDL 接口并制订新的服务级协定，这样就不必完全重构它们的软件系统了。这是业务的水平改变，也就是说，它们改变的是合作伙伴，而所有的业务操作基本上都保持不变。这里，业务接口可以作少许改变，而内部操作却不需要改变，之所以这样做，仅仅是为了能够与外部合作伙伴一起工作。
另一种形式是内部改变，在这种改变中，零售组织现在决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店，这可以看作是采用店中店（store-in-store）的业务模型。这里，虽然公司的大多数业务操作都保持不变，但是它们现在需要新的内部软件来处理这样的出租安排。尽管在内部软件系统可以承受全面的检修，但是它们需要在这样做的同时不会对与现有的供应商系统的交互产生大的影响。在这种情况下，SOA 模型保持原封不动，而内部实现却发生了变化。虽然可以将新的方面添加到 SOA 模型中来加入新的出租安排的职责，但是正常的零售管理系统继续如往常一样。
为了延续内部改变的观念，IT 经理可能会发现，软件的新配置还可以以另外的一种方式加以使用，比如出租粘贴海报的地方以供广告之用。这里，新的业务提议是通过在新的设计中重用灵活的 SOA 模型得出的。这是来自 SOA 模型的新成果，并且还是一个新的机会，而这样的新机会在以前可能是不会有的。
垂直改变也是可能的，在这种改变中，零售商从销售他们自己的服装完全转变到专门通过店中店模型出租地方。如果垂直改变完全从最底层开始的话，就会带来 SOA 模型结构的显着改变，与之一起改变的还可能有新的系统、软件、流程以及关系。在这种情况下，SOA 模型的好处是它从业务操作和流程的角度考虑问题而不是从应用程序和程序的角度考虑问题，这使得业务管理可以根据业务的操作清楚地确定什么需要添加、修改或删除。然后可以将软件系统构造为适合业务处理的方式，而不是在许多现有的软件平台上常常看到的其他方式。
正如您可以看到的，在这里，改变和 SOA 系统适应改变的能力是最重要的部分。对于开发人员来说，这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生，这取决于是否有改变需要知道接口是如何定义的以及它们相互之间如何进行交互。与开发人员不同的是，架构师的作用就是引起对 SOA 模型大的改变。这种分工，就是让开发人员集中精力于创建作为服务定义的功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起，它已经有十多年的历史了，通常用统一建模语言（Universal Modeling Language，UML），并且描述成模型驱动的体系结构（Model-Driven Architecture，MDA）。
‘贰’ soa是什么，先评一下我的理解
拨开SOA的面纱
--------------------------
发布时间:2006-03-20 08:03:09 作者:ever2004 出处:softhouse 语言:中文 阅读次数:8984次
内容简介
SOA是英文Service-Oriented Architecture，即面向服务架构的缩写。这个词汇最近一两年频频出现在各种技术期刊上。但是一直以来对于 SOA到底是什么没有明确的回答；SOA有什么特点？适合用于解决哪些问题？与其他的技术有什么区别与联系？Web Service和SOA又是什么关系 ？SOA的出现对于软件架构设计有什么影响？本文将就上面提到的这些问题，尝试根据作者自己的理解给出SOA的定义；总结出SOA特有的三个基 本特征；然后以HTTP协议为例对这些特征进行解释；最后简要的说明SOA对今后软件架构设计可能带来的影响。
SOA定义
下面是作者给SOA下的一个定义：SOA是指为了解决在Internet环境下业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种 软件系统架构。从这个定义中我希望表达的前提有下面两点：
1) 软件系统架构：SOA不是一种语言，也不是一种具体的技术而是一种软件系统架构，它尝试给出在特定环境下推荐采用的一种架构，从这 个角度上来说，它更像一种模式(Pattern)。因此它与很多已有的软件技术比如面向对象技术，是互补的而非互斥的。它们分别面向不同的应用 场景，用来满足不同的特定需求。
2) SOA的使用范围：需求决定同时也限制功能。SOA并不是包治百病的万灵丹，它最主要的应用场合在于解决在Internet环境下的不同商业 应用之间的业务集成问题。在下面我们会详细讨论Internet的各种特点如何决定SOA的特点，这里我们只需要先简单回顾一下Internet环境区别 于Intranet环境的几个特点：
a) 大量异构系统并存，计算机硬件工作方式不同，操作系统不同、编程语言也不同；
b) 大量、频繁的数据传输仍然速度缓慢并且不稳定；
c) 版本升级无法完成，我们根本就无法知道互联网上有哪些机器直接或者间接的使用某个服务。
基于上面的前提，下面就让我们一起看一下SOA的基本特征。
SOA三大基本特征
1 独立的功能实体
在Internet这样松散的使用环境中，任何访问请求都有可能出错，因此任何企图通过Internet进行控制的结构都会面临严重的稳定性问题。 SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术，如.NET Remoting，EJB，COM或者CORBA，都需要有一个宿主 (Host或者Server)来存放和管理这些功能实体；当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问 题的时候，在该宿主上运行的其它应用服务就会受到影响。
SOA架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术，比如事务处理(Transaction)，消息队列(Message Queue) ，冗余部署(Rendant Deployment)和集群系统(Cluster)在SOA中都起到至关重要的作用。
2 大数据量低频率访问
对于.NET Remoting，EJB或者XML-RPC这些传统的分布式计算模型而言，他们的服务提供都是通过函数调用的方式进行的，一个功能的完成 往往需要通过客户端和服务器来回很多次函数调用才能完成。在Intranet的环境下，这些调用给系统的响应速度和稳定性带来的影响都可以忽 略不计，但是在Internet环境下这些因素往往是决定整个系统是否能正常工作的一个关键决定因素。因此SOA系统推荐采用大数据量的方式一次 性进行信息交换。
3 基于文本的消息传递
由于Internet中大量异构系统的存在决定了SOA系统必须采用基于文本而非二进制的消息传递方式。在COM、CORBA这些传统的组件模型中， 从服务器端传往客户端的是一个二进制编码的对象，在客户端通过调用这个对象的方法来完成某些功能；但是在Internet环境下，不同语言， 不同平台对数据、甚至是一些基本数据类型定义不同，给不同的服务之间传递对象带来的很大困难。由于基于文本的消息本身是不包含任何处 理逻辑和数据类型的，因此服务间只传递文本，对数据的处理依赖于接收端的方式可以帮忙绕过兼容性这个的大泥坑。
此外，对于一个服务来说，Internet与局域网最大的一个区别就是在Internet上的版本管理极其困难，传统软件采用的升级方式在这种松散 的分布式环境中几乎无法进行。采用基于文本的消息传递方式，数据处理端可以只选择性的处理自己理解的那部分数据，而忽略其它的数据， 从而得到的非常理想的兼容性。
HTTP协议：一个典型的SOA实现
每一项新技术都是在一些旧的技术基础上发展出来的。正如XML根本思想来自于在60年代就已经出现的早期标记性语言一样，SOA虽然这两年 才出现，但是它所表达的观念应该说在网络这种分布式系统结构出现不久就已经广泛应用了。例如我们最熟悉的HTTP协议就是一个非常典型的 SOA架构设计。HTTP协议的工作过程简单叙述如下：
1) 客户端，通常是通过浏览器，向服务器端以文本的方式发送一个请求，索取一个Web页面；
‘叁’ SOA到底是什么作用是什么"
对于SOA，目前我听到有两种说法：一种讲它是"颠覆性的革命架构"，一种是"谨慎观望"。但无疑，SOA最近几年发展得非常快，各主要软件厂商纷纷高调跟进，关于SOA的报道可以说是不绝于耳。对"SOA热"，程序员们有的兴奋和期待，有的则感到困惑，最近我在金蝶中间件于广州、上海等城市举行的"Java俱乐部"上和程序员们交流时，他们或是以一种朝圣者的表情说："以前面向对象的技术过时了，SOA时代来了"，或者一再恳切地追问我："
那么，SOA是什么?到底能解决什么问题、解决得怎样?我们和客户都准备好了吗?我给出的答案是"Just Processing，SOA-现在进行中"。SOA到底是什么？SOA（Service-Oriented Architecture）的定义是面向服务的架构，就是说将软件按照功能设计成一个个服务，这些服务用标准的方式定义接口、并通过标准的协议进行调用。SOA所定义的接口和调用方式是独立于编程语言和运行平台的，广义上讲SOA可以基于不同的底层技术实现，比如CORBA和Web Services。但CORBA由于过于复杂和臃肿已很少使用，所以目前所说的SOA绝大多数是基于Web Services技术实现。在Web Services的实现方式下，SOA服务的接口用XML进行定义。在SOA架构下，软件开发从业务流程分析开始，使用组件化业务建模的方法识别和分析各种业务模型，将各种实践融入其中，在这个基础上建立用例，用例直接产生BPEL，这些BPEL则可以被融入一个服务整合框架中，其描述了各种服务的信息，从而把ESB上的各个模块统一起来，形成一个巨大的服务仓。这样，SOA甚至是所有软件人员的一个梦:将中间层再进行抽离，在中间层作一个跨技术架构的元数据和业务逻辑，使之成为跨技术架构的、可长期继承、并不断积累的企业业务库和最宝贵的信息资产，也就是面向服务的组件库，而且这个服务组件库也可以被其它企业复用，且不依赖于任何一种技术架构。夸张一点说，如果所有软件企业都使用SOA架构，那么世界软件业将会发生彻底的改变。显然，这样一个框架不是一种产品，也不仅仅是一种技术，而是一种解决问题的方法论。SOA可能应用的两个场景及现有问题那么，SOA要解决的问题是什么？我认为，从技术本质上讲，SOA可能应用于两个场景：第一种是业务互通互联；第二种是封闭交易系统，即将元数据和业务逻辑抽离，形成可复用。举个例子，在第一种场景中，当不同企业之间的业务需要相互调用，这时就可能采用SOA技术；在第二种场景中，在企业内部需要将系统进行迁移时，利用SOA技术定义的原有数据和业务流程，可以很快完成。无疑，SOA是一个伟大的思想，它试图定义一个大家（各种软件厂商）都"认"的、都"遵循"的法则，大家都使用这样的方法来进行互联互通，从而实现无界限的联通，以及服务组件库的继承和复用，解放无效和重复劳动。打一个不那么恰当的比喻，就像人类的语言一样。SOA或许就像《圣经》中那个着名的"通天塔"的故事：人们用同一种语言交流产生的威力是如此之大，以至于他们在巴比伦几乎要修成一个"通天塔"，直达上帝所在的天庭。但是，在SOA应用的两个场景中，现存的问题同样也是明显的：第一种场景：业务互联互通，就是应用系统互联。业务互联，与其说是技术问题，不如讲是业务问题，例如ERP、CRM的异步整合，数据层面整合都不能很好将两个系统整合，SOA仅仅是一种实现工具之一，整合效果并不会好不到那里去。我们可以说，在没有其他选项之前，SOA是一种最"不坏"的方式，但它并不能解决所有的问题，实际上EAI的牵涉面很广，而我们知道，有些问题并不是单纯靠技术就能解决的。第二种场景：封闭交易系统，缺点是性能慢，而且基于Web Services的交易没有形成明确的规范。使用XML作信息交互比较慢是大家都承认的，性能问题将对SOA的发展造在一定的阻力。同时SOA规范本身没有完善，比如Transaction规范还在不断完善，而且Web Service多年来收效甚微。总的来说，SOA现在还处在一个发展阶段，很多标准还在制定，不同厂商间还存在不兼容的现象，因此SOA还不能说已经是一个成熟的技术，还需要时间的检验，还在"进行中"。当然，金蝶中间件作为JCP组织成员，也会推动SOA规范在J2EE平台上的实现。中国用户的现实选择之惑在憧憬SOA技术可能带来的前景之余，我们不得不回过头来冷静地说：SOA和我们大家的共同客户――中国企业还有距离。中国信息化进程与欧美不同，大量的基础业务系统还没建立起来，整合需求并不如想象的那么大。从我们对客户的了解，发现很少有客户有SOA的需求。简单地总结就是，互通无基础，以新建系统为主，需求并不强烈。而欧美市场大量业务系统已建立起来需要整合，从这个角度讲，SOA是适用于他们的。同时，在成功案例极少的前提下，SOA还处于培育期，新建封闭交易系统使用SOA技术还是有一定风险的。一项新技术需要市场的消化，大型企业出于保护企业投资，不会轻易地转移到新的技术平台；而即使像J2EE这样成熟的技术经过了这么多年的发展，也不敢说占有统治地位的市场份额。SOA还需要整个IT界的用户和供应商共同促进。中国信息化需要什么样的技术架构、能够接受什么样的成本价位？这不仅仅是我们的客户需要考虑，我们软件厂商要比客户考虑得更清楚、更进一步。在这个充满变数的激烈竞争市场，只有冷静务实才能生存、发展。