BT

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

收获面向服务

| 作者 Wil Leeuwis 关注 0 他的粉丝 ,译者 胡键 关注 0 他的粉丝 发布于 2009年9月9日. 估计阅读时间: 18 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

要想获得理想的结果,就值得常常进行回顾和自我反省:“我们学到了什么?”我们正处在红皇后(译注:红皇后是小说《Through the Looking-Glass, and What Alice Found There》中的一个人物,请参考维基百科中文资料1中文资料2。该小说是《爱丽丝漫游奇境》的续集。)所讲的年代,有效地进行学习,并且因此常常要花些时间来从过去的教训中吸取经验,这样做比以前按时获得优质结果显得更有必要,这是一种似是而非的隽语。今天的难题由来已久,而今天的答案是:服务。因此我会把矛头指向服务。

模型和系统

模型是日常现实的简化表述。系统是一类特殊的模型,现实世界或其一部分在其中被建模成元素和元素之间的关系。在系统中,我们可以定义子系统(共享某 些特性的元素子集)和方面系统(aspect system)(共享某些特性的关系子集)。此外,所有这些都是递归的:一个系统集合完全也可以是一个系统。创立于十九世纪40年代的系统论提供了大量的 理论基础,随时可帮助21世纪的问题分析师和解决者在调查研究中去发现事情的本质[1],[2],[3]。

我们创建模型和系统的原因是为了更好地理解我们周围或者我们内部世界的某些方面或者局部。这种理解的获得是以领悟并理解我们所舍弃和抽取的部分和方 面为代价的。模型范围的选择要从我们的目标以及需要学习和交流的内容出发:制作模型是项有针对性的活动。数学模型有别于其他模型的重要一点就是:数学通过 定义公理来创造属于自己的世界。数学模型内的事物都是绝对清晰的,甚至在处理模糊逻辑时也是如此。在自然数的集合里,每个数字不是奇数就是偶数,不存在一 个偶数或多或少比另一个偶数更像偶数这样的情形。这和我们所熟知的世界差别太大了!

任何事物都是模糊的

在现实世界中,任何事物都在一定程度上是模糊的,而且如果不设法使其精确,你就不会意识到这一点。并且,事物的精确表述与我们平时想到的相距甚远,以至于在我们说出自己的想法时,你无法马上理解我们的真实意思[4]。

由于已经习惯于使用我们熟悉的数学抽象进行工作,我们常常会忘记这一点。并且,当我们忘记这一点的时候,我们会错误地把模型当成现实世界。数学太伟 大了。正是由于它,使得大量的现实世界问题得以解决。但是每一位热衷于使用数学对现实世界建模的工程师都知道,模型只是模型。由于现实事物都是模糊的,它 与模型之间存在偏差并不奇怪。正是由于模型的两面性让我的一位老师说出了这样的话“不要相信模型,但也不要忽视模型”。不要把模型误以为是现实世界,要意 识到那些模型忽略掉的事物:不要以后大惊小怪。总而言之:尽可能使用模型。它将帮助你来理解这个对凡人来说过于复杂的世界。

模型增加了复杂性?

模型一旦被描述出来后,它就成了这个世界的一部分。但是有点违反直觉和令人不悦的是:虽然制作模型的出发点是为了控制复杂度,但最终却得到了一个甚 至更复杂的世界。对于这个问题,有3点要说明。首先:它完全取决于你的观点。从全局观点来看,复杂性确实增加了。但是从局部看来,一个形式完好的模型肯定 能有助于控制复杂度。这正是“天下没有免费的午餐”规律的一个例子:局部获利是以全局损失为代价的,很多时候情况恰恰是这样。第二:为世界建模带来了二义 性。以汽车类实例化而得到的汽车对象来说,它当然不同于GM生产线上生产出的汽车。所以当现实世界和模型都在我们讨论范围内的时候,我们需要慎重地选择措 辞。第三:员工要为他们工作的公司负责,并且也要对整个社会负责:如果没有充分的理由,他们不应该增加复杂性。

服务

服务、面向服务、面向服务的架构。有旧、有新、有借、有蓝(译注:婚礼习俗。参见《有旧有新有借有蓝——百年婚礼习俗》)。 新瓶装旧酒还是真正的创新?在我看来这两种说法都对。在服务领域,只要我们能远离非此即彼的谬论,我们就会有很多收获。不要再试图去争辩它是CORBA再 世,或者说你早就拥有它,思路开阔些。因为有很多旧的、易理解的、可用于实践的理论能够帮助我们从服务世界的创新中汲取营养。仅仅出于文章的需要,让我们 构建一个模型来更加紧扣“服务”的概念。我们将在文章结尾推翻这个模型,这样对整体复杂性就不会带来任何损失。

