I've been using the term "Web server" for a while in this blog; and now I realise that I've never defined what such an animal might be. So this is a very brief introduction to Web server technology.

I don't know, but some of you might be familiar with the idea of a file server. Basically, it's a relatively high spec computer with lots of disk space that is used for storing and retrieving files. The advantage of this is that, unlike your local hard disk drive (your C: drive, usually, for all you Windows people out there), it can be effectively backed up, centrally; can provide fault tolerant storage (e.g. parts of the disk can be corrupted or inoperable, but your data stays safe), and can make very large persistent data stores, in the form of files of one type or another, available to users - stores that are far larger than could be attached to ordinary PCs. It also allows the files it stores to be shared securely.

When you retrieve a file from a file store, your computer generally knows what program to use to manipulate the file. If you retrieve a word processing document, for example, your computer will - if it recognises the format - open it in a word processor.

So why am I talking about file servers when I promised to talk about Web servers. Well, because in essence, Web servers are just specialised file servers. They are specialised in the sense that they serve up files (called pages in Web server speak) that conform to a set of standards for Web pages. This allows a client application - a web browser - to request a certain type of page which it, the browser, can then interpret and display for the user.

At the very simplest level, all Web servers do is to serve up HTML pages that they find on their file systems by following the paths sent to them by the client browser: the URL. The URL of a web page is the address you see in the address bar of your browser, underneath the menus. For example, the URL of the page I am typing into now is http://www.blog.co.uk/admin/b2edit.php?blog=51047.

What the above URL means is that there is a document called b2edit.php in the directory called admin on the machine called www that lives in the domain called blog.co.uk. The ?blog=51047 is called the query string and tells the Web server which blog I'm editing.

Of course it's a bit more complex than that. The browser in this case is asking for a PHP page, and the Web server knows to hand off processing of such pages to the PHP application: but at the end of the day, what it sends back to the browser is HTML - even if it's been made up on the fly by another program such as PHP and never actually existed as a real file on the file system.

If you want to see what the Web server sends back, just right click on a Web page and select View Page Source - or whatever your browser says.

Generally speaking, HTML pages on Web browsers are just sent back without modification. Files such as PHP files contain instructions to a PHP processor as well as HTML markup. The Web server hands the page to the PHP processor, which modifies the page and hands the resulting HTML back to the server for sending on to the client (browser).

The pages I am writing are called ASP.NET pages. These are similar to PHP pages in that they contain a mixture of text and instructions. Until recently, these instructions could only be processed on Windows servers using Microsoft's Web server (IIS), but now, with the advent of Mono, they can be processed by other Web servers, notably Apache, using Mono as the processor. My project aims to discover whether the Apache-mono combination is as effective as the native Windows implementation.

That's probably enough for now. If you have any questions, ask away. I love this subject, so I'm only too pleased to respond to anyone else who shows even the slightest interest.

Or at least one is ...

Craig and I had a good crack at sorting out the problems I'd been having getting my ASP.NET pages up and running using the Apache Web server. As it turned out, neither he nor I could figure out what was going awry: so we turned to the mono mailing list (Mono-list@lists.ximian.com).

One of the joys of dealing with Open Source software is the community that exists, pretty well regardless of the application, to provide help and support to nerds in need. Very often, when "talking" to people on these lists you'll find that you are talking not only to someone who is knowledgable, but who is also actually a person involved in the development of the application. Sometimes you find yourself talking to the lead developer him/herself.

So it didn't take long to get an answer back from the list. The problem was that Apache, by default and quite rightly, denies access to the file system - to everybody. If you want a directory to be accessible to all, you have to add a section in the /etc/apache2/httpd.conf file that specifically allows access:

< Directory /MSc >
    order deny,allow
    Allow from all
< /Directory >

There are some other things too, but I don't want to bore you to death.

Anyway, the upshot of all this is that you can now see my bright, shiny, ASP.NET user interface, running on Apache on Linux at the following URL:

MSc User Interface

It doesn't actually do anything, but it gives you an idea of what the finished application will look like.

