January 31, 2007

Wow. I saw the Microsoft ‘Wow’ add for Vista. Wow is right, an operating system that took so long to develop, that delivers so little and requires so much (hardware). Wow. I think Microsoft should pay to upgrade my laptop so I can have the “full Aero experience”. Seems only fair.


Vista, Grrrr

January 30, 2007

This is the Vista Premium Ready spec:

  • 1Ghz processor
  • 1Gb memory
  • 128Mb graphics memory
  • 40Gb hard drive
  • Internet access

But, despite trumping this lot by a long way, including having a 256MB graphics card, my laptop won’t (according to a Vista readiness scan) run the more advanced features of Aero. Grrr. What were they thinking? How did they even develop these advanced features considering the graphics hardware would not have been generally available prior to six months ago.

Make no mistake about it, the Evil Empire has not gone away, and is busily attempting to patent other peoples work. Oh shame on you Microsoft, you’ll just never get it.

Often we need to be able to monitor and manage clustered servers as a single entity. This is an outline of an approach I’ve used before to monitor and manage a clusterable enterprise server product which had very demanding RASP and throughput requirements. It is based on JMX, but allows for an aggregated view of the mbeans (monitoring attributes and management operations) in the cluster i.e. it allows for things to be examined in a meaningful way at the cluster (or service) level, while at the same time being able to view an individual nodes value for that attribute.

It also enables an operation to be executed once for the whole cluster e.g. flush a cache, rather than having to manually do that for each server instance in turn. This can be achieved using a standard single server aware mbean console (a limitation of most off the shelf open source ones).

The kind of aggregation appropriate for an individual attribute can be easily configured, and a view can be presented at the cluster level and at the individual servers (node) level. Different attributes require different kinds of aggregation. For example, the aggregation of the number of items in a given cache across the cluster would be the sum of all the individual cache sizes, but at the same time we also want to be able to see the value for an individual node. In the case of message throughput the aggregation might be an average of all the individual servers throughputs, and we might also want a count across the cluster of messages processed to date, as well as those statistics on an individual node basis. For another attribute it might not be sensible to aggregate it, so we might just want the individual values for each node to be shown together. The point is that a sensible “cluster” view of a given attribute differs.

The basic idea is to instrument the classes that house the stuff you want to expose as normal using an MBean interface. So each node in the cluster exposes all its stuff as an individual server. Additional metadata is added to the MBean interface using variables (static final Strings), which describe what is to be done with the individual attributes and operations. I say static final Strings because this annotation is Java 1.4.x compatible, but if you’re using Java 5 then of course you can use “real” annotations.

The mbeans are registered with the mbean server via a façade – lets call it MBeanServerFacade. The facades job is to interrogate the mbeans and extract metadata using introspection. A simple convention is followed for the variable names in order to associate them with the monitoring attributes and management operations. The values of the strings then describe how the attribute is aggregated (and other useful things). The metadata could be described somewhere else, but the advantage of putting it on the mbean interface is that its easy to develope, and it lives with the attributes, so when the mbean changes the metadata can be easily changed with it. Also, it is really simple to add these annotated mbeans so there is no barrier to adding instrumentation to the server (and for clustered servers setups you can never know enough about what is going on under the covers). MBeanServerFacade writes the metadata to a simple database table, if that particular type of mbean hasn’t already been registered. It also writes the host address of each node in the cluster to another table.

The next element in the architecture is a broker process. This should (but does not have to) live separately to the cluster, so on a standalone server instance. The MBeanServerBroker reads (and periodically reloads) the descriptions in the tables populated by MBeanServerFacade. So the broker has a full description of all the relevant mbeans available and all the servers where they can be found. MBeanServerBroker is used as an intermediary between the various MBeanServers and the calling application. Using the metadata MBeanServerBroker creates JMX dynamic mbeans which expose an appropriate aggregate view of the individual mbeans across the cluster. Because it uses dynamic mbeans, the aggregate mbeans can also expose the individual attribute values (and which server they belong to). When an aggregate operation is invoked from the console, MBeanServerBroker runs that operation on each node in the cluster. The other important job of the broker is caching the returned mbean information. This is because JMX requests are expensive both in terms of the caller (waiting/blocking) and the component exposing the mbeans (doing the work of gathering the mbean info etc.). The console remains responsive because its hitting a cache, and the broker updates the cached values frequently. It’s the dynamic mbeans exposed by MBeanServerBroker that the console looks at.

Here is an example of an annotated mbean interface:

interface MyStatsMBean {

/** attributes */

int getCacheSize();
int getAvgJmsReadsPerSecond();
int getMaxInsertMessageTime();
int getMinInsertMessageTime();
int getUniqueValue();

/** annotations */

String getCacheSize_AM = AggregateMethod.SUM;
String getAvgJmsReadsPerSecond_AM = AggregateMethod.AVG;
String getMaxInsertMessageTime_AM = AggregateMethod.MAX;
String getMinInsertMessageTime_AM = AggregateMethod.MIN;
String getUniqueValue_AM = AggregateMethod.LIST;

In this example we want to see the sum of cache sizes across the cluster, the average JMS reads per second across all nodes, the slowest message insert into the database, as well as the quickest, and a list of individual values for an attribute that it does not make sense to aggregate.

m2eclipse looks good

January 23, 2007

I know I’ve come across various Eclipse plugins that work with maven artifacts like the Project Object Model (pom.xml), but m2eclipse is the first I’ve seen that really attempts to integrate the two project environments. m2eclipse at Codehaus is just getting going, being at a 0.0.10 release, but it looks very promising. Check out the flash demo, the debug integration is really cool. I’m definitely going to give this plugin a whirl shortly as I’m planning a couple of new projects where I’ll be using maven2 in anger (I’ve been a maven 1.x baby for a while, but I think its time to grow up!).

Network Technology Magazine has voted Cape Clear one of the Top 20 Products of 2006. This adds to our already impressive bag of awards for 2006 and demonstrates once again that the Cape Clear ESB is the product to put top of the list when evaluating SOA platforms.

It seems every software company is pitching some form of SOA Best Practices. But even ignoring the built-in bias, some of the best advice can still go very wrong. Instead, by understanding the pitfalls and landmines of SOA implementations, you will be in a better position to create a strategy that makes doing the right thing easy.

Learn from Cape Clear’s expertise across hundreds of SOA deployments and avoid critical mistakes that could spell failure for your SOA initiative.

Join Cape Clear’s CEO Annrai O’Toole for a down-and-dirty discussion on the Top 10 SOA Worst Practices. General topics include:

  • Short-cuts you can’t afford to take
  • Using services the wrong way
  • What not to do with BPEL
  • Performance testing no-no’s
  • Executing projects without the proper tools

This webinar will take place on January 31st, 2007 (08:00 PST, 11:00 EST, 16:00 GMT, 17:00 CET) and you can register here.