OReilly.Java.Web Services 第三章 SOAP 整合的基石

          第三章   SOAP 整合的基石(3.1-3.4)

      就好比WEB SERVICE ，SOAP的广泛定义意味着对于不同人的各种各样的事情。他是一个有线的协议。他是RPC的一个介质，一个整合的标准，一个文档交换协议，一种商业到商业的交流语言，他是你曾经需要的任务和事情，但是，那是不够的。

      事实上，所有中最重要的，可能是明白它能做什么，不能做什么。我们是通过拆分首字母形成实际意思，然后分析他们适合的地方。

3.1 Simple

   对于在SOAP中的首字母 代表SIMPLE。以XML表达数据和以他使用HTTP传输数据的基础方式是简单的。在SOAP协议中，通过这个线路传输的每一件东西都是依照HTTP 头或是SMTP头，MIME编码，和为应用和对象编码的特定的XML语言的方式进行表达的。

不管咋样，充分理解SOAP规则和细节不是一件令人害怕的事。举例来说。通过邮件的附件和MIME metaphor表达SOAP文档的主意是简单的， MIME是简单的吗？是的，他是简单的。因为他使用的数据格式习惯被广泛的使用，为绝大部分IT工作者熟悉，并且对缺乏的技术的人也能在概念上进行理解。或许S应该代表SIMPLER。

XML是简单的吗，他可能是简单的，可能象你想要的那么复杂。XML为通过这个线路传输数据提供了一个增加语意的方法。通过XML-SCHEMA ，我们有一个描述诸如购置订单的复杂文档，但是XML-SCHEMA 是不容易的。SOAP提供了一个为数据创建envelope的规则。SOAP对于编码的应用数据有明确的规则—甚至是二进制的数据—所以他能被用ASCII表达。他并不是所有都是简单的，但是他能被解释。

我们不想由于SOAP的过度复杂而使任何人望而却步，我们带你浏览他和详细的解释他。有一个好消息就是工具和框架已经出来帮助我们。最终，我们将不用担心一个购置订单如何编码或是怎样通过线路传送。我们所有的编码就是一个PO对象和点击一个SAVE按钮。但是，对我们大部分人认为最好的行业工具是VI,EMACS,NOTAPAD，我们必须坚持。甚至那些喜欢框架的人也需要明白底层是什么。

或许。S代表 坦诚。在SOAP中，没有什么事情能被隐藏.SOAP请求的每一部分都有一个彻底的自我描述和广泛的被通过验证的规范。在SOAP后，那确实是完美的。在SOAP中，平台和编程语言是互相独立的，但是他们能进行通信，只要按照如下规范

l         通过使用HTTP或是SMTP进行消息的发送和接收。

l         明白MIME的编码规则和以在这些规则上创建和解构二进制附件为基础。

l         创建和解构遵守以SOAP建立的信封或编码规则的XML文档。

l         如果一个功能被在SOAP文档中被 标记，执行需要的功能。

SIMPLE并不代表脆弱和差劲的。SOAP有足够的能力表示任何数据类型，对象序列化，方法调用或是文档转化。

SIMPLE并不意味着SOAP会缺少一些重要的东西，诸如，安全问题，可靠性,可路由，对多方面互相作用的约定规则。但是，这些条目最终要被增加。让我们现在断定SOAP的前期要比他的前辈简单

3.2Object

O代表着object 并且不得不处理他的根，这个根使用通过internet 的方式调用COM。作为和他有亲密关系 XML_RPC，SOAP 完全有能力描述一个RPC 或是方法调用。这里是一个典型的描述远程对象上面的方法调用SOAP文档。

Post /stockquote http/ 1.1

Host : www.example.org

Content-type : text/xml;charset=”utf-8”

Content-length nnn

Soapaction: http://example.org/2001/06/quotes

<env :envelope xmlns:env=www.w3.org/2001/09/soap-envelope>

<env:body>

<m:GetLastTradePrice env:encodingStyle=http://www.w3.org/2001/09/soap-envelope

   Xmlns:m=http://example.org/2001/06/quotes>

<symbol>DIS</symbol>

</m: GetLastTradePrice>

</env:Body>

<env:Envelope>

Section 3.5 讨论一下这个SOAP请求的细节。到目前为止，他只告诉我们两个最重要的部分，方法名GetLastTradeProce,和他的参数，DIS

3.3 ACCESS

   SOAP 和WEB SERVICE 关键的特性就是可访问性。当初的SOAP的开发者，希望SOAP的交互通过绑定到一个低水平的协议上面去。。最可能的就是HTTP 或是SMTP。这些协议被使用，应为他们是广泛的的，可接受的。大部分线路已经被允许HTTP SESSIONS 和 SMTP exchanges，所以SOAP通信能容易的通过公司边界。SOAP可以绑定任何协议，但是。到目前为止，HTTP是被广发绑定。其他绑定 诸如通过RMI ,JMS（为了提高可靠性）都已经涌现出来。

3.4 PROTOCOL

       把所有的综合在一起。我们有了一个协议。SOAP是基于协议的XML，被用来通过分布式环境进行信息交换。

3.4.1基于文档交换和RPC的消息

   SOAP 在通过HTTP同步远程调用有他自己的根元素,尽管这些天你通过读规范不会知道。事实上，规范似乎开始不用这种方法为了避免这种结合。对于执行同步RPC调用SAOP，尽管特定的条款是可用的，但是这里也有一个同步的，基于文档交换的模型 。实际上，文档交换模型是缺省的在两个终端直接交换数据的方法。一个RPC调用就是一个特定的把多样化单向同步消息和请求响应合成一体的实例。

SOAP规范的1.2中的第二节也做了如下说明。

     SOAP消息从SOAP发送者到SOAP接收者最基本的单向传播。但是SOAP消息经常被和一些实现方式结合起来。。如果请求响应模式.SOAP的实现能优化是为了利用特定网络系统的特性属性。例如，HTTP绑定，提供了SOAP请求消息能被使用HTTP 响应传播，只要使用进站的相同连接。

因为SOAP 能表示一些相当复杂的数据结构，请求和响应的消息。在两种模型中的线路是自然联通的。这章表示和模型有关的信息.RPC 概念建立在更加广泛的被最终解释的概念的。我们使用APACHE SOAP 2.2为了我们例子。下面就是简单的设计.