SOA是旧瓶装新酒吗？

我不懂你举这个例子是什么意思。如果OA使用的用户库跟HRM不是同一个，并且OA不提供“增加用户”的接口，管你SOA还是什么A，难道OA那边就会自动加上一个新用户了？

其实，如果真的象它所说的那样的话，web service要不要上，也值得探讨。同一局域网内的多系统互通问题，完全可以利用socket通讯，约定交易码，报文。似乎要来的更快些，更何况不是每一个人都很熟悉web service。这种情况在真正应用中也是直接采用socket通讯的居多。WS有必要吗？很值得怀疑。想起WSDL，UDDI，SOAP我就有点头晕。

to firebody：
这种时候肯定应该照web service的思路来设计。第一，socket通讯的Java编程比web service来得复杂。第二，你怎么知道OA和HRM系统一定会在同一局域网内？我觉得这个假设是很可疑的。

第一，socket通讯的Java编程比web service来得复杂
有点草率了吧，如果严格约定报文格式，报文编码采用ASCII编码标准，那么，这样的底层通讯并不比WS复杂，我最近做的与银行通讯的前置机系统正是采用这样的方式，感觉底层可以很好的封闭，而且也很容易开发，2－3天的功夫就基本搭建完。
采用WS的话，工作量评估下来，肯定要比这多的多！还不包括对方投入的技术培训，当然了，WS具有的优势是我永远追随它的动力源泉，虽然我这里的例子显然有点不大合适，但是我想，采用WS确实有很多因素需要考虑
一、开发工具的购买。成本上升
二、繁琐的开发，发布、注册、部署步骤
三、三个系统对接，如果你采用WS开发，那么别的两个系统都必须跟着你作WS的部署。
四、WS实时通讯的技术评估我不知道到底怎样？
五、同步异步的良好支持
六、技术培训的成本

考虑下来，让人望而却步

别的不说，socket通讯能不能做到Hessian或者Axis这样的面向对象的remoting，我感觉很困难（当然也可能是我缺乏这方面的了解）。如果remoting上面没有对象只有结构化消息，这就不是SOA，因为系统之间只有通讯，却没有面向对象的架构概念。

真是没有搞清楚状况就争起来了。
WS，Socket是两种技术的名称，具体的实现方式千差万别，有基于已有架构的，有自己从头做的，难易程度能简单比较吗？

gigix有点为了SOA而SOA的倾向了。
不过按照发展的观点看WS应该比socket便宜，这一点上firebody说的五点又只能被认为是针对目前暂时的状况。毕竟WS可以有工具的支持，而socket不管你怎么用工具，都是在底层自己干苦力。不过目前确实没有WS的便宜工具，但是有必要的话就会有很多人出来制造这个工具。开源软件的好处就在在这个地方体现了。

完全可以设计出一个面向对象的底层通讯模块来，我的系统就是这么设计的。但是，确实是比较复杂的处理，报文的格式需要严格定义，可以采用XML，或者类XML的报文（分隔符预定便是其中之一），这样的话，底层是很容易将报文解析成一个对象的。当然免不了一番报文格式的约定，配置等等。

web service的便宜工具早就有了，像axis啦，WSDL4J啦，而且关键是很多异构平台（例如XUL、FLASH）上早就实现了类似的便宜工具。

有道理，架构干的其实就是攒巴攒巴这种事儿