出家如初，成佛有余

    eSales这样的业务运营、支撑系统由于大部分内容都是动态的且由于并发用户数相对较少、压力也相对较低，在设计合理的情况下，性能并不是最大的瓶颈，因此此种情况下采用动态页面的方式是比较恰当。对于门户社区而言，高并发、高负载、高性能、高可用性是第一位的，需要采用各种手段来提高其性能。关于网站优化最好的方法论是Yahoo 的Best Practices for Speeding Up Your Web Site ，技术层面细节的优化策略参看Yahoo的方法论。

    同时这是一个用户为中心(user centered)的年代，诸如“以用户为中心的设计”、“以用户为中心的系统”、“用户为中心的营销”等等。 但是怎样才能够让门户设计中充分考虑用户体验，避免致命性的坏体验（bad smell）？这是门户建设需要重点考虑的问题，这一点上所谓的交互设计模式对于我们还是有所益处的。关于用户交互设计的模式：Yahoo Design Pattern Library 和Interaction Design Pattern Library

    此处重点从技术层面谈一下在门户开发时候需要考虑的重点内容：

    Web2.0化：除了充分使用诸如TAG、RSS、DIGG、SNS、UGC这些典型的Web2.0的元素外，“用户体验”是门户建设的重中之重，以用户体验为中心，把这些web2.0元素恰当地融入无线增值业务门户中，相信我们才会造就一个伟大的无线互联网门户，否则只是一堆与别人雷同的舶来品。

    无线门户、互联网门户一体化：WAP门户及互联网门户采用同样的技术架构，在整个系统的基础架构仍然沿用目前的Struts2+Spring+Hibernate（ibatis）的架构，但在View层不使用JSP，而是采用Freemarker，充分利用Freemarker对模板支持及对xml较好支持，将对WML(WAP1.0)、XHTML（WAP2.0）、HTML（Internet）的处理都统一到同一架构下。

    REST（Representational State Transfer）：遵循REST设计原则，尤其是无状态通信（statelessness）。

    页面静态化：对门户社区页面都尽量采用页面静态化方案，这样能够充分利用cache机制及实现replication、load balance及镜像（例如南北电信部署）。为了实现页面静态化策略，采用Freemarker+FMPP方案来实现页面静态化的策略。

    SEO：在设计时候一定要首先重点考虑搜索引擎友好及针对google、baidu搜索引擎进行优化，主要是Meta Tag部分内容及网站架构，所有的页面url遵循RSET模式，对无法遵循REST模式的，采用lighhttpd的mod_rewrite来实现。

    爬虫：简单的垂直爬虫主要采用httpclient+htmlparser方案实现，复杂爬虫策略采用Heritrix(或Nutch)实现。

    搜索引擎：采用Nutch+Lucene+Compass方案，对门户定时索引，提供全站搜索功能。

    AJAX：在eSales后台的ajax主要采用struts2的dojo实现，可以充分利用struts2的标签，保持架构的统一。在门户实现时候，由于主要采用静态页面化方案，对于需要动态内容的地方，采用ajax来实现动态数据的状态。在ajax库选择上，不再采用dojo，采用jquery方案。

    CSS：在eSales后台主要还是采用frame、table方式来实现页面布局，在门户开发时候完全采用CSS方案，以保证页面布局的灵活性及页面大小。

    Cache：尽量使用诸如memcache和squid的cache机制，提高性能

     镜像：采用rsync来实现对静态页面内容的镜像及同步，解决因不同运营商（移动（铁通）、电信、联通（网通）、教育网、有线网）及地域用户访问速度上差异。

    其他的部署策略参看下图：

参考资料：

• 性能方面：

http://developer.yahoo.com/performance/rules.html

http://highscalability.com/

High Performance Web Sites

Building Scalable Web Sites

http://www.sitepoint.com/print/web-site-optimization-steps

• 用户体验方面

http://www.welie.com/patterns/index.php

http://developer.yahoo.com/ypatterns/atoz.php

http://en.wikipedia.org/wiki/Interaction_design_pattern

http://www.visi.com/~snowfall/InteractionPatterns.html

    随着公司业务的快速开拓，数据库数据量极速增长，一些关键数据表的数据没有备份归档策略，在统计分析策略上也没有进行相应的优化，系统将会很不稳定，最终影响日常交易、运营业务运行，同时也对新业务的开展造成了严重制约（例如商家查询和报表）。特编写手软平台所有系统进行统计分析的基本设计规范，作为各新系统建设的建设。

    基本指导原则：

