Strict Unit Tests for Public Data Contracts

Suppose we have the following code:
public class Thinger {<br /> private static final RESULT = "Joy";<br /><br /> public String doThing() {<br /> return RESULT;<br /> }<br />}
When testing such a code, it is tempting to modify the visibility of RESULT to package protected in order to write tests that share the constant value:
<br />@Test<br />public void doThingWorks() {<br /> assertEquals(Thinger.RESULT, thinger.doThing());<br />}
After all, reuse is good, right?

Well, in this case, I think that reusing this constant is not a good idea if your API is a public one (or if this code gets exposed as a service, which is practically the same thing).

In fact, I advocate to write the test like this:
<br />@Test<br />public void doThingWorks() {<br /> assertEquals("Joy", thinger.doThing());<br />}
But why the duplication?

The catch with public APIs is that they create long lasting expectations in an uncontrolled number of users and systems. Consequently, stability should be their essential characteristic. Through interfaces, it is easy to provide an illusion of stability: as long as the API is backwards-compatible binary-wise (or operation-wise for services), it can change at will and life is peachy.

So what is so risky with the static field above?

Well, the fact of the matter is that the value returned by the doThing() method is also part of the contract. Indeed, beyond the object-oriented concept of interface, data is also part of the overall contract with a particular class (or service). So data should exhibit the same stability as the interface itself.

When sharing a constant in the unit test, it is possible to modify the data contract without noticing. Suppose I change the value of RESULT from "Joy" to "Happy". The first test will give me a green light, while the second will be red. And it is the latter that I am looking for: I want my unit tests to tell me that I have broken the data contract of my class.

Not its users...

Mule and the Home Service Bus

While following the discussions on Oasis Blue's SmartGrid Interest List, I noticed that smart device makers quickly reacted to the draft charter for the proposed OASIS Energy Market Information Exchange (eMIX) Technical Committee by stating that their capacity to implement full-fledged SOAP clients was limited. Looking at the bare-metal specifications of protocols like Zigbee, it is easy to understand that SOAP would be another board game.

Of course, when I heard about this need for protocol adaptation, my favorite quadruped quickly came to mind (I know, when you have a hammer...). So I came up speculating about this:

Yes, that is Mule ESB running on a Sheeva Plug. In fact, I should say Mule HSB, as in this case the platform would serve as a Home Service Bus.

What could be the role of such an HSB?

Protocol adaptation comes first to mind. Allowing all your home devices to interact together internally but also with the outside world with "higher order protocols", like SOAP or anything more RESTful. What would happen if your smart meter starts talking with your dryer?

Orchestration would be another benefit. Here I am not thinking in term of the classic and already solved home automation problem. Imagine orchestrating your home devices in order to satisfy some predefined power consumption patterns. What would happen if a BPEL engine was running your house?

Home rules application would be the ultimate benefit. By plugging a rules engine to Mule, one could define advanced scenarios when a house would automatically negotiate energy purchases and sales based on inference rules and facts (like: do you have an plug-in hybrid sleeping in your garage). What would happen if your house was smart enough to make money while you sleep?

I agree, this is a lot of speculation. But I reckon that a capable Home Service Bus will one day become a must in our habitations.

PS. Google just told me that Bert Boerland coined the Home Service Bus term. We must be up to something ;-)

Organic Distributed Systems

Migrating monolithic systems to distributed ones is probably one of the most exhilarating tasks in software development.

Monolithic systems, even if they engage in interconnected relationships, remain pretty much like silos (I like compare a network of monolithic systems to silos connected by monkey bridges). Reflecting on the work I have been doing in this domain for the past years, I came to realize how much an IT landscape of distributed systems ends up resembling a living organism.

Indeed, some proprieties of the organic world emerge in a system that evolves towards distribution.

Distributed systems are more resilient. Local issues in living organisms tend to remain local instead of endangering the whole system. This is achieved via redundancy, heterogeneity and a limited coupling between each part of an organism. Interestingly, the same applies to distributed software systems: if properly decoupled (interface-wise and time-wise), a particular system can be in pain without taking down the whole operation.

Distributed systems are harder to diagnose. Rare or complex diseases are uneasy to diagnose and often require many analysis to be performed. Distributed systems present the same challenge, complicating forensics tasks when something went haywire. Using tracing mechanisms, like correlation IDs, can simplify such diagnostics, the same way DNA-tracing can help figuring out the spread of a particular gene (or virus!).

Distributed systems can self-heal. Living organisms embark all sorts of self-healing mechanisms, from localized ones (cicatrization) to global ones (fever). Because each member of a distributed system focus on specific tasks and has reduced coupling to the rest, it has more freedom to perform recovery operations in isolation without needing the involvement of any other member. This said, it will still need an escalation mechanism in case the issue can not be treated locally.

There are surely other qualities distributed systems exhibit that make them look like living things. Do you think of any?