the markITeer

Archive for the ‘the Bush Files’ Category

The Bush Files: clients, servers and protocols

Posted by the markITeer on July 3, 2007

This post is part of a series of things ‘everybody-assumes-you-know-but-actually-you-don’t-have-a-clue’.
I call them : the Bush Files.
Today : clients, servers and protocols

If you want to understand how the Internet works, why it is you sometimes have to wait for a webpage to appear or why almost every web address starts with ‘http://’, you must learn about the most important thing that makes the web happen: the client-server model.

The first player in the client-server model is the client. A client can be any program that can access the Internet and wants to retrieve information from it. For instance a web browser, who wants to retrieve web pages, or an e-mail client who wants to retrieve email messages. But in order to get the information they want, somebody has to provide it to them. And that’s where our second player enters the stage: the server. A server is any program that can access the Internet and is able to provide information to the clients. There are servers specialized in delivering web pages, other servers know how to deliver email messages and so on.

You could compare this to going shopping: You, the client, want to get e.g. the latest Radiohead cd (rumoured to be released fall 2007!), and the store (aka the server) can give it to you.

There is however one thing still missing in this story: we assume that the client and server can understand each other! What if you would walk into a record store in China asking for your cd in Dutch? It is very important that the client and the server know how to communicate! That’s why different protocols were invented that define how a request and a response have to be created in order for the server to understand what the client is asking for, and for the client to understand the server’s answer.

For the exchange of web-based information (web pages, RSS feeds etc.), the http protocol is used, which stands for HyperText Transfer Protocol. For the exchange of files, FTP (File Transfer Protocol) can be used, and for the exchange of emails SMTP (Simple Mail Transfer Protocol) can be used. Makes sense, doesn’t it? And maybe you recognize this acronyms? If you enter a URL in your web browser, the first thing you have to enter is which protocol your browser should use to get the information you’re looking for e.g. http://markiteer.wordpress.com.

So, let’s recap using some day-to-day examples:

1. I want to view a web page:
First I type in the web address, let’s say https://markiteer.wordpress.com, into the address location bar of my web browser. My web browser, being a typical client, will then connect to the server where this website resides asking for the web page using the http protocol. The server knows this protocol and can deliver the web page back to the client. The client (your web browser) will then render it for me to view it.

2. I want to read an email:
I open my email reader (e.g. Outlook). Being a client, it will contact a mail server asking it for new email messages using the smtp protocol. The mail server understands what the client is asking for and can deliver the new messages. My Outlook will than render the email messages so I can view them.

3. I want to upload a file:
I open my FTP program (eg. CuteFTP, LeechFTP, …). This client will connect to a server I specify to which I want to upload my file. Using the FTP protocol, the client will send the file to the server. The server will understand this and send back a message that it successfully received the file.

That’s all there is to it. And once you’ve got the hang of this easy principle, the working of most Internet-based applications suddenly will become a lot clearer.

Advertisements

Posted in the Bush Files | 1 Comment »

the Bush Files: Web Services

Posted by the markITeer on June 6, 2007

The Bush FilesThis post is part of a series of things ‘everybody-assumes-you-know-but-actually-you-don’t-have-a-clue’.
I call them : the Bush Files.
Today : Web Services

Although there are a lot of interpretations of the term ‘web services’, it’s most commonly used to describe a set of functionalities of an application that are made available to other applications over the Internet.

For example: Google has a web service allowing you to use their famous search capabilities from within your own web application. You might create your own search box, ask Google for the results of the search via the web service, and show the results any way you like on your web page. Or you might use the web service of Google Maps to (programmatically) ask Google for a map of your region, mark your house, your cafe and the place you walk the dog and publish the result on your website. Schematically, this would look like this:

Web Services

It doesn’t always have to be this visible though: You could also use a web service to e.g. store information in some database somewhere on the web every time a user fills out a form on your website, as pictured below.

Web Services

Applications talking to each other via functions that the applications made available, is not new. The common name for this in the programming world is API: Application Programming Interface, or a way for applications to programmatically interface with each other. Add the web in between the applications, and you understand why Web Services are also often referred to as “Web API‘s”.

Typically, the communication between the applications over the Internet will be done through SOAP (Simple Object Access Protocol): a set of rules (or ‘protocol’) designed to transfer data in a specific dialect of XML over the Internet. So the applications basically talk XML to each other! And a description of the functionalities that can be used, is made available in a WSDL file (Web Services Description Language), which is basically… also XML (click here for the Google search WSDL, you can find functions in there like ‘doGoogleSearch’ and ‘doSpellingSuggestion’).

There are a lot of issues involved in creating and using web services, none of the least is security. But overall it has opened up a lot of possibilities and nowadays powers a great lot of the Service Oriented Architecture (see ‘Web 2.0 unraveled‘) pillar of Web 2.0.

Posted in talking the talk, the Bush Files, Web 2.0 | Leave a Comment »

the Bush Files: XML

Posted by the markITeer on May 23, 2007

The Bush FilesThis post is the first in a series of things ‘everybody-assumes-you-know-but-actually-you-don’t-have-a-clue’.
I call them : the Bush Files.
Today : XML

XML stands for eXtensible Markup Language.
Let’s start with the last part first : It’s a language, a way of communication, of sharing data, mostly between two applications. But it’s not just a language, it’s a ‘markup‘ language. This means that it combines text and extra information about this text. In the case of XML, it’s information about the structure of the text. Finally, it’s extensible, meaning that you can extend the language, invent new ‘words’, so you can have it say exactly what you want it to say.

let’s take a look at a simple example:

<books>
	<book ISBN="1400079179">
		<title>The Da Vinci Code</title>
		<author>Dan Brown</author>
	</book>
	<book ISBN="0345340426">
		<title>The Lord Of The Rings</title>
		<author>J.R.R. Tolkien</author>
	</book>
</books>

What does this tell us?
1. XML is readable: it’s just text and can be read in any text editor, like eg Notepad. Handy!
2. the extra information about our text is put in descriptive ‘tags’ between ‘<‘ and ‘>’
3. text is put in between opening and closing tags: eg <book> …… </book>. The opening tag, text and closing tag together are called an element
4. There is 1 element containing all data. In our example this is the <books> …. </books> element
5. inside an opening tag, you can also put some extra information in an attribute : eg <book ISBN=”1400079179″>

The fun thing is, you can invent any tags and attributes you want, as long as the one you’re sending the XML to ‘speaks’ the same language… That’s why, once a language has been defined between the sender(s) and the receiver(s) of the XML, it can be described in a schema. That way, everybody knows which words can be used so that every-one can understand what the others say.

If you speak the correct language, use the words you and the other people/programs that have to work with the XML have defined, the XML is said to be valid. If your XML is syntacticly correct (see items 3 & 4 above), it is said to be well-formed.

So, that’s basically all there is to XML. Not so difficult, he?

P.S. If you take a close look at HTML, the language used for building web pages, you’ll see … that it’s really XML with it’s own pre-defined tags and attributes! The original HTML wasn’t really well-formed though. That’s why they invented XHTML, which is the same as HTML, but this time fully well-formed.

Posted in talking the talk, the Bush Files | Leave a Comment »