A short note on Application Servers
Date : 3 December 2016
Version: 0.0
By: Albert van der Sel
Status: just starting.
Remark: Please refresh the page to see any updates.
1. Introduction:
Everybody knows that, quite a while back, a "2 tier" architecture was commonplace.
It often meant that a PC (or a number of PC's), could access "one-to-one" a central machine
which holds all data, and all business logic (often in 3GL programming) to retrieve and/or modify data.
In case of "3-tier" or "4-tier", we have an Application Server (or more often: a farm or cluster),
which contains "presentation services" (which forms the webpages for clients with the data), and "business logic",
where this "logic" defines the way to access the data, which data, and which enforces business rules.
This Application Server, more or less, "sits in the middle" between the clients and backend Servers (like database engines).
A number of reasons emerged, as to why to implement such a "3-tier" (or N-tier) architecture.
Those reasons are most interresting, but which I will not discuss here.
Instead, I like to focus on some technical architectures, and maintenance principles, on such architectures,
which I hope might be of use. Ofcourse, this will be a "lightweight" discussion.
Take a look at figure 1 below. It shows a high-level view of an example of such an architecture. Here, this example
is based on a Java EE principles. There are ofcourse more "worlds" or "platforms" next to a Java based architecture.
I plan to discuss some stuff of "Websphere", "Oracle 10ias or 11g/12c Weblogic/fushion", "pHp app server" and "IIS/Dot Net".
That's a whole lot indeed. But needless to say that this will be a high-level, short and humble note on those subjects.
So, this note might have some use if you are relatively new in IT.
By the way, there exists nummerous different "Application Servers". The four mentioned above, I think represent the most
common ones found in business environments. However, some proprierty (and possibly somewhat strange) App servers exists too,
some even with a Win32 API executable as the Server component (on a Windows Server machine).
Figure 1: High-level overview JEE (Java) based Application Server.
The blue part in the middle, represents the Application Server.
Usually, there are two main parts. In a Java EE environment, more comprehensive objects like "enterprise java beans"
take care of transactions, and following the right rules, etc.. and peform (usually) more complex logic.
Another part is responsible for "presentation services", that is, once for example, business data is retrieved,
it will then be nicely packed in (for example) as .jsp page, which then is available for the client.
Many questions can be asked. For example, how is authentication performed in such a setup?
Indeed, that's why the real-world architectures generally have more complexity.
However, you can brush up an App Server to enormous complexity, or contrary, device a simple implementation.
Take a look at figure 2. Here a "pHp Server module" responses to client requests, and retrieves (or insert/update)
information from or to a database. One advantage here is, in this simple setup, is that any client only need browser software,
while a central middle tier handles all requests and transactions.
Figure 2: A simpler implementation of a pHp driven App Server.
Let's take a high-level and simple look at some real-world implementations.
2. Oracle 11g/12c Weblogic / Fushion :
This is quite a large and complex one. The early App servers "9i AS", and "10g iAS", used a certain architecture.
However, since Oracle aquired BEA (Weblogic) and SUN (java, sparc etc..), and ofcourse thanks too continuous R&D,
the resulting Weblogic / Fushion architecture is a rather different animal, but still some 10giAS features can be reckognized.
In a very general statement, you might say that "Fushion" is the full middleware stack, with strong SOA and ESB features,
while "Weblogic" is the active Application Server, working in that architecture.