Can somebody please define the difference between HttpWebRequest and Adding service reference when using web services? Also what is the best approach.
Adding a service reference gives you the benefit of the plumbing code necessary to call the web service methods as if you were just calling methods. It abstracts dealing with the request/response.
I think in terms of performance consuming webservice through HttpWebRequest would be faster when compared with Add service reference approach as in the later case the process involves object construction at runtime & further it carries lot of other overheads (for instance other webmethods part of web service) which you may not be using it in that particular context.
UPDATE:
Looks like my guess was wrong.
In this https://web.archive.org/web/20210619192654/https://www.4guysfromrolla.com/articles/022410-1.aspx there are some statss on SOAPcall vs service reference approach. The test revealed that service reference approach is much faster.
Add reference can only be done with web service URLs (.net amsx services, wcf services, and other SOAP based services like in java,php or ruby etc). Adding a reference generates stub which contains all the classes necessary for calling web services. It includes all object types that are passed as parameters or returned from web methods.
On the other hand HttpWebRequest can be used not only to call webservices but simple aspx pages, HTML pages or any HTTP or HTTPS based urls. Its just like hitting a URL in browser.
Related
Previously I used web services sample from console application, but I don't have much knowledge in that in terms of understanding in xsd and wsdl.
I would like to consume the complex web service to understand xsd and wsdl.
When goggling found some sample free web services, they have provided wsdl file, and service url. I am able to add the web reference in C#, but not understanding how and which method to call, could any body can provide sample code to consume?
Service URL: http://www.webservicex.com/globalweather.asmx?WSDL
Web method : GetWeatherResponse
When I add the service reference from the application I am able to see the these classes.
input1, input2, input3, input4,
output1, output2, output3, output4,
ArticleType, ArticlePtServiceClient, ArticlePTservicechannel
but I'm not able to view GetWeatherResponse()
From the wsdl file can i get to know from which class object we can call the web method?
Theoretical understanding is we can find the web method based on the wsdl.
Eagerly awaiting positive responses. Expecting sample code to call this web method from the web service.As well as requesting you to some references to better understand complex type xsd's.
Thanks in advance.
After lot of R&D understand littele things regarding Web service and WCF.
The only solution is We have to create stub to test in local environment.
Createing stub :
SVCUTIL
still need to learn more, more questions are there in mind. will update here for our reference.
Can I write a web service that implements the same methods and returns the same custom objects using both C#/WCF and also Java Web Services? And if so, can I then access the web services using a single web reference but with different addresses?
I'm asking because I have to host a web service that has a GetCitations and GetTerms method for publically exposing our database content. We are on IIS, so I was going to do it with WCF. However, other partners in the project also have to host an equivalent service and they are all Java based.
We are then building a software app that needs to connect to any number of these services (as defined at runtime by a user). I am expecting that we can have one set of classes to connect to these services (but with different endpoitn addresses), but am not sure whether I'm right in expecting this to work.
Is this possible?
And what considerations/restrictions are there?
Thanks.
It shouldn't be a problem, if you make sure that both services have equivalent wsdl files and you use http/soap binding.
I am not sure about using the binary (net.tcp) one with WCF, though. It might be a problem.
One way to do it is to use JAX-WS (Java 6) to expose a method as a web service.
The JAX-WS stack allows for automatically generating the correct WSDL at runtime.
The .NET team can then take that WSDL, and use standard tools to create a mock implementation of that WSDL. This mock implementation is then used as the actual .NET implementation, and you then use standard tools to generate the WSDL for that web service.
You now have to web services with the same semantics each with their own WSDL.
Both Java and .NET can implement a SOAP compliant web service, so the answer is yes, you can write a .NET and a Java webservice that implement the same WSDL.
My understanding is that a c# based client "prefers" SOAP because when you add a web service reference it creates a proxy class from the wsdl found at the url you specify.
Which almost makes it transparent to the c# client that we are even using a web service, it almost feels like we are using a local class library. you call methods and you use objects.
My question is can REST achieve the same affect. I assume that it can't since it doesn't have wsdl and thus visual studio can't generate a proxy class for it. But Please correct me if I'm wrong?
A "run of the mill" REST service cannot achieve the same kind of tight integration with C# - mostly because it lacks the metadata that a SOAP service will provide (with a list of methods and their parameters and all that stuff).
The WCF Data Services (built on top of REST) do work much the same way as SOAP services, since the OData protocol contains extensions for pure REST services that provide metadata information needed to create a good, useful client-side proxy.
REST can be used to generate client side class libraries. For Example You can create proxy classes for MS generated REST services. In fact MS is actively pushing this model for Entity Framework based WCF DATA Services, e.g. those used by Silverlight and RIA applications. check out MS ODATA framework for REST which involves creating client objects out of standard REST queries.
http://msdn.microsoft.com/en-us/library/dd673930.aspx
I've recently discovered a way to implement RESTful services using Global.asax (by handling the Application_BeginRequest event). Basically, I am saying it is possible (and easy) to implement a RESTful web service in classic ASP.NET, without any need for WCF.
It takes approximately 30 lines of code to figure out which method you want to call (from the URL) and pass it parameters (from the query string, via reflection) as well as serialize the result using XmlSerializer. It all leads to a web service that can be accessed through HTTP GET requests, and returns standard XML data.
So with that in mind, is there any reason to use WCF when creating a RESTful web service that will be invoked only through HTTP GET requests? WCF introduces a lot of overhead and restrictions, whereas the Global.asax approach I described above is much easier to implement, customize, and deploy.
Note - JSON endpoints can also be implemented without WCF by using the JavaScriptSerializer.
Also - HTTP POST requests can be handled by Global.asax in a similar way.
So in the end, what would be the reason to use WCF in such a case? Is there better scalability or performance?
You can also use Asp.Net MVC to implement REST quite easy.
What you don't get for free with this approach is:
non-HTTP bindings.
support for multiple message formats.
non-IIS hosting.
control over the process activation.
control over the instance creation.
object pooling.
message queueing.
transactions.
scalability and reliability.
additional technologies built on top of WCF like the OData support.
If none of these applies to your scenario - you don't need WCF.
The answer is, 2 different pipelines, but the WCF pipeline was built specifically for services, and ASP.Net was built for rendering content via HTTP. Both have their pluses and minuses.
If you are comfortable with the ASP.net stack, and don't have to worry about things like standards, then ASP.Net is fine.
But if you want the best of both worlds, try WCF Data Services, all the cool built-in features of WCF, with none of the hassles. Currently, MVC does not have a view engine to generate OData.
My webservice constructor is getting called each time that I call a webmethod. This is causing some problems with some new functionality that I am adding and I cannot figure out what I am doing wrong to cause this. The only place that I am newing the webservice is in global.asax.cs's Application_Start, but if I remove the code to new the webservice, it still calls the constructor each time that I call a webmethod.
I have tested this by browsing to the .asmx file and calling the webmethod's that way and I have also created a test console application that has a reference to the webservice and will call the methods that way. Both of these give the same results.
I am using c# in ASP.NET 1.1. Any ideas?
Edit:
I am trying to create a heartbeat thread that polls a windows service. I am attempting to save the result in a hash table (multiple threads polling multiple services). I have changed the webmethod (as it used to poll the windows service) to get the results from the hashtable. We are trying to increase the speed of this webmethod call.
Whenever you call a web method, a new instance of the web service is created - this is the intended behaviour. Web services are stateless, which means that an instance of the service is not kept alive between web method calls, and therefore you cannot store any state in members (fields, properties) of the web service.
If you want to save some values/state between web method calls, you have to use the ASP.NET session or a database for that purpose.
See this question for details: Is this supposed to work this way?
Err... this is kind of by design I'm afraid. Can you describe the problems you are getting and what you are trying to acheive, I think you need to refactor your design a little here.
You can also switch to WCF which supports stateful services