Component-Level versus Class-Level

(Ref Id: 1406664013)

Think Packages Not Classes

For DIY LIMS deploying individual classes by their lonesome is not enough. The best way to think about this is electronics. In electronics releasing a particular class is the equivalent of releasing an electronic component like a capacitor. The only people who really know how to use a capacitor are individuals well versed in building electronic circuits. The more causal user will want higher-level components that can be plugged into component-level circuitry. They would want something more like a very small programmable component camera which internally might use a capacitor for the flash module. Such a module satisfies both the casual electronics enthusiast as well as the expert provided both the external interface and the internals are all made available.

These higher level components have to agree on various things. In the case of electronics these might include how much power will be coming in from the board, connections, where to mount (dimensions) on the board surface, etc. In DIY LIMS these agreements are part of the specifications that dictate what the component is and what it does. They would include what kind of data is passed in, what the individual data types might be, what comes out the other end as output, and more.

Component-Level is Not New

The funny thing is that we have actually been building component architectures like this all along in instrument interfaces. When confronted with a wide variety of laboratory equipment developers have often built component-type systems with software modules that act like instrument drivers to handle the back and forth communication with the instruments. An instrument thus connected to the LIMS can be 'virtualized' in this manner for testing by simply sending various types of data to the LIMS from a software component instead of a live instrument. In this case two pieces of software are communicating and the LIMS will not be aware that no real instrument exists.

It is in this fashion that component-level architectures are born. The only difference here is that in a DIY LIMS scenario all parts of the LIMS -- from logging in samples to disposition to billing customers -- everything should exist in these small, encapsulated components that communicate with the outside world using accepted communication protocols and specifications. Although this is fairly easy to envision it takes quite a few iterations to make these components a practical reality. Here are the common problems:

1) The Language Problem

Component A and Component B are written in different languages. Their data types are not similar enough to easily interoperate. Specifications are adopted that define the data itself and the protocols for data transfer but it means that marshaling data across some medium and packaging/unpackaging/parsing it in various places must be employed. Every time that happens there is a performance penalty.

There is currently a lot of work around this area, much of it started with XML-RPC style applications. That gradually morphed into the colossal SOAP specifications and similar verbose, slow, and cumbersome interoperability toolsets. Much of that excitement has died down in recent years however with an interesting pairing of JSON and RESTful web architectures moving to the forefront (at least with regard to Internet applications). With JSON it doesn't matter what your application is written in -- Java, C++, Python, Perl, Visual Basic, C# -- only that it is able to parse JSON. What it communicates back and forth, the data, must be accompanied by a way to make that data intelligible. This is why one needs the RESTful API. If one likens it to verbal communication the data would be the words and the protocol that defines how the words should be strung together is the communication protocol.

As you can see, solutions to the language problem already exist are in production-level use outside of the LIMS space. They simply need to be understood, adopted, and perfected for DIY LIMS use.

2) The Documentation Problem

Existing nomenclatures describing object oriented (OO) models center around software architectures and are therefore generally not suitable for higher-level end users. In short, the more casual component-level builder is going to be as turned off by a stack of OO diagrams as the electronics novice would be when looking at a circuit diagram. This does not mean that such diagrams should not be produced. It does mean that something higher level must precede these that is specifically geared toward mating components together into a working system.

This problem is compounded in LIMS because two different software components targeting two different areas of science are not going to look very much like one another. A solution to the problem is not to try and make the documentation between disparate components look similar but rather to make a component's documentation synchronize with its predecessors and the components it interoperates with.

For example, SQC module from Company X and another module from Company Y apply only minimal standards to their module documentation -- they'll both be in PDF format with a similar header, version number, publication date, some protocol version information, etc. That's it. Everything else can and should be different unless they interoperate in some way. If Company Y however decides that Company X's GUI creates better graphs and would like to use it then Y's documentation should then change to become more like the X's component documentation.

Over time everyone's documentation will eventually start to look similar under this paradigm.

3) Missing Kernel Problem

Finally, a main problem in the DIY LIMS space is the lack of a central 'kernel.' If everything is a module there still needs to be something at the center that validates whether a module is properly registered, etc. Linus Torvalds, the creator of the Linux kernel, gets lots of credit for essentially producing a working kernel before the GNU Hurd could be developed. Oddly enough DIY LIMS is in the same boat that GNU found itself in back then with a wealth of components lying around but needing the core to essentially get our universe spinning.

Go Back

Citation: Component-Level versus Class-Level. (2014). Retrieved Sat Jul 22 04:45:24 2017, from;iid=readMore;go=1406664013