Preface

A few years ago I was working on a team of consultants embedded in an organization (that shall remain unnamed). Our job was to create a system that would help increase a key source of revenue. This organization’s IT department had many problems: political, technical, organizational, and financial. As consultants, we, naturally, wanted to overhaul everything immediately to solve these problems, but the reality of consulting is that we had to take very slow, very small steps toward the goal. In the meantime, we had to work around the technical and organizational problems in order to help solve the financial ones, and that’s how I first learned about aspect-oriented programming (AOP).

We were creating a website for the public to submit registration information and pay fees. One of the constraints we faced when writing this system was the enterprise database. We had to access the enterprise data via an unreliable and error-prone service that was meant to act as this organization’s SOA (service-oriented architecture). There were some good ideas in this service, but the implementation was poor: sometimes as many as half the requests to this system would result in an exception, seemingly at random. After considerable testing and tinkering, we discovered that simply retrying the identical request once or twice would result in a successful request. Because of this, we didn’t want to use this buggy, unproven SOA service, but at that point we didn’t have a choice.