FIGURE 1. All Device Nodes

Order does not matter so any communication from the Application Server to the Registration Server is the same as Registration Server to Application Server. Using the abbreveations, here are our combinations:
App/Reg, App/Auth, App/Desk, App/Phone, App/Hand
Reg/Auth, Reg/Desk, Reg/Phone, Reg/Hand
Auth/Desk, Auth/Phone, Auth/Hand
Desk/Phone, Desk/Hand
Phone/Hand

The way we come up with that list of pairs is that we start with the top of the list and select each item, such as App. Then we pair it with everything else that comes below it. We only pair it with things that come below it. This keeps us from coming up with pairs that are not ordered pairs. Since App/Reg is on the list when we identified all the pairs with App, when we go to the Reg list, we do not go back and put Reg/App on the list as it is the same as App/Reg.

We have 15 pairs. We have to identify which pairs have communcation. Try to resist the temptation to solve the whole problem at once. It is not one problem but a series of small problems. To come up with a diagram that shows the communication may help us to know what nodes communicate, but we also want to know why they communicate.

A path is not just a connection between two nodes, as it often has a directionality meaning there is typically a node that will wait for communication and another one that will initiate the communication. They maintain a client (the initator) server (the waiter) relationship. In this example we will maintain that all connections are client-server directional communication. As client-server is very popular this will be more often the case than not. If you are using a different configuration such as parallel computing, you will have to adapt this method for your situation.

A server starts first and will wait for another machine to connect to it. The client will connect thus allowing communication to take place. We typically see one server with many clients, though if we have only one server and one client the point to be made is that the server is the node that sits and waits to be contacted. A single machine may be both a server to some clients and a client to another server.

It seems as if we are already done with figuring out who is a client and who is a server. But the way we have established what is a client and what is a server is based on the actors. If a person is using a machine for communication it is a client. If there is no person associated with the machine we called it a server. Of course it is not that simple. The clients are correct. Machines used by actors are almost always clients.

Let us start with the bottom of our list, not as it is a bottom-up list but because I want to start with the easier cases of clients connecting to other clients before we tackle clients to server and servers to servers.

The first communication pair we look at is a Phone Client communicating with a Handheld Client. Since our clients here represent possible actors, we should look at the actors. If Carol, our student, were using a Phone Client to check her current scores, would that Phone Client ever have a need to connect to a Handheld Client used by Aaron who is currently viewing the class average. Of course not. So there is no communication between the Phone Client and the Handheld Client. Kathy, our administrator, is entering in scores using a Desktop Client. Would the Desktop Client communicate with Aaron's Handheld Client? No. Would the Desktop Client communicate with Carol's Phone Client? No.

None of the clients communicate with each other. They could if perhaps Kathy, our administrator, was able to "see" at her Desktop Client what Aaron were entering into his Handheld Client so as to help him understand how to use the system. But she cannot. We were not asked to design such a system.

The next pair is the Authorization Server and the Handheld Client. Do they communicate in our system. It is important to think about our system the one we're designing and not the world. It might be true that a user can connect to the Authorization Server using a Handheld Client to change his/her password. But we said that we are going to only use the Authorization Server and not provide any access to it. Check the use cases there is no means by which a user changes his/her password. We will rely on a mechanism already in place between a client and the Authorization Server, but we will not provide it. For our system, there is no communication between the Handheld Client and the Authorization Server.

What about the Phone Client and the Authorization Server? No, the same reason applies we are not designing the user interface to the Authorization Server. What about the Desktop Client and the Authorization Server? No, same reason.

Next we will look at the Registration Server. There is no communication between the Handheld Client and the Registration Server for the same reason there is no communication between the Handheld Client and the Authorization Server. No communication between the Registration Server and the Phone Client. No communication between the Desktop Client and the Registration Server. Notice that each pair has been identified individually. It is very common mistake to rush through the communication pairs once we start to see a pattern. The reason why we identify and discuss each pair is so that we do think through the problem a step at a time.

