Skip to main content Skip to footer

The importance of interoperability in .NET reporting

Interoperability of programming languages is important to their development and integration into end-user processes. Generating peak interoperability in .NET reporting is essential to its optimal functionality, but the diversity of programming languages can make this process a difficult one. Even basic software programming languages are riddled with complexity as deep feature sets and components become the norm. Even for skilled developers, a language that they have not paid as much attention to can be difficult to use, which can create problems when it comes time to develop applications and reporting tools for use in enterprise environments. The reality of report designer processes today is that the focus on the end user means that compatibility is a high priority on the development side.

ACM Queue contributor David Chisnall recently wrote about the difficulty of retaining cross-language interoperability. As virtual machines and other applications become more language-agnostic and more receptive to intercommunication between languages to drive functionality, nontrivial applications are no longer written in just one language. Domain-specific languages are found more frequently, while high-level languages dispense with interoperability in order to better represent their individual subset of algorithms.

"More general-purpose high-level languages such as Java sacrifice the ability to manipulate pointers directly in exchange for providing the programmer with a more abstract memory model," Chisnall wrote. "Specialized languages such as SQL make certain categories of algorithms impossible to implement but make common tasks within their domain possible to express in a few lines."

To cite a fairly common example, Chisnall wrote that Java and C++ integration is not usually easily accomplished, as it requires manual interfaces through a C intermediary. Interoperability between .NET languages can be accomplished with some code, demonstrated here on the Microsoft Developer Network, but in many cases these are workarounds that do not address the root problem.

Is it a question of semantics?
Another way to look at the problem is through the lens of whether it's a semantic issue or a deeper one. The idea that interoperability proposes, namely fostering communication between programming languages, are sound, but do traditional vocabularies still make sense? According to EDN contributor Larry Desjardin, the terms used to describe language interface may be in need of a revision. He wrote that compatibility and interoperability, as priority objectives in test systems, acquire a greater importance when it comes time to actually run a report designer in its designated environment. However, their ubiquity of use can make them fuzzier to define.

"[E]very time I hear a user ask, 'Is that compatible with X?' or 'Are those products interoperable?', I hesitate." Desjardin wrote. "The problem is that these are ambiguous terms, and mean different things to different people. I usually reply with a question, 'Without using those two terms, what is it you want?'"

In lieu of compatibility and interoperability, Desjardin proposed several terms that could offer a deeper understanding of how interfaces interact in .NET development environments. One is "coexistence," which indicates that the products in question can be combined on some level. Instead of the black and white question compatibility infers, coexistence means that at some degree, the two or more items being considered can interface successfully. This is important for test systems, as users can pick and choose the operating systems, software and hardware used in an environment with better knowledge of the level at which they can interface successfully.

Another term, "interchangeability," describes the degree to which one language or product could adequately replace another. A perfect interchange is unlikely, as variables such as measurement functions, form factor and size, and command sets can complicate a substitution. However, it can provide a more insightful perspective on language interfacing and help developers create programs that operate without some of the extraneous functions that could complicate interactivity.

MESCIUS inc.

comments powered by Disqus