云服务：层次结构、集成技术与设计方法

本节首先讨论云服务的层次结构，其次讨论设计云服务的各种方法和设计原则，然后描述如何使用WSDL描述云服务，最后讨论云服务建模的工具。

（一）云服务的层次结构

云服务是粗粒度对象，在软件层。云服务层可以分解为以下几个层。

1.目标层

该层包含现有的系统实现对象和新对象，它们比服务更精细。它们可能是用Java实现的对象，例如企业对象。对于使用JPA的系统，它们可能是JPA实体。SOA可以利用基于服务的集成技术对现有系统进行集成。在这个层中，我们用不同的对象封装底层系统的功能。

2.服务层

公开的服务就在这个级别上。可以动态查找和调用它们，也可以直接静态地调用它们。在此级别上，公开用于描述服务的接口，以便公开接口以供使用。服务的接口以服务描述的形式呈现（例如，使用WSDL来描述它）。运行时提供的服务功能由对象层实现。每个服务可以独立存在，也可以组合成另一个大型服务。业务层是系统中最重要的层。在这一层中，我们使用底层功能组件来构建具有不同功能的服务。通常，SOA中的服务可以映射到特定系统中的任何功能模块。就功能而言，服务大致可分为以下三种类型：

业务服务或业务流程：是企业可以向外部用户或合作伙伴公开的服务。例如，订单服务、检查订单状态服务、商品查询服务等。

业务功能服务：一个业务功能服务，对于某些特定的业务操作可以是冗余的，并且还会被更高级别的业务服务调用。在大多数情况下，这些服务不暴露于对外部用户的直接调用，例如查询用户账户信息。

技术功能服务：主要是冗余成一些基本的技术功能，例如日志服务和安全服务。

3.业务流程层

服务层之上的第四层是业务流程层，在该层中，我们使用封装的各种服务在业务系统中构建业务流程。这个层可以看作是一个更大的服务。它通常是多个服务的组合。它是以与服务相同的方式调用的。我们还可以使用一些可视化的过程集成工具来描述和设计过程。

4.用户访问层

这一层是指最终用户看到的界面。我们可以使用一些高级技术，如Portlet、Widget、Mashup等，或者使用一些传统技术，如HTML、JSP等，或者两者结合使用。此层位于业务流程层的顶部，有时称为表示层。我们使用表示层为用户提供用户界面服务。此层可以从基于门户的系统中构建。

这些层中的每一个都需要一个集成的环境来支持它们的操作，即集成层和管理。

5.集成层

该层集成了所有服务，例如使用ESB。服务调用方通过集成层访问服务，从而确保服务的位置无关性。

6.管理和监测层

该层监视（例如，性能和可用性）并管理（例如，安全性）服务。这一层监视云服务，以确保我们达到云服务的质量标准。该层主要为整个系统提供服务质量管理、安全管理等辅助功能。

最近，一些公司提出了服务模块（简称模块）的概念。它由一个或多个具有固有业务联系的服务组件组成。在一个模块中放置了多少个服务组件，或者将哪些服务组件组合在一起，这在很大程度上取决于业务需求和部署需求。此外，由于模块是一个独立的部署单元，这给应用程序的部署带来了很大的灵活性。例如，只要模块接口保持不变，就很容易通过重新部署新模块来替换现有的业务逻辑，而不会影响应用程序的其他部分。我们认为服务模块是一个单独的小系统。

（二）设计云服务的方法

在智能城市系统中，我们使用SOA来设计云服务。在面向服务的软件设计方法出现之前，业界还有其他的设计方法，它们各有优缺点。在这里，我们快速地回顾这些软件设计方法，以便读者能够更好地理解SOA产生的背景。在设计SOA系统时，我们同时使用这些软件设计方法。

事实上，每个层次都有相应的设计方法。

1.面向对象的分析与设计

面向对象的软件设计方法是从对象（对象、概念或实体）的角度考虑问题域和逻辑解决方案。这些对象通常有许多操作和状态（记住这些操作的结果）。设计人员和分析人员通常封装对象（或对象组）的某些方面，并抽象对象的某些特性。面向对象分析和设计的基本原则如下。

（1）封装：软件对象是模拟现实世界的对象，是包含其物理属性（数据）和函数（方法）的离散包。就像仓库里的东西。

（2）信息隐藏：结构良好的对象具有简单的接口，不向外界透露任何内部机制，如访问库，调用者不需要详细了解库的具体操作。

