The final topic in this series on how the Web Works, and why you should care; will address server-side programming and how it can make your website dynamic and a more effective vehicle of communication between you and your customers (and potential customers).  A good website should always have fresh content.  You want your customers coming back (again and again) to see what is new, and to interact with you.  The more interaction you have with customers, the more business you will obtain from them. 

The web is full of static websites that never change.  Even those static websites with glitzy Flash animations, but that hardly ever change, are really missing the boat.  A website visitor might “Oooh” and “Aaah” over those cool visual effects, but when he or she is done with this short-lived jubilation they are likely never to return.  This is why you can’t completely document a good website.  It is ever-changing.

As you remember, various types of content are delivered by a web server to your browser, such as HTML, Javascript, CSS, photos, audio, video, and Flash. Your computer’s browser then renders these files into a pleasing format, but it does so on the client-side. Some of this content, such as Javascript and Flash, can be very powerful, and can display things differently to the user based on user input.  However, unless you utilize server-side programming the overall effect of the website will be limited to actual static contents of the content files delivered to the browser.

Server-side programming allows your website to dynamically generate the content files that are delivered to the client’s web browser.  For instance, instead of the HTML content being stored in a file on the web server, the web server can be instructed to read a database (such as MS SQL Sever or MySQL) in order to determine what HTML should be delivered to the client’s browser.  This type of programming is very prevalent in Content Management Systems, such as Drupal (PHP based) or DotNetNuke (ASP.NET based).  These systems are a collection of server-side programming that allows a web-site administrator to login, add new sections and pages to their website, and update the HTML on any existing pages through a WYSIWYG (What you see is what you get) interface.  The data from the website administrator is then saved in a database.  When a user visits the website, the database is read first, and then the web-server returns the content that is stored there for a particular page that is requested by the client.

Another methodology for delivering dynamic content is to utilize Javascript and a new Javascript add-on called AJAX (Asynchronous Javascript and XML). In some circles this is known as Web 2.0. When a user requests a page on a website, instead of asking the server to deliver the entire set of content for the page, a relatively small javascript file is delivered.  When the page is loaded the javascript automatically contacts a web service (a special type of server-side program that we’ll deal with in a future blog post) for the initial HTML it needs to load on the browser.  If the user clicks on a button or does something that requires that further content is needed, the javascript will again make an AJAX request to perhaps another web service that will provide the additional HTML content necessary.  Here’s an example: Perhaps a page is supposed to initially display a simple list of contacts within the company that the user can contact if they have questions.  Perhaps there is a link next to each contact that will open a small details window that displays a picture of the contact, and has detailed biographical information for that contact.  Since javascript popup windows are generally blocked these days, the “window” will need to appear like a window, but not be a completely new browser window.  Instead of loading all the details and pictures for every contact in the list, the initial AJAX call will only retrieve the list of contacts, and then display it on the screen.  When one of the links is clicked, an additional AJAX routine will be called in order to retrieve the detailed biographical information for that one contact and display it in a DHTML or pseudo-window.

Server-side programming is also very beneficial for capturing and storing information entered by users into web forms. Before server-side programming became prevalent the best one could do with information entered into a web form was to have the web server email someone the values of what was inputed.  Now you can process, validate, and store any information into a database, as well as sending nicely formatted HTML notification emails to interested parties.  Such power drives eCommerce credit card authorization, user logins, event registration pages, search functionality, and pretty much anything that you see that is cool on the internet!  It can also store inputed values into user cookies or session variables, so that user choices can be remembered for their entire visit to your site. (Ever wonder why a shopping cart remembers what items you have already added to it?)

There are a wide variety of programming languages that can be used in order to create this type of server-side functionality.  What is important to note is that the operating system and web server that you are operating must support these programming languages.  For instance, Microsoft ASP.NET Version 4.0 allows a programmer to program in the latest versions of C#.NET and VB.NET.  These are great and powerful programming languages, but they only work on web servers running Windows, and on the IIS 6.0 or 7.0 Web Server software package.  Java, and Java Server Pages (JSP) are also great options, but they are better suited for Unix Web Servers, running other web server software, like Apache (However, you can configure a Windows Server running IIS to use JSP.  You just need to do a lot of configuring). Other options include ColdFusion, PHP, Ruby, and Perl; most of which have a variety of versions for a variety of operating systems and web server software.  Why is all of this important to know?  Well, if you are in charge of purchasing a web server for your company, or you are in charge of selecting a web server hosting plan for your company, you need to know what programming language your developers want to work with.  That way you can select a Web Server or hosting plan thats going to work for your company.  Don’t let your programmers (or for that matter - a salesperson) dupe you into a high cost solution that your company doesn’t need.  Armed with the right information you can become an active participant in the conversation and help make the proper decisions for your business.  And thats “Why you should care!”

