IT架构师该如何对应用程序实施SOA架构
围绕SOA的宣传热潮似乎是一浪高过一浪。软件提供商和分析师乐于向媒体提供信息，借此大肆吹捧自己的产品和技术特点。一些提供商声称他们的产品为实现SOA不断努力，另一些人尽管可能正在或多或少的使用着这些产品，但他们更愿意认为SOA在更大的程度上只是一种架构模式。
不论市场上有什么样的说法，重要的是要认识到任何一个SOA基础架构产品都是实现SOA的方法之一，是人们在实现SOA这一路走到现在的一个里程碑，但同时，这并不意味SOA的完结，SOA本身还要继续发展。平台软件能够为整个企业的服务架构，提供必要的主干网络，但是选择怎样的方案只能依据企业的具体需要来定。
目前普遍使用的企业服务总线(enterprise service bus，ESB)就是这样一类软件。最近的一些创新产生了一些搔动和困扰。所有的ESB提供商都说使用他们的ESB产品为面向服务的技术架构提供核心组件。然而，大多数提供商仍然是努力组成一个ESB，他们的产品仅仅具有普通ESB应该具备的功能。
设身处地想象一下，作为IT架构师，负责对应用程序实施SOA架构。你应该作些什么?这真的非常简单，你只需回到业务需求一块，只要服务调节指挥和架构模型能够满足业务需求即可。
服务调节
调节(Mediation)并不是一个新概念。在传统的面向对象的文献中,众所周知, 调节者(mediator)是推动“松耦合”(loose coupling)的一种模式, Mediator可以用来控制和协调这些对象间的相互调用,避免他们之间的复杂调用造成混乱甚至死循环,同时使逻辑更加清晰,需要改变某些逻辑时也很容易实现。
用服务替代上一句中的对象,这样你就可以很好地理解什么是服务调节。然而, 在SOA中服务调节不仅可以用来控制和协调这些服务间的相互调用(尽管这种相互间的调用是一个好的开始)。在强调技术中立性的服务世界里, 基于XML的信息交互作用更可以使多事情都变成可能,只要你在服务生产者和服务消费者之间放置一合格的调节者。
传输协议转化
通常,服务提供商基于某种传输协议(例如HTTP)提供服务,而服务消费者只能通过另一种不同的协议(比如MQ)通信。 因此,也许需要在服务提供商与消费者之间建立一座异步起动同步运行的连接桥梁,超越HTTP和Java Messaging Service消息服务(JMS)等协议.从技术角度讲, Java Messaging Service消息服务(JMS)并不是一种传输协议,而是一组供应商中立(vendor-neutral)的通信APIs。正如图1所示,异步Web服务实施通常表现为 “简单对象访问协议(SOAP)服务在JMS之上,”而在使用传输协议的背后是供应商特定(vendor-specific)的,如MQ或Tibco RV。
这种现象在有很多遗留软件的环境中非常普遍,这些遗留软件的服务已被开启,而其它应用程序却因为传输协议不配不能使用这些服务。与其建立一个新的协议适配器或在执行服务提供商的基础上实施异步起动同步运行桥梁,还不如让调节者来解决这些差异不同,做必要的转换。这样服务开发人员只需要集中精力解决服务逻辑问题,可以让基础结构软件负责调节责任。
数据格式转化
即使在同一机构中,不同部门对于业务实体的定义也会不一样。财务部可能有特别的客户结构,它区别于从开发帐单角度定义的客户。这种情况下,一个开发帐单中与客户相关的服务就不能在没有弄清数据模型区别的情况下采用财务部的服务。
你可以努力使每个人都接受一个公共的定义(如使用被提议的标准数据模型),不过这种方法在大型机构中可能并不十分有效。最好的方法就是让斡旋组件来解决不同格式的转化问题.甚至可以让服务接口只处理标准数据模式,不过服务消费者则将需要配置斡旋组件来转化其数据格式,使之成为服务提供商要求的数据格式。
执行服务政策
让调节者来解决服务提供商与服务消费者之间的交互问题,这使得在两者之间阻止XML传输变得十分简单,需要采取必要的步骤来保证政策的执行—例如以适当审查,日志监测和安全检测的方式。
其次,以调节组件代替这些横切关注点(cross-cutting concerns)使服务开发人员不需要一定在服务层满足调节需求.当然,如果这是你面临的唯一调节需求,那么实施像面向方面编程(Aspect-oriented programming,AOP)这样的基于技术的横切解决方案是最划算的。
服务处理器传输途径
传输途径和过滤器架构模式介绍了多用途消息预处理程序和后置处理程序如何提高消息处理循环速度。一个调节平台能够以宣告的形式为服务呼叫构成这样的过滤器，允许我们通过改变过滤器配置，改变这些呼叫预处理和后置处理组件的顺序。
这些预处理程序包括消息内容基础上的服务路径，背景或业务规则，消息富集，消息加密/解密，消息复制等等(如图1)。在这里，调节的核心价值不是在于能够提供一些开发者无论如何都要创建的处理程序，而是在于它能在宣告的形式下使任意处理程序的组合变得简单易行。
服务呼叫与调度
还记得关于服务提供商与服务消费者之间“松耦合”(loose coupling)的部分吗?如果服务消费者直接与服务提供商相互作用，那么在不影响服务消费者的情况下改变服务提供商的接口(不是实施，无论如何实施独立于接口)会是个难题。换句话说，服务消费者永远都与服务提供商紧紧地联系在一起。
然而，如果服务消费者只与中间人调节相互作用，同时调节服务保证不改变它与服务消费者接口，那么很显然调节者可以为不同版本的服务派发服务呼叫，甚至是对不同服务接口。很明显，这种情况下仍然需要调解诶(就是必要的转化)，但是重要的是，它使服务消费者与服务提供商相对独立。
服务编制
与服务调节不同，服务调节本质上就是配置一个中间组件作为实时中间件的一部分，而编制具备与服务内容和服务实施相关的功能。编制技术也是基于中间件，它能建立一个高度集中的架构，来管理设计业务流程的定义以及业务流程逻辑的操作执行。
不论市场上有什么样的说法，重要的是要认识到任何一个SOA基础架构产品都是实现SOA的方法之一，是人们在实现SOA这一路走到现在的一个里程碑，但同时，这并不意味SOA的完结，SOA本身还要继续发展。平台软件能够为整个企业的服务架构，提供必要的主干网络，但是选择怎样的方案只能依据企业的具体需要来定。
目前普遍使用的企业服务总线(enterprise service bus，ESB)就是这样一类软件。最近的一些创新产生了一些搔动和困扰。所有的ESB提供商都说使用他们的ESB产品为面向服务的技术架构提供核心组件。然而，大多数提供商仍然是努力组成一个ESB，他们的产品仅仅具有普通ESB应该具备的功能。
设身处地想象一下，作为IT架构师，负责对应用程序实施SOA架构。你应该作些什么?这真的非常简单，你只需回到业务需求一块，只要服务调节指挥和架构模型能够满足业务需求即可。
服务调节
调节(Mediation)并不是一个新概念。在传统的面向对象的文献中,众所周知, 调节者(mediator)是推动“松耦合”(loose coupling)的一种模式, Mediator可以用来控制和协调这些对象间的相互调用,避免他们之间的复杂调用造成混乱甚至死循环,同时使逻辑更加清晰,需要改变某些逻辑时也很容易实现。
用服务替代上一句中的对象,这样你就可以很好地理解什么是服务调节。然而, 在SOA中服务调节不仅可以用来控制和协调这些服务间的相互调用(尽管这种相互间的调用是一个好的开始)。在强调技术中立性的服务世界里, 基于XML的信息交互作用更可以使多事情都变成可能,只要你在服务生产者和服务消费者之间放置一合格的调节者。
传输协议转化
通常,服务提供商基于某种传输协议(例如HTTP)提供服务,而服务消费者只能通过另一种不同的协议(比如MQ)通信。 因此,也许需要在服务提供商与消费者之间建立一座异步起动同步运行的连接桥梁,超越HTTP和Java Messaging Service消息服务(JMS)等协议.从技术角度讲, Java Messaging Service消息服务(JMS)并不是一种传输协议,而是一组供应商中立(vendor-neutral)的通信APIs。正如图1所示,异步Web服务实施通常表现为 “简单对象访问协议(SOAP)服务在JMS之上,”而在使用传输协议的背后是供应商特定(vendor-specific)的,如MQ或Tibco RV。
这种现象在有很多遗留软件的环境中非常普遍,这些遗留软件的服务已被开启,而其它应用程序却因为传输协议不配不能使用这些服务。与其建立一个新的协议适配器或在执行服务提供商的基础上实施异步起动同步运行桥梁,还不如让调节者来解决这些差异不同,做必要的转换。这样服务开发人员只需要集中精力解决服务逻辑问题,可以让基础结构软件负责调节责任。
数据格式转化
即使在同一机构中,不同部门对于业务实体的定义也会不一样。财务部可能有特别的客户结构,它区别于从开发帐单角度定义的客户。这种情况下,一个开发帐单中与客户相关的服务就不能在没有弄清数据模型区别的情况下采用财务部的服务。
你可以努力使每个人都接受一个公共的定义(如使用被提议的标准数据模型),不过这种方法在大型机构中可能并不十分有效。最好的方法就是让斡旋组件来解决不同格式的转化问题.甚至可以让服务接口只处理标准数据模式,不过服务消费者则将需要配置斡旋组件来转化其数据格式,使之成为服务提供商要求的数据格式。
执行服务政策
让调节者来解决服务提供商与服务消费者之间的交互问题,这使得在两者之间阻止XML传输变得十分简单,需要采取必要的步骤来保证政策的执行—例如以适当审查,日志监测和安全检测的方式。
其次,以调节组件代替这些横切关注点(cross-cutting concerns)使服务开发人员不需要一定在服务层满足调节需求.当然,如果这是你面临的唯一调节需求,那么实施像面向方面编程(Aspect-oriented programming,AOP)这样的基于技术的横切解决方案是最划算的。
服务处理器传输途径
传输途径和过滤器架构模式介绍了多用途消息预处理程序和后置处理程序如何提高消息处理循环速度。一个调节平台能够以宣告的形式为服务呼叫构成这样的过滤器，允许我们通过改变过滤器配置，改变这些呼叫预处理和后置处理组件的顺序。
这些预处理程序包括消息内容基础上的服务路径，背景或业务规则，消息富集，消息加密/解密，消息复制等等(如图1)。在这里，调节的核心价值不是在于能够提供一些开发者无论如何都要创建的处理程序，而是在于它能在宣告的形式下使任意处理程序的组合变得简单易行。
服务呼叫与调度
还记得关于服务提供商与服务消费者之间“松耦合”(loose coupling)的部分吗?如果服务消费者直接与服务提供商相互作用，那么在不影响服务消费者的情况下改变服务提供商的接口(不是实施，无论如何实施独立于接口)会是个难题。换句话说，服务消费者永远都与服务提供商紧紧地联系在一起。
然而，如果服务消费者只与中间人调节相互作用，同时调节服务保证不改变它与服务消费者接口，那么很显然调节者可以为不同版本的服务派发服务呼叫，甚至是对不同服务接口。很明显，这种情况下仍然需要调解诶(就是必要的转化)，但是重要的是，它使服务消费者与服务提供商相对独立。
服务编制
与服务调节不同，服务调节本质上就是配置一个中间组件作为实时中间件的一部分，而编制具备与服务内容和服务实施相关的功能。编制技术也是基于中间件，它能建立一个高度集中的架构，来管理设计业务流程的定义以及业务流程逻辑的操作执行。