（3）类和实例：类是用来定义包含属性和方法的特定类型的软件对象。实例是具有这些属性值的具体对象。创建类的新实例称为实例化。例如，在智能企业系统中，库存是一个类。所有库存都有属性，如项目的名称和数量。每个批发商的库存就是这类的一个例子，有一些特定的属性值（例如，张三的库存在商品类型上不同于李四，张三的库存有很多鞋子，李四的库存有很多衣服）。类一直存在，实例的生命周期有限。

（4）关联和继承：在面向对象的分析和设计中，我们需要表达类之间的关联，继承就是其中之一。我们经常发现软件对象的自然层次结构。例如，在智能企业中，有批发商、制造商、零售店等企业。这些企业共享许多属性，如名称、地址、联系人号码等。我们创建了一个通用的企业类，批发商等都是这个类的子类。

（5）信息传递：软件对象之间需要进行通信。例如：智能企业的商品销售。比方说，批发商A向一家零售店分发100件服装。然后，可以向库存实例发送带有100件服装的库存参数。当库存实例（即批发商A的库存）收到消息时，它执行相应的出站操作（在类中，称为出站方法）。

（6）多态性：两个或多个类（通常是继承的）接受相同的消息，但以不同的方式实现它。

2.面向构件的分析与设计

面向对象的软件设计方法所设计的对象粒度相对较细，实际上很难重用。在应用程序启动和系统集成中，粗粒度组件被越来越多地重用，这些粗粒度组件通过聚合更细粒度的对象来提供完全定义的功能。我们可以将企业的应用程序划分为一组大粒度的组件。面向对象的技术和语言经常被用来实现组件。

3.面向服务的设计

面向服务的软件设计将组件描述为提供相关服务的物理黑匣子，这些服务封装可执行代码单元。其服务只能通过一致发布的接口访问。组件必须能够连接到其他组件（通过接口）才能形成更大的组件。服务通常以粗粒度可调用软件实体的形式实现，这些实体作为单个实例存在，并通过松散耦合和基于消息的通信模型与应用程序和其他服务交互。

在面向服务的设计中，我们使用独立于实现细节的标准化接口构建服务。我们使用一组服务描述语言（例如WSDL）来描述服务的输入参数（例如，“库存查询”服务需要商品编号）和服务响应的细节（例如返回库存中的项目数，这是一个整数）。服务的请求者不需要知道实现服务的编程语言，可以用任何语言编写请求者。这允许一个平台上的服务与另一个平台上的应用程序集成。互操作性的关键是请求和响应消息，例如，使用SOAP消息。

智能公司提供了许多使用面向服务的设计方法设计的服务。面向服务的系统包括以下几种。

服务：逻辑实体，如在线订购服务。服务提供者实现服务软件。

服务使用者（或请求者）：调用服务提供者的软件。传统上，它被称为“客户端”。服务使用者可以是最终用户应用程序，也可以是其他服务。它既可以在外部系统上，也可以在自己的系统上。

服务总线：完成服务位置和代理函数。这是一种特殊类型的服务提供程序，它充当注册表，允许查找服务提供者的接口和位置。它还可以向一个或多个服务提供者发送服务请求。

4.各种设计方法的异同

与面向对象和面向组件的设计方法相比，SOA有以下区别：

服务组件倾向于粗粒度，而传统组件大多是细粒度的；

服务组件的接口是标准的，主要是由WSDL描述的Web Service接口，而传统的组件通常以具体的API形式出现；

服务组件的实现独立于编程语言，而传统组件通常绑定到特定语言。

与面向对象的分析和设计方法相比，SOA有以下区别。

面向对象方法的粒度级别集中在类级别上，这对于以服务为中心的SOA建模来说太低了。类关系（如继承）在类和类之间会产生一定程度的紧密耦合（因此也会产生依赖性）。SOA试图通过放松来提高灵活性。

对于设计服务中的底层类和组件结构，面向对象的设计方法仍然是一种有价值的方法。在智能企业系统中，我们使用面向对象的方法来设计服务中的类。

SOA的系统并不排除使用面向对象的设计来构建单个服务，但它的总体设计是面向服务的。因为它考虑到了系统中的对象，尽管SOA是基于对象的，但作为一个整体，它并不是面向对象的。区别在于接口本身。

（三）云服务的特点

云服务是根据SOA设计的，云服务之间存在松散耦合。云计算本身将软件系统看作是具有标准接口的服务的集合。对于不同的业务需求，企业可以通过将不同的服务（如构建块）组合在一起来构建一个新的业务系统。云服务具有以下特点。

1.松散耦合(www.xing528.com)

松散耦合要求云平台上的不同服务保持松散耦合关系，即相对独立和独立的关系；服务请求者（例如外部系统）与服务提供者（例如库存服务）的绑定也应该与服务松散耦合。这意味着服务请求者（例如外部系统）不知道提供者实现的技术细节，例如编程语言、部署平台等。服务请求者通常通过消息（即请求消息和获取响应）来调用操作，而不是通过使用API。

