SOA穿着华丽外衣的苦力

　　长期以来，由于IBM等大的厂商，声嘶力竭、不遗余力的宣传，SOA开始在江湖盛传，但掌握着是否实施SOA的权力，掌握在高层的领导手中，而IBM的Sales，则将天花乱坠的Solution，很容易的输入到领导的大脑当中，SOA成为无所不能的利器，而领导对于实施SOA，来改变当前混乱的局面，寄于很高的期望。
　　而无论是在IBM、BEA、Oracle等大牌厂商，还是Mule等开源方案，都没有真正的案例，来提供很好的异构系统通信的解决方案，而这正是很多大公司长期以来，所希望解决问题。
　　最近在做一个公司的一个信息集成的工作，由于客户在长期信息化的过程当中，积累了多个IT遗留系统，在工作开始，客户便指定SOA作为一个基础架构的方案。
　　但实际上，客户当中的多个遗留系统当中，一部分是基于ASP＋SQLSERVE的系统，一部分是Jsp + Oracle系统，同时这些系统，物理位置也是分散在各地的。
　　而客户由于预算的原因，原则上在原有系统上不做较的大改造。
　　我研究了这些产品，没有这方面很好的支持，对于基于Java的集成当然是比较容易，但对于异构的支持，仍然要做大量的工作，例如让ASP系统来提供Webservice无异行不通，只能通过Http等通信方式来进行XML数据交换。仍然要写很多丑陋的代码，一些技术人员希望在内网通过异构数据库之间的数据交换方式或通过将存储过程发布服务的方式来解决问题，这无异又将服务直接依赖于底层数据格式上，背离了SOA的原则。
　　这也就算了，但领导受Sales的影响，固执的认为可以很容易的进行集成，给开发造的预算很少，都放在购买产品和服务上了。
　　

没那么难 ms系统用asp脚本将接口需要的数据显示成xml  java系统用jsp也如此这般 

然后这两个系统就可以相互调用数据了 不过这样需要改现有系统 依然很不好

最好的办法是在这两个系统之外再建立一个系统 来调用它们。 

用ods集成？

一分钱一分货, 没钱就少做点.
这倒不是SOA的问题, 而是你们领导决策的问题, 差点被误导...

to OneEyeWolf：
这并不是SOA让你不知所措，而是你（包括你们的公司）误解了SOA。
早就在在说SOA不是"Web Service Orient"，而是“Service Orient”。所以不说SOA就一定需要把信息转换成WS，然后进行通信交互，这是非常的误解。
希望这篇文章可以帮助你理解：
http://blog.csdn.net/james999/archive/2007/07/08/1683075.aspx

你的文章很棒，看了很受教。

是的，从SOA产品上来说，提供了多种数据交换方式或服务调用交互方式的支持，我上面，也说了Http是一种方式，还有更多的，如：JMS，Socket，EJB，WS，还可以自己定义。

我只是感言，实施起来，并不是很爽，而已。

SOA更像是教练，在战术、意识、整体配合，而运球过人、临门一脚，还要靠自己。规范、标准、框架总是落后于实际的需求，在实施时，还要灵活运用自己的经验技术。

我自己现在还处于在战术、意识上的一个接受阶段。

其实SOA什么也没说
啥是服务啊,不就是软件接口么,谁家的系统不是面向软件接口架构的呢?
而且"面向软件接口架构"这个说法太没新意了,于是就叫SOA了

他们知道忽悠不了程序员,只能忽悠那些不懂技术的领导
于是在领导面前说得天花乱坠,在程序员面前就说"SOA只是一种架构风格"云云
于是,程序员就成了苦力,领导成了傻子

同意。不管SOA是好是坏，领导就认为SOA能解决一切问题。