让我们根据图2，观察AustinKayaks和MoneyBroker 之间的电子协作。在使用浏览器工作的AustinKayaks客户(1)访问AustinKayaks URL，然后要求购买一个皮艇时，电子协作开始。请求作为HTTP请求(2)通过Internet传输。AustinKayaks表示层(3)接收到该请求，该表示层通过该站点使用的任何一种本地协议(4)向商务层发出请求。如果AustinKayaks是一个微软站点，那么本地协议可能是（但并不一定是）DCOM。
AustinKayaks商务层现在认识到，需要向MoneyBroker商务逻辑请求支付。 这个请求是在本地(处理中的)SOAP代理(5)上作出的。SOAP代理将支付请求打包为一个SOAP请求，然后使用HTTP (6)，通过Internet将其发送给MoneyBroker站点，在MoneyBroker站点请求被MoneyBroker表示层上的一个SOAP接收器 (7)接收。
SOAP接收器 (7)的唯一用途是将SOAP请求翻译为本地请求，通过本地协议(8)将其传输给MoneyBroker商务层 (9)，请求在此进行处理，并完成支付。然后，结果从MoneyBroker商务层被返回给AustinKayaks表示层，该表示层可以将结果翻译为适合该AustinKayaks客户的浏览器的内容。
SOAP是技术中性的。AustinKayaks和MoneyBroker不需要在使用何种技术建设网站上以致，只要各自的技术支持SOAP技术能够互用即可。
对于允许AustinKayaks使用MoneyBroker服务来说，SOAP功不可没，但是只有在AustinKayaks已经知道4件事情时才可以：MoneyBroker存在；可以找到MoneyBroker的URL；,MoneyBroker可以提供的服务；以及MoneyBroker 可以接受SOAP请求的确切格式。如果AustinKayaks不知道这些又怎么样呢？如果AustinKayaks只知道它需要帐单支付服务，但不知道哪些存在，它们位于何处，以及如何使用它们，又会怎样呢？
这就是使用UDDI的原因。UDDI定义了允许电子协作各方可以彼此找到的标准。描述UDDI标准的所有内容已经超出了本白皮书的范围。
这就是UDDI起作用的地方。UDDI定义了使得潜在的电子协作者可以彼此找到对方的标准。描述所有的UDDI标准（这些信息可以从网上获得[1]）已经超出了本白皮书的范围，但是我们将讨论如下方面：
注册设备的URL，包含关于工业标准接口的信息，如帐单支付服务。
已经承诺支持工业标准接口（如MoneyBroker）的具体公司。
到这些设备的SOAP接口，潜在的协作者可以编程使用这些接口彼此找到对方。
一种用于描述SOAP接口的标准的技术中性语言。
在UDDI功能标准(HTTP, XML, SOAP)与UDDI电子协作标准之间，我们有一种技术中性的架构让企业一起工作。
.NET平台已经包含了XML和SOAP技术。微软公司是UDDI计划的三个领导者之一（其他两个为Ariba和IBM），因此很清楚这三个标准一成熟，我们就可以看到它们会被合并到.NET平台中。
我们有一个专门的小组来描述SOAP可以随时支付的商务逻辑，该小组的站点三使用了合适的UDDI标准来使得SOAP服务可以广泛使用。我们将这样的商务逻辑称为网络服务（Web Service）。
.NET平台：将一切合并到一起
图3显示了.NET平台的所有部分是如何结合到一起的。应将该图与显示这种体系结构的一般形式的图1进行比较。
[1] 例如，可以参阅UDDI Executive White Paper（UDDI执行白皮书）或UDDI Technical White Pape（UDDI技术白皮书），这两个白皮书都可以在http://www.uddi.org/whitepapers.html得到。
