SOA没在忽悠

个人觉得数据整合,应用协同发展的步骤分为以下几步.
第一:数据库整合
第二:应用整合
第三:暴露服务整合,请求模式
第四:SOA

这四个步骤都有这么几个要素.
第一:应用方
第二:数据提供方
第三:业务需求

说SOA是忽悠的也可以理解,因为这四个步骤都可以实现SOA的目标.可是如果从业务扩展和变更的角度去考虑就会发现不同.

一个简单的例子,本来A,B,C三个部门有一个应用(比方是公司的三个不同部门) 因为政策变化公司需要把这个三个部门整合成一个部门,这样完全可以把进行数据库整合然后重新开发应用(第一种),或者把三个部门的应用进行整合(第二种)等...
这样的整合在功能实现上是一样的. 好的又过了一段时间,公司业务发展的需要又要把这个整合后的部门分为两个部门,这时候你依旧可以和以前那样进行整合. 这样就不难看出为了适应变化投入的成本.

下面我说说 第三和第四种整合模式

第三:暴露服务整合,请求模式这种整合已经是准SOA模式了只是它把业务的流程积压在应用方,服务提供方提供服务的细节对应用方是透明的.这种整合的缺点是在业务变化的时候 还需要比较大面积的修改原来应用的逻辑.
第四:SOA,其实它把简单的服务调用流程和数据库整合规则逻辑加在了SB上,服务对应用是不透明的.应用只需要知道有这个服务就可以了,这种模式在业务变化的情况下也许只是简单的修改流程脚本而已.

所以SOA有它自己独特的领域,并不能说SOA在忽悠,如果业务变更不大,业务流程不复杂那么完全可以不用SOA去做.

SOA在理论上是要解决数据孤岛的问题,但是它在本质上确实要解决协调工作的问题.快速应答客户需求只是这种模式带来的好处而已.

我不否认SOA是一大堆适配器,在没有平台规范的情况下这种情况是难免的.君不见JAVA世界里面还一大堆接口.你能说接口就不是一个适配器吗?
SOA在发展,就请不要再否认SOA的意义,容忍SOA在发展过程中犯的小错误,存在即合理.垃圾只是发错地方的财富而已.

评论

43 楼 fjlyxx 2009-02-21  

andot 写道

fjlyxx 写道

个人觉得SOA中碰见的问题大多是因为以下几点引起的

第一 压力
第二 千变万化的服务提供方式
第三 分布式
第四 不确定因素 比如网络阻塞   服务非正常停止
第五 规范化  原来应用的发展历史对SOA平台是有影响的

但是以上这些技术难道 并不是没有办法解决的  已经有很多成功的解决案例  但是不得不承认现在很多公司打着SOA的旗号在忽悠客户  做一个SOA平台需要比较大的投入

SOA涉及的技术领域比较广泛,我觉得单靠PHPRPC 是不能满足需求的.

下面我就来帮你解决上面你遇到的这五个问题：
。

引用

第二 千变万化的服务提供方式

解决这个问题有两种方式：

一种方式是提供一种大而全的集中式服务协议转换器，ESB 的一个主要工作就是做这个。

另一种是，将所有服务方式统一为一种，PHPRPC 的目标就是如此。

前一种方式的弊端大家都很清楚，那就是将本来就低效的服务变的更加低效，如果有人这么认为协议转换是没有成本的，或者成本很低，那他肯定是个外行。协议转换本身就非常消耗资源，而如果又把它作为核心总线的一部分的话，那它势必会成为整个系统最大的瓶颈之一。而且需要转换的协议越多，这个效率下降就越明显。

而将服务方式统一为一种，那么这个问题就很自然的消失了，既不会对效率产生影响（如果有影响也是好的，那就是大大的提高了效率），又降低了系统的复杂性。

那么你可能会说，要统一很难的，如果统一那么简单，为什么以前不用这种方式，还要加一个 ESB 来做协议转换这种事呢？

