I spent a couple of last days to design wsdl for third-party systems in my new project. It got me some painful moments, so i decided to write a post about problems i met and may be some thoughts i gained during the process. I ll try to emphasize them below for more effect.
The idea was that i had an interface (not in C#-syntax or so, but described by words/UML) and i needed to create a wsdl for third-party systems to implement the interface. Show/hide
The idea was that i had an interface (not in C#-syntax or so, but described by words/UML) and i needed to create a wsdl for third-party systems to implement the interface. Show/hide
I started with designing wsdl with eclipse. I tried Altova XML Spy also and it looks pretty suitable, but i like eclipse more because of its color-scheme :) I pretty simple draw messages, ports. bindings and services. Its quite easy and shouldn't confuse you if you have basic understanding of wsdl format. Otherwise i recommend you read carefully its desciption at w3c page.
I met some problems designing schema for my file.
Thought 1. "Add web reference" function of Visual Studio is really useful to check that your wsdl is correct. This option is called "Add service reference" in Visual Studio 2010, but you can click "Advanced" on the first screen and then "Add web reference" on the opened dialog to get to the familiar window. You can then periodically update your reference to be sure that you are on a right way.
Thought 2. You can add web reference by providing wsdl file system path at URL field of the "Add web reference" window. It's not so obvious feature, i got familiar with it half yaer ago. "URL" is not really good name for this field and by default everyone expects traditional http-reference, i beleive.
Thought 3. "Traditional" error message for adding/updating reference at visual studio is pretty poor and it never gives you understanding of real problems with your file. You can use command-line wsdl.exe to generate proxies and it usually provides you better description of error.
I used PowerDesigner to design a class model for my task and it has a powerfull feature to generate xml model. Even thouth there aren't many options to configure behavior of the generation process, anyway, it could save you time if your model is full of entities. You can use this generated schema as a basis for your future wsdl design.
Thought 4. It could be quite usefull to separate your wsdl with some xsd types you plan to change futher. I copied my afutogenerated scheme in separate xsd-file and included it into my wsdl. To include xsd into the wsdl you should use xsd:import element at the wsdl:types/xsd:schema level. Schema location attribute determines your xsd file to include. When deployed, it should point to the http-based location of xsd (look at wsdl-s generated by wcf/asp.net!), but during wsdl design process, target it at file system location - smth like "D:\Development\..." and vise versa.
I faced some difficulties determining correct combination of namespace/targetnamespace attributes at import element/imported xsd/native document, so i just place here my config of this values:
imported xsd:
<xs:schema targetNamespace="http://me/IAdapter.v1/Model"
elementFormDefault="qualified"
xmlns="http://me/IAdapter.v1/Model"
xmlns:mstns="http://me/IAdapter.v1/Model"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
>
wsdl:
<xsd:schema targetNamespace=" http://me/IAdapter.v1/" xmlns:tns="http://me/IAdapter.v1/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wli="http://me/IAdapter.v1/Model">
<xsd:import schemaLocation="D:\Development\my.xsd" namespace="http://me/IAdapter.v1/Model"/>
and to reference types from imported document i use wli: prefix
<xsd:element name="Entity" nillable="true" type="wli:Entity" />
Thought 5. You can play with sequences, choices elements and minOccurs and maxOccurs attributes of the element and see in Visual studio's object browser how it understands various xsd constructs. unbounded as array, sequence as class field, choice as object-typed field and so on. Sometimes it's also useful to create a simple webservice with various input/output types to see how it visualized at wsdl.
Thought 6. Use svcutil to be sure that service could be created by your wsdl and how it will looks. When calling svcutil from command line, not forget to mention your xsd file - smth like
svcutil iadapter.wsdl model.xsd, cause it's not resolved by wsdl content.
I hope this post helps you in future wsdl design. Thank you for the reading:)
I met some problems designing schema for my file.
Thought 1. "Add web reference" function of Visual Studio is really useful to check that your wsdl is correct. This option is called "Add service reference" in Visual Studio 2010, but you can click "Advanced" on the first screen and then "Add web reference" on the opened dialog to get to the familiar window. You can then periodically update your reference to be sure that you are on a right way.
Thought 2. You can add web reference by providing wsdl file system path at URL field of the "Add web reference" window. It's not so obvious feature, i got familiar with it half yaer ago. "URL" is not really good name for this field and by default everyone expects traditional http-reference, i beleive.
Thought 3. "Traditional" error message for adding/updating reference at visual studio is pretty poor and it never gives you understanding of real problems with your file. You can use command-line wsdl.exe to generate proxies and it usually provides you better description of error.
I used PowerDesigner to design a class model for my task and it has a powerfull feature to generate xml model. Even thouth there aren't many options to configure behavior of the generation process, anyway, it could save you time if your model is full of entities. You can use this generated schema as a basis for your future wsdl design.
Thought 4. It could be quite usefull to separate your wsdl with some xsd types you plan to change futher. I copied my afutogenerated scheme in separate xsd-file and included it into my wsdl. To include xsd into the wsdl you should use xsd:import element at the wsdl:types/xsd:schema level. Schema location attribute determines your xsd file to include. When deployed, it should point to the http-based location of xsd (look at wsdl-s generated by wcf/asp.net!), but during wsdl design process, target it at file system location - smth like "D:\Development\..." and vise versa.
I faced some difficulties determining correct combination of namespace/targetnamespace attributes at import element/imported xsd/native document, so i just place here my config of this values:
imported xsd:
<xs:schema targetNamespace="http://me/IAdapter.v1/Model"
elementFormDefault="qualified"
xmlns="http://me/IAdapter.v1/Model"
xmlns:mstns="http://me/IAdapter.v1/Model"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
>
wsdl:
<xsd:schema targetNamespace=" http://me/IAdapter.v1/" xmlns:tns="http://me/IAdapter.v1/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wli="http://me/IAdapter.v1/Model">
<xsd:import schemaLocation="D:\Development\my.xsd" namespace="http://me/IAdapter.v1/Model"/>
and to reference types from imported document i use wli: prefix
<xsd:element name="Entity" nillable="true" type="wli:Entity" />
Thought 5. You can play with sequences, choices elements and minOccurs and maxOccurs attributes of the element and see in Visual studio's object browser how it understands various xsd constructs. unbounded as array, sequence as class field, choice as object-typed field and so on. Sometimes it's also useful to create a simple webservice with various input/output types to see how it visualized at wsdl.
Thought 6. Use svcutil to be sure that service could be created by your wsdl and how it will looks. When calling svcutil from command line, not forget to mention your xsd file - smth like
svcutil iadapter.wsdl model.xsd, cause it's not resolved by wsdl content.
I hope this post helps you in future wsdl design. Thank you for the reading:)
No comments:
Post a Comment