这种松散耦合允许服务软件在不影响另一端的情况下进行更改，同时保持消息模式不变。例如，服务提供者可以重写以前用Java语言用C+编写的库存服务，而不会对服务请求者产生任何影响（只要新代码支持相同的消息模式）。

SOA中的“松散耦合”是通过服务总线或其他服务代理完成的。服务总线向请求者隐藏尽可能多的技术细节。

2.明确定义的接口

服务必须具有一个明确定义的接口，该接口描述服务请求者如何调用服务提供者的服务。我们使用服务描述语言来描述服务。例如：Web服务描述语言（Web Services Description Language，WSDL）是一种广泛使用的服务描述语言。WSDL不包括服务实现的任何技术细节。

3.无国籍（无国籍）服务

服务不应依赖于其他服务的上下文和状态。服务应该是独立的。例如，在线用户登录服务和用户订单查询服务。一个典型的操作是：

外部系统调用联机用户登录服务，以确定用户名和密码是否有效；

外部系统调用客户订单查询服务，获取用户所下订单的信息。

然后，当调用第二个服务时，您不能假设平台已经通过调用第一个服务获得了用户的名称，因此在第二个服务调用中没有用户信息。如果存在此假设，则要求服务提供者记住状态信息。如果开发人员使用J2EE的EJB实现服务，则应该选择无状态会话。

4.使用粗粒度接口

服务的粒度很重要。太大，很难重用，太小，很难将业务操作与服务相匹配。服务是特定功能的完整过程。虽然云服务不一定需要粗粒度接口，但外部调用的服务通常使用粗粒度接口。当然，外部服务可以由细粒度的操作（或服务）组成。例如：在线订购服务，此服务调用库存检查、发货服务等。

5.位置透明度

位置透明度要求云平台上的所有服务对调用方都是透明的。也就是说，每个服务的调用者只需要知道他们正在调用哪个服务，而不需要知道被调用服务的物理位置在哪里。

6.协议独立性

我们建议可以通过不同的协议调用云服务。在这种情况下，其他设备，如移动电话，也可以访问云服务。

7.软件即服务

传统软件作为商品出售。在云计算平台上，软件作为一种服务被出售，这不同于传统的软件，因为软件服务每天都需要维护。

（四）设计云服务的原则

我们使用SOA来设计云服务。在SOA中，系统的体系结构通常由无状态、完全封装和自描述服务组成。在设计云服务时，需要遵循一些原则。

·精心策划的服务。它为业务带来了灵活性和敏捷性，通过松散、封装和隐藏信息使重构变得更容易。

·服务之间的依赖关系被最小化，依赖项被显式声明。

·服务抽象具有凝聚力、完整性和一致性。例如，在设计服务时，我们应该考虑创建服务对象（Create）、读取（Read）、更新（Update）、删除（Delete）和搜索（Search），概括为：Cruds。

·服务是无状态的。

·服务的命名和描述是面向用户的，无须专业知识就可以理解。

不要和现有的系统联系在一起。在大多数情况下，业务流程不仅仅是自上而下或自下而上的过程。如果我们考虑太多现有的IT系统而不是当前和未来的业务需求，那么自下而上的方法往往会导致糟糕的业务服务。

重用应该被认为是识别和定义服务的最重要的标准之一。如果组件（或服务）不可重用，则不能将其部署为服务。它可能连接到另一个服务，但它不能单独作为一个服务存在。服务定义为一组可重用的组件，可用于构建新的应用程序或集成现有软件。例如，客户可以在现有系统中调用云服务。

需要充分注意各种服务质量要求（例如响应时间），以避免系统运行时出现重大问题。企业系统中的服务质量要求往往非常复杂。

服务可以是低级（细粒度）函数，也可以是复杂的高级别（粗粒度）函数。应该在性能、灵活性、可维护性和可重用性之间进行权衡。

整个系统架构中的集成功能应该由服务提供，而不是由应用程序提供。

应该定义企业命名模式（例如XML名称空间、Java包名、Internet域名）。一个简单的方法就是总是用名词命名服务，用动词命名操作。

当SOA架构师构建云服务时，有两件事需要特别注意：首先是服务粒度的控制，然后是无状态服务的设计。

1.服务粒度控制

SOA系统中服务粒度的控制是一项非常重要的设计任务。通常，对于在整个系统之外公开的服务，推荐使用粗粒度接口，而在企业系统架构中通常使用相对细粒度的服务接口。从技术上讲，粗粒度服务接口可能是特定服务的完整执行，而细粒度服务接口可能是实现这个粗粒度服务接口的具体内部操作。

