Build your own C/C ++ plug-in development framework

I have been learning osgi knowledge recently. I bought an osgi principle and Best Practices book, but I haven't got it yet. Unfortunately, several open-source frameworks of osgi currently only support Java and do not support both C and C ++. Unfortunately, the main development languages of our company are C and C ++. Even if osgi is introduced, the benefits are limited. I have long been yearning for the loosely coupled modular development. It seems that osgi has an open-source project for C ++ support, but it seems that the application scope is small. The SCA standard supports the C ++ implementation model, but several open-source frameworks currently only support Java.

Yesterday saw Ding Liang reprinted a blog "C/C ++: build your own plug-in Framework", the original link: http://blog.chinaunix.net/u/12783/showart_662937.html. I have read the method mentioned in it, but I can implement it myself. So I had the idea of building my own C/C ++ plug-in development framework. Today, let's write a preliminary idea.

Elements of the C/C ++ plug-in development framework

Bluedavy has an article about the elements of a service framework (link: http://www.blogjava.net/BlueDavy/archive/2009/08/28/172259.html ). My plug-in framework should also consider and solve the following problems:

1. Register a plug-in;

2. How to call the plug-in;

3. How to test the plug-in;

4. lifecycle management of plug-ins;

5. Management and Maintenance of plug-ins;

6. Plug-in assembly;

7. Agent error handling;

8. Broadcast and subscribe to service events (this is not yet considered for support );

Among them, there are several important points: 1) the plug-in framework should be able to make the modules loosely coupled for real interface-oriented programming; 2) the framework should support automated testing, including unit testing and integration testing; 3) Simplified deployment; 4) Support for distributed deployment. modules can call plug-ins outside the framework.

Technologies used
One problem to be solved by the plug-in framework is the dynamic loading capability of the plug-in. The dynamic loading technology of shared libraries can be used here. Of course, for simplicity, the first step is to consider only a plug-in framework under Linux.

Overall Structure

For the overall structure of the Framework, refer to the osgi "microkernel + system plug-in + application plug-in" structure. Here, we should consider what to do in the kernel. With regard to the microkernel structure, I used to create a microkernel process engine and will share it with you later.

There are two solutions for inter-module data transmission in the framework: first, the XML data bus approach adopted by panyuan. The advantage is good scalability and readability. However, the speed is slow. The second is to use cell streams that I am familiar. The advantage is high efficiency, convenient access, but less readable. In addition, the network byte sequence needs to be considered for cross-framework data transmission.

For inter-framework communication, the system plug-in is encapsulated to hide the communication details of the application plug-in.

Deployment

One-click deployment.

-- Overall Function

In this series of previous articles, I introduced the initial idea of building a C/C ++ plug-in development framework. Next I will expand down step by step to implement my idea.

Today I will talk about the functions or expectations of this framework. I read an article about the continuous Integration Capability Maturity Model yesterday. Inspired by this, my understanding of this framework is becoming clearer.

This framework can be used as the infrastructure of our company's underlying products (switches, resource servers, etc. Upper-layer Java-based products can be developed directly on osgi.

Core functions:

1. The most important function is to provide a modular programming model to promote modular software development and implement interface-oriented programming.

2. Provide an infrastructure that helps improve the reusability of modules.

3. Provides a runtime environment for the C/C ++ plug-in.

4. provides a dynamic plug-in framework that can be dynamically changed without restarting the system. Although this function is not difficult to implement, it does not seem very useful.

--------------------------------------------------------------------------------

Extended functions:

1. Supports the distributed system structure. Multiple runtime frameworks are combined to form a system, which hides remote communication details from the module.

2. Supports the hierarchical architecture of the system.

3. Integration with other development frameworks, such as osgi and SCA.

4. Multiple runtime frameworks can effectively manage runtime frameworks.

5. The concept is similar to that of component, composite, and domain in SCA.

--------------------------------------------------------------------------------

Development Features:

1. To simplify development, develop an Eclipse plug-in for the C/C ++ plug-in the development framework. The ability to generate public code, configuration files, and makefile files that comply with the plug-in specifications according to the plug-in development wizard.

--------------------------------------------------------------------------------

Debug some functions:

1. provides a unified log processing function that can be integrated with log4cpp.

2. Provides message logs between modules and external interface logs of the framework.

3. Provides message and log tracking functions to extract messages and logs related to an event separately.

4. provides resource monitoring to monitor the usage of resources (such as memory, sockets, and file handles.

--------------------------------------------------------------------------------

Test functions:

1. Integrate some unit testing frameworks, such as unitcpp, to achieve the goal of Automated unit testing.

2. Implement the automated integration test framework by yourself, and develop the corresponding Eclipse plug-in to simplify the integration test (using scripts and metadata streams ).

3. Integrate the original automated functional testing framework flowtest and develop the corresponding Eclipse plug-in to simplify functional testing.

4. implement performance testing and monitoring framework.

--------------------------------------------------------------------------------

Deployment functions:

1. automated deployment. Especially for distributed applications.

2. Provide a command line program, use commands to change system configurations, and manage plug-ins.

-- Overall Structure

These days, in order to design the plug-in development framework, I tried to think about the problem with divergent thinking. I have seen dependency injection, AOP (Aspect-Oriented Programming), and contractual design in the middle. Although some tools cannot be used directly, these ideas can be used for reference, such as dependency injection and contractual design. As for AOP, it is highly correlated with tools. Although it is a good idea, it cannot be used directly in C ++.

The dependencies between plug-ins I designed are not implemented through interfaces, but through data (cell streams) between plug-ins ). Cell flow detection can be performed using contracts.

