Power Jython : Extend and Customize a Product using Jython: Part-1

Working for one of the Start ups, I came across a way to extend and customize the Product Functionality.

It was a very elegant way of doing it. Extremely neat and powerful.
The Product was used to manage the IT infrastructure and Software configurations.
The so called 'Product' was completely developed in Java, Jython et al. Yes, Jython was used in a very elegant manner for the end users , Professional services group and other vendors to provide a way for the product to be customized as per the end-user needs. Instead, technically speaking, we had a core product plus the customization features.The additional features were customized on top of the base functionality, where the product users could add and enhance the product functionality using Jython scripting.

TechNikes:

1. Core Product had to communicate with the extended and customized functionality using a standard API. This standard API was developed using Jython scripting. Technically, it is the Facade to the Extension Points. Facade typically like a 'Framework' is well managed and maintained by Facade developer. Each 'Extension Point' adds up and typically resolves in a complete customized product.

What is an Extension Point ?

2. A number of jython scripts executed to accomplish certain specific task. These scripts bundled together is an Extension Point. One can drop in as many Extension Points as possible. The core product picks up a particular 'Extension point' and executes these scripts. Jython provides a Java Interpreter which was embedded within the core product for the scripts to be executed and accomplish a task. So, an Extension Point in other words is a bundled jar of Jython scripts and XML files.

How did it work ?

3. Each Extension Point was developed and bundled as a jar file. The jar file had Jython scripts and a XML configuration file. This XML file provided information about the scripts ( meta data , isn't it ?).

The core product could pick up this bundled jar file , explode it and load the 'meta data' into the

core product. this way end-user of the product can make use of this meta data to execute the scripts. The core product would come to know about the 'Extension Point' through the 'script configuration XML file within the jar. The Core product would pick up the Jar file , read the XML file to get the knowledge of the scripts.

What is the content of the XML file ?
1. Name of the jython script.
2. Location.
3. Display Name of the script - that needs to be displayed within the scripts menu on the core product UI.

Isn't it powerful ?

Usage examples:

• Execute certain Policies. Policies that keep changing. Jython scripts can add value.
• Execute certain 'Rules'. Rules that can be customized.
• Execute any other Jython scripts to manage configuration data.
• Execute reports with additional jython functionality.
• Manage application configuration data.
• Provision files to different nodes (machines) from a single location using SSH or FTP
  
• Execute Unix commands or Shell scripts remotely using SSH.
  

These Jython scripts could enhance additional functionality, like adding encryption/decryption and checksum techniques on top of the existing ones.

"Significant advantage of such a mechanism comes from the fact that these scripts can be modified or added
without any complex deployments or compilation of the application or product".

What did I do with such a framework ?
I developed certain scripts to accomplish this:

Discover WebSphere Application server ports within each node for a given cell. This meant that the core product was not aware of WebSphere or Weblogic. Jython scripts specific to WebSphere application server configuration automation made the product customized to fit to be used for WebSphere Administration purposes. Meaning , the product was customized for WebSphere App server needs. Similarly, customized the same product to execute certain tasks to achieve some configuration changes for Weblogic Application server. All this was done by developing the jython scripts independent of the core product and then the bundled jar of scripts were dropped in a location for the core product to pick and act.

Note: I am going to add some java code and jython scripts to demonstrate the above explanation in my next series of Power Jython.

Keep reading Power Jython series......

** End **