未来整个应用程序合作是以网络为基础，不分广域网或局域网络。如同现今微软在 SOAP Tool Kit 中所示范的，透过自行撰写的 Visual Basic 程序可以经由因特网轻易地呼叫提供股票交易信息的程序对象，以获得最新的股票交易信息。

或是透过因特网呼叫可以将欧语系语言互翻的程序对象。假想你是一个提供中英文互翻的厂商，如今你卖的字典可以轻易地办到欧语系加上中文的互翻能力。因为若有人需要将中文翻成德文，透过撰写的程序将中文转成英文后，再透过因特网呼叫一个欧语系互翻的程序将英文再转成德文，而不必撰写任何其他的程序代码。

现今企业内的信息系统渐渐开始强调整合，我相信这是企业 IT 下一阶段的需求。在当下，大家要忙于建立某种系统，不管是 ERP、CRM、SCM、EIP、KM...。不久后，该有的系统都有了，他们将会发现分崩离析的独立系统对企业局部的功能正常运作没有什么很大的益处，上述的系统都是操作型的系统，只能把事情做对，例如财务正确、客户正确、生管正确等等。但就以公司经营的全局而言，却不知道什么是对的事情。

唯有全面的整合与分析才能突显企业的策略与竞争力，也必须让公司上下都能轻易取得正确有效的分析信息，才有可能掌握先机，否则诚如笔者在某本管理书籍所看到的：「大家都以为公司决策者在做重大的运筹帷幄，殊不知下层经理人所提供的信息都是错误的。」 在 IT 系统整合的需求下，服务导向（SOA）/讯息导向的概念应运而生，也就是各大系统都是另一个系统的 Service 或 Client，而负起穿针引线串联各系统的技术就是 Web Service 与 SOAP 协议。

透过网络，这种程序对象不分企业、地域、国界地整合在一起，但需要有新的程序间互相沟通的协议。以往的 RMI/IIOP/DCOM 等等通讯协议太过繁复与专属，且不适合以因特网为沟通平台，所以由公开机构 W3C 来审定 SOAP 协议，提供所有软件开发厂商有共通的程序沟通协议。

简易对象存取协议 － SOAP

我们就来看看什么是简易对象存取协议（Simple Object Access Protocol，SOAP）：简而言之就是利用现存的因特网架构让应用程序之间可以彼此沟通，而不会被防火墙阻碍。在分布式的架构下及使用 XML 的环境中，SOAP提供两个计算机系统之间交换的数据架构与型别。也因此可以简单定义如下：

SOAP=HTTP+XML

在过去七年来，透过因特网存取已经变成是较进步社会的基础需求，纷纷在其上执行着各式各样的通讯协议。但是直至目前为止，最广泛被接受的通讯协议依然是HTTP，它在浏览器与 Web 服务器之间沟通时使用，对于文字、图形以及其他信息的传输很有效率与弹性，而且它简单易懂（机器看得懂，人也看得懂，这是因特网上应用层协议的特色，诸如 SMTP、POP3、FTP...等等皆是如此）。

SOAP的优点

因为 SOAP 的数据描述方式是采用 XML，因而承袭了 XML 下列的好处：

未来因特网上的系统需要自动完成合作，不再有人工参与。而且彼此的系统是各自以所熟悉的技术完成，这代表着系统不会遵循特殊的架构。有可能甲方的系统是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 协议在因特网上执行。

这个想法经由微软加以改良，提出了实际可行的SOAP通讯协议，目前正在W3C审议中，几乎所有的信息大厂都表态支持。不久的未来即将可能成为在因特网上提供电子服务的标准协议。

SOAP的对象沟通基础规范

SOAP是一个像DCOM或其他分布式对象通讯协议的协议，让用户端与伺服端的RPCs可以沟通。但与其他类似协议不同之处，在于它支持防火墙的使用。同样重要地，SOAP不是只设计用来针对某种对象技术的协议，它不像一些时下的分布式对象通讯协议，会被绑死在某一种特定的对象规格上，这个协议将可以被任何的对象使用。所以它将是两大对象阵营COM 和 CORBA最好的沟通桥梁，让彼此的对象程序可以跨平台、透过因特网呼叫。

