架构面向服务的技术
jopen
13年前
<div id="news_body"> <p> 在其新作<a href="/misc/goto?guid=4959499741059382380">《架构面向服务的技术》</a>中，Philip Wik 总结了使用面向服务的技术搭建解决方案的三大阻力：</p> <blockquote> <ul> <li>复杂性<p>如何在恰当的细节和抽象层次上为复杂的事物建模？</p> </li> <li>沟通——设计元素<p>服务技术架构（Service Technology Architecture，后简称 STA）的基础元件是什么？</p> </li> <li>执行——为成功而做调整<p>如何提升 STA 解决方案的速度和质量？</p> </li> </ul> </blockquote> <p> 在 Wik 看来，最重要的事情是，要记住在处理实际问题时:</p> <blockquote> ……我们必须承认，有些问题是不需要答案的，我们也无法弄清出所有事物的本质，因为思维和符号是有限的……我们必须面对高深莫测的未知。但是，我们只能在这迷一般的世界里行动，不过我们有框架的帮助。框架是蓝图，它指引我们想象、计划、开发、测试、部署并稳固我们的架构。 </blockquote> <p> Wik 认为，面向服务技术解决方案的两个最重要的框架是<a href="/misc/goto?guid=4959499741135463143">开放组织服务集成成熟度模型（OSIMM）</a>和<a href="/misc/goto?guid=4959499741225668553">开放组织架构框架（TOGAF）</a>。</p> <p> OSIMM 之所以重要，是因为它一个用于创建增量 SOA 实施路线图的流程，而且它清晰地定义了每个阶段的业务收益。此外，它还包含一个用来评估当前及未来的 SOA 成熟度的量化模型。至于 TOGAF ，其企业架构框架有助于回答下列问题：如何构建可达成业务目标的系统？</p> <p> 接着，Wik 介绍了 STA 设计的两个基本元素——原则和模式。他说：</p> <blockquote> 原则是强制性标准……他们来自于常识及人们的共识。原则又是一个先验命题，可能合理但却无法证实……即便我们未能符合某个原则，或者我们忽略了它，它一样在那里。 </blockquote> <p> 谈及指导 STA 的主要原则时，Wik 搬出了著名的<a href="/misc/goto?guid=4959499741425915859">《SOA 设计原则》</a>，其中包括服务松耦合、标准化服务契约、服务自治、服务无状态化以及服务可组合性等。Wik 提醒，在使用这些原则时：</p> <blockquote> 若基于这些原则的具体应用去搭建架构，而忽视了原则本身，这样的做法是不对的。因为，它会走向追逐技术和锁定技术的境地，而非向业务目标前进。 </blockquote> <p> 谈到设计模式时，Wik 再一次力荐广为接受的<a href="/misc/goto?guid=4959499741425915859">《SOA 设计原则》</a>。</p> <p> 最后，在谈到为成功而做调整时，Wik 建议使用敏捷开发的每天的 scrum 改进责任划分和沟通；通过 XP 的结对编程改进质量和速度。他断言这些都是根本要素，因为它们支撑着那些引领 STA 走向成功的高层原则，如透明性、沟通、质量和速度等。</p> <p> Wik 在文章末尾说道：</p> <blockquote> 面向服务的技术的根本是，简化系统以符合企业目标；简化流程以实现目标。我们不反对人们花精力去掌握那些有助于实施 STA 的工具，但是，为了实现目标，可能需要我们放弃一些旧工具。TOGAF、UML 和敏捷/XP 是很好的工具，然而有时候我们需要扔掉这些工具才能正确地看待这满世界的服务。 </blockquote> <p> 尽管本文不乏许多有趣的观点，但是有些想法却令人迷惑。首先，Wik 为何弃用“SOA”而采用“SOT”就未交代清楚。而 SOT 这一词汇通常指那些诸如 Web Services 或 SCA 之类的东西，即能够简化 SOA 实施的技术，可是 Wik 把它与 SOA 混用。事实上，本文中的大多数引用、原则和模式都借用自 SOA。再者，文中很大篇幅在关注业务目标和业务驱动力。从前，技术的主要驱动力不是它们，而是实现的简单性。</p> <p> 另一个问题来自本文的标题，我们通常无法架构技术，而是使用技术。所以，对技术的架构的含义也不是一下子就能理解的。</p> <p> 最后，尽管诸如敏捷、XP 和社交工程在软件开发中都非常重要，这些东西如何直接应用于架构也不是那么显而易见。尽管有无数的出版物讨论这一话题，但这仍然没有定论。</p> <p> 此文在英文站一经发布，即引来了众多读者的回应，现摘录几篇评论以飨各位：</p> <p> 读者 Roopesh Shenoy 说到：</p> <blockquote> <p>在我看来，这听起来像是把简单问题复杂化，可是根本不需要这么复杂。我一直认为，架构师使用 OSIMM、TOGAF 或其他框架就如同开发经理们执着于使用成熟的技术（如 java）一样——没有人会因为使用这样的技术而被解雇。其实，我们可以从优秀的实践中学到更好的东西，比如 Amazon 的整个 AWS 基础设施。</p> </blockquote> <p> 读者 Konstantin Ignatyev 说到:</p> <blockquote> 本文再次对 IT 做了错误的假设： <p>指导原则：“正确地做事”</p> <p>目标：创新和质量</p> <p>优势：视野和纪律</p> <p>对于极少数 IT 人来说的确是这样的，但是对于大多数人来说并非这么回事。据统计，人们习惯于安于“现状”——现状会使他们感到舒服。IT 比业务更抵制创新的原因也是如此。所以，使用 TOGAF 或其他框架的目的不仅是创造一份安定的工作，而且其真正意图是让 IT 变成一个受人尊敬的职业（如医生和建筑师），有一组原则可教化从业者，使他们忠于工作，使业务人员不再因为要求走捷径和其他傻事而自毁前程。</p> </blockquote> <p> 本新闻编辑 Boris Lublinsky 认为 IT 是令人尊敬的工作，他回复到：</p> <blockquote> 暂不论我是否赞同本文作者 Wik 的话，但是我认为 IT 是值得尊敬的职业，所以我现在我已经干了 25 年了。而且，我也相信使用合适的框架的确是件好事。 IT 业中令人痛苦的一件事情是，“我比别人更懂”的态度往往导致人们一次又一次地打着“新技术”和“新方法”的旗号重复着 20 年前曾经犯过的错误。 </blockquote> <p> Konstantin Ignatyev 这么回复 Boris Lublinsky：</p> <blockquote> 只有当以下现象成立时，我才认为 IT 是一个令人尊敬的行业： <p>1. 不再出现《傻瓜式 HTML》或《24小时速成c++》之类的书籍时。你见过《24小时速成外科医生》和《一星期成为摩天大楼设计师》之类的书吗？</p> <p>2. 客户会日常地地要求底层实现和架构应该做成什么样。</p> <p>3. IT 能够为“近乎标准”的应用程序设定可预见的时间表；不再花几个月的时间完成只需数周就能完成的项目。</p> </blockquote> <p> Roopesh Shenoy 发表了他对 Konstantin Ignatyev 的不同看法：</p> <blockquote> <p>我有点儿不太同意你的看法：</p> <p>《傻瓜式 HTML》类似于介绍消化系统和呼吸系统的解剖方面的少儿书。它指引孩子们在成长为医生的路上迈出第一步，同理，这样的书能带领新手们走出变成 IT 专家的第一步。</p> <p>我不太理解你第二句话的含义，但是我猜测你所说的是客户干预太多。可这几乎是每个行业都要面临的问题。</p> <p>大多数有价值的项目都是非标准的应用。项目的开销和价值本就不成比例，而且是复杂且难以预测的。</p> <p>我的确同意，即便是小项目，它走向失败也可能是正常的而不是意外，但这并不意味着每个与之相关的人都有错——巨大的需求导致有新人不断地加入，不断地学习。如果有东西能够证明变得优秀不是那么容易的事，那也就意味着这是一个值得尊敬的职业。</p> <p>当然，成为开发者并不需要像医生那样需要多年的医学院学习和住院医的过程。但这也不是生死相关的行业，不是么？</p> </blockquote> <hr /> <p> <strong>查看英文原文：</strong><a href="/misc/goto?guid=4959499741518134129">Architecting Service-oriented Technologies</a><br /> 来自: <a id="link_source2" href="/misc/goto?guid=4959499741597957740" target="_blank">InfoQ</a></p> </div>