Of course, you still may be asking, “Why should I care?”  One good reason is that website technology is constantly evolving.  To know the basic capabilities of websites today, it is necessary so that you, the business leader can formulate what your website of tomorrow will be capable of.

Those businesses who don’t grow usually find themselves lagging behind, and an effective and relevant website that is increasingly user-friendly and keeps your customers (and potential customers) coming back again and again, is essential in today’s market.

HTML itself merely presents text and colors onto a page.  One of the most basic extensions to HTML is the ability is present pictures onto the browser screen.  This is done by either using the HTML <IMG/> tag or by using a background image.  These images are saved in separate image files that are housed on the web server.  Most browsers accept images saved in GIF, JPG, and PNG formats, and these files have the appropriate file extension associated with them (ie - image.gif, image1.jpg, or image1.png). The HTML tag has a SRC (Source) or Background-Image attribute that tells your browser where on the server it will find the appropriate image file to display in that location on the web page.  For example, <IMG SRC=”http://www.millcreekwebworks.com/images/dilbert.jpg” border=”0″ /> tells your browser where to find the Dilbert comic strip you see above.

HTML pages natively only display static content.  Once the page is loaded, the page does nothing.  It soon became apparent, that web pages should interact with the user and with events that happen on the page.  Javascript is a programming language that reacts to these events and performs actions on the webpage after it is loaded.  Events include such actions as the Page Load event, a mouse hovering over or off a certain part of the page, a keypress on a keyboard, a click or double click on an element of the page (such as a button), and many, many more.  Javascript can either be embedded right in the HTML page, or (if the javascript is large) can be housed on the web server in a separate javascript file (eg - myjavascript.js).  By using the <SCRIPT/> tag your web browser either loads the javascript embedded in the HTML page or from the separate javascript file into the client’s memory when the page loads.  When an event occurs, it executes the code.

The original HTML specification only allowed the website developer very basic formatting functionality.  Originally all of this formatting was handled by attributes within the HTML tags themselves, such as BGCOLOR, ALIGN, SIZE, etc.  The attributes were very limited and also varied immensely inbetween browsers such as Internet Explorer and Netscape. Also, if you wanted to format text on the page, you had to use a variety of HTML tags like <FONT/> (Font type and size and color),<B/> (bold), <U/> (Underline), <I/> (Italics), etc.  Even if you used the same type of formatting many times in a page, you needed to insert all the necessary tags in every spot where the formatting would occur within the page.  Then along came Cascading Style Sheets (CSS).  It is a formatting specification that is either embedded within the HTML tag’s STYLE attribute or setup in a series of classes that are embedded in the stylesheet.  The stylesheet can either be embedded in the HTML page itself, or again can be housed in a separate file on the web server by using the <LINK/> tag. The styling format handles almost every conceivable formatting issue you might need to address.   Each HTML tag has a CLASS attribute where you specify the name of a CSS class that defines all the formatting for every object that has the same class.  So if you have 4 places on the page where you need an Arial font, 15pt, bold, italicized, with a padding of 5 pixels surrounding it, and with a a 1 pixel dashed black border surrounding the whole block; you can specify this all in one CSS class. Then in the 4 HTML tags where this formatting is needed you just specify the class name, instead of having to rewrite all that formatting code.  Each HTML tag also has a STYLE attribute.  You would only use this if this particular tag had unique formatting from everything else on the page. The great thing about using a separate CSS file is that you can share classes with every page on your website.  So there are 4 places on one page where that lengthy formatting is needed.  However, throughout the website you may need this formatting in 40 different places.  If you use a separate CSS file with the <LINK/> tag you only need define this formatting once.

