CODEWITHSUNDEEP
c#web-services
karephul
karephul

Reputation: 1483

.NET webservice client from WSDL

I have a WSDL from which I generated the implementation of ClientBase namely MyService 


function void updateData(Data data){
   BasicHttpBinding binding = new BasicHttpBinding();
    // see there is naked username and password.           
   EndpointAddress address = new EndpointAddress("http://qa.farwaha.com/eai_enu/start.swe?SWEExtSource=WebService&SWEExtCmd=Execute&UserName=john&Password=johspassword");
   MyService service = new MyService(binding, address);
   try{
     service.update(data);
   }finally{
     service.close();
   }
}

Unfortunately, to call this web service I have to pass User name and password as shown in the code. so, my question is around best practices.

Given that its a Winform Application.

  1. How memory / CPU intensive is creating MyService object?

  2. If you suggest cashing the service, it will hold on to the EndpointAddress; which intern has a string with Username and Password. Which is not a good idea .. any work arounds?

  3. If I keep the code as such, service object will be garbage collected .. and there will be no trace of user name or password (as soon as GC runs)

This is a sample code, I have User Object which stores password in SecureString and every time I have to access the password; I get string from SecureString in an instance private method, use it quickly and let it be garbage collected. I believe if I use a method something like above, it will be safe OR safe enough rather than holding on to reference of Service, What do you suggest !!

Upvotes: 2

Views: 3758

Answers (1)

Rich Turner
Rich Turner

Reputation: 11014

To your specific questions:

  1. In your client code, what you're constructing are instances of lightweight proxy classes that wrap the channel infrastructure that serialize messages to/from the service's endpoints. As such, these client proxy classes are cheap and fast to construct because they don't generally do a great deal until you actually send something to the service. One thing to watch out for is when you call services which employ a more complex security scheme - establishing connections to such services can be costly and so it's worth caching or re-using such connections if you can.
  2. "Any workarounds"? Nope! Alas, the service you're consuming is poorly designed - not only do they require username and password to be supplied as part of the service method invocation, but they require that you pass them in the clear over HTTP. You might want to ask them to AT LEAST provide an SSL endpoint so that the username and password can be secured during transit. Better still, they could implement basic-auth to allow you to acquire an HTTP auth cookie that you can attach to subsequent calls against their services.
  3. Yes, the GC will eventually clean-up your proxy instances. Better still, you could wrap your instances in using statements to invoke the Dispose pattern and clean-up deterministically. See my Magic8Ball WCF Service on Codeplex for examples.

Other observations:

  1. Because your service requires your username and passoword, each time you call it, you need to pay some very careful thought to how you're going to obtain and store the username and password.
  2. I would urge you to specify your binding information in the app.config rather than inline in your code. Again, see the Magic8Ball WCF Service: If you create bindings in code and the endpoint changes or if they open up a new endpoint, protocol, encoding and/or binding, you'll have to recompile and redist your entire app. If you specify your bindings in config, you might just be able to get away with shipping an updated app.config.

Hope this helps.

Upvotes: 1

Related Questions