Web服務設計師，第2部分：動態(tài)電子商務模式

申請免費試用、咨詢電話：400-8352-114

Web服務設計師，第2部分：動態(tài)電子商務模式

Dan Gisolfi (gisolfi@us.ibm.com)

解決方案設計師，IBM jStart Emerging Technologies

2001 年 4 月

每一種新興的技術必須要穿越創(chuàng)新和接受之間的鴻溝。Web 服務的技術采用生命周期也是如此。然而，這項技術卻很適合決策者的不同對象。他們是誰？什么會激發(fā)他們？基于動態(tài)電子商務這種現(xiàn)象，這篇文章探討了 Web 服務就市場的各個部分給商業(yè)實體提供的一種價值取向。

技術上任何合理的投資都需要有商業(yè)理由。無論這個理由表現(xiàn)為一種新的收入渠道，還是有效地改進了日常商業(yè)的運作，最終決定是否采用這項技術的人，一定要確定的就是這項投資絕對符合價值取向。

不同于近年來的其它新生技術（Java、XML、普及計算），Web 服務的發(fā)展并不只取決于 IT 決策者。這項技術的采用高度依賴于商業(yè)實體在其所在行業(yè)中的角色及其收入模式。由于這個原因，line-of-business (LOB) 的執(zhí)行者就會在很大程度上影響采用新技術的速度和方式。

為實現(xiàn) Web 服務，軟件設計師不得不向他們的上級證實 Web 服務模式商業(yè)原理。因而，我從兩個方面開始這篇文章，試著解釋為什么商業(yè)需要 Web 服務以及它是如何影響商業(yè)目標的。

可能的商業(yè)角色

在 Web 服務的面向服務體系 (SOA) 中，有三個截然不同的角色：提供者、請求者和中介者。如果您是一個軟件工程師，應該很清楚這個問題，任何給定的子系統(tǒng)或進程，都可被設計用來作為請求者或提供者或兼任兩者。然而，從一個商業(yè)執(zhí)行者的高度來看這些可能的參與節(jié)點，去了解與每一個節(jié)點相關的潛在商業(yè)模式是非常必要的。

我們再來從一般的 IT 角度去看，任何 Web 服務 -- 可通過 Web 獲得的軟件資源組件 -- 可以是其它分布式軟件組件服務的請求者，可能是本地的，也可能是遠程的。在這種情況下，軟件設計師可以決定把 Web 服務和這個角色聯(lián)系起來，這樣可以減少操作和維護應用程序的開支，或者提高選擇給定的商業(yè)進程的可用實現(xiàn)的靈活性。即使所有這些可實現(xiàn)，還是存在問題：商業(yè)何時決定認同請求者、提供者或中介者角色？此外，可能認同多個這樣的角色嗎？

雖然存在三個 SOA 參與節(jié)點，但事實上，一個公司有五個可能的商業(yè)節(jié)點以供選擇。讓我們單獨看看每一個：

服務請求者：對于認同這個 SOA 角色的商業(yè)，必須找出他們的商業(yè)行為和請求者行為之間的共性。有兩個明顯的商業(yè)行為，它們允許商業(yè)從實現(xiàn)服務請求者的角色中獲利：

內容集合是一種行為，商業(yè)實體能夠在其中與各種內容提供者相互影響，處理或再生（用顧客期望的表現(xiàn)形式）這種內容。這種商業(yè)實體的示例可能是任何因特網(wǎng)入口或者信息服務提供者。

服務集合是一種行為，商業(yè)實體能夠在其中與各種服務提供者相互影響，重新樹立品牌、充當東道主，或者為顧客提供復合型服務。這種商業(yè)實體的示例就像 OnStar (www.onstar.com) 一樣的機動入口。

服務提供者：對于認同這個 SOA 角色的商業(yè)，必須把自己視為正在執(zhí)行某種程度的電子服務。無論服務被定義為處理數(shù)據(jù)，還是實現(xiàn)特殊任務的行為，商業(yè)實體必須相信，它是作為一種職業(yè)或者商業(yè)為其它的商業(yè)實體提供服務。由于幾乎任何東西都可以是服務，所以很難完整地列出應用商業(yè)的清單。然而，我們可以提供一些簡單的示例：