• 分离统计库（olap）和交易库（oltp）
• 建立相对完备的数据归档、预处理机制，定期将统计数据归档到统计分析中间表
• 统计分析数据从中间表读取，避免从oltp都实时统计查询

1. 目前系统主要的问题及经验教训

    性能问题主要来自于后台统计、结算等操作，这些sql的代价非常庞大，也是系统性能瓶颈所在。

    系统缺少老数据的归档机制，导致一些关键表的数据量一直在增长，导致日常查询操作压力较大，影响所有查询效率。

    系统统计分析和查询操作没有预处理机制，形成中间表或临时表，应用直接查询原始表，导致数据库压力过大。

    存在查询按钮重复点击，导致同一查询同时执行，很容易导致数据库负载达到峰值。

    查询页面需求不明确，存在一些不必要的信息，导致关联查询的复杂性。应用中存在无条件的查询语句。

    业务高负载时，集中在白天。这个时段的并发查询导致整体性能下降。

2. 新系统统计分析设计基本方法

基本方法：

• 数据归档

    对历史数据定时归档，降低在线表各表的数据量。历史数据不进行删除操作。

    用脚本定时完成统计分析数据或查询数据入临时表或中间表，降低查询的压力。

• 数据库优化和应用设计优化（数据库扁平化）

    对数据采用分库、分区、分表方式来处理大数据处理。

    对数据库设计优化。

    对应用系统优化。

3. 数据库分离基本方法

3.1. 数据归档原则

1) 目的：

    归档包括对交易数据的归档，也包括对历史数据的归档。

• 交易数据的归档：

    将业务表与历史数据设计成不同的表来存储数据。业务表中只保留正在处理的业务数据。业务表中保留一段时间后（视数据量和实际需求），系统定时进行归档或人工在界面操作进行归档，将业务数据转移至历史数据表。

• 历史数据的归档

    按照统计分析或大数据量查询要求，通过定时脚本对历史数据进行归档处理以降低统计查询的数据量。

    典型场景：对历史数据，按照日报表、周报表、月报表、年报表要求进行定时处理，形成中间数据表，前台查询时候直接从中间数据表中查询数据。

2) 原因：

    对于历史交易数据如果仍然存在在交易表中不进行清理操作，随着交易数据量的增长，将影响系统业务处理性能。

3) 备注：

    归档策略依赖于统计分析、定时脚本、查询等需求。

    存放时间：电信系统一般保存6个月数据。

    历史数据归档查询：

3.2. 数据分库原则

1) 目的：

    数据库分库原则分离交易库和分析库。

2) 原因：

    OLTP系统管理当前数据，侧重于事务和查询处理，在设计上遵循E-R模型。

    OLAP系统管理大量历史数据,提供汇总和聚集机制.，用于数据统计分析和挖掘，在设计上采用星型或雪花模型和面向主题的数据库设计。

    目前系统并没有区分这两种系统，导致进行统计分析和大数据量查询时候对数据库资源有较大的占用。

3) OLAP与OLTP同步策略

    采用mysql的Master-Slave模式来实现。交易库为Master，统计库为Slave。除对统计报表相关的表进行操作外，对统计库（Slave库）的交易数据不进行任何insert、update、delete操作，需要更新相关数据，只能操作Master库。

3.3. 数据分区原则

目的：

    为了使用户的大量的数据在读写操作和查询中速度更快，利用数据库系统提供的对表和索引进行分区的技术，以改善大型应用系统的性能。

    使用分区的优点：

• 增强可用性：如果表的某个分区出现故障，表在其他分区的数据仍然可用；
• 维护方便：如果表的某个分区出现故障，需要修复数据，只修复该分区即可
• 均衡I/O：可以把不同的分区映射到磁盘以平衡I/O，改善整个系统性能；
• 改善查询性能：对分区对象的查询可以仅搜索自己关心的分区，提高检索速度。

3.4. 数据分表原则

目的：

    把若干个存储相同类型数据的表分成几个表分表存储，在提取数据的时候，不同的用户访问不同的表，互不冲突，减少锁表的几率。

可通过一个原始目标的ID或者名称通过一定的hash算法计算出数据存储表的表名，然后访问相应的表。

3.5. 统计分析处理原则

    写脚本自动生成统计分析结果，存入结果表中，提供查询。

3.6. 数据库操作日志拦截

目的：

    利用hibernate等的interceptor机制，拦截下数据库操作日志，以便于跟踪sql语句及性能调试。

    正常情况下，拦截操作日志为关闭状态。

