面向服务架构风格系统举例面向服务架构风格系统举例分析

什么是面向服务的体系结构?

面向服务架构（Serv-Oriented Architecture，SOA）面向服务架构又称“面向服务的体系结构”，是Gartner于2O世纪9O年代中期提出的面向服务架构的概念。2002年的l2月，Gartner提出“面向服务的架构( SOA)”是“现代应用开发领域最重耍的课题”之后。国内外计算机专家、学者掀起了对SOA的积极研究与探索。

面向服务架构

SOA和基于标准的Web服务以及基于互联网的交付模式的出现为新的软件平台的技术创新提供了重要的基础。我们称作SOP(面向服务编程)的一种突破性的软件组件化技术就是这些技术创新之一。SOA的重点是使用“服务作”的各个系统之间的通讯，而SOP是为建立灵活的应用程序模块提供一种新的技术。这种模块把内部流程、本地服务作当作“组装的元件”。 SOP不是仅仅使用服务访问这些系统，而是提供一种模块驱动的技术，使用内存中的服务镜像运行一个完整的应用程序。由于这些内存中的服务能够通过Web服务标准或者任何专有的协议透明地实现外部化，SOP能够自动地把SOA添加到应用程序模块中，并且从“内部”进行实时整合，从而消除价格昂贵的数据的需求。SOP模块能够用来改变和集成数量级，比单独使用SOA速度更快、更方便。

SOP把一个内存中的服务与面向服务的和模块驱动的编程架构结合在一起，不使用编码和脚本把应用程序模块制作成服务。SOP与“内部的SOA”一起把应用程序组件化和集成功能统一起来，从而消除了把应用程序和SOA集成捆绑在一起的需求。由于这个SOP范例是由模型推动的，因此不需要许多复杂的插件“中间件”产品，如从工作流和商务流程管理工具到数据交换工具的各种中间件软件。通过消除整个SOA中间件软件栈的需求，模型推动的SOP改变了软件自动化的经济。SOP模型在运行的时候将自动地由多租户服务虚拟机运行和管理。

SOP采用分层次的软件模块，用级的、原子的服务代表这个工作的最小的部分;用的、合成的服务包含许多嵌套的服务模块。商务逻辑包括许多合成的服务。在运行的时候，这些服务在多内核、处理器和上自动地以多线程方式运行并且进行分子级的虚拟化。一种类似于“Get Annual Customer Serv Orders”(获得每年用户服务订单)的服务也许包括100个嵌套的服务。通过连续地执行这些服务，服务运行时环境自动把这些服务发送到多个内核，极大地减少了执行时间。服务运行时环境理解诸如数据相关性等全部并行化问题，并且不需要用户输入任何数据就能够在后台解决这些问题。这个过程完全使用超级计算机系统的并行计算能力，不需要麻烦程序员创建线程。

在SOP中，服务接口组成内存中封装的单元并且在运行时透明地客观化，无论在分层次的组合中的什么地方使用它们都是如此。这种把更高级别的服务模块的任何子服务组件客观化的透明的能力是SOP融合资产的核心。它是全部子组件内置的虚拟化的关键。整个多内核和、内部SOA集成以及通过SOP实现的许多其它创新机制都包含这些组件。

目前，现场提供的传统的应用程序与SaaS应用软件厂商使用的应用程序之间的主要平台异存在于SaaS应用程序平台中的多租户中。除了多租户交付模式之外，SaaS和现场应用程序开发使用的范例和技术基本上是相同的。使用多租户SOP平台开发和运行SaaS应用程序组件能够给现有的SaaS交付经济带来模型驱动开发、内部SOA和自动组件虚拟化的的好处。SOP是SaaS、SOA和虚拟化的一个融合点。