Sound and video are usually not handled directly by the browser, but rather by Plugins, or the use of other viewers installed on the user’s computer.  Examples are Flash, Shockwave, Windows Media Player, and Quicktime.  If you want to display these within your website you need to be sure that a very large majority of end users have this software installed on their computers, or at the very least offer a link to a place where they can download the installation files for these products.  In my opinion (especially when it comes to videos) it is always better to offer many options to the user.  Sound and video files are separate files that reside on the server.  If you want to these viewers to appear on your webpage you need to make use of the HTML <OBJECT/> and/or <EMBED/> tags, or make use of a separate <FRAME/> or <IFRAME/> to display these items (I’d avoid the latter).  These files can sometimes be quite large which can be quite a burden to your bandwidth, disk space, the quickness of your web server, and can sometimes frustrate users who don’t want to wait to download things.  Thats why streaming audio and video were invented; so that these items can begin to display right away, and the server continues to download the rest of the file as the user is watching or listening. Streaming is a big subject, so we’ll leave it at that. 

So, as we can see, when a web page is loaded there may be any number of separate files also loaded besides the HTML itself.  Plain HTML pages are static, and are the same everytime it is viewed and by every user who views it.  Truly dynamic sites usually use server-side programming in order to generate customized content that changes.  This will be the subject of our next installment.

Again, you might ask, “Why should I care?”  You might ponder on how much knowledge of internet technologies is good enough for a business leader to have.  Afterall, after a certain point can’t we just leave it to the IT guys?  Again, I would encourage you to learn as much as you can, given the constraints of your time.  Otherwise you won’t be able to effectively manage your IT projects and operations.

“IT guys” have specialities.  Depending on what your company is trying to accomplish you need to hire the right folks for the job.  Depending on the specialities of your existing staff you may want to invest in computers, network equipment, and projects that use specific technologies that your staff is familiar with.  Having an overall understanding of how the World Wide Web works is going to do nothing but help you make informed business decisions on how you invest your IT dollars.

Web Servers, Input and Output Programs

A website is fundamentally a Client-Server program that runs on a Web Server, and is accessed through Clients, which are all the web browsers and automated systems that request information from it using the HTTP or HTTPS protocol.  Web browsers run on computers, and these days even on cell phones.  They are not the computer itself, but rather are software applications (such as Internet Explorer or Mozilla) that runs on these devices.  Similarly, Web Servers (such as Internet Information Server (IIS) or Apache) are also a software application that run on usually more powerful computers.  The job of the client software is to accept user input (through the keyboard and mouse usually) and then contact the remote computer running the Web Server software.  The Web Server handles the requests of the clients, and spits back the information requested to the client’s browser.  The client’s browser, then displays the information it has received from the web server, and displays it to the user.

The web browser usually requests a page or resource on the website, such as http://www.millcreekwebworks.com/default.aspx which is the Mill Creek WebWorks home page.  The web server accepts this request, processes it, and determines what HTML content it should return to the client’s web browser for display.  When you click on a link or a button in your browser, you are usually telling the browser to request a new page or resource from the website.  In the old days, you would not have a page called default.aspx.  The .aspx file extension is specifically a file dedicated to websites built in Microsoft ASP.NET.  Before ASP.NET or any of the other complex server-side technologies were developed, there were only static HTML pages and CGI scripts written in Perl and other compiled lagnuages.  HTML pages have a file extension of .htm or .html, and are files that contain the complete set of characters in HTML that is returned to the client’s web browser.  They are literally a file that resides on the web server, and if you were to login into the web server computer you could open up the HTML file in a text editor like Notepad and see it for yourself.  The HTML file can’t accept parameters, so therefore you couldn’t change things based on what users might type into a text input or anything like that.  The web server will return the same output every single time.  The original HTML specifications did allow for user inputs, like text boxes and checkboxes, but you had to write a CGI script to process the user input.  The script written in Perl was like a mini program.  When the Web Server was instructed to go to a CGI script, it would pass on the parameters of an HTML form to the program.  The program could then process these input variables, perform a storage or database update, and then could either redirect the user to a different HTML page (based on what was inputted), or spit back custom HTML based on the user input.  Perl Scripts were really the predecessors to all the custom and dynamic websites we see today.  Without them the Web was simply a one way communication of static information from the web server to users.  Without them you couldn’t do a Google search, or make an eCommerce purchase, or anything. With them it was the beginning of being able to build truly interactive applications on the Web.

These days the information returned by the Web Server includes much more than straight HTML.  It includes CSS, Javascript, XML, graphics, and sound.  We will discuss all of these complexities and what they do in our next segment.

