有時候，有標準並不能達成我們期望的效果。不少企業費了一番周折才理解這句話。
眾所周知，soa中的「a」代表架構。但是最初如果僅關注於構建web服務
，最終企業只是擁有了一堆分離且邏輯混亂的整合介面；又或者是一堆分離且邏輯混亂的「基於標準」的介面。用soa的行話來說就是jbows（just a bunch of web services），即一大堆web服務，僅此而已。表面看起來非常強大，一擊即垮。
soa從出現到現在經歷了很多年，也有人談過soa和整合
，比較公認的一種說法是soa不是一種整合方法。目前更多的企業使用soa來現代化其遺留應用。通過用服務來訪問遺留應用
，來改善一些整合系統，從而通過效率和更好的資料分析帶來附加利益。從這一點上看，soa作為大廠商的市場營銷概念也做的也不錯。
誠然，也有企業離開了soa這塊是非之地，但如果企業關注業務流程和治理，而不是技術流程，在設計系統的時候，soa應該還是比較有效的途徑。這也意味著企業要為使用頻繁的業務流程來開發服務，像金融機構的信用審查。美國家庭人壽保險公司的it應用服務經理frank braski在一篇文章中表示這些流程也可以通過七個概念來定義和模型化：關係、當事人、產品、協議、位置、屬性以及金融工具。在《金融服務業緣何鍾情soa》
中我們也做過相關介紹。
儘管soa可能簡化應用開發和遺留現代化，但這並不意味著簡單和輕鬆。因為這個過程中存在很多陷阱，包括複製並貼上來重用服務。ibm的sandy carter曾告誡道，it需要不斷地檢查，來看看服務是否還符合業務需求。
老版樂高玩具經常被用來解釋soa，但現在可能在解釋的時候要加上轉折了。因為優秀的樂高設計師知道通用的模式集可以適用於不同的建築問題，服務可以看作是樂高積木，但是任何人都可以將兩塊積木放在一起。這也就是我們所說的模式以及如何來使用這些服務，從這一點上看，一堆樂高積木和乙個真正完美的樂高建築
之間存在本質差別。
建議 2 莫讓常量蛻變成變數
說起來，感覺有點胡扯呢？常量中新增final和static怎麼可能發生改變呢？不能夠進行二次複製吧！下面，我們可以就這段程式一塊看一下。public class client 介面常量 inte ce constrand const是常量嗎？他的值會發生變化嗎？答案是肯定的，並且這種定義方式也是極其...
SOA面向服務架構
首先martin fowler提出soa歧義service oriented ambiguity，認為 什麼是soa 是不可能回答，因為不同的人意味著不同的事情，soa意味服務介面，意味流程整合，意味資源再利用，意味著管制，在下面soa元件圖中，服務和服務消費者 客戶端 之間存在多個約束，當乙個服務...
SOA 實踐 識別服務
soa 是個聽上去很美好的技術或者思想或者架構。當然任何美好的東西都需要有一些難題讓你去客服。實施 soa 又很多難點，其中一點就是識別服務。問題 我現在已經有一套 n種 業務系統。現在需要去充實我得esb，那些服務可以放上去呢？這時候我們可能會有幾種分析方式。自上而下，自下而上，或者中間匯合。所謂...