soap伺服器是什麼

1. soap是什麼牌子，

SOAP
求助編輯網路名片
SOAP：簡單對象訪問協議，簡單對象訪問協議（SOAP）是一種輕量的、簡單的、基於 XML 的協議，它被設計成在 WEB 上交換結構化的和固化的信息。 SOAP 可以和現存的許多網際網路協議和格式結合使用，包括超文本傳輸協議（ HTTP），簡單郵件傳輸協議（SMTP），多用途網際郵件擴充協議（MIME）。它還支持從消息系統到遠程過程調用（RPC）等大量的應用程序。

目錄

簡介四個部分
協議結構
語法規則
SOAP 核心技術
SOAP 的優點
php SOAP實例
消息格式
剖析SOAP封套
SOAP-RPC
SOAP用例
小結簡介 四個部分
協議結構
語法規則
SOAP 核心技術
SOAP 的優點
PHP SOAP實例
消息格式
剖析SOAP封套
SOAP-RPC
SOAP用例小結展開 編輯本段簡介
簡單對象訪問協議含義 這里之所以說是簡單，是因為它是基於已經廣泛使用的兩個協議：HTTP和XML，所以業界把這種技術稱為「它是第一個沒有發明任何新技術的技術"，之所以說是對象，是因為把訪問的Web服務稱為對象，既然服務是對象，那麼服務肯定有相關的屬性和調用行為，這些屬含拿性和行為是通過WSDL來描述的。如果按「簡單的對象訪問協議」來理解，相比「簡單對象訪問協議」要容易些。
四個部分
soap。n.(英文)肥皂 SOAP：簡單對象訪問協議 （SOAP：Simple Object Access Protocol） SOAP 包括四個部分： SOAP 封裝：它定義了一個框架 , 該框架描述了消息中的內容是什麼，誰應當處理它以及它是可選的還是必須的。 SOAP 編碼規則：它定義了一種序列化的機制，用於交換應用程序所定義的數據類型的實例。 SOAP RPC 表示：它定義了用於表示遠程過程調用和應答的協定。 SOAP 綁定：定義了一種使用底層傳輸協議來完成在節點間交換SOAP封裝的約定。 SOAP 消息基本上是從發送端到接收端的單向傳輸，但它們常常結合起來執行類似於請求 / 應答的模式。所有的 SOAP 消息都使用 XML 編碼。一條 SOAP 消息就是一個包含有一個必需的 SOAP 的封裝包，一個可選的 SOAP 標頭和一個必需的 SOAP 體塊的 XML 文檔。 把 SOAP 綁定到 HTTP 提供了同時利用 SOAP 的樣式和分散的靈活性的特點以及 HTTP 的豐富的特徵庫的優點。在HTTP上傳送 SOAP 並不是說 SOAP 會覆蓋現有的 HTTP 語義，而是 HTTP 上的 SOAP 語義會自然的映射到 HTTP 語義。在使用 HTTP 作為協議綁定的場合中， RPC 請求映射到 HTTP 請求上，而 RPC 應答映射到 HTTP 應答。然而虧老晌，在 RPC 上使用 SOAP 並不僅限於 HTTP 協議綁定。 SOAP也可以綁定到TCP和UDP協議上。
協議結構
SOAP 消息格式： SOAP 標頭 <SOAP-ENV: Envelope Attributes> <SOAP-ENV:Body Attributes> </SOAP-ENV:Body> </SOAP-ENV:Envelope>目前主要在web服務中運用。
編輯本段語法規則
這里是一些重要的語法規則： SOAP 消息必須用 XML 來編碼 SOAP 消息必須使用 SOAP Envelope 命名空間 SOAP 消息必須使用 SOAP Encoding 命名空間 SOAP 消息不能包含 DTD 引用 SOAP 消息不能包含 XML 處理指令
編輯本段SOAP 核心技術
SOAP采銷鋒用了已經廣泛使用的兩個協議:HTTP 和XML。HTTP用於實現 SOAP 的RPC 風格的傳輸, 而XML 是它的編碼模式。採用幾行代碼和一個XML 解析器, HTTP 伺服器( MS 的 IIS 或 Apache) 立刻成為SOAP 的 ORBS。SOAP 通訊協議使用 HTTP 來發送XML 格式的信息。HTTP與RPC 的協議很相似,它簡單、 配置廣泛,並且對防火牆比其它協議更容易發揮作用。HTTP 請求一般由 Web 伺服器軟體(如 IIS 和Apache)來處理, 但越來越多的應用伺服器產品正在支持HTTP。XML 作為一個更好的網路數據表達方式( NDR)。SOAP 把 XML 的使用代碼化為請求和響應參數編碼模式, 並用HTTP 作傳輸。具體地講, 一個SOAP 方法可以簡單地看作遵循SOAP編碼規則的HTTP請求和響應, 一個 SOAP 終端則可以看作一個基於HTTP 的URL, 它用來識別方法調用的目標。像CORBA/ IIOP一樣, SOAP不需要具體的對象綁定到一個給定的終端, 而是由具體實現程序來決定怎樣把對象終端標識符映像到伺服器端的對象。
編輯本段SOAP 的優點
(1) SOAP 是可擴展的。SOAP 無需中斷已有的應用程序, SOAP 客戶端、 伺服器和協議自身都能發展。 而且SOAP 能極好地支持中間介質和層次化的體系結構。 (2) SOAP 是簡單的。客戶端發送一個請求,調用相應的對象, 然後伺服器返回結果。這些消息是XML 格式的,並且封裝成符合HTTP 協議的消息。因此,它符合任何路由器、 防火牆或代理伺服器的要求。 (3) SOAP 是完全和廠商無關。SOAP可以相對於平台、 操作系統、 目標模型和編程語言獨立實現。另 外,傳輸和語言綁定以及數據編碼的參數選擇都是由具體的實現決定的。 (4) SOAP 與編程語言無關。SOAP 可以使用任何語言來完成, 只要客戶端發送正確SOAP 請求( 也就 是說, 傳遞一個合適的參數給一個實際的遠端伺服器)。SOAP 沒有對象模型, 應用程序可以捆綁在任何 對象模型中。 (5) SOAP 與平台無關。SOAP 可以在任何操作系統中無需改動正百分比法辦法常運行。
編輯本段PHP SOAP實例
php提供了一個專門用於soap操作的擴展庫，使用該擴展庫後 可以直接在php中進行soap操作。下面將介紹soap的基本操作。 一、soap擴展的使用方法 php的soap擴展庫通過soap協議實現了客服端與伺服器端的 數據交互操作。從php5.0後，php就自帶了soap的支持。使用 soap擴展庫首先需要修改php安裝目錄下的配置文件php.ini 來激活soap擴展庫。 在php.ini文件中找到如下所示的一行代碼，去掉前面的注釋(;)。 ;extension=php_soap.dll 修改後，重啟web伺服器即可激活soap擴展。在soap擴展庫中，主要 包括三種對象。 1、SoapServer SoapServer用於創建php伺服器端頁面時定義可被調用的函數及返回 響應數據。創建一個SoapServer對象的語法格式如下: $soap = new SoapServer($wsdl,$array); 其中，$wsdl為soap使用得wsdl文件，wsdl是描述Web Service的一種 標准格式，若將$wsdl設置為null，則表示不使用wsdl模式。$array是 SoapServer的屬性信息，是一個數組。 SoapServer對象的addFunction方法是用來聲明哪個函數可以被客戶端調用， 語法格式如下： $soap->addFunction($function_name); 其中，$soap是一個SoapServer對象，$function_name是需要被調用的函數名。 SoapServer對象的handle方法用來處理用戶輸入並調用相應的函數，最後返回 給客戶端處理的結果。語法格式如下: $soap->handle([$soap_request]); 其中，$soap是一個SoapServer對象,$soap_request是一個可選參數，用來表示 用戶的請求信息。如果不指定$soap_request，則表示伺服器將接收用戶的全部 請求。 2、SoapClient SoapClient用於調用遠程伺服器上的SoapServer頁面，並實現了對相應函數的調用 。創建一個SoapClient對象的語法格式如下: $soap = new SoapClient($wsdl,$array); 其中，參數$wsdl和$array與SoapServer相同。 創建SoapClient對象後，調用服務端頁面中的函數相當於調用了SoapClient的方法， 創建語法如下: $soap->user_function($params); 其中，$soap是一個SoapClient對象，user_function是伺服器端要調用的函數，$params 是要傳入函數的參數。 3、SoapFault SoapFault用於生成soap訪問過程中可能出現的錯誤。創建一個soapFault對象的語法格式 如下： $fault = new SoapFault($faultcode,$faultstring); 其中，$faultcode是用戶定義的錯誤代碼，$faultstring是用戶自定義的錯誤信息。soapFault 對象會在伺服器端頁面出現錯誤時自動生成，或者通過用戶自行創建SoapFault對象時生成。對於 Soap訪問時出現的錯誤，客戶端可通過捕捉SoapFalut對象來獲得相應的錯誤信息。 在客戶端捕獲SoapFault對象後，可以通過下面的代碼獲得錯誤代碼和錯誤信息。 $fault->faultcode;//錯誤代碼 $fault->faultstring;//錯誤信息 其中，$fault是在前面創建的SoapFault對象。 已刪除無關的內容。
編輯本段消息格式
SOAP在標准化消息格式環境中，可以做所有它能完成的工作。消息的主體部分 是「text/xml」形式的MIME類型，並且包含一個SOAP封套。該封套是一個XML文 檔。封套包含了 報頭（可選的）和報文（必須有的）。封套的報文部分總是用於 最終接收的消息，而報頭項目可以確定執行中間處理的目標節點。附件、二進制 數字及其他項目可以附加到報文上。 SOAP提供了一種讓客戶端指定哪個中間處理節點必須處理報頭項目的方法。由 於報頭與SOAP消息的主體內容是互不相關的，所以可用它們給消息添加信息，而 不會影響對消息報文的處理。 例如，報頭可用於為報文中包含的請求提供數字簽名。在這種情形下，身份驗 證/授權伺服器可以處理報頭項目獨立於報文可以剝離信息以驗證簽名。 一旦通過驗證，封套的其餘部分將被傳遞給SOAP伺服器，它將對消息的報文進行 處理。深入研究一下SOAP封套，有助於明了SOAP報頭和報文元素的位置和用途。
編輯本段剖析SOAP封套
SOAP 1.1規范提供了下面的封套示例：SOAP-ENV:mustUnderstand="1" 5DEF 在這個例子中，GetLastTradePrice請求被傳送給網路上某個位置的一個存儲 -引用服務。 該請求帶有一個字元型參數，一個訂單符號，並在SOAP響應中返回一 個浮點數。SOAP封套是表示SOAP消息的XML文檔的頂層元素。XML命名空間用於將SOAP標識 符與應用程序的特定標識符區分開。XML命名空間在SOAP中使用很頻繁，以把消息 的元素的作用域限制在一個特定的領域。理解SOAP命名空間有助於熟悉XML命名空 間規范。如果您沒有理解命名空間，也可以簡單地把它看作一種鄰近的標識符， 它通過把SOAP元素與特定的位置（真實的或想像的）相關聯，從而有助於惟一地 標識SOAP元素。 命名空間 上面例子中的第一個命名空間參照了在SOAP消息中定義元素和屬性的SOAP模式。 第二個命名空間參照了SOAP編碼，即前文中討論過的「Section 5」數據類型。 由於沒有指定額外的通用元素編碼，這種編碼將適用於整篇文檔。 報頭 在SOAP封套報頭示例中標識的第一個元素是一個transaction（交易）元素，它 帶有一個命名空間屬性和一個值為1的mustUnderstand屬性。既然mustUnderstand的屬性值設為1 ，接受該消息的伺服器必須在該transaction節點上執行中間處理。您可以對此 作這樣的解釋：伺服器與客戶端事先已就管理該報頭元素處理的語義達成了一 致，因而伺服器確切地知道要處理的元素的內容，本例中元素的內容是「5」。 如果接收消息的伺服器不理解transaction報頭的語義，它就會拒絕請求並拋出 一個錯誤。錯誤元素是SOAP報文和定義良好的機制的一個特殊部分，用於把錯誤信 息送回給客戶端。 像這樣的中間處理節點是SOAP可擴展性的一個例子。客戶端在SOAP消息中包含 這樣的節點，以在可以處理消息的報文內容前，指示要發生的特殊的處理需要。 要保證向後兼容不能提供這種處理的現有的伺服器，只需把mustUnderstand 屬性設置為0，它使操作是可選的。除了定義像上例中所示的transaction節點外，SOAP消息還可包含報頭項目， 它們用於指定節點執行身份驗證處理、加密、狀態的永久性、業務邏輯處理等。 報頭有助於把SOAP構建成一種可擴展的模態包模型。只需記住報頭處理是完全獨 立於SOAP消息的報文的。 報文 上面例子中的SOAP報文包含一個XML載荷，我們可以推測RPC沒有為我們對其作 詳細解釋。SOAP不僅是一種模態包模型，它還是一種相當神秘的包模型。沒有什麼跡象清楚地顯示RPC將要開始做什麼。我們在報文中所看到的是幾個 XML元素，其中一個用命名空間進行了限制。它取決於SOAP伺服器理解文檔語義並 執行正確的處理。事實上，伺服器提供了一種架構，以有意義的方式處理XML載 荷。這里的「有意義」意味著伺服器在某些後台資料庫上調用遠程過程，以為消 息報文中包含的股票-符號元素接收股票價格。所有這些魔術般的操作都是在SOAP RPC幕後發生的。
編輯本段SOAP-RPC
SOAP消息本質上是一種從發送方到接收方的單向傳輸，但是SOAP經常組合到實 現請求/響應機制中。要讓RPC使用SOAP，必須遵循幾條規則。首先，請求和響應 消息必須被編碼成結構類型。對一個操作的每一個輸入參數，都必須有一個同名 元素（或輸入結構的成員）作為參數。對每一個輸出參數，都必須有一個名稱匹 配的元素（或輸出結構的成員）。 基於RPC的觀點，會省略一些更早一點顯示的SOAP消息。只帶有報文部分的 SOAP請求與響應封套如下所示： 請求 DEF響應 22.50請求要調用GetLastTradePrice方法。注意響應定義了 GetLastTradePriceResponse操作。對附加響應到響應操作尾部的 一個常用的SOAP調用規則是：創建響應結構。這種輸出結構包含一個名稱為 price的元素，它返回方法調用的結果，假定為浮點型。 在SOAP封套中沒有什麼地方的數據類型是顯式聲明的，注意到這一點很重要， 這樣如果只查看SOAP消息，就不會知道符號類型或結果參數price（價格）的類 型。客戶端應用程序一般通過「Section 5」編碼定義數據類型，或通過與伺服器 私下達成的協議來定義數據類型。在任何一種情況下，這些包含在SOAP消息中的 定義都不是顯式的。 最後，為了進行RPC，需要一種低級協議如HTTP。盡管SOAP 1.0規范強制要求 使用HTTP作為傳輸協議，但SOAP 1.1規范（及其姊妹規范「帶有附件的SOAP消息」 ）允許使用FTP、SMTP、甚至（可能）原始的TCP/IP套接字。所有這些對SOAP通用 的序列化和編碼規則，也適用於RPC參數。
編輯本段SOAP用例
Internet上某些地方的客戶端應用程序使用Web服務。 Web服務（通過SOAP）顯示對象方法。 對象方法訪問Web上任意位置的遠程數據。 對這些網路命題應用傳遞邏輯，我們可以為Web服務和SOAP下一個總的結論： 某些位置的客戶端可以使Web上任意位置的數據。這就是所要證明的。 下面是更加詳細一點的用例。 SOAP客戶端使用UDDI注冊來查找Web服務。不用直接操作WSDL，大多數情況下SOAP應用程序將硬連接到使用特定類型的埠和特定樣式的綁定，並且它將 通過UDDI動態配置要調用的、與發現的Web服務匹配的服務地址。 客戶端應用程序創建SOAP消息，它是一個可執行想要的請求/響應操作的 XML文檔。 客戶端把SOAP消息傳送給監聽SOAP請求的Web伺服器上的JSP或ASP頁面。 SOAP伺服器解析SOAP包並在其領域調用合適的對象方法，在SOAP文檔中包 含的參數中傳遞。在SOAP伺服器接收消息之前，中間處理節點可以執行SOAP報 頭指示的特殊功能，可視情況確定是否執行這步操作。 請求對象執行指示的功能，並返回數據給SOAP伺服器，它把響應打包到 SOAP封套中。伺服器把SOAP封套包裹在要發送回請求機器的響應對象中，如 servlet或COM對象。 客戶端接收對象，剝離出SOAP封套並把響應文檔發送給最初發出請求的程 序，完成請求/響應循環。
編輯本段小結
SOAP是一種基於XML的協議，它用於在分布式環境中發送消息，並執行遠程過 程調用。使用SOAP，不用考慮任何特定的傳輸協議（盡管通常選用HTTP協議）， 就能使數據序列化。用SOAP來構建平台與語言中性的互操作系統是一個好的選擇。總之，SOAP和 Web服務已為在XML上構建分布式應用程序基礎結構所需的一切都考慮好了。通過解決COM和java組件對象模型之間的沖突，SOAP把多個平台在訪問數據時所出現的 不兼容性問題減至最少。先把這些討論放在一邊，SOAP是一種適用於所有類型的對象實體的理想的媒介 即使對於像Brad Pitt和Edward Norton之類的好萊塢電影角色也可用作 一種通信媒介。就像在電影中一樣，期待著這種新技術帶來震撼世界的效果。