例如，对于基于SOA的在线商店，粗粒度服务可能是向外部用户公开的订单提交操作。系统中的细粒度服务可能是该订单提交服务的一系列内部服务，例如保存采购记录、设置发货信息、更新库存等。虽然细粒度的接口为服务请求者提供了更多的细化和灵活性，但它们也意味着引入了更多不可控制的交互可变性模式，也就是说，服务交互的模式可能因服务请求者而异。如果我们向系统的外部用户公开这些易于更改的服务接口，可能会使外部服务请求者难以适应更改服务提供者所暴露的细粒度服务接口。

粗粒度服务接口确保服务请求者以一致的方式使用系统中公开的服务。虽然面向服务的体系结构不需要粗粒度的服务接口，但我们建议将它们用作外部集成的接口。通常，架构师可以使用BPEL为由细粒度操作组成的业务流程创建粗粒度服务接口。

选择正确的抽象级别是服务建模中的一个关键问题。我们经常听到“使用粗粒度建模”的建议。在此应该修改为：尽可能使用粗粒度建模，而不会对相关性、一致性和完整性造成损失或损害。在任何SOA中，都有进行细粒度服务抽象（假设业务需求）的空间。由于SOA并不等同于Web服务和SOAP，所以可以使用不同的协议绑定来访问不同抽象级别的服务，另一种选择是将一些相关的服务绑定到粗粒度的服务定义中。

2.无状态服务的设计

使用SOA设计的特定云服务应该是独立的请求，在调用之前的服务请求时不需要它们的状态，也就是说，服务不依赖于其他服务的上下文和状态。SOA架构中的云服务应该是无状态服务。当云服务无依赖的时，最好将其定义为特定的业务流程。在云服务的实现机制方面，我们可以使用EJB组件来实现粗粒度的服务。我们通常使用无状态会话Bean来实现特定的服务。如果我们基于Web服务技术，则可以将无状态会话Bean公开为可由外部用户调用的Web服务。这样，我们就可以向Web服务客户提供粗粒度的服务。

（五）云服务的组成部分

对于特定的服务，系统设计人员应该主要关注服务可以向外部用户提供什么样的服务，即系统设计人员关心服务所提供的功能。对于SOA架构师来说，他们更关心的是当1000名用户同时调用该服务时会发生什么。换句话说，架构师应该将重点放在平台的选择、服务质量要求、服务接口等方面。

当我们开始建立一个系统时，我们应该尽量减少潜在的技术风险。技术风险通常指所有未知、未经证实或未经测试的风险。这些风险通常与服务质量需求相关，有时还与业务特定的业务需求相关。不管风险的类型如何，我们都应该在项目的早期阶段（设计整个系统架构的过程）探索这些风险。如果等到架构的实现来发现这些风险时，可能会导致大量开发人员在那里等待，直到这些风险得到适当的解决。

如果进一步细化，SOA架构设计人员的主要任务包括整个系统架构的构建、需求分析、体系结构的总体决策、相关组件的建模、相关操作的建模、系统组件的逻辑和物理布局设计。通过使用面向服务的体系结构，我们可以将应用程序功能作为服务提供给客户端应用程序或其他服务。当我们使用SOA构建软件系统时，除了系统的功能外，还关注可用性、性能问题、容错性、可重用性、安全性、可扩展性、可管理性、可维护性、可靠性等。

业务通信协议：通过所述通信协议，传输协议用于将服务使用者的服务请求发送给服务提供者，并将服务提供者的响应发送给服务使用者。

服务描述：描述什么是服务，如何调用它，以及调用它所需的数据。Service Broker（注册中心）是服务和数据描述的存储库，服务提供者可以通过它发布服务，而服务使用者可以通过服务注册中心找到可用的服务。

实际可用的服务：业务流程是一组服务的集合，可以特定的顺序调用这些服务，并使用一组特定的规则来满足业务需求。我们还可以将业务流程本身看作是一种更粗粒度的服务。

服务质量包括以下几方面。

安全管理是对服务使用者的身份验证、授权和访问控制的管理。

为每个服务定义其相关的QoS要求：性能、可伸缩性、可靠性、可用性、可伸缩性、可维护性、可管理性和安全性。在架构设计中，我们需要平衡所有这些服务质量要求。例如，如果最重要的服务质量要求是系统性能，我们可能会在一定程度上牺牲系统的可维护性和可伸缩性，以确保系统满足系统的性能要求。

为了确保云服务的服务质量和非功能性需求，我们必须对已部署的云服务进行监控和管理。