你可以努力使每个人都接受一个公共的定义(如使用被提议的标准数据模型),不过这种方法在大型机构中可能并不十分有效。最好的方法就是让斡旋组件来解决不同格式的转化问题.甚至可以让服务接口只处理标准数据模式,不过服务消费者则将需要配置斡旋组件来转化其数据格式,使之成为服务提供商要求的数据格式。
执行服务政策
让调节者来解决服务提供商与服务消费者之间的交互问题,这使得在两者之间阻止XML传输变得十分简单,需要采取必要的步骤来保证政策的执行—例如以适当审查,日志监测和安全检测的方式。
其次,以调节组件代替这些横切关注点(cross-cutting concerns)使服务开发人员不需要一定在服务层满足调节需求.当然,如果这是你面临的唯一调节需求,那么实施像面向方面编程(Aspect-oriented programming,AOP)这样的基于技术的横切解决方案是最划算的。
服务处理器传输途径
传输途径和过滤器架构模式介绍了多用途消息预处理程序和后置处理程序如何提高消息处理循环速度。一个调节平台能够以宣告的形式为服务呼叫构成这样的过滤器，允许我们通过改变过滤器配置，改变这些呼叫预处理和后置处理组件的顺序。
这些预处理程序包括消息内容基础上的服务路径，背景或业务规则，消息富集，消息加密/解密，消息复制等等(如图1)。在这里，调节的核心价值不是在于能够提供一些开发者无论如何都要创建的处理程序，而是在于它能在宣告的形式下使任意处理程序的组合变得简单易行。
服务呼叫与调度
还记得关于服务提供商与服务消费者之间“松耦合”(loose coupling)的部分吗?如果服务消费者直接与服务提供商相互作用，那么在不影响服务消费者的情况下改变服务提供商的接口(不是实施，无论如何实施独立于接口)会是个难题。换句话说，服务消费者永远都与服务提供商紧紧地联系在一起。
然而，如果服务消费者只与中间人调节相互作用，同时调节服务保证不改变它与服务消费者接口，那么很显然调节者可以为不同版本的服务派发服务呼叫，甚至是对不同服务接口。很明显，这种情况下仍然需要调解诶(就是必要的转化)，但是重要的是，它使服务消费者与服务提供商相对独立。
服务编制
与服务调节不同，服务调节本质上就是配置一个中间组件作为实时中间件的一部分，而编制具备与服务内容和服务实施相关的功能。编制技术也是基于中间件，它能建立一个高度集中的架构，来管理设计业务流程的定义以及业务流程逻辑的操作执行。
文章来源于领测软件测试网 https://www.ltesting.net/
