Client/Server Programming -- Week 1
Introduction
Client Server Programming continues building on the foundation of problem solving and programming learned in CS 1 and CS 2, but adds in the problem of having programs running on different computers communicating with each other. There are many ways of writing client server programs; in this course we will examine several.
This first week will cover the basics of client/server architectures.
Note that the links from this page are to handouts that will be distributed the night of class. Only print out those handouts if you could not attend class.
Main topics this week:
Intro & Syllabus
Course Communications
Your Student Manual
What This Course Does Not Cover
Coding Guidelines
Where To Develop Programs?
Client/Server Overview
Client/Server Communication
Designing a Client/Server Application
Assignment 2-1 Design
Next Week
Our first topic will be introducing the course and discussing the syllabus. I'll talk in more detail about several sections of the syllabus.
Required Materials
There are two books for this course. One is Developing Java Enterprise Applications, the other is NetBeans: The Definitive Guide. In addition, a good Java reference will be helpful.
Submission & Return Policy
Note that assignments are due in class the week they are due. If they are not turned in on the day of class, you have until the next week to turn them in for 10% off. After the extra week, you will receive 0 for the assignment.
If you will not be in class the week that we have a exam, you must make arrangements ahead of time to take the exam at the Teaching and Learning Center if you want the points for it.
Academic Integrity
You are expected to write, debug, and test your own code. If someone else offers you code to use and you accept it, you have cheated. If you give another student your code, and they use it, you have cheated. Any occurrences of cheating will result in a grade of 0 on that assignment, along with a letter that goes into your student record.
Academic Support
Free tutoring is available at Franklin. Use the drop-in tutoring sessions or the bulletin board tutoring if you have a quick question. Use individual tutoring if you are having consistent trouble with the concepts in the course.
Course Schedule
In your student manual is a schedule of the course. You are responsible for knowing when assignments are due. If there is a conflict between the student manual schedule and these lecture notes, the lecture notes are correct for this section of the course.
There are several ways of getting help outside of class.
Many students don't like using email for some reason. Email is the fastest way of getting an answer to a question outside of class. The instructor information page gives my email addresses. To get the most out of email, remember:
As computer programmers, get used to reading email frequently. A timely response to email is one sign of professionalism in programmers.
Course Bulletin Board
The web site associated with this class has a bulletin board. You can post questions there that your fellow students can answer. I will also check the bulletin board once a week, and respond to questions.
Phone
You can call me with questions, but most questions are better asked through email. Anything dealing with coding or problem solving is best done through email where you can show me examples of what you are asking questions about.
If you call me on the phone and I suggest that you send further information in email, that's a good sign that the type of question was better asked through email.
Don't call after 9pm. Thanks!
Your student manual has a lot of great information in the key points section of each module. You are expected to read it along with your textbook.
However, there may be differences between my lecture notes and the student manual. The lecture notes are correct for this course. If you are confused over when something is due or what we will be covering, the lecture notes are correct.
What This Course Does Not Cover
This course does not cover problem solving. You are expected to know the problem solving methodology from CS 1 and CS 2.
This course does not cover basic Java. You are expected to know CS II level Java already, and have an understanding of some of the more advanced topics covered in COMP 313 (multithreading, Java packages, etc).
You will be expected to follow the CS II Java coding guidelines in your programming assignments. The coding guidelines can be found here.
You may develop your programs for this course on any machine. Ultimately, you will turn in both a paper copy of your program and an electronic copy of your program. You will turn in the paper copy in class the week the assignment is due.
To turn in the electronic copy, you must transfer your code to a directory in your account on einstein. Be sure to set the permissions correctly (700), so that no one else can see your code. In the directory where your .java files reside, execute the following command:
~shaffsta/bin/submit345
This will copy all the .java files from the current directory to a special directory in my area on einstein. This is required, and you will not receive points for the assignment until this is done.
The MOSS tool will be used on submitted assignments to detect incidences of code sharing.
Client/server programming is any programming where you have a program on one machine (the client) requesting services or information from a program on another machine (the server). The terms client and server have specific meanings:
client -- Any program that makes requests of another program, typically over a communications network
server -- Any program that processes requests sent by a client, typically over a communications network
While client/server is usually done over a communications network, it does not have to be. A client/server application could run with both the client and server programs running entirely on a single machine.
A traditional client/server application could be represented by the following architecture diagram:
In this traditional view, multiple clients are run and connect to a single server. The server processes the requests from all clients and sends results back to the clients. The server contains all the information needed to process client requests. This approach is called a 2-tier system.
Over time, the architecture of client/server applications has become more complex. One of the additional complexities is the introduction of databases. A database is a server that is specialized in the storage and retrieval of data. A traditional server has the responsibility of both data storage and business logic. Business logic is all the rules and procedures required by the application. When we add a database to the mix, data storage is removed from the server and put into the database. The server and the database may be on different machines, leading to the following architecture:
This approach is traditionally called a three-tier system.
Many times a server does not have all the information it needs to process a client request, perhaps because of a need to distribute the processing over many machines. For example, perhaps one server handles all the information for product sales in Ohio, while another server handles all information for product sales in Kentucky.
With multiple servers, there are two basic ways of allowing the clients and servers to communicate. The first has each client connect to the server that can fulfill their request:
A disadvantage to this approach is that is requires clients to know which server can process a particular request, and where to find each server on the communications network. This is information that may change as the needs of the application change, which would require client updates. For example, the Ohio business may become so large that it needs split into one server per county, which would require the clients to know how to find the server for the appropriate county.
Another approach is to have each client connect to one server, and have that server forward any requests it cannot process. This is the approach used in Internet domain name servers. The request may get forwarded multiple times before it finds a server that can process it.
This approach requires clients to know about only one server, rather than many servers. For example, the Ohio clients will always connect to the Ohio server, even if they're asking about Kentucky data. This approach is called an n-tier system.
Other client/server applications, and their architectures?
There are many, many technologies for creating a client/server application. In this course we will cover some of the possibilities available in Java. Be aware, though, that many more possibilities exist.
To do client/server programming, all you need is a way of communicating between the client and the server. At the most basic level on the Internet, that means some sort of TCP/IP communication. The details of TCP/IP are beyond the scope of this course, so we'll consider a raw TCP/IP connection as the most basic level of communication. A raw TCP/IP connection is typically called a socket.
There are many issues that must be taken into account when using sockets.
For example, on one machine integers may be stored in two bytes, and on another machine in four bytes. Simply transmitting a two-byte integer from the first machine to the second does not allow the second machine to know what integer was transmitted. The second machine also must know how the first machine stores integers. Usually, instead of transmitting data in the machine's native format, the data is converted to a neutral third format for transmission. Then, the server must only know how to convert from that neutral format to its own format.
The process of converting data to the neutral format for transmission is called "marshalling" data. The process of converting data from the neutral format to one the machine can understand is called "unmarshalling" data. There is a definite overhead associated with marshalling and unmarshalling data that is separate from the actual time it takes to transmit the data.
Some of the ways of doing client/server programming: RMI, RPC, DCOM, CORBA, servlets, sockets, CGI scripts, EJB, etc.
Designing a Client/Server Application
Before we even talk about programming a client/server application, it is important to talk about designing a client/server application. Like any other type of application, it is possible to design a client/server application that will not perform as needed. For example, a bad client/server design may introduce unacceptable delays into the processing of client requests. An airline ticket agent cannot wait five minutes to find the status of a passenger's ticket. Or the number of clients that can be serviced by a server may be too low in a poorly designed system.
Client/Server Interface
Since the client and the server are usually separate programs, running on separate computers, there must be a well-defined interface between them. This interface consists of the list of requests that clients can make to the server, the information that clients must send with each request, and the possible responses that a server can make.
Defining this interface is part of the process of problem solving for client/server systems. After all, if you're not sure what is going to be done in the client versus in the server, you cannot start to write code.
Here is an example of a simple interface design between a client and server. The server allows clients to request arithmetic operations on doubles, and will send back the results of the operations.
double add (double first, double second)
The add method takes two doubles and returns the result, first + second.
double subtract (double first, double second)
The subtract method takes two doubles and returns the result, first - second.
double multiply (double first, double second)
The multiply method takes two doubles and returns the result, first * second.
double divide (double first, double second)
The divide method takes two doubles and returns the result, first / second.
Note that a description of each request is important. For example, the subtract request will give an entirely different result depending on whether the server returns first - second or second - first. The exact behavior of the server for each request must be specified as part of the interface design.
Common Client/Server Design Issues
There are some common issues that every client/server application must deal with: validation, and security. These are related issues, and both arise because of the fact that there are two separate programs involved, a client and a server.
You generally have quite a bit of control over the server...it must perform certain tasks, and you write it to perform those tasks. If someone writes another server program, they won't have access to your data sources.
However, you have absolutely no control over the client program. Certainly, you write a client program and distribute it to your users. Legitimate users will use that program and everything will work fine. Non-legitimate users, however, will do whatever they can to break your system (hackers, criminals, etc). Including writing a separate client program that uses your server.
Since you cannot be certain that a user is using the client program you wrote, your server must assume that every client is hostile. In other words, every client may send bad data designed to trick the system in some way. This impacts both validation and security.
Validation is the process of making certain the data the user enters is formatted correctly and conforms to whatever business rules the server has. Some of this validation can be performed on the client, and should be so that the user does not need to wait for a network transmission to the server and back to find out he entered two digits for his area code instead of three.
However, since the server must assume the clients are hostile, the server must also perform this same validation. A common way of hacking into systems is a buffer overrun...that is, sending more data than the server expects for a given field. So the server must be certain the data sent from the client is valid before using it.
Security is the issue of who controls what the user can and cannot do. If the client controls this, then you are asking for someone to write a client that allows them to do anything they want. The server must control security, regardless of what the client asks it to do.
For both validation and security, also remember that clients and servers are often written by different people in a company; there are often misunderstandings between these people as to what the validation and security rules are. The person writing the server must write it so that it behaves correctly no matter what the client sends.
Group Exercise
Design a client/server interface for the following problem:
Good Programming, Inc (GPI) has been contracted to develop a reservation system for rental cars. This system should allow a potential renter to use their home computer to find out what cars will be available when they want to rent a car, and to make a reservation of a specific car. Renters should be able to cancel their reservation if their plans change. A credit card number is needed to make a reservation, along with the renter's name and telephone number.
For the purposes of the exercise, consider a car to be identified by a string containing some identifying information about the car.
As part of designing the interface, your group will have to decide on the responsibilities of the client versus the server. Try to think of the disadvantages of each approach to make your decisions. Also be sure to consider error conditions the server may need to report (describe these in the text for each request).
Your first programming assignment will be officially assigned next week. However, since you will only have a week to finish this assignment, we will go ahead and assign the design portion of the assignment this week. This will not be due until week 3, but you would do well to finish it before week 2 so you can ask questions about the assignment.
The problem description for the assignment will be passed out in class. If you are having trouble coming up with the design for this assignment, a good way to start is by thinking about the problem as if it was all one program. For example, if multiple clients are involved, think of them as simply multiple people using the same keyboard (perhaps taking turns). Write an algorithm as if it were not a client/server application. Once that is done, decide where to separate the client and server (the interface), and separate the algorithm into a client algorithm and a server algorithm.
Next week we will cover using sockets to program a client/server application.