利用Ruby简化你的Java测试
本文是Productive Java with Ruby系列文章的第一篇,我将从单元测试这个话题开始,让Java的开发人员能够在实际工作中利用Ruby提高工作效率。
作者 Dilip Krishnan译者 徐涵 发布于 2008年6月19日 上午2时43分
在那场关于内聚对SOA是否重要的争论中,Carlos Perez表达了他关于软件构造中的耦合(coupling)及其在SOA领域的演变的观点。他首先给出了Bertrand Meyer的模块性原理(principles of modularity),然后将之延伸到自己的一套面向服务的原则上。Carlos首先引用了Bertrand Meyer的模块性原理的原文:
- 模块可分解性(Modular Decomposability)——如果一种软件构造方法能有助于把一个软件问题分解为若干较简单的子问题、并用一个简单的结构将这些子问题连接起来、而且能够独立地对各个子问题作进一步分解,那么该方法就满足模块可分解性。
- 模块可组合性(Modular Composability)——如果一种方法,由它生产出的软件元素,未来可在不同于最初被开发的环境中通过彼此自由组合的方式来产生新的系统,那么该方法就满足模块可组合性。
- 模块可理解性(Modular Understandability)——如果一种方法,由它生产出的软件,人类读者无需了解其他模块(或最多只需研究少许其他模块)便可理解每一个模块,那么该方法就有利于模块可理解性。
- 模块连续性(Modular Continuity)——如果一种方法,在由它得到的软件架构中,功能规格上的微小改动只会引起一个(或少量)模块的变化,那么该方法就满足模块连续性。
- 模块保护性(Modular Protection)——如果一种方法,在由它得到的架构中,一个模块在运行时出现异常条件不会影响到该模块之外(或最多只蔓延到少数周边模块),那么该方法就满足模块保护性。
接着,他考察并评论了该领域的各个思想领袖(如Thomas Erl、Don Box、Stefan Tilkov和David Orchard等)所表达的面向服务原则。
……Thomas Erl的原则是一组糟糕的原则,因为它们把关注点混搅起来了。
……David Orchard的原则体现了较好的平衡,当然我必须要质疑为何把WS-*也加进来。
然后,他根据自己的服务定义,概括了以下面向服务的原则,
- 可分解性(Decomposability)——如果一种方法能有助于把一个软件问题分解为若干较简单的子问题、并用一个简单的结构将这些子问题连接起来、而且能够独立地对各个子问题作进一步分解,那么该方法就满足可分解性。
- 可组合性(Composability)——如果一种方法,由它生产出的软件元素,未来可在不同于最初被开发的环境中通过彼此自由组合的方式来产生新的系统,那么该方法就满足可组合性。
- 可理解性(Understandability)——如果一种方法,由它生产出的软件,人类读者无需了解其他模块(或最多只需研究少许其他模块)便可理解每一个模块,那么该方法就有利于可理解性。
- 连续性(Continuity)——如果一种方法,在由它得到的软件架构中,功能规格上的微小改动只会引起一个(或少量)模块的变化,那么该方法就满足连续性。
- 保护性(Protection)——如果一种方法,在由它得到的架构中,一个模块在运行时出现异常条件不会影响到该模块之外(或最多只蔓延到少数周边模块),那么该方法就满足保护性。
- 自查性(Introspection)——如果一个方法,由它得到的架构提供了“允许在运行时查询并检查模块结构及模块间通信结构”的机制,那么该方法就满足自查性。
- 远程性(Remoteability)——如果一个方法,由它得到的架构提供了“允许托管于不同物理环境下的不同模块与之进行模块通信”的机制,那么该方法就满足远程性。
- 异步性(Asynchronicity)——如果一个方法,由它得到的架构不假定模块调用将被立即响应,那么该方法就满足异步性。换言之,它假定网络或被调用模块有延迟。
- 面向文档(Document Orientedness)——如果一个方法,在由它得到的架构中,内部模块间的通信消息均是明确定义且互相知道的、而且各次调用之间不存在隐式的状态共享,那么该方法就是面向文档的。
- 标准化的协议信封(Standardized Protocol Envelope)——如果一个方法,由它得到的架构要求所有模块通信都共用一种通用信封消息格式,那么该方法就满足标准协议信封。
- 分散式管理(Decentralized Administration)——如果一个方法,由它得到的架构不需要对所有模块进行集中管理,那么该方法就符合分散式管理。
最后他说“至于那个无所不包的‘松耦合’;只要你愿意,上述特性中的许多都可以得到!总之,SOA就只是松耦合的API。”
你觉得呢?Bertrand Meyer的软件质量原则有多少能用在面向服务领域?你一定得看看Carlos Perez的原文。
查看英文原文:Loose Coupling in SOA Defined本文是Productive Java with Ruby系列文章的第一篇,我将从单元测试这个话题开始,让Java的开发人员能够在实际工作中利用Ruby提高工作效率。
InfoQ中文站有幸与阿里软件的首席架构师赵进在一起探讨了SaaS的相关话题,包括SOA和ASP与SaaS的异同、云计算、SaaS的前景、它的关键技术、技术瓶颈等等。
在这篇文章中,Adrien Louis和Marc Dutoo在一个典型的ESB场景中讨论了编配和路由的区别和优缺点。他们讨论了几种连接服务的方法,从使用如自定义路由这样的低级别方法,到使用如工作流和编配这样面向业务的高级别方式,并总结说不存在“一边倒”的解决方案。
本文是根据7月26日InfoQ中文站在杭州举行的QClub活动(第三期)后半程小组讨论总结而成。主要内容包括如何在SOA系统中实现服务编排,如何保证分布式系统中的一致性和可用性,以及如何在实施SOA的过程中控制接口的粒度等。
人们很容易想当然的以为虚拟化技术仅仅应用于服务器。而在现实中,虚拟化这一苏醒的概念正被运用于各个层面,其中包括网络,存储以及应用基础架构。在这篇导论中,InfoQ将深入每个方面,详尽向您描述虚拟化技术的运用以及其优点与不足。
在这篇案例研究中,InfoQ对Adobe AIR和Amazon的简单存储服务(Simple Storage Service ,S3)在NASDAQ市场回放程序(NASDAQ Market Replay)中的应用进行了详细的分析。
没有回复
回复