3.7. 中间表、临时表、视图

目的

    利用中间表和临时表或视图机制，降低统计分析或查询过程中过大sql的操作，造成对数据库排序区过多占用，提高查询速度。

4. eSales系统核心统计策略

    通过Quartz来实现每日凌晨及每月1号凌晨业务量较小时候定时调度统计分析程序，汇总每日的销售明细等统计数据，形成“产品日销售统计”、“产品月销售统计”、“销售员日销售统计”、“销售员月销售统计”几个核心的统计中间表。

构建电信计费系统、保险系统、金融等交易系统之所以复杂，除了对诸如高性能、高可靠性、高可用性、高安全性、高扩展性的要求外，另外至关重要的原因是这些领域存在大量的业务规则，这些规则千差万别，甚至是相互冲突的（瞧瞧电信资费就知道有多么复杂）。在市场驱动的情况下，系统架构和模型必须对客户、竞争对手、合作伙伴和整个市场情况的各种变更及时响应，同时将这些变更产生的需求作为业务规则体现到系统中去。从业务的角度看，业务规则是一种原则，包含在特定活动或范围内关于指导、操作、实践或过程的行为规范；从信息系统的角度看，业务规则是一个定义或限制业务某些方面的声明。一个业务规则包含一组条件和在此条件下执行的操作，它们表示业务规则应用程序的一段业务逻辑。业务规则通常应该由业务分析人员和策略管理者开发和修改，但有些复杂的业务规则也可以由技术人员使用面向对象的技术语言或脚本来定制。业务规则的理论基础是:设置一个或多个条件，当满足这些条件时会触发一个或多个操作。

1、应用场景：

• 电信计费费率模型

一次批价：根据预处理提供的标准格式话单，结合费率表、号段表、区号表等计费资料对话单进行计费。费率表中记录的信息主要有：基本计费单元、基本通话费率、长途计费单元、长途通话费率、优惠时段起始时间、优惠时段终止时间、优惠时段费率等等。号段表记录了IMSI号、MSISDN号所对应的归属地，以此来判定用户的归属地，进而判定出用户是否漫游、是否拨打了异地手机而应收取长途费等等。区号表记录了各个长途区号，用以从用户所拨的对方号码中提取出长途区号供计费使用。

二次批价：在一次批价的基础上，根据用户入网所享受的各项优惠对话单进行重计费，以最终生成向用户收费的话单。用户所享受的各项优惠记录存在营业系统的用户资料中，因此二次批价必须结合营业资料进行。二次批价使是一个耗时耗资源的过程，一般在合帐前集中完成，为了提高速度，将二次批价中需要频繁用到的营业资料载入内存中。

• 信用卡积分规则

凭XX信用卡消费1元人民币，即可获得1分的消费积分，在汽车类商户每消费100元人民币积8分，在房地产类商户每消费100元人民币积6分。

兑奖规则：100分～300分：兑换150元礼品，300分～500分兑换300元礼品，500分以上兑换400元礼品。

2、规则引擎

规则引擎的设计目的是使得规则的创建和维护变得简单，方便和代价低。好的规则引擎应该将业务逻辑的定义从一个系统中分离出来，而不是在代码中固化。同时规则引擎也将系统开发或者集成过程中不同角色的工作耦合程度大大降低，使得业务逻辑开发人员和具体系统开发等人员的工作可以接近并行的进行。在参考文档中有业务规则引擎基础较为详细的描述。

3、规则引擎使用思考

基于drools+MVEL或ognl来构建核心的业务规则处理部分。

需要考虑解决的几个问题：

• 性能及压力测试。对于像企业应用问题还不大，但对于在线实时交易系统，尽管可以预先编译规则，但规则引擎是否会成为性能瓶颈。
• drools与db的结合、内存数据库（berkeleydb）的结合

Loading and managing rules dynamically from a database

• 与mule及SoA框架结合，用于做对外接口
• 规则引擎用于系统部署及内容分发

5、参考资料

http://java-source.net/open-source/rule-engines

http://www.manageability.org/blog/stuff/rule_engines/view

http://www.ibm.com/developerworks/cn/java/j-drools/index.html

http://java.ccidnet.com/art/3737/20060427/531321_1.html

http://www.onjava.com/pub/a/onjava/2005/08/03/drools.html

http://www.infoq.com/articles/Brasilian-Healthcare-System

Technorati 标签:
业务规则引擎,rule engine,电子商务,drools

