SOA五种基本架构模式及远程过程调用

SOA五种基本架构模式及远程过程调用
一、SOA五种基本架构模式
1.五个构建服务的SOA基本模式分别为：
边界组件：将接口（契约）从实现中分离出来以取得灵活性与可维护性
服务托管：使用通常包装器来托管服务实例并重用
主动式服务：在服务中使用至少一个独立线程来启动
事务处理服务：处理事务内部的消息并妥善处理故障
工作流化：在服务中添加工作流以提高灵活性

2.服务托管
　　它是最基本的模式，或者至少是最基本的模式之一。服务托管模式主要负责运行着服务实例的环境，以及与此相关的路由任务。
服务托管就像是一个肩负着许多职责的迷你框架。它的第一个职责就是正确地示例服务所包含的组件或类。服务托管还负责读取配置信息，比如，它可以读取服务消费者用来连接服务的端口。其它职责包括创建服务环境，比如在终端创建监听器。最后，服务托管可以负责连接组件——终端监听器上的协议绑定或者创建一个与数据库的连接。所有这些职责的共同特征是它们都与服务的实例化和初始化有关，你很可能会在多个服务中遇到同样的情况。服务托管是一个框架，与第二种方法中描述的库的概念有所不同。库是一个实用类或方法集，你可以调用它们来获取特定的功能。而框架则包含了一些功能或流程，并通过调用代码来扩展流程或将其转变为具体的流程。这就是“控制反转（Inversion of Control）”原理。这种原理已经在面向对象的框架中获得广泛的应用，比如Spring或Spring.NET、Picocontainers等。
　　服务托管模式与其它方法相比有许多优势。其中一个优势为服务托管是一种框架，它可以调用代码来改善性能，而无需你亲自进行编排。另一个优势是它能更好地实现开放/封闭原则（OCP）。OCP原则认为类应该是可以扩展的，但是不能修改；而框架的概念正是这个原则的具体表现。
　　一个服务托管可以托管多个服务——虽然这种情况可能并不常见。我们曾经构建了一个系统，使用的方案规模小到一台计算机即可应付。这真的很方便。如果换另一种方案，那么服务可能就要扩展到多台计算机上，这样你就得应用多个服务托管实例，各个主机托管服务的一部分，而不是整个服务。
重用性：减少开发时间 开发时，在20分钟内设定新服务的环境。
可移植性：安装 系统必须支持以服务为单位对服务器进行配置。安装过程中，从一个环境切换到另一个环境所用时间应该少于一小时。

3.主动式服务
　　服务的自治性（Autonomous）很重要。自治性能够提高服务之间的松耦合性，并使整体方案产生更好的灵活性。但是自治性服务有什么实际意义呢？有人说，自治性意味着在不同的服务上工作的团队的自治性。这种定义表示，由于各个服务之间只有契约上的关系，因此服务之间几乎没有依赖性。这意味着各团队可以独立工作，专心于自己的服务，而不会互相绊脚。虽然这是一个不错的“功能”，但是同时还有一个更有价值（比如说商业价值）的定义，就是服务是非常自主（self-sufficient ）的。
　　主动服务是一些其它模式的先决条件，而这些模式可以帮助处理质量属性问题，比如可靠性与可用性。并且，即使是单独使用主动服务模式也能满足许多质量属性要求。
　　过预先准备的数据，主动式服务可以减少一些潜在的问题。它可以解决期限的问题，因为它能保证服务在期限之前完成任务（比如按时生成每月账单）。另外，主动服务模式还有可用性的优势，因为从其它服务查询并缓存数据意味着减少了服务的可用性对其它服务的依赖性。
延迟：正常情况下，评估申请的效益只需要2秒不到的时间
期限：未满负载的正常情况下，系统可以每少刷新两次以上股票价格
可用性：正常运行时间，即使断开远程连接，用户仍然可以生成报价单

4.事务处理服务
　　事务处理服务模式的主要组件是消息泵（message pump）。消息泵监听着终端或边界传入的消息。如果接收到消息，消息泵就开始一个事务操作，读取消息，把消息发送到其它组件/类进行处理，处理后，结束事务操作（完成或失败）。如果可以以事务处理的方式发送请求或回应，就可以把这些操作放入到事务处理中，否则你就需要为操作失败准备补偿逻辑。
　　如果消息传输是对事务敏感的，那么实现事务处理服务就容易得多。大部分ESB（比如Sonic ESB和Iona Artix）都是事务敏感的，另外还有消息中间件（比如MSMQ）、所有JMS实现以及SQL Server Service Broker。如果你在使用事务消息传输，你可以通过仅仅在资源上创建一个事务来实现事务处理服务模式。如果，比如你还要在同一任务单元中进行更新数据库的操作，你可能还需要分布式的事务处理。然后只要从ESB或消息中间件读取消息、处理、发送响应或其它处理过程生成的消息到外部或目标队列，最后一切顺利的话结束事务。
　　要注意通常要在事务处理中用到多项资源，比如，一个消息队列和一个用于存储消息处理后的任何状态变化的数据库，这时你应该使用分布式事务处理。在.NET 2.0及以上版本中，如果有需要的话，你可以通过打开一个TransactionScope对象（定义于System.Transactions）显式地过渡到分布式事务处理。
　　如果消息传输不支持事务，只在你把消息存储到了事务存储库（比如队列或表）后有确认信息。你仍然有在没有得到服务消费者的确认的情况下处理事务的风险，因此你得做好再次接收请求的准备，以防确认消息丢失或根本就没有发送。如果出现故障，而处理传入的消息的事务向其它服务发送了消息，你也要准备好补偿逻辑。
可靠性：在任何情况下，凡是经过系统确认的消息都不会丢失
易测性：覆盖率，所有场景都能得到95%甚至更高的测试覆盖率

