Thanks for your answer Arved.
I try to explain better: my purpose is to develop a web application
with a dynamically generated UI according to the logged customer, and
the purchased/activated modules.
A good framework for server-side generated UI could be Vaadin, but for
making the application modular I think that I should use it with OSGi.
I don't know if Vaadin+OSGi could be a good solution for this type of
web app. What do you think?
You may well have a good reason to use OSGi, but customizing the user
experience isn't one of them. Let's say that your web app is called
SuperApp 1.0, and you've sold it to 3 customers, A, B and C, with user
bases of 100, 200 and 300 respectively. Customer A has licensed all 5
bundles, Customer B has licensed 4 of them, and Customer C has only the
2 core bundles for the SuperApp 1.0 application.
OSGi is a good fit for delivering the 3 different versions of SuperApp
1.0 to the 3 different customers. But you're not going to then use it to
shape the UI and functionality experience for all 600 users individually.
Modularity of the sort that you are looking for is typically more
fine-grained than what you'd get from OSGi bundles. Fairly standard Java
EE APIs and techniques are applicable to getting the kind of UI and
modularity you want.
Some points and/or rules of thumb and/or thoughts:
1. in your scenario you've got paying users with known identities.
They'll be logging in and will _expect_ to authenticate. It's at that
point that you can map them to roles or permissions [1] and enforce
declarative or programmatic authorizations;
2. Any decent web framework will have a view technology that supports
disabling/enabling and hiding/un-hiding UI elements based on code-behind
values etc. If a given user hasn't paid for doing something in SuperApp
1.0, this usually translates to not having paid to _see_ something (or
click on something) in a page. And this translates to roles and/or
permissions.
3. Modularize from the bottom up starting with the model/domain/business
logic layer(s), whatever specific terminology you choose. Make _those_
modules (not OSGi modules, but just small-m modules) look like services
in the SOA sense. You'll know you did a good job if, after having
finished that job, you can actually drop some WS-endpoints on top of
those services, and have some users access via web service clients
rather than through your standard web tier.
This is the best kind of modularization, and will serve you in good
stead for any scenario. Furthermore, _once_ you've done that exercise,
if you're then minded to consider OSGi, you're in much better shape to
consider what comprises each bundle;
4. It can be a gray area as to whether you customize a page and its
codebehind for different users with different authorizations, or whether
you supply a different copy of at least the page (and possibly its
codebehind) for user groups with substantially different visuals and
allowed functionality. At one extreme you'll simply have different
chunks of app for different users, actually.
Generally you'll be able to tell if you're trying to make a given page
and its codebehind do too many different things for too many different
user groups.
*********
I think you see what I am getting at here. Modularization is an
architectural, design *and* coding concept that applies to every layer
of your app, horizontally and vertically. You should be doing this all
the time in every app you ever write, in any language.
Re Vaadin: I haven't used it in the real world, so I am not competent to
recommend it. What I do know of it indicates to me that you'd be as
capable of doing what you want to, with Vaadin, as any of many other
frameworks out there.
AHS
1. I prefer permissions, and some security frameworks have good support
for them, not just roles.
