use Perl

OK, so I started a new job last week, and have spent some time head down in web services. The company is very much gung-ho on .NET, and I'm, well,... Not.

So I spent some time figuring out exactly what .NET is. I think I should probably share that here for everyone else trying to figure that out... .NET is several things. So I'll break it down.

Primarily, as far as Microsoft is concerned, it's a new development platform. Think of this like the Win16 API was when Windows first came out (although not quite that unstable!). It's an API layer on top of Windows, just as Win16 was an API layer on top of DOS. Now at the moment, to run .NET applications on Windows you need to install the CLR (Common Language Runtime), (again, just as you would have to install Windows on top of DOS to run Windows applications in the good, err, bad old days). However in the future (i.e. Windows XP), the runtime will come pre-installed.

The API described above is basically a better, much more OO, much cleaner version of MFC, ADO, ODBC, and a bunch of other APIs. Containing APIs for doing GUIs, database access, tying windows controls to databases, etc.

Now in order to write applications that access these new APIs, you need to write in a new language, or a slightly modified version of an old language. The well heard of candidate for these new languages is C# (C-Sharp). This is like an OO version of C, without the complexity of C++ (however it has some horrible aspects, like being able to name variables and methods after keywords by prefixing them with an '@' sign - I have no idea what kind of crack the language designers were smoking when they came up with that one). Alternate languages are VB7, or a slightly modified version of C++, or Perl (but you have to type all your varibles. my Dog $spot). All these languages compile down to a bytecode that runs on a pretty nippy interpreter (with JIT compiling and all that gubbins).

On top of all that, we have Web Services. Now MS are making a big deal about this, saying .NET is *all* about web services. That's pure bullshit, I'm afraid. It's a pretty tiny part of it.

Now anyone who has been playing around with SOAP::Lite knows just how easy it already is to write web services with Perl (or access web services). Microsoft have made it equally as easy with .NET and C# to do so. You simply tag a method with some attributes, and when you install the component it becomes a web service with those given methods available via SOAP and WSDL (I'll come onto WSDL in a second).

Of course this requires Microsoft IIS, to service the web service request (not sure how the .NET ports like Mono will handle this). So when you "install" the component (I haven't figured out exactly what happens when you do that yet, I think it's almost exactly like registering an OLE/COM object works), it registers itself with IIS for web service requests. At least I think that's what happens :-)

When you do this, it also creates a WSDL file (or maybe it's dynamically generated, but I digress) for your component. A WSDL file simply describes the object and what methods it exports. This is used for introspection. For example, in MS Visual Studio, when you start to use a SOAP Web Service for which a WSDL file is available, this tells your code editor what methods are available, which gives you auto-complete on
the objects, so for example you start typing in Foo.B, and it auto-completes to Foo.Bar and shows you the parameters you need to pass to Bar to make it work right.

Kinda funky, but also kinda annoying (yeah I know you can turn that feature off).

Also note that the above is language independant. So where this used to work in the VB editor before, it now works for all languages, irrespective of what language you're working in, and what language the component was written in (providing it has this WSDL file available).

Finally, there is ASP.NET. This is almost completely separate, except to say that it uses all the same toolchain stuff now. So ASP pages compile down to the CLR bytecode and execute, allowing you to write ASP pages in C++ or C# or VB (previously only so-called "scripting" languages were available to ASP developers). Alledgedly you can have C++ ASP pages on your server, make changes to them on a remote server, and have them instantly running again. However I've asked the obvious question: So does your server need visual studio installed for that to work? I got no answer yet...

ASP.NET also implements an amazing technology called taglibs. Actually they don't call it that, and yes, I'm being sarcastic. Anyway, these allow you to write XML-like tags using namespace prefixes. So for example they have this new forms tag library, that allows you to do , and associate code with the button. Whoopdedoo. It turns
out the ASP Forms stuff is almost identical to AxKit's PerForm tag library (see CPAN). Only PerForm isn't beta. And I wrote PerForm without any prior knowledge of ASP's forms stuff. Anyway, taglibs are fabulous, but they are old news. Come up with something new, Microsoft! Plus both ASP.NET and JSP are both using namespace prefixes, and calling their technology "XML-like", but it's fundamentally NOT XML!!! Their prefixes aren't mapped to a URI, and their pages aren't parsed as XML.

OK, I think I'm done explaining .NET. As you can see, it's a bit of a hodge-podge of technologies. But in usual Microsoft style you can use their toolchain and never know what's going on under the hood. For some types of people that's a joy. They want to be able to build web services and have it just work. Just by clicking. Thats what they've done.

Next up I'll explain where I'm going with all of this!