浅谈SOA服务及操作细分

自SOA服务架构产生至今，已有数十个年头，无论是在传统的金融、政府、制造业，还是创新性的互联网、电商行业，SOA的影子已普遍存在。

虽然SOA的影子无处不在，但是至于SOA服务架构中，经常被问到的几个问题，却很难让人回答，问题：什么是服务？什么是操作？

就我个人多年的从事该行业经验而言，服务是提供了某一服务块的操作抽象，操作是提供了服务块中完成某一块功能的抽象。并且服务与操作之间无明确界限，且可相互转换，服务发展到某一阶段可变成操作，操作某一阶段可变成服务。接下来将分三个段落分别阐述以上几个观点。

观点1：服务来源于现实业务需求。

回顾千年历史发展，这个世界中的每个细节之间，都有互相关联影响，有没有什么东西（物品、事件，一种统称的抽象）与其他事物一点关系都没有？答案是肯定的，没有。任何事情都有因就有果，有果就有因。因此对于服务而言，对于没有任何意义的服务是不存在的，服务产生的意义或作用都可以抽象为业务需求。

观点2：服务是提供了某一服务块的操作抽象，操作时提供了服务块中完成某一块功能的抽象。

服务来源于现实业务需求，业务驱动模型，模型驱动设计，设计产生服务，服务细化产生子服务或操作。相信能看到此文的各位看官，现实中都经历过银行转账，银行转账业务初始就是完成了转账功能。一笔完成的转账应该包含收款账户信息校验，资金明细查询等，这些属于转账业务的子功能块，可称为操作。

观点3：服务与操作之间无明确界限，可互相转换。

先说操作转换为服务，从银行成立之初（有银行概念的时代），应该没有独立的划分，它应该属于银行某一个服务的子类，并且该子类从当时的角度看，应该实属这个服务的操作，但是随着银行业务的不断发展，转账业务逐渐完善，包括收款账户信息校验，转账明细查询，转账类型丰富（网银转账，手机银行转账等），伴随着转账业务的不断完善，转账操作进行了细化，产生了转账服务，转账服务下面存在多个操作，并且现在互联网的快速发展，手机银行和网银转账又细化出业务需求（多方面原因，其一，业务需求创新，其二，服务到达瓶颈），包括各自的账户、转账额度等。周而复始，依次类推，操作逐渐过渡到服务。现在开始说服务转换为操作，还是举个例子吧，以联系人管理服务为例，联系人管理包括：基本信息管理（姓名、性别），手机号码管理（姓名、电话号码），所属行业及公司管理（姓名、行业、公司名称），其他联系管理（姓名、邮件、传真、QQ号、微信号、微博号等）等，如此众多的与联系人相关的操作，管理和维护非常不方便，经过公司或个人的讨论及分析，发现联系人管理可归纳为一个联系人管理（姓名、性别、出生年月、联系电话1，联系电话2，联系电话3，邮箱1，邮箱2，邮箱3，传真1，传真2，QQ号1，QQ号2，QQ号3，微信号1，微信号2等），这样在管理维护管理人信息就方便的多，而且也满足需求，节省资源。

总结：服务何时细分为操作，服务何时合并为操作，这个是多方面综合考虑的结果。具体可详解如下示意图：

以上观点均属于本人从事SOA实施行业多年个人经验及个人感悟，如有不当之处，请不吝指教，谢谢！

本文转载自异步社区。

原文链接：https://www.epubit.com/articleDetails?id=NC7E3EF91EAE00001B8A1F270C36A1E0D