2. server 中的soap是什麼

中文名：簡單面向對象訪問協議
SOAP 是微軟 .net 架構的關鍵元素，用於未來的網際網路應用程序開發。
對於應用程序開發來說，使程序之間進行網際網路通信是很重要的。

目前的應用程序通過使用遠程過程調用（RPC）在諸如 DCOM 與 CORBA 等對象之間進行通信，但是 HTTP 不是為此設計的。RPC 會產生兼容性以及安全問題；防火牆和代理伺服器通常會阻止此類流量。

通過 HTTP 在應用程序間通信是更好的方法，因為 HTTP 得到了所有的網際網路瀏覽器及伺服器的支持。SOAP 就是被創造出來完成改昌盯這個任務的。

SOAP 提供了一種標準的方法，使得運行在不同的操作系統並使用不同的技術和編程語言的應用程序可以互相進行通信。

在微軟的這項技術中，最核和直接的表現就是webservice，基於跨平台訪問。在服務端建立相應的方法，在網際網路上進行訪問，雙方運用xml進行數據交迅歲互

在.net 3.0之後，新的技術逐漸由面向對象編程轉向面向服務編程。如WCF,ADO.NET Dataservice等等，都是基於服務，與平台無關的分布式數據訪問模式。

3. 初步理解一下：SOA, SOAP, Web Service, WSDL等

