I want to create a wsdl by using 3 xsd-files. How do you that?
I tried this in the command prompt:
wsdl.exe /language:cs /parameters: c:\myService\Contract\HeaderData.xsd c:\myService\Contract\MyData.xsd c:\myService\Contract\Messages.xsd /out: MyWsdl.wsdl
What do I wrong?
I believe that there's a misunderstanding here. Most likely the wsdl.exe in your illustration refers to Microsoft's tool, which is described as:
The Web Services Description Language tool generates code for XML Web services and XML Web service clients from WSDL contract files, XSD schemas, and .discomap discovery documents.
From what you seem to imply by asking the output to be a WSDL file, I can safely assume that you really try to create a WSDL file starting from XSD files. Below I am trying to explain why you cannot do that that easy, and what options you have.
The diagram below shows you the model behind the WSDL 1.1 specification.
Your XSDs fit exactly, and only under types. It WSDL terms, types represent your type system used to describe the parts that make up messages, which are then used to describe input/output and faults of operations organized as ports (abstract interfaces) bound to application/transport protocols, and ultimately made (physically) accessible as services at one or more network endpoints.
To generate WSDL(s) out of XSD(s), you realized by now that you need to provide some more data to a tool that would automatically generate a WSDL for you. For example, what operations you want to describe in your WSDL? For each one of them, what's the input, most likely the output and maybe one or more faults? How would you group them (portType = interface)? What binding do you want to use: HTTP, SOAP? What version of SOAP? SOAP over: HTTP, MQ? SOAPAction? How many WSDL files: 1, or maybe 3?
Some tools may ask you a series of questions (data entry/wizards) along the above lines and then create the WSDL(s) for you. Others, use predefined patterns in the implementation of XSD schema constructs (for example, IFX has a certain way to define Request/Response elements) so based on those assumptions a specialized tool such as QTAssistant (I am associated with it) would ask you less questions, while still creating the WSDLs.
I remember one or two online tools that were able to allow the user to upload XSD files and then create WSDL after prompting you a couple of questions, but I can't seem to find them anymore... kind of like this one...
From my understanding, you don't go xsd->wsdl, but I could be wrong.
Generating a WSDL from an XSD file might help clear it up for you though.
You cannot auto-generate a WSDL from an XSD in this manner. In order to create the WSDL, you need to start with a new WSDL and import this XSD.
The XSD defines the types of data that are available for services. Some XSD is usually embedded in a WSDL, some are imported specifically.
An alternate way is to use the XSD in C# to generate a service, and then extract the concrete WSDL from that service, but this is not preferred as many teams prefer contract first web services.
Related
I am new to WCF service. I am aware about three ways to generate proxies.
Using Service reference
Using SvcUtil
Using ClientBase
But I am confused in which case I should use which type. In my case I have to generate proxies for third party service for which I don't have service code. I don't want to use add service reference because it gives me following issue. Mentioned in this stackoverflow question. So I want to use clientBase. But I think I cannot use it without using service reference. I am pretty much confused when should we choose which kind of proxies.
In my case I have to generate proxies for third party service for which I don't have service code.
I will have multiple apps using this service.
In that case you are better off using SvcUtil because it can generate a single library that all of your projects can use, even if they are .NET libraries. After it is generated you can always go in and tweak it.
Add service reference on the other hand is fine for a single .exe but as you have discovered, is annoying for multiple apps as you need to repeat the process and you end up with multiple definitions of WCF types that is just going to increase maintenance.
Just be sure to leave WCF client config in the app.config of your applications and not your app.config of your class library (as the former may not be read).
If your vendor had followed "WCF the Manual Way… the Right Way" it would have made your life easier.
SOAP purists would argue however that the only thing the vendor provides is a SOAP WSDL XML file from which you are required to generate your types anyway. (sadly, the default behaviour in .NET is back-to-front)
I have a server in Java which has some web-services. WSDLs (and XSDs) are generated from java using javatows from apache cxf.
Some services share types, and I would like to share these types also in wsdl is it possible?
After that I want to generate c# code using svcutils, but because in each WSDL are some copies of the same types svcutil tell error that this complex type has already been declared...
I know that I can use /namespace switch but I do not want this because that way I will have the same classes generated in different namespaces... I would like to have one class in common namespace...
I suggest you create a common.xsd file (if possible) containing the shared structures which are then included in each WSDL file for each one of the services.
<include schemaLocation="common.xsd"/>
I believe that will overcome the problems you're having when generating client proxy code with svcutil.exe.
Is it possible to generate wsdl with use of SvcUtil or any other tool. I know I can view wsdl in browser while running the service but I need to have one wsdl file that doesn't have xsd:import directive but rather specifies all the information in this file.
If it's a one off you could manually construct the single WSDL file. But that's no fun. :)
Another way is to create an endpoint behavior. See Improving WCF Interoperability: Flattening your WSDL for the full details.
I'm pulling together some services in C# that have to match specific data format; e.g. string lengths, various enumerations and formatting. I have the back-up approach to validate post the SOAP call and respond with friendly messages and pre-defined error codes, but I would like to place additional information into the WDSL (so it is clear that field x can only be 15 alpha characters only with no numbers or punctuation for example).
Is this possible, if so are there any examples and or tutorials?
Take a SOAP message, generate a XSD out of it, and then edit the XSD until all your validation things are in there. Provide the XSD along with the WSDL to your customer.
When you both validate the messages using the same XSD the problem should be gone.
First of all, you should be aware that .NET does not validate SOAP messages against the schema in a WSDL. For instance, if part of your input message shows a maxLength of 50, there will be no error or exception when you are sent 51 instead.
Second, it is not possible to adjust your classes in such a way that you can control the exact schema. For instance, you cannot cause a maxLength attribute into the WSDL.
Third, if you must completely control the WSDL, then you need to write it by hand. You will never have complete control over the WSDL that .NET generates.
Finally, you seen to be talking about ASMX web services here. You should not be using ASMX web services for new development - they have been replaced with WCF.
I have created a schema as an agreed upon interface between our company and an external company. I am now creating a WCF C# web service to handle the interface.
I ran the XSD utility and it created a C# class. The schema was built in BizTalk, and references other schemas, so all-in-all there are over 15 classes being generated.
I put [DataContract} attribute in front of each of the classes.
Do I have to put the [DataMember] attribute on every single property?
When I generate a test client program, the proxy does not have any code for any of these 15 classes.
We used to use this technique when using .asmx services, but not sure if it will work the same with WCF. If we change the schema, we would want to regenerate the WCF class, and then we would haev to each time redecorate it with all the [DataMember] attributes? Is there an newer tool similar to XSD.exe that will work better with WCF?
Thanks,
Neal Walters
SOLUTION (buried in one of Saunders answer/comments):
Add the XmlSerializerFormat to the Interface definition:
[OperationContract]
[XmlSerializerFormat] // ADD THIS LINE
Transaction SubmitTransaction(Transaction transactionIn);
Two notes:
1) After I did this, I saw a lot more .xsds in the my proxy (Service Reference) test client program, but I didn't see the new classes in my intellisense.
2) For some reason, until I did a build on the project, I didn't get all the classes in the intellisense (not sure why).
Neal, besides all the options John has given you, you should also check out the WCSF.blue tool on Codeplex: http://wscfblue.codeplex.com/
It's a "contract first" approach to doing WCF, and one of the many options it offers is to create a WCF DataContract file from your XSD:
This then pops up a dialog in which you can set a slew of parameters on how to create your C# class file from the XSD:
Quite useful, even if you want to use it for nothing more than converting XSD to C# classes that work as WCF DataContracts :-)
Also see this blog post for more explanations on the XSD DataContract generation process.
Classes that use [DataContract] will serialize to a very limited schema. For instance, there will be no attributes, only elements. This is intentional, and is done for performance and interoperability.
In general, a schema of the kind you may be working with may be much more complicated. Such a schema will not be usable with the Data Contract Serializer. You will need to use the XML Serializer instead.
In particular, don't edit the classes created by XSD.EXE. In fact, you should never edit generated code, as your edits will be removed as soon as the code is generated again. These classes should already have the attributes on them that will be needed for WCF to work with them.
What happens if you just use them as-is?
I'm shocked that no one pointed me to this utility, which I believe is what I was asking for:
http://msdn.microsoft.com/en-us/library/system.runtime.serialization.xsddatacontractimporter.aspx
I haven't tried it yet, but it looks like XsdDataContractImporter was what I was looking for, or the SVCUTIL with the /dataContractOnly flag.
I learned this when interviewing a candidate yesterday. She said DataContract serialization is faster and would be preferred to use.
Neal
Re: your XsdDataContract class mentioned in your followup, IMO, This is a niche class (as is ServiceContractGenerator etc) so i'm not surprised no one pointed you to it.
You still need to package it up to make it really useful. I'm pretty sure that code sample covers only very basic use cases so I would expect to do a lot of work with that to get it to a proper working state. . And like i mentioned on the WSCF forum, Svcutil, wscf, xsd.exe and others all use this class and related classes in the code gen process.
Regards the serializer performance, there are really good posts on Youssef Moussaoui's blog on the different serializers and their performance especially
http://blogs.msdn.com/youssefm/archive/2009/07/10/comparing-the-performance-of-net-serializers.aspx
There’s also a really good discussion here on Connect regarding the two serializers (XS and DCS) and a useful point that XS is still the way forward for WSDL/XSD First development as the DCS is only intended to support a simplified programming model and thus doesn’t support various xml constructs.
http://connect.microsoft.com/wcf/feedback/ViewFeedback.aspx?FeedbackID=451277
Hope this helps,
Cheers,
Benjy