Just to save some time (and get you to read the rest of this post!) I think I should answer the second question first, i.e. Why should I care?

You probably know all the buzzwords for internet technology. You can spew off terms like “TCP/IP”,”HTTP”, “SSL”, “HTML”,”ISP”, etc., etc., etc.! However, while you might get away with throwing around a few carefully selected buzzwords at a company social, when you are working with IT departments you really need to have some understanding of how the web works.  If you are simply an end-user of the internet it is probably sufficient to know how to turn your computer on, open up Intenet Explorer and Microsoft Outlook, and start using the web. Not too much to it really.  But if you are going to be utilizing internet technologies in order to build your company you need to know what technologies can help you, what the pluses and minuses of each technology are, and what other dependent technologies are required for their use.  Even if you rely upon the recommendations of your IT department or your IT consulting firm, it is still a wise idea to know enough so that you can make wise decisions on their recommendations.  After all, you’re in charge.  The company’s success is in your hands, not theirs.  You wll be the primary recipient of the rewards of success or the consequences of failure.

The Internet - A Network of Networks

The first thing you should know about the world wide web is that it is NOT the internet. The internet is actually the physical network of computers and devices that are connected together, and communicate together around the world.  Its origins can be traced back to the late 1960’s when the first computer networks were linked together through ARPANET between UCLA and SRI International.  By the early 1980’s it had grown to be an international collection of educational and government computer networks.  By the late 1980’s the TCP/IP protocol was developed and commercial computer networks were allowed to join, and the internet has been booming ever since.

Network protocols, such as TCP/IP, are the low-level language that computers use to talk to each other.  There are others, such as IPX/SPX (Netware Networks) and AppleTalk.  TCP/IP is actually a suite of languanges that are commonly used for the internet.  The backbone of the suite is the IP Address.  Each computer which is connected to the internet must have a unique number in order to differentiate itself from other computers. The IP Address is a set of 4 numbers which can have up to 3 digits for each number.  Each number is separated by a dot (.), and looks like XXX.XXX.XXX.XXX.  Most of these numbers are available for use on the internet, but some ranges are reserved for use in internal networks, such as 10.0.0.0 - 10.255.255.255.    There are approximately 4.3 billion possible IP addresses. As you might imagine, the world is quickly running out of these ip addresses.

Most computers are not directly connected to the internet, but rather are part of a network that is connected to the internet.  You must go through an Internet Service Provider (ISP).  For example, you may have a small wireless home network of computers at your house. The individual computers all are assigned a private ip address, such as 10.0.0.11, 10.0.0.12, etc.  They talk to to your wireless router.  Your wireless router is usually hooked up to a cable or DSL modem, which in turn directly connects to your ISP, such as Time Warner, or Verizon.  Your wireless router is assigned an ip address from the list of your provider’s available public ip addresses by using the Dynamic Host Configuration Protocol (DHCP).  DHCP is one of the network protocols that is part of the TCP/IP suite of network protocols. In the days of dial-up phone modems it really helped on conserving public ip addresses.  When someone disconnected from their dial-up connection, the public ip address would be released, and would be available to give to another computer dialing in.  Now, with all the broadband connections that are available at home, and on mobile devices and cellphones, your connection is always on whether you are using your computer or not, so the public ip address is never released.  Anyhow, when you ask for a web page or ask for anything on the internet, your wireless router acts as a proxy.  By utilizing Network Address Translation (NAT) (Another member of the TCP/IP protocol suite) your wireless router passes on your request for the internet resource using its public ip address, and then when it gets a response it forwards it on to your computer that has a private ip address. It “translates” for you, and for every computer in your house.  Instead of having to have one public ip address for each computer on your home network, it only needs one.

Now the world wide web is actually a bunch of computer servers that are connected to the internet network that serve web pages through either the HTTP or HTTPS network protocols.  Again, these are sub-protocols of the TCP/IP suite of network protocols.  When you type in URL into your browser your browser makes a request to the web server to give you a particular page that it is hosting.  The web server responds to your browser, and the browser displays the results.  HTTP is the normal protocol used.  HTTPS is a secure encrypted protocol that is often used by online banking systems, and other web servers that host sensitive data that you don’t want intercepted by some hacker.

