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!
Final words:
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.
Other people's views
Working in an environment that is slowly transitioning from AVS to JVS and OC (Java). One very important consideration is the cost of conversion. With in-house developed automated tools we can convert a 500 line AVS script as is into a work JVS script in a day (ready to test). The translated JVS script has a very high probability of working cleanly and a low probability of inadvertently changing any business logic, especially the edge cases. Whereas when our scripts are converted from AVS to OC a 500 lines will more likely take two weeks or more of effort to be ready to test, as the conversion is really a complete re-write. The OC testing inevitably goes around the wash a few times too.
In my experience, the biggest bottle neck to the conversions of AVS scripts is to be found in the testing bandwidth. Given that OC conversions take considerably longer to write and test than JVS conversions, our pragmatic rule of thumb is AVS conversions are to JVS.
From a business perspective there is no perceivable difference from an AVS to JVS or OC conversion, not even a liminal one. The benefits are derived from technological positioning and the productivity increase experienced by in house developers whom gain access to modern day development tools, such as the Eclipse IDE., and OO development languages such as .net or Java.
OC gives developers the greatest leverage with its high level abstractions, hence almost all our new development is carried out in OC (Java). OC (Java) has one distinct advantage over OC (.net) for and that is when there is a deficiency in the OC API. In OC (Java) one can still make direct calls to the definitive JVS API. Without the ability to call JVS API one can land in hot water with earlier Findur/Endur versions. As OC matures with future Openlink releases the balance of API provision will eventually change in OC favour but until then one has to make carful choices between the options of JVS and OC.