OK，这个问题的答案很简单，那是因为以前的技术做不到一个服务可以让所有语言都可以无差别调用，所以协议转换就成了必须的。例如，Web Service 你可以认为它已经在很多语言中被发布和被调用了是吧，但是你能够在所有的浏览器中通过 JavaScript 调用它吗？（如果你属于喜欢抬杠的人，那么你可能会说你不知道在 .NET Web Service 刚推出时 IE 5.5 就已经有一个 webservice.htc 可以调用 Web Service 了吗？还有后来的 Mozilla 也内置了对 Web Service 的支持，不是吗？那么我现在就可以回答你，你真的有看到过有人在实际项目中这么用吗？你真的用那个 htc 调用成功过其它语言发布的 Web Service 吗？在这两个浏览器中你可以用相同的方式来使用 Web Service 吗？另外，除了这两个浏览器，那 Opera、Safari，更多其它浏览器、手机浏览器也都能支持吗？它可以跨域调用服务吗？好了，这个问题暂时告一段落）如果可以并且好用的话，就不会有 DWR 这样的东西出现了，而 DWR 有只能用于 JavaScript 和 Java 通讯，根本没有能力代替 Web Service，所以 ESB 才会考虑将这两个整合到一起。看到了吗？这都是不得已的办法。

如果以前就有一个可以在任何环境、任何语言、任何平台都可以方便进行调用的协议和实现的话，ESB 就不会把协议转换作为一个重要的功能来做了。

SOA平台内部标准的定义是必然的,就看你怎么选择了  我所说的 千变万化的服务提供方式 是指 服务提供方 有可能是暴露数据库 有可能是WS接口 有可能是文件 邮件 等等  不管怎么说碰到这些 都必须经过改照让他能够被平台识别调用等,这些工作占SOA工作中很大的一个比重.

42 楼 fjlyxx 2009-02-21  

andot 写道

fjlyxx 写道

个人觉得SOA中碰见的问题大多是因为以下几点引起的

第一 压力
第二 千变万化的服务提供方式
第三 分布式
第四 不确定因素 比如网络阻塞   服务非正常停止
第五 规范化  原来应用的发展历史对SOA平台是有影响的

但是以上这些技术难道 并不是没有办法解决的  已经有很多成功的解决案例  但是不得不承认现在很多公司打着SOA的旗号在忽悠客户  做一个SOA平台需要比较大的投入

SOA涉及的技术领域比较广泛,我觉得单靠PHPRPC 是不能满足需求的.

下面我就来帮你解决上面你遇到的这五个问题：

引用

第一 压力

你说的这个压力我理解没错的话，应该是指服务器本身的负载能力吧（应该不是项目进度给你的工作压力吧）。这个实际上是个系统构架问题，既然你做的是 SOA，那么必然是分布式的，既然是分布式的，那么你就不应该把所有的负载都压倒一台服务器上，你只要合理的部署你的服务，压力这个问题就是不问题。假设以前你用 Web Service，那么 Web Service 的低效是众所周知的，现在你换上一个高效的 PHPRPC，只会让你在拥有同样多数量服务器的情况下，大大的减轻压力，而不是增加压力。难道这还不够解决问题的吗？难道，你有了 ESB，就可以用更少的服务器解决更大的压力问题吗？显然不能。在那种情况下，你只有用更多的服务器才能解决这个问题。那么你可能会问，没有 ESB，我如何来实现负载均衡啊？那么我告诉你，最简单且最有效的方法就是，直接在 DNS 服务器上做负载均衡设置。在这种情况下，对调用者仍然是透明的，但是对服务的质量却比 ESB 的路由方式要提高几十到几百倍的能力。如果你是新手，还不懂 DNS 是做什么的，建议你好好补充一下基础知识。
 

谢谢你的帮助

第一压力问题,我说的恰恰是ESB的压力 而不是服务器本身的压力.这个问题应该是水位保护去解决  不能通过部署去解决  每一个ESB上应该都有自己挂接的接入应用 和服务  这个不能靠要求客户去增加服务器来解决问题的  在实际应用中ESB不是一个的  ESB应该是分布式的  如果你用开源的第三方ESB 那有可能出现只有一个ESB的情况 但是这个是不实际的  实际应用中只有 资源管理应用,流程管理应用,监控应用等辅助应用是一个的吧.

41 楼 bonny 2009-02-21  

口水到此为止吧。

40 楼 bonny 2009-02-21  

引用

现有用于实现 SOA 的技术在忽悠，庞大复杂低效（还要在原本就很低效的各个协议之间转来转去），

现有ESB产品的确是庞大而且低效。经常在各个协议之间转换。

但是这个是没办法的事情，有的客户需要http，有的需要mq，有的需要webservice。。。。
另外还有消息语意的转换，服务整合。请问PHPrpc能解决这些ESB已经解决的问题么？