向SOP平台Ventyx过渡的一个例子是提供用于服务递送管理的ERP应用软件。企业使用这种软件管理客户、员工队伍、零件库存、工具和文件。这种软件为40多个的400多家公司服务，其中包括一些核电公司。由于他们的客户一般都在应用软件中进行了商务逻辑客户化，通过采用在保持优化的计算机性能的同时保证高水平的集成的方式从Ventyx平台过渡到SOP平台能够为用户提供更好的支持。

Ventyx应用NextAxiom公司的Hyperserv商务平台和服务运行时环境，帮助他们移植老式的代码和开发新的应用程序以便运行SOP平台。Hyperserv Studio提供了一个功能齐全的基于语义的环境，用于制作、管理和客户化称作服务的软件模块。同时，服务运营时环境为自动化并行执行服务提供一个管理的运行时环境。老式的代码可以转换为SOP模型或者封装在“包装”中。这样，这些老式代码稍微修改一下就可以像以前一样运行。

采用NextAxiom的SOP平台，开发商务逻辑程序像制作流程图一样是可见的。用户可以用鼠标拖放本地服务界面、增加可视化编程结构并且用线把它们联系在一起。Ventyx产品架构Fernando Alvarez称，现在，我们的客户能够把服务结合在一起，根据需要选择和集成解决方案。用户不需要编写代码，只需要在语义上创建这个平台能够自动执行的一些服务。这就意味着有经验的商务流程专家和软件编程人员能够创建这种服务。由于代码既不是编写的也不是生成的，解决方案在其整个生命周期中都是非常灵活的。

NextAxiom的客户能够运行一个把单线程的老式代码与多线程的合成服务结合在一起的程序。英特尔架构处理器运行这两种线程都非常好。这有益于需要各种工作量的高性能计算的应用程序。这种应用程序软件进行优化之后能够在配置英特尔双核安腾2处理器的惠普Integrity rx6600上运行。

以上对SOA的回答很详细，我就不补充了

SOA有什么用？

soa是面向服务的架构，在soa架构中，服务是最核心的抽象手段，业务被划分为一系列的业务服务和业务流程。

soa是一种架构风格，不是一种方法。soa的首要目标就是IT与业务对齐，支持业务的快速变化，其次是架构的灵活性和资产的重用。soa的重点是服务建模和基于soa的设计原则进行架构决策和设计。学习soa还要学习相关的webserv、soap、wsdl、UDDI、xml等。

总之，soa是一种面向服务的架构风格，具有很好的灵活性和重用性

面向对象，面向服务，面向组件三种编程模式有什么区别

三个数据后面都缺了一个词，分别是：“编程”、“架构”和“开发”(或“软件工程”)。同时，不是“面向”组件而是“基于”组件。

面向对象编程(Object-Oreinted Programming) 是一种编程范式。指在设计程序时大量运用类实例对象的方式。OOP一旦在项目中被运用，就成了时刻要考虑的东西。

面向服务架构(Serv-Oreinted Architecture) 是将软件设计成一组可互作的服务的一套原则或方。通常在考虑系统架构时才会触及SOA。

基于组件开发(Component-Based Dlopment) 是一种软件工程实践，设计时通常要求组件之间高内聚，松耦合。其接口可能是OO的，调用方式可能是以Serv的方式。基于组件开发关注系统层次、子系统边界和子系统间通讯的的设计，处于代码层面但不像OOP的一样是时刻需要运用的东西。

三者身处软件开发的不同层面，因此说他们用于“哪些领域”并不恰当。不论是哪个领域的软件开发，都可能要同时面对OOP、SOA和CBD。

能不能简单的说一下SOA面向服务架构是什么意思? 要形象的，做好举个易理解的实例，不要百度百科！

就是在原有系统基础上实现信息互联互通。

比如：

某人就职，要经过一系列手续，使用实现SOA的话，

人事系统直接拿系统的人员资料作为员工档案的基础

完成员工档案后，安排职务岗位，

这个确定后，财务系统有了这个人的工资标准，ERP中多了这个资源信息，IT部门自动开EMAIL，该人入职完成。

