--企業架構師能從SOA中受益，開發人員同樣能從SOA中受益。有5個原因說明開發人員與SOA關系密切。
難于解決的問題
現有的應用架構已經無法跟上不斷改變的業務模型的步伐了。企業不僅在努力開發內部新應用程序，而且努力把他們的應用程序與合作伙伴、供應商、客戶集成到一起，但是他們面臨的是單一的、緊耦合的應用程序的限制，在編譯和運行時，每個子系統和其他子系統緊密聯系在一起。不僅在一個系統中的改變會造成另一個運行的失敗，而且還使開發人員陷入反復無窮盡的編碼、編譯、測試的循環中。開發人員也必須處理漸增的異構環境，每個環境中應用程序運用了一套新的需要學習和連接的API。
早期解決跨異構平臺集成應用程序的方法（例如CORBA）沒有實現它們的承諾，一部分是因為在對象模型中缺乏標準化，另一部分是因為甚至CORBA沒有想到需要考慮能快速開發、集成、重用應用程序的一個更為松散耦合的方法。
在這種背景下，面向服務的架構可以看成是應用程序架構開發的下一個革命性步驟，一個用模塊化和松耦合應用程序取代單一、緊耦合應用程序的革命。
SOA使用了一種模塊化的方法，其中每個組合或虛擬的應用程序是用來自獨立應用程序的許多不同分離服務組合而成的。服務能存在于網絡的任何地方，可以通過公共和私有注冊表用標準的接口去發現和使用它們�？梢酝ㄟ^將主要功能作為服務而公開，從現有應用程序中獲得服務，也可以從新的面向服務的應用程序中獲得服務。
雖然SOA可以充分利用諸如XML、UDDI、SOAP、WSDL和基于Java消息的技術，但是與CORBA不同，它本身不是一項技術。它是一個全新的思想傾向和結構方法，用來滿足企業應用架構中靈活性的需要。
面向對象的開發既是一種成功，也是一種犧牲。隨著企業軟件開發的發展，面向對象的語言（特別是Java）、方法和框架現在都能很好的被理解。表面上看來，決定是用面向對象的方法還是用面向服務的方法取決于您開發的軟件和與之交互的其他軟件之間的耦合松緊度。一般人的看法是，面向對象的開發適合于緊耦合的集成，然而SOA適合松散耦合的集成，雖然這種看法一般是正確的，但是它太過于簡單了。它不是選擇用一個或者其他一個的問題。就像許多新的開發工具建議的那樣，為了完成令他們傷腦筋的企業應用程序，開發人員需要理解兩者。
SOA不會取代面向對象的開發，面向對象的開發將仍然保持開發單獨應用程序的統治地位。但是隨著這些架構和框架繼續被改進和維護，將會真正的產生一種能支持生態系統（由協作應用程序組成）的基礎結構。不管這些應用程序是不是面向對象的，SOA都能擴充它們，通過提供普遍的、可重用的業務級接口而不是組件級的接口，SOA有助于開發人員完成這種擴充。
此外，SOA要求一個實例能從客戶/服務器方法轉移到考慮事件驅動交互的應用程序開發中去。因為服務可以作為一個業務過程插入到任何地方，開發人員必須對應用程序開發有整體上的把握。主要的不同就在于接口是如何設計的。在SOA中，關鍵是開發粗粒度并且不是基于應用程序的組件架構的接口。所以，在SOA環境下的應用程序開發、集成、重用和業務過程建模、工作流、程序到程序的通信相吻合。
Carrot
協作應用程序的新世界使開發人員的角色朝更好的方向改變。它在相當大的程度上提高了組織中開發人員的價值，這是因為他們不用在一個特別的基礎上再去組裝單個應用程序或處理應用程序集成，而是負責給整個業務定義一個架構。企業構架師比一般意義上的開發人員的角色更關鍵。為了有利于一個新的應用程序，單個工程可能會被取消，開發投入大量個人經驗開發的應用程序可能會被清除。但是所有的企業承認他們需要一個可伸縮的、適應性強的基礎結構，這個結構可以不影響已有的業務而按照需要添加新的應用程序，他們也在求助于技術專家開發這種結構方法。
SOA給開始用服務構建應用程序的開發人員帶來了許多益處。
松耦合
如果您根據由通信服務組成的光纖想一想SOA，很容易會發現松散耦合是如何減少在一個服務中修改代碼也會要求在另外一個服務中修改代碼的機率。在這種情況中光纖可以看成是總的應用程序。如果使用傳統應用程序中的步驟將這些服務硬編碼在一起，則更改一個步驟就像在一個真實的光纖上拉一根線一樣。結果整個光纖將會壞掉。利用SOA，就能夠大批的遷移或者取代單個的服務而不影響總的組合應用程序。
位置透明性
想一下關于從客戶/服務器模式轉移到事件驅動模型我們說了什么？在事件驅動模型中，服務的消費者無需知道服務位于網絡哪個地方。SOA中的服務在注冊表中已經注冊。這個注冊表可能是數據庫、目錄服務、UDDI注冊表或者XML文件，它能很容易地被客戶端應用程序定位。所有注冊和發現都由SOA處理，所以開發人員可以集中精力去解決業務問題。
事實上，這種位置透明性是讓Web服務工作的一個必不可少的部分。以這種方式把應用程序開發和部署分開使得企業能靈活地把服務遷移到不同的服務器中，而不需要考慮那樣會如何影響客戶端應用程序，它也使得開發人員滿足了業務可用性、符合服務級別和可伸縮性的要求。
代碼重用
開發人員會懷疑是否有能達到代碼真正重用的切實可行的辦法，這是可以原諒的。自從過程化語言讓位于面向對象的開發，我們一直期待著將來應用程序的開發是一種Lego積木方式的簡單插拔對象方式。雖然面向對象的框架在普通環境中有一些成功，但是使它們穿過異構平臺工作的困難一直使人畏縮，主要是因為缺乏標準化和一種易理解的公開描述方法的方式。
我們還沒有達到那樣的程度，但是SOA實際上可以通過用UDDI在注冊表中列出服務和公開WSDL文檔中方法（包括參數和類型），使開發人員從代碼重用中受益成為可能。
每次開發人員要集成新的應用程序時，他們不需要重新開發。不需要修改現有應用程序就能達到新的功能。
通用服務
通用服務將取代硬編碼集成，這使得開發人員能夠將精力集中于總體解決方案和更高級別的策略實現。例如，企業軟件的通用方面（如可靠傳遞和智能路由）將由基礎結構本身作為服務提供，無需開發人員再為這些功能編寫代碼。
平臺獨立性
SOA提供了一個能適應多類硬件、操作系統、中間件、語言和數據存儲的抽象層，在許多情況下，企業架構師在不了解每個組件的情況下也能夠集成這些多樣性組件。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
