I've searched on internet and here on SO, but couldn't wrap my mind around the various options.
What I need is a way to be able to introduce customer specific customization in any point of my app, in an "external" way, external as in "add drop-in jar and get the customized behavior".
I know that I should implement some sort of plugin system, but I really don't know where to start.
I've read some comment about spring, osgi, etc, can't figure out what is the best approach.
Currently, I have a really simple structure like this:
com.mycompany.module.client.jar // client side applet
com.mycompany.module.server.jar // server side services
I need a way of doing something like:
1) extend com.mycompany.module.client.MyClass as com.mycompany.module.client.MyCustomerClass
2) jar it separately from the "standard" jars: com.mycompany.customer.client.jar
3) drop in the jar
4) start the application, and have MyCustomerClass used everywhere the original MyClass was used.
Also, since the existing application is pretty big and based on a custom third-party framework, I can't introduce devastating changes.
Which is the best way of doing this?
Also, I need the solution to be doable with java 1.5, since the above mentioned third-party framework requires it.
Spring 3.1 is probably the easiest way to go about implementing this, as their dependency injection framework provides exactly what you need. With Spring 3.1's introduction of Bean Profiles, separating concerns can be even easier.
But integrating Spring into an existing project can be challenging, as there is some core architecture that must be created. If you are looking for a quick and non-invasive solution, using Spring containers programmatically may be an ideal approach.
Once you've initialized your Spring container in your startup code, you can explicitly access beans of a given interface by simply querying the container. Placing a single jar file with the necessary configuration classes on the classpath will essentially automatically include them.
Personalization depends on the application design strongly. You can search for a pluggable application on the Internet and read a good article (for an example: http://solitarygeek.com/java/a-simple-pluggable-java-application). In the pluggable application, you can add or remove a feature that a user decides. A way for the pluggable application is using the Interface for de-coupling of API layer and its implementation.
There is a good article in here
User personalisation is something which needs to be in the design. What you can change as an after thought if the main body of code cannot be changed, is likely to be very limited.
You need to start be identifying what can be changed on a per user basis. As it appears this cannot be changed, this is your main limiting factor. From this list determine what would be useful to change and implement this.
Related
I have been trying to design a software architecture with guice that allows for separate implementations by different teams in different regions.
The idea is like:
API-A ->
API-B -> API-Global
API-C ->
API Global has a bunch of classes (related to GraphQL) that should be non-interface shells of what needs to be implemented.
Because the region specific APIs depend on the Global package I can't have region specific code there. Is there a way to create guice bindings in an overall graph that the Global API can find through introspection for consumption?
I looked at Guice multibinds to do this but I am not sure that the best way to do it. I know this is possible using Spring but would really want to use Guice to do this.
Thanks.
The way OSGi and other frameworks handle this is to let each implementation come with a standardized file which contains meta-information (meaning the implementation class), and which Global-API can then find on the classpath to configure itself.
(Consider using a standardized framework instead of reinventing the wheel, but this is the general process which I have seen in these frameworks).
I want to develop a service that exposes a rest API to upload plugins and the plugins are locally executable, i.e. other classes from the server use them.
The plugins also:
The plugin should be a jar file that is submitted through the REST API and once is validated, is then made available through another API method to see the metadata and to execute.
Are not too complex (they should all contain at least a a class that extends of an abstract class or an interface implementation of an interface, the service) but could have their own dependencies.
The API allows to validate that the plugin is compliant with the service and that it declares some additional information on an XML or JSON file contained on the JAR.
Have some metadata that has to be exposed through the API (Version, who made it, is it usable, what data can it be handled) in Json form.
All implement an algorithm to perform some data crunch so they all have something like an execute() method. The result of executing this method is handled to another class, so is not totally important to expose it on the API.
Must be able to be uploaded and executed by the other server classes in runtime, so no restart is possible
The thing is that I am not sure where to start, since I had already developed some of the basic API on Spring-boot since it had all the things I needed to easily develop a REST API but the more I read about how to dynamically load modules (plugins) the more I see that Spring does not support this ind of thing and I am not sure a class loader or Service loader would work in that context.
I found out about OSGi framework but I honestly do not know it changing the whole technology stack will help me so I want to make sure it is the right answer, and if yes, then find some resources that point me in the right direction, e.g. some tutorial that implements something similar.
Thank you for any advice.
Checkout OSGi enRoute. It includes a model to developing RESTful services: http://enroute.osgi.org/services/osgi.enroute.rest.api.html.
OSGi sounds like the best match to what you try to do.
You can install everything as a bundle including your main application. Nowadays this is much less work than some years before but still not to be underestimated.
The other option is to start an embedded OSGi framework where you just install your plugins. This is less work but you need to know exactly how it works.
So for both cases I suggest to get help from an external OSGi expert as it speeds up the transition a lot and avoids many wrong paths you will choose as a beginner.
I'm writing a big Red5 Java application for the web.
Red5 a Flash Media Server alternative that is java based and is written with the spring framework.
I want to have many versions of my application online, each with different behaviors and different classes enabled or disabled.
I'm looking for a way to convert my code into modules based code that will allow me to remove/add modules/features from the main application.
I know about OSGI http://www.springsource.org/osgi but it says that it needs a SpringSource dm server and I have no idea how it's gonna work together in red5 and it's seems very complicated to fully understand.
I don't have a good knowledge of spring framework in general, i work with it db-related and that's it. red5 uses it more extensively.
so can anyone please make any sense from this information ? is there something that can be done to divide my code to modules ?
any information regarding the issue would be greatly appreciated.
My preferred method of dealing with this kind of situation is Dependancy Injection (DI). Spring has a DI capability built in, for which a tutorial is easy to find online. However, Spring's DI is not as good, for many reasons, as that provided by Guice, which I would highly recommend. (The main advantage of Guice over Spring's DI in my opinion is type safety.)
DI is basically a mechanism for replacing class implementations at runtime. Rather than hard code dependancies into classes (by having a class construct other classes directly for example) you code them to have their dependant classes passed to them in their constructors. The DI framework will then pass the correct instances at runtime according to the configuration. Spring configuration can be done via annotations or an XML file, Guice uses a subclass of com.google.inject.AbstractModule.
So you could use different configuration files for the different instances of your application, and have them provide different sets of features for activation, or indeed different implementations of the same feature. If you set up the application to use this technique then the only thing that need differ between instances is a single configuration file.
For a product that is used by multiple clients where different clients ask for different customizations both user interface wise and functionality wise, how to accommodate those changes without getting the code cluttered with client specific code?
Are there any frameworks(for any programming language) that help with this?
To add more detail the UI is web based and written using JSP.
This is one of the most difficult business requirement to manage different versions of same app, so do not expect open frameworks for that case, however each company involved develops its own system for sth like that.
As for business logic modifications, you would benefit for strong interfacing and IoC (such as Spring). You would override the services for your specific case and change the required methods, then inject into IoC the modified version of the service.
As for UI, it's more difficult because you've chosen JSP, which has little flexibility. When you'd be programming in Swing or GWT, than you could do UI modification same way - override needed UI classes, change them, inject modified versions. With JSP - propably there will be lot of modifications to .jsp files in your customized version.
Now the change modification/bug fixing - there is fully usage of version controll system. Of course, your customer-specific versions are branches, while main, standard version is trunk. Bug fixes are made to trunk, then merged to customer-specific branches. With interfacing/overriding implementations most of the merges would be the easy way, however, with JSP, I would expect conflicts to be often...
Generally, code changes merge easier than anything XML-based.
How about simple OOP? Set up a realistic interface/base class and depending on some sort of configuration, instantiate either child class A or B, depending on the client. It's hard to provide more detail for a language-agnostic question like this, but I think it's very realistic.
One solution to this problem, common in the Win32/.NET world, is to move client-specific "code" into resource files. Many .NET projects (.NET has built-in support for this pattern through the System.Resources namespace) use this pattern for internationalization, by placing the UI strings into one file per language, and then loading UI strings from the appropriate file at runtime.
How does this pattern apply to a JSP application? Well, here you can keep one resources file per client (or, instead of files, use a database), and load the user-specific customizations from the resources file whenever you serve a page.
Say for example that your biggest customer wants to have their logo overlaid on some part of each webpage in your site. Your page could load the CustomerLogo property, and use that as the src attribute for the HTML image at that part of the page. If you are serving the page to the important customer, you load the URL "/static/images/importantCustomerLogo.png," and otherwise you fall back to the default resources file, which specifies the URL "/static/images/logo.png."
This way, you can abstract out the code for loading properties into one or two Java files, and just use those properties throughout the website. The only part of your codebase that is customer-specific will be the set of resources files, and those can be in a clean XML format that is easy to read and modify. The upshot is that people who didn't develop the application in the first place can modify XML without having to read the code first, so you won't have to maintain the resources files - the sales department can do that job for you.
GWT does this out of the box via a feature called deferred binding
When compiling a GWT application the compiler actually generates different versions of the code targeted for each different browsers. this is done automatically out of the box with the GWT components taking care of the different browser gory details.
This feature can be expanded to product arbitrary compilations based on custom properties. here is a simplified example: assume you have different view definitions for a normal and a detailed view
public abstract class AbstractView { ....}
public abstract class NormalView extends AbstractView { ... }
public abstract class DetailedView extends AbstractView { ....}
you can create a module definition that will generate two different versions, one using the NormalView class the other using the DetailedView (in your gwt.xml file)
<define-property name="customMode" values="normal,detailed" />
<replace-with class="com.example.NormalView">
<when-type-is class="com.example.AbstractView" />
<when-property-is name="customMode" value="normal" />
</replace-with>
<replace-with class="com.example.DetailedView">
<when-type-is class="com.example.AbstractView" />
<when-property-is name="customMode" value="detailed" />
</replace-with>
using
AbstractView view = GWT.create(AbstractView.class);
will provide the appropriate instance at runtime.
It's up to you to encapsulate your client specific code into specific classes, and to expose common interfaces for the different implementations.
You will also need to select the appropriate compiled version according to the client currently viewing (you can use jsp for this.)
please don't take the code samples above as tested, there might be problems with the syntax, it is just intended to convey the general idea
A JSP backend is an ideal hosting environment for a GWT app, you will be able to take advantage of the requestfactory mechanism for easy communication between client and server.
obviously there is a learning curve here, IMO the official documentation is a good place to start.
I guess that you may try to read OSGi related articles (or books)...This platform would give you a very pragmatic answer to your modularity issues.It's especially designed to be able to handle different modules living all together with dependencies and versioning.
As mentionned early in an answer , dependency injection through the OSGi Declarative Services is a very valuable alternative to Spring , with dynamic capabilities.. Deploying a bundle providing a service and your references will be updated automatically , dropping it and they will be refreshed too...
Have a look to this technology and ask some questions after ?
Regards
jerome
I'm building a J2EE application in which I want to allows plugins. I'm fairly convince of the goodness of IoC framework, and so the application will have one to manage services.
Now, I want to allows plugins to be added as simple JAR dropped in the classpath + perhaps a simple configuration file to edit to activate them, in no way something looking like Spring XML config files.
Most of the plugin architecture will be base around strategy/pipeline/chain of command patterns: for example the best plugin for an action is chosen by strategy, several plugins add filtering actions to an user input thanks to a pipeline, and so one.
So, I want to be able to:
define service interfaces in the core application,
set-up core implementation for extensible services with the chosen pattern in the main application,
let third party plugins register themselves in these hooks.
The first 2 points are quite easy, with or without IoC. The last one seems more complex without support at the IoC container level, or at least there is a lot of plumbing to do (how to manage classpath/sevice discovery, how to manage service orders in pipeline when the context change (new plugins), how to manage service overriding, etc).
I do know that Tapestry5 is great in that regards[1], but I can't find anything really relevant for Spring and Guice. And my company is more a String/Guice one than a T5 one (well, if I'm able to show that it's the best solution...)
So I'm wondering:
if I missed some obvious documentation;
if my requirement are so specials;
if an IoC container is not the right tool for that, and I should look for OSGi or something else.
Thanks for any tips !
[1] http://tapestry.apache.org/tapestry5.1/tapestry-ioc/configuration.html
I'm not sure how this would work with exactly what you're looking to do, but Guice's basic mechanic for handling plugins is Multibindings. How you handle discovery of plugins is up to you, but there are a variety of choices including scanning the classpath for implementations of plugin interfaces, having plugins provide a Module that adds their implementation(s) to the multibinder(s), using a config file that lists the plugin implementation classes, etc.
As the link mentions, you'd need OSGi if you need plugins to be addable at runtime with no restart.
Have you considered having a look at the Java EE 6 solution - CDI, implementation is named Weld based on JBoss Seam - which might be useful?
Once you start dropping in jars and their dependencies and then go though a couple of iterations of this with different plugins and different dependency versions, then you will start to feel the pain that many "application host containers" succumb to.
One possible solution to this problem is OSGi, although I did note a Tapestry blog highlighting the pitfalls of the OSGi approach:
http://blog.tapestry5.de/index.php/2010/01/19/tapestry-ioc-modularization-of-web-applications-without-osgi/