David S. Read

I was teaching a class last week that introduced the attendees to a BPM tool. Since this particular BPM environment leverages the use of OO paradigms, basing the organization of its rules and workflow on classes, it is central to the tool’s operation to have an understanding of Object Oriented Design (OOD). When I teach this course I always spend a day covering OO terminology and concepts. This gives the class a common basis to proceed as we learn how to navigate, design, build and test within the BPM tool.

At one point during the week we were discussing an example of some code within the BPM tool that included a variable whose declaration (type) was an interface and whose definition, obviously, was a class. Although not key to the example, I pointed out the use of the interface declaration as a reminder regarding good practices, noting that developers should always “program to the interface”.

I continued on but a student’s raised hand caught my eye. The individual asked me to repeat and elaborate on what I had mentioned. Although we had spent a day discussing OOD, it occurred to me that I may not have used that expression before. Even though we had discussed interfaces, heterogeneous collections, Liskov’s Substitution Principle, and so forth, apparently I had not effectively stressed the relationship to using interfaces as data types in order to decouple our code from implementation.

As we discussed the value of using interfaces as our data types the students caught on and were able to describe the advantages of this “rule”. Certainly Spring developers are familiar with the concept since Inversion of Control (IoC) is specifically used to decouple our code from other implementations.

Developers should favor the use of interfaces for data types rather than the implementation type even if it is not clear that another implementation will ever be leveraged or created. The practice of coding to interfaces will aid in consistently decoupling modules. The approach simplifies refactoring and allows for much more flexibility in future releases.

(more…)

When applied to software, the principle of Security in Depth helps us mitigate the fact that we will always produce flawed applications. In this case the flaws of which I am writing relate to the security of the application. Although we should always strive to create secure code, the fact is that exploitable vulnerabilities will eventually be discovered in our programs.

Certainly the odds of an exploit being discovered are based on the complexity of the application, the value of the data accessible through the exploited application and the quality of the security-related focus given to the application during the SDLC. Note that the value of the data accessible through the exploited application is not necessarily limited to what the application is supposed to access, but rather what is exposed by the exploit.

Since we know that we cannot produce “perfect” code, we need to plan for minimizing the impact of a successful exploit. In other words, we strive to make the value of the data accessible through the exploited application no greater than the value of the data the application is intended to access by an authenticated and authorized user. Security in Depth is a powerful approach to meeting this objective.

Security in Depth requires that each tier in our application enforce the same restrictions on information flow as the other tiers. For example, if our front-end is restricting input to a maximum length and escaping HTML and JavaScript strings, then the object and the persistence layers should do likewise. If a user is restricted to accessing certain data as part of the application’s operation, the database management software should enforce the same limitations.

(more…)

Ever since I first heard the Benedictus from Karl Jenkins‘ “The Armed Man: A Mass for Peace” I knew that I would enjoy having the opportunity to share it with my church family. I also thought that it would need more than just me playing a piano accompaniment. Luckily my children and two of their friends were willing to put in the effort to learn an arrangement of the piece that I put together.

The Benedictus comes late in Jenkins’ Mass and provides a respite from the devastation, sadness and grief that is brought to life during the preceding movements. It begins in a beautifully serene way, erupts with a wonderful climax on the words “Hosanna in excelsis” (Hosanna in the highest) and then returns to its original calm and peaceful spirit.

Although scored for strings, with the brass appearing during the “Hosanna”, I think that the use of brass throughout worked well. During our early rehearsals the trumpets used mutes for the opening phrases, but we decided that the tone was not conducive to the mood of the piece.

A video of the performance has been uploaded to YouTube so that family and friends may share in the experience. I thank all four of these hard-working students for giving up some of their summer recess time to work on this. I know that the congregation and I truly appreciate each of them sharing his or her talents. Also, a special thank you to my wife, Lisa, for recording the service so that this could be shared.

The video is available at: http://www.youtube.com/watch?v=1_KdZfnyizE

My family has been using Chandler for about a year. Chandler, in case you haven’t heard, is a “Note-to-Self Organizer“. I am not convinced that this tagline does the application justice. It provides a task list, note management and calendar that are easily shared with others through server software known as the Chandler Hub. Further, the tasks, notes and calendar entries are easily reclassified.

Chandler provides two interfaces: 1) a rich client that is installed on a PC and 2) a web interface used to interact with the information via a user’s browser. The Hub also provides a web-based service that is used by the desktop application to share information among users.