Actually, comparing my experience of getting support for Mono on Apache compares interestingly with the experience of one of my colleagues who is a real Microsoft fan. He needs to get a certificate server up and running, for digital certificates, and to this end had followed Microsoft's instructions on how to write a little program necessary for the implementation. Despite following all the instructions, the application was not showing up in the list where it should.

He came to me today in desperation asking me to look at the program to see if I could see the problem. So I looked, but the program seems fine to me. It compiles and registers as a COM object exactly like it says on the tin. The problem is with the Microsoft application that is supposed to use it.

Can he get support from Microsoft to fix this problem? Yes. If he (or rather we) pay Microsoft a bundle of cash. I don't think that this is an option, so he's not a happy bunny at this particular moment in time.

I've given him a couple of areas to look at, but I think he's on his own at the end of the day. You're never on your own with Open Source Software.

Sermon over.

Feel free to play with the user interface. If you experience any problems please let me know. Don't expect it to be very fast, though. It's only running on an old PC.

I've mentioned before that it would be nice to get my test application up and running on the Apache Web server under Linux, rather than just using XSP - especially since XSP is listening on port 8080, by default, rather than port 80, which I would prefer. So, to this end, I had a go at configuring Apache for Mono (.NET, if you like) on my Linux server. The error message I get when trying to access .aspx (i.e. ASP.NET) pages is that I don't have permission to access the requested object. So it's a permissions problem, but permission to do what is a mystery to me at the moment: access the page, access the mono libraries, access the mono interpreter? I've no idea. Something tells me that the trusty Craig may be called upon before long.

Under Windows I'll be using IIS version 5 (or 6, it won't make much difference). Of course, no special configuration is necessary for IIS because ASP.NET handling is configured by default - this being Microsoft's technology and all.

If the worst comes to the (nearly) worst, I'll stick with XSP and try and configure it to listen on port 80. At the very worst, I'll just have to stick with port 8080 and restrict the application to internal users only (i.e. users on the same LAN as I am at work).

On a brighter note, the user interface to the application is pretty much complete. It looks quite good. One day I hope to be able to show it to you, but that depends on getting Apache going (Grrr!).

I've just three months left now, and it's all beginning to look a bit daunting. However, if I can get the software up and running before the end of February, I'll be able to allow two weeks to collect the results. That will leave me six weeks to analyse the results and get everything written up. It's tight, but I think I can do it.

On a slightly brighter note still, my local LUG (Linux User Group) is conducting a lightning talks session on 7th February, so I'm going to give a 5 minute talk on Mono. It'll be my birthday, as well, so I hope it goes down OK.

Well almost. I have to work out a way to get my E-R diagrams into the report; and there are a couple of small inconsistencies that I'll have to sort out. Still, it's looking fairly good. I've never seen a perfect expression of an application in UML. There's always something you could do better: but as long as it's good enough to begin coding from, then it's alright. What I have is good enough to begin coding from.

An E-R diagram, by the way, is an Entity-Relationship diagram. It's the application's data model: the persistent, non-transient data that is. The data that will remain after the application finishes. In other words, it's the database tables you're going to want, and the relationships between them. Some E-R diagrams are very complex. Imagine the data model for an HR/Payroll system, for example; or the model for a Student Record System.

Fortunately, the model for the application I'm writing for this project is very simple: five or six tables at the most. So I don't have much to do. In fact I've done most of it. I just can't work out how to get the CASE tool to include the diagrams in the report.

The rest of the UML report runs to 4,700 words over forty-five pages and includes about thirty diagrams. Since the word limit on the dissertation is 20,000, I think this will have to be an appendix - along with the Statement of Requirements and the Technical Specification. Between them, these three documents would probably account for nearly the whole of the word count if I were to include them in the body of the dissertation.

Next week, I'm going to try to get Apache up and running using Mono for .aspx pages. In other words I'm going to try to get my Linux Web server to run .NET applications using the Apache Web server as opposed to the XSP Web server I was playing with last week. Then I'll decide which option I'm going to take. I really want the application to run on port 80, the usual http port. If I'm going to do that, Apache might be a better bet. It does serve 70% of the world's Web pages after all.