简易对象存取协议如其名称所言，要求定义要“简易”，所以它只订出对象沟通基础规范，如：@內標:● 让对象透过因特网提出需求的方式标准化，以 HTTP 当传输的方式，以 XML 描述沟通的内容

● 建立可延伸的传递对象呼叫格式的承载

但它不定义一些一般分布式对象系统需要定义的

● 分布式系统资源回收(garbage collection)

● 双向的 HTTP 沟通

● 对象参照

● 对象初始化

以上这些不明确定义的规格都交由各系统厂商自行实作。

SOAP 讯息的结构

SOAP 讯息的结构基本上有三块：Envelope、Header 以及 Body，另外，当 Web Service 运行错误时，会传回含在 Body 内的 Fault 区块。这几个基本区块的功能如下：

以下是笔者直接透过封包撷取程序，将用户端对 Web Service 的呼叫，以及服务器端响应用户的 SOAP 封包撷取下来，并整理如程序代码一及程序代码二的内容：

程序代码一：用户端对 Web Service 呼叫的封包内容

POST /getwsdl/service1.asmx HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 1.0.3705.0)
Content-Type: text/xml; charset=utf-8
SOAPAction: http://myDemo/GetEmployee
Content-Length: 310
Expect: 100-continue
Connection: Keep-Alive
Host: byronnew
＜?xml version="1.0" encoding="utf-8"?＞
＜soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"＞
＜soap:Body＞
＜GetEmployee xmlns="http://myDemo/"＞
＜intI＞1＜/intI＞
＜/GetEmployee＞
＜/soap:Body＞
＜/soap:Envelope＞

程序代码二：Web Service 响应用户端的封包内容

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
Date: Tue, 15 Oct 2002 03:54:43 GMT
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Content-Length: 393
＜?xml.version="1.0" encoding="utf-8"?＞
＜soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"＞
＜soap:Body＞
＜GetEmployeeResponse xmlns="http://myDemo/"＞
＜Employee＞
＜LName＞胡＜/LName＞
＜FName＞百敬＜/FName＞
＜Title＞顾问＜/Title＞
＜/Employee＞
＜/GetEmployeeResponse＞
＜/soap:Body＞
＜/soap:Envelope＞

除了传回一般函数的执行结果外，SOAP 也制定了错误讯息的传递方式，也就是上述的 Fault 区块。

笔者同时在 Web Service 内的方法故意触发例外状况，该例外状况透过 SOAP 封包回传的内容如程序代码三所示：

程序代码三：Web Service 响应用户端的 SOAP Fault 封包内容

＜?xml version="1.0" encoding="utf-8"?＞
＜soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"＞
＜soap:Body＞
＜soap:Fault＞
＜faultcode＞soap:Server＜/faultcode＞
＜faultstring＞System.Web.Services.Protocols.SoapException: 服务器无法处理要求。 ---> GetWSDL.myExcept: 发生了很严重的例外状况!!
   at GetWSDL.Service1.ThrowExcept() in C:\BookSamples\ch09\GetWSDL\Service1.asmx.vb:line 72
--- 内部例外堆栈追踪的结尾 ---＜/faultstring＞
＜detail /＞
＜/soap:Fault＞
＜/soap:Body＞
＜/soap:Envelope＞

在 Fault 区块内，可以包含四个子元素：

因为我们透过上层应用程序架构丢出的例外类别，可以透过 SOAP Fault 封包传递，所以若用户端的应用程序也是透过相同程序架构撰写，经由 SOAP 协议与 Web Service 沟通，依然可以正常地撷取服务器端所丢出的例外状况。

笔者在此故意丢出自定的例外，若用 Visual Studio.NET 撰写用户端程序，透过代理程序呼叫，可以获得一般的例外状况，画面如图一所示：

《图一 最受欢迎的脚本语言调查分析》

