建立一個完全基於SOA的大型應用程序是明智的嗎？或只是一些部分？用戶帳戶登錄，會計，地理信息映射，銷售等？完全應用SOA嗎？
換句話說，在HTML中構建一個這樣的應用程序的GUI是明智的嗎？& Javascript是否通過ajax與後端的.NET Web服務進行交互？
我看不到它值得失去所有.net .aspx功能，如窗體身份驗證，視圖狀態等。但我的同事說如果我們要去SOA，那麼不需要.NET在前端。但我認爲應該有某種平衡。你在哪裏畫線？是否所有對數據庫的調用都要通過Web服務？
我聽到這首歌'如果我有一把錘子'的話。 SOA is an architectural approach將軟件開發爲一系列服務。在我看來，對於延遲時間短，帶寬有限，訪問成本高的系統來說，這是最好的選擇（這些都顯然是非常主觀的）。你不需要完整的SOA只是在組件之間發生鬆散的連接，我認爲這是一個很好的目標。
數據庫調用可以通過服務，以ADO.NET數據服務爲例，但是您真的必須權衡服務的提供。採取緩存。一個體面的SOA方法將考慮可能需要緩存數據以減少服務負載。那麼你的數據是否會在用戶界面中陳舊？你允許這個用例嗎？登錄信息陳舊是正確的（我知道一個粗略的例子，但可能可能需要解決）。
總而言之 - 這要看。我認爲有些東西很適合SOA。如果採取DDD的方法，那麼代表域的服務可能會這樣做。通過這種方式，您的用戶界面會與域服務進行對話，而不會與表中的行進行對話，因爲數據庫在域服務之後被抽象化
不要使用一種方法來解決所有問題。
看到這個SO question也
我只想說，「與SOA我們正在建設的變化，而與傳統的系統工程中，我們建立了穩定。」
穩定性的問題當然是，它只需要業務到目前爲止 - 如果組織需要業務敏捷性，那麼他們會更好地實施SOA。
所以，它完全取決於你想要達到的目標，你是應該劃定邊界的人。
我幾天前在關於SOA的文章中讀到它，因爲我太過於關注SOA。
編輯：
同時我碰到this文章，與大家分享思想。 該視頻很好地解釋了當前SOA的情況以及不同人的看法。
這是一個面向服務的體系結構，而不是服務獨有的體系結構。
演示邏輯和管道必須住在某個地方;這一切都取決於它最適合生存的地方。
例如，假設您有一個UI組件，它依賴於對數據庫的高度健談但高效的調用來生成對某事的複雜分析（請隨意選擇）。如果您的Web瀏覽器正在進行所有這些呼叫，則會引發大量網絡延遲和併發問題。如果Web服務完成所有這些調用，則可能會將表示邏輯放入其中以格式化該結果。
如果您使用會話狀態（或網絡服務期），則基本上使用ASP.Net。嘗試卸載它並查看您的Web服務是否仍在運行。
如果表示邏輯需要存在於服務器端，那麼最好將它放在用於表示的框架中，而不是Web服務IMO。如果你沒有看過MVC 2，那就這樣做。它使建立一個融合瀏覽器和服務器UI支持的應用程序（例如，由服務器端驗證支持的jQuery驗證器控件）非常容易。
相反，Web瀏覽器提供了一個富有表現力的平臺。假設瀏覽器支持和團隊知識，你描述的AJAX/SOA架構是一個很好的。我越來越多地使用它，並試圖讓我的服務器頁面變得更清潔和簡單，但我沒有計劃很快將ASP.Net從我的工具包中排除。
客戶端實現應完全斷開與SOA中的後端Web服務的連接。該服務應該能夠被任何客戶使用。如果您在後端和前端使用.NET，因爲它們可以被編碼爲直接通信，那麼您就錯過了這一點，因爲現在它們緊密耦合，現在您擁有的是一個爐管應用程序。客戶端應該不知道服務器端是如何實現的 - 如果後端Web服務是使用.NET，Java或其他來構建的，應該無關緊要。
在真正的SOA中，您應該能夠搜索服務存儲庫中的服務，或許將輸出與其他服務綁定在一起，或者使用XSLT創建替代輸出，這些輸出在構建原始服務時不一定要考慮，並在前端的任何客戶端以標準方式使用它。
這聽起來像你真正要問的是如何構建一個應用程序。 SOA的要點是通過可重用接口提供標準數據集，這些接口沒有具體的應用或實現。開始構建包含SOA服務的整個後端的單個應用程序將是一項艱鉅的任務。在我們看來，每個後端服務都應該建立起來，因爲它的內在價值都在它自己的身上，並被提供給整個SOA「域」。然後，當您或我決定創建一個X，Y和Z的客戶端時，我們可以在SOA中找到這些功能並注入它們。
你們都可以查找首字母縮略詞，看看你是否同意它的實際含義。來回彈跳，看看是否有任何*真實的想法在三個字母之外彈出。然後做一些對你們有意義的事情。如果你的同事只是繼續關注這些信件，然後尋找另一個。 – 2010-10-08 21:57:45