Perhaps I'll have more to say about Web servers and how they work next week.

The Unified Modelling Language.

Fashion is a powerful determinant of professional behaviour in computer circles; and at the moment, the UML is fashionable. Perhaps not quite as much as it was, but fashionable nonetheless.

All it is, is a way of describing the structure and behaviour of the application you're going to write, using a set of diagrams: Use Case Diagrams, Sequence Diagrams, State Diagrams, Collaboration Diagrams, Class Diagrams and others. And what's handy about it is that it is very amenable to computerisation. In other words, you can get a computer program to help you draw the diagrams, by selecting from sets of pre-built shapes suitable for the particular diagram you are working on. Not only that, but the computer program will also keep everything consistent. So if you have a Use Case (a scenario, if you like) that is called, say, Administrator Login and you change the name on one diagram to, say, Co-ordinator Login, the program will change the name of the Use Case everywhere that it appears. It will also keep track of relationships between model components, and provides facilities for printing out fancy reports. Programs like this are called CASE tools - Computer Assisted Software Engineering tools.

When you have developed your UML model in this way, you can pass it on to a developer - along with the Statement of Requirements and the Technical Specification - and, so the theory goes, the Developer will be able to code it up in practically no time at all. In fact some CASE tools will even generate some program code for you.

As I mentioned before, I had some trouble with my CASE tool over the weekend, but that's sorted out now, and I've managed to produce a first version of my model.

It has to be said that there are few more boring occupations than taking a technical specification and turning it into UML: but it has to be done. I'll probably spend next Saturday in work, as I did last Saturday. There are fewer distractions, so it's easier to get ones head down and press on.

I posted the first draft of the model to my tutor, and she seems quite happy. So it's just a matter of keeping plodding on.

Next week maybe, just maybe, I'll get to do some coding.

The main thing I've achieved since I last posted is to get XSP to run as a service on my Linux server at work. XSP is a lightweight Web server supplied for Mono. It can either run as a standalone application or it can be used by Apache just for running ASP.NET applications. I've decided to use it as a standalone application because I don't need all the other facilities that Apache provides like being able to run PHP programs, CGI programs and so on.

Well getting XSP to work at all was a bit of a coup, to be honest.

Exactly the same stuff had been downloaded from Novell - who own Ximian, who produce Mono - using exactly the same tool (Red Carpet) as I have on my box at home, and onto the same operating system (SuSE 9.3) as well; but for some reason the XSP root directory and test applications were nowhere to be seen. Fortunately, Linux is a lot simpler than Windows in that you don't have to worry about all that Registry stuff. I just copied the stuff from my box at home onto a CD and then copied it into the right place on the box at work. Everything then just worked a dream.

Except I needed to get it (XSP) to start as a service at boot time. You have to do a bit of scripting for this, but with a little help from the invaluable Craig we got it going in the end. The guys in work were amazed to see ASP.NET programs running on a Linux box.

The UML for the application is well on its way as well even despite having some problems with my CASE (Computer Aided Software Engineering) tool both at home and at work. In the end, I've put in a HelpDesk call from work to the suppliers. The problem is with the report generator, which is pretty crucial because if I can't get that going I won't be able to add it to my project. Gulp!

Well, all bar the shouting.

This Christmas break has been pretty much successful in getting things back on track. I had rather let things slip through November and December. Stuff like ironing had started to look attractive in comparison with getting on with my project work, and I really only just managed to get my project specification and design stuff in on time. Well, just a little bit late, actually.

But we're back on course now: and with any luck I should be able to make a start on the UML application model this week. Which is good. It is!

I've posted my statement of requirements and technical specification to my tutor in the hope that she'll tell me if there's anything very wrong with either of them: but I don't think there is. It's the sort of stuff I do all day and every day at work, after all.

So there we are then. Happy New Year to all. Now back to work ...