BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

SOA设计关乎契约还是服务实现?

| 作者 Boris Lublinsky 关注 1 他的粉丝 ,译者 胡键 关注 0 他的粉丝 发布于 2010年2月12日. 估计阅读时间: 2 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

大量的出版物都在描述SOA实现的设计,但却对接口(契约)设计鲜有关注,这让人不由得产生一种“实现的设计更重要而且更值得关注”的感觉。对此的一个常见理由是契约会随着时间改变,预先把过多的时间花在它们的定义上跟敏捷开发方法相抵触。

Steve Jones在他最近的贴子里对这一普遍误解提出了异议,说道:

在我看来,这种看法就像那种不愿意写文档的伪敏捷人士,他们根本就是狗屁不通,而不是因为他们已经开发出了具备自描述能力的质量极高的组件。这基本上就是在说任何人都要等到系统可运行了之后你才能知道它的功能。这等于让需求改变适应实现。我现在并不是说需求不能改变,也不是鼓吹瀑布模型,而想说明SOA编程中的时间分配问题:在确定规格说明和设计过程中,大部分时间应该花在服务间的契约和交互上,至于关注如何设计这些服务满足契约,则可以少花些时间。

为什么契约是SOA实现中的最重要部分,Steve列举了以下原因:

  1. 其他组件依赖的是契约而不是设计。因其错误而导致的成本跟提供者的数量成指数关系。一旦契约正确就位,那么人们就可以并行开发,这可以大大加速交付时间,减少风险。
  2. 测试是围绕契约而不是设计进行的。契约是正式的规格说明,设计必须满足它,而且各种形式的测试也都应该使用它。
  3. 设计可以在契约的边界内悄悄地改变。

契约的重要性这一概念并不是新鲜事物。按照Dimuthu Leelarathne的说法:

如果你没有首先设计服务间的契约,服务间复杂的集成问题就会出现。

实际上,创建好的服务契约并不是件易事,要求很好地理解契约核心业务。虽然已有一些服务接口设计的公认方法,但是更多的时候它还是艺术而非科学。结果,开发者和软件厂商都典型地把注意力放在了他们受到的培训(和要卖的东西)上——服务实现的设计和编码。在Steve看来:

……IT的重点……太少地放在了确保外部接口至少在一段时间内保持正确的上面。契约可以演变,我有意地使用了这个术语,但大多数时候,旧的契约在人们迁移到新版本的过程中还要被支持。这意味着契约比设计拥有的生命跨度要长得多……契约是大事,设计则微不足道。

随着我们继续提倡将SOA用于业务/IT对齐,与业务需求对齐的服务契约的作用会越来越明显。

查看英文原文:SOA Design: Is it about Contracts or Service Implementation?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT