From the IBM WebSphere Developer Technical Journal.

Fantasy meets reality

OK, I'll confess a weakness. I'm addicted to a particular genre of fantasy novels. One of my favorite pastimes is reading novels where the hero finds himself transported to a world where magic works, and it takes him half the novel to figure out how it works, and the other half to figure out how to save the girl. Not refined literature, I admit, but since there always seem to be a few more novels written every year with the same general plot, at least I know I'm not alone in my predilection.

Part of the attraction is that we've all had the fantasy of being able get something important done without having to work at it. Wouldn't it be great to be able to wave a magic wand and say "abracadabra" or "hocus-pocus" and have all of the drudge work of your job taken care of? While I'm not suggesting that I know how to make candlesticks sing and mops clean the floor of their own accord, I do know of something available for WebSphere administrators that in some regards can come startlingly close. For instance:

1. We've all experienced applications with memory leaks. Trying to track down memory leaks is a painful and sometimes fruitless task, and so we often end up deciding to make due by restarting all of the application servers every 24 hours or so -- which we do either manually or by writing a chron job. Wouldn't it be cool if the application server could figure out if an application running on it had a memory leak and could restart itself when necessary?
   
   
2. We spend ages planning how much hardware we need to run our WebSphere applications. The plans, of course, don't usually work out quite the way we hoped they would. Either we end up over-planning and have underutilized servers, or we under-plan and find our applications crashing at peak load -- when we least want them to crash. Wouldn't it be neat if the application could figure out how much processor power it needed at any given time based on how much was actually being used and only used that much?
   
   
3. Administering a WebSphere production deployment is often a thankless job. Many times the first indications you get of trouble are the angry calls from users telling you that response times are getting worse, or that the application has frozen. So you fire up ps on your Unix boxes and discover, sure enough, that your application servers are dropping like flies -- but only on some machines. Wouldn't it be great if you had a crystal ball to tell you the status of your whole cell at a glance?
   
   
4. To achieve acceptable response times when solving some application programming problems you must cache data. In some cases, the amount of data that must be cached is huge -- much larger than a single JVM can hold. And, of course, we want these programs to be highly available. Wouldn't it be nice if you could write a robust J2EE application that could cache data effectively, no matter what the size of the underlying datasets?
   
   

So where do we get this magic wand and crystal ball? They come as part of a new and so far little-known product called IBM WebSphere Extended Deployment (XD). WebSphere XD was introduced on a limited basis late last year, and learning about it and helping customers adopt it has occupied most of my time for the past twelve months. WebSphere XD, while not literally magic, can seem that way. Its magic comes through the use of autonomic computing, which can be thought of as applied artificial intelligence.

An autonomic manager (kind of like a little rules engine) monitors input from sensors, analyzes the input, and uses the information to plan decisions and execute appropriate actions. That's how WebSphere XD operates. Sounds simple when put that way, right?

While autonomic computing has been an emerging technology from IBM for several years now, WebSphere XD is the first product in the WebSphere family to take advantage of it in a really big way. We've taken the technology out of the research labs and moved it into the production environment.

So, what about the four magical examples listed above? Are they real or not? Turns out, they are very real:

1. Health Monitoring is a feature of WebSphere XD that enables you to set up a Health Policy on an application. You can set up a memory threshold that a sensor will monitor -- so for example, when your application's heap usage (as determined by the amount of heap remaining after garbage collection) hovers above 80% for some specified period of time, you can trigger an event that will force the application server to restart.
   
   
2. Dynamic Operations is another feature that enables you to set up Service Policies for your applications -- a service policy can specify a set of response time goals that your application must meet. If response time starts to slow down, the system can trigger Dynamic Placement -- which means that more copies of the application will be started on servers that are currently underutilized. If demand for the application goes down, the system can reassign those machine resources to other applications when they are no longer needed.
   
   
3. Visualization enables you to take different, "birds-eye" views of your entire WebSphere cell, or any subset of it. The Tree-map view shows you in one visual sweep how all your application servers are functioning, and whether they are meeting their goals. The topology view lets you to zoom in on individual nodes and see not only what's currently running, but how the node is performing as a whole.
   
   
4. The WebSphere Partitioning Facility (WPF) is a framework for building entire classes of applications that have previously been difficult or impossible to write in J2EE -- applications that require high availability, high transaction rates, very large in-memory caches, and likely partitioned databases. Previously, this kind of application would have required a high-end OLTP system and C programming, but now it can be done in Java™ with commodity hardware.
   
   

Impressive as these capabilities are, these are only the beginning. For example, WebSphere XD can also prioritize incoming HTTP requests according to predetermined criteria, meaning that more important applications are given correspondingly more resources than less important applications, while simultaneously making sure that no applications are ever completely starved.

In upcoming developerWorks articles, I will begin to explore how these capabilities are implemented, and how the magic of autonomic computing is harnessed within the WebSphere XD environment. In particular, we will examine what it takes to implement WebSphere XD in your environment, and how the new programming models available in WPF can help you take advantage of new patterns for building very large-scale applications.

And, as amazing as all this may sound, there will be no hand-waving or hocus-pocus involved.

Back to top

Acknowledgements

Thanks to Tom Alcott, Ken Klingensmith, Steve Fontes, and Bobby Woolf for comments and help with this article.

Resources

• IBM Autonomic Computing guide
  
  
• IBM developerWorks Autonomic computing zone
  
  
• Get involved in the developerWorks community, participate in developerWorks blogs.
  
  
• Browse for books on these and other technical topics.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Fantasy meets reality
• Acknowledgements
• Resources
• About the author
• Comments

Dig deeper into WebSphere on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers