Who holds the keys to the Kingdom

During the years I worked as a Web application developer, it seemed like every application had its own authentication mechanism. An application developer is thinking in terms of the domain model for their application whether it be eCommerce, Systems management, photography, or weblogs. Identity Management is a cross cutting concern, and it is hard to get right. Why, then, do so many applications have “user” tables in their databases?
Continue reading

Wizard Woodcarving

After reading The Hobbit to my sons, my younger guy requested his favorite character. Quite pleased with how this grey pilgrim turned out.

Presentation on Keystone Deepdive and Folsom


There is not a lot of text: I tend to keep my presentations as a visual mnemonic for the topics being discussed.

Let me know if you want to steal any of the images I created. I have them all as SVG, and the UML diagrams came out of ArgoUML.

Most of the Creative Commons images were found on DeviantArt.com, attributions at the end.

Cloud Narrative

Identity Management (IdM) needs change as an organization grows in size. For an example, I’ll describe a fictional company, and take it from the smallest to largest stages. While, to some degree, the industry of this firm really doesn’t matter, I am going to use a small import business started by a single individual and scale it up to a multinational corporation. As the organization grows in size, the technical needs will drive the scope and scale of the identity management solutions required.
(This is my writing Cross posted from the FreeIPA wiki)

Continue reading

WebUI diagrams

I gave a presentation to some of the other teams at Red Hat about our approach on the WebUI.  Here are a couple of the graphics from the presentation.

This is the  “class” diagram for our UI toolkit.  It doesn’t show everything.  Instead it is intended to orient you to the most important aspects of the toolkit.

WebUI core-classes

WebUI core-classes

Click to see the whole diagram.  The top “swimlane” is the abstractions we provide.  The middle is the classes you’ll want to use when actually designing an application.  The bottom shows the command objects:  there are many instances of these, but with all pretty much the same behavior.  Calling this a class diagram is a stretch, as there are not really classes per-se in Javascript, but out programming approach pretty well mimics what Java or C++ does in overloading virtual functions.  Hence, thinking of them as classes is not a bad idea.


The second is an old-school flow chart.  The Angled boxes indicate IO, the square boxes are browser side operations.

The load of the initial Javascript files is not strictly serial.  It is possible that they overlap, and thus that section is shown happening in parallel.

The bottom of the diagram is pretty much an endless loop.   The yellow box represents the waiting state of the application:  from there you can see the four types of events that change the state of the application.

Technology Overload

Here is the current list of technologies on my horizon, not all of which I am completely clueless:

  • JBossAS5
  • OSGi
  • Qpid/AMQP
  • JSF
  • Facelets
  • Seam
  • Git
  • Jopr/RHQ
  • Maven
  • EJB3/Hibernate
  • Portlets
  • Struts and Tiles…did this before but it has been a few years.
  • Jepp
  • JNA/JNAerator

Of course, there are also my completely unrelated side projects cpp-resolver and the bproc work, both of which go in completely differnt directions.    My brain hurts…but it is a good kind of hurt.  And yet, strangely, in my brain these all fit together into a single consistent whole.

Dependency Collectors

Certain portions of an application function as a registration point, whether they are in the native language of the project or a configuration file read in. These files provide a valuable resource to the code spelunker. For instance, when starting to understand a Java web archive, the standard directory structure with WEB-INF/web.xml provides a very valuable starting point. Just as reading C Code you can start with main. The dependency Collections often are an xml file, like struts-config.xml, or the Startup portion of a Servlet.

The concept in Inversion of Control is that you separate the creation policy of the object from from the object itself, such that the two can be varied independently. Often, a project that otherwise does a decent job of cutting dependencies via IofC will build a dependency collector as a way to register all of the factories for the components. The xml files that Spring uses to define all of the control functions are dependency collectors just as surely as a C++ file with an endless Init function that calls “registerFactory” for each component in the inventory.

As you might be able to tell from my tone, I respect the usefulness of the dependency collector, but still feel that there is a mistake in design here. In C++, you can specify a chunk of code guaranteed to run before main that will initialize your factories, so the language provides support for IofC. In Java, classes can have static blocks, but this code only get executed if the class file is somehow referenced, which means this is not a suitable mechanism for registering factories. The common approach of using XML and Introspection for factory registration violates the principle of not postponing until runtime that which should be done at compile/link time.

So I give myself two goals. 1) To find a suitable Java based mechanism for registering factories and 2) to provide a method to compensate for the lack of orientation that a dependency collector provides.