导读：
1.SOAP也被称作XMLP，为两个程序交换信息提供了一种标准的工作机制。在各类机构之间通过电子方式相互协作的情况下完全有必要为此制定相应的标准。
交换信息可以采用很多方法，比如电子邮件、即时聊天和远程过程调用（RPC）等。电子邮件和聊天消息通常不具备计算机友好性。计算机可以读取电子邮件报头，但是其类型内容却无法得到计算机这个"硅脑袋"的理解。即时聊天和RPC也面临同样的尴尬情况：计算机倒是可读可人又没法读了。
计算机确实知道如何理解XML。SOAP描述了把消息捆绑为XML的工作方式。它还说明了发送消息的发送方、消息的内容和地址以及发送消息的时间。这也是为什么把SOAP叫做一种协议的原因。SOAP并没有同电子邮件协议（SMTP）、RPC（套接字和IDL）或者Web协议（HTTP）截然分开。SOAP要利用这些系统作为消息的起点。
2.SOAP是Web Service的基本通信协议。因为SOAP与DCOM和CORBA在概念上有相同之处，所以很多人在问："SOAP是怎样激活对象的？"或"SOAP在使用什么命名服务（Naming Service）？"。或许在执行SOAP的过程当中会用到这些，但这些并不在SOAP规范要考虑的范畴之内。SOAP只是定义SOAP消息的XML格式（XML Format），如果你用一对SOAP标记（SOAP Elements）把XML文档括起来，那么这个就是一个SOAP消息，这不是很简单吗？
3.SOAP规范还定义了怎样用XML来描述程序数据（Program Data）,怎样执行RPC（Remote Procedure Call）。这些可选的规范是为了构建RPC-style的应用程序（客户端SOAP消息包含函数名和在函数中用到的参数，而服务器端SOAP消息包含执行函数之后的结果）。大多数SOAP解决方案都支持RPC-style应用程序，因为很多程序员已对DCOM或CORBA熟悉。SOAP还支持Document-style应用程序（SOAP消息只包含XML文本信息）。Document-style应用程序有很好的灵活性，所以很多用RPC很难构建的Web Service用这种方式构建。
1.最后SOAP规范还定义了HTTP消息是怎样传输SOAP消息的。这并不代表SOAP只能用HTTP来作为传输协议，MSMQ、SMTP、TCP/IP都可以做SOAP的传输协议。
很多大公司根据SOAP规范，都开发出了自己的SOAP解决方案。这些解决方案都是相对于某种语言。比如说Microsoft SOAP toolkit2.0把COM函数转换成SOAP消息，而Apache toolkit把JAVA函数转换成SOAP消息。这样难免带来一些兼容性问题。
现在SOAP的很多另人瞩目的特性已成为现实（SOAP已经运行于不同的硬件和软件平台），而且有70多个解决方案。之所以SOAP被人们所爱戴，是因为SOAP比其他同类技术（CORBA、DCE）简单易用。
安全性对于应用程序来说是很重要的。那么SOAP的安全性如何呢？对于把HTTP作为传输协议的SOAP来说是没有问题的，因为HTTP协议已经有很好的安全构架。那么用其他传输协议会出现安全问题吗？不是的，你不必担心，因为已经有这方面的规范了（http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-security.asp）。
2.簡易物件存取協定
Simple Object Access Protocol (SOAP)
作者: 恆逸資訊 胡百敬
什麼是簡易物件存取協定(SOAP)，簡而言之就是利用現存的網際網路架構讓應用程式之間可以彼此溝通，而不會被防火牆阻礙。在分散式的架構下，使用 XML 的環境中，SOAP提供兩個電腦系統之間交換的架構與資料型別。
在過去五年來透過網際網路存取已經變成是較進步社會的基礎需求。在其上執行著各式各樣的通訊協定。但是直至目前為止最廣泛被接受的通訊協定依然是Hypertext Transfer Protocol(HTTP)，它是瀏覽器與Web伺服器之間溝通時使用，對於文字、圖形以及其他資訊的傳輸很有效率與彈性，而且它簡單易懂。
你我所撰寫的應用程式利用網際網路在遠端互動已經變得越來越重要。現今在網際網路上提供eService已經是大勢所趨。舉個例子來說，你可能在某一家網路公司所提供的行事曆上註冊，當快遞公司要送貨品給你時，它的系統會自動與提供行事曆的網路公司合作，查閱你的在家的時間，自動排定送貨的行程。或著是你想寫一個入門網站，但覺得某個網站所提供的交通資訊或是天氣預報系統很好，你想直接讓你的使用者透過系統之間的合作，可以在你的網站線上查詢別的網站上這些資料。而那些提供服務的網站也可以查詢的次數向你收費。
以上這些動作都需要系統自動完成合作，不再有人工參與。且彼此的系統是各自以他所熟悉的技術完成，這代表著系統不會遵循特殊的架構。有可能我的系統是Win32，使用的是COM+﹔而你的是UNIX作業系統，利用CORBA提供服務。
讓兩個系統透過網際網路溝通，僅僅用HTTP通訊協定本身提供的功能是不夠的，雖然HTTP本身的彈性很大，但它基本的設計並不適合呼叫遠端的程式物件。這種互動在區域網路內一般是使用Remote Procedure Call(RPC)，也就是使用者端傳出一些參數，並由伺服端回傳一些結果。
現今已有許多分散式物件通訊協定(distributed object protocols) 提供遠端程式間的溝通。例如微軟的Distribured Component Object Model(DCOM)、Object Management Group的Internet Inter-ORB Protocol(IIOP)等等。所有這些服務都提供相同的服務，也就是讓使用者端可以觸發RPC到伺服端應用程式，並接到回傳結果。 在企業內部網路(Intranet)上使用分散式物件傳輸協定有很好的效果。但在公眾的網際網路上使用這些協定就有很多問題。任何連上網際網路的伺服器基本上都可以被任何網際網路的使用者存取，這導致需要較嚴謹的安全考量。為了安全，大部分的企業都在它們內部與外部網路之間加裝防火牆以防止網際網路上的大眾存取企業內部的伺服器。這些防火牆，例如微軟的Proxy伺服器，可以經由條件設定以阻止一些想進企業內部來的公眾網路需求，這可以大幅提昇內部系統的安全。
雖然防火牆是提供接上網際網路安全的基礎機制，但它卻會降低分散式物件通訊協定的使用效能。為了要解決這個問題，有識之士紛紛提出了各自的解決方案。在 1998 年，UserLand 公司的執行總裁 Dave Winner 提出透過 XML 讓 RPC 的通訊方式透過 HTTP 協定在網際網路上執行。
這個想法經由微軟公司加以改良，提出了實際可行的Simple Object Access Protocol(SOAP)通訊協定。現今正在W3C審議中，已經有IBM等大廠表態支持。不久的未來即將可能成為在網際網路上提供電子服務的標準協定。
SOAP是一個像DCOM或其他分散式物件通訊協定的協定，讓使用者端與伺服端的RPCs可以溝通。但與其他類似協定不一樣的地方是，它支援防火牆的使用。同樣重要地，SOAP不是只設計用來針對某種物件技術的協定，它不像一些時下的分散式物件通訊協定會被綁死在某一種特定的物件規格上，這個協定將可以被任何的物件使用。所以它將是兩大物件陣營COM 和 CORBA 最好的溝通橋樑，讓彼此的物件程式可以跨平台透過網際網路呼叫。
簡易物件存取協定如其名稱所言，要求定義要"簡易"，所以它只訂出物件溝通基礎規範，如
讓物件透過網際網路提出需求的方式標準化，以 HTTP 當傳輸的方式，以 XML 描述溝通的內容
建立可延伸的傳遞物件呼叫格式的承載 但它不定義一些一般分散式物件系統需要定義的
分散式系統資源回收(garbage collection)
雙向的 HTTP 溝通
物件參照
物件初始化
以上這些不明確定義的規格都交由各系統廠商自行實作。
使用防火牆所造成的問題以及 SOAP 所提供的解決方案
要了解為何防火牆會造成分散式物件通訊協定的問題必須先了解到防火牆是如何分辨協定之間的不同。在TCP/IP的架構下，每一個被廣泛使用的協定都被賦予一個特殊的埠號(port number)而每一個使用該協定的需求封包都帶著這個埠號。例如HTTP協定的埠號是80、FTP是21等等。大部分的防火牆可以用來防止某個特殊協定的方式就是針對埠號拒絕某種協定的通訊。通常防火牆是被設定成允許埠號80的運作的-如果該公司不拒絕使用HTTP的話。
但大部分的防火牆會擋住其他的埠，因為它們假定利用其他的埠對公司內部網路的運作都是有危險的。 但這也正是造成分散式物件通訊協定無法運行的原因。不像HTTP、FTP等其他著名的通訊協定，分散式物件通訊協定通常沒有使用一個著名的大家都知道的埠號來溝通。相反地，這些通訊協定通常動態地被賦予埠號，埠號碼在被需求時任意產生。如果沒有防火牆擋在使用者端與伺服端之間，這種方式將可以很有效地運作。但若加了防火牆，則該通訊協定會因為防火牆不允許兩端任意使用任何埠號來溝通而中斷。
當下存在很多種解決方式，例如某些防火牆可以被設定成允許某個範圍的埠號碼可以進行溝通。若該分散式物件通訊協定也可以被設定成只用這個範圍的埠號碼，則這個方案便可行，使用者端與伺服端之間可以進行溝通。但比較注重安全的網路管理者將不會贊成開放任意一組埠號碼而導致這個方案並不完美。另一個選擇是採用COM網際網路服務，這讓傳統的DCOM封包在TCP上透過埠號80來傳遞。這在某些方面很有用，但這項技術只有微軟的Internet Information Server和DCOM在使用，而不是一項完整的解決方案，所以我們需要一個更普遍一般性的解決方案。
因為幾乎所有的防火牆都允許透過埠號80來溝通，所以透過埠號80來溝通的分散式物件通訊協定將是一個較好的方案。但這並不是說說那麼容易，因為埠號80已經被設定給HTTP協定。所以SOAP這個分散式物件通訊協定是架在HTTP協定之上的。HTTP通訊協定相當簡單，僅僅以少數基礎的動詞所組成，如GET、PUT、POST等等，而這些動詞在瀏覽器與伺服器之間傳遞。而每一個動詞之後跟著一些資訊，而這些資訊通常以簡易的字串方式傳遞。
本文转自
http://www.tianyablog.com/blogger/post_show.asp?BlogID=360358&PostID=4267254
1.SOAP也被称作XMLP，为两个程序交换信息提供了一种标准的工作机制。在各类机构之间通过电子方式相互协作的情况下完全有必要为此制定相应的标准。
交换信息可以采用很多方法，比如电子邮件、即时聊天和远程过程调用（RPC）等。电子邮件和聊天消息通常不具备计算机友好性。计算机可以读取电子邮件报头，但是其类型内容却无法得到计算机这个"硅脑袋"的理解。即时聊天和RPC也面临同样的尴尬情况：计算机倒是可读可人又没法读了。
计算机确实知道如何理解XML。SOAP描述了把消息捆绑为XML的工作方式。它还说明了发送消息的发送方、消息的内容和地址以及发送消息的时间。这也是为什么把SOAP叫做一种协议的原因。SOAP并没有同电子邮件协议（SMTP）、RPC（套接字和IDL）或者Web协议（HTTP）截然分开。SOAP要利用这些系统作为消息的起点。
2.SOAP是Web Service的基本通信协议。因为SOAP与DCOM和CORBA在概念上有相同之处，所以很多人在问："SOAP是怎样激活对象的？"或"SOAP在使用什么命名服务（Naming Service）？"。或许在执行SOAP的过程当中会用到这些，但这些并不在SOAP规范要考虑的范畴之内。SOAP只是定义SOAP消息的XML格式（XML Format），如果你用一对SOAP标记（SOAP Elements）把XML文档括起来，那么这个就是一个SOAP消息，这不是很简单吗？
3.SOAP规范还定义了怎样用XML来描述程序数据（Program Data）,怎样执行RPC（Remote Procedure Call）。这些可选的规范是为了构建RPC-style的应用程序（客户端SOAP消息包含函数名和在函数中用到的参数，而服务器端SOAP消息包含执行函数之后的结果）。大多数SOAP解决方案都支持RPC-style应用程序，因为很多程序员已对DCOM或CORBA熟悉。SOAP还支持Document-style应用程序（SOAP消息只包含XML文本信息）。Document-style应用程序有很好的灵活性，所以很多用RPC很难构建的Web Service用这种方式构建。
1.最后SOAP规范还定义了HTTP消息是怎样传输SOAP消息的。这并不代表SOAP只能用HTTP来作为传输协议，MSMQ、SMTP、TCP/IP都可以做SOAP的传输协议。
很多大公司根据SOAP规范，都开发出了自己的SOAP解决方案。这些解决方案都是相对于某种语言。比如说Microsoft SOAP toolkit2.0把COM函数转换成SOAP消息，而Apache toolkit把JAVA函数转换成SOAP消息。这样难免带来一些兼容性问题。
现在SOAP的很多另人瞩目的特性已成为现实（SOAP已经运行于不同的硬件和软件平台），而且有70多个解决方案。之所以SOAP被人们所爱戴，是因为SOAP比其他同类技术（CORBA、DCE）简单易用。
安全性对于应用程序来说是很重要的。那么SOAP的安全性如何呢？对于把HTTP作为传输协议的SOAP来说是没有问题的，因为HTTP协议已经有很好的安全构架。那么用其他传输协议会出现安全问题吗？不是的，你不必担心，因为已经有这方面的规范了（http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-security.asp）。
2.簡易物件存取協定
Simple Object Access Protocol (SOAP)
作者: 恆逸資訊 胡百敬
什麼是簡易物件存取協定(SOAP)，簡而言之就是利用現存的網際網路架構讓應用程式之間可以彼此溝通，而不會被防火牆阻礙。在分散式的架構下，使用 XML 的環境中，SOAP提供兩個電腦系統之間交換的架構與資料型別。
在過去五年來透過網際網路存取已經變成是較進步社會的基礎需求。在其上執行著各式各樣的通訊協定。但是直至目前為止最廣泛被接受的通訊協定依然是Hypertext Transfer Protocol(HTTP)，它是瀏覽器與Web伺服器之間溝通時使用，對於文字、圖形以及其他資訊的傳輸很有效率與彈性，而且它簡單易懂。
你我所撰寫的應用程式利用網際網路在遠端互動已經變得越來越重要。現今在網際網路上提供eService已經是大勢所趨。舉個例子來說，你可能在某一家網路公司所提供的行事曆上註冊，當快遞公司要送貨品給你時，它的系統會自動與提供行事曆的網路公司合作，查閱你的在家的時間，自動排定送貨的行程。或著是你想寫一個入門網站，但覺得某個網站所提供的交通資訊或是天氣預報系統很好，你想直接讓你的使用者透過系統之間的合作，可以在你的網站線上查詢別的網站上這些資料。而那些提供服務的網站也可以查詢的次數向你收費。
以上這些動作都需要系統自動完成合作，不再有人工參與。且彼此的系統是各自以他所熟悉的技術完成，這代表著系統不會遵循特殊的架構。有可能我的系統是Win32，使用的是COM+﹔而你的是UNIX作業系統，利用CORBA提供服務。
讓兩個系統透過網際網路溝通，僅僅用HTTP通訊協定本身提供的功能是不夠的，雖然HTTP本身的彈性很大，但它基本的設計並不適合呼叫遠端的程式物件。這種互動在區域網路內一般是使用Remote Procedure Call(RPC)，也就是使用者端傳出一些參數，並由伺服端回傳一些結果。
現今已有許多分散式物件通訊協定(distributed object protocols) 提供遠端程式間的溝通。例如微軟的Distribured Component Object Model(DCOM)、Object Management Group的Internet Inter-ORB Protocol(IIOP)等等。所有這些服務都提供相同的服務，也就是讓使用者端可以觸發RPC到伺服端應用程式，並接到回傳結果。 在企業內部網路(Intranet)上使用分散式物件傳輸協定有很好的效果。但在公眾的網際網路上使用這些協定就有很多問題。任何連上網際網路的伺服器基本上都可以被任何網際網路的使用者存取，這導致需要較嚴謹的安全考量。為了安全，大部分的企業都在它們內部與外部網路之間加裝防火牆以防止網際網路上的大眾存取企業內部的伺服器。這些防火牆，例如微軟的Proxy伺服器，可以經由條件設定以阻止一些想進企業內部來的公眾網路需求，這可以大幅提昇內部系統的安全。
雖然防火牆是提供接上網際網路安全的基礎機制，但它卻會降低分散式物件通訊協定的使用效能。為了要解決這個問題，有識之士紛紛提出了各自的解決方案。在 1998 年，UserLand 公司的執行總裁 Dave Winner 提出透過 XML 讓 RPC 的通訊方式透過 HTTP 協定在網際網路上執行。
這個想法經由微軟公司加以改良，提出了實際可行的Simple Object Access Protocol(SOAP)通訊協定。現今正在W3C審議中，已經有IBM等大廠表態支持。不久的未來即將可能成為在網際網路上提供電子服務的標準協定。
SOAP是一個像DCOM或其他分散式物件通訊協定的協定，讓使用者端與伺服端的RPCs可以溝通。但與其他類似協定不一樣的地方是，它支援防火牆的使用。同樣重要地，SOAP不是只設計用來針對某種物件技術的協定，它不像一些時下的分散式物件通訊協定會被綁死在某一種特定的物件規格上，這個協定將可以被任何的物件使用。所以它將是兩大物件陣營COM 和 CORBA 最好的溝通橋樑，讓彼此的物件程式可以跨平台透過網際網路呼叫。
簡易物件存取協定如其名稱所言，要求定義要"簡易"，所以它只訂出物件溝通基礎規範，如
讓物件透過網際網路提出需求的方式標準化，以 HTTP 當傳輸的方式，以 XML 描述溝通的內容
建立可延伸的傳遞物件呼叫格式的承載 但它不定義一些一般分散式物件系統需要定義的
分散式系統資源回收(garbage collection)
雙向的 HTTP 溝通
物件參照
物件初始化
以上這些不明確定義的規格都交由各系統廠商自行實作。
使用防火牆所造成的問題以及 SOAP 所提供的解決方案
要了解為何防火牆會造成分散式物件通訊協定的問題必須先了解到防火牆是如何分辨協定之間的不同。在TCP/IP的架構下，每一個被廣泛使用的協定都被賦予一個特殊的埠號(port number)而每一個使用該協定的需求封包都帶著這個埠號。例如HTTP協定的埠號是80、FTP是21等等。大部分的防火牆可以用來防止某個特殊協定的方式就是針對埠號拒絕某種協定的通訊。通常防火牆是被設定成允許埠號80的運作的-如果該公司不拒絕使用HTTP的話。
但大部分的防火牆會擋住其他的埠，因為它們假定利用其他的埠對公司內部網路的運作都是有危險的。 但這也正是造成分散式物件通訊協定無法運行的原因。不像HTTP、FTP等其他著名的通訊協定，分散式物件通訊協定通常沒有使用一個著名的大家都知道的埠號來溝通。相反地，這些通訊協定通常動態地被賦予埠號，埠號碼在被需求時任意產生。如果沒有防火牆擋在使用者端與伺服端之間，這種方式將可以很有效地運作。但若加了防火牆，則該通訊協定會因為防火牆不允許兩端任意使用任何埠號來溝通而中斷。
當下存在很多種解決方式，例如某些防火牆可以被設定成允許某個範圍的埠號碼可以進行溝通。若該分散式物件通訊協定也可以被設定成只用這個範圍的埠號碼，則這個方案便可行，使用者端與伺服端之間可以進行溝通。但比較注重安全的網路管理者將不會贊成開放任意一組埠號碼而導致這個方案並不完美。另一個選擇是採用COM網際網路服務，這讓傳統的DCOM封包在TCP上透過埠號80來傳遞。這在某些方面很有用，但這項技術只有微軟的Internet Information Server和DCOM在使用，而不是一項完整的解決方案，所以我們需要一個更普遍一般性的解決方案。
因為幾乎所有的防火牆都允許透過埠號80來溝通，所以透過埠號80來溝通的分散式物件通訊協定將是一個較好的方案。但這並不是說說那麼容易，因為埠號80已經被設定給HTTP協定。所以SOAP這個分散式物件通訊協定是架在HTTP協定之上的。HTTP通訊協定相當簡單，僅僅以少數基礎的動詞所組成，如GET、PUT、POST等等，而這些動詞在瀏覽器與伺服器之間傳遞。而每一個動詞之後跟著一些資訊，而這些資訊通常以簡易的字串方式傳遞。
本文转自
http://www.tianyablog.com/blogger/post_show.asp?BlogID=360358&PostID=4267254
扫一扫
342
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