什麼是SOA、SOAP?

SOA到底是什麼？

SOA（Service-Oriented Architecture）的定義是面向服務的架構，就是說將軟體按照功能設計成一個個服務，這些服務用標準的方式定義介面、並通過標準的協議進行調用。 SOA所定義的介面和調用方式是獨立於編程語言和運行平台的，廣義上講SOA可以基於不同的底層技術實現，比如CORBA和Web Services。但CORBA由於過於復雜和臃腫已很少使用，所以目前所說的SOA絕大多數是基於Web Services技術實現。在Web Services的實現方式下，SOA服務的介面用XML進行定義。

在SOA架構下，軟體開發從業務流程分析開始，使用組件化業務建模的方法識別和分析各種業務模型，將各種實踐融入其中，在這個基礎上建立用例，用例直接產 生BPEL，這些BPEL則可以被融入一個服務整合框架中，其描述了各種服務的信息，從而把ESB上的各個模塊統一起來，形成一個巨大的服務倉。

將中間層再進行抽離，在中間層作一個跨技術架構的元數據和業務邏輯，使之成為跨技術架構的、可長期繼承、並不斷積累的企業業務庫和最寶貴的信息資產，也就 是面向服務的組件庫，而且這個服務組件庫也可以被其它企業復用，且不依賴於任何一種技術架構。誇張一點說，如果所有軟體企業都使用SOA架構，那麼世界軟 件業將會發生徹底的改變。顯然，這樣一個框架不是一種產品，也不僅僅是一種技術，而是一種解決問題的方法論。

