Useing web service without a web reference

This article covers how to use a web service without a web reference.

The only thing that it fails to do is to recommend the creation of a descendant class to set the url.
This should be standard behaviour when dealing with autogenerated code – don’t touch it.

This allows the creation of a proxy that can have the url specified at run time.
This provides far better decoupling of the web service and gives the client the possiblility of choosing from a number of web service implementations.


Here is a link to an article on AJAX and PHP.
This is intended to make websites far more dynamic.

In case anyone is wondering why I am using PHP it is because I bought a domain and hosting for £30 for two years. The site advertised Pythin support that I only found out was disabled after I had the domain. The remaining options were Perl or PHP. I found the PHP to not be too painful to use. The site is strictly of local area interest so does not get quite the load that would cause trouble.

What a Web Service contract requires

A comment on one of my earlier posts lead me to think of a feature that is missing from web services. The whole point of using web services is to decouple links between products so that it comes down to a service agreement. I think that these agreements should have a defind duration. This should be of the form “I promise to keep this service available for 3 years and I will update my future intentions after 2 years”. This could permit a web service to evolve over time without breaking the contract.

COM used to have immutable contracts – although these were occasionly broken ( OLE-DB has a great feature that breaks the IUnknown contract – the behaviour of IUnknown on a provider varies depending upon whether the connection is connected).

This would require some extensions to the basic infrastructure but would save a lot of trouble in the future. This would prevent a system being built with a dependance upon somrthing that is just due to expire.

Cognotive Distance

A discussion in this dot net rocks show explained why an experienced C++ devloper would chose to use VB.NET over C#. The two languages are of equivalent expressiveness but have slightly different biases. VB.NET is better for dealing with variants and default parameters while C# has unmanaged code support.

Kate’s argument was that C# was too close to C++ to make freely jumping between them difficult and error prone this made VB.NET a more natural choice. I have had similar experiences. Currently I am working in Delphi, SQL and C#.

I find that keeping the SQL in strict upper case allows me the seperation so that I don’t find myself adding “then” to the end of my if statements. This allows me to keep a Cognative Distance between the two languages. Since Delphi and C# have a suitable distance between them (begin end vs {} ) I generally don’t have a problem switching..

The major gotcha that I have between Delphi and C# is the calling of a method with an empty parameter list. In Delphi you can call foo; where C# requires foo();

C# reserves foo for referencing the method itself.

The other niggle that I have with C# is the casting syntax.

In Delphi if I wanted to cast a class to a specific descendant and then use a method exclusive to that type I would use:


C# would require:


which has slighly too many brackets for my taste.
I know this was implemented for the C and Java developers but since one of the aims of C# was to correct the mistakes of the C and C++ world this could have been improved.


How Many Languages?

These days is is unlikely that one language is enough to get the job done.

Today I used:

  1. Delphi
  2. SQL
  3. Expect
  4. Python
  5. Want

I use compiled languages for the heavy lifting.
SQL is for data manipulation (mostly stored procs).
Expect and Python provide the flexible utilities (database creation).
Want (the delphi port of ant) provides the build tools.

API going AWOL

Microsoft in their infinate wisdom have decided to break the Mailslot API in the XP line and above. Mailslots were a great means of communicating between processes running under differing user accounts. Under XP these were made unreliable which renders them unusable.

In addition I have found that certain security API’s are missing on Windows Server 2003 custom builds. What is the point of developing against a fixed plaform if a custom build take away API calls?


Welcome to Dev Rants.

This blog contains the random musings of a software developer.

It is probably fair to give some background first.
I am an experience software developer with a diverse background.

The majority of the development that I have done over the last ten years has been in Delphi,
although I have also used C++, Java, Visual Basic, Powerbuilder, APL, Tcl/Tk/Expect,
Python and a fair amount of SQL. Recently I have started investigating C#

I am pro Open Source (but not rabidly so).

This Blog should allow me to record various devlopment issues that I have found along the way. Hopefully someone else (possibly myself down the line) will find these useful.