Sjoerd Visscher's weblog

My ideas about new web technology that can change the future of the world wide web.

Last Update

10/25/2002; 8:15:26 PM

Weblog Search

Don't like the look of this site?

XML coffee mug
Click to see the XML version of this web page.

Updated with

Click here to visit the Radio UserLand website.

Thursday, January 31, 2002

Let's go into some more detail about what is the overhead in .NET web service example. The problem is that there's no good context for the code to run in. So every department of the compiler needs to know what this code is going to be used for. Let's see how many code could have been inferred when the compiler would know we're writing a webservice: "WebService", "using System.Web.Services", "WebService", "public", "[ WebMethod ]". Also the class definition is of no use, and could have been generated. (Just like Tomcat does for JSP pages) So I don't understand why .Net doesn't allow you to write:

<%@ WebService Namespace="urn:Hello" Language="C#" %>
 
public string sayHello(string name) {
 
    return "Hello " + name;
 
}

This would still give you all the functionality and power of SOAP and .Net. I can only think of one reason: Microsoft tries to make it so complex that you have to use their tools.

Read this article on Web Services interop. It's an eye-opener because they include sample code for a web service in .NET. Look at all the overhead. Did they really design an environment for web services? If so what are all those magic incantations about? [Scripting News]

Indeed. And I think most C-programmers think this example is actually very short, certainly for a webservice. But with scripting it can be as simple as this:

<?
 
function sayHello($name) {
 
	return "Hello $name";
 
}
 
?>

I save this as hello.lib in the right directory, et voila.

Dave and I are both having fun seeing how others say the comparison isn't fair. Oh sure, it really isn't. The .Net example only excepts strings. This example also does a good job on numbers and dates. And we don't have to learn new things, only that functions created in a special place automatically become webservices. It saves us time so we can keep our weblogs updated.

It might look very hard to write a "Hello world" routine in C#, Java or even Assembler and expose that as a Web Service. On the other hand, it might look very hard to write a Pascal-Compiler in UserTalk, PHP or Python and expose that as a Web Service. [A Practising Maniac at Work]

Christian Riege has a good point. However most webservices are more like a "Hello World" routine than like a compiler. (anyone up for a Java Compiler webservice?)