SOA概念

SOA是什么

SOA不是针对某一个系统的架构设计，他更多是针对整个企业的架构设计，他所解决的是更高层的整个企业各业务领域的整合问题。
SOA（面向服务的架构），顾名思义它是一种架构思想，不单单指某一种特定的架构，而是重在面向服务的思想。可以认为“一切皆服务”，也就是说底层的数据资源可以通过服务直接暴露，也可以通过封装实现原子服务，这些原子服务可以根据业务逻辑构成业务流程，从而实现复杂的业务功能。这其中就涉及到SOA服务重用性、松耦合性、透明性等特点，这种架构思想可以促进不同业务部门间信息的共享。

SOA：面向服务架构，java级企业开发的首选。

SOA的提出是在企业计算领域，就是要将紧耦合的系统，划分为面向业务的，粗粒度，松耦合，无状态的服务。服务发布出来供其他服务调用，一组互相依赖的服务就构成了SOA架构下的系统。

基于这些基础的服务，可以将业务过程用类似BPEL流程的方式编排起来，而BPEL反映的是业务处理的过程，这些过程对于业务人员更为直观，调整也比hardcode的代码更容易。

当然企业还需要对服务治理，比如服务注册库，监控管理等。

我们知道企业计算领域，如果不是交易系统的话，并发量都不是很大的，所以大多数情况下，一台服务器就容纳将许许多多的服务，这些服务采用统一的基础设施，可能都运行在一个应用服务器的进程中。虽然说是面向服务了，但还是单一的系统。

面向服务的体系结构将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以使用一种统一和通用的方式进行交互。

企业系统的架构师认为SOA能够帮助业务迅速和高效地响应变化的市场条件 ^[1] . 服务导向的架构在宏观（服务）上，而不是在微观上（对象）因此提高了重复使用性。同时，服务导向的架构可以简化与传统系统的互连和使用。

SOA的目标在于让IT变得更有弹性，以更快地响应业务单位的需求。

SOA的原则

以下指导原则是开发，维护和使用SOA的基本原则^[3]：

• 可重复使用, 粒度, 模组性, 可组合型, 物件化原件, 构件化以及具交互操作性
• 符合开放标准(通用的或行业的)
• 服务的识别和分类，提供和发布，监控和跟踪。

下面是一些特定的体系架构原则：

• 服务封装
• 服务松耦合(Loosely coupled) - 服务之间的关系最小化，只是互相知道。
• 服务契约 - 服务按照服务描述文档所定义的服务契约行事。
• 服务抽象 - 除了服务契约中所描述的内容，服务将对外部隐藏逻辑。
• 服务的重用性 - 将逻辑分布在不同的服务中，以提高服务的重用性。
• 服务的可组合性 - 一组服务可以协调工作并组合起来形成一个组合服务。
• 服务自治 – 服务对所封装的逻辑具有控制权
• 服务无状态 – 服务将一个活动所需保存的资讯最小化。
• 服务的可被发现性 – 服务需要对外部提供描述资讯，这样可以通过现有的发现机制发现并访问这些服务。^[4]

除此以外，在定义一个SOA实现时，还需要考虑以下因素：

• 生命周期管理
• 有效使用系统资源
• 服务成熟度和性能

SOA作用

面向服务架构（SOA）是让IT更加关注于业务流程而非底层IT基础结构，从而获得竞争优势的更高级别的应用程序开发架构。

　　SOA对需要使用信息技术解决关键业务问题的企业（包括希望减少冗余架构、创建跨客户和员工系统的公共业务接口的企业；需要基于角色和工作流对用户提供个性化信息的业务的企业；希望通过Internet实现跨区销售、升级销售和经由移动设备的访问来提升客户服务的组织）很有价值。 
 
　　采用服务驱动型方法的企业体验着以下业务和IT好处：

　　面向服务架构的业务好处

　　效率：将业务流程从"烟囱"状的、重复的流程向维护成本较低的高度利用、共享服务应用转变。 
　　响应：迅速适应和传送关键业务服务来满足市场需求，为客户、雇员和合作伙伴更高水准的服务。 
　　适应性：更高效地转入转出让整个业务变得复杂性和难度更小，达到节约时间和资金的目的。

　　面向服务架构的IT好处

　　复杂性降低：基于标准的兼容性，与点到点的集成相比降低了复杂性。 
　　重用增加：通过重用以前开发和部署的共享服务，实现了更有效的应用程序/项目开发和交付。 
　　遗留集成：用作可重用服务的遗留应用程序降低了维护和集成的成本。

