SOA到底是什麽？
SOA(service-oriented architecture)的定義是面向服務的架構，也就是說將軟件按照功能設計成服務，這些服務以標準的方式定義接口，通過標準的協議調用。SOA定義的接口和調用方式獨立於編程語言和運行平臺。概括地說，SOA可以基於不同的底層技術來實現，比如CORBA和Web服務。而CORBA由於過於復雜臃腫，很少使用，所以目前提到的SOA大多是基於Web服務技術。在Web服務的實現下，SOA服務的接口由XML定義。
在SOA框架下，軟件開發從業務流程分析入手，使用組件業務建模的方法來識別和分析各種業務模型，並將各種實踐融入其中。在此基礎上建立用例，用例直接產生BPEL，可以集成到壹個服務集成框架中，框架描述了各種服務的信息，從而將所有模塊統壹在ESB上，形成壹個龐大的服務倉庫。
分離中間層，在中間層做壹個跨技術架構的元數據和業務邏輯，使之成為壹個跨技術架構、長期繼承、不斷積累的企業業務庫和最有價值的信息資產，即面向服務的構件庫，並且這個服務構件庫也可以被其他企業重用，而不依賴於任何壹種技術架構。誇張點說，如果所有軟件企業都使用SOA架構，世界軟件業將被徹底改變。顯然，這樣的框架不是產品，也不僅僅是技術，而是解決問題的方法論。
SOA可能適用於兩種場景:第壹種是業務互聯；二是封閉的交易系統，將元數據和業務邏輯分離，形成可重用性。比如第壹種場景，當不同企業之間的業務需要相互調用時，此時可能會采用SOA技術；在第二種場景中，當系統需要在企業內部遷移時，SOA技術定義的原始數據和業務流程可以快速完成。
SOA並不是壹個新事物。多年來，IT組織已經成功地建立和實現了SOA應用軟件。BEA、IBM等廠商看到了它的價值，紛紛效仿。SOA的目標是使其更加靈活，更快地響應業務單元的需求，並實現實時企業(這是Gartner對SOA的願景目標)。BEA的Rhonda早在2001年6月就提出將BEA的IT基礎設施改造為SOA，並在控制整個企業架構、提高開發效率、加快開發速度、減少定制和人員技能投入等方面取得了良好的效果。
SOA是壹種在計算環境中設計、開發、應用和管理分布式邏輯(服務)單元的規範。這個定義決定了SOA的普遍性。SOA要求開發人員從服務集成的角度設計應用軟件，即使這樣做的好處不會立即顯現出來。SOA要求開發人員超越應用軟件，考慮重用現有的服務，或者檢查如何重用服務。SOA鼓勵使用替代技術和方法(如消息傳遞機制)來構建應用程序，方法是將服務鏈接在壹起，而不是編寫新代碼。在壹個合適的框架之後，這種消息機制的應用使得公司只需要調整原有的服務模式，而不是被迫開發大規模的新應用代碼，就可以在商業環境允許的時間內快速響應不斷變化的市場條件。
SOA不僅僅是壹種開發方法——它還包括管理。例如，應用SOA後，管理人員可以方便地管理這些構建在服務平臺上的企業應用程序，而不是管理單個應用程序模塊。其原理是，SOA通過分析服務之間的相互調用，方便公司管理者獲取何時、為何以及執行了哪些業務邏輯的數據信息，從而幫助企業管理者或應用架構師叠代優化其企業業務流程和應用系統。
SOA的壹個中心思想是讓企業應用擺脫面向技術的解決方案的束縛，輕松滿足企業業務服務的變化和發展需求。企業環境中的單壹應用程序無法滿足業務用戶的(各種)需求。即使是大規模的ERP解決方案，也無法滿足這種需求不斷擴大和變化的缺口，快速響應市場。業務用戶只能通過不斷開發新的應用程序和擴展現有的應用程序來支持他們現有的業務需求。通過關註服務，應用程序可以集中起來提供更豐富和更有目的的業務流程。因此，基於SOA的企業應用系統通常更真實地反映了與業務模型的結合。服務從業務流程的角度看待技術——這是自上而下的。這種觀點與由可用技術驅動的壹般業務觀點相反。服務的優勢很明顯:它們與業務流程相結合，因此可以更準確地表示業務模型，更好地支持業務流程。相反，我們可以看到，以應用程序為中心的企業應用模型迫使業務用戶將其能力局限於應用程序的能力。
企業流程是流經企業框架的空氣，它賦予業務模型中的組件以生命，並更清晰地定義它們的關系。流程定義了與業務模型交互的專門方法。例如，會計可能是企業服務系統的壹個組成部分，但是向客戶發送發票是壹個業務流程。服務是為了支持業務流程而定義的，所以貫穿整個流程的是流程中各種服務組件的組裝操作和邏輯實現。理解業務流程是定制服務的關鍵。
傳統的應用集成方法(點對點集成、企業消息總線或中間件集成(EAI)、基於業務流程的集成)復雜、昂貴且不靈活。這些集成方法難以快速適應基於企業現代業務變化的不斷增長的需求。基於面向服務的架構(SOA)的應用程序開發和集成可以解決許多這樣的問題。
SOA描述了壹組完美的開發模式來幫助客戶端應用程序連接到服務。這些模式定制了壹系列用於描述服務、通知和發現服務以及與服務通信的機制。
與傳統的應用集成方法不同，在SOA中，所有圍繞服務的模式都是通過基於標準的技術來實現的。大多數通信中間件系統也是如此，如RPC、CORBA、DCOM、EJB和RMI。然而，它們的實現並不完美，在權衡標準定制的交互性和可接受性方面總是存在問題。SOA試圖消除這些缺陷。因為幾乎所有的通信中間件系統都有固定的處理模式，比如RPC函數，CORBA對象等等。然而，服務可以被定義為功能和對象、應用程序等等。這使得SOA適用於任何現有的系統，並且使得系統在集成時不必刻意遵循任何特殊的定制。
SOA幫助企業信息系統遷移到“離開層”架構，這意味著系統可以在不修改現有企業系統的情況下提供Web服務接口，因為它們已經被可以提供Web服務接口的應用層封裝，所以SOA可以在不修改現有系統架構的情況下快速將系統和應用轉換為服務。SOA不僅包括來自打包應用程序、定制應用程序和遺留系統的信息，還包括來自IT架構的功能和數據，如安全性、內容管理和搜索。因為基於SOA的應用程序可以很容易地從這些基礎服務架構中添加功能，所以基於SOA的應用程序可以更快地響應市場變化，並為企業業務部門設計和開發新的功能應用程序。
什麽是肥皂？
SOAP是簡單對象訪問協議的縮寫。
SOAP是分布式環境中基於XML的輕量級信息交換協議。
對Soap的理解:
第壹步是理解:soap = http+XML。
第二步是理解:SOAP將XML的使用編碼成請求和響應參數的編碼方式，使用HTTP作為傳輸方式。
SOAP結合了基於HTTP的成熟WEB技術和XML的靈活性和可擴展性。
步驟3:理解:具體來說，SOAP實現可以簡單地視為遵循SOAP編碼規則的HTTP請求和響應。
註意:SOAP是壹個與編程語言無關的協議。事實上，很多語言已經開始支持SOAP，比如Java、C、c++和JavaScript。
肥皂的起源？Soap解決的問題？
SOAP最初是微軟為了解決MTS/COM的資源消耗大、輕量級等問題而發起的。後來逐漸被IBM等巨頭接受，加入研究。現在已經提交給W3C，成為Web服務應用的傳輸標準。SOAP技術主要用於實現大量異構程序和平臺之間的互操作，以便現有的應用程序可以被廣泛的用戶訪問。
SOAP的意思是簡單對象訪問協議。的確，正如它的名字所暗示的，SOAP非常簡單。它是壹種基於XML的協議，允許程序組件和應用程序使用標準的互聯網協議HTTP相互通信。SOAP是壹個獨立的平臺，不依賴於編程語言。它簡單、靈活、易於擴展。目前，應用程序可以使用基於DCOM和CORBA技術的遠程過程調用(RPC)相互通信，但HTTP不是為此目的而設計的。RPC在互聯網上的應用是非常困難的，會有很多兼容性和安全性的問題，因為防火墻和代理服務器通常會阻止這些類型的流量。應用程序之間通信的最佳方式是通過HTTP協議，因為HTTP支持所有的Internet瀏覽器和服務器。為此，SOAP協議應運而生。
SOAP(簡單對象訪問協議)是壹種在分散或分布式環境中交換信息的簡單協議，它是壹種基於XML的協議。它包括四個部分:SOAP信封，定義了壹個框架來描述消息中的內容是什麽，是誰發送的，應該由誰接受和處理以及如何處理；SOAP編碼規則，用於表示應用程序需要使用的數據類型的實例；SOAP RPC表示，表示遠程過程調用和應答的契約；SOAP綁定，使用底層協議來交換信息。
雖然這四個部分都被定義為SOAP整體的壹部分，但是它們在功能上是交叉的，並且相互獨立。特別是，信封和編碼規則是在不同的XML名稱空間中定義的，這使得定義更加容易。
CXF是什麽？
Apache CXF = Celtix+XFire，Apache CXF的前身是Apache CeltiXfire，現在已經正式更名為Apache CXF，以下簡稱CXF。CXF繼承了Celtix和XFire的精髓，提供了對JAX-WS的全面支持，並提供了對各種綁定、數據綁定、傳輸和格式的支持，可以根據實際項目的需要，采用代碼優先或WSDL優先，輕松實現Web服務的發布和使用。目前還只是Apache的壹個孵化項目。
Apache CXF是壹個開源服務框架，CXF幫助您使用前端編程API構建和開發服務，如JAX-WS。這些服務可以支持多種協議，如SOAP、XML/HTTP、RESTful HTTP或CORBA，並且可以運行在多種傳輸協議上，如HTTP、JMS或JBI。CXF大大簡化了服務的創建，同時繼承了XFire的傳統，可以與Spring自然無縫集成。
CXF包含大量的功能特性，但主要集中在以下幾個方面:
支持Web服務標準:CXF支持各種Web服務標準，包括SOAP、基本概要、WS-Addressing、WS-Policy、WS-ReliableMessaging和WS-Security。
前端:CXF支持各種“前端”編程模型，CXF實現了JAX-WS API(遵循JAX-WS 2.0版TCK)，它還包括壹個“簡單前端”，允許創建客戶端和端點，而無需註釋批註。CXF支持Java的WSDL優先開發和代碼優先開發模式。
易於使用:CXF的設計更加直觀和易於使用。有大量簡單的API可以快速構建代碼優先的服務，各種Maven插件也使得集成更加容易，支持JAX-WS API，在Spring 2.0中支持更加簡化的XML配置等等。
支持二進制和遺留協議:CXF是壹個可插拔的架構，可以支持XML和非XML類型綁定，比如JSON和CORBA。
讓我們使用cxf創建壹個簡單的webservice。
首先，cxf需要的包:網站顯示以下包都是必須的，但是紅色的包在我的實際項目中並沒有用到。
每個人都可以有自己的需求添加適配包。
cxf.jar
commons-log . jar
geronimo-activation.jar(或Sun等價物)//
geronimo-annotation.jar(或Sun等價物)//
geronimo-javamail.jar(或Sun等價物)//
尼提罐
jaxb-api.jar
jaxb-impl.jar
stax-api.jar//
XmlSchema.jar
wstx-asl.jar
xml-resolver.jar
分布式應用程序和瀏覽器
研究當前的應用開發，妳會發現壹個絕對的趨勢:人們開始偏好基於瀏覽器的瘦客戶端應用。這當然不是因為瘦客戶可以提供更好的用戶界面，而是因為它可以避免發布桌面應用程序的高成本。發布桌面應用程序的成本很高，壹部分是因為應用程序安裝和配置的問題，壹部分是因為客戶端和服務器之間的通信問題。
傳統的Windows富客戶端應用程序使用DCOM與服務器通信並調用遠程對象。配置DCOM在大型網絡中正常工作將是壹項具有挑戰性的任務，也是許多IT工程師的噩夢。事實上，許多IT工程師寧願忍受瀏覽器帶來的功能限制，也不願在局域網上運行DCOM。在我看來，結果是壹個應用程序很容易發布，但很難開發，並且用戶界面極其有限。極端的情況下，妳花了更多的錢和時間，卻開發了壹個從用戶角度來看更弱的應用。不信？問問妳的會計師對新的基於瀏覽器的會計軟件有什麽看法:大多數商業程序用戶希望使用更友好的Windows用戶界面。
關於客戶端和服務器之間的通信，壹個完美的解決方案是使用HTTP協議進行通信。這是因為任何運行網絡瀏覽器的機器都使用HTTP協議。同時，許多防火墻目前被配置為只允許HTTP連接。
許多商業程序還面臨另壹個問題，即與其他程序的互操作性。如果所有的應用程序都是用COM或者。NET語言並運行在Windows平臺上，世界將會太平。然而，事實上，大多數商業數據仍然以非關系文件(VSAM)的形式存儲在大型機中，並由COBOL語言編寫的大型機程序訪問。而且還有很多商業程序繼續用C++、Java、Visual Basic等各種語言編寫。現在，除了最簡單的程序，所有的應用程序都需要與運行在其他異構平臺上的應用程序集成，並交換數據。這類任務通常通過特殊的方法來完成，比如文件傳輸和分析、消息隊列，以及只適用於某些情況的API，比如IBM的高級程序到程序通信(APPC)。之前沒有應用通信標準，獨立於平臺、構建模型、編程語言。只有通過Web Service，客戶端和服務器才能用HTTP自由通信，而不用考慮兩個程序的平臺和編程語言。
什麽是網絡服務？
Web服務是構建可互操作的分布式應用程序的新平臺。作為壹名Windows程序員，您可能已經用COM或DCOM構建了壹個基於組件的分布式應用程序。COM是非常好的組件技術，但是我們很容易舉出COM達不到要求的情況。
Web服務平臺是壹組標準，它定義了應用程序如何在Web上實現互操作性。妳可以用妳喜歡的任何語言，在妳喜歡的任何平臺上編寫web服務，只要我們可以通過Web服務標準查詢和訪問這些服務。
Web服務平臺需要壹套協議來實現分布式應用的創建。任何平臺都有其數據表示方法和類型系統。為了實現互操作性，Web服務平臺必須提供壹套標準類型的系統，以溝通不同平臺、編程語言和組件模型的不同類型的系統。在傳統的分布式系統中，基於接口的平臺提供了壹些描述接口、方法和參數的方法。同樣，Web服務平臺必須提供壹個標準來描述Web服務，這樣客戶才能獲得足夠的信息來調用這個Web服務。最後，我們還必須有壹種方法來遠程調用這個Web服務。這個方法實際上是壹個遠程過程調用協議(RPC)。為了實現互操作性，這個RPC協議還必須獨立於平臺和編程語言。
Web服務是web應用的壹個新分支。它們是自包含、自描述和模塊化的應用程序，可以通過web發布、定位和調用。Web服務可以執行從簡單請求到復雜業務處理的任何功能。部署後，其他Web服務應用程序可以發現和調用它部署的服務。
Web服務是壹個應用程序，它可以使用標準的Internet協議，如超文本傳輸協議(HTTP)和XML，在Internet和intranet上以編程方式顯示其功能。您可以將Web服務視為Web上的組件編程。
1歷史記錄
網絡中廣泛使用的技術:
◆TCP/IP:壹種通用的網絡協議，被各種設備使用。
◆HTML:通用用戶界面，可以用HTML標簽顯示數據。
◆Java:寫壹次可以在任何地方運行的通用編程語言。
◆XML:壹種通用數據表達語言，壹種在web上傳輸結構化數據的簡單方法。
它們的特點是開放性、跨平臺性，而開放性是Web服務的基礎。
2網絡發展趨勢
內容更加動態
◆帶寬更便宜，更容易獲得。
◆內存存儲更便宜，更容易獲得。
無處不在的計算變得更加重要:手機、頁面、電腦、PC等大量設備在互聯網上變得無處不在，平臺變得更加多樣化，XML等跨平臺技術變得更加重要。
web服務扮演什麽角色？
這些趨勢意味著更加智能地處理、操作和總結內容非常重要。讓我們看看從Web服務的角度預測的四個趨勢:
◆內容更加動態:web服務必須能夠組合來自多個不同來源的內容，包括股票、天氣、新聞等。在傳統環境中，庫存水平、購物訂單或目錄信息等內容都來自後端系統。
帶寬更便宜:網絡服務可以分發各種類型的內容(音頻、視頻流等。).
更便宜的存儲:web服務必須能夠智能地處理大量數據，這意味著使用數據庫、LDAP目錄、緩沖和負載平衡軟件等技術來保持可伸縮性。
◆普適計算更重要:web服務不能要求客戶使用windows傳統瀏覽器的某個版本，而必須支持各種設備、平臺、瀏覽器類型和各種內容類型。
4兩項重要技術
為了實現這個目標，Web服務應該使用兩種技術:
◆XML XML是在web上傳輸結構化數據的壹種很好的方式。web服務應該以可靠和自動的方式操作數據，HTML不會滿足要求。但是，XML可以使Web服務非常方便地處理數據，其內容和表示的分離是理想的。
◆SOAP SOAP使用XML消息調用遠程方法，使得web服務可以通過HTTP協議的post和get方法與遠程機器進行交互，SOAP更加健壯、靈活、易用。
其他技術，如UDDI和WSDL，與XML和SOAP緊密結合，用於服務發現。& lt/SPAN>。
構成Web服務平臺的這三項技術。
XML和XSD
可擴展標記語言(XML)是Web服務平臺中表示數據的基本格式。除了易於構建和分析之外，XML的主要優點是它獨立於平臺和供應商。冷漠比技術優勢更重要:軟件廠商不會選擇競爭對手發明的技術。
XML解決了數據表示的問題，但是它沒有定義壹套標準的數據類型，更不用說如何擴展這套數據類型了。比如整數到底代表什麽？16，32還是64？這些細節對於實現互操作性非常重要。W3C開發的XML Schema(XSD)就是解決這個問題的壹套標準。它定義了壹組標準的數據類型，並給出了壹種語言來擴展這組數據類型。Web服務平臺使用XSD作為其數據類型系統。當您用某種語言(如VB.NET或C#)構建Web服務時，為了符合Web服務標準，您使用的所有數據類型都必須轉換為XSD類型。您使用的工具可能已經為您自動完成了這種轉換，但您可能會根據自己的需要修改轉換過程。
WSDL
當每個函數被調用時，妳如何告訴別人妳的Web服務的函數和參數？您可以自己編寫壹組文檔，甚至可以口頭告訴需要使用您的Web服務的人。這些非正式的方法至少有壹個嚴重的問題:當程序員坐在電腦前，想要使用妳的Web服務時，他們的工具(比如Visual Studio)幫不了他們，因為他們根本不了解妳的Web服務。解決方案是以機器可讀的方式提供壹個正式的描述文檔。Web服務描述語言(WSDL)就是這樣壹種基於XML的語言，用於描述Web服務及其功能、參數和返回值。因為它是基於XML的，WSDL對機器和人都是可讀的，這將是壹個很大的好處。壹些最新的開發工具不僅可以根據妳的Web服務生成WSDL文檔，還可以導入WSDL文檔生成調用相應Web服務的代碼。