看上去很普通的功能，但如果这些系统都不是一家厂家实现的，实现难度相当大。

如何认清面向服务架构SOA的真实面目

在经典软件工程理论中，不管是瀑布方法还是原型方法，都是从需求分析做起，一步一步构建起形形的软件系统。但是，需求变更像一个挥之不去的阴影，时刻伴随着系统左右。每一个实际应用系统的开发者都饱尝了在系统进入开发阶段、测试阶段，甚至上线阶段遭遇应接不暇的需求变更的极端痛苦。客户将变更的需求视为bug(错误)是测试上线阶段的主要问题。如何解决这一问题?能否来一场软件开发和架构的革命?SOA架构的提出，就是被人看成这样的一场革命。其实质就是要将系统模型与系统实现分割开来。 1.定义 SOA并不是一个新概念，有人就将CORBA和DCOM等组件模型看成SOA架构的前身。早在1996年，Gartner Group就已经提出了SOA的预言，不过那个时候仅仅是一个“预言”，当时的软件发展水平和信息化程度还不足以支撑这样的概念走进实质性应用阶段。到了近一两年，SOA的技术实现手段渐渐成熟了。在BEA、IBM等软件巨头的极力推动下，才得以慢慢风行起来。Gartner为SOA描述的愿景目标是实现实时企业(Real-Time Enterprise)。关于SOA，目前尚未有一个统一的、业界广泛接受的定义。一般认为：SOA，面向服务的架构是一个组件模型，它将应用程序的不同功能单元 ----服务(serv)，通过服务间定义良好的接口和契约(contract)联系起来。接口采用中立的方式定义，于具体实现服务的硬件平台、作系统和编程语言，使得构建在这样的系统中的服务可以使用统一和标准的方式进行通信。这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。从这个定义中，我们看到下面两点： ·软件系统架构： SOA不是一种语言，也不是一种具体的技术，更不是一种产品，而是一种软件系统架构，它尝试给出在特定环境下采用的一种架构，从这个角度上来说，它其实更像一种架构模式(Pattern)，是一种理念架构，是人们面向应用服务的解决方案框架。 ·服务(serv)是整个SOA实现的核心。SOA架构的基本元素是服务，SOA 指定一组实体(服务提供者、服务消费者、服务注册表、服务条款、服务和服务契约)，这些实体详细说明了如何提供和消费服务。遵循 SOA 观点的系统必须要有服务，这些服务是可互作的、的、模块化的、位置明确的、松耦合的并且可以通过网络查找其地址。 2.SOA三种角色的关系服务是一个自包含的、无状态(staess)的实体，可以由多个组件组成。它通过事先定义的界面响应服务请求。它也可以执行诸如编辑和处理事务(transaction)等离散性任务。服务本身并不依赖于其他函数和过程的状态。用什么技术实现服务，并不在其定义中加以限制。服务提供者(serv provider)提供符合契约(contract)的服务，并将它们发布到服务。服务请求者(serv consumer)也叫服务使用者，它发现并调用其他的软件服务来提供商业解决方案。从概念上来说，SOA 本质上是将网络、传输协议和安全细节留给特定的实现来处理。服务请求者通常称为客户端，但是，也可以是终端用户应用程序或别的服务。服务者(serv broker)作为储存库、电话黄页或票据交换所，产生由服务提供者发布的软件接口。这三种 SOA 参与者：服务提供者、服务者以及服务请求者通过 3 个基本作：发布(publish)、查找(find)、绑定(bind)相互作用。服务提供者向服务者发布服务。服务请求者通过服务者查找所需的服务，并绑定到这些服务上。服务提供者和服务请求者之间可以交互。所谓服务的无状态，是指服务不依赖于任何事先设定的条件，是状态无关的(state-free)。在SOA架构中，一个服务不会依赖于其他服务的状态。它们从客户端接受服务请求。因为服务是无状态的，它们可以被编排(orchestrated)和序列化(sequenced)成多个序列 (有时还采用流水线机制) ，以执行商业逻辑。编排指的是序列化服务并提供数据处理逻辑。但不包括数据的展现功能。 3.SOA特征基于上面讨论，我们给出SOA的下面一些特征： ·服务的封装(encapsulation)。将服务封装成用于业务流程的可重用组件的应用程序函数。它提供信息或简化业务数据从一个有效的、一致的状态向另一个状态的转变。封装隐藏了复杂性。服务的API保持不变，使得用户远离具体实施上的变更。 ·服务的重用(reuse)。服务的可重用性设计显着地降低了成本。为了实现可重用性，服务只工作在特定处理过程的上下文(context)中，于底层实现和客户需求的变更。 ·服务的互作(interoperability)。互作并不是一个新概念。在CORBA、DCOM、web serv中就已经采用互作技术了。在SOA中，通过服务之间既定的通信协议进行互作。主要有同步和异步两种通信机制。SOA提供服务的互作特性更利于其在多个场合被重用。 ·服务是自治的(Autonomous)功能实体。服务是由组件组成的组合模块，是自包含和模块化的。 SOA非常强调架构中提供服务的功能实体的完全自主的能力。传统的组件技术，如。NET Remoting， EJB，COM或者CORBA，都需要有一个宿主(Host或者)来存放和管理这些功能实体;当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问题的时候，在该宿主上运行的其它应用服务就会受到影响。 SOA架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术，比如事务处理(Transaction)，消息队列 (Message Queue)，冗余部署(Redundant Deployment)和集群系统(Cluster)在SOA中都起到至关重要的作用。 ·服务之间的松耦合度(Loosly Coupled)。服务请求者到服务提供者的绑定与服务之间应该是松耦合的。这就意味着，服务请求者不知道提供者实现的技术细节，比如程序设计语言、部署平台，等等。服务请求者往往通过消息调用作，请求消息和响应，而不是通过使用 API 和文件格式。这个松耦合使会话一端的软件可以在不影响另一端的情况下发生改变，前提是消息模式保持不变。在一个极端的情况下，服务提供者可以将以前基于遗留代码(例如，COBOL)的实现完全用基于 Ja 语言的新代码取代，同时又不对服务请求者造成任何影响。这种情况是真实的，只要新代码支持相同的通信协议。 ·服务是位置透明的(location transparency)。服务是针对业务需求设计的。需要反应需求的变化，即所谓敏捷(agility)设计。要想真正实现业务与服务的分离。就必须使得服务的设计和部署对用户来说是完全透明的。也就是说，用户完全不必知道响应自己需求的服务的位置，甚至不必知道具体是哪个服务参与了响应。 4.三个抽象级从概念上讲，SOA 中有三个主要的抽象级别： ·作：代表单个逻辑工作单元(LUW)的事务。执行作通常会导致读、写或修改一个或多个持久性数据。SOA 作可以直接与面向对象 (OO) 的方法相比。它们都有特定的结构化接口，并且返回结构化的响应。完全同方法一样，特定作的执行可能涉及调用附加的作。 ·服务：代表作的逻辑分组。服务可以分层，以降低耦合度和复杂性。一个服务的粒度(granularity)大小也与系统的性能息息相关。粒度太小，会增加服务间互作通讯的开销;粒度太大，又会影响服务面对需求变化的敏捷性。 ·业务流程：为实现特定业务目标而执行的一组长期运行的动作或活动。业务流程通常包括多个业务调用。在SOA中，业务流程包括依据一组业务规则按照有序序列执行的一系列作。作的排序、选择和执行称为服务或流程编排。典型的情况是调用已编排服务来响应业务。从建模的观点来看，由此带来的挑战是如何描述设计良好的作、服务和流程抽象的特征以及如何系统地构造它们。这些涉及服务建模、特征抽取的问题已经成为现阶段人们关注的焦点。