The next pair is the Registration Server and the Authentication Server. Looking at the names we would not think that a server connects to another server. This is not always the case. Sometimes in order to satisfy a request from a client, a server may have to turn around and connect to another server for information or work. For instance, the Registration Server may contact the Authorization Server to determine if a particular user has adminstrator rights in order to cancel an entire course. For two servers, we should look at them based on order to see if either one will act as a client of the other.

Will the Registration Server contact the Authentication Server? In spite of the example just given about checking to see if a user can cancel a course, we really do not know if the Registration Server will contact the Authentication Server. That would be up to the Registration Server. We are only using the Registration Server and are blissfully unaware of how it works. We could check, but how the Registration Server works is outside of our system and so we will not include it. After all, we did not include if the Desktop Client contacts the Authentication Server.

Will the Authentication Server contact the Registration Server? Again, communication between the Authentication Server and the Registration Server is outside of our system.

While the Registration Server and the Authentication Server are outside the scope of our system, do not assume that we would never indicate communication between two servers outside of the scope of our system as off limits. The methods presented here are a guide. If you feel strongly that your design will be stronger if you include the additional information, even though it is out of scope, you should include it.

Moving on we have five pairs to consider all involving the Application Server.

Does the Handheld Client communicate with the Application Server? Yes. Does the Phone Client communicate with the Application Server? Yes. Does the Desktop Client communicate with the Application Server? Yes. The clients connect to the Application Server to do all their requests.

FIGURE 2. Application Server and Clients

Does the Authentication Server communicate with the Application Server? Remember for server-server communication we should view it from each side. Will the Authentication Server make a request of the Application Server? No. The Authentication Server has no need to connect. Does the Application Server connect to the Authentication Server? Yes. That is how the Application Server can validate the username and passwords for the users. As long as there is a connection in one direction, there is communication between nodes.

Does the Registration Server communicate with the Application Server? Again, let's look at each direction. Does the Registration Server make a request of the Application Server? No. Does the Application Server make a request of the Registration Server? Yes. Therefore, there is communication between the Application Server and the Registration Server nodes.

Notice that I did not continue to draw the components or the execution environment nodes within the device nodes. A diagram may consist of several pages with different levels of detail. The earlier diagrams that identified the internals of the device nodes should be included. Different levels of abstraction is one of the only reasons for multiple pages. Do not create a huge diagram that has to be printed as multiple pages and taped together. Diagrams that cover a wall are not useful and are very difficult to understand.

FIGURE 3. Communication

Earlier I said that if the communication, or really any part of the design, is out of scope yet very important to be included, you should include it. Looking at Figure 19, there is one very important thing we have brought up during the process of coming up with our deployment design that we do not capture. We said that we will not provide any means to add/delete/modify users or their passwords. We said that that will be handled by the Authentication System. Figure 19 is our primary artifact from the node communication exercise and it seems to not capture that very important information. I am going to include a connection from a client to the Authentication Server and identify that it is out of scope using a comment. Otherwise someone may come along and think that we forgot to include the ability to change passwords.

FIGURE 4. Communication with Note

FIGURE 5. Application Server and Client Communication

How does Application Server communicate with the Registration Server? The two servers may not be close enough (same room or building) to be on the same local area network. But they are not simply on the Internet. We are able to label the communication how we see fit. The best description would be "campus network", a wide-area network (WAN). The Application Server and the Authentication Server even though run by the same department do not have to be on a fast LAN connection and can also be described as using our campus network or WAN.

The protocol used for communication would be dictated by the Registration Server and by the Authentication Server. For this we would ask. I will say that they both were written in CORBA, Common Object Request Broker Architecture, and so the protocol would be IIOP, Internet Inter-Orb Protocol. Since the protocol is very important when we implement the system, we should include it on our deployment diagram.

FIGURE 6. Communication with Type