:: INTRODUCTION

The main problem in my projects was a dynamically features extension through new implementations and new technology fully-fit across the time (software maintenance). For this problem i’m looking for a method to develop a core engine and to develop features through hooked attached plugins.

I decided to write this tutorial to share my plugin connector view.

:: MAIN SCENARIO

Here we have the base scenario about plugins/core interconnection.

:: DATA FLOW

1. An exeternal request incoming

2. Core module do something and pass result to communicator interface.

3. Communicator Interface analyze data received, and identify the correct plugin to load.

4. Communicator Plugin Method, receive data from Communicator Core Interface and parse looking for the correct method to call

5. Method receive data from Communicator Plugin Method and do something.

6. Result value will be returned back through the reversed flow path.

:: MESSAGE STRUCTURE

To accomplish the data flow structure depicted before we should to have the following message structure:

A structure like this is useful to build a correct data flow through Main Core Application and Multiple Plugins.

:: BENEFITS

1. Path Oriented Communication (Like TCP/IP Communication … it works )

2. Low CPU Computation Load (No load on message passing architecture)
   

3. Multiple Plugins Loading (We can call multiple plugins at the same time)
   

4. Memory Optimization (Dinamic Module Load/Unload)

5. Better Software Management (Only Plugins should to be maintained)
   

6. Better Collaboration (Everyone could write his own plugin)
   

7. … and more over !!!

:: DISADVANTAGES

1. Considerable Network Load (in case of heavy production environment)

2. Plugins Developing Rules (plugins should be written following a rigorous scheme)

:: SOURCE CODE

Let’s post some code to understand basic concepts:

We receive a preformatted input string from our input device. In this string we have the message structure depicted before. Then, first of all, we should to get our “Header” (passed[0]);

In the following statement we prepare the plugins load call

# Construct Module Name
my $obj = “SRVConf::” . $passed[0];

Now we must (in Perl) load requested plugin through eval syscall

# Use Dynamical Module
eval “use $obj”;

Now we can call Plugins Communicator method.

# Initialize Module
if(my $module = $obj->new())
   my @returned = $obj->communicator($passed[1]);

For those about Plugins Statement we must supply a “new” method

sub new {
my $this = {};
….
}

and a “communicator” method that know all Plugin method list

sub communicator() {
    if ($action eq “adduser”) {
        return(_adduser($splitedstr[1]));
    } elsif ($action eq “moduser”) {
        return(_moduser($splitedstr[1]));
    } elsif ($action eq “deluser”) {
        return(_deluser($splitedstr[1]));
    } elsif ($action eq “getuserinfo”) {
……