如果我们从技术的角度探究Web之所以能成功，会发现遵循开放标准所带来的松散藕合(loose coupling)是最重要的关键。怎么说?站在一个使用者的立场，我只要有一个浏览器，不管是用什么平台--PC、Unix、Mac，甚至是PDA，我都可以看遍全世界的网站。或许我明天会挖掘出几个之前从来没去过、令人兴奋的新网站。

　　最棒的是，我的计算机和浏览器事先不用和那些新的网站先进行设定，只要想连结到哪个网站去就随时可以去。更神奇的是，浏览器(信息消费者)和网站(信息生产/服务提供者)双方不会因为各自不定期，或者是定期的升级、改版动作而影响彼此的连结与信息的撷取。这就像灯泡、电池一样，可自由选择不同厂牌，来搭配不同的台灯和手电筒。而Web之所以能成功，正是因为大家--也就是各厂牌的浏览器和网页服务器--基本上都遵循HTML、JPG，HTTP 这些开放格式和标准。但如果用到某浏览器或服务器专属的功能时，开放性和选择性就会受到扼杀。

　　随着网站的迅速普及，除了用网页来提供内容和信息外，很快的，网站也变成了数据库查询、在线交易等各形各色的服务提供者。网站服务器 (Web server) 同时也开始被赋予要执行应用程序的任务。当这些任务变得愈来愈重要、艰巨且专业时，应用服务器 (application server) 便应运而生，时至今日，发展已趋于成熟。

　　我们可以把这一波的网络革命--使用者藉由浏览器作为窗口，享受到网站所提供的各项应用服务--称做是Web 1.0的时代。而「browser to AP」可说是这个时代不二的运行模式。

　　几年前，网络上的有识之士开始思考：为什么要那么僵硬的局限大家，一定要透过浏览器才能来执行网站上的应用、享受所提供各项服务?是不是可以让信息服务的消费者和生产者之间更「松散藕合」一点;换句话说，网站上的应用程序在提供各项服务时，是不是可以不要将交易和查询的结果立即format成HTML网页的格式?

　　因为这样一来，就等于对信息的消费端预设了一个立场，变成强迫消费端非得要用浏览器来与信息供应端互动。是不是能有一个更中立的方式，让消费端自行决定要如何消化、呈现从服务端所提供的信息?XML正是在这样的背景下诞生，其目的即在于提供一个对信息能够做精准描述的机制，藉以弥补 HTML 太过于表现导向的特质。

　　在这样的情况下，消费端的应用弹性便大幅增进。生产端应用服务器所提供出来的信息「服务」，除了浏览器外，还有包含IM (Instant Messenger) 在内的P2P软件、Java手机、IA 家电，乃至于其它服务器上的服务程序。而Office类的文书软件，也都摇身一变为潜在的信息消费者。Web 的运行模式，也从之前的 Web 1.0 --「browser to AP」，演化到「AP to AP」的 Web 2.0 时代。而「Web services」这个名词被选择用来代表这个新的应用模式。

　　Web 1.0 时代为因应需求所衍生的应用服务器，在Web 2.0 时代也逐渐开始演化为服务导向的应用平台。在后续的专栏中，将会进一步的讨论到这个主题。

　　再来看看 Web services 发展至今，已经受到广泛探讨和研发的各个技术层面。我们用真实世界中的服务来对照，会发现Web services和SOA 中所强调的「服务」，在观念上有许多地方的确有如前两期中所言，与业务面非常贴近。

　　就以日常生活中常接触到的邮局、银行，监理所等的服务柜台来说，我们在临柜申办之前，可以先在服务台查询服务说明、服务项目，然后得找到正确的申办窗口。至于申办前，也必须先按规定先填单子，照字段格式一项项的填写，还必须出具印鉴、身分证等验明正身，然后交给承办人员办理。

　　当业务繁忙、排队的人多的时候，可能会有义工或专人引导我们到比较不忙的窗口去申办，以加快处理速度。服务的质量;也可能会受到服务主管的监听和纪录(像我们打电话到客服中心去，就常常被告知说，为确保服务质量，这通电话可能受到监听)。

　　这些和服务相关的各项功能，在Web services和SOA的领域中，也都一一有相对应的机制，包括UDDI和 WSDL(服务查询和描述)、service endpoint(申办窗口)、XML Schema/XSD(申请单元格式)、WS-Security(验明正身)、SOAP(申办动作)，此外还有服务绕径/路由和负载平衡(申办排队的引导)、服务监控、管理、稽核，以及质量的确保。

　　所有这些 Web services 的相关领域，目前都已经有专门的产品提供解决方案。在设计规划 Web services 和服务导向架构时，负责的建筑师也可以利用这些与真实世界业务相仿的特性，来协助鉴定所规划的 IT 服务，同时应与使用单位进行充分的沟通。而此举对成功的导入，将有相当的帮助。