Tapestry for Nonbelievers
I. Drobiazko和R. Zubairov合作撰写了一篇文章,详细介绍Apache Tapestry 版本5——一个面向组件web框架。文章向读者展示了创建组件方法,并谈到了Tapestry中的IoC以及Ajax的相关特性。
作者 Jean-Jacques Dubray译者 胡键 发布于 2008年5月11日 上午3时9分
去年,Olaf Zimmermann及其IBM研究院同事开发了一个能促进企业应用开发的架构决策框架。
在实践过程中,捕获架构决策对架构师来说依旧是一个挑战。已知的决策捕获抑制剂包括:项目发起人没兴趣、缺少时间和工具支持不足
他们提出了针对3个决策捕获步骤的概念框架:
- 决策识别 —— 现实:决策识别仅仅基于个人经验,而且[常常是]临时性的。
- 决策制定 —— 现实:决策制定者常常带有个人偏见……他们依赖于过去的经验……[或]……行业趋势。
- 决策执行 —— 现实:训练、架构模板和代码互审是主要的决策执行方法。
通过给决策建模提供一个结构、积极主动的方法,他们意在:
通过决策依赖模型、决策驱动者目录和推荐的决策制定技术来改善决策制定质量
几周前,Cesare Pautasso、Olaf Zimmermann和Frank Leymann在WWW 2008会议(在北京举行)上发表了一篇论文,详细比较了“RESTful Web服务和大型Web服务(Big Web Service)”,对“制定正确架构决策”进行了深入探讨。
首先,作者详细地回顾了每种技术公认的优缺点:集成企业应用可以使用多种不同风格。这个选择……是一个重要架构决策。“大型”Web服务技术栈(SOAP、WSDL、WS-Addressing、WS-ReliableMessaging、WSSecurity等)提供了远程过程调用(RPC)和消息集成风格的互操作性。最近,另一种解决方案被提出来实现跨互联网的远程过程调用:所谓的RESTful Web服务。
分布式系统中关键的架构决策,如选择集成风格和技术,应该以每个备选方案的技术论据和具体交付能力的公平比较为基础。而WS-* 与REST之争已经不幸地退化成了偏见和信仰的争论,这只能导致混乱和无法履行的期望。
在这篇论文中,[作者]在架构原则和决策的基础上,采用了量化方法来比较这两种集成风格。
除了它们公认的复杂性,SOAP消息格式和WSDL接口定义语言作为能在异构中间件系统中提供互操作性的网关技术得到了广泛使用。
自相矛盾的是,这种由当今WS-*工具所提供的将已有软件组件方便地转化为Web服务的能力也会被滥用。这样,避免跨抽象级别的信息泄露就变得很重要。例如,在服务接口中出现服务实现的本地数据类型和语言结构就会引发互操作性问题。这个缺点可通过表述和强制某种设计和编码指南(如契约优先的开发)得到缓解。
RESTful Web服务的简单性是公认的,因为REST利用了现有众所周知的W3C/IETF标准(HTTP、XML、URI、MIME),这种必须的基础设施已经深入人心……
这种轻量级的基础设施,使用极少的工具就能开发其中的服务,获取成本低廉且采用门槛很低。
[但是],关于公认的RESTful Web构建最佳实践存在一些混淆。高端REST(Hi-REST)推荐已被制定,但是它们并不总被所谓的低端REST(Lo-REST)实现遵守……[在实践中]只有2个动词(幂等请求使用GET,其他则使用POST)被使用……[因为]代理和防火墙可能不总是允许建立使用其他动词的HTTP连接……限制导致了一系列的替代方法(workaround),其中“真正的”动词要么使用一个特殊的HTTP头(X-HTTP-Method-Override)发送,要么就——如Ruby on Rails——用一个隐藏框(——method)提交……
接下来,他们基于架构决策框架确定了一个比较方法。他们使用字面含义识别候选决策和替代决策。在使用EST和WS-*时,他们开发了几个记录架构决策的集成场景。他们为每种集成风格创建了一个决策模型,这使得他们能使用一些数据(如决策数量、每个决策的备选数量……)来客观的比较这两个模型。
作者接着继续比较了原则、概念和技术。他们的发现包括:
在原则层次,两种方法有相似的量化特征。
在概念层次,在为WS-* Web服务决策时,必须制定的架构决策更少,而备选方案更多。
在技术层次,必须制定的决策数目相同,但是在构建RESTful Web服务时必须要考虑的备选方案更少。
特别地,作者说明:
这样,就从量化的观点认识了REST公认的简单性。
[但是],据我们的经验,对于RESTful服务非常容易做出的决策会导致显著的开发努力和技术风险,如设计严格的资源规范和它们的URI寻址模式。
作者总结说:
……灵活地使用RESTful服务,特别是跨互联网的集成(以Mashup的方式),对于生命跨度更长和具有高级QoS需求的专业企业应用,优先使用WS-* Web服务。
查看英文原文:A Fair Comparison of REST and WS-* using an Architectural Decision Framework: is the Debate Over?
I. Drobiazko和R. Zubairov合作撰写了一篇文章,详细介绍Apache Tapestry 版本5——一个面向组件web框架。文章向读者展示了创建组件方法,并谈到了Tapestry中的IoC以及Ajax的相关特性。
在本文中,Adrien Louis讨论了两种基于ESB的SOA拓扑方案的优缺点:单个公司级ESB vs. 彼此互联的“部门级”ESB系统。Adrien讨论了每种方案对管理、业务监测、治理、可靠性和编配等问题的影响。
InfoQ中文站有幸与IBM中国开发中心Web 2.0首席架构师毛新生聊了聊Project Zero和软件新发展的相关话题,其中包括Project Zero的组织形式、支持的语言、以及未来发展方向等等。
在某个软件产品设计的初始阶段,Segundo Velasquez曾以客户的身份与一个敏捷团队共同工作;Deborah Hartmann就这段经历对他进行了采访。
本视频从互联网的分类讲起,介绍了开放平台的类型、开放的价值以及开放平台对开发者的机会和挑战。然后以雅虎的NCP开放平台为例,讲解了NCP的特点、基本架构和具体的开发过程。
1 条回复
回复