SOA应用系统总体框架及相关概念及实现技术

SOA相关概念 

1，SOA----一种架构准则，其中心内容是把IT资产描述和公开为（远程）服务。然后可以把这些服务以松散耦合的方式作为高级业务流程的一部分，从而在面临IT异构性时提供业务灵活性。

一种设计方法，其目标是重用应用中立的服务，从而提高IT适应性和效能。

SOA是一种企业集成的解决方案，它利用Web services 和业务流程执行语言（Business Process Execution Language，BPEL）。这些技术提供开放的、基于标准的集成，该集成通过组合消息传递技术和 XML 及各种Web services 标准来提供互操作性。一旦开发了Web service 接口，您就可以使用BPEL 来定义和编排业务事务，最终使遗留系统转变成全新的现代信息系统。

 

 

2，（远程）服务，是指提供远程调用能力的组件。提供了功能。可以为远程的客户端提供服务。EJB,JMS,Corba,COM，Web Service等远程调用机制，就是这里说的服务。

 

3，Web Services是SOA的原料。它解决了其他远程调用机制的兼容性问题。它与任何语言和平台无关。几乎所有远程调用机制都可以生成Web Services。Web Services是远程服务的世界语。

尽管SOA未必一定是用Web Services，但是SOA概念的提出和今天的热火朝天，主要是由于Web Services这种远程服务的世界语，消除了企业IT资产远程重用的障碍。

 

4，ESB(Enterprise Services Bus)企业服务总线

Corba有服务器，发布和管理Corba远程服务；COM组件业有服务器DCOM，发布和管理Corba远程服务；JMS,EJB也有服务器J2EE，发布和管理J2EE平台下的远程服务。

Web Services可以被各类中间件服务器发布。但是，还没有管理它们的服务器。如，J2EE服务器没有管理Web Services的功能。

ESB(Enterprise Services Bus)企业服务总线，就是这样一个Web Services的中间件服务器。它发布和管理所有的Web Services，正如EJB容器使用JNDI发布和管理所有的远程EJB一样。

ESB服务器是Web Services的储存、管理之地。是SOA取得Web Services的地方。这也有助于SOA开发人员管理、寻找和重用Web Services。

 

5，BPEL（Business Process Execution Language）业务程序执行语言。也有叫作BPEL4WS或BPELWS，意思是：使用Web Services的业务程序执行语言。

意思都是一样的。

这是工作流语言/业务程序管理语言的扩展，它是能够使用Web Services为业务程序服务的业务程序。

xPDL是一种业务程序语言规范。jBPM提供了扩展JPDL语言。它使用了类似UML的活动图。可以使用业务程序变量、脚本语言、ActionHandler实现类。因为它是只使用java的POJO类的业务程序引擎。所以可以使用java的一些特性。

实际上，我们也可以使用POJO来代表Web Services，间接的调用Web Services。但是，由于它是JPDL语言，依赖于Java，所以，该业务程序定义不能够直接被不同的语言平台所使用！

BPEL虽然只是业务程序管理引擎的扩展，但是它只使用Web Services，从而有一些特殊的要求。

1，它不使用任何特定的编程语言。Web Services是一种脱离特定语言实现的描述语言。所以，在BPEL中，我们也不能使用任何特定的语言。

2，在JPDL中，我们可以在ActionHandler中委派Web Services执行业务逻辑。但是，我们可以在ActionHandler中使用Java语法执行特定的功能。

在BPEL中，我们唯一能够使用的就只有现有的Web Services，所以，我们必须提供编程语言的一些语法机制，帮助我们仅仅使用BPEL语法就可以完成业务流程。

但是，请注意，可能我们最终无法脱离特定的语言来构建BPEL。

    现在已经提出了BPELJ这种Java扩展的BPEL。
SOA应用系统总体框架

看到SOA的一堆名词，读者可能会感到迷惑，有必要结合实际的应用环境进一步阐释SOA的相关概念。

总体框架

图1所示的就是一个SOA应用系统的大体框架结构。它大体上可以分为五个部分：

● 展现层（presentation）：图1中5区，通过portal等技术建立展现平台，方便用户在这个界面上提出服务请求。

● 业务处理建模（business process modeling）：图1中的4区，SOA元模型从MDA中继承了平台无关模型来对业务处理过程建模。这一部分独立于服务设计和部署层。模型驱动架构MDA（Model Driven Architecture）的主要缺陷是在模型设计阶段就对需求有完整的描述，而且没有需求变更的反馈机制。SOA通过添加敏捷方法AM来应对需求变更的情况。