我提议的这个模型包含四个组件:内存、处理器、二者间的连接以及执行器。内存代表了世界上所有内部和机器可读的内存,同样的规则也被适用于处理器和 连接,因此后者还包含诸如互联网之类的事物。为了简单起见,执行器代表了世界上所有能够直接跟内存交互(即他们可以直接读写内存)的机器和人。鉴于处理 器、连接器和内存的组合就是一台机器,因此这个模型能够用于描述递归流程。

探索模型

我把详细设计该模型的任务留给了读者。例如,你可能会在内存或者处理器上安置可执行程序,并附以用于描述执行过程的特定结果。但即使在这个描述的不 严格的模型中,有一点也很清楚:19世纪50年代汇编语言时代的子程序与久经考验的Cobol和2008年Web 2.0+时代的Web服务,它们被调用的方式完全一样。

什么正在发生?这个流程是什么?先是有选择地收集一些数据。接着会有一个发往该世界一个不同参与者的请求,被收集到的数据往往作为请求参数一并提 供。接下来是代码执行,可能是直接执行,也可能过一段时间之后执行,其执行结果又作为另一请求的一部分被发往这个世界的另一参与者,以此类推。在执行完成 后,可能会发送给请求者一条工作已完成的消息,并伴随有一些数据。

怎样?我的第一印象就是,你根本无法从中把服务指出来。从我们简单模型中的所有当前流程中,很难指出那个服务到底是什么。在很大程度上,我们所知道 的就是它的名字。余下的流程步骤是:调用、执行代码、改变存储在特定内存位置中的值、当特定内存位置中的值等于或者超过某个值时候采取行动,等等。我们是 否能推断:服务是客观实在的,通过给它命名,我们就让像“存在”这样的事物被抽象了出来?或者服务具有突发性,它是偶然发生的,因所有的活动都发生了而产 生?我认为玩味措辞没有太大的价值,因此毫无疑问,我想我们应该会对能够给一个服务命名而感到高兴。

自从分支到子程序时代以来,现在有什么已经被改变了?通过达尔文我们知道了现实世界并不存在本质,但是IT系统和它们的数学模型联系得实在太紧密 了,以至于在某些限制下有必要问一句:当跟它们的遗留对应物进行比较时,当代应用中有什么本质区别使得服务概念有价值? 这个问题的答案很简单:复杂度。在汇编程序时代,交叉引用表是关于所有你所需服务的概览,记录了什么地点什么人物使用它们。在2008年该对象的Web服 务版本中,你确实需要模型和系统来指导服务的开发和使用。在所有层面,服务都很复杂。如果你需要一些隐藏细节的有趣例子,那么可以去看看面向服务在实践中 使用的情况。让业务人员可以使用服务并使用这些服务来创建业务流程并不简单,这需要服务目录用业务语言表达服务的目标。在技术层面存在大量的复杂性,因为 要使所有不同平台和网络技术必须在一个服务环境下无缝的协作。在设计和构建层面,这些面向业务和面向技术的元素被编织在一起。一旦完成部署,还需满足服务 水平。并且在所有领域,同一世界中的所有这些都喜欢每天进行一些少量的改变。因此一成不变并不好,服务必须随变化而构建。我甚至都没敢提信息安全!

如果服务是少数人的兴趣,那本文所说的就完全不切题了。事实上,正好相反。它们承诺带来机动性,故此赢得了业务人员的喜欢!

因此,为了行动迅速,我们需要站在巨人的肩膀上。耦合和内聚的概念、结构化分析和设计、封装、模式的使用,全都在那儿供我们差遣[5]、[6]、[7]。

关键词

和面向服务关联使用的词有:架构、成熟度模型、路线图、治理。在这一领域是否已经完成了一些降低复杂度的工作?我认为是有的。

成熟度模型讲的是最佳实践。这就意味着它们的主要内容是关于在特定条件下产生高质量结果的真实存在的流程。通过指引企业去关注那些重要性已被证明了 的流程领域,成熟度模型可以用于引导企业的执行水平更上一层楼。以这种方式使用的成熟度模型起到了路线图的作用:在旅途中,它引导你由此及彼。但是还有另 一种广为人知的路线图,它的目的地是未知的,从某种意义上来说,我们无法明确指出真的存在这样一个所谓的目的地。与之相反,目的地是一种可感知、值得期待 的位置。在这样的位置上,下一步要做的就是计划如何通过一系列中间步骤由当前位置通向天堂。这种迁移并没有任何错误,实际情况正相反。但是你不应该把最终 模型称为成熟度模型。要是这样做了,你就把成熟度模型的概念扩展到了一个使它无意义的程度。这种做法仅仅增加了全局复杂性,而没有消除局部复杂性。

