《雲計算：原理與範式》一3.10 企業對企業內建服務

對于連接配接地理上分散的企業而言，企業對企業內建（b2bi）是具有針對性和互利合作的主流活動。産品供應商紛紛生産b2b集線器和套件，使參與企業間以标準相容的方式順利共享資料。現在，随着雲的普及，用認真和真誠的态度努力放置雲中的這些産品，用極少的投資和維護成本将b2bi作為服務提供。雲的思想和理念為從資本支出到營運開支轉變和維持轉換奠定了強有力和刺激的基礎。

在b2bi空間中有幾個成熟的內建方法。為了實作更快的成功，在不斷變化的iaas場景中取得更好的回報和價值，可以捕獲這些方法并使之資本化。b2bi系統是iaas的極佳候選，因為傳統上利用b2bi系統可以在制造商和它們的外部貿易夥伴（如零售、倉儲、運輸、庫存系統）之間使業務流程自動化。這意味着，它們提供了這樣的關鍵功能——用于連接配接内部和外部軟體的應用程式到應用程式（a2a）的連接配接，即跨越企業防火牆的安全的資料交換。

與僅用于内部資料共享的純企業應用內建（eai）解決方案有所不同，b2bi平台有能力通過公共網絡對檔案加密、管理大量的資料卷、傳輸批處理檔案、轉換成不同的檔案格式，并保證資料的準确、完整、保密和傳遞。有確定在制造商及其外部供應商或客戶之間溝通順暢的能力，它們還在托管和安裝的應用程式之間可靠地交流。

iaas模式還充分利用由b2bi廠商開發的擴充卡庫提供與各個業務系統的快速內建。b2bi合作夥伴專業知識淵博、經驗豐富，他們為主要的erp、crm、scm和其他打包的業務應用（packaged business application），以及從as400到mvs和大型機的遺留系統提供了預建構的連接配接器。星型拓撲集中式架構的使用進一步簡化了實施，該架構為系統管理提供了良好的控制。最終，這避免了用戶端上放置過多的程序負擔。在saas供應商的雲中心安裝集線器（hub），以完成類似重新格式化檔案的重任。一個分支單元通常包含一個小的可下載下傳的java用戶端，接着在每個使用者站點部署該分支單元以處理如資料傳輸等基本任務。這也消除了昂貴的基于伺服器的解決方案、資料映射和客戶所在地的其他任務的需求。由于internet是主要的通信基礎設施，是以企業可以與他們世界各地的合作夥伴進行智能和系統協作以保持同步。

用于b2b場景的基于雲的企業混搭內建服務[17]。對于生疏、情景和特定的b2b應用程式而言，大量的業務最終使用者有着巨大的需求。企業混搭和輕量級組合方法及工具是有前景的方法，它們釋放授權最終使用者的巨大的、尚未開發的潛力以開發或組裝對齊，并意識到綜合服務以克服“長尾”的窘境。目前，支援b2b協作的可用解決方案聚焦于長期業務關系的自動化，它們仍然缺乏提供給使用者直覺的方式，以根據使用者的特定或情境需要修改或擴充這些解決方案。由于較長的開發周期和缺乏所需的業務知識，這類應用開發中的正常程式需要耗費大量的時間和人力。

特别是在支援b2b協作的領域中，目前産品的特點是高豐度、低範圍。如以衆多功能為重點的b2b分支，盡管支援電子協作，但小型團體甚至個人則缺乏可用性。另一個具有低範圍、高豐度的極端解決方案，如web站點、門戶網站和電子郵件，缺乏标準化和公式化，這使得它們不适合自動化或特殊企業的需求。是以，新的開發方法需要克服這些障礙，涉及開發過程中的非技術性商業使用者。為了解決這個長尾綜合征，實作成本效益和效率的提高，并克服it部門與經營機關之間的正常限制。

企業混搭應用是一種新一代基于web的應用，似乎充分履行最終使用者的個别和異構要求并促進最終使用者開發（eud）。為了縮短傳統和費時的開發過程，這些新品種的應用由非專業程式員開發，往往以非正式、疊代和協作的方式組裝現有的結構塊（building block）。

soa一直是組織的內建困境的一種有效解決方案。在soa驅動的公司内，esb用于內建不同的服務。然而，大多數esb都沒有被指定為跨組織的協作，是以在闡明和針對這種擴充協作時會出現問題。soa簡化和精簡了新的服務及第三方服務的內建，然而熟練的和經驗豐富的開發人員仍然可以完成它。最終使用者通常不能實作想要的內建方案。在內建項目的高成本下，這導緻不必要的僵化。因為內建項目持續更長的時間，盡管市場競争要求積極主動地及時響應興起的要求。

b2b內建中的另外一個挑戰是程序的所有權和責任。在許多組織間的設定中，業務流程隻有稀疏的結構和形式，而非松散耦合和基于特定合作。組織間的合作往往涉及越來越多的參與者，不斷增加的參與者還繪制了大量的不同要求。另外，參與者可根據不同的角色、控制和優先權做事。從曆史上看，合作的重點是根據一套規則管理團隊的參與。

現在，對供應商和合作夥伴共同創新及客戶共同創造的支援，其重點是轉向支援參與者的合作，但參與者受到多個領域控制和不同過程和實踐的限制。這表示從靜态的b2b方法到新的動态的b2b內建遊戲規則的轉變，可以自适應行為并對任何意外幹擾作出反應，可以允許快速配置和定制并管理和節制端到端業務流程使用的日益複雜性。

