I have a scenario in which I'm going to need an arbitrary number of servers to provide the same SOAP web service. I would like to generate one set of proxy classes and be able to supply them with a location to point them at the different servers at runtime. Unfortunately, it looks as though the wsdl:port node (child of wsdl:service) requires the address of a specific server to be hardcoded. It appears that due to this the URL will be baked into my proxy classes. I know that I could potentially modify this by hand-editing the generated proxy classes, or modifying the code generation, but I'd really prefer not to resort to that. I feel like there's got to be a better way to solve this problem. I just want to decouple the interface definition from the location that the service will be residing at. I'm using VS2008 and C#.NET if that's of any help though best would be a language-agnostic (SOAP or WSDL specific) general solution to this problem.
Why don't you load balance the web servers and then create a DNS entry for the load balanced IP address....essentially creating a web farm. This will allow you to reference the hostname rather than the static IP addresses and if you ever need to change the IP address of the load balancer or the web servers it is a one time change. Plus you then have redundancy and performance control.
If you're using a WebReference (pre-WCF) to get to the web service, you can simply set the Url property on the web service proxy class after you create it.
For WCF, you can provide a different endpoint address to the proxy class constructor, rather than using the default (among other possible solutions).
No, in .NET you can change the URL at runtime.
Service svc = new Service ();
svc.url = "Value read from config. file or some such"
output = svc.method (input);
When you add a web reference to your project, it places the address of the web service into the .config file of your application / web application. You can then simply change this setting in the config file to point to a different web service location, assuming of course that the services are identical.
The easiest solution would be to use a software load balancer such as HAProxy. At more cost, you could use a hardware solution such as Big-IP.
Here's a hint on how to decide the URL of WSDL. I´m just changing the port but it´s of course possible to make it more advanced.
public class PortChangeReflector : SoapExtensionReflector
{
public override void ReflectDescription()
{
ServiceDescription description = ReflectionContext.ServiceDescription;
foreach (Service service in description.Services)
{
foreach (Port port in service.Ports)
{
foreach (ServiceDescriptionFormatExtension extension in port.Extensions)
{
SoapAddressBinding binding = extension as SoapAddressBinding;
if (binding != null && !binding.Location.Contains("8092"))
{
binding.Location = binding.Location.Replace("92", "8092");
}
}
}
}
}
}
Put that in your Add_Code and add the following reference to your web.config.
<webServices>
<soapExtensionReflectorTypes>
<add type="Dev.PortChangeReflector,App_Code"/>
</soapExtensionReflectorTypes>
</webServices>
I hope you can get new ideas of this.
Client proxies have URL property you can set at runtime. To make it simpler, wsdl.exe utility has /appsettingurlkey key. When you generate a client proxy, it's constructor will check the key in appSettings and set the service URL accordingly. I believe WCF has this feature as well.
However, I would agree with #Matt and suggest you consider load balancing as the best solution in the long run.
Is this for scaling (each server provides the same data) or
for same API different data on each server?
For 2, then you can do as above, just change the service URL in code.
For 1, you could use round-robin DNS (e.g. you see multiple servers with at the command line type nslookup www.google.com).
Related
Today I started delving into WCF. I took to the tutorial at https://msdn.microsoft.com/en-us/library/ms734712(v=vs.110).aspx
I walked through this tutorial up until where you host the service host. The tutorial segment here told me start up the service and then navigate to the uri specified in code. When I did that my connection was refused. After a short while of messing around, I found that the base address was specified in the app.config as something else entirely. Navigating to that URI followed by the endpoint name took me where I wanted to go. I don't know how that address was generated, and don't really care all that much. What I'm more interested in is what purpose setting the base URI on the services plays when it seemingly has no effect whatsoever, and the actual base URI that is used comes from the app.config. It's required by the constructor of the ServiceHost type... so you would think its important. Can someone explain this to me?
If you look carefully at the two constructors of ServiceHost that are expecting Uris, the Uri parameter is prefixed with params.
In C#, it means you can pass as many Uris as you want, including zero.
Passing no Uri is interesting if you want to use the of the app.config.
If you got no configuration, you pass a type or an object and some Uris.
Then WCF creates a service that is expose all the interfaces of the service on all the Uris.
For instance if you ve got two interfaces in you service and you call :
var host = new ServiceHost(typeof(HelloService),
"net.tcp://localhost:7000/service1",
"net.pipe://localhost:8000/service1",
"http://localhost:9000/service1");
You 'll get 2x3 exposed endpoints
Most of the time ServiceHost are built without providing addresses.
Config is made in XML.
Regards
I'm creating a .Net application to consume the Soap APIs.
I downloaded 2 partner wsdl files from 2 instances(production and sandbox). I think the only difference of the two APIs are their endpoints.
I then added the web references to a single application. When I write the method to consume the APIs, I don't want to duplicate the code to do same thing(insert,update...).
How can I design my code so maybe I can pass a parameter to let the method know which target instance should it talk to?
Thank you!
If the services are truly the same and just the endpoint differs, you should be able to use the generated client's Endpoint property to change the endpoint.
var client = new ServiceReference1.WebService1SoapClient();
client.Endpoint.Address = new System.ServiceModel.EndpointAddress("http://localhost:2850/WebService1.asmx");
I have a project that has a web service reference. I also have an app.config file that contains the binding information and endpoint. In one of my classes I'm invoking the the soap client object generated by the web service reference. I can initialize the soap client object to one of the endpoint I created in the app.config file. My confusion is with the constructor that takes in two strings. One is for the endpoint name in the app.config file and the other is the remote address. Why would I want to provide a remote address when I could just specifie it in the app.config file under the endpoint element?
And what if you'd like this address to be dynamic?
You surely DO wish to have an constructor taking the remote address as a parameter rather than sticking only with a static configuration.
The constructor which takes both the binding and the endpoint address gives you most flexibility. We often delete the static configuration from the configuration files and create the proxy instances using this particular, two-argument constructor.
This way, it's easiest to dynamically relocate your application without the need to touch anything.
It's an overload if you for some reason don't want to specify your configuration in the app.config file, it could be that you are storing it in a database or some other configuration mechanism.
I've been tasked with creating a class wrapper for a SOAP service, the idea is that you'll be able to treat it as a regular class. The main reason for this is that the WDSL for the SOAP service contains only one method and it's got 5 parameters and it's only kind of OO so you'd have to know all the method calls really well and it's a bit hard to remember them all.
OK, so I've tried adding a web reference, now web references can now be added as service references in VS 2010. You click add service reference advanced etc and it puts in a service reference. Great. Unfortunately if I try and access this from a class I can't.
I can build a console app and put code in the main procedure and access the method of the SOAP service fine but when I add a reference to a class library the intellisense won't allow me to select anything. I'd instantiate an instance like so:
SOAPService.webServiceService ws = new SOAPService.webserviceService();
ws.
and then the intellisense refuses to kick in. If I do the same in a web project or a console app then I can access it fine. I've added the namespace I've done all kinds of things. Also, I can add a web reference and get a DISCO file whenever I create a web project.
OK, also while I'm on the subject I also need to pass credentials to the web service in PHP.
The problem is that in the past I'd create some .net system credentials and add these and it would usually pass through if I was connecting to another .net service.
How should I be sending them to a PHP web service? I always get either invalid username/password combo errors or envelope malformatted error types
Thanks
Mr. B
So the intellisense is not working, but if you add the method in and try to use it does it work, or produce an error?
With regard to diagnosing authentication issues try using fiddler to view the SOAP messages that are being sent, and to view the reply. Do you have some other software that connects and authenticates to that service? Use fiddler to look at the SOAP messages and compare them to see if the header is different etc.
I'd normally do it like this,
using (Service service = new Service())
{
service.ClientCredentials.Windows.ClientCredential.Domain = "domain";
service.ClientCredentials.Windows.ClientCredential.Password = "password";
service.ClientCredentials.Windows.ClientCredential.UserName = "username";
}
Also with regard to the service working or not in general use fiddler if you have any problems, you can see the SOAP messages and it often gives you a clearer message.
I know in IIS you can turn on failed request handling that also gives you an insight from what is going on at the server end, perhaps you have some form of logging too for your php service?
it looks like I am not able to succesfully move my WCF proxy code into a separate DLL (as opposed to an EXE as I can see in all the examples I have run into).
The reason I am trying to do this is that I would like my proxy code to be invoked by different clients (possibly unmanaged code), which might not know anything about WCF but just need to access to the services (through a Facade exposed by the proxy maybe?).
Whenever I move the following code that creates a new proxy to a different VS project within the same solution, I get the dreaded "Could not find default endpoint element that references contract 'localhost.IRemoteCommandService' in the ServiceModel client configuration section" exception.
localhost.RemoteCommandServiceClient proxy =
new localhost.RemoteCommandServiceClient();
The same code works smoothly whenever used within a Main method in the same project where the proxy code is (auto-generated from Visual Studio).
Any idea? I hope that the client code of my proxy does not need to have the service model XML configuration as the proxy, because that would defeat the purpose I am moving the WCF proxy code into a DLL in the first place.
Thanks,
Stefano
The endpoints are indeed normally specified in the configuration file. You must look at the serviceModel data in the config file, and copy it into your calling app.config - or you need to use the more verbose way of creating the proxies in your code (i.e. specifying the address, binding, configuration etc through code to the constructors).
If you don't want to have to endpoint configuration on the client, you'll have to embed it into your proxy dll by specifying everything in code.
Another option would be to use a dynamic proxy, like this one, which would allow you to not have the serviceModel in your client apps.