【日志归档】 06月, 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者都强了，才能持续胜利。
洪波：谷歌的对手是阿里巴巴而非百度
【收集-003】开启智慧：哲理寓言十三则
转自：http://www.qzqz.cn/kegai/ShowArticle.asp?ArticleID=7421
1.应万变的能力
鸟儿们聚在一起推举它们的国王。孔雀说它最漂亮,应该由它当,立刻得到所有鸟儿的赞成。只有穴鸟不以为然地说:当你统治鸟国的时候,如果有老鹰来追赶我们,你如何救我们呢?
原意：做任何事一定要深谋远虑,才不至于害了自己。
新意：富贵名誉,自道德来者,如山林中花,自是舒徐繁衍；若以权力得者,如瓶钵中花,其根不植,其萎可立而待矣。
说明:一个哈佛经理,当储备多方才能,不只在才识方面要有过人之处,更当有应万变的能力,如此,不但可服人,并且还能对付不可预知的意外事件。
2.本性难移
一只雌猫爱上一位英俊的青年,就向女神亚福罗迪特祈祷,请求把它变成人的样子。女神被它的真情感动,就把它变成美丽的少女。青年看到这位少女,一见钟情, 两人彼此爱慕,就结婚了。有一天,亚福罗迪特想试探猫在变成人形后性格有没有改变,就在房间里放进一只老鼠。这时,猫忘记自己已经是人,就从床上跳下来, 敏捷地捉住那只老鼠,放进嘴里吃掉。女神看了大叹一声,便将它恢复成原来的模样。
原意：一个人即使外貌改变了,性情仍是不易改变的。
新意：欲火难抑,猛然转念,明知犯着,邪魔又生。
说明: 江山易改,本性难移,染色的乌鸦,禁不起雨水的冲洗。要了解一个人的本性,须从他日常待人处事的细节上观察,不可只看外表,而遂下结论。
3.量力而行
老鹰从很高的岩石上向下俯冲,用它的利爪抓在小绵羊身上,穴鸟看到了,心想自己一定比老鹰强,就模仿老鹰的动作,飞到绵羊身上,没想到脚爪却被绵羊弯曲的 毛给缠绕住,拔不出来。牧羊人发现了,就跑过去把穴鸟的脚爪尖剪掉,把穴鸟带回去给孩子们玩。孩子们很想知道这是什么鸟,牧羊人说:据我所知,这是穴鸟, 但是它却自以为是老鹰。
原意：人不可不自量力。
新意：世人皆知名利为荣,不知无名无利之乐为最真。好高鹜远必自讨苦吃。
说明:人各有所长,要了解自己的能力去发展。看到他人名利双收,便想依样画葫芦,是得不偿失的。看他人经营贸易赚钱,忘却自己在个性、专业上不适合,便思自立门户,失败往往接踵而来。
4.合营前的思考
因为狮子的力量大,而野驴跑得很快,狮子野驴便合作一起狩猎。有了丰收后,狮子把猎物分成三等分,说:因为我是万兽之王,所以要第一份；我帮你守猎,所以我要第二份；如果你还不快逃走,第三份就会成为使你丧命的原因了。
原意：知已知彼,百战百胜。
新意：应走不走,反受掣肘,反受其乱。
说明:苏秦的连横政策,远交近攻,先并吞最弱国,再并吞次弱国；反之,公司经营,若因为想并占财力微弱的公司而联合比自己财力雄厚的公司,最后通常是得不偿失的。
5、珍惜权力
狮子爱上了农夫的女儿，请求农夫将女儿嫁给它。农夫既不忍心把女儿许配给猛兽，又不敢拒绝，就想出了一个方法。当狮子来催促的时候，农夫对它说:我很愿意 将女儿嫁给你，但她很怕你的尖牙利爪，如果你剪掉它们，我女儿立刻与你结婚。狮子立刻答应了，回去剪掉它的尖牙和利爪。可是如此一来，农夫就不怕狮子了， 当狮子再来的时候，农夫就用木棒把它赶走了。
原意：轻易放弃已有的力量是一种不智之举。
新意：鱼不可离开深渊，国家赏罚的利器不可随便易人。
说明:一个哈佛经理，切勿轻易放弃自己的实权，否则一旦失去，再要索回，为时已太迟了。
6、未雨绸缪
一只山*在大树旁勤奋地磨獠牙。狐狸看到了，好奇地问它，既没有猎人来追赶，也没有任何危险，为什么要这般用心地磨牙。山*答道:你想想看，一旦危险来临，就没时间磨牙了。现在磨利，等到要用的时候就不会慌张了。
原意：防患于未然的工作是绝对需要的。
新意：未雨绸缪，善养天机，日后便有真道。
说明：书到用时方恨少，平常若不充实学问，临时抱佛脚是来不及的。也有人抱怨没有机会，然而当升迁机会来临时，再叹自己平时没有积蓄足够的学识与能力，以致不能胜任，也只好后悔莫及。
7、短暂的快乐
一间蜂蜜工厂的仓库里，洒了很多蜂蜜，吸引了许多苍蝇飞来吃，而且因为蜂蜜太香了，它们都舍不得离开。不久，这些贪吃的苍蝇都因脚被蜂蜜粘住而飞不走了。当它们快溺死时，很难过地说:我们真是太贪心了，为了短暂的快乐，却赔上了宝贵的生命。
原意：美食往往成为许多灾祸的原因。
新意：得意时，便生失意之悲；不贪为实，可渡越一世。
说明:贪婪是一切祸乱的根源，不论做人处事，都必须戒慎。与人相处，若好贪便宜，必将受人唾弃；经营事业，若好高鹜远，不能本诚信原则慢慢扩张也难长久。
8、能力与待遇
主人将货物分成两份，平均分给驴和骡背，驴看到自己背的东西和骡一样多，很气愤地说:人们给骡吃的食物比我多一倍，却让我和它驮负一样重的货物。走了一段 路以后，主人看到驴支持不了，就把它身上的货物移一部分到骡背上。再走了一段路以后，驴更没精神了，又把货物移过去一部分，最后，驴身上空无一物。这时骡 瞪着驴说:你现在还会认为我多吃一倍食物不应该吗?
原意：判断一个人的能力，一定要长期观察，不可逐下评论。
新意：人之际遇，有齐有不齐，相观对治，不亦齐乎?
说明：一个组织的工作，可分成例行工作及解决问题的工作。通常是愈富有解决问题性质的工作，工资愈高，但所承受的压力也愈大。有些专做例行性工作的人，却埋怨工资比不上其他人，但他若有机会尝试解决问题性的工作时，就会了解别人是否比他有能力多了。
9.两面人的防范
一只狐狸被猎人追赶，它看到樵夫，赶紧向他求救。樵夫让它躲在自己的小茅屋里。不久，猎人追到，问樵夫有没有看到一只狐狸经过?樵夫既虽然说没有看到，手 却指向狐狸躲藏的地方。可是猎人没有看到樵夫的手势，就离开了。狐狸看到猎人走了，立刻跑出来，没有向樵夫道谢就要离开。樵夫责备它不知感恩，狐狸回答 说:如果你的心口如一，我就会向你道谢了。
原意：口蜜腹剑的人不可不防。
新意：发现隐私不如扶公议；欲使人知恩，不若无恶无结。
说明：笑里藏刀，言行不一致，便是两面人。故事中樵夫嘴里想讨好甲，又想讨好乙；想两边都得到好处。公司里也有许多这种两面人，在大家的面前假装很讲义气、够朋友，但在私底下却揭人隐私，到处告状。
10.供奉者的目的
有一个人为了供奉半神(介于人与神之间的英雄)花了许多钱财，所有的供品都用最上等最名贵的。一天夜里，半神现身对他说:你不要再把大笔的钱花在我身上了，否则一旦你没钱了，一定会把所有的罪过都归在我身上。
原意：在付出之际，即要有所认知，以免在得不到回馈时，而反责于人。
新意：以财货讨好人者，必有所求，受者不可不慎。
说明：荀子云:下臣事君以身，上臣事君以人。下臣事君以货，所愿不得遂毁之。组织里若有人送礼太大，必有所求，如所求未遂，则常反向攻击。
11.以理服人
已饱餐一顿的狼发现一只绵羊倒在地上，知道绵羊是因过分害怕而昏倒，就走过去叫它不要怕，并答应绵羊，只要说出三件真实的事情就放它走。于是绵羊说出下面 三件事:第一是不想遇到狼，第二是如果一定要遇到，最好是只瞎眼的狼，第三:我希望所有的狼都死掉，因为我们对狼丝毫没有恶意，而狼却常来攻击我们，欺负 我们。狼认为绵羊说的话都没有错，就放它走了。
原意：真理有时还真能感动敌人。
新意：看到敌人惊破胆，一任覆雨翻云冷透心。随缘去，点头入无生机自然。
说明:在公司里，小职员碰到董事长时若缺乏自信，觉得自己处处不对劲，就会被看成庸才，若能镇定地讲出心中的感受，让老板真正地了解问题、解决问题，必能受到赏识。
12.反躬自省
狐狸在跨越篱笆时脚滑了一下，幸而抓住一株蔷薇才不致摔倒，可是脚却被蔷薇的刺扎伤了，流了许多血。受伤的狐狸就埋怨蔷薇说:你太不应该了，我是向你求救，你怎么反而伤害我呢?蔷薇回答道:狐狸啊!你错了，我的本性就带刺，你自己不小心，才被我刺到的啊!
原意：遭遇挫折时不反躬自省 ，反而责怪或迁怒别人，是无济于事的。
新意：责人之错须据理，因人品极处是本然。
说明:有句俗话说:一个快淹死的人，连一根稻草也会赶紧去抓，但却常因饥不择食，反而无济于事。同样地，遭遇不幸时，若只知向人求救，不知自己想办法，很 可能反而会被落井下石。有许多商人，在周转不灵时便求助于高利贷，结果为了负担利息反而愈陷愈深，后悔也来不及了。
13.居高位者自重
在一次百兽舞会中，狮子因为舞跳得很好，被推举为王，一只狐狸很嫉妒，看到猎人设的陷井里有一块肉，就说找到了宝物，但不愿独占，要献给国王，力劝狮子去 拿那块肉。狮子听了很欢喜地走了过去，结果掉入陷井，很生气地说：“你为什么要骗我？”狐狸说：“啊！狮子先生，像你这么愚蠢，怎能当百兽之王呢？”
原意：不假思索便伸手索惠的人，注定会失败。
新意：居高位若案牍无节、名根不除，便易随入尘情。
说明：勿以为得势而可生贪婪，或天下人都应归顺，将所有的好处留给自己。在公司里，若当上主管，应会分辨什么是应得的，什么是不应得的，不可来者不拒，予人危害之机。
控制情绪，不要制造伤害
从前，有一个脾气很坏的男孩.他的爸爸给了他一袋钉子，告诉他，每次发脾气或者跟人吵架的时候，就在院子的篱笆上钉一根。第一天，男孩钉了37根钉子。后面的几天他学会了控制自己的脾气，每天钉的钉子也逐渐减少了。他发现，控制自己的脾气，实际上比钉钉子要容易的多。终于有一天，他一根钉子都没有钉，他高兴的把这件事告诉了爸爸。
爸爸说：”从今以后，如果你一天都没有发脾气，就可以在这天拔掉一根钉子.” 日子一天一天过去，最后，钉子全被拔光了。爸爸带他来到篱笆边上，对他说：”儿子，你做得很好，可是看看篱笆上的钉子洞，这些洞永远也不可能恢复了。就象你和一个人吵架，说了些难听的话，你就在他心里留下了一个伤口，像这个钉子洞一样。”插一把刀子在一个人的身体里，再拔出来，伤口就难以愈合了。无论你怎么道歉，伤口总是在那儿。要知道，身体上的伤口和心灵上的伤口一样都难以恢复。你的朋友是你宝贵的财产，他们让你开怀，让你更勇敢。他们总是随时倾听你的忧伤。你需要他们的时候，他们会支持你，向你敞开心扉。”告诉你的朋友你多么爱他们，告诉所有你认为是朋友的人，你的行动可以从邮寄这个小小的故事开始。有一天，当这封信回到你的信箱里时。你会发现你有一个很大的朋友圈.
永远不要嘲笑别人的梦想。不要随便给一个人定性。说话时要慢，思想时要快。
打电话的时候请你微笑，对方一定感觉得到。
农民的抉择【与范跑跑的抉择】
一个农民从洪水中救起了他的妻子，他的孩子却被淹死了。
事后，人们议论纷纷。有的说他做得对，因为孩子可以再生一个，妻子却不能死而复活。有的说他做错了，因为妻子可以另娶一个，孩子却不能死而复活。我听了人们的议论，也感到疑惑难决：如果只能救活一人，究竟应该救妻子呢，还是救孩子？于是我去拜访那个农民，问他当时是怎么想的。他答道：“我什么也没想。洪水袭来，妻子在我身过，我抓住她就往附近的山坡游。当我返回时，孩子已经被洪水冲走了。” 归途上，我琢磨着农民的话，对自己说：所谓人生的抉择不少便是如此。
范跑跑相关的文章：
“范跑跑”现象争鸣的理性对待
博客专访范跑跑：八级大地震 逃跑不丢人！
“范跑跑”让我们学习如何面对“异端”
教师地震时不顾学生先跑被教育部取消从教资格
策划：道德拷问
替罪羊拯救不了我们的道德灵魂：谈范美忠事件
下面是感人的故事：
“四川汶川地震”感人故事
四川汶川8级地震中感人故事全集
汶川地震中的感人故事
组图：抗震救灾15大感人绿镜头 致敬最可爱的人
游客拍下首批空降兵勇士伞降灾区场景(组图)
哀悼与团结的曲线
双胞胎儿女同时溺水 父亲内疚只救一人
危机时刻的抉择，真能看得很清楚吗？
这些都不是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入口点：
【收集-002】忍耐的风度
在西方，考核一个政客的第一道试题——忍耐。
光是漫长而激烈的竞选过程就够难熬的，其间还会碰上无数意想不到的打击，没有
足够的忍耐力是坚持不下来的。即便成功地爬到了国家政要的位置上又怎样呢？他们在
国内接触选民或出国访问的时候，有谁没遭到过民众的围攻、谩骂，甚至还受到过石
头、臭鸡蛋和西红柿的袭击？
远的不讲就说最近的。全世界都知道英、美关系最好，美国新当选的总统布什第一
次访问英国，毫无例外地受到了英国民众的抗议。群众聚集在他要经过的街头，举着旗
子，喊着口号，指责他在美国部署和发展“反导弹系统”和拒不在维护世界环境的“京
都议定书”上签字……抗议达到高潮时就有鸡蛋像绣球一样朝他抛去——是不是臭的，
从电视画面上看不真切。没过几天，英国首相布莱尔出访另一个同盟国，也受到了跟布
什大致差不多的“礼遇”。当时他们的表情:你骂你的，你扔你的，我尴尬归尴尬，只
要你没有一石头把我的脑袋开了瓢，我就该笑还要笑，该说还要说，该干什么照干不
误!
有时还不仅仅是政客，只要在西方做个名人或有钱有势的人，就很容易碰上类似的
尴尬。2001年3月29日，世界银行行长沃尔芬森在芬兰举行记者招待会，突然遭到蛋糕
袭击，满头满脸都是奶油，像烂葡萄一样滴流甩挂，他仍不忘保持风度，并立即为自己
解嘲:“味道还不错，只是这东西破坏了我的节食计划!”
没有这两下子，怎么当一个大名人或做一个现代政客？像2001年春天英国大选时的
那个工党副首相，人家打了他一下，他马上回一拳，愣把人家给打倒了!痛快倒是够痛
快，可自己的政治前程也叫这一拳给打飞了。“小不忍则乱大谋”，你心里既有“大
谋”，在小处就要能忍。
云计算(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 进行分布式并行编程
什么是云计算
新闻周刊：云计算道路曲折前途光明
ESB产品升级准备：SOA、ESB、JBI、SCA、OSGI概念再学习、再理解
这几日看了许多SOA，ESB，JBI，SCA，OSGI相关的书籍、BLOG、文章、JavaOne上的一些资料，希望在ESB产品升级之前，能对这些概念再次进行学习、理解。明确术语，确定关系。
SOA
-
SOA是一种业务建模思想，是一种架构风格；它以服务为核心，构建系统；通过进化控制节奏;【摘录】支持对业务进行整合，使其成为一种能够相互联系、可重用的业务任务或者服务。
- 一种业务建模思想
SOA是一种业务建模思想，而不是一种技术体系。它来自业务敏捷的需求，植根于业务，致力于提升业务的敏捷性。
最低层面：使用SOA的思想分析、重构业务，用服务的概念定义业务单元。实现层甚至使用现有技术体系，选择几种结构型模式：Façade模式，Proxy模式，Composite模式配合，从而达到原始的SOA层面。SOA并不强制我们必须分布，必须采用一些支持SOA的技术或产品，只要业务敏捷了，且当前技术架构也能够满足生产发展的需要，就是合适的。 - 一种架构风格
SOA也是一种架构模式，特别是一种分布式架构模式。
实践观点：第二个层面以第一个层面为基础，没有第二个层面，只有第一个层面，我们还可以说这个系统是SOA化的；没有第一个层面，只有第二个层面，这个系统是否SOA化，值得商议。(IBM提出的SOA切入点中，包含有以技术为中心的切入点【连通性】，从我们实践、公开案例的实践、专家有关SOA实践的书籍来看，以业务为切入点是最合适的，也是最容易成功的，获得组织支持的概率也大；单一的基于技术切入SOA架构，案例较少)
它的一些特征：
以服务为基本单元，可以把服务视为构件。
服务质量可度量，且可以提升。
基于开放标准。
该架构同时是一种分层架构。
具有分布的能力。
与技术无关性。
鼓励扩展。
支撑业务敏捷的要求。
架构层面主张组合。 - 服务设计的原则
松散耦合
服务契约
自治
抽象
复用性
组合性
无状态性
可发现性
互操作性
【注：此处的架构仅指技术相关的架构。】
IBM的SOA架构框架：
该图从技术层面描绘了SOA的架构模型，以及OA技术架构所包含的主要概念。
ESB
-
ESB是一类中间件产品的通称；是一种分布式的技术架构，以中介为核心概念；是一种支持SOA实施的技术选择；来源于集成的需要，实现服务、系统之间的互联、整合；ESB产品通常提供一种容器，方便插入各类通用服务（编排服务、消息服务等）、提供服务虚拟化的能力（协议和模式、接口、身份等）、提供面向方向的连接（安全性、管理、日志记录和审核等）；支持业务逻辑和实现的技术逻辑的分离。
-
它使用XML（可扩展标识语言）作为标准通信语言。
它支持Web服务标准。
它支持消息传递（同步、异步、点对点、发布-订阅）
它包含对服务编制（orchestration）和编排（choreography）的支持。
它包含智能、基于内容的路由服务（itenerary路由）。
它包含转换服务（通常是使用XSLT），在发送应用和接收应用之间转换格式，简化数据格式和值的转换。
它可以条件路由，或基于非集中策略的消息转换，即不需要集中规则引擎。
它提供对服务监控、治理相关的内容。 -
参考资料：
http://www.ibm.com/developerworks/cn/architecture/ar-esbpat2/index.html
http://www.ibm.com/developerworks/cn/architecture/ar-esbpat1/index.html
http://www-128.ibm.com/developerworks/cn/webservices/ws-esbscen/index.html
http://www.infoq.com/cn/articles/ESB-Roundup-Part1-Defining-ESB
http://www.ddj.com/java/201200303;jsessionid=DP5D5J5VEP4XKQSNDLPSKHSCJUNN2JVN?_requestid=459785
最常用到的特性:
JBI
-
【摘录】是基于面向服务体系提倡的方法和原则，为了解决 EAI 和 B2B 若干问题的 Java 标准。JBI 定义了基于插件方式的架构，以便服务能融入“ JBI 运行时”环境。 JBI 提供了详细的接口，使服务能与“ JBI 运行时”环境交互。
- 资料：
http://soaneu.blog.com.cn/index.shtml
http://www.jcp.org/en/jsr/detail?id=208
http://www.infoq.com/jbi
服务引擎、组件绑定图：
本图强调了服务引擎，组件的绑定方式，更倾向与产品的扩展。对业务级别的服务模型支撑比较弱，业务通过API来实现与JBI产品的交互。
SCA
-
服务组件体系结构 (SCA) 是一个规范；是一种架构模式；是一种通用的面向业务服务的组件模型；定义了部署模型；提供了实现提供服务和使用其他服务的组件、组装组件，以通过服务引用其他服务的方式来构建业务应用程序–与SOA组合的原则一致；SCA是平台无关的；SCA是一种编程模型；支持业务逻辑和实现的技术逻辑的分离；是一种支持SOA实施的技术选择；SCA支持组件的分布。
- 资料：
http://dev.yesky.com/topic/308/7667308.shtml
http://www-128.ibm.com/developerworks/cn/webservices/ws-theme/ws-soa.html#sca
http://www.davidchappell.com/articles/Introducing_SCA.pdf
http://www.osoa.org/display/Main/Service+Component+Architecture+Home
http://www.infoq.com/sca
http://www.infoq.com/articles/setting-out-for-sca
http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-41500&yr=2007&track=3
【摘录】is a set of specifications which describe a model for building applications and systems using a Service Oriented Architecture. SCA models solutions as sets of service components offering services and making references to services supplied by others, which are combined together by composites which wire references to services and which declaratively apply bindings for communication methods and also apply policies for aspects such as security and transactions. SCA extends and complements prior approaches to implementing services, and SCA builds on open standards such as Web services.
核心概念图：
本图强调了组件模型，服务组件之间的组合模式，把业务级别和系统级别的组件，同等对待。提供了业务组件接入容器的方式。完全符合SOA的概念。
OSGI
-
【摘录】一个开放并且提供统一接口标准的体系框架，基于这个体系框架，服务提供商，程序开发人员，软件提供商，服务网管运营商，设备提供商能够协调地联合起来开发，部署以及管理向用户提供的各种服务。
- 资料：
http://www.riawork.org/
http://www.infoq.com/osgi
http://www.osoa.org/download/attachments/250/Power_Combination_SCA_Spring_OSGi.pdf?version=3
http://xml.coverpages.org/OSGi-ServicePlatformOverview2004.pdf
http://www.blogjava.net/BlueDavy/archive/2007/10/14/152820.html
http://www.blogjava.net/hx9111/archive/2006/11/10/OSGi-SCA.html
http://www.blogjava.net/zhaobin/archive/2007/11/06/158485.html
【摘录】provides a service-oriented, component-based environment for developers, primarily on the
Java platform. It provides a dependency resolution mechanism, with version support and also offers standardized ways to manage the software lifecycle. OSGi is a particular boon when using different components that use different versions of some shared package. These capabilities greatly increase the value of a wide range of computers and devices that use the Java™ platform.
相互之间的关系
- SOA – ESB
ESB是一种支持SOA实施的技术选择。 - SOA – JBI
JBI是Java领域一种支持SOA实施的技术选择。 - SOA – SCA
SCA是一种支持SOA实施的技术选择。 - SOA – OSGI
没有直接关系,目的不一致。 - ESB—JBI
JBI和ESB是互补的。JBI提供一个模型和将集成组件作为服务的标准接口。JBI可以宿主在一个应用程序服务器环境或者在一个ESB容器中。ESB提供了一套基础架构包括了事件驱动的SOA，高度分布的路由目的地命名，企业消息能力和分布管理能力。 - JBI – SCA
【摘录】SCA has a strong model for defining composite applications、Services can be implemented in multiple languages、Can bind interfaces and references to different technologies。
JBI:Defines a standard, loosely coupled, ESB architecture、SE / BC are exchangeable between JBI implementations、Provides standard abstraction for all JBI components。
融合性：When combining JBI and SCA, all JBI service engines can be used in SCA components, SCA components can be called from JBI, SCA applications can be deployed as service units in a JBI container. - SCA-OSGI
相同点：都是一种规范；都是一种架构；一种编程模式；都定义了模块，服务概念。
不同点：OSGI强调模块的动态性；SCA强调服务的分布性；OSGI来源与单个JVM产品架构的需求；SCA来业务SOA化的技术需求；OSGI更适合产品架构；SCA更适合业务系统架构。
融合性：SCA可以作为Bundle部署到OSGI环境，以增强OSGI环境的业务架构解决能力；OSGI可以作为一个模块部署到SCA环境中，从而利用OSGI环境下的基础通用服务。 - SCA-ESB
相同点：都是SOA的一个可选的技术方案；都基于服务的概念；都是可分布的；都提供插件特性等。
不同点：SCA是一个标准，ESB是一个概念；SCA有模块的概念，ESB没有这个概念；SCA是一个组装车间，ESB是一个中介机构；SCA简单而清晰，ESB复杂而模糊，不同产品特性千差万别。
ESB分布式的基础–传输层、远程通讯
ESB作为SOA的基础产品，它的第一个目标就是服务的分布化。提到服务分布，那么必然会想到传输、远程通讯、TCP/IP、SOAP等等概念。
不久前看到朋友的一篇文章Java远程通讯可选技术及原理, 读完之后，感觉有些概念定义的还不是很清楚。再者最近又准备升级ESB产品，因此就一些想法写出来，和朋友们交流。
归类正名
古人有黑马和白马的逻辑辩论，其目的就是正名。只有把概念定义清楚了，外延画定了，我们在讨论问题的时候，才能避免大象和犀牛一起比较的情况。下面我就平时遇到的一些东西进行简单了归类和定义。
- 四层协议：网络通讯的一种模型。参考TCP/IP协议分析-协议分层一文。
- 传输协议：四层模型中的第三层–传输层，主要指TCP、UDP。
- 应用协议：四层模型中的第四层–应用层，基于TCP/UDP，面向应用开发的高层协议。例如：HTTP、FTP等。
- ESB的传输层：它是一个逻辑概念，相对于ESB体系结构来说，解决服务（或系统）交互的一层。可以直接利用第四层协议，例如：SMTP协议，FTP协议等；或者基于第三层、第四层协议定制的解决服务交互的协议，把一个系统的数据+指令传输到另一个系统（可以获取回执，也可以不获取回执），例如：SOAP+HTTP协议，RMI协议，Hessian协议，REST（HTTP + XML方式）的协议，XML+JMS协议；甚至与传输无关的一些交互方式，例如：File协议，内存协议等。
- 通讯框架：基于TCP、UDP等开发的面向应用协议的框架。这类框架往往为使用者提供了一套通讯解决方案，允许使用者，定制需要的业务协议。例如：MINA，Netty2 ，Cindy，Grizzly等。其它可参考：Java开源 网络服务器端组件一文。
- POJO服务框架：这类框架提供了一种通用调用模式，简化POJO类的服务化问题，它们也提供了很强的扩展机制，允许使用通讯框架、ESB传输层来进行扩展。例如：Spring Remote，JBoss Remote，EJB等。
四层协议的共性
通过分析，可以看到四层协议具有如下特点：
- 每一层的职责清晰，专著于本层的关键问题。例如：网络层，它处理路由选择等分组在网络中的活动，而不会关心：与传输媒介的物理接口细节等。
- 上层协议利用下层协议来处理更低级的数据传输问题。
- 都有连接相关的定义。
- 都有数据打包的定义。
- 都有marshallers/unmarshallers 上层数据的定义。
- 都提供了上层如何使用的方案，发送方，接收方（提供方）。
由此扩展到应用协议，我们会发现它们要解决的根本问题也都包含这几个方面。因此：通讯层的模式是相对稳定的。
ESB分布式层、JMS、POJO服务框架等分布式产品的一些共性
- 明确定义服务标示的概念。例如：ESB产品Mule对服务的定义：vm://hello.service,xfire:http://localhost:8888/hello.service。JBOSS Remote中服务的定义：rmi://localhost:8797/hello.service。
- 插件化的传输协议。例如：JBOSS Remote提供了，Socket ，RMI，HTTP等。
- 插件化的数据编码和解码。该层与传输相关，而与应用无关。例如：Http协议，有文本型编码，Multipart编码。
- 插件化的序列化解决体系，例如：Java对象可以用Hessian方式序列化，可以用XML方式序列化，可以用SOAP方式序列化，可以用Java二进制方式序列化，以Jason方式序列化，甚至自定义的方式序列化。这一层通常解决高级应用层的数据（可能包括指令）的序列化方案。
- 有选择的提供数据压缩，数据加密，数据签名等常用方案。
- 为POJO层（或者定义为：业务层）提供同步、异步等多种业务交互模式。
- 错误处理机制。
- 提供专有API，或者与IOC容器、EJB容器整合的解决方案。
- 服务定位机制，寻址机制。
ESB分布式层的一种选型
在我们的ESB产品中，分布式层解决了如下问题：
- 包含了“ESB分布式层、JMS、POJO服务框架等分布式产品的一些共性“一节中描述的特性。
- 一个服务，通过一个端口支持多种协议。例如：通过5200端口，我们提供Hessian协议，WS协议，REST协议，HTTP+XML业务协议的方式。而且可以依据需要进一步定制。
- 传输质量的解决，例如：数据重发，超时。
- 批量传输数据。
- 长连接提升性能。
- 软负载。
- 大数据传输。
- 可靠传输。
- 流量监控。
- 在通讯框架上，我们选择了MINA。原因：A：文档齐全 B：扩展性好 C：协议层定制方便 D：基于事件模型 E：有HTTP的扩展（AsyncWeb） F：稳定性也不错 H：公司内已经有使用先例 G：Apache在不断升级
【说明：】群集，远程类装载（JINI特性），服务器组等一些高级特性，由于在我们的SOA化过程中，并没有业务上的需求，因此没有考虑这方面的内容。此外，我们发现，可以通过其它一些简单的技术（软件 + 硬件 + 发布 + OSGI等）来简单获得这些复杂技术提供的基本特性，以满足我们业务的需求。
对于开发一款通用ESB产品和符合自己企业需要的ESB产品，其出发点是不同的，由此在分布式特性的选择上也必然不会相同，每种产品的特性选择，只要满足了自己的目标和需求即可。不过，有些共性的特性点，无论如何也跑不了的（当然，可以简化方案，例如传输层，可以只有RMI，或者JMS）。
在这儿，一个程序员需要学习的东西的目录
在软件开发过程中，难免会遇到遇到各种问题，随着时间的流逝，居然形成了一些文字化的东西和一些口传心授的东西—我们称呼曰“文档、标准”。随着人员的增多，并发项目也很多，这些东西，对我们产生的影响力也越来越大。新人来时，每每言传身教之后，都会有所遗漏。的确，在这儿，做一个好的程序员学的东西也真够多的，累！！何况，这些东西还在不断增加中，苦！！
最容易出现问题的技术点、业务点的说明。时刻牢记之，否则就会出问题。
项目管理流程文档。没有标准的一个玩意，玩法多样。
<<需求分析模板>>文档。
<<系统分析模板>>文档。尽可能的全面，结果反而导致无从下手。<<架构分析模板>>文档。
<<软件设计模板>>文档
程序开发过程中，要严格按照相关业务准则执行，当程序准则违背业务准则时，以业务准则为主。
《产品编码风格》文档。
《产品技术体系结构》文档。
《WEB层开发规范和指导手册》文档。
《数据存储规范和指导手册》文档。
《服务层指导手册》文档。
《领域层指导手册》文档。
《业务逻辑层指导手册》文档。
《服务化业务指导手册》文档。
《软件配置指导手册》文档。
《分布式服务使用规范》文档。
《内部编码约定》文档。
《对象XML序列化规范》文档。
《数字、时间使用规范》文档。
《权限定义、使用、管理指导手册》文档。
《日志编写指导手册》文档。
《常量、枚举、国际化指导手册》文档。
《安全编码指导目录》文档。
《批量任务指导手册》文档。
《应用系统健康检查指导手册》文档。
《数据库开发和使用规范》文档。
《代码Review指导目录》文档。
《单元测试指导手册》文档。
《系统回归测试指导手册》文档。
《系统集成测试指导手册》文档。
<<项目发布计划模板>>文档。
《源代码使用和管理规范》文档。
涉及到各个业务层面的规则文档。
