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
So I spent some time figuring out exactly what
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
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
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
Of course this requires Microsoft IIS, to service the web service request (not sure how the
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
Next up I'll explain where I'm going with all of this!