SOA可能應用於兩個場景：第一種是業務互通互聯；第二種是封閉交易系統，即將元數據和業務邏輯抽離，形成可復用。舉個例子，在第一種場景中，當不同企業 之間的業務需要相互調用，這時就可能採用SOA技術；在第二種場景中，在企業內部需要將系統進行遷移時，利用SOA技術定義的原有數據和業務流程，可以很 快完成。

SOA並不是一個新事物，IT組織已經成功建立並實施SOA應用軟體很多年了，BEA、IBM、等廠商看到了它的價值，紛紛跟進。SOA的目標在於讓IT 變得更有彈性，以更快地響應業務單位的需求，實現實時企業（Real-Time Enterprise，這是Gartner為SOA描述的願景目標）。而BEA的CIO Rhonda早在2001年6月就提出要將BEA的IT基礎架構轉變為SOA，並且從對整個企業架構的控制能力、提升開發效率、加快開發速度、降低在客戶 化和人員技能的投入等方面取得了不錯的成績。

SOA是在計算環境下設計、開發、應用、管理分散的邏輯（服務）單元的一種規范。這個定義決定了SOA的廣泛性。SOA要求開發者從服務集成的角度來設計 應用軟體，即使這么做的利益不會馬上顯現。SOA要求開發者超越應用軟體來思考，並考慮復用現有的服務，或者檢查如何讓服務被重復利用。SOA鼓勵使用可 替代的技術和方法（例如消息機制），通過把服務聯系在一起而非編寫新代碼來構架應用。經過適當構架後，這種消息機制的應用允許公司僅通過調整原有服務模式 而非被迫進行大規模新的應用代碼的開發，使得在商業環境許可的時間內對變化的市場條件做出快速的響應。

SOA也不僅僅是一種開發的方法論--它還包含管理。例如，應用SOA後，管理者可以方便的管理這些搭建在服務平台上的企業應用，而不是管理單一的應用模 塊。其原理是，通過分析服務之間的相互調用，SOA使得公司管理人員方便的拿到什麼時候、什麼原因、哪些商業邏輯被執行的數據信息，這樣就幫助了企業管理 人員或應用架構師迭代地優化他們的企業業務流程、應用系統。

