Plugin Application
I guess this is the best place where to ask this.
I am trying to design (for now) an application that is made up from many different plugins (similar to eclipse). I gave a look to how eclipse manages this, I also did some sample code. In practice it looks easy.
What I did so far is having a jar file that defines a set of classes (for now 1) that needs to be inherted by a class inside the other jar file. An xml document that comes with the jar file defines this class, which is then loaded by the main application and certain actions are called on it.
So far so good. My problem comes because of the database. I was hoping to use Hibernate, however to connect with the database. Now what if one of the plugins needs to add a new table inside the database?
My idea was that on stat-up, the main application check whether new tables or constraints are needed and then create them accordingly, however I do not know if there are better solutions!?
does anyone has any comments on the desing I mentioned above, or sugestions?
thanks, and regards,
sim085
[1102 byte] By [
sim085a] at [2007-10-2 8:49:33]
In general I am against having applications add schema to databases.
But if you want to...
You need a generalized interface that applies to all applicable plugins.
It should have the following methods
- Validate Schema - returns true if current schema is valid
- Update Schema - called if the above method returns false.
The above would be called when the jar file, not class file, is first used.
You could enhance this further by providing the following functionality.
- A table with at least the following fields: component identifier, component version and applied timestamp.
- And simple wrapper with CRUD functionality.
The above table would be used by the previous interface (implementations) to easily determine whether they need to do anything. This also allows for updates of existing schemas.
Thank very much for the answer :) It really put things more clear :)
I understood all that you said and already transfered that to paper (I do not want to start anything before having it clear in my mind).
My only further question is on this line:
> And simple wrapper with CRUD functionality.
When you say a wrapper with CRUD functionality you mean; a class that extends an abstract class which in turn is responsable to open a connection with the database (could be retrieved from a pool), insert data, update data and delete data? That is the connection with the database can only be retrieved from this abstract class.
You also said:
> In general I am against having applications add
> schema to databases.
Do you think that would be a flaw in my application design?
Thanks again for your post, as I said before it explains much to me :)
regards,
sim085
and also wanted to add whether you would think it would be wrong to use something like Hibernate to persist the application data.Doing so would mean that also the plugins would have to use hibernate.regards,sim085
> Thank very much for the answer :) It really put
> things more clear :)
>
> I understood all that you said and already transfered
> that to paper (I do not want to start anything before
> having it clear in my mind).
>
> My only further question is on this line:
>
> > And simple wrapper with CRUD functionality.
>
> When you say a wrapper with CRUD functionality you
> mean; a class that extends an abstract class which in
> turn is responsable to open a connection with the
> database (could be retrieved from a pool), insert
> data, update data and delete data? That is the
> connection with the database can only be retrieved
> from this abstract class.
You are providing a table for the plug in users to use. You provide a class that provides access to that table rather than relying on the users to write their own.
>
> You also said:
>
> > In general I am against having applications add
> > schema to databases.
>
> Do you think that would be a flaw in my application
> design?
It probably depends on what the plug ins are really going to do and how they are going to be used.
How often will it really be necessary to provide schema updates?
How independent are the plugins actually? (Just because you are trying for different product lines in a single business doesn't mean that there is no dependence.)
> and also wanted to add whether you would think it> would be wrong to use something like Hibernate to> persist the application data.> > Doing so would mean that also the plugins would have> to use hibernate.Why?
My idea was to have like a framework where the plugins can run. The framework take care of initializing the plugins and all the database conectivity issues. However having a full framework is both complicated, and I am afraid out of my reach at the moment :(
My application will have an end database yes. The reason for this is that all application I can think of always need some sort of database in the back end. I do not want each and every one of the pugins installed have to have a different storage element. So I was thinking of createing a back end database which all plugins would have access to. Now, Yes it is true someone can decide to create a plugin that saves in a text file. However I still want to give the possiblilty to have a common database that all plugins have access to.
Saying this I understood that then all plugins must be able to modify the database. So I tought whether this "Framework" could possibly take care of that issue. That is the plugins would have Util classess that help do this, or else could have like an xml document that specifies what they need to modify in the database!
I have been reading on eclipse for quite some time now. And can not wait to insert in one of my applications. I tought that the plugins could use this framework to use the database
Otherwise what I can do is create an open implimentation on the database, a bunch of interfaces. An then I would have an implimentation of these interfaces with Hibernate, and with normal JDBC, just so that the people doing the plugins can have an option, or invent there own.
I do not know if what I am saying make sense, but what I want to achieve is an application that have a standard UI and a standard Database.
This may be out of subject. But there is a game called Morrowind. It allows you develop standard plugins for the application. Add characters, add resources etc. The backend database is the same. The way the Ui components will be the same. It is just adding information by means of a plugin that changes!
Thanks again for your input jschell. Any coments or sugestions will be apreciated ... Thanks once more :)
regards,
sim085
> My application will have an end database yes. The
> reason for this is that all application I can think
> of always need some sort of database in the back end.
> I do not want each and every one of the pugins
> s installed have to have a different storage element.
> So I was thinking of createing a back end database
> e which all plugins would have access to. Now, Yes
> it is true someone can decide to create a plugin that
> saves in a text file. However I still want to give
> the possiblilty to have a common database that all
> plugins have access to.
>
Hibernate has some way of specifying the interface. You pass that to the plugin.
I have no idea if hiberate allows you to create schema though.
>
> This may be out of subject. But there is a game
> called Morrowind. It allows you develop standard
> plugins for the application. Add characters, add
> resources etc. The backend database is the same.
> The way the Ui components will be the same. It is
> s just adding information by means of a plugin that
> changes!
>
I doubt that it creates any new schema though. Instead it either uses a fixed set of types of it stores meta data and has a generic table for values.
Meta data is where you keep track of the type of data, and the groups of data, etc. And you store values generically usually as a string. And your interface returns the correct type by using the metadata to convert the stored value.
Obvously there is overhead to this. But it means the schema doesn't change.
Thanks for your sugestions jschell :)
I still have many questions in mind, however I prefer doing some examples rather then posting here only for lack of knowledge ... Next I will start playing a little bit more onn Threads, and also want to make some designs on how to keep a layer between the plugins and the database the same.
Thanks again for your sugestions :) and comments. I will keep you informed when I have acomplished something :)
regards,
sim085
I'm just about finished my own plugin framework, which decouples plugins from each other even at the interface level, if you want it to. it makes heavy use of Java 5 so anything implementing it would need to be compliant, but basically I annotate Classes that the plugins want to export with a Service Domain name, for instance "Catalog Services" and annotate the methods those classes want to expose with Service names eg "Catalog Provider".
The API for these plugins makes plugin-izing an application trivial beyond a joke. for example if I have a plugin that provides catalogs and a plugin that consumes them, the catalog plugin would look like this
@Service ( Description="core catalog services", Domain="Catalog Services")
public class CoreLoader extends AbstractPlugin {
@PluginService( serviceName = "Catalog Provider")
public BaseCatalogFactory getFactory(URL location) {
/* CatalogFactory is a singleton that implements BaseCatalogFactory
* this class needs no knowledge of it beyond its name
* and the plugin manager takes care of binding the method as its needed
return CatalogFactory.getInstance().load(location);
}
}
and the client plugin that needs these services is as simple as
@Service( Description="a catalog browser", Domain="Client")
public class ConsoleClient extends AbstractPlugin {
public void intitialize() {
// this is a hook method that can be used to initialize data or whatever
// the plugin manager runs this on every plugin once all are loaded
}
@PluginProxyMethod( Domain="CatalogServices", serviceName="CatalogProvider" )
public BaseCatalogFactory getCat(URL location) {
/* invoke is a protected final method of AbstractPlugin
* that uses a neat combination of reflection, annotations and
* stack trace inspection to work out what service the method
* is acting as a proxy for, the plugin manager returns the
* equivalent method from the other plugin, and then it is invoked
* note that the method does not even need to share a name with its
* remote equivalent. the invoke method uses generics to avoid any tiresome
* casting issues.
BaseCatalogFactory factory = invoke(location);
return factory;
}
}
notice that even passing arbitrary parameters between plugins is trivial, as long as the method signatures match, everything else is taken care of for you. note also that although a plugin can only export one service domain, it can proxy any number for your application to use. with this framework, writing plugin architectured applications really is a simple as the above example. it's certainly no OSGi core, but it's far easier to use
