Preemptive Support

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Ian Goldstein's Blog | January 25, 2007  11:54 AM | Comments (4)

What It Isn't
Traditional customer support in the software industry has always been reactive: you encounter some problem, you do a bunch of time-consuming research and troubleshooting, you report it to your vendor's support organization. You wait for a resolution.

What It Is
Pre-emptive support turns that model on its head by using software to check for potential problems before they become actual problems. BEA Guardian is that software.

How Does It Work?
Let's start with the facts: software vendors' support organizations know a lot about the kinds of issues you encounter when you run their products, and the experts in the support organization know how to resolve those issues. The problem has always been about how to share or distribute that vast collection of specialized knowledge and expertise to the right customers. BEA Guardian solves that problem: each potential problem is encapsulated and described in a signature. Guardian evaluates signatures against your target systems and makes specific recommendations for how to avoid the problems you may encounter.

What is a Signature?
A signature is an XML document which describes a potential problem. It includes instructions for Guardian to determine whether this signature is "detected" in your target system, and each signature provides user-friendly recommendations for how to resolve any issues that are detected.

BEA Support has already written lots of useful signatures which are helping our customers prevent potential problems from becoming actual problems. Do you want to help us? Check out the Guardian Signature Sweepstakes.

Comments

• You asked:

  Is there a public list of the capabilities that Guardian has when scanning a domain? Meaning, what is in scope for a signature:

  Guardian v1.0 collects three types of data for the supported targets*:

  • Configuration and Runtime MBeans
  • Java System Properties
  • JDBC Metadata

  Signatures today can use any combination of data from these sources. We are introducing new collectors in our upcoming releases, so please don't limit your signature contest submissions to the data available today -- your ideas will be very helpful in prioritizing additional collectors.

  *Supported Targets: BEA Guardian runs with BEA WebLogic Platform 8.1 and above (including the following related products: BEA WebLogic Portal, BEA WebLogic Integration, BEA WebLogic SIP Server, BEA AquaLogic Service Bus, BEA AquaLogic Data Services Platform, and BEA WebLogic RFID Enterprise Server).

  Posted by: iang on February 2, 2007 at 10:29 AM

• I would like to add that this list was taken from the following page and created by a different company - a consulting company.
  http://joce.nljug.org/confluence/display/EJAPP/Home
  
  Our own internal performance hot spot lists has a number of differences but most important a weighting on the possible severity of each issue we have ourselves identified. A database probably can have response times in the minutes whereas it is very unlikely that an external library could consume such an amount of cpu or wall clock time.
  
  For your information configuration is on our list but of a very low weighing both because it is ow hanging fruit (solved before we get there) and because the severity is normally low. Of course one would expect that containers do already come with resource (threading, pooling,....) managers that are self tuning. Just imagine developers having to run a complete execution of their application just to determine the fixed size of a hashmap - not practical hence the hashmap internally manages its own growth.
  
  regards, William

  Posted by: wlouth on January 29, 2007 at 11:17 AM

• Here is a list of common performance problems presented at the recent JavaPolis conference. So considering that Guardian has very little insight into actual ** application runtime ** behavior other than deployment configuration via JMX it would seem that the association with improved performance is greatly exaggerated if not completely misleading.
  
  * 10 - Excessive logging
  * 9 - Incorrect application server configuration
  * 8 - Incorrect usage of JavaEE
  * 7 - Unnecessary use of XML
  * 6 - Improper caching
  * 5 - Excessive memory usage
  * 4 - Badly performing libraries
  * 3 - Incorrectly implemented concurrency
  * 2 - Unnecessary remoting
  * 1 - Incorrect usage of databases
  
  At the end of the day Guardian is a solution for BEA's own support problems and in the big scheme of things has very little to offer operations fighting issues with internally/externally developed and deployed applications.
  
  It's great to see BEA improve its support offering especially when competing against JBoss/RedHat which makes its money on solely support and yet has nothing similar to offer except for bog standard web-based support case tool.
  
  regards,
  
  William Louth
  JXInsight Product Architect
  JInspired
  
  "Java EE tuning, testing, tracing and monitoring with JXInsight"
  http://www.jinspired.com
  

  Posted by: wlouth on January 29, 2007 at 8:42 AM

• Ian,

  I like the Ducati grand prize for the sweepstakes!

  Is there a public list of the capabilities that Guardian has when scanning a domain? Meaning, what is in scope for a signature:

  • web.xml
  • config.xml
  • system classpath
  • EJB deployment descriptors
  • .class bytecode inspections
  • jsp parsing
  • etc

  This info would help to know what are valid submissions.

  Thanks!

  Posted by: plaird on January 25, 2007 at 1:36 PM