SOA的一個中心思想就是使得企業應用擺脫面向技術的解決方案的束縛，輕松應對企業商業服務變化、發展的需要。企業環境中單個應用程序是無法包容業務用戶 的（各種）需求的，即使是一個大型的ERP解決方案，仍然不能滿足這個需求在不斷膨脹、變化的缺口，對市場快速做出反應，商業用戶只能通過不斷開發新應 用、擴展現有應用程序來艱難的支撐其現有的業務需求。通過將注意力放在服務上，應用程序能夠集中起來提供更加豐富、目的性更強的商業流程。其結果就是，基 於SOA的企業應用系統通常會更加真實地反映出與業務模型的結合。服務是從業務流程的角度來看待技術的--這是從上向下看的。這種角度同一般的從可用技術 所驅動的商業視角是相反的。服務的優勢很清楚：它們會同業務流程結合在一起，因此能夠更加精確地表示業務模型、更好地支持業務流程。相反我們可以看到以應 用程序為中心的企業應用模型迫使業務用戶將其能力局限為應用程序的能力。

企業流程（enterprise process）是流經企業框架的空氣，它賦予業務模型里的組件以生命，並更加清晰地定義了它們之間的關系。流程定義了同業務模型進行交互操作的專門方 法。例如，會計可能是企業服務系統的一個組件--但是將發票寄給客戶卻是一個業務流程。服務被定義用來支持業務流程，因而貫穿整個流程始終的是：各種服務 組件在流程和邏輯實現過程中的裝配操作。理解業務流程是定製服務的關鍵所在。

有利於企業業務的集成傳統的應用集成方法（點對點集成、企業消息匯流排或中間件的集成（EAI）、基於業務流程的集成）都很復雜、昂貴，並且不靈活。這些集 成方法難於快速適應基於企業現代業務變化不斷產生的需求。基於面向服務架構 (SOA) 的應用開發和集成可以很好的解決其中的許多問題。

SOA 描述了一套完善的開發模式來幫助客戶端應用連接到服務上。這些模式定製了系列機制用於描述服務、通知及發現服務、與服務進行通信。

不同於傳統的應用集成方法，在 SOA 中，圍繞服務的所有模式都是以基於標準的技術實現的。大部分的通信中間件系統，如 RPC、CORBA、DCOM、EJB 和 RMI，也同樣如此。可是它們的實現都不是很完美的，在權衡交互性以及標準定製的可接受性方面總是存在問題。SOA 試圖排除這些缺陷。因為幾乎所有的通信中間件系統都有固定的處理模式，如RPC 的功能、CORBA 的對象等等。然而，服務既可以定義為功能，又可同時對外定義為對象、應用等等。這使得 SOA 可適應於任何現有系統，並使得系統在集成時不必刻意遵循任何特殊定製。

SOA 幫助企業信息系統遷移到"leave-and-layer"架構之上，這意味著在不用對現有的企業系統做修改的前提下，系統可對外提供 Web 服務介面，這是因為它們已經被可以提供 Web 服務介面的應用層做了一層封裝，所以在不用修改現有系統架構的情況下，SOA 可以將系統和應用迅速轉換為服務。SOA 不僅覆蓋來自於打包應用、定製應用和遺留系統中的信息，而且還覆蓋來自於如安全、內容管理、搜索等 IT 架構中的功能和數據。因為基於 SOA 的應用能很容易地從這些基礎服務架構中添加功能，所以基於SOA的應用能更快地應對市場變化，為使企業業務部門設計開發出新的功能應用。

Soap是什麼？

SOAP 是Simple Object Access Protocol（簡單對象訪問協議）的縮寫。

SOAP是一個用於分布式環境的、輕量級的、基於XML進行信息交換的通信協議.

對於Soap的理解：

第一步理解：SOAP＝HTTP＋XML

第二步理解：SOAP把XML的使用代碼化為請求和響應參數編碼模式，並用HTTP作傳輸。

SOAP是把成熟的基於HTTP的WEB技術與XML的靈活性和可擴展性組合在了一起。

第三步理解：具體地講，一個SOAP實現可以簡單地看作遵循SOAP編碼規則的HTTP請求和響應。

注意：SOAP 是一個協議，與編程語言無關。實際上，許多語言已經開始支持 SOAP，如：Java，C，C＋＋以及JavaScript。

Soap的起源？Soap解決的問題？

SOAP最初由微軟發起研究，用以解決MTS/COM資源消耗大，不夠輕巧等問題，後逐漸被IBM等巨頭接納並加入研究，現已提交W3C，成為Web Service應用傳輸標准。SOAP技術主要用於實現大量異構程序和平台之間的互操作性，從而使存在的應用能夠被廣泛的用戶所訪問。

SOAP意思是簡單對象訪問協議（Simple Object Access Protocol）。的確如它的名字一樣，SOAP是很簡單的。它是一個基於XML的協議，允許程序組件和應用程序彼此使用一種標準的Internet協 議--HTTP來通訊。SOAP是一種獨立的平台，它不依賴程序語言，它是簡單的，彈性的，很容易擴展的。目前，應用程序能夠彼此使用一種基於DCOM和 CORBA技術的遠程過程調用（RPC）來進行相互通訊，但HTTP不被設計為這個目的。RPC在Internet上應用是非常困難的，它們會出現許多兼 容性和安全性的問題，因為防火牆和代理伺服器通常都會阻斷（block）這些類型的流量。應用程序之間最好的通訊方式是通過HTTP協議，因為HTTP是 支持所有Internet瀏覽器和伺服器的。基於這個目的，SOAP協議被創建出來。

SOAP（Simple Object Access Protocol ）簡單對象訪問協議是在分散或分布式的環境中交換信息的簡單的協議，是一個基於XML的協議，它包括四個部分：SOAP封裝(envelop)，封裝定義 了一個描述消息中的內容是什麼，是誰發送的，誰應當接受並處理它以及如何處理它們的框架；SOAP編碼規則（encoding rules），用於表示應用程序需要使用的數據類型的實例; SOAP RPC表示(RPC representation)，表示遠程過程調用和應答的協定;SOAP綁定（binding），使用底層協議交換信息。

雖然這四個部分都作為SOAP的一部分，作為一個整體定義的，但他們在功能上是相交的、彼此獨立的。特別的，信封和編碼規則是被定義在不同的XML命名空間(namespace)中，這樣使得定義更加簡單。

什麼是CXF？

Apache CXF = Celtix + XFire，Apache CXF 的前身叫 Apache CeltiXfire，現在已經正式更名為 Apache CXF 了，以下簡稱為 CXF。CXF 繼承了 Celtix 和 XFire 兩大開源項目的精華，提供了對 JAX-WS 全面的支持，並且提供了多種 Binding 、DataBinding、Transport 以及各種 Format 的支持，並且可以根據實際項目的需要，採用代碼優先（Code First）或者 WSDL 優先（WSDL First）來輕松地實現 Web Services 的發布和使用。目前它仍只是 Apache 的一個孵化項目。

Apache CXF 是一個開源的 Services 框架，CXF 幫助您利用 Frontend 編程 API 來構建和開發 Services ，像 JAX-WS 。這些 Services 可以支持多種協議，比如：SOAP、XML/HTTP、RESTful HTTP 或者 CORBA ，並且可以在多種傳輸協議上運行，比如：HTTP、JMS 或者 JBI，CXF 大大簡化了 Services 的創建，同時它繼承了 XFire 傳統，一樣可以天然地和 Spring 進行無縫集成。

CXF 包含了大量的功能特性，但是主要集中在以下幾個方面：

支持 Web Services 標准：CXF 支持多種 Web Services 標准，包含 SOAP、Basic Profile、WS-Addressing、WS-Policy、WS-ReliableMessaging 和 WS-Security。

Frontends：CXF 支持多種「Frontend」編程模型，CXF 實現了 JAX-WS API （遵循 JAX-WS 2.0 TCK 版本），它也包含一個「simple frontend」允許客戶端和 EndPoint 的創建，而不需要 Annotation 註解。CXF 既支持 WSDL 優先開發，也支持從 Java 的代碼優先開發模式。

容易 使用： CXF 設計得更加直觀與容易使用。有大量簡單的 API 用來快速地構建代碼優先的 Services，各種 Maven 的插件也使集成更加容易，支持 JAX-WS API ，支持 Spring 2.0 更加簡化的 XML 配置方式，等等。

支持二進制和遺留協議：CXF 的設計是一種可插撥的架構，既可以支持 XML ，也可以支持非 XML 的類型綁定，比如：JSON 和 CORBA。

我們來利用cxf創建一個簡單的webservice吧。

首先cxf 所需要的包：更具網站說明以下的包都是必須的，但是在我的實際項目中紅色部分的包並沒有用到。

大家可更具自己需求來添加適應的包。

cxf.jar

commons-logging.jar

geronimo-activation.jar (Or the Sun equivalent)//

geronimo-annotation.jar (Or the Sun equivalent)//

geronimo-javamail.jar (Or the Sun equivalent)//

neethi.jar

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協議來通信。這是因為任何運行Web瀏覽器的機器都在使用HTTP協議。同時，當前許多防火牆也配置為只允許HTTP連接。

許多商用程序還面臨另一個問題，那就是與其他程序的互操作性。如果所有的應用程序都是使用COM或.NET語言寫的，並且都運行在Windows平台上， 那就天下太平了。然而，事實上大多數商業數據仍然在大型主機上以非關系文件(VSAM)的形式存放，並由COBOL語言編寫的大型機程序訪問。而且，目前 還有很多商用程序繼續在使用C++、Java、Visual Basic和其他各種各樣的語言編寫。現在，除了最簡單的程序之外，所有的應用程序都需要與運行在其他異構平台上的應用程序集成並進行數據交換。這樣的任 務通常都是由特殊的方法，如文件傳輸和分析，消息隊列，還有僅適用於某些情況的的API，如IBM的"高級程序到程序交流(APPC)"等來完成的。在以 前，沒有一個應用程序通信標准，是獨立於平台、組建模型和編程語言的。只有通過Web Service，客戶端和伺服器才能夠自由的用HTTP進行通信，不論兩個程序的平台和編程語言是什麼。

什麼是WebService?

Web services是建立可互操作的分布式應用程序的新平台。作為一個Windows程序員，你可能已經用COM或DCOM建立過基於組件的分布式應用程序。COM是一個非常好的組件技術，但是我們也很容易舉出COM並不能滿足要求的情況。

Web service平台是一套標准，它定義了應用程序如何在Web上實現互操作性。你可以用任何你喜歡的語言，在任何你喜歡的平台上寫Web service ，只要我們可以通過Web service標准對這些服務進行查詢和訪問。

Web service平台需要一套協議來實現分布式應用程序的創建。任何平台都有它的數據表示方法和類型系統。要實現互操作性，Web service平台必須提供一套標準的類型系統，用於溝通不同平台、編程語言和組件模型中的不同類型系統。在傳統的分布式系統中，基於界面 (interface)的平台提供了一些方法來描述界面、方法和參數（譯註：如COM和COBAR中的IDL語言）。同樣的，Web service平台也必須提供一種標准來描述Web service，讓客戶可以得到足夠的信息來調用這個Web service。最後，我們還必須有一種方法來對這個Web service進行遠程調用。這種方法實際是一種遠程過程調用協議(RPC)。為了達到互操作性，這種RPC協議還必須與平台和編程語言無關。

Web Service 是一種新的web應用程序分支，他們是自包含、自描述、模塊化的應用，可以發布、定位、通過web調用。Web Service可以執行從簡單的請求到復雜商務處理的任何功能。一旦部署以後，其他Web Service應用程序可以發現並調用它部署的服務。

Web Service是一種應用程序，它可以使用標準的互聯網協議，像超文本傳輸協議(HTTP)和XML，將功能綱領性地體現在互聯網和企業內部網上。可將Web服務視作Web上的組件編程。

