railco 案例分析

本文主要是翻譯

RailCo最初的目標是升級其自動化系統,以便保持競爭力,並繼續與其主要客戶TLS的業務關係。當競爭對手設法以較低的價格提供空氣制動部件,同時還與TLS的B2B系統接口時,RailCo失去了TLS的客戶身份。RailCo匆忙趕上來,生產了一對僅用於TLS系統的Web服務。這使得RailCo重新獲得了TLS供應商的地位。

這兩個最初的Web服務是

發票提交服務

訂單履行服務

(稍後添加了另一個服務以與TLS通知服務交互。)

然而,儘管RailCo已經成功地與TLS重新連接,但它已經失去了它的獨佔關係。現在,它發現自己處於這樣一種境地:它必須對每一個發出的採購訂單都與一個咄咄逼人的競爭對手進行競價;因此,它仍在損失收入。

Railco公司避免大規模裁員的唯一辦法就是找到新客戶。爲了實現這一目標,RailCo需要繼續與其他提供B2B解決方案的運輸公司一起尋求在線供應商市場。很明顯,RailCo目前的一組Web服務不足以達到這一目的。因爲它們是專爲與TLS一起使用而設計的,所以它們對於與其他要求不同業務和事務需求的客戶進行交互是沒有用處的。

RailCo當時面臨着一個重要的決策,要麼爲每個新客戶開發一組定製的服務,要麼從頭開始,構建一組通用的標準化服務,以方便多個客戶。它選擇了後一種選擇,並決定實現這一目標的最佳方法是徹底檢查其現有環境,以支持SOA。

RailCo的兩個主要業務流程是:

訂單履行(接受和處理來自客戶的訂單)和

發票提交(向客戶發送發票)。

RailCo進行了面向服務的分析,將其業務流程邏輯分解爲一系列候選服務。這表明需要以下潛在的服務和服務層:

由兩個以任務爲中心的業務服務組成的業務服務層。

由四個應用服務組成的應用服務層。

RailCo沒有技術或預算來投資能夠提供編排的中間件。因此,它選擇不在編排服務層中追求業務邏輯的集中化。

相反,它決定用以任務爲中心的業務服務來表示每個業務流程,該服務將充當應用程序服務層的控制器。對以下服務進行了建模和設計:

o發票處理服務(以任務爲中心)

o訂單處理服務(以任務爲中心)

o遺留系統服務(應用程序)

o輪詢通知服務(應用程序)

o轉換服務(應用程序)

o元數據檢查服務(應用程序)

在應用服務的設計中特別強調了可重用性和可擴展性。RailCo希望其初始的SOA由支持其當前業務流程的服務組成,同時具有足夠的可擴展性以適應未來的需求,而不會產生太大的影響。

爲了實現發票提交流程,RailCo能夠將這些服務組合成一個兩級層次結構,其中父發票處理服務協調所有應用程序服務的執行(圖a.1)。
在這裏插入圖片描述
圖A.1。RailCo的服務組合,使其發票提交過程自動化。

訂單履行流程現在可以通過PO處理服務實現自動化,該服務重用發票提交流程使用的兩個相同的應用程序服務(圖A.2)。

在這裏插入圖片描述

圖A.2。訂單履行過程由一個由兩個可重用應用程序服務組成的訂單處理服務自動化。

面對一些壞消息,包括負責交付其原始Web服務的.NET顧問的離職,RailCo能夠很好地利用內部資源。經過培訓,新的SOA被創建爲J2EE解決方案。

RailCo通過生成支持兩個面向服務的解決方案的SOA來實現其最初的目標。RailCo現在可以繼續與TLS進行在線交易,同時自信地尋找新客戶。引入新需求的其他客戶可以以最小的影響來適應。它的標準化應用服務層可能會繼續提供可重用的功能,以滿足新的需求。任何功能上的差距都可能通過擴展服務來解決,而不會對現有的實現造成嚴重的干擾。

此外,如果RailCo決定在未來用編排服務層取代其以任務爲中心的業務服務,則由現有應用服務層建立的抽象將保護應用服務不必進行重新開發。

完成此項目後,RailCo發現了其新解決方案環境的一個附帶好處。通過將遺留系統服務(本質上是其會計系統的包裝服務)作爲其應用程序服務層的一部分建立起來,它打開了一個通用端點,可以促進集成。

這爲RailCo提供了在其會計系統和聯繫人管理應用程序之間實現互操作性的潛力(在第2章中首先介紹)。通過允許這兩個環境共享數據,RailCo可以更有效地利用協調的聯繫人和財務歷史檔案來接納和服務新客戶。

考慮本文中介紹的RailCo案例以及課堂和召回服務的設計原則。根據鬆耦合評估RailCo解決方案。陳述並捍衛你的觀點。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章