● 服务层(Services): 图1中的3区，整个SOA的核心层，它承上启下，对上响应业务模型，对下调用相关组件群完成业务需求,形成“业务驱动服务、服务驱动技术”的SOA事务处理格局。服务可以根据粒度分层。虽然细粒度提供了更多的灵活性，但同时也意味着交互的模式可能更为复杂。粗粒度降低了交互复杂性，但敏捷性却下降。

● 企业组件层（enterprise components）：图1中的2区，这里是相关组件发挥作用的场所。这些组件是平台相关的。因为到了这一层，许多底层软硬件平台的特性已经不再透明了。

● 系统软件层(Operational System):图1中的1区，这一层包括操作系统、数据库管理系统、CRM、ERP、商业智能(BI)等异构系统，是一个集成的平台。

除此之外，诸如QoS、安全性等(图1中7区)也是SOA架构的组成部分。

在上面的介绍中，自上而下有一条线，如图2所示，由业务建模开始，通过定义业务过程，得到服务模型，它是平台无关的，实现了模型与实现的分离。再通过设计组件群，得到平台相关的组件模型。

实施原则

Jason Bloomberg在其《Principles of SOA》中指出，SOA的实践必须遵循以下原则：

● 业务驱动服务，服务驱动技术。从本质上说，在抽象层次上，服务位于业务和技术中间。面向服务的架构设计师一方面必须理解在业务需求和可以提供的服务之间的动态关系;另一方面，同样要理解服务与提供这些服务的底层技术之间的关系。

● 业务敏捷是基本的业务需求。SOA考虑的是下一个抽象层次：提供响应变化需求的能力是新的“元需求”，而不是处理一些业务上的固定不变的需求。从硬件系统以上的整个架构都必须满足业务敏捷的需求，因为，在SOA中任何的瓶颈都会影响到整个IT环境的灵活性。

● 一个成功的SOA总在变化之中。SOA工作的场景，更像是一个活的生物体，而不是像传统所说的“盖一栋房子”。IT环境惟一不变的就是变化，因此面向服务架构设计师的工作永远不会结束。对于习惯于盖房子的设计师来说，要转向设计一个活的生物体要求有崭新的思维方式。SOA的基础还是一些类似的架构准则。

与其他概念的关系

1. SOA与Web Services的关系

SOA构架是独立于技术实现的。SOA并不必用Web Services来实现，相反，Web Services也并不一定遵循SOA标准。

不过，Web Services的特性十分适合用来实现SOA架构。Web Services 之间能够交换带结构的文档（比如XML），这些文档可能包含完全异构的数据信息。这些文档可以同时附带关于数据的数据：元数据（metadata）。换句话说，Web Services可以有较粗的粒度，这样较粗的粒度正好可以构成SOA中服务的粒度。

说到底，两者是相交的圆，SOA服务和Web Services之间的区别还在于设计。SOA概念并没有确切地定义服务具体如何交互，而仅仅定义了服务如何相互理解。其中的区别也就是定义如何执行流程的战略与如何执行流程的战术之间的区别。而另一方面，Web Services在需要交互的服务之间如何传递消息有具体的指导原则；从战术上实现SOA模型是通过 HTTP传递的SOAP消息中最常见的SOA模型。因而，从本质上讲，Web Services是实现 SOA的具体方式之一。

2. SOA中的服务与组件对象（Components Objects）的关系

相似之处在于：都有一个或多个接口，并且，服务发布者和使用者都遵守这些接口。

不同之处在于：SOA是关于模式（schemas）的，组件对象是关于对象类型（object types）的；SOA通过像SOAP这样的标准消息机制（messages）来实现通信，而组件对象通过方法调用（method calls）来交互。与CORBA 中的接口定义语言IDL (Interface Definition Language)相比，SOA 在WSDL (Web Services Definition Language) 中采用XML，会显得更加普遍和通用。

联系之处在于：服务最终还是通过类和组件对象来实现的。

SOA被认为是传统紧耦合的、面向对象的模型的替代者。像通用对象代理架构CORBA (Common Object Request Broker Architecture)和分布式组件对象模型DCOM (Distributed Component Object Model)。在SOA 中，单个服务可以用面向对象方法来设计，但是，整个SOA的设计却是面向服务的。下面的表格中给出了SOA与分布式组件架构的不同点。

3. SOA与网格计算（Grid Computing）的关系

