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