|
175 | 175 | servlet context path as appropriate).
|
176 | 176 | </para>
|
177 | 177 | <programlisting><![CDATA[http://localhost:8080/spring-ws/orders.wsdl]]></programlisting>
|
| 178 | + <note> |
| 179 | + <para> |
| 180 | + All <interfacename>WsdlDefinition</interfacename> bean definitions are exposed by the |
| 181 | + <classname>MessageDispatcherServlet</classname> under their bean id (or bean id) with the |
| 182 | + suffix <literal>.wsdl</literal>. So if the bean id is <literal>echo</literal>, the host name |
| 183 | + is "server", and the Servlet context (war name) is "spring-ws", the WSDL can be |
| 184 | + obtained via <uri>http://server/spring-ws/echo.wsdl</uri> |
| 185 | + </para> |
| 186 | + </note> |
178 | 187 | <para>
|
179 | 188 | Another cool feature of the <classname>MessageDispatcherServlet</classname> (or more correctly the
|
180 | 189 | <classname>WsdlDefinitionHandlerAdapter</classname>) is that it is able to
|
|
214 | 223 | The next application context snippet shows how to create such a dynamic WSDL file:
|
215 | 224 | </para>
|
216 | 225 | <programlisting><![CDATA[
|
217 |
| -<bean id="holiday" class="org.springframework.ws.wsdl.wsdl11.DynamicWsdl11Definition"> |
218 |
| - <property name="builder"> |
219 |
| - <bean class="org.springframework.ws.wsdl.wsdl11.builder.XsdBasedSoap11Wsdl4jDefinitionBuilder"> |
220 |
| - <property name="schema" value="/WEB-INF/xsd/Orders.xsd"/> |
221 |
| - <property name="portTypeName" value="Orders"/> |
222 |
| - <property name="locationUri" value="http://localhost:8080/ordersService/"/> |
223 |
| - </bean> |
224 |
| - </property> |
| 226 | +<bean id="orders" class="org.springframework.ws.wsdl.wsdl11.DefaultWsdl11Definition"> |
| 227 | + <property name="schema" ref="schema"/> |
| 228 | + <property name="portTypeName" value="Orders"/> |
| 229 | + <property name="locationUri" value="http://localhost:8080/ordersService/"/> |
| 230 | +</bean> |
| 231 | +
|
| 232 | +<bean id="schema" class="org.springframework.xml.xsd.SimpleXsdSchema"> |
| 233 | + <property name="xsd" value="/WEB-INF/xsd/Orders.xsd"/> |
225 | 234 | </bean>]]></programlisting>
|
226 | 235 | <para>
|
227 |
| - The <classname>DynamicWsdl11Definition</classname> uses a |
228 |
| - <interfacename>Wsdl11DefinitionBuilder</interfacename> implementation |
229 |
| - to generate a WSDL the first time it is requested. |
230 |
| - Typically, we use a <classname>XsdBasedSoap11Wsdl4jDefinitionBuilder</classname>, which builds |
231 |
| - a WSDL from a XSD schema. This builder iterates over all <literal>element</literal> elements |
232 |
| - found in the schema, and creates a <literal>message</literal> for elements that end with the |
| 236 | + The <classname>DefaultWsdl11Definition</classname> which builds |
| 237 | + a WSDL from a XSD schema. This definition iterates over all <literal>element</literal> elements |
| 238 | + found in the schema, and creates a <literal>message</literal> for all elements. Next, it creates |
| 239 | + WSDL <literal>operation</literal> for all messages that end with the |
233 | 240 | defined request or response suffix. The default request suffix is <literal>Request</literal>;
|
234 | 241 | the default response suffix is <literal>Response</literal>, though these can be changed by
|
235 | 242 | setting the <property>requestSuffix</property> and <property>responseSuffix</property>
|
236 | 243 | properties, respectively.
|
237 |
| - Next, the builder combines the request and response messages into a WSDL |
238 |
| - <literal>operation</literal>s, and builds a <literal>portType</literal> based on the operations. |
| 244 | + It also builds a <literal>portType</literal>, <literal>binding</literal>, and <literal>service</literal> based on the operations. |
239 | 245 | </para>
|
240 | 246 | <para>
|
241 | 247 | For instance, if our <filename>Orders.xsd</filename> schema defines the
|
|
244 | 250 | <literal>GetOrdersRequest</literal> and <literal>GetOrdersResponse</literal> message, and a
|
245 | 251 | <literal>GetOrders</literal> operation, which is put in a <literal>Orders</literal> port type.
|
246 | 252 | </para>
|
| 253 | + <para> |
| 254 | + If you want to use multiple schemas, either by includes or imports, you might want to use the |
| 255 | + <classname>CommonsXsdSchemaCollection</classname>, and refer to that from the |
| 256 | + <classname>DefaultWsdl11Definition</classname>, like so: |
| 257 | + </para> |
| 258 | + <programlisting><![CDATA[ |
| 259 | +<bean id="schemaCollection" class="org.springframework.xml.xsd.commons.CommonsXsdSchemaCollection"> |
| 260 | + <description> |
| 261 | + This bean wrap the messages.xsd (which imports types.xsd), and inlines them as a one. |
| 262 | + </description> |
| 263 | + <property name="xsds"> |
| 264 | + <list> |
| 265 | + <value>/WEB-INF/xsds/Orders.xsd</value> |
| 266 | + <value>/WEB-INF/xsds/Customers.xsd</value> |
| 267 | + </list> |
| 268 | + </property> |
| 269 | + <property name="inline" value="true"/> |
| 270 | +</bean>]]></programlisting> |
| 271 | + <para> |
| 272 | + When the <property>inline</property> property is enabled, it folows all XSD imports and includes, |
| 273 | + and inlines them in the WSDL. This greatly simplifies the deloyment of the schemas, which still |
| 274 | + making it possible to edit them separately. |
| 275 | + </para> |
| 276 | + <para> |
| 277 | + The <classname>DefaultWsdl11Definition</classname> uses WSDL providers in the |
| 278 | + <package>org.springframework.ws.wsdl.wsdl11.provider</package> package and the |
| 279 | + <classname>ProviderBasedWsdl4jDefinition</classname> |
| 280 | + to generate a WSDL the first time it is requested. |
| 281 | + Refer to the class-level Javadoc of these classes to see how you can extend this mechanism, |
| 282 | + if necessary. |
| 283 | + </para> |
| 284 | + |
247 | 285 | </section>
|
248 | 286 | </section>
|
249 | 287 | <section>
|
|
0 commit comments