獨立軟件提供者是潛在服務提供者的最好示例。他們普遍擁有并維護軟件資產(chǎn)，這些軟件資產(chǎn)能夠執(zhí)行一個或多個任務。這些軟件資產(chǎn)可以作為服務集合使用，或者分解成明顯獨立的軟件服務資源。

經(jīng)過驗證和大眾化，能夠適應一整套不同應用方案的商業(yè)程序很可能成為一個好的服務提供者。例如，如果一個銀行認為它的貸款處理業(yè)務是足夠強大的資產(chǎn)，可以公開向社會提供，而且它也愿意將其作為一種商業(yè)服務，那么，這個銀行就可以把自己視為貸款處理服務提供者。

注冊處：如果一個商業(yè)實體的業(yè)務是收集和整理其它商業(yè)的數(shù)據(jù)，然后將這些數(shù)據(jù)賣給某些商業(yè)，那就可以恰當?shù)胤Q其為注冊處，也是某種形式的 SOA 中介者。通常情況下，一個注冊處會收集像商業(yè)名稱、描述和聯(lián)系信息的數(shù)據(jù)。在 UDDI 術語中，這個 SOA 角色經(jīng)常被稱為白頁。

中介者：建立在注冊處概念的基礎之上，商業(yè)實體也能夠認同中介者的意見，在 UDDI 術語中通常被稱為黃頁。中介者經(jīng)常通過提供智能搜索能力和商業(yè)分級或分類數(shù)據(jù)來擴展注冊處的價值取向。

集合者／門戶：就是那些提供中介者功能并具有描述實際策略、進行商業(yè)處理和綁定描述能力的商業(yè)實體，能夠把自己標識為綠頁。

采用理由

這些商業(yè)角色在決定與給定的角色進行聯(lián)合并采用技術之前，必須還要為商業(yè)提供一些附加值。為了達到這一點，有兩類因素能夠證明采用 Web 服務技術是正確的。第一類因素不總是和最終金錢價值有關，第二類因素則取決于收入。

非收入理由

非收入理由說明了一些采用動機，這些動機對于商業(yè)的成長和生存很重要，但不會輕易地或不必要地使用特定的金錢價值做信用。例如：

上市所需的時間。

通過通信提高運作效率，并降低運作成本。

向關系密切的商業(yè)伙伴顯露內在過程，壓縮供應鏈。

通過第一個上市或者成為實際標準充分利用網(wǎng)絡影響。

提高創(chuàng)新速度。

更大膽地向新領域滲透。

收入理由

收入理由允許商業(yè)接觸新客戶，擴展現(xiàn)有的伙伴關系或者建立新的伙伴關系，并且為新的交貨渠道提供現(xiàn)有的供應方式。這類采用動機可使?jié)撛诘姆仗峁┱邍L到甜頭。雖然下面的可能是不盡完整的列表，但是我所在的組一直在努力地補充新增加的內容。當然，我歡迎來自讀者的任何意見。

對于服務提供者，這里有五個收入模式：事務處理、成員資格／簽署、租借／許可、商業(yè)伙伴關系和 注冊。

事務處理模式指的是點擊付款或者使用付費模式。它是所有模式中最基本的。一旦兩個貿易伙伴（一個服務請求者和一個服務提供者）之間存在了商業(yè)關系，那么提供者需要確定如何獲得使用服務的同意條款。一個可行的方法是 pay-as-you-go 方法。這里，每筆交易的收費通過使用類似信用卡之類的付費工具來實現(xiàn)?，F(xiàn)在對于 Web 服務提供者，可以通過他們提供的服務界面來使用這種收入方法，但是這一點必須在設計時就被考慮進去。建立使用條款的另一個可能方法是 out-of-band 關系。簡言之，就是商業(yè)關系條款要在使用服務之前達成一致。既然電子合同的技術尚未成熟，那么必須依賴使用服務之前建立的商業(yè)關系。使用這種方法，服務提供者只需要審查服務的使用并定期付款。無論哪一種方法，這兩個貿易伙伴必須建立一個雙邊服務付費協(xié)議。

