- 浏览: 155680 次
- 性别:
- 来自: 奥克兰
文章分类
最新评论
-
u012625419:
...
CXF之用spring配置服务端和客户端实例(转) -
bambooshangye:
CXF之用spring配置服务端和客户端实例(转) -
最佳蜗牛:
写的很好,谢谢!
tomcat下的server.xml文件和context.xml (转) -
mohaowen1989:
亲 有中文版的么?在grails基础上的spring-secu ...
Simplified Spring Security with Grails(转) -
douhongyang:
挺好,,思路很清晰,
spring security详解教程 (转)
转自 http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/
A WSDL document describes a web service. A WSDL binding describes how the service is bound to a messaging protocol, particularly the SOAP messaging protocol. A WSDL SOAP binding can be either a Remote Procedure Call (RPC) style binding or a document style binding. A SOAP binding can also have an encoded use or a literal use. This gives you four style/use models:
- RPC/encoded
- RPC/literal
- Document/encoded
- Document/literal
Add to this collection a pattern which is commonly called the document/literal wrapped pattern and you have five binding styles to choose from when creating a WSDL file. Which one should you choose?
Before I go any further, let me clear up some confusion that many of us have stumbled over. The terminology here is very unfortunate: RPC versus document. These terms imply that the RPC style should be used for RPC programming models and that the document style should be used for document or messaging programming models. That is not the case at all. The style has nothing to do with a programming model. It merely dictates how to translate a WSDL binding to a SOAP message. Nothing more. You can use either style with any programming model.
Likewise, the terms encoded and literal are only meaningful for the WSDL-to-SOAP mapping, though, at least here, the traditional meanings of the words make a bit more sense.
For this discussion, let's start with the Java method in Listing 1 and apply the JAX-RPC Java-to-WSDL rules to it (see Resourcesfor the JAX-RPC 1.1 specification).
Listing 1. Java method
public void myMethod(int x, float y);
|
Take the method in Listing 1 and run it through your favorite Java-to-WSDL tool, specifying that you want it to generate RPC/encoded WSDL. You should end up with something like the WSDL snippet in Listing 2.
Listing 2. RPC/encoded WSDL for myMethod
<message name="myMethodRequest">
<part name="x" type="xsd:int"/>
<part name="y" type="xsd:float"/>
</message>
<message name="empty"/>
<portType name="PT">
<operation name="myMethod">
<input message="myMethodRequest"/>
<output message="empty"/>
</operation>
</portType>
<binding .../>
<!-- I won't bother with the details, just assume it's RPC/encoded. -->
|
Now invoke this method with "5" as the value for parameter x
and "5.0" for parameter y
. That sends a SOAP message which looks something like Listing 3.
Listing 3. RPC/encoded SOAP message for myMethod
<soap:envelope>
<soap:body>
<myMethod>
<x xsi:type="xsd:int">5</x>
<y xsi:type="xsd:float">5.0</y>
</myMethod>
</soap:body>
</soap:envelope>
|
A note about prefixes and namespaces
For the most part, for brevity, I ignore namespaces and prefixes in the listings in this article. I do use a few prefixes that you can assume are defined with the following namespaces:
- xmlns:xsd="http://www.w3.org/2001/XMLSchema"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
For a discussion about namespaces and the WSDL-to-SOAP mapping, see paper "Handle namespaces in SOAP messages you create by hand" (see Resources).
There are a number of things to notice about the WSDL and SOAP message for this RPC/encoded example:
- The WSDL is about as straightforward as it's possible for WSDL to be.
- The operation name appears in the message, so the receiver has an easy time dispatching this message to the implementation of the operation.
WS-I compliance
The various web services specifications are sometimes inconsistent and unclear. The WS-I organization was formed to clear up the issues with the specs. It has defined a number of profiles which dictate how you should write your web services to be interoperable. For more information on WS-I, see the WS-I links in Resources.
- The type encoding info (such as
xsi:type="xsd:int"
) is usually just overhead which degrades throughput performance. - You cannot easily validate this message since only the
<x ...>5</x>
and<y ...>5.0</y>
lines contain things defined in a schema; the rest of thesoap:body
contents comes from WSDL definitions. - Although it is legal WSDL, RPC/encoded is not WS-I compliant.
Is there a way to keep the strengths and remove the weaknesses? Possibly. Let's look at the RPC/literal style.
The RPC/literal WSDL for this method looks almost the same as the RPC/encoded WSDL (see Listing 4). The use in the binding is changed from encoded to literal. That's it.
Listing 4. RPC/literal WSDL for myMethod
<message name="myMethodRequest">
<part name="x" type="xsd:int"/>
<part name="y" type="xsd:float"/>
</message>
<message name="empty"/>
<portType name="PT">
<operation name="myMethod">
<input message="myMethodRequest"/>
<output message="empty"/>
</operation>
</portType>
<binding .../>
<!-- I won't bother with the details, just assume it's RPC/literal. -->
|
What about the SOAP message for RPC/literal (see Listing 5)? Here there is a bit more of a change. The type encodings have been removed.
Listing 5. RPC/literal SOAP message for myMethod
<soap:envelope>
<soap:body>
<myMethod>
<x>5</x>
<y>5.0</y>
</myMethod>
</soap:body>
</soap:envelope>
|
A note about xsi:type and literal use
Although in normal circumstances xsi:type
does not appear in a literal WSDL's SOAP message, there are still cases when type information is necessary and it will appear -- in polymorphism, for instance. If the API expects a base type and an extension instance is sent, the type of that instance must be provided for proper deserialization of the object.
Here are the strengths and weaknesses of this approach:
- The WSDL is still about as straightforward as it is possible for WSDL to be.
- The operation name still appears in the message.
- The type encoding info is eliminated.
- RPC/literal is WS-I compliant.
- You still cannot easily validate this message since only the
<x ...>5</x>
and<y ...>5.0</y>
lines contain things defined in a schema; the rest of thesoap:body
contents comes from WSDL definitions.
What about the document styles? Do they help overcome this weakness?
Nobody follows this style. It is not WS-I compliant. So let's move on.
The WSDL for document/literal changes somewhat from the WSDL for RPC/literal. The differences are highlighted in bold inListing 6.
Listing 6. Document/literal WSDL for myMethod
<types>
<schema>
<element name="xElement" type="xsd:int"/>
<element name="yElement" type="xsd:float"/>
</schema>
</types>
<message name="myMethodRequest">
<part name="x" element="xElement"/>
<part name="y" element="yElement"/>
</message>
<message name="empty"/>
<portType name="PT">
<operation name="myMethod">
<input message="myMethodRequest"/>
<output message="empty"/>
</operation>
</portType>
<binding .../>
<!-- I won't bother with the details, just assume it's document/literal. -->
|
The SOAP message for this WSDL is in Listing 7:
Listing 7. Document/literal SOAP message for myMethod
<soap:envelope>
<soap:body>
<xElement>5</xElement>
<yElement>5.0</yElement>
</soap:body>
</soap:envelope>
|
A note about the message part
I could have changed only the binding, as I did from RPC/encoded to RPC/literal. It would have been legal WSDL. However, the WS-I Basic Profile dictates that document/literal message parts refer to elements rather than types, so I'm complying with WS-I. (And using an element part here leads well into the discussion about the document/literal wrapped pattern.)
Here are the strengths and weaknesses of this approach:
- There is no type encoding info.
- You can finally validate this message with any XML validator. Everything within the
soap:body
is defined in a schema. - Document/literal is WS-I compliant, but with restrictions (seeweaknesses).
- The WSDL is getting a bit more complicated. This is a very minor weakness, however, since WSDL is not meant to be read by humans.
- The operation name in the SOAP message is lost. Without the name, dispatching can be difficult, and sometimes impossible.
- WS-I only allows one child of the
soap:body
in a SOAP message. As you can see in Listing 7, this example'ssoap:body
has two children.
The document/literal style seems to have merely rearranged the strengths and weaknesses from the RPC/literal model. You can validate the message, but you lose the operation name. Is there anything you can do to improve upon this? Yes. It's called the document/literal wrapped pattern.
Before I describe the rules for the document/literal wrapped pattern, let me show you the WSDL and the SOAP message inListing 8 and Listing 9.
Listing 8. Document/literal wrapped WSDL for myMethod
<types>
<schema>
<element name="myMethod">
<complexType>
<sequence>
<element name="x" type="xsd:int"/>
<element name="y" type="xsd:float"/>
</sequence>
</complexType>
</element>
<element name="myMethodResponse">
<complexType/>
</element>
</schema>
</types>
<message name="myMethodRequest">
<part name="parameters" element="myMethod"/>
</message>
<message name="empty">
<part name="parameters" element="myMethodResponse"/>
</message>
<portType name="PT">
<operation name="myMethod">
<input message="myMethodRequest"/>
<output message="empty"/>
</operation>
</portType>
<binding .../>
<!-- I won't bother with the details, just assume it's document/literal. -->
|
The WSDL schema now has a wrapper around the parameters (see Listing 9).
Listing 9. Document/literal wrapped SOAP message for myMethod
<soap:envelope>
<soap:body>
<myMethod>
<x>5</x>
<y>5.0</y>
</myMethod>
</soap:body>
</soap:envelope>
|
Notice that this SOAP message looks remarkably like the RPC/literal SOAP message in Listing 5. You might say it looks exactly like the RPC/literal SOAP message, but there's a subtle difference. In the RPC/literal SOAP message, the <myMethod>
child of<soap:body>
was the name of the operation. In the document/literal wrapped SOAP message, the <myMethod>
clause is the name of the wrapper element which the single input message's part refers to. It just so happens that one of the characteristics of the wrapped pattern is that the name of the input element is the same as the name of the operation. This pattern is a sly way of putting the operation name back into the SOAP message.
These are the basic characteristics of the document/literal wrapped pattern:
- The input message has a single part.
- The part is an element.
- The element has the same name as the operation.
- The element's complex type has no attributes.
Here are the strengths and weaknesses of this approach:
- There is no type encoding info.
- Everything that appears in the
soap:body
is defined by the schema, so you can easily validate this message. - Once again, you have the method name in the SOAP message.
- Document/literal is WS-I compliant, and the wrapped pattern meets the WS-I restriction that the SOAP message's
soap:body
has only one child.
- The WSDL is even more complicated.
As you can see, there is still a weakness with the document/literal wrapped pattern, but it's minor and far outweighed by the strengths.
RPC/literal wrapped?
From a WSDL point of view, there's no reason the wrapped pattern is tied only to document/literal bindings. It could just as easily be applied to an RPC/literal binding. But this would be rather silly. The SOAP message would contain a myMethod
element for the operation and a child myMethod
element for the element name. Also, even though it's legal WSDL, an RPC/literal part should be a type; an element part is not WS-I compliant.
Where is doc/lit wrapped defined?
This wrapped style originates from Microsoft®. There is no specification that defines this style; so while this style is a good thing, unfortunately, the only choice right now, in order to interoperate with Microsoft's and other's implementations, is to make educated guesses as to how it works based on the output of the Microsoft WSDL generator. This pattern has been around for awhile, and the industry has done a good job of understanding it, but while the pattern is fairly obvious in this example, there are corner cases in which the proper thing to do is not particularly clear. Our best hope is that an independent group like the WS-I organization will help stabilize and standardize this in the future.
Why not use document/literal wrapped all the time?
So far, this article has given the impression that the document/literal wrapped style is the best approach. Very often that's true. But there are still cases where you'd be better off using another style.
Reasons to use document/literal non-wrapped
If you have overloaded operations, you cannot use the document/literal wrapped style.
Imagine that, along with the method you've been using all along, you have the additional method in Listing 10.
Listing 10. Problem methods for document/literal wrapped
public void myMethod(int x, float y);
public void myMethod(int x);
|
A note about overloaded operations
WSDL 2.0 will not allow overloaded operations. This is unfortunate for languages like the Java language whichdo allow them. Specs like JAX-RPC will have to define a name mangling scheme to map overloaded methods to WSDL. WSDL 2.0 merely moves the problem from the WSDL-to-SOAP mapping to the WSDL-to-language mapping.
WSDL allows overloaded operations. But when you add the wrapped pattern to WSDL, you require an element to have the same name as the operation, and you cannot have two elements with the same name in XML. So you must use the document/literal, non-wrapped style or one of the RPC styles.
Since the document/literal, non-wrapped style doesn't provide the operation name, there are cases where you'll need to use one of the RPC styles. For instance, say you have the set of methods in Listing 11.
Listing 11. Problem methods for document/literal non-wrapped
public void myMethod(int x, float y);
public void myMethod(int x);
public void someOtherMethod(int x, float y);
|
Now assume that your server receives the document/literal SOAP message that you saw back in Listing 7. Which method should the server dispatch to? All you know for sure is that it's not myMethod(int x)
because the message has two parameters and this method requires one. It could be either of the other two methods. With the document/literal style, you have no way to know which one.
Instead of the document/literal message, assume that the server receives an RPC/literal message such as the one in Listing 5. With this message it's fairly easy for a server to decide which method to dispatch to. You know the operation name is myMethod, and you know you have two parameters, so it must be myMethod(int x, float y)
.
The primary reason to prefer the RPC/encoded style is for data graphs. Imagine that you have a binary tree whose nodes are defined in Listing 12.
Listing 12. Binary tree node schema
<complexType name="Node">
<sequence>
<element name="name" type="xsd:string"/>
<element name="left" type="Node" xsd:nillable="true"/>
<element name="right" type="Node" xsd:nillable="true"/>
</sequence>
</complexType>
|
With this node definition, you could construct a tree whose root node -- A -- points to node B through both its left and right links (see Figure 1).
Figure 1. Encoded tree.
The standard way to send data graphs is to use the href tag, which is part of the RPC/encoded style (Listing 13).
Listing 13. The RPC/encoded binary tree
<A>
<name>A</name>
<left href="12345"/>
<right href="12345"/>
</A>
<B id="12345">
<name>B</name>
<left xsi:nil="true"/>
<right xsi:nil="true"/>
</B>
|
Under any literal style, the href attribute is not available, so the graph linkage is lost (see Listing 14 and Figure 2). You still have a root node, A, which points to a node B to the left and another node B to the right. These B nodes are equal, but they are not the same node. Data have been duplicated instead of being referenced twice.
Listing 14. The literal binary tree
<A>
<name>A</name>
<left>
<name>B</name>
<left xsi:nil="true"/>
<right xsi:nil="true"/>
</left>
<right>
<name>B</name>
<left xsi:nil="true"/>
<right xsi:nil="true"/>
</right>
</A>
|
Figure 2. Literal tree
There are various ways you can do graphs in literal styles, but there are no standard ways; so anything you might do would probably not interoperate with the service on the other end of the wire.
So far I have been discussing request messages. But what about response messages? What do they look like? By now it should be clear to you what the response message looks like for a document/literal message. The contents of the soap:body
are fully defined by a schema, so all you have to do is look at the schema to know what the response message looks like. For instance, see Listing 15 for the response for the WSDL in Listing 8.
Listing 15. document/literal wrapped response SOAP message for myMethod
<soap:envelope>
<soap:body>
<myMethodResponse/>
</soap:body>
</soap:envelope>
|
But what is the child of the soap:body
for the RPC style responses? The WSDL 1.1 specification is not clear. But WS-I comes to the rescue. WS-I's Basic Profile dictates that in the RPC/literal response message, the name of the child of soap:body
is "... the corresponding wsdl:operation
name suffixed with the string 'Response'." Surprise! That's exactly what the conventional wrapped pattern's response element is called. So Listing 15 applies to the RPC/literal message as well as the document/literal wrapped message. (Since RPC/encoded is not WS-I compliant, the WS-I Basic Profile doesn't mention what an RPC/encoded response looks like, but you can assume the same convention applies here that applies everywhere else.) So the contents of response messages are not so mysterious after all.
There are four binding styles (there are really five, but document/encoded is meaningless). While each style has its place, under most situations the best style is document/literal wrapped.
发表评论
-
Java web services: WS-Security with CXF (转)
2011-09-05 17:45 2146This article is refered from h ... -
CXF全接触 --- WS-Security的实现 (转)
2011-09-05 17:36 2269转自 http://blog.csdn.net/kuns ... -
SSL原理解密(转)
2011-07-26 06:47 1520RSA公钥加密在计算机产 ... -
UsernameToken 介绍(转)
2011-04-14 12:39 1726很好的一篇文章,转过 ... -
不同格式证书导入keystore方法(转)
2011-04-14 12:24 2447转自: http://hi.baidu.com/%D3%C ... -
CXF使用WSS4J实现WS-Security规范之使用用户名令牌(转)
2011-04-14 10:35 2138转自 http://blog.csdn.net/fhd001/ ... -
WSDL 规则解释(转)
2011-04-13 11:56 3388转自 http://www.blogjava.net/baoy ... -
深入浅出WS-Addressing(转)
2010-10-28 11:51 12091. 为什么需要 WS-Addressin ... -
WS-Addressing EndpointReference(转)
2010-10-28 11:18 1004WS-Addressing规范主要描述 ... -
WS-Addressing 问题的引出(转)
2010-10-28 11:15 789SOAP 协议定义了在 Web Services 之间传 ... -
WS-Addressing Message Addressing Properties (转)
2010-10-28 11:09 1759相对EndpointReference而言,个人认为在WS-A ... -
SOAP与CORBA,COM/DCOM的区别(转)
2010-09-23 17:49 1701CORBA(Common Object Request Br ... -
Java Web 服务: Axis2 中的 JAXB 和 JAX-WS(转)
2010-09-23 17:41 1260Apache Axis2 支持各种数据 ... -
Web Service简介 (转)
2010-09-23 17:25 6831.定义 由两部分组成 ... -
WSDL & SOAP & Web Service (转)
2010-09-23 17:24 897WSDL 是基于 XML 的用于描述 Web Services ...
相关推荐
Webservice接口测试及联调工具 非常好用,适用于接口开放测试、系统集成测试 操作简单。 使用手册也网上一搜一大把 由于文件大小分了2个上传 第一个3分 第二个不要分
通过示例说明document/literal、document/literal(wrapped)、rpc/encoded、rpc/literal样式的web服务对应的soap消息格式,对于理解webservice有很大好处,尤其是根据wsdl构造soap消息,非常有价值。
学习axis容器document/literal样式的好例子,值得一看。
C# 操作ACCESS数据库以及EXCEl类 操作EXCEl与ACCESS数据库代码是一样的,我已经测试过了 至于调用方法,应该不用我说下载者应该也懂得吧,如果是对C#一巧不通的初学者,不懂也不要怪我,可以问我,或问懂点的人。...
SoapUI是一个开源测试工具,通过soap/http来检查、调用、实现Web Service的功能/负载/符合性测试。该工具既可作为一个单独的测试软件使用,也可利用插件集成到Eclipse,maven2.X,Netbeans 和intellij中使用
NULL 博文链接:https://douh.iteye.com/blog/727105
” //simple string literal“” //empty string literal“\nCC\toptions\tfile.[cC]\n” //string literal using newlines and tabs字符字面值: ‘A’ //single quote:character literal字符串字面值: “A” //...
Literal控件的例子
// declare variable, number literalvar f = fun ( x , y ) { // function literal return x + y ; // return statement} ;if ( x != 0 ) { // if statement (not expression) print ( "assert false\n" ) ; // ...
Literal控件的使用 自己在做网页的时候,总结的一点东西
<Literal> <ID>type</ID> 属性类型</ToolTip> <Default>int</Default> </Literal> <Literal> <ID>property</ID> 属性名</ToolTip> <Default>MyProperty</Default> </Literal> </Declarations> ...
001-glib-gdate-suppress-string-format-literal-warning.patch 001-glib-gdate-suppress-string-format-literal-warning.patch 001-glib-gdate-suppress-string-format-literal-warning.patch
天轰穿系列教程之-40HiddenField、LinkButton、Literal天轰穿系列教程之-40HiddenField、LinkButton、Literal天轰穿系列教程之-40HiddenField、LinkButton、Literal天轰穿系列教程之-40HiddenField、LinkButton、...
<Literal> <ID>type</ID> 属性类型</ToolTip> <Default>int</Default> </Literal> <Literal> <ID>property</ID> 属性名</ToolTip> <Default>MyProperty</Default> </Literal> </Declarations> ...
在ThinkPHP中可以使用literal标签来防止模板标签被解析,例如: 复制代码 代码如下:<literal> ”$name> value1 ”$name>value2 <else> value3 </if> </literal> 上面的if标签被literal标签包含,因此if标签里面的...
css-literal-loader, 将CSS标记的模板文本解析为CSS文件 css-literal-loader用于提取和处理其他文件中定义的css的web pack加载器和babel插件。"inline CSS",它只适用于 CSS 。PostCSS 。LESS 。tlb或者任何它的他...
快乐回忆 路由器模块解析路径并从匹配路径中提取参数。 这个模块做相反的hapi :给定一个hapi路径和一个表示路径参数的查询对象,返回一个格式化的路径 使用 var hapiRecall = require('... // => '/bar/literal/bee'
选项卡的精确定位 准确的定位你想要的选项卡,如果出现的滚动条 相应的将滚动条滚动想要的内容出现在可视区域。
StringLiteral stringLiteral = ast.newStringLiteral(); stringLiteral.setLiteralValue("中国"); //将其作为引用方法参数 methodInvocation.arguments().add(stringLiteral); //创建变量 ...
<asp:Literal ID="LiteralPager" EnableViewState="false" runat="server"> <a href='{3}&page={1}'> <img src="images/preview.gif" width="46" height="15" /> </a>{0}<a href='{3}&page={2}'> ...