你批评这些毫无道理

39 楼 andot 2009-02-21  

bonny 写道

andot 写道

bonny 写道

andot 写道

SOA 没有在忽悠，是现有用于实现 SOA 的技术在忽悠，庞大复杂低效（还要在原本就很低效的各个协议之间转来转去），且仅面向 Java（虽然口号是语言无关，可是在对其它语言的支持上基本上都是空白一片）。其实，要构建 SOA 系统，根本不需要那些复杂的东西，只要有 PHPRPC 这样的高效易用且语言支持广泛的技术就足够了，其它的都是在扯淡。ESB 是啥？翻译成中文其实就是：哦，傻逼！

因为你的产品敬佩你
因为你的言语鄙视你

感谢你的赞扬，更感谢你的鄙视～～
不过程序员也需要一点幽默感哦，你的头像和言语都太过于严肃了吧，哈哈～

如果你觉得推荐自己作品的时候，随意评价别人傻逼是幽默。我的确很难和你在这个角度产生一致。


可能我们无法到达joshnson大师那样的水准和薪资，但是，我觉得达到他那种心态还是很容易的。如果你推销自己作品的时候和joshnson大师推销spring那样谦卑，我觉得更容易让大多数人接收，尤其在你不十分了解或者权威的领域，更不要侮辱。

我最近一年多以来一直在作电信方面的ESB系统，因此我觉得在SOA，ESB等概念上，我还是可以说一点的：它完全和你推销的PHPRPC不是一个层面的东西。

而SOA和ESB更不是一个互相竞争，而是一个互相促进的概念。也许现在ESB实现在大多数应用里都很丑陋，但是我所参与的这个项目，ESB的确是促进了电信内部系统的整合。

而不仅仅是傻逼，噱头和忽悠。

首先我要澄清一点，我没有评价某一个人，或者某一些人是傻逼。我只是对一个技术概念的英文缩写做了比较粗口的中文音译，是对事不对人的。而你鄙视我是对人不对事的，你是否赞同这一点啊？

另外，我从来没说 PHPRPC 和 ESB 是一个层面的东西，ESB 是为了整合以往那些技术而建立起来的，PHPRPC 是从一个新的角度来诠释 SOA 的。如果在你看来只有丑陋（这个词是你先用的，我只是引用，免得再被你鄙视），复杂，庞大的东西才是好的，那 ENIAC 也就不会发展到现在的 PC 机了。

38 楼 andot 2009-02-21  

kimmking 写道

终于见到 传说中的神兽
《xxx》的真人版了
长见识了

我是对事不对人，你是对人不对事。咱俩哪个更那啥，明眼人一眼就看得出来，哈哈

37 楼 bonny 2009-02-21  

andot 写道

bonny 写道

andot 写道

SOA 没有在忽悠，是现有用于实现 SOA 的技术在忽悠，庞大复杂低效（还要在原本就很低效的各个协议之间转来转去），且仅面向 Java（虽然口号是语言无关，可是在对其它语言的支持上基本上都是空白一片）。其实，要构建 SOA 系统，根本不需要那些复杂的东西，只要有 PHPRPC 这样的高效易用且语言支持广泛的技术就足够了，其它的都是在扯淡。ESB 是啥？翻译成中文其实就是：哦，傻逼！

因为你的产品敬佩你
因为你的言语鄙视你

感谢你的赞扬，更感谢你的鄙视～～
不过程序员也需要一点幽默感哦，你的头像和言语都太过于严肃了吧，哈哈～

如果你觉得推荐自己作品的时候，随意评价别人傻逼是幽默。我的确很难和你在这个角度产生一致。


可能我们无法到达joshnson大师那样的水准和薪资，但是，我觉得达到他那种心态还是很容易的。如果你推销自己作品的时候和joshnson大师推销spring那样谦卑，我觉得更容易让大多数人接收，尤其在你不十分了解或者权威的领域，更不要侮辱。

我最近一年多以来一直在作电信方面的ESB系统，因此我觉得在SOA，ESB等概念上，我还是可以说一点的：它完全和你推销的PHPRPC不是一个层面的东西。而PHPRPC的竞争概念SOAP，也未必是ESB和SOA的必选组件。

而SOA和ESB更不是一个互相竞争，而是一个互相促进的概念。也许现在ESB实现在大多数应用里都很丑陋，但是我所参与的这个项目，ESB的确是促进了电信内部系统的整合。

而不仅仅是傻逼，噱头和忽悠。

36 楼 andot 2009-02-21  

kimmking 写道

@ andot
zhuangbility leads to leipility

咱们说母语吧

35 楼 kimmking 2009-02-21  

终于见到 传说中的神兽
《xxx》的真人版了


长见识了

34 楼 kimmking 2009-02-21  

@ andot


zhuangbility leads to leipility

33 楼 andot 2009-02-21  

bonny 写道

andot 写道

SOA 没有在忽悠，是现有用于实现 SOA 的技术在忽悠，庞大复杂低效（还要在原本就很低效的各个协议之间转来转去），且仅面向 Java（虽然口号是语言无关，可是在对其它语言的支持上基本上都是空白一片）。其实，要构建 SOA 系统，根本不需要那些复杂的东西，只要有 PHPRPC 这样的高效易用且语言支持广泛的技术就足够了，其它的都是在扯淡。ESB 是啥？翻译成中文其实就是：哦，傻逼！

因为你的产品敬佩你
因为你的言语鄙视你

感谢你的赞扬，更感谢你的鄙视～～
不过程序员也需要一点幽默感哦，你的头像和言语都太过于严肃了吧，哈哈～
我说那些话也没指望所有的人都爱听，就算是郭德纲说一段相声，也不一定台下的观众都爱听啊！
我想没有人能够说出让所有人都爱听的话，所以，有人不爱听我说的话，我很欣慰，这说明我说的还是人话，哈哈！

32 楼 bonny 2009-02-21  

andot 写道

SOA 没有在忽悠，是现有用于实现 SOA 的技术在忽悠，庞大复杂低效（还要在原本就很低效的各个协议之间转来转去），且仅面向 Java（虽然口号是语言无关，可是在对其它语言的支持上基本上都是空白一片）。其实，要构建 SOA 系统，根本不需要那些复杂的东西，只要有 PHPRPC 这样的高效易用且语言支持广泛的技术就足够了，其它的都是在扯淡。ESB 是啥？翻译成中文其实就是：哦，傻逼！

因为你的产品敬佩你
因为你的言语鄙视你

31 楼 andot 2009-02-21  

fjlyxx 写道

个人觉得SOA中碰见的问题大多是因为以下几点引起的

第一 压力
第二 千变万化的服务提供方式
第三 分布式
第四 不确定因素 比如网络阻塞   服务非正常停止
第五 规范化  原来应用的发展历史对SOA平台是有影响的

但是以上这些技术难道 并不是没有办法解决的  已经有很多成功的解决案例  但是不得不承认现在很多公司打着SOA的旗号在忽悠客户  做一个SOA平台需要比较大的投入

SOA涉及的技术领域比较广泛,我觉得单靠PHPRPC 是不能满足需求的.

下面我就来帮你解决上面你遇到的这五个问题：

引用

第一 压力

你说的这个压力我理解没错的话，应该是指服务器本身的负载能力吧（应该不是项目进度给你的工作压力吧）。这个实际上是个系统构架问题，既然你做的是 SOA，那么必然是分布式的，既然是分布式的，那么你就不应该把所有的负载都压倒一台服务器上，你只要合理的部署你的服务，压力这个问题就是不问题。假设以前你用 Web Service，那么 Web Service 的低效是众所周知的，现在你换上一个高效的 PHPRPC，只会让你在拥有同样多数量服务器的情况下，大大的减轻压力，而不是增加压力。难道这还不够解决问题的吗？难道，你有了 ESB，就可以用更少的服务器解决更大的压力问题吗？显然不能。在那种情况下，你只有用更多的服务器才能解决这个问题。那么你可能会问，没有 ESB，我如何来实现负载均衡啊？那么我告诉你，最简单且最有效的方法就是，直接在 DNS 服务器上做负载均衡设置。在这种情况下，对调用者仍然是透明的，但是对服务的质量却比 ESB 的路由方式要提高几十到几百倍的能力。如果你是新手，还不懂 DNS 是做什么的，建议你好好补充一下基础知识。

引用

第二 千变万化的服务提供方式

解决这个问题有两种方式：

一种方式是提供一种大而全的集中式服务协议转换器，ESB 的一个主要工作就是做这个。

