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.
Related
I have built and deployed a web service onto a server – let’s call this WebService1. The web service has a number of utility methods which can retrieve, update, remove entries from a database.
I want to create another web service with different but similar functionality to WebService1. Let’s call this WebService2. It will also have the ability to retrieve, update, remove entries from a database, but the code inside the methods of WebService2 will be fundamentally different to WebService1, and WebService2 will be accessing a separate database to the database of WebService1.
If I set up a Service Reference using the endpoint address of WebService1 inside a C# Project, in theory should it be possible to only change the endpoint address to instead point to WebService2 without needing to update the Service Reference and still be able to call methods from the Web Service?
Obviously if I build and deploy WebService1 onto two different servers, it’s very simple to just change the endpoint address between the two services since they are using the exact same codebase, but should it be possible to do something similar by deploying WebService1 and WebService2 to two different servers if the two services have different code bases, provided the public facing web methods have the same method names with the same argument types and names and same return types? If this is possible, is there a fundamental difference between the two web services that would need the service reference to be updated as well as changing the endpoint address when changing between the two?
i guess you are using soap web services. soap technology uses XML serialization in order to send and receive and XML serialization depends on lots of thing like: class namespace, parameters type, ....
for instance if you are using different namespaces in the inputs you wouldn't be able to switch the address.
but i thinkyou are doing it wrong. if you use restful web services with json input you can easily switch between endpoints.
restful web services is more flexible than soap.
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.
I have a wcf service which provide a main configuration to all the other services in the system.
According to the configuration, I would like to create an instance (RegisterInstance\Type) at runtime.
I found only samples for how to do it by a configuration file.
I want to recieve the type from my configuration service.
All the types which I can get from the service are inherit from the same interface.
How can I do it without configuration file?
Thanks
If the service has to send back enough info for you to be able to perform a registration then you will need to pass back the fully qualified type name including the assembly name and then you can call Type.GetType to get hold of the type object which you can then pass into RegisterType
I can't say that I think its a good idea to use a WCF service to send configuration information across the wire in the way you plan to do it.
On the client side you would need to start a client (which needs to be configured correctly)
Call the "configuration service" and take whatever information you get from there and
Try to make sense of it in a local context (find types in assemblies that you might not even have in your local scope etc.).
Configure a local instance of your UnityContainer and then
resolve your object graph and start your application/service
Not a straight forward solution IMHO.
But if you want to stick with that setup: why not send the config xml directly? It's even possible to stream the xml if you need to.
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.
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.