電子資料交換（edi）轉換器和受管檔案傳輸（mft）都有一個較長的曆史，而b2b網關則在過去十年中才出現。然而，大多數可用的解決方案旨在支援中大型規模的公司，導緻成本高、實施周期和時間長，這使得他們無法負擔，對規模較小的組織也無吸引力。是以，這些産品并不适合短期合作，這需要用特定的方式設定。

企業混搭平台和工具。混搭應用善于結合不同的分布式資源，包括内容、資料或應用功能。資源表示混搭應用的核心結構塊。人們可以通過api通路資源，其中api封裝資源并描述可用的接口。小部件或小工具主要放在底層資源，為它們提供圖形表示及從資源接收到的管道資料。管道可以包括運算符，如聚合、合并或過濾。混搭平台是一種基于web的工具，它允許通過管道資源一起進入小工具和接線小工具來建立混搭應用。

企業混搭應用在b2b內建場景中極具優勢，大家已意識到并為其做好準備。混搭應用能解決許多b2b分支的缺點，如硬接線連接配接的下遊。混搭應用允許eud和輕量級系統連接配接，可以使現有的輕量級解決方案更加豐富，如增加一定程度的規範和标準的網站或門戶網站。混搭應用促進易于混合及轉換各種内部和商業夥伴的資訊來源。b2b操作中的複雜性往往與異構系統和平台有關。煩瑣的內建程序及各種支援和軟體維護的要求是當今動态b2b內建的一個主要障礙，對中小型企業來說更是如此。

混搭內建服務正在fast項目中作為原型實施。圖3.9中的體系結構是對原型層的說明，它描述了這些服務如何協同工作。該架構的作者對使用雲基礎設施和服務的服務技術實作前景做出了展望。

原型架構顯示了服務和彼此之間的關系。中間方框内顯示的是核心服務。中間方框下顯示的是擴充服務，通過api允許使用第三方産品實作其功能。使用者通過自己選擇的混搭平台使用這些服務。通過api将混搭平台連接配接到混搭內建服務。

要想使用這些服務，使用者必須确定自己對使用者的通路控制服務。該服務連接配接到使用者管理服務，進而控制使用者及其設定。使用者管理服務通過一個api連接配接，允許使用外部服務，如企業使用者資料庫。所有來自使用者的資料通過轉換引擎（translation engine）統一資料對象和協定，內建不同的混搭平台。轉換引擎有一個接口，可以連接配接其他外部轉換引擎以支援額外的協定和資料标準。被轉換的資料轉發給路由引擎（routing engine），這是混搭內建服務的核心。路由引擎處理混搭平台收到的各種輸入，并轉發給正确的收件人。人們可以通過api配置以許多規則為基礎的路由。

為了簡化這一架構，可以為最終使用者提供gadget。路由引擎還通過api連接配接一個消息隊列。是以，不同的消息隊列引擎是可連接配接的。消息隊列負責存儲和轉發由路由引擎控制的消息。消息隊列下面的持久性存儲可存儲大量的資料，它還可以通過api連接配接以允許可交換性。錯誤處理和監控服務允許跟蹤消息流以檢測錯誤，并收集統計資料。混搭內建服務作為一種基于雲的服務托管。另外，還有一些基于雲的服務提供內建服務所需的功能。這樣，混搭內建服務可以重複使用，并充分利用現有的雲服務加快實施。

消息隊列。使用amazon簡單隊列服務（sqs）可實作消息隊列。sqs是一個web服務，它為消息提供了一個隊列，并存儲這些消息直到其可以處理。混搭內建服務，尤其是路由引擎，可以将這些消息放入隊列中，并在需要時再調出它們。

持久性存儲。amazon簡單存儲服務（s3）也是一種web服務。路由引擎可以使用該服務存儲大量的檔案。

轉換引擎。這主要集中在混搭平台可以連接配接了解的不同協定（如rest或soap web服務）之間的轉換。然而，如果轉換的對象需要轉換時，可能會連接配接到轉換引擎。一方面，需要這種服務的a公司可以開發這樣的服務，并把它連接配接到混搭內建服務。另外一種可能性是連接配接現有的轉換服務，如mule on demand提供的許多服務，也是基于雲計算的産品。

服務之間的互動。圖3.9描述的是混搭內建服務平台傳遞和處理消息的過程。這一過程的先決條件是使用者已經建立了一個收件人的路由。通過api收到來自企業混搭工具的消息後，首先檢查消息發送者對外部服務的通路權限。隻有授權消息發送者，才能處理收到的消息。也就是說，消息發送者有權利将消息傳遞到收件人并使用混搭內建服務。如果他沒有被授權，處理過程則停止，并記錄一個錯誤資訊。錯誤日志資訊将寫入日志檔案，它會駐留在amazon的簡單存儲服務。如果已接受該消息，則放入amazon的sqs服務消息隊列中。如果需要，可以把該消息轉換成另外一種格式，它也可以由外部的、基于雲的服務完成。随後，這些服務就可以開始嘗試将消息傳遞到收件人。評估消息的收件人是以存儲在路由引擎中的規則為基礎的，這些規則使用者之前已配置過。最後，可以記錄該消息的成功傳遞，若發生錯誤亦可記錄。