面向服务是否是完全不同的事物?从某些角度看,确实如此。仅仅由于它的不同,就真的需要它自己的成熟度模型、治理等等吗?视情况而定。开发一个全面 的成熟度模型,涵盖整个面向服务领域,潜在范围从业务流程到XML和语义接口,不是件简单的事情。如有可能,我们应使用易于获得的元素去及时得到这样一个 打算使用的成熟度模型。像Photoshop和Eclipse这样差别巨大的应用程序也都采用了同样的机制:插件。尤其是在面向服务环境下,出于复用的目 的对现有模型进行评估是第一步。当采用插件视角时,许多像CMMI、ITIL和COBIT这样的模型都能够为面向服务的实现速度和业务成功做出贡献。

因而我要再次强调“保持简单”这句格言。不要增加模型,除非不这样做会导致恶果,坚持爱因斯坦的观点,尽量简单地表达每个事物,但又不是过于简单。 把握词汇的既定含义:成熟度模型讲的是最佳实践,路线图被用于以一种Rand McNally(译注:美国制图厂商,有百年历史,其所制之图极其详尽。)风格来了解目标,迁移计划是为了通往天堂。并且最后但并非不重要的是:复用,复用,复用。

最后一个关键词:ABC

有一个被称为ABC的臭名昭著三人组:学究(Academics)、企业(Business)和顾问(Consultants)。学究铸造新学说。 顾问用自己的语言把它们翻译成企业钟意的部件。而企业给顾问付费,并让学究有机会在组织内部四处闲逛收集新学说的基础素材。很明显,要在这个领域挣到钱, 你就不应该使用具有清晰含义的措辞。相反,你要采用“新瓶装旧酒”的策略。用营销的话来讲:你是唯一的。但效果却是相同的:大量的文字游戏,却没有完成多 少实事。像这样一个过程能否解释为什么我们看到有这么多的新模型,却很少主动让模型适应变化——或乃至适合使用——并让它们与时俱进?

结束语

记住,模型摒弃了你和你的目标并不关注的方面和部分。为理解顾问们的故事而创建的模型未必能解决你的问题。正如Mark Anthony Luhrmann所说“谨犯那些劝你买东西的人,但是对于给你忠告的人应有耐心。忠告是某种形式的怀旧,给出忠告就像从过去的废墟中寻宝一样,擦去表面的 污垢,美化其丑陋的部分,重新利用它让其物超所值。”

如果这个文章是一个服务,那请求可能就是:“我如何从面向服务中有所收获”,而返回的数据就是:“设法弄清楚哪些是新的。尽量掌握新的内容。不要忘记之前有很多像你这样或那样的人都或多或少的已经学习了这些。复用它。新部件要复杂些。复用并不简单。让这种力量与你同在。”

[1] Kenneth E. Boulding, 1956. General Systems Theory, The Skeleton of Science. In: Management Science, 2, 3 (Apr. 1956) pp.197-208; reprinted in General Systems, Yearbook of the Society for General Systems Research, vol. 1, 1956.

[2] W. Ross Ashby, 1956. An Introduction to Cybernetics, London, Chapman & Hall.

[3] Ludwig von Bertalanffy, 1968. General System Theory: Foundations, Development, Applications, New York: George Braziller, revised edition 1976: ISBN-13: 978-0807604533.

[4] Bertrand Russell, 1918. Lecture: The Philosophy of Logical Atomism. Bertrand Russell, David Peers (ed.), 1985. The Philosophy of Logical Atomism, Open Court Classics. ISBN-13: 978-0875484433. Also available via the Amazon Online Reader.

[5] Edward Yourdon and Larry L. Constantine, 1979. Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design. Prentice Hall. ISBN-13: 978-0138544713 facsimile edition 1986.

[6] Glenford Myers, 1979. Reliable Software Through Composite Design. Van Nostrand Reinhold, ISBN-13: 978-0442256203.

[7] Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, a.k.a The Gang of Four, 1995. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. ISBN-13: 978-0201633610.

服务概念通常对企业和社会都很重要。它意味着迈向无约束信息流(Open Group的愿景)和Brewster Kahle的互联网档案馆所设想的随时访问所有人类知识的一大步。多么令人激动的两个愿景!

查看英文原文Harvesting Service Orientation


感谢马国耀对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个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