另一种是，将所有服务方式统一为一种，PHPRPC 的目标就是如此。

前一种方式的弊端大家都很清楚，那就是将本来就低效的服务变的更加低效，如果有人这么认为协议转换是没有成本的，或者成本很低，那他肯定是个外行。协议转换本身就非常消耗资源，而如果又把它作为核心总线的一部分的话，那它势必会成为整个系统最大的瓶颈之一。而且需要转换的协议越多，这个效率下降就越明显。

而将服务方式统一为一种，那么这个问题就很自然的消失了，既不会对效率产生影响（如果有影响也是好的，那就是大大的提高了效率），又降低了系统的复杂性。

那么你可能会说，要统一很难的，如果统一那么简单，为什么以前不用这种方式，还要加一个 ESB 来做协议转换这种事呢？

OK，这个问题的答案很简单，那是因为以前的技术做不到一个服务可以让所有语言都可以无差别调用，所以协议转换就成了必须的。例如，Web Service 你可以认为它已经在很多语言中被发布和被调用了是吧，但是你能够在所有的浏览器中通过 JavaScript 调用它吗？（如果你属于喜欢抬杠的人，那么你可能会说你不知道在 .NET Web Service 刚推出时 IE 5.5 就已经有一个 webservice.htc 可以调用 Web Service 了吗？还有后来的 Mozilla 也内置了对 Web Service 的支持，不是吗？那么我现在就可以回答你，你真的有看到过有人在实际项目中这么用吗？你真的用那个 htc 调用成功过其它语言发布的 Web Service 吗？在这两个浏览器中你可以用相同的方式来使用 Web Service 吗？另外，除了这两个浏览器，那 Opera、Safari，更多其它浏览器、手机浏览器也都能支持吗？它可以跨域调用服务吗？好了，这个问题暂时告一段落）如果可以并且好用的话，就不会有 DWR 这样的东西出现了，而 DWR 有只能用于 JavaScript 和 Java 通讯，根本没有能力代替 Web Service，所以 ESB 才会考虑将这两个整合到一起。看到了吗？这都是不得已的办法。

如果以前就有一个可以在任何环境、任何语言、任何平台都可以方便进行调用的协议和实现的话，ESB 就不会把协议转换作为一个重要的功能来做了。

引用

第三 分布式

SOA 是分布式的，PHPRPC 是提供构建分布式系统能力的一个工具，问题解决了。

引用

第四 不确定因素 比如网络阻塞   服务非正常停止

这个问题在任何分布式系统中都会遇到，但是如果在构建分布式系统时，你能够清楚的认识到这一点，那么它就不是问题。有人（甚至是专家）会说 RPC 方式隐藏了网络通讯的细节，以至于让人们忽略了网络调用和本地调用之间的区别，我觉得这个说法是错的。如果说隐藏网络通讯细节的话，这个问题应该归咎到分布式对象模型的头上，而不是 RPC 的头上，只有在分布式对象模型中，程序员才无法分清一个操作是否要跨网络（如果你不明白，建议补充一下对分布式对象模型的一些知识，最好是学一些关于分布式对象模型的一些具体技术，在对这些具体技术有所实践后，你应该明白我说的是什么）而在 RPC 中，任何一个远程调用都是跨网络的，这一点是可以很清楚的知道的。

另外一点，就是 RPC 调用只有两个结果，要么成功，要么不成功。当然你还可以分得更细，可以分三种，一种是是调用成功后，客户端得到了结果；第二种是调用成功后，客户端还没有得到结果，但网络中断了，客户端认为没有成功，而实际上服务器端已经成功执行了调用；第三种是调用开始后，客户端请求还未完全到达服务器，网络中断了，这时服务器没有执行调用，也就是不成功，客户端也自然收到没有调用成功的消息。在 PHPRPC 调用中（其它的 RPC 协议我不能保证）不存在这种情况，那就是客户请求一边发送，服务器就一边执行，所以，你不用担心服务器会在执行一部分调用后失败的情况，这种情况在 PHPRPC 中是不存在的。所以，现在问题简单了，你只要遵循下面一套指导原则，对于网络的不确定因素就能很好的面对和处理了。

指导原则很简单，那就是把服务分为两类，一类是幂等性操作，一类是非幂等性操作。当执行幂等性远程过程调用操作时，网络发生故障中断并再次恢复后，只需重发调用即可。对于非幂等性操作，你可以为它配一个查询执行是否成功的幂等性操作，在正常情况下，我们不需要使用这个查询执行是否成功的幂等性操作，但是当执行非幂等性远程过程调用操作时，网络故障中断并再次恢复后，我们首先要执行这个查询执行是否成功的幂等性操作，然后根据它的返回的状态来决定是否重发非幂等性远程过程调用操作。这样就可以保证幂等性操作至少执行一次，非幂等性操作仅执行一次的要求了。

这个指导原则不仅适用于用 PHPRPC 构建的系统，同样适用于其它可以将执行调用结果分为以上三类的 RPC 服务，例如 Web Service。但是不适用于基于分布式对象模型构建的系统，因为在这样的系统中，你无法弄清到底哪个调用触发了网络通讯。

引用

第五 规范化  原来应用的发展历史对SOA平台是有影响的

这就是一个过渡问题，如果要让一个原有系统过渡到一个利用新技术构建的系统要花费很大的代价的话，自然会成为一个很大的问题。而 PHPRPC 充分的考虑了这点，因此，当你将一个原有系统用 PHPRPC 重新构建时，你会发现你几乎不需要对你的原有系统做什么更改，你原有的业务逻辑层可以直接使用 PHPRPC 来发布成服务。而且不仅适用于 Java，同样适用于其它语言构建的系统，例如 PHP、.NET、Ruby、Python 甚至 ASP 等。对其它技术来说（包括 Web Service），这点确实很难做到。这也是 PHPRPC 的最大亮点之一。

综上所述，PHPRPC 解决了 SOA 领域对于以前大多数技术可能会遇到的问题。因此，利用 PHPRPC 构架 SOA 系统是非常合适的选择。

30 楼 LibreTeam 2009-02-21  

SOA讲究的是什么？Service！！，而PHPRPC解决的是什么？提供服务，到目前为止，PHPRPC很好的解决了我们如何提供服务，这其实就解决了SOA的最大问题，如何发布服务，各种开发平台如何利用服务，SOA模型中心就是Service。

29 楼 fjlyxx 2009-02-21  

SOA在技术角度上来说 可以简单的分为 网络  服务方 请求方 管理应用  其中网络这层你可以考虑 长短连接的选择  路由拓扑可以根据需要进行架构  灵活的SOA平台寻址是很方便的  长短连接并用(这个和业务的生命周期有关系吧)  推荐用LINUX C NIO去实现

服务方就不用说了 可以是原始业务应用暴露的WS 或者DCOM  文件  等等接口 当然为了满足平台规范 或许还要进行一系列的改造  这时候就是适配器的工作了
 
请求方 其实就是SOA平台的接入点  这个和技术无关吧

管理应用  这个和具体的架构有关系 但是SOA平台流程脚本的设计 需要一个设计器  流程解析需要一个解析器和执行器  这个解析器可和执行器以理解为 ESB上的逻辑处理单元  需要一个服务方管理应用和一个流程管理应用 其他的还可以有SOA的网络节点管理应用 监控应用  调度应用等等

简单的说有了这些就可以搭建一个SOA平台 但是还有一些附属的功能 比如监控,安全认证等

技术难点还是有很多

如何在分布式中实时的监控流程运行情况  流程间的相互调用和通信  简单的接入模式  简单的服务提供模式  路由同步  容错  资源发布同步等等 这些其实都是需要解决的问题 

个人觉得SOA中碰见的问题大多是因为以下几点引起的

第一 压力 第二 千变万化的服务提供方式  第三  分布式  第四  不确定因素 比如网络阻塞   服务非正常停止  第五  规范化  原来应用的发展历史对SOA平台是有影响的

但是以上这些技术难道 并不是没有办法解决的  已经有很多成功的解决案例  但是不得不承认现在很多公司打着SOA的旗号在忽悠客户  做一个SOA平台需要比较大的投入

SOA涉及的技术领域比较广泛,我觉得单靠PHPRPC 是不能满足需求的.

28 楼 andot 2009-02-20  

sun201200204 写道

每种技术都是为应用而产生的，一味的炒作，一味的跟风是没有意思的。
能解决实际问题，就是最好的技术。

非常赞同您的观点！“能解决实际问题”这就是我们的目标。

