Deployment

 

 

 

Application deployment is easy, especially if an ear file has been assembled properly.  With WebSphere, the art of deployment is essentially confirming that the names and bindings that are outlined in the various deployment descriptors are correct. Who knows, maybe an administrator will be required to associate an EJB with a connection pool, and then click finish.

“Application Deployment is Easy”

Now I’m sure that many a WebSphere administrator will cringe at that assessment, and surely managers will delight, but the fact is, when an ear file is assembled properly, preferably with WebSphere Studio Application Developer, deployment will indeed be easy.

The tough part of WebSphere administration is configuring the environment within which the application will run.  This includes everything from setting up connection pools and configuring message queues to setting up a persistent JNDI namespace and binding the appropriate resource references.

But to deploy a simple J2EE application, an application that doesn’t have huge dependencies on messaging or connection pooling, all you need to do is specify a Java Virtual Machine upon which the application will run and click ‘Finish.’

All of the J2EE components we create are Java components.  In order to run, they need a Java Virtual Machine (JVM) to run on.

How do you set up and configure Java Virtual Machine on which your applications will run?

Well, in the base installation, one is already set up for you, and it’s given the name “server1,”  although that Java Virtual Machine is usually cluttered with all sorts of sample applications you really don’t need. 

When you deploy an application, it’s nice to have a Java Virtual Machine dedicated just to that application. Of course, resource limitations don’t always make that possible, but it is nice to hone a JVM just for your application.

In a perfect world, if an administrator is about to deploy an application, they’ll set up or configure a Java Virtual Machine on which that application will run WebSphere, that’s an easy thing to do.

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:

Fclasspath

Fdebugging service

Foutput logs

Fheap 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.

How do you implement workload management with WebSphere?

If you want to protect yourself from a single, crazy, JVM going out of control and eventually shutting down your applications, what you do is deploy your application onto two or more JVMs.  That way, if one JVM shuts down, another JVM will pick up the slack.  In the meantime, WebSphere will recognize that a JVM has been injured, send it to triage, and hopefully get it back up and running again soon.  However, with an extra JVM running and picking up the slack, you clients won’t experience any downtime.

What is a cluster?

A cluster is the term given to two or more JVMs working together to serve up a common set of EJBs and Servlets.  If you want to workload manage your applications, which essentially means having redundant JVMs on which your applications are running, what you do is set up a ‘cluster.’

With a cluster, when you deploy your application, rather than deploying to a single JVM, you deploy your application to the cluster.  Then each member of the cluster, each Java Virtual Machine that is, is capable of handling requests from clients.

What is Vertical Scaling?

If a cluster is a collection of JVMs working together to provide a workload managed environment, then “vertical scaling” happens when each of those JVMs are running on the same physical machine.

Now I know what you’re thinking:  that doesn’t provide any failover support?  Well, if the cleaning staff accidentally kicks out the power cord on your server, then indeed, you’re going to experience some downtime.

So what benefit does vertical scaling provide? 

Vertical scaling provides a variety of benefits, especially if your environment is heavy on hardware.

First of all, if one JVM goes offline, whether intentionally or not, the other JVMs can pick up the slack, so you do get a certain degree of failover, although its not exactly the level of failover we usually associate with workload management. With vertical scaling, we are still node dependent.

A more likely reason for implementing a vertically scaled environment is to take advantage of powerful, multiprocessor machines.

The fact is, despite the use of our modern, multithreaded operating systems, there are enough concurrent processes within a JVM to make having one java.exe process running on a multiprocessor system a fairly ineffective endeavor. To take maximum advantage of your multiprocessor machine, you should implement vertical scaling and have n-1 JVMs running, where n is the number of processors in your system, and 1 is the number between zero and two.

What is Horizontal Scaling?

Horizontal scaling occurs when you deploy an application across multiple physical machines.  Horizontal scaling is traditionally  what we think of when the term ‘workload management’ is thrown around.

WebSphere makes implementing horizontal scaling incredibly easy.  The first step is to install the base edition of WebSphere onto a couple of different machines, and then install the Deployment Manager on another machine.  Make the base editions part of the deployment manager’s administrative domain, and then use the administrative console to create a cluster. 

The WebSphere Administrative Console makes it very easy to set up JVMs on multiple nodes that will act as a cluster.  When you subsequently deploy your applications to the cluster, the various JVMs on the multiple nodes will take part in serving up the application.  If one node goes down, the other JVMs on other nodes will pick up the slack.

Do I have to copy the contents of the ear to each node taking part in a horizontal cluster?

Prior to WebSphere 5, configuring a cluster through the admin console merely updated a central database where configuration was maintained for the entire administrative domain. An administrator was still responsible for physically moving all of the files and code associated with the application to each node responsible for serving the application.

With WebSphere 5, the administrator no longer needs to transfer files from one node to another.  A built in file transfer process transports the enterprise archive associated with the application to each of the nodes participating in horizontal scaling.

Can I deploy an application to just one member of the cluster?

Once you create a cluster of JVMs, you can no longer deploy an application to just one JVM in that cluster.  With a cluster, it is all or nothing.

However, there is nothing stopping an administrator from setting up another JVM separate from the cluster on which you can deploy your application.

Can I do WLM with the base installation?

The base installation allows you to create multiple servers, but it does not provide any facilities for clustering.  In order to implement horizontal or vertical scaling, you must purchase a license for the Network Deployment Manager.

Why isn’t there a button to start my server in the base installation?

The base edition allows you to create as many ‘application servers’, meaning JVMs, on which we can deploy an application, but it doesn’t provide any facilities for staring that server.  I guess someone at the WebSphere labs really wants you to upgrade to the deployment manager.

Any server created with the base edition can be started by going to the bin folder of the base editions install directory and running the ‘startServer’ command and providing the case sensitive name of the server that was created in the admin console.

Keep in mind that port conflicts might exist between server1, upon which the admin console for the base editions runs, and the server you may have created. 

If you’re having trouble starting a second server, named myserver for example, issue the following commands:

 

FstopServer server1

FstartServer myserver

Can you combine horizontal and vertical scaling?

Absolutely.  If you wish to implement vertical scaling and run four JVMs on a multiprocessor machine, and you also wish to concurrently take advantage of horizontal scaling by running a single JVM on a second, less powerful machine, WebSphere provides all of the facilities you need to do this.  In fact, it is no harder or easier than implementing horizontal or vertical scaling by themselves.

Does creating a cluster automatically provide session failover?

No.  Read on.