1 歷史

web廣泛用到的技術：

◆TCP/IP：通用網路協議，被各種設備使用

◆HTML：通用用戶界面，可以使用HTML標簽顯示數據

◆Java：寫一次可以在任何地方運行的通用編程語言

◆XML ：通用數據表達語言，在web上傳送機構化數據的容易方法

他們的特點是其開放性，跨平台性，開放性正是Web services的基礎。

2 Web發展的趨勢

內容更動態化

◆帶寬Bandwidth更便宜，易於獲得

◆存儲器Storage更便宜，更易獲得

◆普遍式計算變得更加重要：大量的設備，例如行動電話，頁面，電腦，pc，已經在Internet上變得普遍，平台變得更多元化，象XML這樣的跨平台技術變得更重要

3 Web Services扮演什麼角色？

上述的這些趨勢意味著，更加智能的處理，操作和匯總內容變得十分重要。讓我們看看按照Web services角度所預示的四個趨勢：

◆內容更加動態：一個web service必須能合並從多個不同源來的內容，可以包括股票，天氣，新聞等，在傳統環境中的內容，如存貨水平，購物訂單或者目錄信息等，都從後端系統而來

◆帶寬更加便宜：web services可以分發各種類型的內容（音頻，視頻流等）

◆存儲更便宜: web services必須能聰明地處理大量數據，意味著要使用資料庫，LDAP目錄，緩沖，和負載平衡軟體等技術保持可擴展能力

◆普遍式計算更重要：web services不能要求客戶使用某一版本的windows的傳統瀏覽器，必須支持各種設備，平台，瀏覽器類型，各種內容類型。

4 兩種重要技術

要達到這樣的目標，Web services要使用兩種技術：

◆XML XML是在web上傳送結構化數據的偉大方式，Web services要以一種可靠的自動的方式操作數據，HTML不會滿足要求，而XML可以使web services十分方便的處理數據，它的內容與表示的分離十分理想

◆SOAP SOAP使用XML消息調用遠程方法，這樣web services可以通過HTTP協議的post和get方法與遠程機器交互，而且，SOAP更加健壯和靈活易用。

其他象UDDI和WSDL技術與XML和SOAP技術緊密結合用於服務發現。</SPAN>

組成Web service平台的這三個技術。

XML和XSD

可擴展的標記語言(XML)是Web service平台中表示數據的基本格式。除了易於建立和易於分析外，XML主要的優點在於它既是平台無關的，又是廠商無關的。無關性是比技術優越性更重要的：軟體廠商是不會選擇一個由競爭對手所發明的技術的。