Gigaspaces公司的大牛Nati Shalom及其同事Geva Perry 的关于在web2.0时代，java在高性能、大容量、高负荷的互联网应用领域所扮演的角色进行了较为理智和深入的思考，在TheServerSide和Artima上也引起了激烈的讨论。由于Nati Shalom及Geva Perry  ，都算得上Java的大牛，其所在公司Gigaspaces开发的产品GigaSpaces eXtreme Application Platform (XAP)也是基于Java的高性能平台，因此其观点算得上对Java在互联网时代的定位的反思，相比较而言国内的“我该学习Java还是学习.Net之类的讨论”层次明显得不一样。

讨论的一些相关内容：

Why most large-scale web sites not written in Java

Why most large-scale Web sites are not written in Java [Personal View]

Large-Scale Web Sites and Java

一些Web2.0应用杰出代表的系统架构

我比较赞同Geva Perry 在Large-Scale Web Sites and Java的观点：

my intuition is that the trend for Web apps that are coming from start-ups or large pure web players (as opposed to web apps from airlines, banks, etc.) is definitely towards the LAMP stack. However, Java will still remain strong for a while and  especially for Web apps that have to deal with more complex processes in the back-end.

对互联网企业的Web应用而言，强调的是开发、部署、维护的敏捷性，因此我觉得Web层的应用还是采用像RoR、Django、LAMP（CakePHP）的应用架构相对方便，另外在性能调优（例如Cache、页面静态化）方便，像LAMP这样的架构还是较为成熟；在诸如像电子支付这样关注事务完整性、在MVC业务层有复杂的业务逻辑处理（例如交易、结算）的互联网应用领域采用Java架构还是较为恰当的；当然像银行业务、电信系统、电子政务系统这样传统的企业应用领域（Workflow、ESB、Rule Engine、SoA、消息服务等）Java还是会占据较大的优势。

归根结底，采用什么样的语言及架构还是需要根据业务模式的需要来决定。

一些相关的文档,值得一读

http://fishtrain.com/2007/09/26/interview-with-gigaspaces

http://royal.pingdom.com/?p=95

http://royal.pingdom.com/?p=173

http://natishalom.typepad.com/nati_shaloms_blog/2007/10/why-most-scalab.html

http://natishalom.typepad.com/nati_shaloms_blog/2007/10/why-most-large-.html

http://gevaperry.typepad.com/main/2007/10/large-scale-web.html

Pownce的创始人之一兼主力开发人员leah culver（好像是一个女士，牛人）在slideshare上发布了一篇pownce lessons learned的文章，比较全面介绍了关于构建Pownce应用的各种经验，对于构建web2.0应用还是很有借鉴意义的。怎样“Do a lot with a little”是每一个创业者都必须随时考虑的问题。

另外一篇关于Pownce的文章也值得一读Interview with Leah Culver: The Making of Pownce

1、团队规模、产品开发周期

开发团队规模：只有一个web开发工程师（应该还有后台开发人员），呵呵，那就是leah culver。

开发周期：开发了4个月，pownce是自筹资金玩的，也面临初创性互联网公司短交付期的要求。只不过付出没有白费，现在应该有一堆投资商排队要投。

2、Lessons Learned

2.1、Think about technology choices

主要信息来自Interview with Leah Culver: The Making of Pownce

Web框架：基于django，我的最爱

文件存储：基于amazon的S3（Simple Storage Service）

Web IM：基于AIR（Adobe Integrated Runtime）

数据库：mysql

Caching：memcached

Load balancing:Perlbal

2.2、Do a lot with a little

Small Team：Multiple roles，Learn quickly，Dedicated

采用开源工具

充分利用自己的资源

2.3、Be kind to your database

使用memcached做caching；Caching at page and object / list level；Cached  static pages since launch

对非实时任务，使用队列（消息队列？）作为任务调度的机制。

限定返回的记录数量及数据分页。

采用恰当的索引

避免复杂查询

2.4、Expect Anything

数据备份、版本控制

系统监控

利用社区的力量-Keep in touch with your community.

  • Let users know what you’re working on
  • Respond to individual bug reporters
  • Inform users of bug fixes and new features
  • Be careful about asserting deadlines

同盟军及合作伙伴

持续优化

3、 参考资料

http://immike.net/blog/2007/07/06/interview-with-leah-culver-the-making-of-pownce/

http://phaedo.cx/archives/2007/07/02/pownce-django-powered/

每間公司都該聘一位駭客的３大理由

1、REST开发框架纵览

转自http://www.swm.com.cn/cn/pop/pop.jsp?InfoID=2158

