Fasten your seatbelts, you are in for the next round of Web Reference vs. Service Reference, which brings an unexpected twist to the story. After giving reasons why not to use Web References, I’ll now put my devil’s advocate’s hat on, and try to have you change your mind.
It’s simple: there are situations where Service Reference won’t work as expected, and Web Service will.
A beauty of Web services is that they don’t need to care at all about who’s consuming them. Whether there is .NET on Windows, Java on Linux or some proprietary stuff on an iPad on the other end, they do exactly the same stuff.
To make it short: if something works on one platform and fails on another platform, it’s not the fault of the Web service being called, it’s the fault of the caller platform.
As I said in the last post, there are two ways, or platforms if you wish, native to .NET Framework, which you can use to connect to any Web services. And they don’t work exactly the same.
Once upon a time, Freddy has delivered a great series on connecting to NAV Web Services from a smorgasbord of technology flavors. If you are a .NET enthusiast, like me, the obvious choice is to connect through the tools that are at your disposal in Visual Studio: the proxy classes.
A proxy class is a class which wraps a Web service functionality into a strongly-typed .NET object, and allows simpler communication through Web services. It hides away all intricacies of SOAP communication, authentication, serialization and deserialization, and exposes simple, easy-to-use objects. Every NAV Web service results in a series of proxy classes, and in Visual Studio the generation of those classes is as simple as clicking a mouse a couple of times.