XML解決了數據表示的問題，但它沒有定義一套標準的數據類型，更沒有說怎麼去擴展這套數據類型。例如，整形數到底代表什麼？16位，32位，還是 64位？這些細節對實現互操作性都是很重要的。W3C制定的XML Schema(XSD)就是專門解決這個問題的一套標准。它定義了一套標準的數據類型，並給出了一種語言來擴展這套數據類型。Web service平台就是用XSD來作為其數據類型系統的。當你用某種語言(如VB.NET或C#)來構造一個Web service時，為了符合Web service標准，所有你使用的數據類型都必須被轉換為XSD類型。你用的工具可能已經自動幫你完成了這個轉換，但你很可能會根據你的需要修改一下轉換 過程。

WSDL

你會怎樣向別人介紹你的Web service有什麼功能，以及每個函數調用時的參數呢？你可能會自己寫一套文檔，你甚至可能會口頭上告訴需要使用你的Web service的人。這些非正式的方法至少都有一個嚴重的問題：當程序員坐到電腦前，想要使用你的Web service的時候，他們的工具(如Visual Studio)無法給他們提供任何幫助，因為這些工具根本就不了解你的Web service。解決方法是：用機器能閱讀的方式提供一個正式的描述文檔。Web service描述語言(WSDL)就是這樣一個基於XML的語言，用於描述Web service及其函數、參數和返回值。因為是基於XML的，所以WSDL既是機器可閱讀的，又是人可閱讀的，這將是一個很大的好處。一些最新的開發工具 既能根據你的Web service生成WSDL文檔，又能導入WSDL文檔，生成調用相應Web service的代碼。

4. REST和SOAP Web Service的區別比較

restful是一種架構風格，其核心是面向資源；而webService底層SOAP協議，主要核心是面向活動。

SOAP：簡單對象訪問協議，很輕量，同時作為應用協議可以基於多種傳輸協議來傳遞消息（Http,SMTP等）。

客戶端和伺服器端的通訊方式

總結：

REST對敏歷於資源型服務介面來說很合適，同時特別適合對於效率要求很高，但是對於安全要求不高的場景。而SOAP的成熟性可以給需要提供給多開發語言的，對於安全性要求較高的介面設計帶來便利。所以我覺得純粹說什麼設計模式將會占據主導地位沒有什麼意義，關鍵還是看應用場景。成熟度SOAP雖然發展到現在已經脫離了初衷，但是對於異構環境服務發布和調用，以及廠商的支持都已經達到了較為成熟的情況。不同平台，開發語言之間通過SOAP來交互的web service都能夠較好的互通。

5. soap和rest簡單比較整理

討論該問題的原因是之前有一次開會，討論到webservice的實施，我直接給出的結論是應該使用rest替換掉原來的soap介面，原因是soap"太重量級了"(其實我內心想的是rest的實現比soap簡單)但是當被問到怎麼"重量級"的時候又是說不出來的。因為這個詞'也是之前隨便搜搜得到的答案。因為好像很多人就是這么闡述他們的去別的。所以究竟他們有什麼不同呢，我簡單說一下我的理解。

1. 從定義上他們就是完全不同的，soap是一個協議，restful是一種架構風格，是直接基於http協議實現的。所以直接可以看出當你想實現webservice的時候，後者的實現是相對簡單的。soap相當於將要傳輸的內容又包了一層，都封裝在envelope裡面進行傳輸，而restful可以理解為發送的就是請求本身，是透明的。

2. 安全校驗: 通常的做法是當有從客戶端 Client2 發出的 HTTP 請求都經過代理伺服器 (Proxy Server)。代理伺服器制定安全策略：所有經過該代仿並理的訪問 User 和 User List 資源的請求只具有讀取許可權，即：允許 GET/HEAD 操作，而像具有寫許可權的 PUT/DELTE 是不被允許的。那麼如果是使用soap，那麼代理是沒有辦法確定它的請求類型的，因為之前講到的，soap的請求是被封裝過的，很難解析envelope裡面的請求類型。

3. 關於緩存，REST 的應用可以充升棗分地挖掘 HTTP 協議對緩存支持的能力。當客戶端第一次發送 HTTP GET 請求給伺服器獲得內容後，該內容可能被緩存伺服器 (Cache Server) 緩存。當下一次客戶端請求同樣的資源時，緩存可以直接給出響應，而吵大拆不需要請求遠程的伺服器獲得。而這一切對客戶端來說都是透明的。而soap還是我們提到的那個問題，無法知道請求類型。(默認soap使用的是post)。這一點在我們新要使用的webservice上極為重要，因為我們只提供一個get介面供用戶得到信息，且信息內容不會經常改變。而且更重要的事get比post要快。

參考文章:

http://www.importnew.com/24695.html

https://blog.csdn.net/wdeng2011/article/details/78274683

https://blog.csdn.net/yanbober/article/details/45308935

https://blog.csdn.net/zzk220106/article/details/78595108/(get vs post)

6. 什麼是 RESTful 到底 REST 和 SOAP，RPC 有何區別

第一個問題：什麼是RESTful？

REST這個詞，是Roy Thomas Fielding在他2000年的博士論文中提出的。有興趣可以看看這里論文`，誰是Fielding?點擊前面名字了解。

那RESTful到底是什麼呢？簡單的講，它是：一種架構設計風格，提供了設計原則和約束條件，而不是架構。而滿足這些約束條件和原則的應用程序或設計就是 RESTful架構或服務。

推薦閱讀：
張善友博客——REST 入門介紹

infoq——深入淺出REST

第二個問題：到底 REST 和 SOAP、RPC 有何區別？

這個問題比較大，要知道他們有什麼區別首先需要明白，他們分別是什鍵老么？

REST上面已經簡單的說明了它是什麼。

SOAP(簡單對象訪問協議)是什麼？SOAP是一種數據交換協議規范，是一種輕量的、簡單的、基於XML的協議的規范。它有什麼優點？簡單總結為： 易用，靈活，跨語言，跨平台。

易用：是因為它的消息是基於xml並封裝成了符合http協議，因此,它符合任何路由器、 防火牆或代理伺服器的要求。

靈活：表現在極具拓展性，SOAP 無需中斷已有的應用程序, SOAP 客戶端、 伺服器和協議自身都能發展。而且SOAP 能極好地支持中間介質和層次化的體系結構。

跨語言：soap可以使用任何語言來完成，只要發送正確的soap請求即可。

跨平台：基於soap的服務可以在任何平台無需修改即可稿哪升正常使用。

RPC(遠程調用框架) 是一種允許分布式應用程序調用網路上不同計算機的可用服務的機制。涉獵不多，一下省略256個字。有熟悉的朋友可以在評論補充，然後我會修改到該內容中去

從上面我們可以看出，REST 和 SOAP、RPC 有何區別呢？沒什麼太大區別，他們的本質都是提供可支持分布式的基礎服務，最大的區別在於他們各自的的特點所帶來的不同應用場緩慶景。

REST可以看著是http協議的一種直接應用，默認基於json作為傳輸格式，使用簡單，學習成本低效率高，~~但是安全性較低~~，而SOAP可以看著是一個重量級的協議，基於xml，SOAP在安全方面是通過使用XML-Security和XML-Signature兩個規范組成了WS-Security來實現安全控制的，當前已經得到了各個廠商的支持，.net ，php ，java 都已經對其有了很好的支持 。這是REST薄弱的地方。

7. soap 和webservice的區別

SOAP簡單的理解，就是這樣的一個開放協議SOAP=RPC+HTTP+XML：採用HTTP作為底層通訊協議；RPC作為一致性的調拆檔中用途徑，XML作為數據傳送的格式，允許服務提供者和服務客戶經過防火牆在INTERNET進行通訊交互。RPC的描敘可能不大准確，因為SOAP一開始構思就是要實現平台與環境的無關性和獨立性，每一個通過網路的遠程調用都可以通過SOAP封裝起來，包括DCE（Distributed Computing Environment ）RPC CALLS，COM/DCOM CALLS, CORBA CALLS, JAVA CALLS，etc。

SOAP 使用 HTTP 傳送 XML，盡管HTTP 不是有效率的通訊協議，而且 XML 還需要額外的文件解析（parse），兩者使得交易的速度大大低於其它方案。但是XML 是一個開放、健全、有語義的訊息機制，而 HTTP 是一個廣泛又能避免許多關於防火牆的問題，從而使SOAP得到了廣泛的應用。但是如果效率對你來說很重要，那麼你應該多考慮其它的方式，而不要用 SOAP。

為了更好的理解SOAP,HTTP,XML如何工作的，不妨先考慮一蠢世下COM/DCOM的運行機制，DCOM處理網路協議的低層次的細節問題旅山，如PROXY/STUB間的通訊，生命周期的管理，對象的標識。在客戶端與伺服器端進行交互的時候，DCOM採用NDR（Network Data Representation）作為數據表示，它是低層次的與平台無關的數據表現形式。