宏观设计Web services

服务导向架构 (SOA) 是透过业务服务的概念来提供 IT 的各项基本应用功能，以此拉近业务和 IT 之间的距离。因为传统上，IT 的思维多偏应用导向（没什么不对）。ERP、CRM、SCM、...，专有名词缩写多到目不暇给。在试图为一个个应用空间提供解决方案的同时，也累积造就了一个个的信息壁垒，也就是所谓的silos。

服务导向架构的产生，正是着眼于将这些纵向信息堡垒加以横向贯穿，让它们各自提供若干对企业整体有价值的应用服务，让这些服务可以自由的被排列组合、融会贯通，以便在未来能随时弹性配合新的需求而调整。

我们同时谈到，Web services协助跨越系统间的鸿沟，扮演了SOA的催化剂角色；反过来看，要成功导入 Web services，进而获致成效，那么整个IT架构必须有通盘、全面性的规划，以SOA为大方向和指导原则，将它定位在接下来三至五年规划蓝图的核心。

其实算一算，Web services的风潮也已喊了有两、三年了。但感觉上，尤其在国内，至今仍难免给人雷声大、雨点小的印象。事实上，许多读者可能已经观察到一个pattern：热门新科技的问世，随着市场上的炒作，往往才刚开始便一炮冲天，high 到最高点；如果把它的热度发展用曲线来描绘，像极了一座陡峭的山峰，一过顶点便大幅下滑，坠入谷底--因为已被谈腻，大家也没兴趣听了。

这个大起大落、如洗三温暖般的发展过程被称作是「炒作曲线」(Hype Curve)。 Web services是如此；几年前的 Java、两年前鼎沸的3G、还有去年被大书特书的纳米科技，何尝不都是如此？随着炒作曲线发展的同时，真正具有潜力的科技，会逐渐受到愈来愈多青睐，导入的比例随着时间逐渐攀升，就像一条比较平缓却务实的曲线，由地平线逐渐升起，有如高原状般。这条被称作叫「导入曲线」(Adoption Curve)，与炒作曲线形成强烈对比。

回顾J2EE的发展，历经过去几年的洗礼，可说早已渡过炒作曲线跌至谷底深渊的危机，开始进入导入曲线的后段高点，成为新一代最主流的中间件（middleware）运算平台（我们将在稍后一期的专栏中将探讨应用平台，包括 J2EE 和 .NET 与 SOA 的关系）。从西方大企业近两年导入Web services的盛况（如BEA、微软、IBM等主要的Web services厂商皆不乏成功案例），加上国内近年来的发展（如电子化政府共通平台），以及各科技厂商在研发上持续的支持和投资来观察，Web services后续看起来也有很强的支撑力度。

其实Web services所招致的误解和片面了解的程度也不小。这一部分要归咎于它的名称取得也实在是有点不太明确，也不响亮。很多人的直觉反应可能会是：「提供网站服务的，像 Web server提供网页这类HTTP服务，就是 Web services啊」。另外，有的工程师朋友们可能看得比较底层，会认为Web services/SOAP只不过是种「透过 XML 封装、较为冗长，执行效能较差的沟通模式」。

这样的叙述，虽然从纯技术的角度而言基本上正确，但却也容易导致见树不见林的遗憾。我们说 Web services要能担负企业级、关键性应用，在实作和设计上必先把握几个关键原则，包括松散藕合 (loose coupling) 和正确的颗粒大小 (granularity)。

先前提到，Web services提供的是异质系统间的沟通接口，这个接口越中立越好，而且必须由双方共同配合遵守，以避免因为单方面系统、程序内部的调整而冲击到双方的沟通。中立的接口同时有助于提升再利用率--因为设计时将完全不预设未来可能呼叫此一接口的系统或使用者。

此外，由于Web services是用来提供相当于业务服务的功能，因此在设计上便应将所传递的XML数据内容，朝向设计成为一种在业务上有意义的单元。换句话说，颗粒必须要够粗，层级必须要够高（高到business层级），这和过去在设计函式呼叫、小颗粒的作法，在概念和目标上便有所分别。

至于什么时候适用 Web services，以及沟通接口的长相及颗粒大小等设计课题，也将逐渐成为一个专门的学问。我们可以归纳一个简单的原则：如果是跨机关企业、跨应用系统，或跨程序语言间的交流，那么便该优先考虑Web services；但如果是某一个系统、或某一种语言内部的沟通，它就不见得是最好的候选人了。只有使用得当，Web services才能真正发挥它潜在的价值。如果只是「为Web services而Web services」，那可有苦头吃的。

（文/萧百龄）

查看本文来源