星期一, 11月 17th, 2008
另一个层次的耦合度
耦合度有很多的理解，《模块的耦合度》就讲到非常好。文中分别讲了七种耦合情况：非直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合、内容耦合。本文从“产品”的层面来谈谈耦合度（以上经验也是在实施SOA之后，系统变得更加庞大，业务变得更加复杂之后的一些思考）。
第一，技术与业务的耦合，在使用开源产品的发展型公司中，这是普遍存在的一个现象，技术中包含业务，业务中包含技术。出现的结果是：技术只为使用它的业务服务，难以持续发展；技术的重视变为一种口头禅，想单独发展也困难；技术管理变得虚弱，甚至不存在；不断refactor，技术架构与业务架构联动；开发人员的能力要求等同化，不利于培养和发展；遗留问题边缘化、遗弃化。【看参考《闲话通用技术之二 ：苦中作乐》与系列文章】
第二，产品与产品的横向耦合，产品之间的耦合表现为模块接口耦合、数据耦合、业务模型耦合（解决它是具有巨大挑战的。出现的结果是：被耦合度产品，关联度越高，越难以维护，越难以发展；数据上的一丝变化，就导致业务故障；任何被耦合度模型，即使一个小的变化，就需要重新设计其它模型；为了应对多样性的存在，产品提供的相似接口有一打。
解决以上两种耦合度方法是：技术产品化、架构平台化、耦合协议化与规约化、产品体系化。
星期五, 11月 7th, 2008
闲话通用技术之三 ：首次
首次总是会给人流下深刻的记忆。
听一朋友曰：来了一高手，1周才把环境搭建起来，2周才把系统跑起来，3周才摸到了点门路。初次听来，似乎很夸张，不可能吧？我就体验过这种“首次”【至于其中的基本状况，可参考《闲话通用技术之二 ：苦中作乐》一文中的第三阶段】。对于一些新进入编程领域的人来说，这种情况给他带来的挫折是非常巨大的，即使有2-3年经验的人，也很受打击呀，从而出现了某些人很长时间才能融入环境，才能安心开始“正式”的编程事业。
对于一个新进入环境的程序员来说，他要面对技术、业务、管理过程等多方面的再学习，所有的都面临“首次”考验。我一直以来有个梦想：“通用技术能否帮助这些程序员降低首次的恶梦，而不再是梦魇的制造者“ — 这也是一位“高手”义不容辞的责任。
星期三, 11月 5th, 2008
闲话通用技术之二 ：苦中作乐
开源带给许多软件、互联网公司以快乐，可以免费获取到许多资源，可以获取到社区的帮助，可以在某一个开源东西的基础上定制自己的东西（我不把它称为产品，是因为许多定制出来的东西的确不是产品）；开源给程序员带来了快乐，他们可以学到学到新技术，可以学到许多新思想，他们可以通过开源贡献价值。快乐呀！！
韩非子“塞翁失马”的道理总是很快就体验到我们的身边，快乐到一个点，痛苦随着而来；艰苦的熬过痛苦，终于又看到了快乐；然后周而复始；直到那个终点出现（这个终点也是EJB与Spring等的汇合之点。）？看看下面的故事线索：
-
在网站系统创建的1-2年，是快乐的时候，Spring、WebWork等开源框架，很快就搭建了自己的系统，而且运转的那么好。
-
第三年，日用户量达到了百万，服务器也增加到了几十台，业务系统也达到10几个，终于进入了分布式领域，引入了SOA、远程服务、分布式事务、消息等技术。痛苦的开始。
-
第四年，服务器增加到了几百台，开发人员100-200人，解决发布冲突的问题、并行开发的问题等，引入了SCA、OSGI之类的思想和技术；数据量太大了，需要分布存储，引入了分库、统一数据访问、搜索等技术。痛苦在继续。
-
第五年，所有的指标都增加了翻了一倍，似乎一起都混乱了，需要治理，引入了服务治理、服务器监控、更强大的过程管理工具、更多的技术出现了。有人开始乐乐，有人更加痛苦了。
-
第六年………………..
日复一日，重复着这些过程，程序员就是这么可悲。开源并不能解决这个过程中遇到的困境，开源也不是上帝之手;一些开源技术把我们带入了快乐，也给我们埋下了痛苦的隐患。
在这个过程中，我们定义了一系列的规范、标准，就像制定EJB的规范一样来制定企业自己的技术规范；开发了一系列的技术，依然不能解决我们的难题。对玩技术的也许有些讽刺，我们在不断的给业务搞技术架构，却很少给自己的技术搞个架构，把我们的技术平台化，产品化，看看那些成功的互联网、软件公司，无一不会通过这种方式来化解上面的困境。看到技术，永远是点，点多了必然会乱；只有把点组织为有机体（产品），才会健康。“众里寻他千百度。蓦然回首，那人却在，灯火阑珊处”，这诗句写的就是好。
【备注：】朋友写的一篇文章：大型网站架构演变和知识体系，进一步证实了这种情况，即使在第九个阶段，也不是最终阶段呀。
星期二, 11月 4th, 2008
闲话通用技术之一：EJB与Spring会否汇合
晚饭后，与几位同事在办公桌边消食，不知哪位兄弟说起了EJB，结果立刻引起了一片讨论。总体论调无非是EJB已经死亡，以及EJB死亡的原因，以及Spring为啥流行。
在此处我不想对此进行太多探讨，毕竟EJB还在不断进化，使用者也还是有很多；Spring等轻量级框架也在进化，使用者也很多；非Java领域也有很多 东西在不断创新的东西被大量使用。世界本来就是多样性的，关键是个体的选择。在软件领域，架构师对技术平台的选择，可以参考《构建架构的思考》一文的观点 （由三大类要素决定选择架构）。
来看看EJB，Spring的进化：
EJB1.0 –》EJB2.0 –》EJB3.0
Srping –》Spring Application 1.0 –》？？
从大趋势看：EJB标准由复杂走向简单，Spring从框架走向产品。抛开复杂度、个人兴趣等等，只看问题域它们都是一致的：
- 产品化
- 可管理
- 可监控
- 组件化
- 模块化
- 容器
- 事务
- 分布
- 开发者支持（工具等）
- 组装（Ioc特性）
那么它们的终点是否会汇合？
星期日, 06月 29th, 2008
SOA是可持续的战略，不是一次项目
常常听到如下关于SOA的说法：
- 我们完成了SOA化改造。
- 我们的SOA化，已近实现了80%。
- 这次项目是为了实现SOA化，因此要请有这方面经验的公司来实施。
- 从技术角度层面来说，我们达到了SOA化的目标。
- 这是我们最后一个SOA个项目
- 等等
如果这些话出自程序员，项目经理等人员，也是无所谓的；如果出自IT管理层的人员，哪就是一种可怕的想法了。因为他把SOA仅仅看作是一次项目了，而没有把它作为战略。这样的后果也是可以预见的，最终本次投资将会失败。
因此，建议那些准备实施SOA的公司，首先回答这个问题：SOA是贵公司的一个战略吗？
为什么要回答这个问题？
- 从SOA概念来看
关于什么是SOA，我有几篇文章，可以参考（《这些都不是SOA》,《ESB产品升级准备：SOA、ESB、JBI、SCA、OSGI概念再学习、再理解》,《SOA，想说爱你不容易》）。丛概念上可以看出，SOA不少技术问题，它是一种思想，一种架构，因而不可能通过一个项目就把这种思想或架构完全实现；思想也是会发展得，今天的思想在明天或许就会不适应。
- 从SOA目标来看
SOA的目标是解决业务敏捷性问题。如今，大环境复杂多变，任何一个公司都不敢说自己的业务就是这几个、自己的业务会一直不会变，很多企业，在很短的周期内，就会推出各类产品（特别是服务类企业，例如：银行、互联网企业等）。只有那些能够快速适应变化，主动寻求变化的企业才能够生存下来，发展起来，例如：会跳舞的大象IBM，IT行业最大的特色就是变化快、发展快，如果IBM的业务不能敏捷的适应这种变化，它还能跳舞吗？正因为IBM深刻理解了SOA的目标，因而它把SOA看作一种战略–可持续的战略。
- 从IT管理角度来看
对于IT主管，一定要确保本公司的IT战略是可持续的，不能今天一种想法，明天又看到什么好思想，就换了一种想法，或者换个主管，就彻底换了战略（这种做法，就像我们国内的城市建设，路总是修不好）。既然从一种思路切合到了SOA领域，那么再次切换的成本将会更高，也不可能多种思路同时进行（吃得多，嚼不烂）。此外，谁能保证一次项目就确保几年内业务变化的需要？从我们实施的经验来看，必须持续的进行SOA化，才能确保SOA持续的发挥效果。
- 从系统分析角度来看
每次项目都要进行系统分析，都是基于当前的业务进行，那么不可避免的就会有一些盲点（从认知的角度看，人不可能一次就抓住事物的本质，何况大多数系统分析员不具有这种能力）和不合理支出。这些问题，只有在实施后一段时间才能发现（我们自己的实践经验）；此外随着补丁的实施，原有的系统已经恶化，和最初的SOA化目标越来越远。此时，如果不能再次用SOA的思想重新审视系统，就将彻底失去了SOA带来的好处。
- 从技术特征来看
SOA非但不能让系统架构变得简单，反而变得复杂了（系统设计要求变高了、系统部署复杂了、发布复杂了、各类SOA相关技术的引入增加了对人员的要求），这也是为什么要引入SOA治理。从这一点来看，只有持续的SOA化，才能最终发挥SOA技术架构的好处。
再次提醒将要进行SOA化的朋友和已经进行了SOA化的朋友，把SOA当作贵公司的可持续的战略来看，而不要认为它紧紧是一次项目。
星期五, 06月 27th, 2008
SOA实践之：在程序层，面向服务的设计准则探讨
在面向OO领域有10几条设计准则，那么这些是否都能够延续到SOA领域的服务接口设计层哪？下面列出本人实践过程中，认为能够继续适用的一些原则：
- SRP 单一职责原则
就一个服务接口而言，应该仅有一个引起它变化的原因。
职责即为”变化的原因”.
- ISP 接口隔离原则
不应该强迫客户依赖于他们不用的方法。接口属于客户，不属于他所在的类层次结构。
多个面向特定用户的接口胜于一个通用接口。
- REP 重用发布等价原则
重用的粒度就是发布的粒度.
- ADP 无依赖原则
在包的依赖关系中不允许存在环.
细节不应该被依赖.
- IDP(Interface Design Principle)接口设计原则
规划一个接口而不是实现一个接口。
其它一些可以参考的点：
- 放弃程序级别的OO概念。
- 业务的粒度就是接口方法的粒度。
- 接口方法尽可能简单、清晰、业务含义明确。
在实际应用中，按照这些准则，我总结了一些具体需要需要的点：《SOA实践之：在程序层，服务接口设计的一些准则》【对于这篇文档，会随着实践而不断补充】
星期一, 06月 16th, 2008
一个程序员眼中的google和百度
我经常回去百度的贴吧看看，也会用百度搜索些MP3;日常工作中大部分使用google进行资料检索，email使用，链接收藏等。因为工作的关系，常常会寻找一些技术资料，对这方面也比较敏感，随着发现了如下一些差别。
1、google的更多页面：更多谷歌产品,百度的更多页面：百度产品大全。这2个页面很有意思的，百度的页面，基本都是信息搜索相关业务，其中音乐相关的就有3个；google的这个页面，处包括了一些信息搜索相关的业务外，还有Google 实验室，SketchUp(3D绘图软件),文件(在线建立、撰写、储存和分享您的文档与电子表格)等应用软件【因在搜索方面我是外行，因此不进行比较】。从这2个页面，我们就可以看出两者的一个差别，google全球把自己放在与yahoo，微软等公司竞争的层面【在中国，在搜索这个市场，它还是需要追赶百度的】，百度把自己放在国内门户类网站、C2C、B2C（或许还有B2B）竞争的层面。战略上还是有些差别的。
2、近日看到，google开辟了一个生活搜索频道，很是强大，见文章技术与产品-有感于google和口碑的搜房产品,百度没有类似的频道（有贴吧这样的社区频道），但传闻在搞B2C、C2C相关的内容，要与Alibaba系竞争了。从贴吧和生活搜索频道的差别来看，两者对于社区的发展方向是不同的。google在它的生活搜索频道中，极好的诠释了技术+整合+本地化=创新的产品。百度是自己聚焦人气，google是和别人分享人气。此外，从google与天涯等网站合作，也可以看出其社区建设的思路。
3、在技术领域，我们经常会听到云计算、MapReduce、BigTable、Google guice、google toolkit、Android等技术相关的论文、文章、介绍。却很少听到百度有关的内容【当然了，国内的互联网公司都很少听到这方面的东西，sina搞过Memcachedb 与 NCache，已经很不错了】。在技术领域的影响力和贡献力存在巨大差距，这种潜在的量能积累，在几年后会否转换为商业的优势？视目以待之。
4、在协作/共享领域，google提供了Google Maps API、OpenSocial API、Google Apps等等更多的API；在百度和国内其它互联网公司，在这方面却很少【有些根本没有开放的API】。作为一名程序员，我感谢google提供的这些技术分享，从中学到了很多；作为一名博客作者，我可以用google的这些API写点有意思的东西，也很是快乐。
总之：在国内，目前百度的商业是非常成功的；google还有很长的路要走。在国际上、在全球战略上、在开发者领域、在开放领域、在云计算领域等方面，Google已经走得很远了，Google也是值得敬佩的【很希望百度、国内其它互联网公司也在这方面能有突破，让我等程序员分享一下百度的技术果实】。在某些业务领域，虽然技术领先未必会赢得商业胜利，随着时间的前进，这种技术的优势会逐步体现出来。
近日又看到这篇文章浪潮之巅 第九章 硅谷的另一面（一）近日又看到这篇文章，讲了成功公司的几个原则：创始人、能盈利的商业模型、判断力和执行力、运气。
百度在这几个方面都占据了，所以它成功了；腾讯在这几个方面也都占据了，因而也成功了；淘宝到目前为止没有找到一个好的能盈利的商业模型，因此距离成功还有一步。
在这几个因素中，没有提到技术的因素，我认为国内有很多人也有好的想法，因为技术达不到，因此最终失败了，所以对于高科技公司，是否还要加上‘合适的技术体系’哪？
当跨出了第一步之后，商业模型能够被模仿，此时要获得领先优势，就必须依靠技术了。否则必死无疑，yahoo就是一个典型案例。
相关文章：
百度CEO李彦宏的成功之路
百度网络营收增速放缓 流量价值需深度开发 — Yahoo开发的新的广告系统在美国追赶不上google，百度的广告系统因为流量的原因，短期还是业务领先的，技术上还是有差距的，需要不断提升，才能使自己的盈利能力与流量地位相匹配。
韩国互联网公司击败国外巨头的启示：产品本土化的创新 — 淘宝是另外一个例子。
讨论Google搜索的一些文章：
谁比Google 懂中文?
Google的排名算法最权威解密
阻碍Google发展的11大搜索趋势
星期日, 06月 15th, 2008
技术与产品-有感于google和口碑的搜房产品
这几日，房东要涨房价，因此准备看看我住的地方的房价。打开google，看到有个生活栏目，进去一看，也能搜房子。突然，我被它震惊了。【顺便看了一下它的其它产品，例如餐饮、工作（看到它和招聘网的合作）、出行票务，都是一个思路。】
- 产品简单，很容易使用，看不到无关的东西
- 搜索到的信息很多，但来源不同
- 列表情况下，鼠标放到某个信息位置，同步在右边的小地图，就能看到变量的位置指示
- 地图模式下，选择某个区域，放大后，右边就会列出选中区域的信息
- 地图模式下，鼠标点击地图的某一个数字圆圈上，就能提示处这个位置的房屋信息
- 切换城市的小标签，也很是方便，要是再有个输入框，就更好了【可能和它目前之提供这些城市的信息有关，不需要用户输入，这个界面就可以做到。当然了，如果能达到www.yoee.com选择飞机出发城市的效果也许更好】
下面就看看几张图：
列表模式：
地图模式：
信息来源：
口碑抓图：
演示链接：
Google列表搜索模式
Google地图搜索模式
口碑搜索模式
Google在这个产品中，充分利用了它的搜索技术、地图技术、AJAX技术，把三者完全整合在了一起。在看看Google在其它产品中对地图的使用。我们不得不惊叹它内部的架构是多么强大，一个产品可以容易的应用到不同业务中，这又是一个基于SOA思想的真实案例【参看这些都不是SOA，Google把它内部的产品完全服务化，基于这些产品，能够快速的推出各类中产品】。
反之，我们再看看Yahoo中国与Alibaba的结合，最近Yahoo中国与口碑的合并，很难看到Yahoo的搜索技术【yahoo虽然在06年也推出了地图服务，但现在却很少看到应用，特别是中国】对Alibaba、对口碑产生的技术支撑【纵观整个alibaba集团，在技术层面，缺少集团层面的架构规划和设计】。
2个公司产品，至少在查询房屋信息这个业务目标上是一致的。在这个业务目标上之所以产生了如此巨大的差异，来源于技术的差异，口碑的技术不能支撑它达到Google的这个高度【我也看到其它一些房屋搜索产品，甚至提供了三维地图，但用起来却没有google的这么爽？为什么，除去信息地图信息不完整之外，还有Web页面技术上的差别】，我想口碑也是很希望做到这个效果的。
在Google这个产品的背后，还隐藏着云计算的支撑。这么大量的房屋信息，地图数据，速度却非常快，依赖一般的服务器技术是很难实现的。有时候，我总觉得Google的云有些虚，但它已经通过一个一个的产品来证明云的强大和实在【或者说Google得技术的强大】。
细节的差异，这2个产品，在页面设计上，输入框的摆放上，也有很大的差距，体验也很不同。我们很多网站，在做页面时，只是简单的参考别的网站的样子，而不花费大力气在页面设计上，设计出来的网站毫无新意，死气沉沉。
Google在这个产品中，没有自己的房源录入功能，它完全聚合了外部的独立房屋信息提供者。它提供的是一个平台，至少这些房屋信息提供网站，不需要开发这样一个强大的终端【或许它也开发不出来】，每个房屋信息提供网站只需要专注于自己抓住自己的房源【注：从知名度，广告收益等角度看，对于大的信息提供网站是弊大于利；对于小的信息提供网站事利大于弊。对于Google来说，通过这种方式，可以吸引更多的客户，让小的信息提供网站成为信息提供商，自己免去信息维护；自己再把这些信息包装成产品，从而开拓新的业务领域—整合优势、双边获益。Yahoo中国如果能够整合Alibaba的商业信息，其它一些小的商务网站的信息，或许是个好注意。疑问：Google未来是否会成为一个门户平台（或服务平台），它提供类似搜房这样的产品，信息都是别人的，自己只是一个门】。
以前，我对技术鼓励创新感觉还是模糊的，Google的这个例子，震惊了我。同样的业务，通过技术，整合，好的产品设计，也能够起到老树开新花的效果。
【感受总结】
- 架构：整个公司（集团）层面的架构的好坏，对业务有很大的影响
- 技术研究不可或缺，没有扎实的技术，有些业务很难达到预期效果
- SOA的思想，要贯彻业务和技术2大层面
- 开放、协同、整合同样能够带来新的产品；甚至扩大市场
- 云计算不是虚的；要支撑无限扩大的业务量，必须发展云计算（分布式技术）
- UI技术的研究，对产品体验的好坏，影响巨大
- 产品设计（UI设计），不是简单的摆放
- Google的这种侵入模式，对同类业务的网站是否有很大的冲击，再观察之。但这种模式，却值得我们借鉴–技术与业务的出色结合。
- Google中国正在变化，它利用自己的技术在不断变化
- 技术型网站和业务型网站发展的方式很不同。但技术和业务最后必须同步发展，互相支撑，终点时啥样？或许2者和为一体！
资料：
阿里巴巴威胁刚刚开始 诚信认证缺失后劲堪忧,这篇文章的最后2段话，说的还是有些道理的。业务上要练功，技术上也要练功；就像武侠里的外功【业务】和内功【技术、企业文化等】，只有2者都强了，才能持续胜利。
洪波：谷歌的对手是阿里巴巴而非百度
星期六, 06月 14th, 2008
这些都不是SOA
在和同事们讨论我们的服务化过程中，以及网上看到的一些帖子，甚至在某些SOA的宣讲会中，把以下情况都认为是在搞SOA：
- 使用web服务的应用就是SOA
- 使用RESTful的应用就是SOA
- 使用了分布式计算就是SOA
- 使用WS-*扩展的web服务应用就是SOA
- 使用了ESB产品，就是SOA
- 使用了SCA产品，就是SOA
- 使用了IBM,Microsoft等公司提供的SOA产品，开发出来的应用就是SOA
以上这些情况都不是SOA。SOA是以业务入口点，来自于实际的业务需求，以下例子才是真实的SOA。
XX航空集团开发的独立系统很多，现在需要把信息流整合起来，制作更全面的报表、提升信息流转的速度、方便信息分享、提高信息检索速度等，此时从业务信息整合的角度出发，以服务的思想构件了一个新的统一信息平台。
我们公司存在同样一个业务逻辑，会用在WEB平台，手机平台，管理平台，开放平台（还有其它原因，参考SOA，想说爱你不容易）,原有的做法是共享类库，直接操作SQL等实现，现在利用SOA的思想，把这个业务逻辑封装为服务，供所有平台使用。
Yahoo中国和口碑合并，内部系统必然涉及到人员，业务流程的变化，采用SOA就能够化解之（我们常常看到一些报道，某公司收购另外一个公司，信息化系统的整合往往花费几年时间[当然还有其它原因，例如文化]，甚至会失败。案例表明：采用SOA的公司，成功率高于不采用SOA的公司）。
参考资料：
http://www.infoq.com/cn/news/2007/07/soa-ws-relation
IBM提供的实践文章
IBM 内的 SOA 应用，第 1 部分: SOA 案例研究
IBM 内的 SOA 应用，第 2 部分: SOA 案例研究
IBM 内的 SOA 应用，第 3 部分: SOA 案例研究
IBM定义的SOA入口点：
星期四, 06月 12th, 2008
云计算(Cloud Computing)是什么–读google云计算新闻有感
【文章】云中漫步——迎接云计算时代的到来
云界面为使用者提供透明的服务入口；云是一个虚拟群；云内部提供各类服务，包括saas；使用者把各类云服务整合起来之后的应用，又可以通过google的AppEngine来驻留。如果用户自己的应用也可以加入到云中【有点服务的味道了】，就更好完了。
【新闻】Google CEO施密特访华时，谈到云计算。他认为，云计算将替代网格计算。
云技术代替网格计算，说明它们是一个路线，分布式路线。疑惑的是，有关差别无法比较：云计算强调发挥虚拟中央的计算、存储能力；网格计算是强调发挥终端的计算能力，整个互联网形成一个大的计算平台。另一个概念，P2P，发挥终端的计算和存储能力，它和云有啥关系？
P2P、网格都强调客户端的计算能力，云强调服务端的计算和存储能力。这几个领域有各自的来源背景和目的，最可能的趋势是融合，而不是代替。
【新闻】Google CEO说：“服务信息都不是存在于个人电脑上，而是存在网络中，云计算是开放标准 ，业界不会有公司独裁，实际上不是只有Google一家在做云计算。”
云计算难道就是解决信息存储的问题吗？粗略看，这个定义和李开复讲的云计算有些不同，李强调服务，此处强调数据存储；细细琢磨，李讲的那些东西【”利用 Google Sites 搭建网站，利用 Gmail 提供企业邮件服务，利用 Google Calendar 管理日程信息，利用 Google Docs 分享企业内部文档，GFS（分布式文件系统）、MapReduce（分布式计算系统）以及 BigTable（分布式存储系统）”】，数据都存储在google上；再看看
Amazon的S3+EC2【Dynamo】,提供的也是存储相关的服务。原来，云计算以数据存储为基本核心之一。
最终，google的云是：
网络数据中心、数据银行 –>数据分析、数据挖掘、数据搜索
，它所有的服务都是围绕这个中心开展，再利用云提供的分布式计算能力【通过MapReduce来实现】，从而形成完整的云计算。
【新闻】雅虎正在借助 Hadoop 开源平台的力量对抗 Google, 除了资助 Hadoop 开发团队外，还在开发基于 Hadoop 的开源项目 Pig, 这是一个专注于海量数据集分析的分布式计算程序。Amazon 公司基于 Hadoop 推出了 Amazon S3 ( Amazon Simple Storage Service )，提供可靠，快速，可扩展的网络存储服务，以及一个商用的云计算平台 Amazon EC2 ( Amazon Elastic Compute Cloud )。在 IBM 公司的云计算项目–”蓝云计划”中，Hadoop 也是其中重要的基础软件。Google 正在跟IBM合作，共同推广基于 Hadoop 的云计算。
其它公司的云的核心基础是：数据存储，对使用者是一个数据源，云内部的数据存储提供者可以是分布式存储系统，甚至其它方式；云内提供分布式计算能力【也可以用MapReduce实现，或者其它技术】，从而形成完整的云计算体系。
从Googel，其它公司实现云计算的方式可以看到，云计算 的构成 （数据存储 + 分布式计算）& 服务[n]（N=0,1,2…）。【此处的服务可以是具体的业务产品，例如：Google Docs ，报表产品等；也可以是一种算法，例如：基因图谱定序，搜索算法等。】
看到大量“IBM中国云计算中心落户江苏无锡”的新闻，从报道中的内容与大部分公司提供的云计算方式来看，还是有些不同的，IBM这个中心提供的貌似就是一些软件，难道又是为了挣个眼球？
云与SAAS
- 在某些具体业务领域，两者存在竞争关系；云强化了SAAS的能力。
- GOOGL的云路径：从搜索开始，逐步到SAAS服务，最后到云。为用户提供信息化解决方案。
- 单纯的SAAS，也可以把云作为自己的后端来发展，从而强化自己。
- 云忽略具体业务，SAAS强调具体业务。
- 云强调基础服务，单一服务，容许用户自行定制，扩展，承认用户是懂IT的；SAAS强调功能的完整性，假定用户不需要知道IT知识，而把业务系统完全外包。
云与SOA
- 两者不具有比较性，来源背景，目标都完全不同。
- 云发展自网格；SOA发展自企业信息化建设。
- 云提供的能力可以作为SOA的一个服务，例如：存储服务，计算服务。
- SOA更适合企业级应用，是一种思想和架构思路；云是一种技术路线。
- SOA专注于业务的敏捷；云专注于数据和计算的能力的供给。
- SOA业务产品可以加入到云中。
术语
SaaS（Software as a Service，软件即服务）是应用软件的一种销售方式，客户按使用时间或使用量付费。这些应用软件通常是在企业管理软件领域，并通过互联网来使用。SaaS（软件即服务）具备这个特点：“软件部署为托管服务，通过因特网存取。”
SOA（Service-Oriented Architecture，面向服务架构）是一个面向服务的架构模型，它将应用程序的不同功能单元——服务（service），通过服务间定义良好的接口和契约（contract）联系起来。接口采用中立的方式定义，独立于具体实现服务的硬件平台、操作系统和编程语言，使得构建在这样的系统中的服务可以使用统一和标准的方式进行通信。SOA与大多数通用的客户端/服务器模型的不同之处，在于它着重强调软件组件的松散耦合，并使用独立的标准接口。
云计算（Cloud Computing）是基于互联网的商业计算模型。利用高速互联网的传输能力，将数据的处理过程从个人计算机或服务器移到互联网上的服务器集群中。这些服务器由一个大型的数据处理中心管理着，数据中心按客户的需要分配计算资源，达到与超级计算机同样的效果。
【相关文章：】
也谈云计算
云计算、SaaS和企业2.0
云计算（cloud computing）10问
Amazon Elastic Compute Cloud (Amazon EC2)
Amazon EC2 Gains Favor with JEE and Groovy Developers
用 Hadoop 进行分布式并行编程
什么是云计算
新闻周刊：云计算道路曲折前途光明
另一个层次的耦合度
耦合度有很多的理解，《模块的耦合度》就讲到非常好。文中分别讲了七种耦合情况：非直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合、内容耦合。本文从“产品”的层面来谈谈耦合度（以上经验也是在实施SOA之后，系统变得更加庞大，业务变得更加复杂之后的一些思考）。
第一，技术与业务的耦合，在使用开源产品的发展型公司中，这是普遍存在的一个现象，技术中包含业务，业务中包含技术。出现的结果是：技术只为使用它的业务服务，难以持续发展；技术的重视变为一种口头禅，想单独发展也困难；技术管理变得虚弱，甚至不存在；不断refactor，技术架构与业务架构联动；开发人员的能力要求等同化，不利于培养和发展；遗留问题边缘化、遗弃化。【看参考《闲话通用技术之二 ：苦中作乐》与系列文章】
第二，产品与产品的横向耦合，产品之间的耦合表现为模块接口耦合、数据耦合、业务模型耦合（解决它是具有巨大挑战的。出现的结果是：被耦合度产品，关联度越高，越难以维护，越难以发展；数据上的一丝变化，就导致业务故障；任何被耦合度模型，即使一个小的变化，就需要重新设计其它模型；为了应对多样性的存在，产品提供的相似接口有一打。
解决以上两种耦合度方法是：技术产品化、架构平台化、耦合协议化与规约化、产品体系化。
闲话通用技术之三 ：首次
首次总是会给人流下深刻的记忆。
听一朋友曰：来了一高手，1周才把环境搭建起来，2周才把系统跑起来，3周才摸到了点门路。初次听来，似乎很夸张，不可能吧？我就体验过这种“首次”【至于其中的基本状况，可参考《闲话通用技术之二 ：苦中作乐》一文中的第三阶段】。对于一些新进入编程领域的人来说，这种情况给他带来的挫折是非常巨大的，即使有2-3年经验的人，也很受打击呀，从而出现了某些人很长时间才能融入环境，才能安心开始“正式”的编程事业。
对于一个新进入环境的程序员来说，他要面对技术、业务、管理过程等多方面的再学习，所有的都面临“首次”考验。我一直以来有个梦想：“通用技术能否帮助这些程序员降低首次的恶梦，而不再是梦魇的制造者“ — 这也是一位“高手”义不容辞的责任。
闲话通用技术之二 ：苦中作乐
开源带给许多软件、互联网公司以快乐，可以免费获取到许多资源，可以获取到社区的帮助，可以在某一个开源东西的基础上定制自己的东西（我不把它称为产品，是因为许多定制出来的东西的确不是产品）；开源给程序员带来了快乐，他们可以学到学到新技术，可以学到许多新思想，他们可以通过开源贡献价值。快乐呀！！
韩非子“塞翁失马”的道理总是很快就体验到我们的身边，快乐到一个点，痛苦随着而来；艰苦的熬过痛苦，终于又看到了快乐；然后周而复始；直到那个终点出现（这个终点也是EJB与Spring等的汇合之点。）？看看下面的故事线索：
- 在网站系统创建的1-2年，是快乐的时候，Spring、WebWork等开源框架，很快就搭建了自己的系统，而且运转的那么好。
- 第三年，日用户量达到了百万，服务器也增加到了几十台，业务系统也达到10几个，终于进入了分布式领域，引入了SOA、远程服务、分布式事务、消息等技术。痛苦的开始。
- 第四年，服务器增加到了几百台，开发人员100-200人，解决发布冲突的问题、并行开发的问题等，引入了SCA、OSGI之类的思想和技术；数据量太大了，需要分布存储，引入了分库、统一数据访问、搜索等技术。痛苦在继续。
- 第五年，所有的指标都增加了翻了一倍，似乎一起都混乱了，需要治理，引入了服务治理、服务器监控、更强大的过程管理工具、更多的技术出现了。有人开始乐乐，有人更加痛苦了。
- 第六年………………..
日复一日，重复着这些过程，程序员就是这么可悲。开源并不能解决这个过程中遇到的困境，开源也不是上帝之手;一些开源技术把我们带入了快乐，也给我们埋下了痛苦的隐患。
在这个过程中，我们定义了一系列的规范、标准，就像制定EJB的规范一样来制定企业自己的技术规范；开发了一系列的技术，依然不能解决我们的难题。对玩技术的也许有些讽刺，我们在不断的给业务搞技术架构，却很少给自己的技术搞个架构，把我们的技术平台化，产品化，看看那些成功的互联网、软件公司，无一不会通过这种方式来化解上面的困境。看到技术，永远是点，点多了必然会乱；只有把点组织为有机体（产品），才会健康。“众里寻他千百度。蓦然回首，那人却在，灯火阑珊处”，这诗句写的就是好。
【备注：】朋友写的一篇文章：大型网站架构演变和知识体系，进一步证实了这种情况，即使在第九个阶段，也不是最终阶段呀。
闲话通用技术之一：EJB与Spring会否汇合
晚饭后，与几位同事在办公桌边消食，不知哪位兄弟说起了EJB，结果立刻引起了一片讨论。总体论调无非是EJB已经死亡，以及EJB死亡的原因，以及Spring为啥流行。
在此处我不想对此进行太多探讨，毕竟EJB还在不断进化，使用者也还是有很多；Spring等轻量级框架也在进化，使用者也很多；非Java领域也有很多 东西在不断创新的东西被大量使用。世界本来就是多样性的，关键是个体的选择。在软件领域，架构师对技术平台的选择，可以参考《构建架构的思考》一文的观点 （由三大类要素决定选择架构）。
来看看EJB，Spring的进化：
EJB1.0 –》EJB2.0 –》EJB3.0
Srping –》Spring Application 1.0 –》？？
从大趋势看：EJB标准由复杂走向简单，Spring从框架走向产品。抛开复杂度、个人兴趣等等，只看问题域它们都是一致的：
- 产品化
- 可管理
- 可监控
- 组件化
- 模块化
- 容器
- 事务
- 分布
- 开发者支持（工具等）
- 组装（Ioc特性）
那么它们的终点是否会汇合？
SOA是可持续的战略，不是一次项目
常常听到如下关于SOA的说法：
- 我们完成了SOA化改造。
- 我们的SOA化，已近实现了80%。
- 这次项目是为了实现SOA化，因此要请有这方面经验的公司来实施。
- 从技术角度层面来说，我们达到了SOA化的目标。
- 这是我们最后一个SOA个项目
- 等等
如果这些话出自程序员，项目经理等人员，也是无所谓的；如果出自IT管理层的人员，哪就是一种可怕的想法了。因为他把SOA仅仅看作是一次项目了，而没有把它作为战略。这样的后果也是可以预见的，最终本次投资将会失败。
因此，建议那些准备实施SOA的公司，首先回答这个问题：SOA是贵公司的一个战略吗？
为什么要回答这个问题？
- 从SOA概念来看
- 从SOA目标来看
- 从IT管理角度来看
- 从系统分析角度来看
- 从技术特征来看
关于什么是SOA，我有几篇文章，可以参考（《这些都不是SOA》,《ESB产品升级准备：SOA、ESB、JBI、SCA、OSGI概念再学习、再理解》,《SOA，想说爱你不容易》）。丛概念上可以看出，SOA不少技术问题，它是一种思想，一种架构，因而不可能通过一个项目就把这种思想或架构完全实现；思想也是会发展得，今天的思想在明天或许就会不适应。
SOA的目标是解决业务敏捷性问题。如今，大环境复杂多变，任何一个公司都不敢说自己的业务就是这几个、自己的业务会一直不会变，很多企业，在很短的周期内，就会推出各类产品（特别是服务类企业，例如：银行、互联网企业等）。只有那些能够快速适应变化，主动寻求变化的企业才能够生存下来，发展起来，例如：会跳舞的大象IBM，IT行业最大的特色就是变化快、发展快，如果IBM的业务不能敏捷的适应这种变化，它还能跳舞吗？正因为IBM深刻理解了SOA的目标，因而它把SOA看作一种战略–可持续的战略。
对于IT主管，一定要确保本公司的IT战略是可持续的，不能今天一种想法，明天又看到什么好思想，就换了一种想法，或者换个主管，就彻底换了战略（这种做法，就像我们国内的城市建设，路总是修不好）。既然从一种思路切合到了SOA领域，那么再次切换的成本将会更高，也不可能多种思路同时进行（吃得多，嚼不烂）。此外，谁能保证一次项目就确保几年内业务变化的需要？从我们实施的经验来看，必须持续的进行SOA化，才能确保SOA持续的发挥效果。
每次项目都要进行系统分析，都是基于当前的业务进行，那么不可避免的就会有一些盲点（从认知的角度看，人不可能一次就抓住事物的本质，何况大多数系统分析员不具有这种能力）和不合理支出。这些问题，只有在实施后一段时间才能发现（我们自己的实践经验）；此外随着补丁的实施，原有的系统已经恶化，和最初的SOA化目标越来越远。此时，如果不能再次用SOA的思想重新审视系统，就将彻底失去了SOA带来的好处。
SOA非但不能让系统架构变得简单，反而变得复杂了（系统设计要求变高了、系统部署复杂了、发布复杂了、各类SOA相关技术的引入增加了对人员的要求），这也是为什么要引入SOA治理。从这一点来看，只有持续的SOA化，才能最终发挥SOA技术架构的好处。
再次提醒将要进行SOA化的朋友和已经进行了SOA化的朋友，把SOA当作贵公司的可持续的战略来看，而不要认为它紧紧是一次项目。
SOA实践之：在程序层，面向服务的设计准则探讨
在面向OO领域有10几条设计准则，那么这些是否都能够延续到SOA领域的服务接口设计层哪？下面列出本人实践过程中，认为能够继续适用的一些原则：
- SRP 单一职责原则
就一个服务接口而言，应该仅有一个引起它变化的原因。
职责即为”变化的原因”. - ISP 接口隔离原则
不应该强迫客户依赖于他们不用的方法。接口属于客户，不属于他所在的类层次结构。
多个面向特定用户的接口胜于一个通用接口。 - REP 重用发布等价原则
重用的粒度就是发布的粒度. - ADP 无依赖原则
在包的依赖关系中不允许存在环.
细节不应该被依赖. - IDP(Interface Design Principle)接口设计原则
规划一个接口而不是实现一个接口。
-
其它一些可以参考的点：
- 放弃程序级别的OO概念。
- 业务的粒度就是接口方法的粒度。
- 接口方法尽可能简单、清晰、业务含义明确。
在实际应用中，按照这些准则，我总结了一些具体需要需要的点：《SOA实践之：在程序层，服务接口设计的一些准则》【对于这篇文档，会随着实践而不断补充】
一个程序员眼中的google和百度
我经常回去百度的贴吧看看，也会用百度搜索些MP3;日常工作中大部分使用google进行资料检索，email使用，链接收藏等。因为工作的关系，常常会寻找一些技术资料，对这方面也比较敏感，随着发现了如下一些差别。
1、google的更多页面：更多谷歌产品,百度的更多页面：百度产品大全。这2个页面很有意思的，百度的页面，基本都是信息搜索相关业务，其中音乐相关的就有3个；google的这个页面，处包括了一些信息搜索相关的业务外，还有Google 实验室，SketchUp(3D绘图软件),文件(在线建立、撰写、储存和分享您的文档与电子表格)等应用软件【因在搜索方面我是外行，因此不进行比较】。从这2个页面，我们就可以看出两者的一个差别，google全球把自己放在与yahoo，微软等公司竞争的层面【在中国，在搜索这个市场，它还是需要追赶百度的】，百度把自己放在国内门户类网站、C2C、B2C（或许还有B2B）竞争的层面。战略上还是有些差别的。
2、近日看到，google开辟了一个生活搜索频道，很是强大，见文章技术与产品-有感于google和口碑的搜房产品,百度没有类似的频道（有贴吧这样的社区频道），但传闻在搞B2C、C2C相关的内容，要与Alibaba系竞争了。从贴吧和生活搜索频道的差别来看，两者对于社区的发展方向是不同的。google在它的生活搜索频道中，极好的诠释了技术+整合+本地化=创新的产品。百度是自己聚焦人气，google是和别人分享人气。此外，从google与天涯等网站合作，也可以看出其社区建设的思路。
3、在技术领域，我们经常会听到云计算、MapReduce、BigTable、Google guice、google toolkit、Android等技术相关的论文、文章、介绍。却很少听到百度有关的内容【当然了，国内的互联网公司都很少听到这方面的东西，sina搞过Memcachedb 与 NCache，已经很不错了】。在技术领域的影响力和贡献力存在巨大差距，这种潜在的量能积累，在几年后会否转换为商业的优势？视目以待之。
4、在协作/共享领域，google提供了Google Maps API、OpenSocial API、Google Apps等等更多的API；在百度和国内其它互联网公司，在这方面却很少【有些根本没有开放的API】。作为一名程序员，我感谢google提供的这些技术分享，从中学到了很多；作为一名博客作者，我可以用google的这些API写点有意思的东西，也很是快乐。
总之：在国内，目前百度的商业是非常成功的；google还有很长的路要走。在国际上、在全球战略上、在开发者领域、在开放领域、在云计算领域等方面，Google已经走得很远了，Google也是值得敬佩的【很希望百度、国内其它互联网公司也在这方面能有突破，让我等程序员分享一下百度的技术果实】。在某些业务领域，虽然技术领先未必会赢得商业胜利，随着时间的前进，这种技术的优势会逐步体现出来。
近日又看到这篇文章浪潮之巅 第九章 硅谷的另一面（一）近日又看到这篇文章，讲了成功公司的几个原则：创始人、能盈利的商业模型、判断力和执行力、运气。
百度在这几个方面都占据了，所以它成功了；腾讯在这几个方面也都占据了，因而也成功了；淘宝到目前为止没有找到一个好的能盈利的商业模型，因此距离成功还有一步。
在这几个因素中，没有提到技术的因素，我认为国内有很多人也有好的想法，因为技术达不到，因此最终失败了，所以对于高科技公司，是否还要加上‘合适的技术体系’哪？
当跨出了第一步之后，商业模型能够被模仿，此时要获得领先优势，就必须依靠技术了。否则必死无疑，yahoo就是一个典型案例。
相关文章：
百度CEO李彦宏的成功之路
百度网络营收增速放缓 流量价值需深度开发 — Yahoo开发的新的广告系统在美国追赶不上google，百度的广告系统因为流量的原因，短期还是业务领先的，技术上还是有差距的，需要不断提升，才能使自己的盈利能力与流量地位相匹配。
韩国互联网公司击败国外巨头的启示：产品本土化的创新 — 淘宝是另外一个例子。
讨论Google搜索的一些文章：
谁比Google 懂中文?
Google的排名算法最权威解密
阻碍Google发展的11大搜索趋势
技术与产品-有感于google和口碑的搜房产品
这几日，房东要涨房价，因此准备看看我住的地方的房价。打开google，看到有个生活栏目，进去一看，也能搜房子。突然，我被它震惊了。【顺便看了一下它的其它产品，例如餐饮、工作（看到它和招聘网的合作）、出行票务，都是一个思路。】
- 产品简单，很容易使用，看不到无关的东西
- 搜索到的信息很多，但来源不同
- 列表情况下，鼠标放到某个信息位置，同步在右边的小地图，就能看到变量的位置指示
- 地图模式下，选择某个区域，放大后，右边就会列出选中区域的信息
- 地图模式下，鼠标点击地图的某一个数字圆圈上，就能提示处这个位置的房屋信息
- 切换城市的小标签，也很是方便，要是再有个输入框，就更好了【可能和它目前之提供这些城市的信息有关，不需要用户输入，这个界面就可以做到。当然了，如果能达到www.yoee.com选择飞机出发城市的效果也许更好】
下面就看看几张图：
列表模式：
地图模式：
信息来源：
口碑抓图：
演示链接：
Google列表搜索模式
Google地图搜索模式
口碑搜索模式
Google在这个产品中，充分利用了它的搜索技术、地图技术、AJAX技术，把三者完全整合在了一起。在看看Google在其它产品中对地图的使用。我们不得不惊叹它内部的架构是多么强大，一个产品可以容易的应用到不同业务中，这又是一个基于SOA思想的真实案例【参看这些都不是SOA，Google把它内部的产品完全服务化，基于这些产品，能够快速的推出各类中产品】。
反之，我们再看看Yahoo中国与Alibaba的结合，最近Yahoo中国与口碑的合并，很难看到Yahoo的搜索技术【yahoo虽然在06年也推出了地图服务，但现在却很少看到应用，特别是中国】对Alibaba、对口碑产生的技术支撑【纵观整个alibaba集团，在技术层面，缺少集团层面的架构规划和设计】。
2个公司产品，至少在查询房屋信息这个业务目标上是一致的。在这个业务目标上之所以产生了如此巨大的差异，来源于技术的差异，口碑的技术不能支撑它达到Google的这个高度【我也看到其它一些房屋搜索产品，甚至提供了三维地图，但用起来却没有google的这么爽？为什么，除去信息地图信息不完整之外，还有Web页面技术上的差别】，我想口碑也是很希望做到这个效果的。
在Google这个产品的背后，还隐藏着云计算的支撑。这么大量的房屋信息，地图数据，速度却非常快，依赖一般的服务器技术是很难实现的。有时候，我总觉得Google的云有些虚，但它已经通过一个一个的产品来证明云的强大和实在【或者说Google得技术的强大】。
细节的差异，这2个产品，在页面设计上，输入框的摆放上，也有很大的差距，体验也很不同。我们很多网站，在做页面时，只是简单的参考别的网站的样子，而不花费大力气在页面设计上，设计出来的网站毫无新意，死气沉沉。
Google在这个产品中，没有自己的房源录入功能，它完全聚合了外部的独立房屋信息提供者。它提供的是一个平台，至少这些房屋信息提供网站，不需要开发这样一个强大的终端【或许它也开发不出来】，每个房屋信息提供网站只需要专注于自己抓住自己的房源【注：从知名度，广告收益等角度看，对于大的信息提供网站是弊大于利；对于小的信息提供网站事利大于弊。对于Google来说，通过这种方式，可以吸引更多的客户，让小的信息提供网站成为信息提供商，自己免去信息维护；自己再把这些信息包装成产品，从而开拓新的业务领域—整合优势、双边获益。Yahoo中国如果能够整合Alibaba的商业信息，其它一些小的商务网站的信息，或许是个好注意。疑问：Google未来是否会成为一个门户平台（或服务平台），它提供类似搜房这样的产品，信息都是别人的，自己只是一个门】。
以前，我对技术鼓励创新感觉还是模糊的，Google的这个例子，震惊了我。同样的业务，通过技术，整合，好的产品设计，也能够起到老树开新花的效果。
【感受总结】
- 架构：整个公司（集团）层面的架构的好坏，对业务有很大的影响
- 技术研究不可或缺，没有扎实的技术，有些业务很难达到预期效果
- SOA的思想，要贯彻业务和技术2大层面
- 开放、协同、整合同样能够带来新的产品；甚至扩大市场
- 云计算不是虚的；要支撑无限扩大的业务量，必须发展云计算（分布式技术）
- UI技术的研究，对产品体验的好坏，影响巨大
- 产品设计（UI设计），不是简单的摆放
- Google的这种侵入模式，对同类业务的网站是否有很大的冲击，再观察之。但这种模式，却值得我们借鉴–技术与业务的出色结合。
- Google中国正在变化，它利用自己的技术在不断变化
- 技术型网站和业务型网站发展的方式很不同。但技术和业务最后必须同步发展，互相支撑，终点时啥样？或许2者和为一体！
资料：
阿里巴巴威胁刚刚开始 诚信认证缺失后劲堪忧,这篇文章的最后2段话，说的还是有些道理的。业务上要练功，技术上也要练功；就像武侠里的外功【业务】和内功【技术、企业文化等】，只有2者都强了，才能持续胜利。
洪波：谷歌的对手是阿里巴巴而非百度
这些都不是SOA
在和同事们讨论我们的服务化过程中，以及网上看到的一些帖子，甚至在某些SOA的宣讲会中，把以下情况都认为是在搞SOA：
- 使用web服务的应用就是SOA
- 使用RESTful的应用就是SOA
- 使用了分布式计算就是SOA
- 使用WS-*扩展的web服务应用就是SOA
- 使用了ESB产品，就是SOA
- 使用了SCA产品，就是SOA
- 使用了IBM,Microsoft等公司提供的SOA产品，开发出来的应用就是SOA
以上这些情况都不是SOA。SOA是以业务入口点，来自于实际的业务需求，以下例子才是真实的SOA。
XX航空集团开发的独立系统很多，现在需要把信息流整合起来，制作更全面的报表、提升信息流转的速度、方便信息分享、提高信息检索速度等，此时从业务信息整合的角度出发，以服务的思想构件了一个新的统一信息平台。
我们公司存在同样一个业务逻辑，会用在WEB平台，手机平台，管理平台，开放平台（还有其它原因，参考SOA，想说爱你不容易）,原有的做法是共享类库，直接操作SQL等实现，现在利用SOA的思想，把这个业务逻辑封装为服务，供所有平台使用。
Yahoo中国和口碑合并，内部系统必然涉及到人员，业务流程的变化，采用SOA就能够化解之（我们常常看到一些报道，某公司收购另外一个公司，信息化系统的整合往往花费几年时间[当然还有其它原因，例如文化]，甚至会失败。案例表明：采用SOA的公司，成功率高于不采用SOA的公司）。
参考资料：
http://www.infoq.com/cn/news/2007/07/soa-ws-relation
IBM提供的实践文章
IBM 内的 SOA 应用，第 1 部分: SOA 案例研究
IBM 内的 SOA 应用，第 2 部分: SOA 案例研究
IBM 内的 SOA 应用，第 3 部分: SOA 案例研究
IBM定义的SOA入口点：
云计算(Cloud Computing)是什么–读google云计算新闻有感
【文章】云中漫步——迎接云计算时代的到来
云界面为使用者提供透明的服务入口；云是一个虚拟群；云内部提供各类服务，包括saas；使用者把各类云服务整合起来之后的应用，又可以通过google的AppEngine来驻留。如果用户自己的应用也可以加入到云中【有点服务的味道了】，就更好完了。
【新闻】Google CEO施密特访华时，谈到云计算。他认为，云计算将替代网格计算。
云技术代替网格计算，说明它们是一个路线，分布式路线。疑惑的是，有关差别无法比较：云计算强调发挥虚拟中央的计算、存储能力；网格计算是强调发挥终端的计算能力，整个互联网形成一个大的计算平台。另一个概念，P2P，发挥终端的计算和存储能力，它和云有啥关系？
P2P、网格都强调客户端的计算能力，云强调服务端的计算和存储能力。这几个领域有各自的来源背景和目的，最可能的趋势是融合，而不是代替。
【新闻】Google CEO说：“服务信息都不是存在于个人电脑上，而是存在网络中，云计算是开放标准 ，业界不会有公司独裁，实际上不是只有Google一家在做云计算。”
云计算难道就是解决信息存储的问题吗？粗略看，这个定义和李开复讲的云计算有些不同，李强调服务，此处强调数据存储；细细琢磨，李讲的那些东西【”利用 Google Sites 搭建网站，利用 Gmail 提供企业邮件服务，利用 Google Calendar 管理日程信息，利用 Google Docs 分享企业内部文档，GFS（分布式文件系统）、MapReduce（分布式计算系统）以及 BigTable（分布式存储系统）”】，数据都存储在google上；再看看
Amazon的S3+EC2【Dynamo】,提供的也是存储相关的服务。原来，云计算以数据存储为基本核心之一。
最终，google的云是：
网络数据中心、数据银行 –>数据分析、数据挖掘、数据搜索
，它所有的服务都是围绕这个中心开展，再利用云提供的分布式计算能力【通过MapReduce来实现】，从而形成完整的云计算。
【新闻】雅虎正在借助 Hadoop 开源平台的力量对抗 Google, 除了资助 Hadoop 开发团队外，还在开发基于 Hadoop 的开源项目 Pig, 这是一个专注于海量数据集分析的分布式计算程序。Amazon 公司基于 Hadoop 推出了 Amazon S3 ( Amazon Simple Storage Service )，提供可靠，快速，可扩展的网络存储服务，以及一个商用的云计算平台 Amazon EC2 ( Amazon Elastic Compute Cloud )。在 IBM 公司的云计算项目–”蓝云计划”中，Hadoop 也是其中重要的基础软件。Google 正在跟IBM合作，共同推广基于 Hadoop 的云计算。
其它公司的云的核心基础是：数据存储，对使用者是一个数据源，云内部的数据存储提供者可以是分布式存储系统，甚至其它方式；云内提供分布式计算能力【也可以用MapReduce实现，或者其它技术】，从而形成完整的云计算体系。
从Googel，其它公司实现云计算的方式可以看到，云计算 的构成 （数据存储 + 分布式计算）& 服务[n]（N=0,1,2…）。【此处的服务可以是具体的业务产品，例如：Google Docs ，报表产品等；也可以是一种算法，例如：基因图谱定序，搜索算法等。】
看到大量“IBM中国云计算中心落户江苏无锡”的新闻，从报道中的内容与大部分公司提供的云计算方式来看，还是有些不同的，IBM这个中心提供的貌似就是一些软件，难道又是为了挣个眼球？
云与SAAS
- 在某些具体业务领域，两者存在竞争关系；云强化了SAAS的能力。
- GOOGL的云路径：从搜索开始，逐步到SAAS服务，最后到云。为用户提供信息化解决方案。
- 单纯的SAAS，也可以把云作为自己的后端来发展，从而强化自己。
- 云忽略具体业务，SAAS强调具体业务。
- 云强调基础服务，单一服务，容许用户自行定制，扩展，承认用户是懂IT的；SAAS强调功能的完整性，假定用户不需要知道IT知识，而把业务系统完全外包。
云与SOA
- 两者不具有比较性，来源背景，目标都完全不同。
- 云发展自网格；SOA发展自企业信息化建设。
- 云提供的能力可以作为SOA的一个服务，例如：存储服务，计算服务。
- SOA更适合企业级应用，是一种思想和架构思路；云是一种技术路线。
- SOA专注于业务的敏捷；云专注于数据和计算的能力的供给。
- SOA业务产品可以加入到云中。
术语
SaaS（Software as a Service，软件即服务）是应用软件的一种销售方式，客户按使用时间或使用量付费。这些应用软件通常是在企业管理软件领域，并通过互联网来使用。SaaS（软件即服务）具备这个特点：“软件部署为托管服务，通过因特网存取。”
SOA（Service-Oriented Architecture，面向服务架构）是一个面向服务的架构模型，它将应用程序的不同功能单元——服务（service），通过服务间定义良好的接口和契约（contract）联系起来。接口采用中立的方式定义，独立于具体实现服务的硬件平台、操作系统和编程语言，使得构建在这样的系统中的服务可以使用统一和标准的方式进行通信。SOA与大多数通用的客户端/服务器模型的不同之处，在于它着重强调软件组件的松散耦合，并使用独立的标准接口。
云计算（Cloud Computing）是基于互联网的商业计算模型。利用高速互联网的传输能力，将数据的处理过程从个人计算机或服务器移到互联网上的服务器集群中。这些服务器由一个大型的数据处理中心管理着，数据中心按客户的需要分配计算资源，达到与超级计算机同样的效果。
【相关文章：】
也谈云计算
云计算、SaaS和企业2.0
云计算（cloud computing）10问
Amazon Elastic Compute Cloud (Amazon EC2)
Amazon EC2 Gains Favor with JEE and Groovy Developers
用 Hadoop 进行分布式并行编程
什么是云计算
新闻周刊：云计算道路曲折前途光明
