初识SOA

随着企业级的应用越来越多，企业级应用的整合势在必行，在越来越深入的应用整合中，人们发现要将原有的基于对象的应用整合在一起，简直就是一个灾难！因为不同功能的应用，根本就不能和谐的存在在一起，强制的圈在一起，只会导致冲突，混乱。最终导致应用效率下降，甚至无法使用。为了避免或减小应用之间的冲突，现有最实际的做法就是采用portal来将不同的应用入口整合到一个页面，但是业务流程还是基于每个应用独立的。
在现有情况下，当要对需求有所变化时，我们唯一可以做的就是重新开发整个应用，或者对其进行全面改造。无论是哪一种情况，都会花费大量人力、物力，更要命的是，在我们花费大量时间对其进行改造、或开发后，发现需求随着业务的不断变化，又发生了巨大的变化……

    在这种情况下，一种名为SOA的新的技术构架逐渐被人们所认识和接受。SOA(Service-Oriented Architecture)：才面向服务的体系结构，它是一个组件模型。顾名思义，它是面向服务（应用的不同功能单元）的，它将应用程序的不同功能单元（即服务）通过这些服务之间定义良好的接口和契约联系起来，成为一个应用整体。其中，接口和契约采取中立的方式进行定义，并独立于实现应用的硬件平台，操作系统和编程语言。

    SOA的服务体现了组件之间的松耦合性，松耦合性有以下两大优点：其一是灵活性，组件之间的不同组合与搭配，即能实现业务需求，最大程度上降低了开发的工作量和节约了开发时间；其二是当业务需求发生变化，它能继续存在而不受影响。

在SOA系统中，ESB（Enterprise Service Bus）企业服务总就像一个插线板，不同的业务模块（服务）如同插头，根据需要，灵活的“安插”到ESB上，实现企业的业务需求。这样，当业务需求发生变化的时候，服务能按照需求进行变化和组合，实现按需变化（On Demand）。ESB使用许多可能的消息传递协议来负责适当的控制、流甚至还可能是服务之间所有消息的传输。ESB本身可以是单个引擎，甚至还可以是由许多同级和下级ESB组成的分布式系统，这些ESB一起工作，以保持SOA系统的运行。

 

    其实，SOA早在1996年就被做为一种概念提出了，但因为缺乏一定的技术支持，一直没有形成更加具体的观念和技术。直到XML语言的出现及发展，还有WEB技术的发展，才为SOA提供了根据实际和坚实的理论支持。此外，它还需要安全性，策略管理，可靠消息传递以及会计系统的支持，从而有效地进行工作。你还可以通过分布式事务处理和分布式软件状态管理来进一步得改善它。

    XML自身的特点使其成为SOA系统中，数据流转的最好实现方式，你可以根据你自身的特点，定义自己的XML格式，使之符合你的业务系统需要。而实现SOA模型是通过 HTTP 传递的 SOAP 消息中最常见的SOA模型。因而，从本质上讲，Web是实现SOA的具体方式之一。

面向服务的体系结构（Service-Oriented Architecture，SOA，也叫面向服务架构）是指为了解决在Internet环境下业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

传统的Web（HTML/HTTP）技术有效的解决了人与信息系统的交互和沟通问题，极大的促进了B2C模式的发展。WEB服务(XML/SOAP/WSDL）技术则是要有效的解决信息系统之间的交互和沟通问题，促进B2B/EAI/CB2C的发展。SOA则是采用面向服务的商业建模技术和WEB服务技术，实现系统之间的松耦合，实现系统之间的整合与协同。WEB服务和SOA的本质思路在于使得信息系统个体在能够沟通的基础上形成协同工作。

对于面向同步和异步应用的，基于请求/响应模式的分布式计算来说，SOA是一场革命。一个应用程序的业务逻辑（Business Logic）或某些单独的功能被模块化并作为服务呈现给消费者或客户端。这些服务的关键是他们的松耦合特性。例如，服务的接口和实现相独立。应用开发人员或者系统集成者可以通过组合一个或多个服务来构建应用，而无须理解服务的底层实现。举例来说，一个服务可以用.NET或J2EE来实现，而使用该服务的应用程序可以在不同的平台之上，使用的语言也可以不同。

 
SOA三大基本特征

独立的功能实体
在Internet这样松散的使用环境中，任何访问请求都有可能出错，因此任何企图通过Internet进行控制的结构都会面临严重的稳定性问题。SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术，如.NET Remoting，EJB，COM或者CORBA，都需要有一个宿主(Host或者Server)来存放和管理这些功能实体；当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问题的时候，在该宿主上运行的其它应用服务就会受到影响。

SOA架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术，比如事务处理(Transaction)，消息队列(Message Queue)，冗余部署(Redundant Deployment)和集群系统(Cluster)在SOA中都起到至关重要的作用。

大数据量低频率访问
对于.NET Remoting，EJB或者XML-RPC这些传统的分布式计算模型而言，他们的服务提供都是通过函数调用的方式进行的，一个功能的完成往往需要通过客户端和服务器来回很多次函数调用才能完成。在Intranet的环境下，这些调用给系统的响应速度和稳定性带来的影响都可以忽略不计，但是在 Internet环境下这些因素往往是决定整个系统是否能正常工作的一个关键决定因素。因此SOA系统推荐采用大数据量的方式一次性进行信息交换。

基于文本的消息传递
由于Internet中大量异构系统的存在决定了SOA系统必须采用基于文本而非二进制的消息传递方式。在COM、CORBA这些传统的组件模型中，从服务器端传往客户端的是一个二进制编码的对象，在客户端通过调用这个对象的方法来完成某些功能；但是在Internet环境下，不同语言，不同平台对数据、甚至是一些基本数据类型定义不同，给不同的服务之间传递对象带来的很大困难。由于基于文本的消息本身是不包含任何处理逻辑和数据类型的，因此服务间只传递文本，对数据的处理依赖于接收端的方式可以帮忙绕过兼容性这个的大泥坑。

此外，对于一个服务来说，Internet与局域网最大的一个区别就是在Internet上的版本管理极其困难，传统软件采用的升级方式在这种松散的分布式环境中几乎无法进行。采用基于文本的消息传递方式，数据处理端可以只选择性的处理自己理解的那部分数据，而忽略其它的数据，从而得到的非常理想的兼容性。