esProc Implements Dynamic Pluggable Computing Modules for Java Application

In JAVA development, programmers sometimes get stuck in such a situation where the other modules are relatively stable, but in the computing module some unpredictable changes often take place. You have to rewrite the computing module every time when you need, for example, the algorithm will change with business rules;the types of data sources and data structures must be adapted to the specific application environment; the query criterions must be adjusted accordingly based on user’s ever-changing demands. In such scenarios,there needs to be a dynamic pluggable computing module to replace the original computing module without affecting other functions. Here are some common examples:

1. With the same query functions, different users have different requirements on the query criterions.You need to customize the computing module as required by given users.

2. To read data from Excel and compute such data, the parameter input interface and result output interface all keep unchanged, but you needto use different algorithms dynamically depending on Excel format.

3. Each branch has its own database, you need to present the same query results from different databases with different types and structures.

4. Real wages of employees in an enterprise are computed based on performance scores with an algorithm that changed frequently, and you need to replace the old algorithm with a new one while other codes being unchanged.

There are many ways to implement such dynamic pluggable computing modules. Here we describe how the computing module in the above example 4 is implemented with esProc.

First, to implement the computing module in esProc, its script is shown as below:

         

This article focuses on input and output parts, but not on the specific algorithm. As can be seen from cell A1, this module has two input parameters: start and end, which come from the caller, namely, JAVA codes. As we can see from cell A12, the computed result will be output to JAVA through JDBC.

Then, to implement the calling code of dynamic module in JAVA, as shown below:

Class.forName("com.esproc.jdbc.InternalDriver").newInstance();

Connection conn = DriverManager.getConnection("jdbc:esProc:local://");

CallableStatement cstmt = conn.prepareCall("call dynamic(?,?)");

cstmt.setString(1, start);

cstmt.setString(2, end);

cstmt.execute();

ResultSet rs = cstmt.getResultSet();

As you see, the methods to call esProc script and stored procedure of common database are exactly same; where, Driver Name and URL must follow the naming rule of esProc. dynamic is the module name, i.e., prefix of esProc script file name dynamic.dfx. dynamichas two input parameters: start, end. The computed results are stored in variable rs, which can be directly output to a Web or a client application.

Finally, to plug the computing module dynamically.

When the algorithm changes, the old module requires to be replaced with a new one. As we can see from codes in the previous step, the computing module is less likely to couple with JAVA codes, so that it only needs to be replaced directly with the file of the same name. If you want to retain the old module, the module name can also be read from profile, or passed to prepareCallfunction via string parameter. The new module code is not listed here, because that’s not the point of this article.

Through the above steps, esProc will help you easily replace the old computing module with a new one.

Of course, the dynamic pluggable computing module can also be achieved in JAVA, but JAVA lacks the function library for basic algorithms, such as: grouping, aggregation, sorting, filtering, joining, distinct value, intersection, rank, etc., the programmer shave to write these basic algorithms manually to achieve computing modules. It is obviously unreasonable for you to implement these basic algorithms directly in the business logic, because thiswould lead to repeatedly writing similar codes for each computing module, further to make them too enormous and less readable. The ideal practice is to implement a set of basic algorithm library functions, then call these library functions in allcomputing modules.But it is harder for application programmers to design a complete set of well-built systematic basic-algorithm function library,this often leads to higher coupling codes, poor stability, eventually muddled maintenance on computing modules. In addition, JAVA codes need to be recompiled, and deployed with more trouble; when there are lots of pluggable computing modules, whether they would be used or not, these Java class/jar will occupy a certain memory space but cannot be released, producing a certain impacton performance.

esProc itself is a set complete of well-designed basic library functions, and only required one-tenth of JAVA codes, it can implement the computing module with equivalent functions, so as to return you a higher developing efficiency; esProc's main program and the script file are separated from each other, between which, a lower coupling makes maintenance far more convenient. In addition, esProc script can be used without compiling, as a real hot-deployment, esProc script will not be loaded into memory in advance, but loaded as needed, then released immediately after computation is finished, not taking up too much memory over a long time.