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.
Last Monday I’ve attended my second daughter’s birth, and then spent the week trying to relieve my wife as much as possible from anything but breastfeeding.
As a matter of fact, I’d like to keep doing it, it was not only a great break from daily worries, but also a fantastic occasion to spend all the time available with my closest and dearest, which I am not sure when I will have next.
It seems that there is life to keep going on, so I’ll now try to be back with my work and my blog.
Let me introduce bug #5: fields within a FixedLayout control.
In my country, there’s a saying: “A good horse has a hundred flaws; a bad one has only one.” It’s bad.
People have asked me why I am doing this, and if I hate Web services because I’m blogging about their flaws. In fact, I love Web services, and as I said in the first post in this series – they are great. They are a good horse. A winner.
The reason why I am doing this is because I want to share the problems I encountered over months of working with Web services intensively, as well as the solutions or workarounds I identified.
Today, on the repertoire we have another security-related glitch, which has been confirmed to me by Microsoft, but as far as I know there has not yet been a hotfix for this.
Bug #4: accessing Web services in multi-company scenarios.