你如何做系統整合？

Question

我很好奇不同的人如何解決系統的整合。我有一種感覺，就是最近幾年越來越多的工作已經進入整合系統，這種工作需求也會增加。

我想知道你是否解決了它開發自己的小型服務，然後連接或者如果你使用某種產品（WebSphere，BizTalk，Mule等）。我也認爲了解如何管理和維護這些解決方案（您如何解決安全性，儀器等等），您遇到的解決方案遇到了哪些問題等都很有趣。

Answer 1

哇 - 好吧 - 會在這個帖子上發帖，但會很大。

集成需要在企業獲得好處的情況下得到很大理解的支持 - 獲得一個可操作的模型 - 由於業務可能非常需要標準化而不是集成，因爲這可能代價高昂 - 爲什麼大多數SOA失敗！ Enterprise Architecture: Driving Business Benefits from IT Author(s): Jeanne W. Ross

如果需要整合，則需要解決整合類型。

什麼是速度和性能指標？

我們有一個.NET SOA與一個複合應用程序，它使用BizTalk 2006和webservices與業務線應用程序。在複合端應用程序的性能（消費） - 僅限於業務應用程序中的Web服務（及其實現）的速度！我們需要結果 - 案例列表3秒返回<。無法在web服務中實現，因此我們需要直接轉到數據庫進行初始搜索。然後通過Web服務創建案例。成本影響和維修成了一個問題。

在這裏點是看性能標準的規範和業務需求，這將在看看整合式幫助，你需要做的 - Web服務（HTTP），文件拖放/ EDI等

在功能上，爲了整合，您需要查看所提出的架構中的失敗點，因爲這將導致SLA/OLA中的一系列責任。您可能需要將集成/失敗點包裝到您控制的事物中。

關於與業務線集成的相似點，您需要先了解其他產品需要多少錢？是的，Webservices應該是按合同設計的，但實現往往是漏洞，你需要了解有關正在發生的事情 - 如果這是一個產品，即使Web服務泄漏到你的綜合技術（又稱BizTalk）中，你不控制抽象。

將這兩點結合在一起，您最好的建議是獲得像BizTalk這樣的集成中心類型 - 在您創建的webservices中封裝業務應用程序的行 - 所以BizTalk方面可以免於泄漏抽象，那麼您也可以減少因爲您已將業務線應用程序從集成中心和失敗點解耦爲單一源而不是在編排中。

SOA和Intergation中的儀器和診斷對象很難達到！ - 不要讓任何閃耀的銷售人員嘗試以不同的方式告訴你！是的MOM與MOM的媽媽可以做到這一點UniCenter可以做到這一點。

主要問題是要了解集成中的錯誤aka意味着什麼，以及如何從中恢復......您最終會遇到消息停滯，並且您需要了解這個業務流程的含義。你可以得到一個警告 - 處理器是100％Ram 100％編排失敗 - 但沒有真正意義。你必須從一開始就把這些東西設計到解決方案中 - 並希望進入你的失敗點。

集成模式的類型以及如何做它們也需要考慮。

以上是實際應用中的BizTalk .NET .NET的真實世界視圖。但這也是由於這種架構限制 - BizTalk主要是HUB和SPOKE模式。

退房Enterprise Application Patterns by Martin Fowler

有很多方法對皮膚的任務！

其他考慮...平臺/開發語言等

一種爲我們的大因素是開始這個​​東西所需要的技能。我們有OO開發人員對Java和C＃的理解，但主要是C＃。所以我們去了MS堆棧。但是，當您選擇整合類型和產品來管理這些時，他們需要更多技能來理解該技術。但是，嘿，這對我們來說是正常的嗎？錯誤的許多開發人員，無論那裏expereince可以與諸如BizTalk的喜歡取消！範式的巨大轉變 - 部分原因是由於消息轉移而不是代碼。

最後一點！