SOA是在计算环境下设计、开发、应用、管理分散的逻辑（服务）单元的一种规范。这个定义决定了SOA的广泛性。SOA要求开发者从服务集成的角度来设计应用软件，即使这么做的利益不会马上显现。SOA要求开发者超越应用软件来思考，并考虑复用现有的服务，或者检查如何让服务被重复利用。SOA鼓励使用可替代的技术和方法（例如消息机制），通过把服务联系在一起而非编写新代码来构架应用。经过适当构架后，这种消息机制的应用允许公司仅通过调整原有服务模式而非被迫进行大规模新的应用代码的开发，使得在商业环境许可的时间内对变化的市场条件做出快速的响应。
SOA也不仅仅是一种开发的方法论--它还包含管理。例如，应用SOA后，管理者可以方便的管理这些搭建在服务平台上的企业应用，而不是管理单一的应用模块。其原理是，通过分析服务之间的相互调用，SOA使得公司管理人员方便的拿到什么时候、什么原因、哪些商业逻辑被执行的数据信息，这样就帮助了企业管理人员或应用架构师迭代地优化他们的企业业务流程、应用系统。
SOA的一个中心思想就是使得企业应用摆脱面向技术的解决方案的束缚，轻松应对企业商业服务变化、发展的需要。企业环境中单个应用程序是无法包容业务用户的（各种）需求的，即使是一个大型的ERP解决方案，仍然不能满足这个需求在不断膨胀、变化的缺口，对市场快速做出反应，商业用户只能通过不断开发新应用、扩展现有应用程序来艰难的支撑其现有的业务需求。通过将注意力放在服务上，应用程序能够集中起来提供更加丰富、目的性更强的商业流程。其结果就是，基于SOA的企业应用系统通常会更加真实地反映出与业务模型的结合。服务是从业务流程的角度来看待技术的--这是从上向下看的。这种角度同一般的从可用技术所驱动的商业视角是相反的。服务的优势很清楚：它们会同业务流程结合在一起，因此能够更加精确地表示业务模型、更好地支持业务流程。相反我们可以看到以应用程序为中心的企业应用模型迫使业务用户将其能力局限为应用程序的能力。
企业流程（enterprise process）是流经企业框架的空气，它赋予业务模型里的组件以生命，并更加清晰地定义了它们之间的关系。流程定义了同业务模型进行交互操作的专门方法。例如，会计可能是企业服务系统的一个组件--但是将发票寄给客户却是一个业务流程。服务被定义用来支持业务流程，因而贯穿整个流程始终的是：各种服务组件在流程和逻辑实现过程中的装配操作。理解业务流程是定制服务的关键所在。
有利于企业业务的集成
传统的应用集成方法（点对点集成、企业消息总线或中间件的集成（EAI）、基于业务流程的集成）都很复杂、昂贵，并且不灵活。这些集成方法难于快速适应基于企业现代业务变化不断产生的需求。基于面向服务架构 (SOA) 的应用开发和集成可以很好的解决其中的许多问题。
SOA 描述了一套完善的开发模式来帮助客户端应用连接到服务上。这些模式定制了系列机制用于描述服务、通知及发现服务、与服务进行通信。
不同于传统的应用集成方法，在 SOA 中，围绕服务的所有模式都是以基于标准的技术实现的。大部分的通信中间件系统，如 RPC、CORBA、DCOM、EJB 和 RMI，也同样如此。可是它们的实现都不是很完美的，在权衡交互性以及标准定制的可接受性方面总是存在问题。SOA 试图排除这些缺陷。因为几乎所有的通信中间件系统都有固定的处理模式，如RPC 的功能、CORBA 的对象等等。然而，服务既可以定义为功能，又可同时对外定义为对象、应用等等。这使得 SOA 可适应于任何现有系统，并使得系统在集成时不必刻意遵循任何特殊定制。
SOA 帮助企业信息系统迁移到"leave-and-layer"架构之上，这意味着在不用对现有的企业系统做修改的前提下，系统可对外提供 Web 服务接口，这是因为它们已经被可以提供 Web 服务接口的应用层做了一层封装，所以在不用修改现有系统架构的情况下，SOA 可以将系统和应用迅速转换为服务。SOA 不仅覆盖来自于打包应用、定制应用和遗留系统中的信息，而且还覆盖来自于如安全、内容管理、搜索等 IT 架构中的功能和数据。因为基于 SOA 的应用能很容易地从这些基础服务架构中添加功能，所以基于SOA的应用能更快地应对市场变化，为使企业业务部门设计开发出新的功能应用。
"架构之上，这意味着在不用对现有的企业系统做修改的前提下，系统可对外提供 Web 服务接口，这是因为它们已经被可以提供 Web 服务接口的应用层做了一层封装，所以在不用修改现有系统架构的情况下，SOA 可以将系统和应用迅速转换为服务。SOA 不仅覆盖来自于打包应用、定制应用和遗留系统中的信息，而且还覆盖来自于如安全、内容管理、搜索等 IT 架构中的功能和数据。因为基于 SOA 的应用能很容易地从这些基础服务架构中添加功能，所以基于SOA的应用能更快地应对市场变化，为使企业业务部门设计开发出新的功能应用。