网格计算（Grid Computing）是利用互联网技术，把分散在不同地理位置的计算机组成一台虚拟超级计算机。每一台参与的计算机就是其中的一个“节点”，所有的计算机就组成了一张节点网——网格。从实质上来说“网格计算”是一种分布式应用，网格中的每一台计算机只是完成工作的一个小部分，虽然单台计算机的运算能力有限，但成千上万台计算机组合起来的计算能力就可以和超级计算机相比了。

网格计算基于因特网，提供了资源整合和共享的平台。十分适合作为SOA架构的实施平台。

我们来具体地看一下：

SOA 的构建策略：创建一个面向服务的计算SOC（service-based computing）环境；可以用类似于web services的技术来设计服务：使用SOAP通信机制；采用XML数据格式；强调服务的重用和互操作；最大化的应用现有资源；希望有一个类似于网格计算环境的基础平台。

网格作为平台的基本特点：网格被视为一个由各种计算资源组成的统一环境，其管理软件将网格整合成一个完整而协调的透明计算整体；网格是一个虚拟的应用服务器;是一个应用实现和数据处理的理想平台；服务在网格中部署和调用执行；商业逻辑和服务调用被当成网格程序一样在平台上运行；网格为SOC计算的有效性、快速性、灵活性、伸缩性和计算环境的管理提供便利。

SOA带给企业什么？

作为需要构建SOA应用的企业来说，究竟有些什么好处呢？我们来看一下：

● 集成现有系统，不必另起炉灶。面向服务的体系结构可以基于现有的系统投资来发展，而不需要彻底重新创建系统。通过使用适当的 SOA 框架并使其用于整个企业，可以将业务服务构造成现有组件的集合。使用这种新的服务只需要知道它的接口和名称。服务的内部细节以及在组成服务的组件之间传送的数据的复杂性都对外界隐藏了。这种组件的匿名性使组织能够利用现有的投资，从而可以通过合并构建在不同的机器上、运行在不同的操作系统中、用不同的编程语言开发的组件来创建服务。遗留系统可以通过 Web 服务接口来封装和访问。

● 服务设计松耦合， 带来多方面优点。服务是位置透明的，服务不必与特定的系统和特定的网络相连接。服务是协议独立的，服务间的通信框架使得服务重用成为可能。对于业务需求变化，SOA能够方便组合松耦合的服务，以提供更为优质和快速的响应，允许服务使用者自动发现和连接可用的服务。松耦合系统架构使得服务更容易被应用所集成，或组成其他服务，同时提供了良好的应用开发、运行时服务部属和服务管理能力。提供对服务使用者的验证（authentication） 授权（authorization），来加强安全性保障，这一点也优于其他紧耦合架构。

● 统一了业务架构，可扩展性增强。在所有不同的企业应用程序之间，基础架构的开发和部署将变得更加一致。现有的组件、新开发的组件和从厂商购买的组件可以合并在一个定义良好的 SOA 框架内。这样的组件集合将被作为服务部署在现有的基础构架中，从而使得可以更多地将基础架构作为一种商品化元素来加以考虑，增强了可扩展性。又由于面向服务的敏捷设计，在应对业务变更时，有了更强的“容变性”。

● 加快了开发速度，减少了开发成本。组织的 Web 服务库将成为采用 SOA 框架的组织的核心资产。使用这些 Web 服务库来构建和部署服务将显著地加快产品的上市速度，因为对现有服务和组件的新的创造性重用缩短了设计、开发、测试和部署产品的时间。 SOA 减少了开发成本，提高了开发人员的工作效率。

研究表明，一般系统的接口的开发费用占到整个开发费用的33%，最高的竟达到了70%。在SOA中，接口的重用会节省费用60%。而且节省的费用不是一次性的，而是每年。随着业务需求的发展和新的需求的引入，通过采用 SOA 框架和服务库，为现有的和新的应用程序增强和创建新的服务的成本大大地减少了。同样，开发团队的学习难度也降低了，因为他们可能已经熟悉了现有的组件。

● 持续改进业务过程，降低激变风险。SOA允许清晰地表示流程流，这些流程流通过在特定业务服务中使用的组件的顺序来标识。这给商业用户提供了监视业务操作的理想环境。业务建模反映在业务服务中。流程操纵是以一定的模式重组部件（构成业务服务的组件）来实现的。这将进一步允许更改流程流，而同时监视产生的结果，因此促进了持续改进。重用现有的组件降低了在增强或创建新的业务服务过程中带来的风险，也减少了维护和管理支持服务基础架构的风险。
SOA的相关技术
要实施SOA，首先要了解实现SOA所需要的相关技术，其中涉及的主要技术包括以下几个：XML、SOAP 、WSDL、UDDI和ESB。如下图1所示。

