SOA宣称的一大优势是异构系统服务整合,最大化利用现有的，旧系统的功能。
但怎么热论的都是B/S结构的，基于WebService的系统之间的SOA解决方案呢？甚至大多都是基于java的，也有.net和java之间的，但这有什么稀奇的呢？ 在SOA这个概念出来之前， B/s结构的系统之间通信，整合方法本来就很多（http,xml,soap,webservice等等），SOA只不过把这些方法归拢，并形成一个标准的模式，也即包装而已。当然SOA提出的构建系统的理念还是很值得吸取的。
问题在由，SOA强调的它最大的功能就是，异构，任何语言编写的，新的，旧的系统之间都能共享服务，数据。
那么如果是3个旧的系统(C/S结构的)，分别用vb, delphi, c++ 或者其它任何语言编写的系统之间，如何通过应用SOA来让这三个旧的系统协同工作，服务，流程，数据共享呢？ 如果有办法，那是否需要花费大量的时间对这些系统进行重新开发呢？
如果没有办法，或有办法太花费的代价太大，那是不是可以说，能够应用SOA这个概念进行整合的系统，其开发时必须遵守SOA的标准规范呢？ 如果不遵守，将不能应用SOA, 或者说将付出很大的代价才能SOA. 那这对于那些想整合共享异构的老系统的服务的用户来说还有什么意义呢？ SOA的“充分发挥,利用legacy system 服务”的这一优势又如何体现呢？
以或这里的legacy system是指的不能太老？ 至少能支持web service的?
也就是说，不是任何系统的改造都能套用SOA的，但是SOA的概念里面可是说的任何系统，所有语言啊，这可是让很多客户为止狂欢的主要原因啊
B/S基本都是通过web service来干的吧？
像LZ这样几个C/S来搞SOA的，以前还真没想过。如果是不同的语言编写的话又要协同，应该要使用一种通用的数据格式了，最直接的大概是XML吧，那不又像WS一样了？
期待高人的想法出现
是啊，我们给客户吹了半天SOA，人家很感兴趣。但人家的系统都是C/S的老系统，而且用的很好，不愿意重新开发新的，只是希望能在这几个旧系统里做整合。
怎么做？ 到处宣扬平台，语言无关性，但到处讨论的都是有局限性的，基于java, .net的应用。
遇到这种老式语言开发的C/S系统怎么应用呢？ 会不会经过调研，预算后得出结论:在这种结构上应用SOA代价过大，因此SOA不适用！那就又和SOA的最亮点冲突了。
期待指点，谢谢！
SOA只是个名词，落到实处，异构应用的整合问题，也就是要让说不同语言的人之间能够交流，本来就没有什么灵丹妙药，只能设定出一个世界语让大家来通用。妄想扔个SOA锦囊进去，世界就马上大同了，这是天方夜谭，呵呵。
好像SOA不是一种技术吧,在我看来SOA是一种态度. 以前老的系统怎么样了.如果跑的很好又何必重新开发呢?你要做的只是把老的系统提供的功能适配成你的SOA平台能够识别的服务.
“把老的系统提供的功能适配成你的SOA平台能够识别的服务” 这句话是核心。但是怎么做呢？ 我想用一些传统的，老套的办法也可能解决问题，但这是不是SOA呢？ 怎么做才算的上是正宗的SOA呢。
还是SOA说了"只要你整合，共享服务了，就都属于我SOA了”
太过强调SOA的概念。其实客户关心的是如何整合原来老的系统，共享数据，提高效率。是否采用SOA和如何采用SOA不是他们关心的事情。抓住事情的本质
SOA确实就是个大忽悠，没有它之前异构系统的整合的案例照样存在，而且实施的很好
如果把SOA理解成技术，首先看SCA的C++版能不能很容易的封装旧代码，如果不能，就直接考虑数据级别的整合吧，你们可以针对数据库开发一个web service的应用然后和SOA平台进行整合
SOA的目的就是为了整合老应用系统，实现数据交互，并且，最重要的，减少耦合，降低二次开发量。
讨论少的原因是，这里许多人没有（VC，带耳非，VB）等工作经验，也没用过。怎么交流？而且，每本书上，每个人都在谈C/S维护难的问题，自然没人愿意去趟这浑水。
SOA其实也是要解决新系统和老系统的互联问题。 当然还是得通过web services. 用JBI举例， 对老的C/S结构的系统， 你需要开发一个BC作为老系统的web services接口和其他系统通信， 同时这个BC也是老系统的一个Client。这也是为什么会有很多JDBC, File, SMTP等等BC的原因
不同意这个说法,SOA不一定要通过WS 通过WS的SOA我觉得很危险,不论你是内部路由调度还是服务发布用WS接口 后期性能都将极其的低.特别是内部路由这块,服务发布用ws倒是可以考虑. 在SOA平台内部建议使用长连接去进行通信. 根据我的测试结果 简单一个报文在短连接的情况下 要比长连接的情况最少慢一个到两个数量级. 而且SOA是不暴露WS的 他暴露的仅仅是一个访问接入的接入点(服务的协议发布形式是不暴露的).应用统一通过这个接入点接入到SOA平台内,如果你直接暴露服务的协议那这个平台缺少安全性和规范性.
SOA是概念， 集成构架， 而JBI是一种实现SOA的技术。两个是不同层次的东西。 JBI是要求用SOAP进行通信， 但SOA完全可以不基于Web services, 更何况SOAP。
SOA是不暴露WS的： 我觉得SOA是一种理念， 只有一个应用才有暴露WS的问题。
至于性能，你的BC可以保持长连接， 但ESB内部还是通过消息传递（都不一定是IPC）， 这也是在实施时考虑的具体优化问题
SOA是概念， 集成构架， 而JBI是一种实现SOA的技术。两个是不同层次的东西。 JBI是要求用SOAP进行通信， 但SOA完全可以不基于Web services, 更何况SOAP。
SOA是不暴露WS的： 我觉得SOA是一种理念， 只有一个应用才有暴露WS的问题。
至于性能，你的BC可以保持长连接， 但ESB内部还是通过消息传递（都不一定是IPC）， 这也是在实施时考虑的具体优化问题。
RMI也可以实现SOA的，前面很多人说过，SOA只是一种架构方式.
但怎么热论的都是B/S结构的，基于WebService的系统之间的SOA解决方案呢？甚至大多都是基于java的，也有.net和java之间的，但这有什么稀奇的呢？ 在SOA这个概念出来之前， B/s结构的系统之间通信，整合方法本来就很多（http,xml,soap,webservice等等），SOA只不过把这些方法归拢，并形成一个标准的模式，也即包装而已。当然SOA提出的构建系统的理念还是很值得吸取的。
问题在由，SOA强调的它最大的功能就是，异构，任何语言编写的，新的，旧的系统之间都能共享服务，数据。
那么如果是3个旧的系统(C/S结构的)，分别用vb, delphi, c++ 或者其它任何语言编写的系统之间，如何通过应用SOA来让这三个旧的系统协同工作，服务，流程，数据共享呢？ 如果有办法，那是否需要花费大量的时间对这些系统进行重新开发呢？
如果没有办法，或有办法太花费的代价太大，那是不是可以说，能够应用SOA这个概念进行整合的系统，其开发时必须遵守SOA的标准规范呢？ 如果不遵守，将不能应用SOA, 或者说将付出很大的代价才能SOA. 那这对于那些想整合共享异构的老系统的服务的用户来说还有什么意义呢？ SOA的“充分发挥,利用legacy system 服务”的这一优势又如何体现呢？
以或这里的legacy system是指的不能太老？ 至少能支持web service的?
也就是说，不是任何系统的改造都能套用SOA的，但是SOA的概念里面可是说的任何系统，所有语言啊，这可是让很多客户为止狂欢的主要原因啊
B/S基本都是通过web service来干的吧？
像LZ这样几个C/S来搞SOA的，以前还真没想过。如果是不同的语言编写的话又要协同，应该要使用一种通用的数据格式了，最直接的大概是XML吧，那不又像WS一样了？
期待高人的想法出现
是啊，我们给客户吹了半天SOA，人家很感兴趣。但人家的系统都是C/S的老系统，而且用的很好，不愿意重新开发新的，只是希望能在这几个旧系统里做整合。
怎么做？ 到处宣扬平台，语言无关性，但到处讨论的都是有局限性的，基于java, .net的应用。
遇到这种老式语言开发的C/S系统怎么应用呢？ 会不会经过调研，预算后得出结论:在这种结构上应用SOA代价过大，因此SOA不适用！那就又和SOA的最亮点冲突了。
期待指点，谢谢！
SOA只是个名词，落到实处，异构应用的整合问题，也就是要让说不同语言的人之间能够交流，本来就没有什么灵丹妙药，只能设定出一个世界语让大家来通用。妄想扔个SOA锦囊进去，世界就马上大同了，这是天方夜谭，呵呵。
好像SOA不是一种技术吧,在我看来SOA是一种态度. 以前老的系统怎么样了.如果跑的很好又何必重新开发呢?你要做的只是把老的系统提供的功能适配成你的SOA平台能够识别的服务.
“把老的系统提供的功能适配成你的SOA平台能够识别的服务” 这句话是核心。但是怎么做呢？ 我想用一些传统的，老套的办法也可能解决问题，但这是不是SOA呢？ 怎么做才算的上是正宗的SOA呢。
还是SOA说了"只要你整合，共享服务了，就都属于我SOA了”
太过强调SOA的概念。其实客户关心的是如何整合原来老的系统，共享数据，提高效率。是否采用SOA和如何采用SOA不是他们关心的事情。抓住事情的本质
SOA确实就是个大忽悠，没有它之前异构系统的整合的案例照样存在，而且实施的很好
如果把SOA理解成技术，首先看SCA的C++版能不能很容易的封装旧代码，如果不能，就直接考虑数据级别的整合吧，你们可以针对数据库开发一个web service的应用然后和SOA平台进行整合
SOA的目的就是为了整合老应用系统，实现数据交互，并且，最重要的，减少耦合，降低二次开发量。
讨论少的原因是，这里许多人没有（VC，带耳非，VB）等工作经验，也没用过。怎么交流？而且，每本书上，每个人都在谈C/S维护难的问题，自然没人愿意去趟这浑水。
SOA其实也是要解决新系统和老系统的互联问题。 当然还是得通过web services. 用JBI举例， 对老的C/S结构的系统， 你需要开发一个BC作为老系统的web services接口和其他系统通信， 同时这个BC也是老系统的一个Client。这也是为什么会有很多JDBC, File, SMTP等等BC的原因
不同意这个说法,SOA不一定要通过WS 通过WS的SOA我觉得很危险,不论你是内部路由调度还是服务发布用WS接口 后期性能都将极其的低.特别是内部路由这块,服务发布用ws倒是可以考虑. 在SOA平台内部建议使用长连接去进行通信. 根据我的测试结果 简单一个报文在短连接的情况下 要比长连接的情况最少慢一个到两个数量级. 而且SOA是不暴露WS的 他暴露的仅仅是一个访问接入的接入点(服务的协议发布形式是不暴露的).应用统一通过这个接入点接入到SOA平台内,如果你直接暴露服务的协议那这个平台缺少安全性和规范性.
SOA是概念， 集成构架， 而JBI是一种实现SOA的技术。两个是不同层次的东西。 JBI是要求用SOAP进行通信， 但SOA完全可以不基于Web services, 更何况SOAP。
SOA是不暴露WS的： 我觉得SOA是一种理念， 只有一个应用才有暴露WS的问题。
至于性能，你的BC可以保持长连接， 但ESB内部还是通过消息传递（都不一定是IPC）， 这也是在实施时考虑的具体优化问题
SOA是概念， 集成构架， 而JBI是一种实现SOA的技术。两个是不同层次的东西。 JBI是要求用SOAP进行通信， 但SOA完全可以不基于Web services, 更何况SOAP。
SOA是不暴露WS的： 我觉得SOA是一种理念， 只有一个应用才有暴露WS的问题。
至于性能，你的BC可以保持长连接， 但ESB内部还是通过消息传递（都不一定是IPC）， 这也是在实施时考虑的具体优化问题。
RMI也可以实现SOA的，前面很多人说过，SOA只是一种架构方式.
作者：jackxiang@向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除
地址：https://jackxiang.com/post/2493/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明！
最后编辑： jackxiang 编辑于2010-1-7 12:06
[转自建鑫]Linux命令重定向与管线命令
用mysql触发器自动更新memcache评论列表
