Elements of UML Style

Recently I've been developing a large number of UML diagrams that are part of a Solution Architecture Document. I ran across a great little book that has helped me improve the diagrams style, consistency, and make them easier to understand.

The book is The Elements of UML 2.0 Style by Scott W. Ambler.   The book assumes that you understand basic UML techniques and modeling already.  It provides a set of standards and rules for different types of diagrams along with a justification.

The book is inexpensive and easy to use as a basic reference.  Highly recommended.

Esper Complex Event Processor

I have recently been experimenting with an open source product called Esper that provides a complex event processor (CEP) engine.   Commercial support is provided by EsperTech along with an enterprise edition that offers some additional capabilities.

An article from TheServerSide describes Esper this way:

"The Esper engine works somewhat like a database turned upside-down. Instead of storing the data and running queries against stored data, Esper enables applications to store queries (or statements) and run the data through them. Response from the Esper engine is thus real-time when conditions occur that match queries. The execution model is thus continuous rather than only when a query is submitted."

I used  Esper to build an application that monitors an Oracle SOA Suite for Healthcare Integration cluster and provides information about the status of endpoints and different views of the messages flowing across the cluster.  I had done something similar using Splunk earlier in the year and wanted to see how Esper would compare.

I started by creating simple Java POJO classes that represented the events of interest.  For example, the class for an HL7 message looks like this:

public class MessageEvent {
    String id;
    String direction;
    String messageType;
    String senderName;
    String receiverName;
    String state;
    String docTypeName;
    String docProtocolName;
    String docProtocolVersion;
    GregorianCalendar eventDate;
           ....

Next, I defined various windows using Esper's Event Processing Language (EPL).  A window is a logical view of a sliding time scale.  Using a window makes queries easier to write.  For example, to create a window that retains messages for the last 15 minutes, the definition looks like:

create window Messages15mWindow.win:time(15 minutes) as 
select * from MessageEvent

Finally, I created queries that retrieved data of interest from these windows.  For example, to retrieve the number of messages that have appeared in the last 15 minutes, the query looks like:

select count(*) as quantity, direction, senderName, receiverName, state, docTypeName 
from Messages15mWindow 
group by direction, senderName, receiverName, state, docTypeName

I found the Esper EPL syntax to be very easy to use and very familiar if you have used SQL before.
The queries listed above are registered with the Esper engine and when new events arrive in the system, Esper will notify listeners that new results are waiting to be processed.  In my application, I used a reverse-ajax library named Direct Web Remoting (DWR) to broadcast the results to a web page.  Here's an example:

Configuration Management Database (CMDB)

On many software development or implementation projects there is a need to track important work products, components, and their relationships.  Many mid-size companies use Microsoft SharePoint for this, but SharePoint has some issues with data integration and usability.

I've been using an open-source tool named that CMDBuild that I highly recommend.  You can read more about it and get the software from http://www.cmdbuild.org

It is very simple to setup new data structures for the important stuff you want to track and define relationships.  CMDBuild also has great support for developing custom reports using Jasper Reports and support for workflow management.  It also includes a SOA interface for data integration with other systems as well as an import/export utility.

CMDBuild uses a PostgresSQL database to store all data and history of changes so you can always work at the database level for advanced functionality if it is not supported from the CMDBuild web application.