What OSGi tutorials are there for learning how to build modular Java applications? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.

Closed 9 years ago.

开发者_JAVA技巧 Improve this question

What tutorials would you recommend for learning about modular Java with OSGi, and advice on how to write decoupled systems by decomposing them into modules? What level of granularity is right; a big bundle with everything, lots of very little bundles with one specific task, or somewhere in between?

---

What level of granularity is right

I hope this doesn't come off as sounding too trite, but I can't think of any way to answer other than - it depends. Off the top of my head, here are some factors that would influence the answer: How big is the project? How many developers? How long will it be in use? Is it a single-shot throwaway app (say, for a demonstration), or something you need to continue to develop over a number of years? Do you want to support multiple configurations of the same base application? After releasing, do you have the opportunity to do major refactorings, or would this be impossible? Is it open source or closed source? Does the budget allow additional up-front costs (to design and develop in an appropriate modular way) for projected future benefits (not having to modularise a monolithic initial implementation)?

If you develop lots of little bundles you increase your flexibility, but at the cost of an increase in complexity. You will probably have to abstract out common interfaces into their own modules that other modules use to interact with each other. If you look at something like the Eclipse IDE, which has a lot of bundles (100+?), some of which are quite large in themselves, trying to decipher how it all fits together without some really good documentation or roadmap is like pulling teeth.

Can you provide a few more concrete details of a specific application? It might help narrow down the advice.

---

As Ash say: "It depends". I would take the following points into regard before deciding on the structure of the modularity.

• Embedded or enterprise application? The first realm is a environment with very scarce resources. Here it make sense to have many bundles, that can loaded and unloaded if needed (but not to many bundles since the management etc eats up resources as well). In the enterprise world you need fast start-up time and reactions for an application.
• Can you easily separate your application in model, view, and controller? This is a good starting point for the modularization.
• Do you expect that some parts of the application need to be updated often, some won't? This might be good cutting line as well.
• Finally, can you foresee that some parts of the application can be reused in other applications? Put them into a separate bundle.

One more advice: have a look at the versioning capabilities of OSGi. You can specify what is the minimum (and maximum) version that is needed by another bundle.

---

It probably doesn't suit you, but I've liked this book (in German, i don't think there are translations available): http://www.dpunkt.de/buecher/2635.html

---

I think there is no straight-forward answer to your question. Its a Software Engineering problem and if there is a phrase that applies its "It depends....".

The general idea of decomposition is to tackle complexity by composing a solution to a large problem from simpler solutions to smaller problems (i.e. divide and conquer). There should not be an increase in complexity, rather it should be easier to build your system this way. From practice, this usually works fine, as long as the "modules" are loosely coupled i.e. without introducing too many inter-dependencies.

The trade off may sometimes be investing a little bit more of work into each module, depending on how independent a module should be (example: Felix embeds an XML parser in some modules to avoid the dependency; or it provides various mechanisms for configuration, so that bundles don't depend on other services; there will always be some kind of tradeoff...)

Also there are mechanisms to get a visual overview of a composition even if you have a complex composition see "Visualizing OSGi Systems" (I also remember having seen some BEA presentation with graph plots....).

I have been working on the Coalevo Project for some time now (sorry, the link is currently down, because I am in a transition phase) and I think it has worked to a large degree and maybe the future shows how much so).

From my point of view, I think that the decision should be rather strategic and go beyond a single project view.

Also consider, that in todays landscape, with most commercial J2EE containers on top of OSGi (BEA is, Websphere is, JBoss to some degree, Glassfish in the works), maybe the upfront cost is reduced drastically by the fact that you can obtain off-the-shelf ready-to use bundles from various different providers (which was always a basic element of the OSGi vision).

Expect to see more patterns emerging over time, that will help to design OSGi software "properly" for modularity; OSGi by itself, does provide the fundamental definitions for dynamic modular systems, but I think that software build on top of it isn't just modular by itself.

I have been trying to work in this area a little bit myself; check out "OSGi Mediator".

For me, OSGi may be at the node scale, what SOA can be at a large distributed scale, if done right.