Overall structure of the plug-in development framework

Microkernel:

1. Loading, detecting, and initializing plug-ins.

2. register the service.

3. Calls services.

4. Service Management.

Extension layer:

1. Log printing.

2. The message (cell stream) is interpreted as text in binary format. Easy to locate.

3. Tracing of messages and logs.

Distributed Processing Layer:

1. It is used to communicate with other frameworks.

2. Works with other frameworks to form a distributed system.

Automated Testing Framework layer:

1. Integrate cppunit.

2. Automated integration testing framework.

3. Automated functional testing framework.

Integration layer with third-party frameworks:

1. integration layer with third-party frameworks.

-- Core layer design and implementation

The previous article roughly describes the overall structure of the plug-in development framework. This section describes the design and implementation of the core layer.

As for the design of the core layer, I would like to learn from the idea of the microkernel. The core layer is only responsible for implementing the following functions:

1. Plug-in loading, detection, and initialization.

2. Service Registration.

3. service call.

4. Service Management.

Plugin loading, detection, and initialization

Plug-in loading uses the dynamic loading technology of Linux shared libraries. For more information, see Linux dynamic library analysis on the IBM website.

Service Registration

Service Registration and calling adopt the table-driven method. Maintain a service registry in the core layer.

// Interaction message type between plug-ins
Typedef Enum _ service_type
{
Service_max,

} Service_type;

// The plug-in is used to communicate with other plug-in interface functions, provided by the plug-in.
Typedef prsp_ele_stream (* pf_invoke_service_func) (preq_ele_stream pele_str );

// Driver table
Typedef pf_invoke_service_func service_drive_table [service_max];

The driver table is an array with the subscript of the interactive message type between plug-ins. The members are the receive message processing functions provided by the plug-in. When the plug-in is initialized, register the registration function that calls the plug-in framework to register with the driver table.

The initialization Implementation of the plug-in is:
// The plug-in is used to register the Message Type Function for processing, provided by the plug-in framework.
Typedef ret_result (* pf_service_register_func) (service_type );

// The plug-in is used to communicate with other plug-in interface functions, provided by the plug-in framework.
Typedef prsp_ele_stream (* pf_invoke_service_func) (preq_ele_stream pele_str );

// The response function of the plug-in. After receiving the asynchronous request, the plug-in sends a Response Message to the requesting plug-in after processing is complete. Provided by the plug-in framework
Typedef void (* pf_send_response_func) (prsp_ele_stream pele_str );

// Initialize the plug-in information
Typedef struct plugin_init_st
{
Pf_service_register_func register_func; // register a function with a series of enumerated values. Service enumerated values that the plug-in can process
Pf_invoke_service_func invoke_serv_func; // a function called to interact with other components when interacting with other components. Send the request message.
Pf_send_response_func send_rsp_func; // design an interface for replying to a response message. After receiving the asynchronous request, the system notifies the request module of the processing result.
} Plugin_init_st, * pplugin_init_st;

// Initialize the plug-in function, similar to the constructor. Provided by the plug-in for the plug-in framework to initialize the plug-in when loading the plug-in.
Void pf_init_plugin (pplugin_init_st pinit_info );

The plug-in calls the register_func function in the pf_init_plugin function to register the type of message to be processed by the plug-in.

Service call
// Cell struct
Typedef struct ele_st
{
Ele_tag;
Ele_length Len;
Ele_value value;
Pele_st next;
} Ele_st, * pele_st;

// Request message, in the cell stream format.
Typedef struct req_ele_stream
{
Plugin_id src_id; // Source Plug-in ID
Service_type req_type; // request type
Pele_st ele;
} Req_ele_stream, * preq_ele_stream;

// Response message, in the cell stream format.
Typedef struct rsp_ele_stream
{
Plugin_id dest_id; // the ID of the target plug-in.
Service_type req_type; // type of the Response Request.
Execute_result result; // record the execution result
Execute_reason reason; // reason for recording execution results
Pele_st ele;
} Rsp_ele_stream, * prsp_ele_stream;

// The receiving Plug-In calls the service request function, which is provided by the plug-in and the input parameter is the request cell stream. The return value is the response cell stream, which is used for Synchronous request processing.
Prsp_ele_stream pf_receive_invoke_proc (preq_ele_stream pele_str );

// The processing entry function provided by the plug-in to receive the Response Message. This is the response cell stream.
Void pf_receive_reclipse_porc (prsp_ele_stream pele_str );

Dependencies between plug-ins are implemented through cell streams. The use of cell streams is described in "using cell streams (tlvstream) specifications and simplifying interaction between modules (C/C ++)" In another blog. The external interfaces of the plug-in are unified.

If the plug-in needs to communicate with other plug-ins, call the service Calling Interface passed by the pf_init_plugin function: invoke_serv_func. The plug-in framework searches for the driver table based on the type of the cell stream and finds the corresponding service receiving function. The plug-in uses the pf_receive_invoke_proc function to accept requests from other plug-ins. This function is intended for the plug-in framework to actively register with the driver table.

If it is synchronized during service, this function is used to return the information directly, and the returned information is in the Response Cell stream. For asynchronous requests, the plug-in sends a response through the send_rsp_func function after processing is complete.

Uninstall plug-ins
// The function called when the plug-in is uninstalled, similar to the destructor. Provided by the plug-in, which is called when the plug-in framework is uninstalled.
Void pf_destroy_func ();

 

 

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/pizi0475/archive/2010/04/10/5471637.aspx