-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathreadme.txt
184 lines (152 loc) · 5.78 KB
/
readme.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
http://www.ibm.com/developerworks/library/ws-whichwsdl/
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:
1. RPC/encoded
2. RPC/literal
3. Document/encoded
4. Document/literal
1. 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>
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>
Strengths
1. The WSDL is about as straightforward as it's possible for WSDL to be.
2. The operation name appears in the message, so the receiver has an easy time dispatching this message to the implementation of the operation.
Weaknesses
1. The type encoding info (such as xsi:type="xsd:int") is usually just overhead which degrades throughput performance.
2. 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 the soap:body contents comes from WSDL definitions
3. Although it is legal WSDL, RPC/encoded is not WS-I compliant.
2. RPC/literal WSDL for myMethod
The use in the binding is changed from encoded to literal. That's it.
<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>
RPC/literal SOAP message for myMethod
<soap:envelope>
<soap:body>
<myMethod>
<x>5</x>
<y>5.0</y>
</myMethod>
</soap:body>
</soap:envelope>
Strengths
1. The WSDL is still about as straightforward as it is possible for WSDL to be.
2. The operation name still appears in the message.
3. The type encoding info is eliminated.
4. RPC/literal is WS-I compliant.
Weaknesses
1. 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 the soap:body contents comes from WSDL definitions.
3. Document/encoded
Nobody follows this style. It is not WS-I compliant. So let's move on.
4. Document/literal
The WSDL for document/literal changes somewhat from the WSDL for RPC/literal
<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>
Document/literal SOAP message for myMethod
<soap:envelope>
<soap:body>
<xElement>5</xElement>
<yElement>5.0</yElement>
</soap:body>
</soap:envelope>
Strengths
1. There is no type encoding info.
2. You can finally validate this message with any XML validator. Everything within the soap:body is defined in a schema.
3. Document/literal is WS-I compliant, but with restrictions
Weaknesses
1. 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.
2. The operation name in the SOAP message is lost. Without the name, dispatching can be difficult, and sometimes impossible.
3. WS-I only allows one child of the soap:body in a SOAP message but here soap:body has two children
5. Document/literal wrapped
<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>
Document/literal wrapped SOAP message for myMethod
<soap:envelope>
<soap:body>
<myMethod>
<x>5</x>
<y>5.0</y>
</myMethod>
</soap:body>
</soap:envelope>
Strengths
1. There is no type encoding info.
2. Everything that appears in the soap:body is defined by the schema, so you can easily validate this message.
3. Once again, you have the method name in the SOAP message.
4. 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.
Weaknesses
1. The WSDL is even more complicated.
Literal use Model
1. When using a literal use model, the body contents should conform to a user-defined XML-schema(XSD) structure.
2. You can validate the message body with the user-defined XML-schema,
3. You can also transform the message using a transformation language like XSLT.
Encoded use Model
1. With a (SOAP) encoded use model, the message has to use XSD datatypes.
2. structure of the message need not conform to any user-defined XML schema.
3. Difficult to validate the message body or use XSLT based transformations on the message body.