SAP NetWeaver Landscape for Idiots
SAP landscapes seem to be very complex and therefore developers aren’t especially fond of going into details about them. I’ll try to explain in this weblog how the whole system builds up and why these parts are needed.
First of all, there is one component we call a server. This is where all our software runs (and we’re not discussing here why this makes sense). Despite the fact that after even the install of a developer version (that has only one server) there are more parts, those actually would not be needed. Actually, if you know the right port number you are even able to access this server and work with it directly.
This situation changes immediately once we put a second server into this environment, that is configured exactly the same way as the first one. Basically this is done to gain performance and again we are not caring why this is the case. From this point on we have two servers on a single machine (which in turn could be called a server), it is a good idea to call these server nodes. Once we have two (or more) server nodes a problem occurs that we did not have before: Which server should a client connect to?
To solve this problem there are several solutions, out of which we choose this one: another component is introduced, named a dispatcher. This component is dispatching requests between the client and the server nodes. The dispatcher’s job has several tasks. One is load balancing. We don’t want to go into the details here, just assume the dispatcher forwards requests to server nodes one after another.
But this is not all. Unfortunately we have to take into consideration that in the same session of one user this user may come back to the server node several times with requests. For the dispatcher this is not a problem as long as it would be for example a web server that is handling static web sites. In that case it does not matter on which server node each of the subsequent requests of one session would end up as the answer always would be an HTML page that is the same on all server nodes.
But in a second case we are running a program that is answering the request and any subsequent request could depend on its predecessor’s data. We call this context and therefore we need to handle all requests that are coming in for the same session to be forwarded to the same server node to find its session context again. This is simply done by putting a session tag into the request, so the dispatcher knows which server node is running this session.
Java or ABAP
So far we did not look into any specialty of ABAP or Java part of Web AS. As you might know, you can run application servers that are purely ABAP or Java, or you could run them together. The description of the landscape so far applies to both. In case you have an integrated system also called full blown NetWeaver server, there are two of the constructs we have described so far, one ABAP, one Java.
Again we have a dispatching challenge here, but a different one than before. We need to distinguish where any request that is coming in should go. That is easy to decide for the Internet Communication Manager (ICM), due to the fact that every request carries that information in the calling URI. In addition, the ICM has some web server functionality to prevent you from always going down to the application server level just for pumping through graphics.
Until now we were speaking about a single host system (despite the fact that you style=”font-style: italic;”>could install the already described stuff also on different machinery). Building a system that has more than one host brings up some more tasks. First of all there is the challenge for any client of such a system to find out where all those machines are located. Out of all possible solutions, it has been found that it is a good idea to have one single component that takes care of this. This component is called the message server.
The Central Unit
The message server plays style=”font-style: italic;”>the central role in a software cluster (That is a bunch of machines running all the same software to serve more clients then one system could). Unfortunately, when we would go into the details (which we will not do here), we would find out that the different systems in the cluster need to talk to each other to keep the system consistent. The message server not only knows where all the machines are, but also takes the role of the message distributor. If it would not be there, any communication in the cluster would have to be done directly between all servers. Once your cluster starts to grow, this means an explosion in communication efforts (the formula is something with a square sign in – Oh, style=”font-style: italic;”>you want to know it? It’s a good excercise and I kindly ask you to find out and put it into the comments of this weblog!)
- software cluster is a mechanism that makes a bunch of application servers react as if they where a single system.
- hardware cluster is a hardware system that connects machinery in a way so one system can take over if another system breaks down. This is also called switchover system
- database cluster is a way to distribute a database system.
The message server keeps cluster communication straight and serves signals that need to be broadcasted to all servers from a single place (There are exceptions, like the one that a message server can allow servers to open a direct connection for larger messages, but that again is a detail).
Now we are set. This is basically what you need to set up a complete distributed system (at least as long as it is from SAP). One thing to add:
If you followed accurately you may have a question at this point: Don’t we have a dispatching problem again when using different machines? Or is the message server the dispatcher for a cluster? Yes and no. When using SAPGui, the system actually is using the message server as a dispatcher by calling a list of servers from it and chosing one of them to connect to. But when using the web there are more requirements, like SSL handling and actual forwarding of requests. This is done by a new piece of software, the Web Dispatcher. The Web Dispatcher is again doing dispatching like we had it before and a couple of more things. Most important is that it has its own process and because of that can sit in between the firewalls of your web system, in the so called Demilitarized Zone (DMZ). If there would be no Web Dispatcher you would have to expose one of the other pieces of the system into the DMZ and that is not a real secure area to be in.
Actually I’m lying: there are alternatives for the Web Dispatcher, like reverse proxies (parts of web servers) or hardware load balancers. The difference is that those parts have not built in capabilities to read all the information from a message server (remember? Where are all my servers!) And you had to configure that for those parts (and changes too!). Though, they are not really alternatives.
I guess this is pretty much it. Any questions anybody?