如果我們從技術的角度探究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 服務，同時應與使用單位進行充分的溝通。而此舉對成功的導入，將有相當的幫助。