David S. Read

Another International Business Rules Forum has run its course.  It was great to see the mainstream acceptance of leveraging Business Rule Engines (BRE) and Service Oriented Architectures (SOA) to facilitate both business and integration agility.  Paul Evans and I presented on that topic at last year’s Forum.  This year it was clear that vendors and implementers are leveraging the approach broadly.

I met many great people and learned a lot about how businesses are succeeding with Business Process Management (BPM) tools to automate processes.  This year there was a lot of focus on expanding to focus on data and rules.  This relates to the discussions we have regarding the semantic web.  We need to leverage semantics throughout our systems, starting with the data.  Without appropriate semantic underpinnings the promise of automated service discovery and self-describing environments cannot be attained.

I thoroughly enjoyed having an opportunity to hear Dave McComb describe the value of semantics as we pursue the use of business rule environments.  His deep knowledge of the semantic landscape and his energy while discussing it certainly inspires one to learn more about the topic.  Thanks to him I continue to evolve my thinking around the creation and structuring of data dictionaries and vocabularies when documenting and implementing business rules. Read the rest of this entry »

I am looking forward to this year’s Business Rules Forum (BRF - http://www.businessrulesforum.com/).  This is the 11th year this international gathering has occurred.   It is interesting to listen to the real-world experiences that people are having as they leverage business process gathering and execution environments.

Once again I have been given the opportunity to co-present a session.  This year Mike Strianese and I will be discussing the importance of security when leveraging web services.  The Service Oriented Architecture (SOA) approach has gained a lot of traction in rule engine and workflow environments.  With the accelerated pace of integration and application deployments comes an increased risk of vulnerabilities and exploits.

Beyond the informative sessions, the BRF provides a great showcase to see and experience a broad range of tools and services available for documenting, testing, integrating and deploying rule-based solutions.  This is an efficient way to gain a lot of insight into the operation of the diverse offerings.

I am a strong advocate for leveraging rule and workflow engines to accelerate application development.  In the same way relational databases free us from creating a lot of code to manipulate data in files, these environments simplify certain aspects of enterprise business system development.  It has become rare to encounter a financial or healthcare-related enterprise that does not leverage at least one of these tools.

If you happen to be at the BRF next week I invite you to stop by our session (Security of Services, Thursday at 9:05 am - http://www.businessrulesforum.com/abstracts.php?id=350).  Feel free to introduce yourself afterwards as well! 

As developers become more comfortable with their favorite syntax(es) they tend to favor terseness in coding.  This isn’t something limited to those writing programs.  The fact is, as people become more comfortable with a situation they look for ways to shorten interactions and bypass redundancies.

For example, as we become more comfortable with cooking, we may begin to approximate measurements.  We’ve measured a teaspoon of salt a hundred times.  We know that if we go slightly over or under it won’t ruin the recipe, so we just cup our hand and pour until it looks right.  At the gas pump I never press the “Pay by credit card” button.  Instead I insert my card and the machine recognizes what I am doing.  No need for the extra step. 

When communicating we shorten common phrases.  We may create compound words, contractions, or acronyms.  The goal is to reduce the overhead and increase entropy.  That is, we want each word we utter, or command we type, to do more for us.  When working with software we often refer to “power users” who know all the shortcuts to quickly access the program’s features.

Those who are new to the situation will need the more verbose and redundant approach.  Just because power users know how to bypass an application’s menus, a novice will still need the menus to help him or her learn the software. 

In a similar light, experienced developers need to consider their junior brethren as programs are being created.  At a basic level the issue is that the software may be maintained by others and those developers may not be as experienced as the original authors. 

One high-risk programmatic shortening concerns side-effects in decisions. 

Read the rest of this entry »

Full Disclosure: The title of this post quotes a phrase I have heard countless times from Java programmers.  The statement itself is misleading.  The Vector class cannot guarantee thread safety for an application.  Let me tell you why…

When considering thread safety we really have to consider the context under which we need thread-safe operations.  In the Java world we tend to focus on synchronizing methods as a quick way to achieve a thread-safe design and the Vector class is the poster child for this approach.  In fact I often hear that using a Vector is better than ArrayList when dealing with multi-threaded applications.

By synchronizing its methods a Vector does protect itself from unpredictable changes to its internal state.  In other words, the Vector is guaranteed to be internally consistent.  For instance, if two threads attempt to do an insert at position 3 at the same time, one will be inserted first and the other will then be inserted (moving the previously inserted value to position 4 in this case).  The synchronized methods prevented any odd collision where one of the values might be lost.

However this internal protection does nothing to protect our external view of the Vector.  In the face of multiple threads updating the Vector there is no advantage of the Vector over an unsynchronized class like ArrayList.  Why?  It comes down to what actually needs to be locked in support of creating an atomic operation.

The synchronized methods in Vector imply that the atomic operation is the individual Vector method.  However, in a multithreaded application the definition of an atomic operation probably has a larger scope.  For instance, if the Vector is helping to maintain a collection of calculation results, the atomic operation might be the entire cycle of reading the value from the Vector, calculating a new value and replacing the value in the Vector.

In order to understand how this would work we need to understand a mutex.  The term mutex comes from “Mutual Exclusion” and signifies that some portion of our code needs mutually exclusive access to some object(s).  In the case of synchronized (non-static) methods the mutex is the object itself.  Therefore, all those synchronized methods in the Vector class require that they have an exclusive lock on the Vector instance. 

Read the rest of this entry »

Blue Slate Solutions has an annual family day and for the past couple of years it has been held at our local Six Flags (The Great Escape) in Lake George, NY.  This year it was held on September 14.  The weather looked suspicious in the morning but brightened up and cooperated throughout the afternoon and evening.

One ride that my family has considered on previous visits is The SkyCoaster.  If you are not familiar with the ride you can read about it at skycoaster.com.  The version at The Great Escape is 175 feet tall.

This year we went beyond the consideration stage and took flight!  We had a couple of coupons that allowed us to purchase two groups of three for one-third off.  Lisa did not think that she wanted to ride it so the plan was for Sarah and me to ride a couple of times with others that had made the trek.

Lisa took a video of our first ride.  She also decided that it looked like fun, so she took my place on the second ride.  Lisa tends to scream on rides, and this one was no exception!  I took over the video responsibilities and watched with Michael and a friend of his.  The two boys have decided that they want to give it a try next year.

All of us who took the plunge highly recommend this attraction.  Videos of our two rides are on YouTube:

http://www.youtube.com/watch?v=hVK869xUPgE
http://www.youtube.com/watch?v=xu0IGxD0uYc

Often when I am discussing programming practices with developers they are quick to mention their use of unit testing.  It is a badge of honor that they wear and rightly so.  “I test my code.  I care about the quality of my work!”  Of course unit testing means that the test is exercising a small “unit” of code, typically a method or function.  Does the term tell us anything else?  Are all unit tests equivalent?

The tools and techniques developers use for unit tests differ, such as using frameworks versus more homegrown approaches, but many developers stress the importance of unit testing. However, saying that one subscribes to the use of unit tests is like saying that someone uses a motorized vehicle.  There is a lot of detail missing.

If you explore someone’s motorized vehicle it might turn out to be a motorcycle, car, train, boat, etc.  What is meant by motorized vehicle can vary widely making the term ineffective when trying to determine the vehicle’s ability to carry or tow something.  In the same fashion, if you dive more deeply into each person’s definition of unit tests, it is clear that one developer’s unit testing is not the same as another’s.

Here I’ll explore some details surrounding unit testing.  I’ll start off with my two invariants: predefined results and automation.

A test is less effective if its result is not defined before the test is run.  Each test must be defined with its input and result documented.  This means that no interpretation on the part of the tester can be involved.  The reason for this is simple; people can convince themselves that an answer is correct when they see it.  If a tester enters a test input without a definition of the correct answer, he or she may be willing to accept the result as correct.  This is human nature; to accept information that we see presented.

A logical corollary is that unit tests should be automated.  In order to guarantee that the tester is not interpreting any results, let the computer do the check.  The result is a pass or fail.  No murky gray area where the tester tries to understand whether it is correct.  The automation also leads to the creation of a regression test suite that will grow with the code.  Finally, if the tests are automated, other tools can help us assess the completeness of the tests.

Beyond these two statements there are decisions that developers need to make about the types of unit tests that will be created.  These decisions impact the complexity of the tests that must be written as well as the number of tests required. Read the rest of this entry »

My family just returned from a week in York Beach, Maine.  We love the area and typically head up there each year at some point.  A few highlights included unexpected treasure while hunting for sand dollars, a great musical in Ogunquit and comfortable swimming conditions.

Sarah and I walked the beach most days and typically kept our eyes open for interesting shells and sand dollars.  Low tide is best for such finds and we adjusted our schedule to match the tides.  On one of the days were were walking along Long Sands beach and encountered an area thick with seaweed. 

Sarah was not enamored with the slimy sludge as it wrapped around her legs with each wave.  She complained about how “gross” the stuff was and wanted to move out of the water to avoid further encounters.  However, she spotted something green trapped in the plants and realized it was money.

Suddenly she was willing to walk through, reach into and touch the seaweed!  Her reward was a ten dollar bill.  For the remainder of the week she stopped complaining when we wandered through seaweed. Read the rest of this entry »

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.

Read the rest of this entry »

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.

Read the rest of this entry »

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