软件及服务的松耦合

软件的模块性:

  1. 模块可分解性(Modular Decomposability)——如果一种软件构造方法能有助于把一个软件问题分解为若干较简单的子问题、并用一个简单的结构将这些子问题连接起来、而且能够独立地对各个子问题作进一步分解,那么该方法就满足模块可分解性。
  2. 模块可组合性(Modular Composability)——如果一种方法,由它生产出的软件元素,未来可在不同于最初被开发的环境中通过彼此自由组合的方式来产生新的系统,那么该方法就满足模块可组合性。
  3. 模块可理解性(Modular Understandability)——如果一种方法,由它生产出的软件,人类读者无需了解其他模块(或最多只需研究少许其他模块)便可理解每一个模块,那么该方法就有利于模块可理解性。
  4. 模块连续性(Modular Continuity)——如果一种方法,在由它得到的软件架构中,功能规格上的微小改动只会引起一个(或少量)模块的变化,那么该方法就满足模块连续性。
  5. 模块保护性(Modular Protection)——如果一种方法,在由它得到的架构中,一个模块在运行时出现异常条件不会影响到该模块之外(或最多只蔓延到少数周边模块),那么该方法就满足模块保护性。

服务的模块性:

  1. 可分解性(Decomposability)——如果一种方法能有助于把一个软件问题分解为若干较简单的子问题、并用一个简单的结构将这些子问题连接起来、而且能够独立地对各个子问题作进一步分解,那么该方法就满足可分解性。
  2. 可组合性(Composability)——如果一种方法,由它生产出的软件元素,未来可在不同于最初被开发的环境中通过彼此自由组合的方式来产生新的系统,那么该方法就满足可组合性。
  3. 可理解性(Understandability)——如果一种方法,由它生产出的软件,人类读者无需了解其他模块(或最多只需研究少许其他模块)便可理解每一个模块,那么该方法就有利于可理解性。
  4. 连续性(Continuity)——如果一种方法,在由它得到的软件架构中,功能规格上的微小改动只会引起一个(或少量)模块的变化,那么该方法就满足连续性。
  5. 保护性(Protection)——如果一种方法,在由它得到的架构中,一个模块在运行时出现异常条件不会影响到该模块之外(或最多只蔓延到少数周边模块),那么该方法就满足保护性。
  6. 自查性(Introspection)——如果一个方法,由它得到的架构提供了“允许在运行时查询并检查模块结构及模块间通信结构”的机制,那么该方法就满足自查性。
  7. 远程性(Remoteability)——如果一个方法,由它得到的架构提供了“允许托管于不同物理环境下的不同模块与之进行模块通信”的机制,那么该方法就满足远程性。
  8. 异步性(Asynchronicity)——如果一个方法,由它得到的架构不假定模块调用将被立即响应,那么该方法就满足异步性。换言之,它假定网络或被调用模块有延迟。
  9. 面向文档(Document Orientedness)——如果一个方法,在由它得到的架构中,内部模块间的通信消息均是明确定义且互相知道的、而且各次调用之间不存在隐式的状态共享,那么该方法就是面向文档的。
  10. 标准化的协议信封(Standardized Protocol Envelope)——如果一个方法,由它得到的架构要求所有模块通信都共用一种通用信封消息格式,那么该方法就满足标准协议信封。
  11. 分散式管理(Decentralized Administration)——如果一个方法,由它得到的架构不需要对所有模块进行集中管理,那么该方法就符合分散式管理。

原文:

  1. SOA定义的松耦合
  2. Loose Coupling in SOA Defined
By javafuns on April 20, 2009 at 15:50 · Views: 352 · Permalink · RSS
Categorized in: Design Patterns, SOA · Tagged with: , ,
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading ... Loading ...

Leave a Reply


  • Highest Rated

  • My PicasaPhotos

    b4ece2733f512e0f8701b0f8.jpg

    IMG_0868.JPG

    image019.jpg

  • RSS My del.icio.us

  • My RSS