5.工作流化
　　工作流化模式是在服务中添加一个工作流引擎来驱动业务过程。工作流引擎中包含一个工作流实例（workflow instance）。最基本的形式是每个工作流负责一种请求类型；然而，工作流可以更复杂，处理连续的过程并且有多个接收外部服务请求或数据的入口点。
　　使用工作流的优势是可以以活动为构建块进行思考，从而更灵活、更轻松地安排流程。以活动流的方式建模过程意味着可以更容易地分辨并重用稳定的部分，直到有变化需求为止。既然活动可以进行自我测试，重用一个活动就代表你不用再进行大量的测试。而灵活地重新安排活动则代表你可以迅速地响应业务需求。
　　流程编排（Orchestrated Choreography）是一种与工作流化密切相关的模式；这两种模式都使用相同的底层技术：使用工作流引擎。不过，虽然底层技术一样，但是不同的架构考虑方式却会导致选择不一样的模式。比如，两者之间一个很明显的不同就是工作流化局限于一个单独的服务中，而流程编排则需要在服务间添加调整性工作流。
灵活性：添加过程，对于所有预付费方案，添加对新方案的支持只需要两天不到的时间。
重用性：核心模块，每个新方案可以重用90%以上的常用销售过程。

6.边缘组件 
　　最简单的（或许过分简单了）办法是不要做任何具体的变动。比如，直接把一部分逻辑当作Web服务。这对技术提供商的在线业务来说是很常见的，比如Microsoft (WCF)和 Sun (JAX-WS)提供的教程。然而，由于契约操作与业务逻辑实现直接纠缠在了一起，这给代码维护带来了极大的不便——比如，如果要支持场景1，用这种方法来替换技术可能就会非常困难。
　　我们可以通过在复制服务上替换新技术来解决前面的在当前服务中替换技术的问题，这种方法也叫“自我克隆（own and clone）”。不过这也会产生维护上的问题，因为你现在有了同一业务逻辑的多个复本，因此你得改动所有复本，并且这还解决不了场景3里要在多个服务上添加记录功能的问题。
　　由边界组件模式与许多质量属性有关。这些属性大多是由共同使用边界组件模式和其它模式产生的结果。然而，有两个质量属性是直接与边界组件模式相关的。第一个是灵活性——增强服务的适应性，提高服务的外部属性，并且不会影响到业务逻辑。第二个是易维护性——关注点分离（SoC）使各组件的行为更易于理解。回想一下上面三个场景——在当前服务中添加新技术、在不改变契约的前提下改变业务行为、以及迅速解决交叉问题——通过边界组件，我们可以在不影响方案的其它部分（或者至少将影响最小化）的情况下解决问题。下表列出了几个使用边界组件的示例场景。
易维护性：向后兼容性，随着契约的变化，服务应该能够使用老版本的契约为消费者提供支持（至少前两个版本）。
灵活性：扩展点，在将来一年之内，客户将需要SOX compliance和董事会的审计制度。

二、远程过程调用
远程过程调用包含如下步骤：
1.客户过程以正常的方式调用客户存根；
2.客户存根生成一个消息，然后调用本地操作系统；
3.客户端操作系统将消息发送给远程操作系统；
4.远程操作系统将消息交给服务器存根；
5.服务器存根调将参数提取出来，而后调用服务器；
6.服务器执行要求的操作，操作完成后将结果返回给服务器存根；
7.服务器存根将结果打包成一个消息，而后调用本地操作系统；
8.服务器操作系统将含有结果的消息发送给客户端操作系统；
9.客户端操作系统将消息交给客户存根；
10.客户存根将结果从消息中提取出来，返回给调用它的客户存根。
　　以上步骤就是将客户过程对客户存根发出的本地调用转换成对服务器过程的本地调用，而客户端和服务器都不会意识到中间步骤的存在。
　　RPC 的主要好处是双重的。首先,程序员可以使用过程调用语义来调用远程函数并获取响应。其次,简化了编写分布式应用程序的难度,因为 RPC 隐藏了所有的网络代码存根函数。应用程序不必担心一些细节,比如 socket、端口号以及数据的转换和解析。在 OSI 参考模型,RPC 跨越了会话层和表示层。


以上部分内容来自如下
版权声明：CSDN博主「judyge」的原创文章，遵循CC 4.0 BY-SA版权协议
原文链接：https://blog.csdn.net/judyge/java/article/details/41080731