正因为 Web API 是一个开放参与的架构。如果没有它,我们对一个网站的功能和操作介面,便毫无选择和掌控的权利 -- 介面设计成什么样子,进阶搜寻有哪些条件选项,一切都操控在该网站的主事者手上;更甭提将数个网站的功能融合在一起,作创新的 mashup 应用了。举个更实际的例子,Amazon.com 创办人/CEO Jeff Bezos 在一年半前一场 Web 2.0 的演讲中提到,他们提供了 Web services 之后,让很多 Amazon 自己没时间做、较低优先的创新应用,能假他人之手,让网路上广大的程式设计者,根据自身的需要,一同来帮忙开发。
在众多的创新应用中,有一个得奖的应用叫 ScoutPal。这是某位网站开发人员,为了帮忙在网路上作旧书买卖的太太所写的。他用 Perl 语言,只花了一天的时间便完成了这个应用。搭配一个 bar code 扫描器,接上一个可无线上网的手机/PDA,便可以让她在四处寻访搜集旧书时(像是去跳蚤市场、旧书摊和私人庭院办的 garage sales),立即从 Amazon 的 Web services 中查询到一本书当下的行情。藉以和眼前的货主所愿意出的价相比,来决定是否值得把书买下来。
也就是说,提供一个开放的架构,广邀各路网路开发好汉,不管是擅长哪一种语言 -- javascript, Perl, Java, PHP, Python, Ruby, VB, C#... 的开发人员,都能轻易快速地兜出一个组合式的应用,来快速满足各自的需要。
企业所致力打造的 Service-Oriented Architecture,正是这么一个参与的架构(Architecture of Participation)。而企业进行 SOA 体质改造的第一大要务,正是研究如何将必须不断沿用下去的各后台 legacy 系统,给 service-enable 起来。换句话说,就是替他们设计一层 Web API,将既有的重要功能以 XML/Web services 的方式给包装起来。
由于 XML/Web services 是完全跨平台、跨程式语言的媒介,各种相应的高阶 API、工具箱,和视觉化发展工具又日新月异,因此开发组合式应用 (Composite Applications) 的门槛比传统的应用开发低了许多。这么一来,CIO 便可开始将企业内原本隶属不同团队(如 J2EE, .NET, PHP, SAP, PowerBuilder...)的开发人员加以整并,统合运用,而可更有效率地作任务编组,来完成未来需要交付的新应用。此项 SOA 所带来的获益,就个人观察,在目前已成功导入的企业中,屡见不鲜。
有人预测,五年至十年之后,随著 SOA 的大行其道,成功的企业将逐渐实现 Gartner 所谓的 "Real-time Enterprise"。也就是说,业务部门有任何新的应用需求,都能很快地得到实现。有的时候,业务人员甚至不需假手 IT 部门。因为许多业务服务,都已经以高阶的 Web services 的方式提供出来,许多会在 Excel 里作一点 scripting 的 power users 和 business analysts,都能够很轻易地去运用,例如在试算表中动态呼叫几个 Web services,组出一份最即时的报表。
我在 BEA 一位负责业务的同事,数年前在某大软体公司任职业务时,就曾经因为公司的 commission 计算方式太过庞杂,从来没有人真正搞清楚过到底算出来的数字是否正确,就连会计都有时都不是很确定。这位兄弟索性自己写一个 Excel 试算表,造福大众。从此以后,不再有计算奖金的争议。其实企业里面卧虎藏龙,具有这种实力的 power users 甚至不在少数,“开放参与的架构”和 SOA 提供了他们更多挥洒的空间和参与的机会,来打造他们最切身需要的应用。
1