成員資格或者簽署模式指的是一種收入模式，這種模式適用于帶有特殊使用條款的已建立的用戶帳戶。使用者可以定期進行使用注冊（不限量）或者按量注冊。服務提供者可以創(chuàng)建成員資格級別，這樣可以滿足特殊級別用戶的特定要求。類似于事務處理模式，服務提供者必須決定服務界面是否處理管理收入模式方面的問題，或者是否能夠通過 out-of-band 關系來管理收入。

租借或者許可模式指的是一種收入模式，這種模式在大的商業(yè)伙伴中比較普遍，他們需要大量地使用服務并期望更加合體的協(xié)議。這里，服務提供者可能根據(jù)交易量收費，或可能根據(jù)服務請求者內部的請求“組件”（席位）數(shù)量收費。在本例中，out-of-band 關系就是一個給定的假設。

商業(yè)伙伴模式是一個新概念。雖然在 2000 年 .com 為之所做的宣傳提供了足夠的證明說明這個模式是必需的，我們仍必須為這個模式提供一個示例。本質上，這個模式指的是在服務交換、等同體或甚至請求者總收入的一部分的基礎上，通過 out-of-band 或者基于提前使用的系統(tǒng)，來建立相關條款。

注冊模式指的是一種收入模式，這種模式可以更容易地應用于 UDDI 門戶或者綠頁商業(yè)。這里，基于 pay-to-be-seen 概念的收集收入概念是可行的。前提是服務提供者希望被發(fā)布，他們愿意支付注冊費用。

顯然，只要服務提供者提供一個合理的商業(yè)概念，收入和非收入這兩類都可為構建一個采用 Web 服務技術的商業(yè)案例提供充分的理由。

假設采用

這里所說的收入模式和采用理由的種類都比較普遍，對于任何市場部分都是適用的。在嘗試提供一個示例時，我要求讀者考慮圖像轉換的范圍，以及 Sharpe Images (SI) 的假設商業(yè)實體和它的圖像轉換產(chǎn)品 -- Convert-It。SI 最近失去了對一家大保險公司的投標，那家公司正在尋找把它需要的全部圖片和文檔轉化為電子資料。SI 的產(chǎn)品定位很好，而且在所有的競爭產(chǎn)品中最具靈活性。然而，Convert-It 是一個可安裝的產(chǎn)品，不作為軟件服務提供。SI 具有長遠目光的商業(yè)主管意識到如果他們想要贏得商機，就需要滿足資源電子化需求。他們決定做自己產(chǎn)品的主人，為顧客提供基于工程規(guī)模的租借業(yè)務。這個建議不僅讓 SI 贏得了這個項目，而且它也給用戶提供了基于 pay-as-you-go 的一個新的交貨渠道。

總結

由于商業(yè)尋求與動態(tài)電子商務技術的結合，那么他們必須能夠把商業(yè)與特定的 SOA 角色關聯(lián)起來。在大多數(shù)示例中，他們還需要從商業(yè)的角度，為采用這種技術提供充分的理由。在本文中，我們聲明了商業(yè)的五個不同的 SOA 角色，并提供了兩類采用這種技術的商業(yè)原因。在下一期文章中，我將會討論動態(tài)電子商務的本質。

參考資料

通過點擊文章頂部或者底部的討論，加入這篇文章的論壇。

閱讀我這個系列的第一個專欄Web 服務設計師，第 1 部分：動態(tài)電子商務介紹。

請閱讀Web 服務體系概覽。

請查看動態(tài)電子商務的 real world adoption scenarios。

請回顧擴展標記語言。

請了解簡單對象訪問協(xié)議。

請閱讀 Web 服務描述語言。

請訪問它的主頁，了解關于通用描述、發(fā)現(xiàn)和集成的更多信息。

請看一下 XML 協(xié)議工作組的成員。

請從 alphWorks 下載 IBM 的 WSDL 工具包。

請從 alphWorks 下載 IBM 的 Web 服務工具包。

關于作者

瀏覽： Web服務設計師，第1部分

Web服務設計師，第3部分

Web服務設計師，第4部分

Web服務設計師，第5部分

Web服務設計師，第6部分