I'm trying to use NeoLoad to generate and execute SOAP requests and upon supplying the WSDL, it doesn't seem to like the imports that they are referring to.
I'm thinking I would need to flatten the WSDL generated by the WCF service.
Are there any techniques I could use to flatten it?
I've been reading:
http://blogs.msdn.com/dotnetinterop/archive/2008/09/23/flatten-your-wsdl-with-this-custom-servicehost-for-wcf.aspx
http://blogs.thinktecture.com/cweyer/archive/2007/05/10/414840.aspx
Would this be something I should be trying out?
Yes, some clients have trouble with the (standards-compliant) way that Microsoft has implemented the WSDL and XSD.
Those two articles you mention are great starting points - they show how you can get your WCF service to render out a flattened WSDL (which includes the XSD inside it).
The same goes for WCF Extras on Codeplex, which also does a few more things in addition (most notably exporting the XML comments from your C# or VB.NET code into the WSDL). Highly recommended.
Related
I have to connect to the service provided by the third party client. The issue is to do that dynamically. When I generate proxy on a static way with Add web reference everything is OK. With usage of WsdlImporter and CodeDom I get some strange generated classes (for proxy client per instance).
Then I saw in case of Add Service Reference I got the same values as with WsdlImporter. My conclusion WsdlImporter is used by svcutil.exe.
Does someone knows what is here so different ?
Service is using SOAP1.1
They're just two different tools. svcutil.exe actually uses WsdlImporter under the covers (which is why the two outputs are the same). Add Web Reference uses the same classes as the tool wsdl.exe (I don't know which class they use internally, but you can use a tool such as ILSpy or reflector to see what wsdl.exe uses.
"Add Web Reference" is part of the legacy ASMX support, not part of WCF. Don't use it if you have a choice.
The solution of this problem is to use ServiceDescriptionImporter. This importer is working as wsdl.exe .
Additionally, XSD schemes have to be imported (also take care on nested schemas). Great sample for this is on the following :
http://forums.asp.net/post/1740748.aspx
Thank you all, it works now
I have a WSDL file from a published ASMX web service. What I am after
is creating a mock service that mimics the real service for testing purposes.
From the WSDL, I used SvcUtil.exe to generate code. Apparently it also generates
the server side interface.
Well the issue is that it generates very chunky interfaces. For example, a method
int Add(int, int) is showing up in the generated .cs file as AddResponse Add(AddRequest). AddRequest and AddResponse have a AddRequestBody and AddRequestResponse and so on.
The issue is that, to implement, I need to create the body and response instances for each method, even when I just want to return a simple int result.
Why can't it generate the method signature properly? Is there a better way of generating WCF Server side interface/contracts from WSDL?
The message structure you are describing is caused by two things:
better interoperability across web service stacks and their programming models (RPC vs messaging);
flexibility to accommodate new parameters into existing web services.
You are not the first one to complain about it, or the last. It's a WSDL binding style commonly called the document/literal wrapped pattern. It produces document/literal web services and yet also supports an RPC programming style. It's very "WS interoperability friendly", so to speak...
The WS-I Basic profile specifies that the soap:body must have only one child element and in this case it's a wrapper for the operation name that's being invoked. The parameters of the call are packed into only one element as a best practice since it's more flexible to later changes. In case of WCF you usualy end up with a MessageContract which has one MessageBodyMember which wraps all the parameters.
Basically, you are seeing the results of web service battles fought long time ago.
Here is some extra reading on the subject (and that's just the tip of the iceberg):
Which style of WSDL should I use?
RPC/Literal and Freedom of Choice
My Take on the Document/Literal 'Wrapped' Idiom
As a contrast with a asmx file, how can I get in the visual service page that shows the available methods on the service?
http://soweb.adwiza.com/person.asmx
Versus
http://soweb7.adwiza.com/remote/person.svc
WCF does not have the list of operations page. The information is available by looking at the raw WSDL http://soweb7.adwiza.com/remote/person.svc?WSDL.
If you want a friendlier way to see that information as well as the ability to invoke the service (which the old ASMX page gave for simple types) then you can use the WCF Test Client (WcfTestClient.exe).
It will show you all of that information:
I understand this is a basic topic but never done this before starting from wsdl.
I am being handed a wsdl file and a bunch of xsd with the types definitions. I don't have a clue if they were created from a WCF service (I guess so because of the split out format) but I do need to create a WCF service that implements the contract.
Question: How do I get the service contract interface?
I know about wsdl.exe and svcutil.exe - but not too familiar with what's what.
I guess after that all that's left is implementing the service contract.
Any help appreciated!
P.S. I had another question about this but I tried to put too much stuff in the same question - so let's keep it simple for now.
You have two choices:
Option 1: Use the svcutil.exe utility on the command line. It should be installed in your C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin directory (or something similar, depending on machine and OS you have)
Use svcutil -? for the list of all the many parameters. Basically, in its most simple form, use:
svcutil (name of your service).wsdl (name of your datafile).xsd
and that will create a corresponding (name of your service).cs C# file with the service and data contracts, and a sample config file.
The resulting *.cs file (or *.vb, if you want VB.NET) will contain the service contract (the methods, resulting from the WSDL) and the data contracts (the data portion, coming from the XSD) for your service.
Option 2: Use the "Add Service Reference" dialog in Visual Studio (on the "References" node in your Solution Explorer) and just enter the file name of your WSDL file:
This will create a service reference, which is basically the same as the output from the svcutil.exe utility - plus a few helper classes and files for Visual Studio.
Unfortunately, in both cases, the import will create a horribly overloaded config file which is probably one of the reasons lots of programmers think WCF is awfully complicated - it's really not, but these two import tools just do a horrendously bad job on creating the basic config for you.... don't let that scare you away!
If the Add Service Reference for the WSDL doesn't automatically convert all relevant and necessary XSD files, you might need to add those to your project, and then use something like XSD2Code to convert those to C# (or VB.NET) classes for you.
The wsdl.exe is the deprecated utility to convert a WSDL file into a ASMX (ASP.NET webservice) stub - don't use that anymore, use svcutil.exe or Visual Studio's Add Service Reference for WCF.
As for how to create a proper and minimal WCF config, check out the DotNet Rocks TV Show #122 with Miguel Castro entitled Extreme WCF. Miguel presents a great way to structure your WCF projects, and to create just as much config as is really needed (and thus can be understood a lot better than the generated mess by svcutil).
Does anyone know of any problems with using WCF to expose a SOAP interface for non .NET clients? For example incompatibilities with other SOAP libraries?
This is so that the SOAP interface can be exposed for third parties to integrate with our software.
Some of the problem areas I've encountered with WCF:
It generates WSDL that is split
across multiple URLs. That is, one
part of the schema is at one URL,
another is at a different URL, etc.
The "main" WSDL URL (the one with
just "?WSDL" after the service name)
references the others via xsd:import
elements. Many SOAP clients (eg pre-.NET Delphi) have enormous difficulty with this idiom. So you really have to "flatten" your WSDL in order to achieve interoperability in practice. One solution is given here.
WCF doesn't generate XML namespaces
the same way as, say, ASMX web
services. WCF has a tendency to
place any service or data contract
into a namespace of its own
choosing. Again, some SOAP clients have difficulty with this. You can increase you interoperability level by adding an explicit namespace to your ServiceContract and DataContract attributes.
Many SOAP clients won't handle
faults as nicely as WCF clients. For example,
the proxy generation code won't
create client-side objects for the
faults declared in the WSDL. The
faults will still be transmitted to
the client, of course, but the
client then has to do more work to
figure out what kind of fault it
was.
versions of the WS-* standards stack can also be an interoperability issue - for example the version of WS-Addressing (2003) supported by some java implementations eg Oracle BPEL is not supported by WCF which supports the later draft and 1.0 versions but not the earlier 2003 one
Generally everything works fine. It will obviously depend on the client you're using - not everyone implement SOAP properly.
P.S. Could you please rephrase your question if you hope for more specific answer?