就是所谓RPC与Document或者Wrapped,Literal与Encoding
先说Literal与Encoding
-
Literal就是不在SOAP消息中表明数据类型,而通过其它方式获知数据类型,这种方式是开发包相关的,没有什么标准;如<x>50</x>,单从SOAP消息,你无法判断50是数字还是字符串,而具体的类型可以在开发包将SOAP请求映射到具体的Service类时来确定并完成转换,对于返回值也一样,客户端可已通过SetReturnValueType(...)之类的方法告知开发包自己期待什么类型
-
Encoding就是在SOAP消息中携带类型信息,并且依据某种规则将数据编码传递,接收端可以根据类型信息和编码规则完成解码,获得原始数据;如<x xsi:type="xsd:string">50</x>
再看看RPC与Document
-
RPC就是按照类似函数调用时所需的信息来组装SOAP消息:操作名作为根元素,参数组成子元素,如:
<envelope><body><myMethod><x>5</x><y>8</y></myMethod></body></envelope> (RPC/Literal) <envelope><body><myMethod><x type=string>5</x><y type=int>8</y></myMethod></body></envelope> (RPC/Encoded) |
-
Document就是将SOAP请求和响应,或者说输入输出定义为XML元素,有严格的Schema("document" style means the messages in and out of the service are exactly as they are describe by the XML Schema in the WSDL).如某个Web Service的WSDL片断:
然而这种方式没有在SOAP消息中包含操作名,所以如果两个不同的操作具有相同的输入,开发包有可能无法决定把请求转发到哪个函数,为避免这种情况,开发包一般为每个操作的输入输出都产生具有唯一名称的Element,不管它们是否内容相同;或者作为开发者,你可以选择 Wrapped 风格 |
-
Wrapped 风格就是定义与操作同名的Element,将参数作为 Child Element;这样操作名又重新回到了SOAP消息中,如WSDL片断:
这种方式也具有明显的弱点:无法方便的处理重载,因为XML Schema不允许定义相同名称的元素;这样,即使你的后台编程语言支持函数重载,你也应该尽量避免使用 |