If you read the IBM literature, the
word server can practically be swapped with the word JVM.
Each 'server' in WAS has its own logging file, its own process id, its own ports for http listening, etc. All those things sound like the properties you'd associate with a JVM.
So, yes, each running server, with its own ports and logging file, is a unique, identifiable JVM that runs as a process on your server. You can see the java.exe file in task manager if you're running Windows.
Here's a little snippet from an article I wrote on the subject:
What is an Application Server in WebSphere?
What is an �Application Server?�
The administrative console makes it very easy to set up and configure a JVM on which to deploy your application, although they throw you a curve ball by referring to a JVM as an �application server.�
Yes, within the administrative console of the WebSphere Application Server , you can set up these things called �application servers.� Confusing? I think so.
I mean, it is an application server, and it can create application servers. I�m sure there�s an Abbot and Costello routine in there somewhere.
If you use the administrative console of the WebSphere Application Server, and look at the various features of an �application server,� the type that you can create within WebSphere, you�ll notice that many of its properties are curiously similar to the ones you might see on a regular, everyday, Java Virtual Machine.
Some things you can configure on this mysterious entity called an �application server� include:
-classpath
-debugging service
-output logs
-heap size
Sounds an awful lot like the properties of a Java Virtual Machine to me!
In fact, when you �start� an application server, you can monitor the various process that are running on your system using the task manager, and you�ll notice a java.exe process will kick off that consumes upwards of one hundred megs of memory. That�s your application server running right there.
Of course, we must accept that the JVM running our enterprise applications is much more than the simple process that supports the standard Java development kit (SDK). Our java.exe process that our applications run on also supports a web container, an ejb container, a naming service, security service and transaction service, just to name a few. Nevertheless, under the covers, an �application server� simply represents a java.exe process running on your machine.
So, how do we resolve this naming conflict? WebSphere is an �application server.� Yet what we deploy to, essentially JVMs are �application servers� as well?
When I�m consulting, I try to establish a common vocabulary as early as possible. When I�m talking about the product WebSphere, like the one that comes on the CD that you purchase from IBM, I refer to it using the acronym WAS, which rhymes with spazz, meaning WebSphere Application Server.
�Always try to establish a common vocabulary�
When I�m referring to the java process on which ear files are deployed, I refer to them as JVMs, and to a lesser extent, �application server,� although I try my best to avoid the term.
Establish a common vocabulary between your developers, administrators and managers as early as possible. Understanding what your teammates are saying isn�t nearly as important as understanding what they mean.
One of the problems with an application server, or JVM, or java.exe process, or whatever you want to call it, is that it can fail. It can all of a sudden just disappear, or even get so tripped up over itself that it just sits there and consumes memory and clock cycles but doesn�t actually do anything. Of course, this type of scenario would never happen if you were using software and hardware by IBM, but if you�ve got software from any of those fly by night companies such as Microsoft or Oracle, you just might run into a situation like this.
And what happens when your virtual machine shuts down? Well, your applications stop working of course. They don�t just run on their own, you know.
