Loosely Coupled Events with XSLT

This development group has missed the promised deliverable date for a public-facing financial application. Important business functionality simply doesn't work, so the incomplete event management requirements are, understandably, at the bottom of their priority list. Nonetheless, the application cannot ignore the system management requirements for two important reasons. First, operations will strongly resist the deployment of an application into which they have no visibility and, second, because of the sensitive nature of the data, the developers have restricted access to the system.

Complicating matters was the developers' misunderstanding that the event console accepted events in an XML format and an schedule didn't permit changing the event generation code. Furthermore, the few events seen in the development development highlighted the fact that the developers had little opportunity to adequately instrument the application, let alone think about the types of events they need. So we change strategy. The XML is acceptable provided the events are populated meaningful XML elements or attributes. For example, ORA-06502 instead of a unparseable text message. A listener will receive the event, translate the XML with XSLT (Extensible Stylesheet Language Transformations), and create the event with XSLT beanShell extensions.

The XML strategy is promising because the event definition between the application and the console is now loosely-coupled. If a developer adds an element, the XML will likely continue to parse without problems. Best of all, the design policy is to simply send as many significant events as possible formated in XML. This policy relieves the developers from understanding the art of event management and I'll assume the burden of creating meaningful events. Hopefully this strategy is not one of wishful thinking; the project is still in development. Nonetheless, the promise of loosely-coupled events are significant enough that I'm recommending XML events to another project.

Tech Tags: IBM+Tivoli XML XSLT

WSDM is More than Marketing Fluff

WSDM, at least from IBM's perspective, is more than marketing fluff. Witness Tivoli Enterprise Console's (TEC) Feature Option 1 . Feature Option 1 is a set of four components to recieve and send TEC events as Web Services invocations using the Common Event Infrastructure (CEI) The four components are,

1. Tivoli Enterprise Console Web Services Adapter allows the rules engine to receive events as a web service.
   
2. Common Event Infrastructure Web Services Receiver is an event receiver for WebSphere.
   
3. EIF WebSphere JMS Provider forwards CEI events to TEC
   
4. EIF Event Definition to Baroc Converter, an utility to convert XML event definitions into a BAROC file format, the TEC rules engine event definition.

Feature Option 1, as the name itself might indicate to existing Tivoli customers, should be viewed as a preview. The documentation is sparse and searches of the both mailing list and support database yield nothing beyond marketing announcements.

HP is not as chatty a corporation as IBM and I'm not able to find implementation-specific evidence similar to IBM's CEI. But, truth be told, I'm not as familar with HP's sites so I'm probably missing some clues. The only implementation evidence I could find is the inclusion of WSDM in the glossary in two manualscan of HP's SOA Manager.

Tech Tags: IBM+Tivoli OpenView WSDM SOA

System Management Ruby?

The public spat between Joel Spolsky, the blogging CEO of Fog Creek Software, and David Heinemeier Hannson, the author of Ruby-on-Rails, elevates the Ruby scripting language to the topic of the day. Ruby will interest the system management community because it traces much of its heritage to Perl, the scripting language that so often patches together bits and pieces of the enterprise infrastructure. Ruby is also the scripting language that has captured the mindshare of the under 25 crowd and could subvert Perl much in the same way Perl subverted shell scripts and other utilites. Like Perl, Ruby can hit all the Unix system calls and most of the Windows API, process text with the same ease and bervity. In contrast to Perl, Ruby holds to a simple syntax and adds some powerful features such as dynamic programming. Unlike Perl, Ruby cannot yet leverage a comprehensive library of time-tested modules available in the Comprehensive Perl Archive Network (CPAN), but RubyForge shows much promise. And Perl can boast of its legitimacy because Sun, IBM and HP supply their respective operating systems with Perl, even if official support is uncertain.

Ruby has garnered much attention through a productive web application framework named Ruby-On-Rails. Rails is Ruby's killer app and should not be confused with the Ruby language. The Rails crowd shares a philosophy of simplicity with the author of Ruby and will gladly deny the framework additional functionality if that functionality adds complexity. And herein lies the rub. Complexity is often foisted upon system management and tools that promise simplicity are viewed with a healthy skepticism. Ruby is a language whose practioners zealously worship simplicity and denounce complexity as heretical. In fact, "enterprisey" is a derogatory term for complexity. Yet, almost paradoxically, the simplicity makes it so approachable and so productive that the language is difficult to ignore. All that is needed is time for the developers to code and maintain the libraries to integrate the odds-and-ends of the enterprise infrastructure.

