调解是一种使冲突方之间达成协调或妥协的干预行为。协调的三种常见形式在分布式系统中(广义上讲)和面向服务的解决方案中(狭义上讲)是必需的。
-
接口调解;在基于对象或组件的系统的接口中,调解是发送方和接收方之间操作定义的变更。 在面向服务的解决方案中,则将其视为发送方和接收方之间消息内容/模式并不一致。
-
协议调解;最常用的基于对象或组件的解决方案倾向于通过一个或一组通用协议进行通信。 在面向服务的解决方案中,在整个解决方案中混用多种协议是很普遍的,这是面向服务的体系结构的优点之一。
为了在服务间进行通信,消息必须涵盖发送方和接收方之间的各种不同协议。
-
操作调解;开发人员可能也熟悉这种调解形式。它与常用的策略模式有关。组件能够根据运行时参数或请求的内容,在某个特定服务或操作的一组实施中进行选择。 这也称为基于内容的路由。
非常值得注意的是,越来越多的中间件平台提供了高级调解功能,这使得不必单独开发调解组件。 在这种情况下,因为中间件会检测到数据结构或通信协议中的不一致,所以它能够在其运行时执行调解。
此外,这类平台可以提供充当开关的介体(基于消息内容和业务规则),从而能够为提供的服务使用者请求选择正确的实施。
在连接服务时,如果消息的定义不匹配或消息需要在发送方和接收方之间进行转换,则可以使用 UML 2.0 活动提供的功能来指示发送方和接收方之间的转换。 此功能对两个操作之间的 UML 2.0
行为与对象流进行关联,从而能够确定将消息转变为其他消息的可复用转换行为(具体来说,是根据 UML 2.0 规范变更或替换沿边缘流动的数据标记)。
如上所述,该转换是一个可复用的元素。因此,它可将一种消息类型转换为另一种类型,然后在调解发送和接收服务之间的消息时使用(如果需要)。 请注意,虽然 UML
提供了一组用于浏览、读取和更新结构的操作,但是这些操作比较复杂,这使得将它们用于定义转换过于困难。 该转换应当与更简洁的表示法相关联(请考虑 XSL/T 语言),或者与一种新的表示需要提供 UML 操作的方法相关联。
也可以将数据调解视为服务迭代的具体模式。例如,有一个显式的调解服务负责实施一个或多个数据转换。 在这种情况下,介体必须对服务使用者发送的消息作出响应、对该消息进行转换,然后将其转递给服务(如下所示)。
另一方面,协议调解在模型中得到了很好的表达和明确的支持。由于协议信息被指定为服务通道的绑定,因此可以引入改变协议规范的其他 <<服务>> 或 <<服务网关>> 模型元素。 例如,在以下组合结构图中,您将看到两个分区,一个对应于面向 Web
的服务,而另一个对应于内部服务,在这两个分区之间存在一个具有“HTTP-SOAP”绑定的服务通道,此类绑定对于面向 Web 的服务是很普遍的。
问题是,为了支持所需的性能级别和其他非功能需求、内部分区中的所有通信都通过特定于平台的协议进行。 下图说明了如何使用 Java RMI 协议将服务连接到服务网关“Port : ISvcTwo”,但随后 Web 分区如何使用
HTTP-SOAP 连接到同一网关呢?
答案是服务网关本身能够通过将消息结构和调用从一种格式转换为另一种格式来调解协议。 这是在一般情况下,诸如“对象请求代理”(ORB)或“消息代理”所提供的常见功能。 实际上,如果需要,可以从上述模型生成此类中间件,或者“Port :
ISvcTwo”自己可以具体化为一个服务,即从 Web 分区进行调用并将调用转送给附带的服务。
此外,可将调解显式地建模为一个服务(而不是服务网关),这将向服务使用者端绑定显现正确的接口,并将实施委托给具有其他绑定的服务提供者。
如介绍中所述,通常会定义一个结构,其中的一项服务通过某个操作依赖于另一项服务。但是,为任何特定请求调用的实际服务取决于该请求中内嵌的详细信息(请求者以及使用此信息应用的业务规则)。此结构的一个常见例子是客户请求,接收服务可以选择根据服务使用者的级别选择两个实施中的一个。例如,众所周知,付出较多费用的客户会得到优惠待遇。
如我们先前所述,在此类调解中,尝试将用于在实际操作实施的一个或多个提供者之间进行选择的规则具体化很重要。 在上图中,我们将此显示为一个与调解服务相连的规则组件。
显而易见,可以将解决方案构建为一组服务,其中介体、规则和所有实施都是独立的服务。 这可在下面看到。
正如您所看到的那样,调解组件不仅拥有其实现的服务规范,还拥有一个需要由其调解的所有服务来实施的服务规范。 这使我们能够同时定义服务的组合结构(上面所示)和下面所示的动态行为。
请注意,在上面的结构中,代表所调解服务的部分由需要的接口表示,并用无限多重性显示。
此外,此类基于内容或基于规则的消息路由可通过选为解决方案体系结构一部分的中间件平台来实现。
|