I've a relatively small problem.
I'm developing and interface between my application and a third party program. The communication between both of them is made by SOAP webservices. They have provided me the wsdl that they are going to use to receive AND send data. I've create the service interface and the client with the wsdl.exe tool, and there are no errors or warnings while the generation.
The problem comes from the generated code namespace. Instead of using the one defined in the interface, it uses the tempuri.org one.
Ok, no big deal, I can define the namespace in the
[ServiceContract (Namespace = "theDesiredNamespace")]
The problem is that i want to provide access to my webservice method from
http://theDesiredNamespace/myMethod
and instead my service provides it at:
http://theDesiredNamespace/nameOfTheInterface/myMethod
where nameOfTheInterface is the name of the interface generated automatically by the wsdl tool.
Any advice on how i can handle this? I know the easiest solution would be to actually send my new wsdl version to the third party (as it should be done) but I don't really have a choice.
Is there any workaround to this problem?
WSDL.EXE is for legacy ASMX web services, not for WCF (which is what you're using when you use [ServiceContract]).
Although it may look like a URL, the XML namespace has nothing to do with the location on the web. You want to use a single namespace like http://www.company.com/webservices/applicationName/serviceName/. You can then access your service at whatever URL you like. There is no relation between XML Namespace and the URL of the service.
Related
I have code that calls a web service. We'll say a "3rd party" web service. So I can get the wsdl for this service, in fact I've generated a proxy class using this wsdl.
The requirement that I'm trying to meet is this: Create a web service that LOOKS just like the above mentioned one, but does other stuff. So the web service URL will be changed in a config file/database, to allow switching between the two web services.
What I'm not sure about is how I can use that proxy class that I generated, or some other method, so that the namespacing and data contract look exactly the same. I don't know much about this and these are terms that colleagues have tossed out there. I only need to actually implement one of the web service's methods in my version.
Build site with any technology you know of and return responses that match that service.
Note that if you just need to return static enough responses for occasional testing you can use Fiddler as it allows to return arbitrary responses instead of real once.
In my application, end user can fetch the data from any SOAP based web services and use it in the application. The application provides an option to register the service on fly. The application examine the service, show available operations along with parameter, finally execute the selected operation and use the response, of course everything will be on the fly. There are few steps need to be follow in order to achive that:
Discover the service through WSDL
Examine it and select a method
Build required parameter values
Execute the service
Handle the response
I am able to discover the service on the fly using some WCF classes like DiscoveryClientProtocol, WsdlImporter, ServiceDescription, ServiceContractGenerator, etc. Now, I want to execute them and take the response XML that is available inside SOAP Body.
I am able to execute it by generating the Assembly at runtime using above library and execute a method through reflection. This solution works fine if I have to do everything in single-shot on a box. But it adds complexity when we scale-out. That means, one server generates the proxy, another one use the proxy and consume the services.
Yes, we can keep newly generated assembly somewhere in shared location and use them. But I want to avoid them. We want to keep service definition locally somewhere in DB, execute it without generating assembly and just consume the XML available inside SOAP body.
Appreciate the advice in advance on how to achieve this?
To communicate with WCF services without code generation you use the ChannelFactory< T > where T is the service interface.
Obviously in your case the service interface is not known at compile time so your objective would be to dynamically generate this type, or better yet use a custom ChannelFactory implementation that does not rely on strong typing and lets you call methods in a dynamic or programmatic way.
You can use the WsdlImporter to import the WSDL at runtime and which can give you the ContractDescriptions. From there you might be able to use ContractType as your service interface but I'm not sure. You may need to write your own ChannelFactory...
You can implement ChannelFactory to your abstract generic BaseFactory class which has override CreateDescription method to set Binding and Endpoint for ChannelFactory.ServiceEndpoint. You can pass your configuration interface which has Binding, Endpoint and Credentials to this abstract class. So you can have a dynamic proxy for a wcf service.
This is going to be a bit long so please bear with me.
I have been beating my head against this issue for quite some time. I am not very experienced in web services from a client and am having real issues setting this up. What I have is a web service from a third part hosted on a site. The service is a WSDL service written in JAVA. I am trying to connect to it from y .NET solution and consume the web services provided. One of the requirements from the vendor is to "set the Headers parameter to 'XXXX' and the value to 'YYYY'"
I am having some serious issues doing this. My first attempt was to simply add the web service as a web reference in Visual Studio (2012). There were no methods exposed by the service to set the header so I simply called a function to see what happened. I received an exception "No SOAP Headers specified".
Next I attempted to create a manual proxy using SVCUTIL.exe. I think there may be something wrong with the web services because I receive errors "Cannot import wsdl:binding": "Detail: The required WSDL extension element 'binding' from namespace 'http://schemas.xmlsoap.org/wsdl/http/' was not handled."
However, the class and config files are still created. Anyways, I imported the class into my web app and updated my web.config with the necessary settings from the proxy config. I declare an instance of the needed class and this is where things go south for this attempt. When declaring an instance of the class I receive the error "could not find default end point element that references contract "ContractName" in the ServiceModel client configuration. This might be because no endpoint element matching this contract could be found in the client element". I am wondering if perhaps there is a problem with the services or they simply weren't designed for .NET. The other obvious option is I am doing something wrong. I would be happy to post the config file and such if you would like to see it (I just felt I had loaded this post enough as it is).
What I am really looking for is instructions (a tutorial would be awesome) on how to add a web service as a reference within Visual Studio c# application but being able to set the headers from within the code.
I am sorry for the length of this post.
Thank you for your help.
suppose when i have only wsdl file then how can i create proxy class just to call webservice various method. how webservice related all class and its property & method will be exposed in my c# apps. can anyone help guiding me. thanks
You would need to use the ServiceModel Metadata Utility Tool, or Visual Studio's Add Service Reference Dialog in order to generate a client proxy for the service with which you want to communicate. The generated proxy will provide classes that abstract the service contract, and you can program your client applications to interact with these classes.
There is an utility, it shipps with Visual Studio (since 2005, I think), called wsdl.exe
It's commandline, and can be used to generate proxy.
You can use WSDL.exe tool using command line.
i.e. WseWsdl3 WSDLPath /out:MyProxyClass.cs
if WseWsdl3.exe is unable to create the proxy class, there is still a way.
If you can run your service as a regular ASP.NET web application in IIS, it creates temporary ASP.NET files where the proxy class is nicely generated for you.
You can find it in folder:
C:\Windows\Microsoft.NET\Framework\vMAJOR.MINOR.BUILD\Temporary
ASP.NET Files\YOUR_WEB_APP.
There are some subfolders with random names, go to most recent one and look something like "App_WebReferences.XXXX.0.cs".
Before I venture down the path of creating one, I was wondering if anyone knows of a utility program which will take the REST Help page of a WCF Rest Service and create the relevant Client for C# consumption.
Similar to what svcutil.exe does for WCF Services or what wsdl.exe did for web services but for WCF REST Services
Kind Regards,
Andrew
EDIT Some more detail:
Please see this link: http://msdn.microsoft.com/en-us/library/dd203052.aspx
In the restful service using the WCF Rest Starter Kit Preview 2, they supply types which will be serialized. But My intention is be able to create clients form the help page which describes schemas. Clients could then be created for C#, JavaScript, ActionScript etc.. shearly as a strongly typed version of the restful service, not a requirement or necessity. It is a program or uitlity I am wondering exists which does this
I think you might be looking for the WebChannelFactory. It can generate a channel class based on a WCF-attributed REST interface.
Well, there will not be any use even if you would like to abstract. ALL Rest services can use HTTP verbs like GET, POST, PUT, DELETE
So, basically what your client can have is only a static class which can accept the end point, network credentials, a name value collection which needs to be passed and the verb to use.
This would be more of a utility class rather than a client.
I don't remember seeing WSDL or some contract based on which we can write clients for the REST services.
I hope you don't spend too much time basing your code on the current help page of a pre-release piece of code. Are you even sure this help page provides all the information you would need to produce clients?
Also, have you seen Prerelease 2 of the WCF REST Starter kit yet? If no, go look. There's new client-side technology in there.
Why would you create clients for a RESTful service? You don't need one - you just need to be able to initial HTTP requests. If you would like to call the same operations via SOAP or some other method then create a new endpoint for the service and a new contract and expose mex for it so that svcutil can consume it.