將SOA經驗應用於Web 2.0實現

兩位IBM傑出工程師，Kyle Brown和Rachel Reinitz，在這篇新文章的開頭對現有Web 2.0方式進行了快速討論：

新的技術忽如一夜春風來，突然間我們過去所做過的所有技術都過時了並將被淘汰。乍一看，新的Web 2.0技術也將步此後塵。這些技術的硬派支持者將會告訴你,，你需要把所有的SOAP服務都扔掉了；使用SOAP和WSDL來構建不僅會使得你的專案時間變得更長，它們更不會帶來任何益處……儘管REST簡化了對某些型別服務的構建——特別是那些對外、面向Internet或Ajax客戶端的服務，但仍然還有許多服務會通過應用SOAP，WSDL，以及WS-*規範而獲益。另外，取決於你所擁有的SOAP服務的型別，你可以通過將你的服務轉化為REST服務來擁抱Web 2.0；特別對於面向資料的服務更是如此。

他們還描述了幾個主要的企業級SOA的經驗教訓可以如何被運用於REST實現。

支援新興業務模型是SOA的主要賣點之一，通常是通過提升企業業務流程的靈活性來達到，以此幫助企業進入新的市場或領域。同樣的，Web 2.0技術提供了新興的接觸客戶和業務夥伴，與之溝通以及進行協作的方式：

Web 2.0的概念可通過幾種方式被用來驅動新型的業務模型。業務可構築社群，允許使用者成為關鍵資料的生產者，圍繞使用者構築生態系統，尋求與使用者溝通的新途徑，並支援將資訊“混搭”成新的形式或檢視……這當然是一種簡化，但如果你只將Web 2.0看作是關注於富UI，Atom feed以及RESTful服務的“炫”技術的話，你就錯失了Web2.0是如何被用於帶來根本性業務變革的。

聯絡業務。一個成功SOA實現的一個主要先決條件就是，通過簡明扼要的將實現所需投資和投資回報(ROI)兩者聯絡起來，實現業務－IT的對齊。

……對於可能的業務價值你需要越具體越好，最好是，對Web 2.0的採用提供預計的投資回報……業務方未必會像開發者那樣為新技術而感到興奮。因此，為了促使Web 2.0起航，你需要能夠以他們的方式(就像你對開發者所做的那樣)來聯絡業務方。

從一個堅實的方法論基礎來驅動採納。另一個關鍵的SOA成功基石是從SOA方法論基礎而來的實踐，過程以及規則。作者引用了物件導向建模與構架(SOMA)和元件業務建模(CBM)，將其作為讓業務使用者參與進來並幫助他們理解業務與IT對齊的手段。為了達成這一目的，Web 2.0將需要一個由現有SOA和麵向物件設計方法演化而來的堅實的方法論基礎：

……需要有一種方法來發現Web 2.0應用目標的群體，以及找出他們通訊風格的方法……同時還需要定義利用這些群體來幫助你評估服務，從而得到業務價值的方法。同樣地，需要更改或擴充套件SOMA服務發現機制，以及服務“石蕊測試”來找出那些適合於應用整合的服務與適合於支援富Internet應用的服務之間的區別。

明確願景，建立路線圖，貫徹計劃。成功的另一個先決條件是擁有一個整體的願景並朝著這個願景執行計劃：

如果你只關注於Web 2.0的願景和路線圖(包括實現基礎設施和框架專案)而缺少“真正”專案(深入生產並交付業務價值)，那你就冒著實現出一個無法滿足專案需求的基礎設施和過程的風險，也使得專案團隊更難遵守路線圖/架構/框架。如果你啟動一個單獨的Web 2.0專案而缺少一個願景和路線圖，缺少一個通用框架，你冒的風險是交付更少的價值，重複勞動，在專案中未能對程式碼進行重用，並且無法構建通用的基礎設施和過程……早期專案不必大到要交付價值，但通常應當是能為從新的技術和業務模型獲取經驗而提供機會。

不要忽視治理。已經有足夠多的文章強調SOA治理的重要性：

我們從以前運用Web 2.0原則構建的應用中所看出的是，Web 2.0的治理將會更富有挑戰，因為Web 2.0採納的關鍵方面在於社群內自由的通訊，協作，以及資訊共享。由於我們暴露了RESTful和Atom服務，問題變成了：我們如何控制卻不限制對於這些服務的使用和使用者資產的開發？如果構建一個社群的社會性方面受限於一個太過於限制的治理流程，那這一社群將不會興旺。然後，我們太容易看到線上社群由於不夠或不當的治理而受損害了；太容易被“廢品”所掩埋而不能夠彰現出那些真正存在的有價值的內容。

對於企業級SOA，簡單而言，有影響力的Web 2.0實現是將企業整體作為目標。結果，由成功的以及失敗的SOA實現所得出的經驗都可以被應用到許多Web 2.0專案。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780828/viewspace-567472/，如需轉載，請註明出處，否則將追究法律責任。