图1是一张SOA技术实施的示意图

1．XML

XML 1.0 (可扩展标记语言，Extensible Markup Language) 标准是一个基于文本的 World Wide Web 组织 (W3C) 规范的标记语言。与 HTML 使用标签来描述外观和数据不同，XML 严格地定义了可移植的结构化数据。它可以作为定义数据描述语言的语言，如标记语法或词汇、交换格式和通信协议。

2．SOAP

简单对象访问协议 (Simple Object Access Protocol) 是一个基于XML的，用于在分布式环境下交换信息的轻量级协议。SOAP 在请求者和提供者对象之间定义了一个通信协议，这样，在面向对象编程流行的环境中，该请求对象可以在提供的对象上执行远程方法调用。因为SOAP是平台无关和厂商无关的标准，因此尽管SOA并不必须使用SOAP，但在带有单独 IT基础架构的合作伙伴之间的松耦合互操作中，SOAP仍然是支持服务调用的最好方法。

W3C SOAP 1.2规范在服务请求者和服务提供者之间定义使用XML格式的消息进行通信。将应用程序请求（在XML中）放入 SOAP 信封中（也是 XML ），并从请求者到提供者发送应用程序请求，提供者发回的响应也采用相同的形式。最近 SOAP 被称为面向服务的架构协议 (Services-Oriented Architecture Protocol)。

SOAP的优点在于它完全和厂商无关，相对于平台、操作系统、目标模型和编程语言可以独立实现。另外，传输和语言绑定以及数据编码的参数选择都是由实现决定的。

3．WSDL

Web服务描述语言 WSDL (Web Services Description Language) 是一个提供描述服务IDL标准方法的XML词汇。Web 服务描述语言（WSDL）规范定义了一个 XML词汇表，该词汇表依照请求和响应消息，在服务请求者和服务提供者之间定义了一种契约。我们能够将Web服务定义为软件，这个软件通过描述SOAP消息接口的 WSDL文档来提供可重用的应用程序功能，并使用标准的传输协议来进行传递。

WSDL描述包含必要的细节,以便服务请求者能够使用特定服务：

● 请求消息格式

● 响应消息格式

● 向何处发送消息。

WSDL 是基于 XML 的，因此 WSDL 文档是计算机可读的（machine-readable）。这样开发环境使用WSDL将集成服务的流程自动处理到请求者应用程序。例如 WebSphere Studio产生一个Java的代理对象，它能够像本地对象一样实现服务，但是实际上代理对象仅仅处理请求的创建和响应消息的解析。不管服务是否用Java、C#或者其他的语言实现，生成的Java代理对象都能够从WSDL描述中调用任何的Web服务。实际上，WSDL不能像编程语言那样描述实现细节。

4．UDDI

统一描述、发现和集成 (Universal Description, Discovery and Integration) 规范提供了一组公用的 SOAP API，使得服务代理得以实现。UDDI为发布服务的可用性和发现所需服务定义了一个标准接口（基于 SOAP 消息）。UDDI 实现将发布和发现服务的 SOAP 请求解释为用于基本数据存储的数据管理功能调用。

为了发布和发现其他SOA服务，UDDI 通过定义标准的 SOAP 消息来实现服务注册（Service Registry）。注册是一种服务代理，它是在 UDDI 上需要发现服务的请求者和发布服务的提供者之间的中介。一旦请求者决定使用特定的服务，开发者通常借助于开发工具（如Microsoft Visual Studio .NET）并通过创建以发送请求并处理响应的方式访问服务的代码来绑定服务。

SOA不需要使用UDDI，但由于 UDDI 是建立在SOA上来完成自身工作的，所以UDDI是服务发现的一个好的解决方案。

5．ESB

如图2所示，企业服务总线ESB（Enterprise Service Bus）是SOA架构的一个支柱技术。 作为一种消息代理架构它提供消息队列系统，使用诸如SOAP或JMS (Java Message Service)等标准技术来实现。

有人把ESB描述成一种开放的、基于标准的消息机制，通过简单的标准适配器和接口，来完成粗粒度应用（比如服务）和其他组件之间的互操作。

ESB的主要功能有：通信和消息处理、服务交互和安全性控制、服务质量和服务级别管理、建模、管理和自治、基础架构智能等。