WSDL Generated Proxy Classes?

[Arpan]

Web Services make use of proxy classes whose methods & properties are
accessed in exactly the same way as how a normal class' methods &
properties are accessed. So what for does ASP.NET generate proxy
classes (using WSDL) which consume more hard disk space & resources?

For e.g. consider the following code which exists in a user-defined
class file:

Imports System
Imports System.Data
Imports System.Web.Services

Namespace AddNumbers
Public Class Calculator : Inherits WebService
<WebMethod()> Public Function Add(ByVal intA As Integer, ByVal
intB As Integer) As Integer
Return (intA + intB)
End Function
End Class
End Namespace

The above code spans just 11 lines but if the above code (excluding the
2 Namespace lines) is encapsulated in an ASMX file after which WSDL is
used to generate a corresponding class file, the class file spans
almost 100 lines (excluding the commented lines). Moreover, most part
of the code in the generated class is not comprehensible to newbies
like me. So why use WSDL to generate a class file? Also there
definitely must be some additional overheads involved in this approach,
isn't it?

Thanks,

Arpan

 

[Laurent Bugnion]

Hi,

Web Services make use of proxy classes whose methods & properties are
accessed in exactly the same way as how a normal class' methods &
properties are accessed. So what for does ASP.NET generate proxy
classes (using WSDL) which consume more hard disk space & resources?

The above code spans just 11 lines but if the above code (excluding the
2 Namespace lines) is encapsulated in an ASMX file after which WSDL is
used to generate a corresponding class file, the class file spans
almost 100 lines (excluding the commented lines). Moreover, most part
of the code in the generated class is not comprehensible to newbies
like me. So why use WSDL to generate a class file? Also there
definitely must be some additional overheads involved in this approach,
isn't it?

Thanks,

Arpan

WSDL is Web Service Description Language. It is a standard which is used
to describe what the Web Service can do. The advantage of generating a
WSDL file is that each client can download the WSDL file and generate
proxy "on the fly". This is what Visual Studio does when you create a
WebReference to a web service, and it generates proxies. However, there
are also other consumers of web services (ATLAS in JavaScript), and they
also create proxies in JavaScript dynamically using the WSDL file. Since
JavaScript is a very different language than C# and VB.NET, and since
web services may actually be written in yet other languages, WSDL
abstracts the language differences and allows different languages to
communicate through this medium.

It's very possible to do AJAX without SOAP and without WSDL. The code is
much thinner then. But SOAP and WSDL offer an additional level of
comfort for the consumer of web services.

..NET creates WSDL files automatically (just use the URL
myService.asmx?WSDL), but other providers of web services (Google comes
in mind) also deliver WSDL files with their web services.

HTH,
Laurent

 

[Arpan]

The advantage of generating a

WSDL file is that each client can download the WSDL file and generate
proxy "on the fly".

But what proxy classes do, the same can be done using business objects.
In other words, the logic that a proxy class encapsulates, the same
logic can be implemented using a business object i.e. both of them can
be used to retrieve data dynamically but using WSDL means the client
has to save the proxy file (along with the disco & results.discomap
files though not necessarily) in his machine thus consuming disk space
but with business objects, the client needn't save anything on his hard
disk.

Moreover to access the methods & properties in a proxy file, the client
has to pass commands to the Web Service (which maybe preceded by first
finding where the Web Service exists using DISCO) but with business
objects, there isn't any need for clients to use any extra tools like
WSDL.exe & DISCO.exe to access the business object's methods &
properties.

Both Web Services & business objects require compiled objects that are
implemented in ASP.NET pages. An ASP.NET book for beginners states that
the ONLY difference between Web Services & business objects is that
with Web Services, the compiled object (i.e. the proxy class) can
reside anywhere on the Internet. In other words, the ASP.NET page can
be located on a client's home computer in New York while the Web
Service resides on a server which is in Tokyo. But even business
objects that reside on a server in Tokyo can be accessed by an ASP.NET
page which is located in a client's machine in New York!

So what's the difference between Web Services & business objects or
what are the advantages of using Web Services (using WSDLs & sometimes
DISCOs) over business objects?

Thanks,

Regards,

Arpan

 

[Laurent Bugnion]

Hi,

But what proxy classes do, the same can be done using business objects.
In other words, the logic that a proxy class encapsulates, the same
logic can be implemented using a business object i.e. both of them can
be used to retrieve data dynamically but using WSDL means the client
has to save the proxy file (along with the disco & results.discomap
files though not necessarily) in his machine thus consuming disk space
but with business objects, the client needn't save anything on his hard
disk.

I think that you're missing the point that web services are not tied to
a technology or an environment, and that the proxy classes can be (and
often are, for example in ATLAS) generated dynamically during runtime.
In that scenario, nothing is saved on the client, and a description file
is needed. The .NET way of using "static" web references to consume web
services is, IMHO, rather the exception.

I think that everything which SOAP does can be done in other more
efficient ways, for example using simpler AJAX. But SOAP offers an
additional level of comfort for the user, which explains why it's
"bloated" (which is the most common criticism found against SOAP based
web services).

HTH,
Laurent