Now the web server has a public ip address, and if you typed it in to your browser the website would still work.  Google’s web server has a public ip address, and if you type http://74.125.45.100/ into your browser, Google will appear.  Typing http://www.google.com only works because www.google.com is registered with a Domain Name System (DNS).  A DNS Server keeps an entry in its records for every domain name, and what the public ip address is for the internet server that it corresponds to.  DNS is yet another sub-protocol of the TCP/IP suite.

Email and FTP do not use the HTTP or HTTPS protocols.  Rather they make use of other TCP/IP protocols such as POP3, SMTP, and FTP.  If you use a browser to get your email from a hotmail email account you are indeed using HTTP or HTTPS to access the hotmail  web server.  However, the hotmail web server uses the SMTP and POP3 protocols in the background in order to access hotmail’s dedicated email servers. If you are using MS Outlook, the program accesses the email servers directly, and uses the SMTP and POP3 protocols to do so.

Summary

There are many great articles on internet infrastructure.  I would suggest the How Internet Infrastructure Works on howstuffworks.com.  In the next blog post, I will discuss how web servers operate.  Please check back soon!

What exactly is a “Specializing Generalist” anyhow?  We all know what a “Specialist” is.  This is someone who devotes most all of their efforts to one particular field of study, and is usually really, really knowledgeable about it.  A “Generalist” on the other hand, is someone who knows a little bit about about a lot of different fields of study.  The critique on specialists is that that they usually are in world of their own, and don’t understand or appreciate the other fields of human knowledge.  It tends to make them hard to work with; like the proverbial nerd stuck in a server room somewhere that no one really wants to talk to unless there is a BIG problem.  The critique on generalists is that while they might make great conversationalists at parties, they most likely will be unable to contribute anything useful or unique.

A “Specializing Generalist” is one who takes an in-between tact.  In a business environment they make it a point to have a large breadth of knowledge about all aspects of their industry.  This way they can appreciate and work with their co-workers more effectively.  At the same time they spend extra time in a particular specialized field of study, such as IT.  Even within the IT field itself, Agile Development proponents, like Scott Ambler, encourage IT professionals to obtain a large breadth of knowledge in the various IT disciplines, but still concentrate on a few areas of technical expertise.  After all, unless we are Michelangelo, or Matt Damon in “Good Will Hunting,” even the best IT professionals are simply incapable of being experts in ALL the various and ever-increasing arsenal of computer technologies.

What does this mean in practical terms?  For me it means that I have made a conscious decision to specialize in a few key areas like ASP.NET and MS SQL Server.  At the same time I also devote a good amount of time studying other related technologies, like Java, Oracle, and hardware configuration.  The benefit of this approach is that most of the time I have enough knowledge of all the disciplines required to bring an IT project from start to finish.  There are occasional times I get stuck, and have to peruse technical forums and consult the true specialists, but that’s the exception and not the norm.

In addition, I have also always made it a point to become well versed in how the company I am working for does business, and how Information Technology might be able to improve their processes.  A good applications developer knows the business well enough that they can read between the lines of a business requirements document, and deliver a product that is truly going to help the business grow.  In reality I am both a “Specializing Generalist” within the IT profession, and within the general business framework itself.

What does this mean for the non-technical business professional?  It means that while you have your field(s) of expertise, you still need to learn the other business disciplines within your company, including IT.  For instance, you may be a marketing professional.  While you might be an expert in that field, you still need to know about product development, and sales, and finance; because all these disciplines interact everyday with your company.  And you better know IT.  A LOT of marketing is internet-based these days, and you need to have an understanding of what technology can and can not do for your next marketing campaign.

The end result, of course, is that business teams of various types of “Specializing Generalists” can work better together when they each have some knowledge of the others specialties.  The more effectively teams can work together, the more likely it is that your business will grow.

My goal is for this blog is for business and IT professionals to engage.  The chasm between the two worlds is shameful, and is most certainly not advantageous for anyone.  Likewise, as I delve more and more into the blog world, I hope I can gain a better knowledge of other disciplines from you, the business professional.  Its a two-way street.  It always has been!

We want your input! Please leave LOTS of comments, questions, and suggestions for new topics.  If your a technical expert and feel there are some subjects that would benefit a business audience we would enjoy your contributions.

By the way, this blog is sponsored by Mill Creek WebWorks.  While we would enjoy working with your company to provide applications development services, this blog is not an advertisement, but rather a public service.  When business and IT leaders share common knowledge and respect, all of our efforts will be bettered.