SOA的由来，服务整合的进化史

来源：互联网发布：快手视觉冲击软件编辑：程序博客网时间：2024/04/29 10:23

现在SOA很时髦，好像哪个系统不喊上两句与SOA相关的口号或者与之挂上点边就觉得很落伍。

SOA是什么，字面意义是面向服务的架构，好像很容易理解，又很空洞，说了半天还是半懂不懂。

本文试图就"什么是SOA"，"SOA的应用场景"用一个进化的模式给出一个非常简单的答案，欢迎大家拍砖!

因为对轻量级的Spring容器比较熟，这里的技术大部分采用Spring的解决方案，其他的方案思想是类似的。

关键字：SOA, ESB, Spring, Integration, IoC, JMS, ActiveMQ, Http Invoker

一、异常简单的需求

一个注册系统，注册时需要对信息进行验证。

二、石器时代：面向过程时的解决方案；

public void register(String userName){ if (userName.equals("leo")){ System.out.println("The one is a good guy."); }}

慢慢地，编程人员觉得校验逻辑可能会有变化。本着把"变化"的内容抽象出来的原则，我们把验证的逻辑剥离为一个独立的方法：

public void register(String userName){ if (validate(userName)){ System.out.println("The one is a good guy."); }}public boolean validate(String userName){ if (userName.equals("leo")){ return true; } return false;}

三、青铜器时代：面向对象的解决方案

再后来，验证的逻辑越来越复杂，一个内部方法已经不能满足需要，于是将验证逻辑独立出一个类，再后来成为一个接口，有不同的实现，在register时通过延迟加载实现类来满足不同逻辑的验证规则。Spring的IoC, 也就是依赖注入是这方面的一个很好的应用。

public class Register { private Validator validator; public void setValidator(Validator validator) { this.validator = validator; } public void register(String userName){ boolean result = validator.valid(userName); if (result){ System.out.println("No problem, the guy passed the authentication."); }else{ System.out.println("Keep an eye on, this guy have a crime history."); } }}public interface Validator { public boolean valid(String userName);}public class ValidatorImpl implements Validator { public boolean valid(String userName) { if (userName != null && userName.equals("leo")) return true; return false; }}

Spring的配置如下：

四、电汽时代：分布式解决方案

在后来，由于系统规模越来越大，迫于scalability的原因，需要将不同的业务逻辑部署到不同的应用上。于是将注册的业务逻辑放在应用A上面，将验证逻辑放到应用B上面。

两个应用独立、分布运行，可能机房也不在一起。

应用分开了，但是注册的需求还需要验证，怎么办呢，就有了远程方法调用。相关的技术有Web Service, RMI, Burlap, Hessian, HttpInvoker等等，都属于同步调用。

让我们把需求再具体一点，举个现实中的例子。比如在淘宝(TAOBAO)上开店卖东西要先注册卖家，而卖家用户需要先通过公民身份核查中心(NCIIC)的身份验证。

这时，在TAOBAO和NCIIC两边都已经有了自己的遗留系统，我们需要整合原有系统来实现新的业务逻辑。

要整合这两边的系统，该动那边的代码呢？估计那边都不愿意修改自己的系统源代码。那么有什么办法能尽可能不动源码还能实现服务的整合呢？

幸运的是，TAOBAO和NCIIC的应用都是基于Spring的。我们先通过HttpInvoker的方式来实现远程方法调用的配置。

在NCIIC端，其需要将自己的validator暴露为一个HttpInvoker的url，配置如下：

<bean name="/validator-http" class="org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter"> <property name="service" ref="validator" /> <property name="serviceInterface" value="org.springframework.security.providers.rcp.RemoteAuthenticationManager" /></bean> <bean id="urlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping"> <property name="mappings"> <props> <prop key="/validator-http"> /validator-http </prop> </props> </property></bean>

首先，两边都不想改代码，处于安全的原因甚至不想把自己的代码甚至服务实现的class文件给对方。但是，接口文件还是可以给的，因为里面没有任何逻辑。

所以，TAOBAO的一个家伙跑到NCIIC那里，要到了一个身份验证的接口class文件:Validator.class

在TAOBAO端，可以进行如下配置：

<bean id="validator" class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean"> <property name="serviceUrl"> <value> ${protocol}://${serverName}:${httpPort}/${contextPath}/spring/validator-http </value> </property> <property name="serviceInterface"> <value>leo.demo.rpc.httpinvoker.Validator</value> </property> </bean><bean id="register" class="leo.service.Register"> <property name="validator" ref="validator" /></bean>

接下来，然后，TAOBAO的系统就可以运行了。

怎么样，这种方式还是不错的吧，不修改任何代码，只需要进行接口的配置，it's awesome, right?

五、信息时代：异步解决方案

上面的例子很不错，但是考虑到NCIIC要为很多客户服务，有时不能保证系统的响应速度，遇到高峰时可能慢的不可接受，那么这时，如果你是TAOBAO负责卖家身份验证的兄弟姐妹，你就可以每提交一个验证请求，就跑出去看个报纸，逛个街，喝杯咖啡之后再回来了。生活真是美好，是吧？

可惜，你的老板不会让你这么舒服。一大堆卖家资料需要验证呢，所以不会同意这种同步的技术方案，需要像星巴克的收银员一样不停地收钱，然后将订单提交给下面的工种。也就是采用异步的方式。

异步？那不就是用消息中间件，JMS什么的嘛。那岂不又要编写一大堆代码？

这次，我们还是很幸运，因为有了Spring Integration。我们依然只需要通过配置就能实现这些复杂的逻辑，甚至不需要编写一行代码。

怎么做呢？不要急，我们慢慢来。

因为是TAOBAO要享受服务，所以TAOBAO要多卖卖力气。在TAOBAO端先搭建一个JMS Provider，比如：ActiveMQ. 建两个队列：queue.request, queue.response。

然后依然是修改配置文件。

在NCIIC端，配置如下：

大功告成!

这回就可以异步地实现方法的调用了。一样没有写任何一行代码，就实现了通过JMS进行服务整合。是不是很cool , 很awesome？!!

当然，这个例子里因为validate方法有返回值，相应地配置成了"类同步"模式，执行validator.validate(userName)时，线程会等待（后台执行doSendAndReceive())，当然我们也可以不用获得响应。只要配置inbound-gateway的Channel变化一下就可以了。

六、总结

这就是一个服务整合的进化过程。你会不会说：这不就是把简单的事情复杂化吗？（俗一点的说法：脱了裤子放屁？）

没错! 原本很简单的一个代码调用，在不同的应用场合，被不同的商业的、政治的客观因素所限制，其调用就会变得很复杂。（从这点上说：好像一个人可以把很简单的事情用很复杂的办法做出来，这个人就可以算是个牛人。开个玩笑，呵呵）

这就是SOA.