Joomla Slide Menu by DART Creations
Middleware Matters

Several projects that I have seen while supporting ORBexpress have implemented a fairly complex processing architecture and still easily met stringent performance requirements. One commonality among these successful projects is that they identified and addressed architectural risks early on in the process.

Lots of projects, influenced by the "waterfall" development model, don't try to run any of their pieces together until all or most of the pieces have been developed. In the ensuing integration nightmare, new requirements are discovered and design flaws are uncovered -- with no time left to deal with them. In particular, performance bottlenecks or unexpected error paths are discovered only at this late stage…or in the words of Homer Simpson, D’OH.

Unlike the sitcom character, you can avoid this experience. To help ensure a smooth development that meets their proposed schedule, smarter projects develop a "skeleton" of the system early in the project. These can have many forms, but generally include all of the major components present, as token "stubs", and exercise all of the major data flow paths with "dummy data". The closer this “skeleton” is to the production processing environment, the better, but compromises are often necessary. The target hardware may not be available, the target operating system may not be easy to test on, or the communications infrastructure may be missing.

CORBA can help in all of these situations. It offers a degree of transparency that allows different processing hardware, different operating systems, and different communications to be used in the initial architectural prototype. For example, many ORBexpress users prototype their system on a standalone Windows or Linux machine, and then gradually move each component to their actual target operating system. The location transparency of ORBexpress makes it easy for developers to do this.

Performance is another aspect that can be explored and verified with a prototype using ORBexpress. The initial prototype can validate that sufficient bandwidth exists in the infrastructure, that sufficient feedback is present to handle congestion, and that fan-in and fan-out points don't introduce excessive latency. As the implementation proceeds, stubs and dummy data can gradually be replaced by more complete data representations and realistic processing algorithms.

Finally, an architectural prototype gives you something to show the customer. Customers are much more assured by a lash-up that just "blinks the lights" than all the progress charts showing thousands of lines of code you have developed to date. Incremental progress can be demonstrated by blinking the lights in ever more sophisticated patterns.

It is important that projects port the prototype skeleton to the actual target as it becomes available, since the benefit of transparency may hide real issues in the architecture. For example, calls on a single system never fail due to unavailability of the called subsystem -- the caller would also have failed! Thus these error paths cannot be discovered or exercised after discovery.

Projects that start with a skeletal architectural prototype have the opportunity to explore performance, reliability, and platform-application integration issues at an early stage of the project before a significant part of the application is developed. If the "bones" are strong and well connected, the application will be more robust when it is "fleshed out".