For drama, read Joel's post and DHH (as David Heinemeirer Hannson is known) response. Joel's criticism's are almost correct, but he's not understanding the benefits of a dogmatic belief in simplicity. For thoughtful perspective, read Martin Fowler's essays on Evaluating Ruby and EnterpriseRails, or browse the many Ruby articles on IBM's DevelopersWorks site. Or read Tim O'Reilly's post comparing Ruby sales stats compared to those of Java, Perl and Python, and then wonder how long before Ruby becomes a presence in your infrastructure. If it isn't already.

Tech Tags: Perl Ruby System+Management

Doug McClure's blog on System Management

One of the most informative and balanced blogs I've discovered on business, service and operations management. Well worth the subscription.

Is WSDM a viable standard?

I view webMethods' Open Management Interface (OMI) as a consumer needing to build a simple custom agent to monitor the webMethods Integration Server. The requirement is a simple interface with which an agent can monitor events, performance, and, perhaps, start and stop certain components. The interface should require no more than a few hundred lines of Java to connect, monitor availability and capture events and I should need not invest more than a few days of development time to the effort. An off-the-shelf agent would be preferable, no such agent exists. I don't know if I can build such an agent in a reasonable time, but, a well-documented OMI interface exists for me to try.

Since OMI has evolved into Management Using Web Services (MUWS) portion of the WSDM, I'm hoping that some OMI work will translate to understanding a nascent, but useful standard. So imagine my disappointment when all I could dig up were press releases and marketing vaporware from the vendors. IBM, to take but one example, boasts about initial implementations of WSDM ..., as well as 30 products that the support the initial WSDM event format on their Autonomic Computing WSDM page. At best, two products support WRF (Web Services Resource Framework), a prerequisite for WSDM. Other vendors are just as guilty in their marketing claims.

But some more digging uncovers evidence that WSDM is slowly maturing. The architect and developer blogs of several vendors reveal a well-articulated shared desire for a web services management standard. IBM has contributed its Common Base Event to form the basis of the MUWS (Management Using Web Services) of portion of WSDM. And the WSDM mailing list exposes quiet, but steady activity. I'm guessing that WSDM will probably survive into a living standard as a sort of SNMP for web services, but it will be a few years before we see more than a few implementations.

My del.icio.us WSDM links are here.

Tech Tags: IBM+Tivoli SOA webmethods

Monitoring webMethods

One of my customers is deploying webMethods as a cornerstone of their SOA infrastructure and my group was tasked to monitor webMethods for availability. The easy, but less than elegant monitoring solution is to deploy a Tivoli Logfile Adapter to parse the webMethods log files for select messages, parse those messages into Tivoli events and forward the events to the event console. WebMethods admirably logs its many messages in a consistent format. Most messages are documented in an impressive 890 page guide. The more elegant solution is to write a client to plugin into WebMethod's OMI (Open Management Interface) and subscribe to the notifications. From a system management perspective, webMethods seems to be empathetic to the operations folks who need to keep the systems running.

Some searching quickly uncovered that the OMI specification was co-authored with HP and is a predecessor to MUWS, (Management Using Web Services) a portion of yet another OASIS web services standard called WSDM (Web Services Distributed Management). I haven't decided on WSDM's viability. My search results first led me to think WSDM was a stillborn standard birthed by marketing, but, now I'm not so sure. Look where MUWS lives now - the Apache WebServices Muse Project.

Tech Tags: webMethods WSDM Tivoli Apache

Some Serious Open Source Enterprise System Management Companies

A Slashdot post pointing to a Network World article titled Open Source Companies to Watch surprised me. Nine open source companies are reviewed and three companies, none familiar to me, are developing three separate open source system management suites. I had no idea that the open source system management community was so vibrant.

• Hyperic offers a well-balanced availability and monitoring suite for Windows and the major Unix flavors. Oracle, DB2, WebSphere, WebLogic and JBoss are supported. Hyperic is backed with $3.8 million in funding. The Hyperic suite impresses me as the most complete availability and performance management suite.
  
• QClusters is the company behind OpenQRM. It focuses on provisioning and managing virtualized environments such as Xen and Vmware. Qlusters has secured $23 million in funding.
  
• Zenoss is an availability monitoring package written in Python. Windows monitoring is supported through WMI. The development change logs reveal an actively developed product. Like Hyperic and Qlusters, Zenoss enjoys VC backing.
  

QClusters and Zenoss are founding members of the Open Management Consortium. Three other interesting consortium members are,

• Emu Software supports NetDirector, an configuration management system.
• Sybiot Security contributed OpenSIMS to tie together nmap, Snort and other tools into an unified management system, however, my impression is that development activity insufficient to sustain the project.
  
• Webmin is a venerable web-based system administration console for Linux.