REST的流行使得越来越多的框架开始支持REST，而历史的原因使得它们各自具有不同的特点。

随着SOA的兴盛，Web服务也开始驶入了加速发展的快车道。2000年Roy Thomas Fielding博士一纸论文更是宣告了第二代Web Service的到来，REST—表述性状态转移，为我们构建下一代高性能、高可伸缩性、简单性、可移植性、可靠性的Web程序提供了一个架构风格上的准则。Web是简单的，Web更是可编程的，REST利用简单的 HTTP、URI标准和XML语言构建起轻量级的Web服务，从而大幅度地提升了开发效率和程序性能。

由于REST设计哲学变得越来越流行，许多RESTful框架如雨后春笋般涌现出来。

Rails

Ruby on Rails是新兴的敏捷Web开发框架，在动态语言Ruby的支持下，Rails以新鲜的视角告诉我们Web开发是简单而快乐的。Rails对 RESTful Web Service的开发作了极大的封装和简化，这对开发人员来说是一个强大的工具。而且即将发布的Rails 2.0将全面基于REST。

Rails 将ActiveRecord Model抽象为资源，比如http://www.example.com/books就是一个books资源抽象，而URI就是该资源的地址和唯一标识符。对该资源的CRUD是利用标准HTTP协议中的GET、POST、PUT和DELETE方法，见表1。

对于Book这个Model我们只需在URL映射配置文件routes.rb中使用map.resources:books作资源声明，则Rails自动为我们将表1中的URL和HTTP动词与 Action做映射。而且，Rails提供的scaffold_resource这个简单的Generator，可以让我们使用一条简单的命令自动完成上述工作，而且会为我们自动生成页面视图。

HTTP动词中的GET和POST是我们常用的，但是PUT和DELETE方法却很少见。由于目前流行的Web浏览器大多不支持PUT和DELETE方法，所以Rails采用一个虚拟的:method参数来模拟HTTP中的GET、 POST、PUT、DELETE方法。从表1中我们可以看到，PUT和DELETE实际上都分别用POST和GET来作为提交方法。

事实上，当我们使用Rails 页面模板的辅助链接方法并设置:method参数时，Rails会自动为我们生成一个form提交，并加上一个名字为“_method”的hidden字段，“_method”字段的值根据模板辅助链接方法:method的值而分别被赋予PUT或DELETE。这样，Rails就弥补了Web浏览器不支持 PUT和DELETE的缺点，让Rails开发人员透明地使用RESTful Web Service API。

另外，Rails最新的SVN代码库里还增加了一个RESTful Web Service客户端的封装库：ActiveResource。ActiveResource模块是Rails的REST客户端，它对开发REST客户端 Web Service程序提供了简化。ActiveResource参考了Rails的ActiveRecord架构，甚至连API几乎都是照搬过来，这对于熟悉ActiveRecord的开发人员十分方便。使用ActiveResource时，我们只需让一个自定义的模型继承自 ActiveResource::Base类，并在该模型中设置好self.site属性作为你要访问的RESTful Web Service的URL，就可以像使用ActiveRecord一样通过find、create、save、destroy方法来执行针对该资源的 GET、CREATE、UPDATE和DELETE操作。

Rails对REST开发做出了最大的简化，Rails即将发布的2.0版本将全面基于REST。作为一个敏捷的Web开发框架，Rails一直在不断突破传统的Web开发模式、寻找Web开发领域的杀手级架构和框架，并在不断进步和发展中得到了大家的认可。

Axis2

Apache Axis2是传统的Java Web Service框架Axis的下一代版本。从最初的Apache Axis和Apache SOAP到目前的Axis2，经历了大量变革和发展。相对以前的版本，Axis2更灵活、更高效、更简单。作为Java端官方和传统Web Service框架，在REST与SOAP的硝烟弥漫、战火纷飞的状况下，Axis2尝试同时支持SOAP和REST，采用了WSDL2.0中将REST 与Web服务结合的工作成果。

同样的商业逻辑，Axis2同时提供WS-*风格的接口和REST风格的接口。除了支持WS-*规范外，Axis2已经可以配置作为REST容器来发送和接收RESTful Web Service请求和应答。这让Axis2的灵活性、易用性、安全性和可靠性等都得到大幅度地提升。

在Axis2里启用REST风格的Web服务十分简单，首先修改服务器端的axis2.xml配置文件，将enableREST参数的值设置为true。

然后在Axis2的客户端的使用中，初始化一个Options对象，填入我们要访问的服务URL、设置传输协议为HTTP、设置打开对REST支持等，然后将Options对象传递给一个Call对象，最后调用 call.invodeBlocking方法，并在该访问的参数里指定调用的服务方法即可。

Axis2会同时作为SOAP端点和REST端点，在服务端可以同时发布这两种风格的Web服务。在客户端，如果接收到的消息的contentType为text/xml,并且没有SOAP相关的Header的话，这个消息就会当作 RESTful消息来处理，否则当作SOAP消息来处理。

其他RESTful框架

除了Ruby on Rails和Axis2，还有一些框架也纷纷提供了对REST的支持。

Django是基于python语言的敏捷Web和Web服务开发框架，它的设计与Rails十分类似，只不过简化和封装稍少一些。

django -rest-interface是Google Code上的一个开源项目，它给Django的REST开发接口提供了简便的封装。最重要的是Collection类和XMLResponder类，在 urls.py文件里使用Collection定义资源集合以及使用XMLResponder定义responder，并在urlpatterns中将该资源集合映射到某一url，则该资源就以REST方式发布了Web服务，对该Web服务的实现细节如HTTP动词等都隐藏在Collection里。

Apache CXF提供了一套创建SOA服务的基础设施，利用Apache CXF可以轻松创建基于SOAP或REST的Web服务。CXF是基于两大著名开源项目Celtix和XFire发展起来的，它提供了对JAX-WS的全面支持，并且还支持Binding以及Transport。

Restlet是基于Java的另一个轻量但健全的RESTful框架，它的发展十分稳定，有一定的潜力。Restlet支持所有REST概念（资源、展示、连接器、组件等），支持阻塞和非阻塞(NIO)模式，支持logging （LogChainlet）、authentication（GuardChainlet）和cool URIs重写（RedirectRestlet）等。

另外Microsoft的Indigo/WCF平台最近也加入了REST的集成，这意味这Indigo中的WebService将不仅仅使用SOAP了。

而JSR 311: JAX-RS则定义了RESTful Web Service的Java API规范，该规范基于JDK5的元数据语法。

对比SOAP和WS-*规范，REST对于简化Web服务开发和消费的意义是重大的，许多大型网站已经开始提供REST服务，如Amazon、eBay、 Yahoo和Flickr。在关注CRUD场景的、面向数据的应用以及简单的、没有复杂安全要求的Web服务方面，使用REST是明智的，但是在需要事务、严密的安全性等高级应用方面，可能基于WS-*的方案会更胜任。

目前实现的最好、开发效率最高的REST框架就是Ruby on Rails了。RoR在即将发布的2.0版本也将全面基于REST，可见Rails的作者DHH对REST是多么看重。Axis2则是Java端老牌 Web服务方案，但是Axis2支持的东西太多太杂，用Axis2开发REST应用总觉得有点大材小用。Restlet则麻雀虽小，五脏俱全，轻量而简洁，还有完善的认证支持，很值得期待。JAX-RS作为RESTful Web Service的Java API规范，又是基于Annotation语法来提高开发效率，相信不久的将来会更好地支持REST。

表1. Rails的REST URL、HTTP动词与Action的对应

图1 Axis2架构

2、我的思考及选择

  对于RESt适合资源导向的网站，例如对于Flickr、Youtube这样的资源导向（resource-oriented）站点是较为适合的，而对于诸如paypal、易宝支付、支付宝这样交易导向（Transaction-oriented）的电子商务的网站还是采用典型的Web Service（SOAP或XML-RPC方式）较为适合。

  基于Java进行平台选择来说（尤其是对外提供接口时候），如果要选择一个相对具有扩展性、普适应的平台架构，可能选择基于mule这样对SoA有较好支持并且集成了REST、Web Service功能的框架较为恰当，如果只是作为一个library来提供对REST的支持， Apache CXF（XFire）、Gomba或Restlet还是值得选择的。

  而对于PHP或Python，基本上都有参考RoR思想的框架，这些框架本身借鉴了RoR的REST思想，因此天然就可以支持REST。PHP我选择CakePHP，Python我选择Django。

• Java

   Apache CXF（XFire）

   Restlet

   Gomba

   Apache Axis2

• PHP：

   cakephp

• Python：

   django

3、参考资料：

  Building Web Services the REST Way

  http://brainstorm.javaeye.com/blog/119963

  http://www.slideshare.net/ozten/rest-vs-soap-yawn

  面向资源与面向活动的 Web 服务

  Architectural Styles and the Design of Network-based Software Architectures