整合中可能面臨的交易數量很可能是所有這一切中最大的一個因素。因爲這將指導什麼樣的模式，失敗點和對這些事情的寬容。

您需要在正確的捲上選擇最好的反捲。一些可以擴大和擴大的東西！我們之所以選擇BizTalk，是因爲它可以正確擴展和擴展，並且比其他人有更好的理解。

如果你沒有卷，然後看看沒有得到的東西來管理它們，並尋求web服務web服務類型的風格，沒有管理 - 性能和失敗的理解將需要編碼到他們。

如果您在Windows平臺上使用.net 3，請查看WWF/WCF，因爲這可以幫助將web服務轉換爲webservice - 現在有更多的acutal平臺可以解決所有這些問題，而不會造成BizTalk和其他人的開銷。

希望這會有所幫助。

Answer 2

根據我的經驗，這取決於你正在解決什麼樣的問題。

以我的經驗來說，很難擊敗BizTalk 2006 R2以獲得巨大回報，但它確實意味着使用Microsoft技術堆棧。

Websphere MQ似乎更容易向大型企業銷售，並且可能在企業級應用更廣泛。

兩者都提供了良好的儀器功能，但作爲開發人員，您可以根據自己的客戶需求進行定製。

在某些情況下，我發現定製的解決方案是最合適的，或利用MSMQ等技術降低成本。

Answer 3

您提到了WebSphere，BizTalk，Mule。其中每一個的優點和缺點都有很不相同的特點。 如果你只是集成後，我會建議騾子。我對它有非常好的經驗，更重要的是架構師非侵入性，因此您可以隨時遷移到不同的ESB或其他Buzz字詞投訴解決方案。 Mule的甜蜜之處在於它可以嵌入到您的應用程序中，並且您的最終工件可以部署在Webshpere，WLS，Glassfish等等......甚至不需要嵌入ESB。然後這個ESB可以執行所有的集成管道（管理連接類型和協議）。而一些端點可能是您提到的其他集成解決方案。

Answer 4

我們正在使用Mule一段時間（現在調查從1.4遷移到2.1.x版本）。

嗯它是現場社區和供應商方面的快速反應的最佳ESB之一，但IMO版本2.1.x仍然有點粗糙（或者我們只是使用它來調用CXF web的公司:)另請參閱我的帖子詳情http://www.nabble.com/Migration-from-XFire-to-CXF:-Is-Web-Service-Client-in-Mule-2.x-broken--to19969320.html#a19969320）

Answer 5

我們有一個Oracle合同。所以我們使用Oracle Stack。 SOA套件10.1.3.4。大多數BPEL解決方案和我們試圖使用ESB的簡單轉換。

ESB有一個錯誤的故障處理機制。對於BPEL，有許多方法可以處理錯誤。我們嘗試開發java web服務來連接到SOA套件，我們的主要系統是Oracle EBS系統。它們通過SOA套件附帶的默認EBS適配器與遺留系統或其他EBS環境進行通信。

我們遇到的問題是缺乏有關EBS適配器的知識。我們遇到了一些從EBS系統收到信息的BPEL解決方案的問題。準備好解決方案生產是一項艱鉅的任務。

保護我們的web服務不是一個大問題。隨Oracle數據倉庫一起提供Oracle Web服務管理器。有了這個，我們可以保護，記錄所有的web服務。

我們遇到的最大問題是缺乏我們自己的標準。讓業務感覺他們也可以構建SOA解決方案。我們無法解釋他們通過SOA解決方案獲得的好處。更快？不！便宜？一定不行！更簡單的解決方案那麼，也許當我們獲得好的可重用服務......好吧，那個更容易的部分有一個問題：我們如何知道哪些應用程序使用可重用的Web服務？

我們需要一個寄存器，可以顯示這種信息。由於我們無法找到一個好的開源解決方案，我們正在努力建立自己的註冊表。簡單的APEX解決方案，再次來自Oracle堆棧。 ;）

那麼有人知道一個好的產品來註冊這種信息？