未来整个应用程式合作是以网路为基础，不分广域网路或区域网路。如同现今微软在 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 下列的好处：
- ● 容易使用与延伸：XML 技术的本身相当简洁，且具有高度的延伸性。同时，一般的系统已经多多少少采用 XML 的技术，因此存取 XML 资料对开发各系统的程式设计师来说并不陌生。而大多数提供平台的厂家也都支援 XML，因此它是跨平台合作、交换资料的最佳选择。
- ● 资料清楚明白：这是 XML 特色，一开始它的设计就是为了资料交换，在 XML Schema 的辅助下，让资料的使用清楚明白。
- ● 容易建立、分析与处理：不管是提供给程式开发人员所使用的物件，或是编写 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 区块。这几个基本区块的功能如下：
- ● Envelop：代表 SOAP 讯息的 XML 文件的根节点。其内可以包含两个区块，选择性的 Header 以及必定存在的 Body。
- ● Header：若 Header 区块有出现，则必定紧接在 Envelope 元素之后。但它是选择性的，所以也可以不出现。
- Header 主要是提供辅助资讯，在沟通中，不必然需要。一般可能将安全讯息、交易等资讯放在此处。在后文中，会利用此区块来传递使用者的帐号资讯。
- ● Body：如果 Header 区块未出现，Body 就紧跟在 Envelope 之后，若 Header 有出现，则 Body 跟在 Header 之后。 Body 放的是使用者端与伺服器端，方法呼叫所传递的资料，这部分一定会出现，否则无法呼叫 Web Service。
- ● Fault：用来传递错误的讯息，如果 SOAP 封包内有 Fault 区块，则该区块一定出现在 Body 内，且只能出现一次。
以下是笔者直接透过封包撷取程式，将使用者端对 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＞
'
＜Employee＞
＜LName＞胡＜/LName＞
＜FName＞百敬＜/FName＞
＜Title＞顾问＜/Title＞
＜/Employee＞
"
＜/soap:Body＞
＜/soap:Envelope＞
除了传回一般函数的执行结果外，SOAP 也制定了错误讯息的传递方式，也就是上述的 Fault 区块。
笔者同时在 Web Service 内的方法故意触发例外状况，该例外状况透过 SOAP 封包回传的内容如程式码三所示：
程式码三:Webservice 回应使用者端的 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.Except: 发生了很严重的例外状况!!
at GetWSDL.Service1.ThrowExcept() in C:\BookSamples\ch09\GetWSDL\Service1.asmx.vb:line 72
--- 内部例外堆叠追踪的结尾 ---＜/faultstring＞
＜detail /＞
＜/soap:Fault＞
＜/soap:Body＞
＜/soap:Envelope＞
在 Fault 区块内，可以包含四个子元素：
- ● faultcode：必须存在，用来定义错误。
- ● faultstring：必须存在，提供人类也可以阅读的错误说明提示。
- ● faultfactor：选择性存在，当 SOAP 讯息的最终目标不是当下的应用程式时，透过这个元素传递 URI 格式的来源位置。
- ● deatil：选择性存在，应用程式与 Body 元素有关的特定错误讯息，如果 Body 内的某些内容无法处理时，会将原因写在这个元素内。
因为我们透过上层应用程式架构丢出的例外类别，可以透过SOAP Fault 封包传递，所以若使用者端的应用程式也是透过相同程式架构撰写，经由SOAP 协定与Web Service 沟通，依然可以正常地撷取伺服器端所丢出的例外状况。
笔者在此故意丢出自定的例外，若用 Visual Studio.NET 撰写使用者端程式，透过代理程式呼叫，可以获得一般的例外状况，画面如图一所示：
| 《图一 透过 Web Service 前端代理程序呼叫，可以透过一般的 try/catch/end try 完成例外处理 》 |
|
防火墙问题与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 让当下触发远端函数不需要有任何改变。让应用程式可以透过网际网路存取不是一件简单的事，且它并未被绑死在任何一个单一的物件模型，可预期这项新的技术可以被用在许多不同情况，相当有潜力。
相關作者
相關产业类别
相關关键字
相關网站单元