David S. Read

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. 

(more…)

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. 

(more…)