27 楼 andot 2009-02-20  

boyingking 写道

andot 写道

fjlyxx 写道

看SOA不能从技术的角度去考虑,如果把SOA能解决的问题抛给开发人员那就很容易误解SOA的意义. 如果你从业务的角度去看待SOA的问题就会不同的. 我个人觉得在IT里面技术永远不是问题,问题是有没有这样的需求和发展的需要. 从数据整合的历史我们可以很清楚的看出SOA是发展的需要,从SOA能解决的问题来说也很容易发现SOA是客户所强烈需要的.

我觉得不应该排斥SOA这个东西  可能是SOA在我国的技术实现上不尽人意但这应该是暂时的. 同时我也觉得SOA平台不应该只是简单使用第三方的平台 这样的SOA在很大程度上不能满足用户实际的需要. SOA平台应该是分行业的. 

基本业务需求,硬件设施对SOA的影响是比较大的.

很赞同楼主的观点！SOA 应从业务角度出发，80%甚至90%的精力放在业务分析上，也就是系统中业务的分解和重组。如果 80% 的时间都投入到那种云里雾里让人都搞不清是什么东西的技术的研究上，只能说明这个技术有问题。所以，目前来说，只有 PHPRPC 适合来做 SOA 应用，因为有了它，你就真的可以把 90% 以上的精力都用于业务分析而不是技术实现了。

这句话最起码可以评为今年的JE最牛

不敢当，比起阁下的字字珠玑来，还差得远哦～

26 楼 sun201200204 2009-02-20  

每种技术都是为应用而产生的，一味的炒作，一味的跟风是没有意思的。
能解决实际问题，就是最好的技术。

25 楼 boyingking 2009-02-20  

andot 写道

fjlyxx 写道

看SOA不能从技术的角度去考虑,如果把SOA能解决的问题抛给开发人员那就很容易误解SOA的意义. 如果你从业务的角度去看待SOA的问题就会不同的. 我个人觉得在IT里面技术永远不是问题,问题是有没有这样的需求和发展的需要. 从数据整合的历史我们可以很清楚的看出SOA是发展的需要,从SOA能解决的问题来说也很容易发现SOA是客户所强烈需要的.

我觉得不应该排斥SOA这个东西  可能是SOA在我国的技术实现上不尽人意但这应该是暂时的. 同时我也觉得SOA平台不应该只是简单使用第三方的平台 这样的SOA在很大程度上不能满足用户实际的需要. SOA平台应该是分行业的. 

基本业务需求,硬件设施对SOA的影响是比较大的.

很赞同楼主的观点！SOA 应从业务角度出发，80%甚至90%的精力放在业务分析上，也就是系统中业务的分解和重组。如果 80% 的时间都投入到那种云里雾里让人都搞不清是什么东西的技术的研究上，只能说明这个技术有问题。所以，目前来说，只有 PHPRPC 适合来做 SOA 应用，因为有了它，你就真的可以把 90% 以上的精力都用于业务分析而不是技术实现了。

这句话最起码可以评为今年的JE最牛

24 楼 andot 2009-02-20  

fjlyxx 写道

看SOA不能从技术的角度去考虑,如果把SOA能解决的问题抛给开发人员那就很容易误解SOA的意义. 如果你从业务的角度去看待SOA的问题就会不同的. 我个人觉得在IT里面技术永远不是问题,问题是有没有这样的需求和发展的需要. 从数据整合的历史我们可以很清楚的看出SOA是发展的需要,从SOA能解决的问题来说也很容易发现SOA是客户所强烈需要的.

我觉得不应该排斥SOA这个东西  可能是SOA在我国的技术实现上不尽人意但这应该是暂时的. 同时我也觉得SOA平台不应该只是简单使用第三方的平台 这样的SOA在很大程度上不能满足用户实际的需要. SOA平台应该是分行业的. 

基本业务需求,硬件设施对SOA的影响是比较大的.

很赞同楼主的观点！SOA 应从业务角度出发，80%甚至90%的精力放在业务分析上，也就是系统中业务的分解和重组。如果 80% 的时间都投入到那种云里雾里让人都搞不清是什么东西的技术的研究上，只能说明这个技术有问题。所以，目前来说，只有 PHPRPC 适合来做 SOA 应用，因为有了它，你就真的可以把 90% 以上的精力都用于业务分析而不是技术实现了。