Do you know how often your message delivery fails? Do you get an error when it does? If not, you could be putting your systems at risk. One of the key, often-overlooked issues in systems integration is how messages between systems are passed. Even more important is whether or not deliveries are guaranteed. More often than not, we have discovered that they aren’t. When a message fails to get passed between System A and System B, whether it’s not received or left unsent, there needs to be a robust framework in place to track the event and assess both the specific problem as well as the root cause. This isn’t just a technical issue. Inaction can result in costly support problems down the line. Aside from the practical needs of keeping an integration running, there can be security breaches or even legal concerns that are just as problematic.
Why Non-Repudiation Is Essential
In our overview of systems integration best practices, we used the example of an educational assessment platform integrated with a learning management system (LMS). If the integration doesn’t guarantee message delivery, a student could complete an assessment without the grade ever being passed to the LMS and entered into the gradebook. Even worse, they likely won’t know until their final grade is determined when they get a glaring ‘C’ on their transcript for the missing assessment take. If the system is well architected, documented, and a sufficient level of system logging is occurring, the application support team may be able to recover the grade for the student. However, the flurry of support calls that are created for the recovery of the grade is not only a substantial hassle for those involved, but also a potentially costly exercise with no assurance of success. What’s more is that due to various internal security policies support teams are often not afforded access to the application or systems logs, making the job of piecing together what has happened substantively more difficult. If the system isn’t as robust, imagine how angry and disappointed the student would be to have their grade ruined by a system error! Ultimately, that turns into a time-consuming and expensive problem for the school’s administration — and possibly even their legal team.
Defining Non-Repudiation
Non-repudiation is another way of saying “unable to deny.” It’s a term borrowed from the legal field that has come to define how system integrators ensure that messages are authentic and delivered successfully. In this context, it essentially just means “guaranteed message delivery.” Just like a process server hands out subpoenas after identifying the person in question, system integrations need to certify that messages get sent, received, and logged. There are a few ways of achieving non-repudiation:
Message brokers and queueing systems like WebSphere Message Broker and Rabbit MQ will spool messages, verify delivery and retry until successful.
Persistent data storage on all systems or a centralized hub means that even when a message doesn’t make it from System A to System B, it’s stored on System A anyway. Alternatively, it might persist on System C, which acts as a third-party gateway.
Local storage until at least one receiver acknowledges delivery is another, less data intensive way to accomplish this. This is accomplished by essentially spooling the message on the first system until the second verifies receipt. This is likely the most common approach to guaranteed message delivery. However, if not implemented with the proper safeguards and logging approaches it can be no solution at all.
Error reporting to users, system administrators or support personnel makes sure delivery failures are known and can be addressed manually. This simple approach raises red flags that can help address not only specific errors, but also the root cause. And most importantly, allow for proactive resolution to issues; getting the grade fixed before the student calls support to complain.
Enterprise service bus (ESB) architectures typically include a message queue built into the service bus. ESBs are ideal for integrating numerous systems. It’s the most robust method for reliable integration, but it’s also one of the most costly.
Store and forward is a telecom technique where information is sent to an intermediate system that verifies the integrity of the message. The system passes it along to the final destination at a later time. Store and forward is similar to a message broker located on a 3rd-party system, except that real-time integration is inherently impossible. Store and forward is one of the best solutions for integrations that are expected to have intermittent connectivity, as in the case of mobile learning, for example.
If your organization is considering the integration of any web applications, back-end systems or services, we strongly suggest you give one of the approaches above consideration. Implementing a method of non-repudiation after your integration is completed will be far more costly in the long run.