UML is a well-established notation for the design of object-oriented applications. In component detailed design meetings people are comfortable describing a design and articulating issues using UML.  This is not the case in integration projects. I go in the meetings to review an integration solution and invariably the discussion is based on a Power Point presentation with diagrams that include very basic, ad-hoc notations. The picture on the right is an example; the diagram mixes the component model with the deployment model, using ad-hoc notations for the components and execution environments.

Why is that? Why UML is not used more often in integration projects?

(Continue reading …)

From time to time I read about an interesting Java project and would like to try it.  For example Apache Jackrabbit, a library implementing JSR 170 (Java Content Repository). But setting up the my Java environment to run the examples is a hassle because of the many libraries required. Over time I got better at starting new projects: I have project snapshots that contain all the Eclipse and Ant artifacts for a simple application with proper JUnit tests and logging. Still, downloading all required libraries in the proper directories and updating Ant and Eclipse configuration is a drag. There must be a better way to do it other than downloading manually libraries from various sites. In this context I decided to try  Apache Ivy with the recently released version 2.0.0.

(Continue reading …)

Over the years I built a number of tools that can be used for the synchronization of reference data. They are now available in a toolkit:

• XML schemas for events that are generated when an entity is changes (added, modified or deleted);
• tools to synchronize two systems based on: SQL, flat-file and XML data source/targets)
• instrumentation of existing applications to generate events when data changes:
  • event tables populated by the application on a change
  • web-service invocation
• pre-defined auditing and logging capabilities for data synchronization. User interface to access the audit/log.

(Continue reading …)

A few years ago I worked for a company that just created a new IT team for "integration." One member of the team was the "solution architect." There was no formal definition of that role but there was an informal understanding that the person will be responsible to ensure that the system works end-to-end. Since then, the role has become more common and there are more or less formal definitions many of which are very generic and, as a result, they loose any practical meaning. Recently, having the task of training people for the Solution Architect role, I tried again to explain what Solution Architects do and how they do it.

(Continue reading …)