The Chandler Hub is available for download, along with the Chandler Desktop, so groups can run their own Chandler service. For those not interested in running the server, the Chandler Project provides a free Chandler Hub instance.

Chandler’s interface is great for sharing information, and in my case schedules. Multiple calendars are easily overlaid. Further, the sharing of a calendar is done by sending people a URL that allows for either read-only or read-write access to the data.

(more…)

I was recently working on a Java program whose only interactions were through web services. The application accepted web service requests and, as part of its processing, made other web service requests to other services. I leveraged a couple of frameworks to simplify the web service interactions, namely Spring and Castor. Spring-WS provided the web service endpoint support and Castor did all my marshalling and unmarshalling.

At this point you may be asking what this has to do with Thread Safety. I am glad you asked. It could be that my title is misleading, but I believe the next paragraph will help resolve any apparent disconnect.

As part of integrating the marshalling and unmarshalling process involved in the web service, I needed to create JavaBeans™, which provide the objects housing the program’s data. However, since a framework was handling the marshalling and unmarshalling process, I never used the new keyword. Nor did I call the bean’s accessors or mutators directly when reading or writing the XML. Instead, the framework decided the order of get and set calls, and more to my point, I wondered whether the framework was free to multithread the interactions.

The reason for my concern was that one of my beans had a dependency between two properties. If one was set to a certain value, the other was impacted. The framework controlled the order of calls, so I had to deal with either being set first. Handling order was not a big issue, but what if their mutators were called simultaneously?

This led me to look more closely at the JavaBean™ specification. I was interested in whether it mentions anything about multi-threaded access. If it stated that beans should not expect multi-threaded access by default, then I was in good shape. Otherwise, the framework might have me at a disadvantage.

(more…)

For all the publicity surrounding software vulnerabilities and successful exploits, we as an industry don’t seem to be rigorously incorporating effective approaches for making software more secure. Many resources are available to educate people involved in software creation regarding security. Further, tools and libraries exist which simplify the redundant aspects of secure software composition.

There are also well-known concepts that have been applied to physical and network security for many years which are equally effective when designing and implementing software. Concepts such as Security in Depth, Least Privilege, Segregation of Duties and Audit Trails serve us well when applied to programming. Tools such as the OWASP and Apache libraries simplify the process of sanitizing and normalizing data received from users and external systems. Automated inspection tools, static and dynamic, help us to identify and remove vulnerabilities in our implementations.

Those who architect, design, implement and test software must understand the typical risks created by different aspects of an application’s architecture in order to leverage appropriate techniques to reduce the likelihood of a vulnerability being released. Further, we should assume vulnerabilities will be found and exploited. Our designs must include features to limit the extent of damage such an exploit would create.

In this category’s posts I will concentrate on the classifications of vulnerabilities and effective techniques that we should apply when creating software. Hopefully this will help to raise awareness surrounding security-centric due diligence that is expected from those of us who participate in the process of authoring software.

Another Odyssey of the Mind (OotM) year has finished for my children. For the 2007-2008 long term problem their team, representing O’Rourke Middle School, chose “The Eccentrics.” They worked through the late fall, winter and into spring getting their script, costumes and set prepared.

I think this was their best script yet (having been involved in 3 prior years). The story had a nice flow, solid dialog and humor throughout. The team also had positive dynamics with much less in-fighting and interpersonal frustration than in prior years.

They won their divisional competition and proceeded onto the state competition where they achieved 4th place! This was their best finish and a clear testament to their hard work. They are already talking about getting geared up for the 2008-2009 problem. I guess I shouldn’t get used to having all the cardboard out of the house!

For those interested, their performances are on YouTube:

• Regional: http://www.youtube.com/watch?v=hrUaEuMdSyE
• State: http://www.youtube.com/watch?v=jvXZryszO6A

You’ve probably heard an expression similar to, “If builders built buildings the way programmers wrote programs, the first woodpecker that came along would destroy civilization.” At face value it is amusing and seems in some ways prophetic.

After all most computer users have experienced countless software failures that led to lost data, reduced productivity and basic frustration. If our buildings’ infrastructures failed as often we wouldn’t dare enter them. The earlier quote makes a not-so-subtle statement that programmers do not do as good a job when constructing software as their building builder brethren do when building buildings.

However, the premise of the quote, and others like it, is fatally flawed. Statements of this nature assume that building a physical structure is like creating software. I disagree strongly. In fact I think the two are as similar as bridge construction and music composition, i.e. not very.

In this category’s posts I intend to flesh out my thoughts on the process of software creation, or composition as I like to call it.