soa什么是SOA?

什么是SOA

SOA，即 Service Oriented Architecture, 是计算机系统软件设计中的一种面向服务的体系结构。

SOA中解决的问题就是应用程序的不同的业务功能单元，即服务的复用问题，强调服务调用者和服务提供者之间通过标准的契约来实现调用，推崇服务的重用。

同时，SOA又着力于架构体系，强调技术的中立性，体系的完整性。

一些诸如Web Service、REST、XML、BPMN等标准，都是SOA中经常出现的关键字。

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界的用户和供应商共同促进。

中国信息化需要什么样的技术架构、能够接受什么样的成本价位？这不仅仅是我们的客户需要考虑，我们软件厂商要比客户考虑得更清楚、更进一步。

在这个充满变数的激烈竞争市场，只有冷静务实才能生存、发展。

什么是SOA?

SOA 的生命周期 　由于soa涉及到业务的诸多方面，因此需要从一开始就对 SOA 项目进行细心的规划和设计。

您需要考虑项目的整个生命周期，从最初的阶段到第一个实现，再一直到可能的修订和重用。

　　现在让我们看看 SOA 生命周期，如图 1 中所示。

此部分概略说明了在生命周期的各个阶段发生的事项，并详细介绍了实现生命周期的各个步骤。

　　　　 图 1. SOA 生命周期 　　建模 　　面向服务的体系结构项目的第一步几乎和技术没有任何关系，所有事项都与您的业务相关。

请记住，面向服务的方法将业务所执行的活动视为服务，因此第一步是要确定这些业务活动或流程实际是什么。

对您的业务体系结构进行记录，这些记录不仅可以用于规划 SOA，还可以用于对实际业务流程进行优化。

通过在编写代码前模拟或建模业务流程，您可以更深入地了解这些流程，从而有利于构建帮助执行这些流程的软件。

　　建模业务流程的程度将依赖于预期实现的深度。

另外，这个程度还依赖于您在开发发团队中担任的角色。

如果您是企业架构师，您将会对实际的业务服务进行建模。

如果您是软件开发人员，您将可能对单个服务进行建模。

　　组装 　　对业务流程进行了建模和优化后，开发人员可以开始构建新的服务和/或重用现有的服务，然后对其进行组装以形成组合应用程序，从而实现这些流程。

在“建模”步骤中，您已经确定了需要何种类型的服务以及它们将访问何种类型的数据。

已经存在某种形式的实现这些服务或访问该类数据所需的一些软件。

“组装”步骤将要找到已经存在的功能，并为其添加服务支持。

另外，还涉及到创建提供功能和访问数据源所需的新服务，以便满足您的 SOA 涉及的业务流程范围内的需求。

　　部署 　　进行了建模和组装后，要将组成 SOA 的资产部署到安全的集成环境中。

此环境本身提供专门化的服务，用于集成业务中涉及的人员、流程和信息。

这种级别的集成可帮助确保将公司的所有主要元素连接到一起协同工作。

此外，部署工作还需要满足业务的性能和可用性需求，并提供足够的灵活性，以便吸纳新服务（并使旧服务退役），而不会对整个系统造成大的影响。

　　管理 　　系统就位，一切都正常运行。

现在您可以对一切放手不管了，对吗？不对。

部署后，需要从 IT 和业务两个角度对您的系统进行管理和监视。

在“管理”步骤中收集的信息用于帮助实时地了解业务流程，从而能更好地进行业务决策，并将信息反馈回生命周期，以进行持续的流程改进工作。

您将需要处理服务质量、安全、一般系统管理之类的问题。

　　在本步骤中，您将监视和优化系统，发现和纠正效率低下的情况和存在的问题。

由于 SOA 是一个迭代过程，因此，在此步骤中，您不仅要找出技术体系结构中有待改进之处，而且还要找出业务体系结构中有待改进之处。

　　完成此步骤后就要开始新的“建模”步骤了。

在“管理”步骤中收集的数据将用于重复整个 SOA 生命周期，再次进行整个过程。

　　控制 　　SOA 是一种集中系统；其中可以包含来自组织的不同部门的服务，甚至还能包含来自组织外的服务。

如果没有恰当的控制，这种系统很容易失控。

　　控制对所有生命周期阶段起到巩固支撑作用，为整个 SOA 系统提供指导，并有助于了解系统全貌。

它提供指导和控制，帮助服务提供者和使用者避免遇到意外情况。