By Daniel Bregler
Which of the two APIs is the right one for customizing Openlink?
As with all complex problems the answer is: “It depends!”
JVS and OC are designed for different purposes even though they have a high degree of overlap.
At the surface one may think, JVS was just a stepping stone away from Openlink’s legacy propriety scripting language AVS and that the more recent C#/Java .net OC interface is its successor. Yes, Open Components is very powerful far beyond JVS, but JVS is here to stay.
“With great power comes great responsibility”.
If JVS is your standard hand saw, then OC is a 2000 Watts circle saw. No responsible workshop owner would give these to their workers, unless they are well trained, the tools are serviced and everyone is aware of the safety procedures. In the simplicity of a hand saw lays also its strength. It is easier to use, faster for concise work items and still achieves excellent result from experienced hands.
Luckily we are only talking about software development, and not the risk of cutting off hand or fingers, but the point is that inefficient OC code can seriously destabilise your implementation.
OC is not the answer to a messed up code base, if anything it requires even more vigilant testing processes and discipline to standard design patterns than JVS already does! There are of course requirements where OC is inevitable, for example when binding to further 3rd party APIs like Tibco RV, using web services or even standalone applications. Mighty OC has its exclusive merits, but…
The end should always justify the means
If a solution is possible in JVS you should not jump on OC and think, it will be even better now! The JVS API is a tailored application and for the most part the entry point will be one execute method of an abstract class to interact with propriety objects. For this reason, it is reliable. Even the most rapid of prototyping has limited systematic risks. The limitation is actually ring-fencing unintended knock-on effects of your customisation.
Examples for how sensitive OC can be:
A custom bootstrapper in OC once used can never be re-released, but only updated. Its extension ID is hardcoded in the curve definitions. If deleted, a circular dependency prevents you from ever fixing it through the GUI. Without hacking it, the database is broken and must be restored from backup. Also pre-matured disposal of shared resources during multi-threading are common sticky points causing crashes. Be mindful right from the beginning when developing OC!
Openlink clients are not software houses and QA and design cohesiveness more often than not have to give way to pragmatic results under tight deadlines. OC requires careful design patterns, coding discipline and testing procedures which are naturally conflicting with this OC is very mighty but can be hazardous, with JVS clients are benefiting more directly from the safeguards a 3rd party vendor system offers.