防火墙问题与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等等，而这些动词在浏览器与服务器之间传递。每一个动词之后跟着一些信息，这些信息通常以简易的字符串方式传递。SOAP 不能改变任何的现状，也不能要求增加 HTTP 现有的动词。替代方案是 SOAP 将使用XML来定义需求与响应消息的格式，并允许使用正常的HTTP POST 命令来传递这些讯息。所有的 SOAP 通讯都使用80埠，这也代表着在因特网上，SOAP 可以透过任何的 Web 服务器来沟通 － 防火墙将不再是一个问题。

SOAP 主要的设计目的之一，是保证它可以有效地使用既有的因特网架构 － 也就是 HTTP、防火墙、代理服务器(proxy)以及其他架构。例如 SOAP 可以使用 Secure Sockets Layer(SSL)通讯协议以加密维护安全、使用 HTTP 的联机管理机制等等。SOAP让分布式对象通讯协议透过因特网的沟通就像使用浏览器来存取网页一样方便。

潜力无限的SOAP

直到今天，各种 XML Web Service 的相关规格都还在研议发展中，我们已经拥有的只是非常基础的规格，也就是透过 SOAP(Simple Object Access Protocol) 通讯协议，完成简单的沟通基础，但若要进一步提供严谨的商业服务却还是力有未逮。因为诸如交易管理、讯息交换质量、数据安全、讯息绕送、附加档案...等等规格都还需要制定。

微软、IBM、BEA以及陆陆续续在后来加入的公司，为了提供更有弹性、稳定的 XML Web Service，一起通力合作，对上述的需求及相关规格提出许多草案。这许许多多的建议案合称为 Global XML Web Service Architecture(GXA)。各软件公司再根据该规格，在自己的平台上实做出应用程序平台。例如微软最近提供的 Microsoft Web Services Enhancements 2.0 函式库。

就是遵循 GXA 以 .NET Framework 函式库的形式实做了 WS-Security、WS-Policy、WS-Trust、WS-Secure Conversation、WS-Attachments 和 DIME 等定义的对象类别，让你透过 SOAP 通讯协议传送讯息时，可以增加一些 SOAP 原先没有定义，但实做 Web Service 时可能需要的功能。

这些规格的制定只是开始，不是最终的解决方案，但它开启了未来的光明之路。当然，规格的制定都需要靠信息界携手合作，尤其 XML Web Service 的特色是联邦式(Federated)，也就是在一定的基本规则上可以自定义规则来玩，并不一定要经过某个中心，或受什么控管，这就更需要大家的参与，XML Web Service 才有美好的未来。

虽然目前已有许多分布式对象通讯协议被创造出来，但尚未有一个能够不被改变，就适用于现今的因特网上的。藉由提供一个架在 HTTP 之上，简单、有弹性的机制来传送需求与响应，SOAP 让当下触发远程函数不需要有任何改变。让应用程序可以透过因特网存取不是一件简单的事，且它并未被绑死在任何一个单一的对象模型，可预期这项新的技术可以被用在许多不同情况，相当有潜力。

延 伸 阅 读	新一代的Web应用标准竞争 在微软正式宣布.NET之后，J2EE将有一些必要的议题值得进行进一步的开发、整合与提升。例如在对XML的支持方面，更应朝向延伸类似SOAP的协议层次。而在与各项标准的整合上，则应更加努力迎向世界的共享标准，例如将JNDI整合JMS、LDAP、NIS、COS Naming，并与标准的SOAP/BizTalk伺服端衔接合作。 浅谈SOAP 本文对SOAP作了一个初步介绍，并给出几个简单范例。叙述CORBA、DCOM/COM与SOAP的联系与区别，然后再浅析SOAP简单的理解为RPC+HTTP+XML时的运行机制。 细看SOAP 本文将介绍一些高级主题，这其中包括SOAP复杂类型处理，错误处理和远程引用。

相关组织网站	W3C的SOAP文件官方网站 SOAP新闻网站 W3C的Web Services文件官方网站