Develop Reference

Is it possible to build a SOA without a service broker? Is there any good example of this?

I have built an application in OSGi which offers a REST API for reading values from different data sources. Then I have several modules installed in my application exposing those data sources. For example one module exposes readings from a database, another exposes from a website, another reads from a TCP/IP device, etc...
For example, if I do this:
http://--------/listAllDataSources
I would get something like this if I had 3 modules installed:
{
dataSources : [ 0, 1, 2 ]
}
Then if I do this:
http://--------/read/1
I would get a reading from the data source number 1.
{
currentValue : "44.5"
}
So my architecture consists of:
[ External Apps]
|
|
*Web*
|
|
[ REST API ]
[M1][M2]....[Mn]
Is this considered a SOA?
Also, I do not use any service broker as you can see. Does this makes my app not a SOA?
Thanks!

I think you're mixing concepts here, PedroD. You can read in detail what the term SOA refers to here. (I'm intentionally not linking to the Wikipedia article, which is absolutely terrible and misleading).
Your application is built to expose functionality, so it can be said that it can be a part of SOA but it is not a SOA by itself.
SOA refers to an architectural style that supports service orientation. It helps an organisation integrate and develop its systems in a service oriented way. SOA is a paradigm much broader than what you have and it greatly exceeds the context of a single application - e.g. it establishes internal enterprise guidelines, governance processes, building of service inventories across multiple business domains and orchestration of services in order to enable the organisation to implement business processes very fast, thus reducing time to market.
Of course SOA has levels of evolution. You may not still have processes in place or you may not use a messaging broker, and it can be said you're still working towards a fully service-oriented architecture. But in order to achieve SOA you must have at the very minimum have some kind of middleware tier, so you can avoid point-to-point integration and do at least simple service compositions.
I'd say that your appliation is built with integration in mind, with service orientation in mind, but it is not SOA by itself.
Note: If you want to internally organise your application in a style that borrows many concepts from SOA you might want to check out Microservice Architecture. Actually to me, your architecture seems more similar to Microservices.

SOA is an abstract concept which similarly to 3-tier architecture can be applied on different levels.
If you consider "External Apps" as a part of your system then these apps are service consumers and "[Rest API] with [M1]..[Mn]" is a service provider. Communication is over http. This is SOA.
If scope of your system is only "[Rest API] with [M1]..[Mn]" then you still have consumer - [Rest API] ( which is also provider of external service), and providers [M1]..[Mn].
Each of this module is a service so I would consider this design as a very simple SOA. Service broker job is done by OSGI runtime, and communication protocol can be just Java method calls - however it can be simply replaced by ECF to distribute modules across different JVMs and then the communication protocol depends on what is configured in ECF.

Distributed OSGi - what is the proper way to manage bundles across all containers?

We are considering utilizing distributed OSGi in our enterprise environment.
We would have the following setup:
10 to 100 OSGi containers on many hosts offer various services.
Many of these services are provided by more than one container.
Some of these services may require being consistent across all
containers (same version deployed).
What is the proper way to manage bundles' lifecycle (install, start, update, stop, uninstall) across all containers?
Several requirements:
As there may be so many containers, all of them should be handled
together; i.e. when I am about to update a bundle, a single command
should update all containers where that bundle already present.
Commands must be repeatable: first perform a command on test systems, and then repeat the exact same command on production system once testing is complete.
I appreciate any suggestion regarding the above question.
Best regards,
Marton

You might want to have a look at more "managed" solutions made for cloud-like environments: Apache ACE or its bigger brother Amdatu.
Apache ACE turns a single OSGi Containers into managed containers whose state can be controlled from a single administration point.
Amdatu is a more complete framework that includes ACE for provisioning but adds horizontal functionality.

In terms of managing large numbers of bundles, look at Karaf features - they greatly simplify handling largely suites of bundles.
For the distributed side of things, take a look at the Karaf subproject Cellar, it's clustering Karaf using HazelCast (and it installs in Karaf via the features mechanism).

If you are serious about enterprise ready - meaning "robust" - distributed OSGi runtimes - then have a look at the Paremus Service Fabric. We've been doing this since 2005 :)
The Service Fabric's provisioning / management architecture is extremely scalable (>> 1,000's of containers), responsive and stable! Several years development and commercial runtime experience underpinning this product. The Service Fabric architecture supports multiple concurrent distributed OSGi based applications. The Service Fabric's architecture is OBR centric; our lead engineer was responsible recent OSGi Alliance OBR specification activities.
The Service Fabric message backplane leverages the DDS messaging protocol - which IMO is the natural partner for distributed OSGi. The Paremus RSA (remote service implementation) is a clean room implementation of the standard - which is highly robust, light weight and allows dynamic plug ability of protocol and distribution providers. The default discovery provider - is again DDS.
Finally - and Service Fabric works out of the box.

In Gyrex we use p2 to distribute bundles across different nodes of a cluster. It's possible to control which bundles should be provisioned to which node by using the node tags and LDAP filter expressions (common in OSGi). For example, it's possible to install (and activate) web bundles only on web nodes.
Support for distributed services is not available out-of-the box. ECF needs to be integrated manually.

Benefits of an enterprise service bus

Where can I find some information on the uses and benefits of an enterprise service bus (ESB)?
I am looking for information about:
the kinds of problems and ESB helps to solve
the alternatives to an ESB - and the tradeoffs in selecting between them
what you need to do as a developer to build ESB-compatible systems
I'm looking for a finer level of detail than just Wikipedia or online marketing brochures from vendors. Ideally, some example code would help to clarify what's involved in taking advantage of an ESB. Information from a .NET or Java perspective would be the most useful.
Thanks.

I'd suggest To ESB or not to ESB to start with, written by the creator of Mule.

ESB's are a good way to implement Enterprise Integration Patterns.
Kinds of problems that an ESB helps to solve
You have a number of protocols you'd like to normalize to a single protocol (e.g. FTP, email, SOAP, XMPP, etc. to a messaging system) e.g. ActiveMQ. This lets you decouple the implementation of services from the protocol.
You want a consistent way to hook services into this architecture so that they can listen for messages, process messages and generate messages (Message Endpoints, Channel Adapters etc.).
You may want a managed container to deploy these various components into (e.g. ServiceMix, Mule)
You may want a number of prebuilt components and adapters into various protocols (e.g. ServiceMix, Mule and Camel have a lot of pre-built components).
You may require long running workflows. Business Process Management is often something that is provided alongside an ESB (Apache ODE plugs into a number of Open Source ESBs).
Alternatives to an ESB
The alternatives really depend on the problem that you're trying to solve.
To provide distributed services, people often use application servers exposing services via some point to point RPC protocol (like EJBs over RMI or Web Services over HTTP). So, rather than putting a message onto a 'bus', a client directly calls a server.
To respond to specific protocols, you could just build a client that responds to that protocol for example writing an application that listens for emails using JavaMail or one that listens to XMPP using Smack. If your problem is constrained to one or two protocols it may not be worth bringing in a full ESB.
What you need to do as a developer to build ESB-compatible systems
This will depend on the ESB you select, although given that most of the good ones are designed to call out into all sorts of protocols as well as host POJOs, there isn't much you should need to do build ESB compatible systems. It is worth trying to make your code asynchronous.
For examples, Apache Camel probably has the most succinct configuration, here's a tutorial.

Three key advantages:
A bus provides a way for end points to connect to each other without having to directly talk to each other. It simplifies the communications for the end points as they only have to conform to a standard communication interface, the bus. (This is with any technical bus, not just ESBs)
An ESB provides a single place to get some key end point metrics: frequency, availability, and performance.
An ESB tends to provide more than one communication interface. However, a developer only needs to choose the easiest one to get and receive the data from the bus.
However, make sure those will provide business value for your situation. Having an ESB is adding yet another complexity to your enterprise. Ideally you shouldn't choose this based on a few applications, but the entire organization. There should be only one production ESB cluster for the organization.
Alternatives:
Just connect things to each other directly especially if the communication protocols are the same. This is good for simple application clusters and does not require too much thinking. However, as your number of applications grow, maintaining the interconnections becomes difficult.
Another alternative is an MQ implementation. This will provide you with a way of pushing data around without having complex interconnections, but then you are forced to use only one communication channel. Fortunately for Java, they have the JMS standard.
Practicality:
I have stated the possible alternatives. They may seem lousy at first, but it is not to say you cannot start that way. I personally write things to talk to the remote directly without going through an ESB to make sure it works without worrying too much about integration issues.
If you don't have an ESB, I suggest you try Mule for development and WebSphere ESB for test and production. I tend to use two products that supposedly follow standards to make sure we keep the vendors honest and to make sure your developers are conforming to standards preventing inadvertent vendor lock-in.
In the end, just answer the following question: is the time adding the bit of complexity to simplify other complexities your enterprise worth the cost in the long run?

In addition to the sites that were already mentioned. You should read this article on "Don't use an ESB unless you absolutely have to". It was written by the CTO of MuleSource, one of the most popular open source ESB's available. Not exactly an answer to your question, more of making a point to ask yourself "Do I need an ESB"?

There is a decent 3-part series over at IBM regarding ESB that's pretty concept oriented and vendor agnostic (for the most part). I have found lots of good stuff on ESB by poking around IBM's site. There is also some decent info and videos and stuff over at the BizTalk site.

Check out this Hanselminutes podcast. It answers a few questions that you should really ask yourself before implementing a service bus.

An enterprise service bus (ESB) is a software architecture for middleware that provides fundamental services for more complex architectures. For example, an ESB incorporates the features required to implement a service-oriented architecture (SOA). In a general sense, an ESB can be thought of as a mechanism that manages access to applications and services (especially legacy versions) to present a single, simple, and consistent interface to end-users via Web- or forms-based client-side front ends.
In essence, ESB does for distributed heterogeneous back end services and applications and distributed heterogenous front-end users and information consumers what middleware is really supposed to do: hide complexity, simplify access, allow developers to use generic, canonical forms of query, access and interaction, handling the complex details in the background. The key to ESB's appeal, and possibly also its future success, lies in its ability to support incremental service and application integration as driven by business requirements, not as governed by available technology.
http://searchsoa.techtarget.com/definition/enterprise-service-bus
WSO2 Enterprise Service Bus(Product)
WSO2 Enterprise Service Bus (ESB) 4.7.0 documentation! WSO2 ESB is a fast, lightweight, 100% open source, and user-friendly ESB distributed under the Apache Software License v2.0. WSO2 ESB allows system administrators and developers to conveniently configure message routing, mediation, transformation, logging, task scheduling, failover, load balancing, and more. It supports the most commonly used Enterprise Integration Patterns (EIPs) and enables transport switching, eventing, rule-based mediation, and priority-based mediation for advanced integration requirements. The ESB runtime is designed to be completely asynchronous, non-blocking, and streaming based on the Apache Synapse mediation engine.
WSO2 ESB is developed on top of the revolutionary WSO2 Carbon platform, an OSGi-based framework that provides seamless modularity to your SOA via componentization. It includes many features and optional components (add-ons) you can install in the ESB, and you can easily remove features not required in your environment, thereby allowing you to fully customize and tailor WSO2 ESB to meet your exact SOA needs.
Architecture
Application infrastructure on the enterprises may be inherently complex, comprising hundreds of applications with completely different semantics. Some of these applications are custom built, some are acquired from third parties, and some can be a combination of both and can be operating in different system environments.
Integration among these heterogeneous applications is vital to the enterprise. Different services may be using different data formats and communication protocols. Physical locations of services can change arbitrarily. All these constraints mean your applications are still tightly coupled together. An ESB can be used to loosen these couplings between different services and service consumers.
WSO2 ESB is a full-fledged, enterprise-ready ESB. It is built on the Apache Synapse project, which is built using the Apache Axis2 project. All the components are built as OSGi bundles.

Take a look at my presentation "Spoilt for Choice - How to choose the right ESB".
I explain when to use an ESB, Integration Suite, or just an Integration Framework (such as Apache Camel). I also discuss the differences between open source and proprietary ESBs.

there is zero reason to use an ESB. Don't do it. Needless complexity. Why go through an intermediary when you can go direct? The ESB folks will tell you point to point is bad, yet somehow point to point to and from the ESB is good.

The first question you need to ask yourself is why do you need an ESB?
ESB is usually used in Event SOA distributed architectures, which seem to be a hot buzzword nowadays. Before you jump into ESB let me remind you of Martin's Fowler First Law of distributing Systems:
http://martinfowler.com/bliki/FirstLaw.html
"My First Law of Distributed Object Design: Don't distribute your objects (From P of EAA).
The relevant chapter is available online."
When you're build a new system, the most important aspect is that it is future proof, that means easy scalability and maintainability. If you build your system around the concept of loosed services with static defined contract distributed in a networked environment, you can "hide" the architecture you want for that particular service, because the interfaces are still there.
ESB is close related to asyn messaging systems, so before you start jumping into that kind of implementation, know that an architecture does not have to be homogeneous, that is all services be implemented the same way, don´t start the biggest mistake which is distributing your system from the start, you should only distribute as you need to scale, no before hand. What you need to make sure though, is that your services should be able to be easily distributed should the need arise, without breaking any contracts which would mean, changes to clients of that service.
As for the benefits of ESB, they are the same as SOA, ESB adds the context of asyn messages (events) operations.

First let me explain SOA. It it about building an architecture as a set of reusable software modules exposed as “Services” with well defined interfaces. The services facilitate loose coupling and abstracts its implementation details from the clients.
SOA might end-up messy if each component called on services directly. Therefore it has following common issues.
How do you find which services are used & which are not?
How do you find the clients using a particular service?
How do you roll out updates to a service or expose new versions to existing services without disruption?
How do you support backwards compatibility for older clients invoking older service interfaces
How do you perform logging, auditing, security enforcement etc across all services for internal / external traffic?
The ESB is the solution to above issues. ESB…
Helps brings in order
Can strictly enforce corporate policies
e.g. Security, throttling, auditing etc applied consistently
Virtualizes service endpoints
Facilitate versioning, flexible updates, HA / Load Balancing etc.
Perform routing, mediation, transformation, etc
Some sample use cases can be found here. Note that they are from AdroitLogic's developer site and strictly coupled with UltraESB, AdroitLogic's ESB.

Embedded OSGi or Application Bundle

I've just spent the last two days reading up all the OSGi stuff I can get my hands on and I finally think I've got my head around it.
I'm now trying to integrate it with an existing application for many reasons such as 3rd party plugins, automatic updates, not to mention that SOA just makes me happy.
I now have a decision I'm struggling to make, which is weather
My entire application should become an OSGi bundle installed by default in the container; or
My application should launch an embedded OSGi container and interact with it for all the plugged services.
I'd prefer 1, as this lets me update the application easily and the architecture would be consistent. Of course I expect to have to refactor the application into many smaller bundles. However 2 makes things much easier in the short term, but will become awkward in the future.

for option 1) you really don't want your whole application in one bundle - you would loose all the benefit from OSGi - but really that depend on the size of your application.
It really depends where you want to run application and which task you want it to perform. Also you probably want to have some kind of remoting to access the exposed services.
in option 1) you need to enable some kind of http/servlet bundle (there is a bridge that exists)
in option 2) you application can run inside an application server so you don't have to worry about that.
The first question you want to ask yourself is about the operational environment. Who is going to run the application? Do they need/want to be trained on OSGi? Are they more comfortable with the J2EE stack?
I think the best option for you is to keep your options open, there is no real differences between 1) and 2) but what is staring the OSGi framework, either your code or the framework code. Your application itself, ie the bundles constituting your application will be exactly the same.
My advice would be not to worry too much about OSGi runtime to start with - but start on OSGi development - nothing stop you from developing "OSGi-style" and running in a standard JRE environment.

I think you want to go with option 1, and have your application consist of a set of bundles inside of an (mostly out-of-the-box) OSGi container.
It will improve modularity of your own code. You may even find that some parts of it can provide services of use outside of the original application.
It is much easier to use other bundles from inside of OSGi, than from the host application. Because the host application cannot see the bundles' classes (and the bundles can only see what you explicitly expose from the host), you have to set up a pretty convoluted classpath or resort to reflection to call bundles from outside the container.
So I'd say that even in the short run, option 1 is probably easier.
Also, I agree with Patrick's assertion that the bulk of your code does not need to care if it runs in OSGi or in a plain JVM. Especially when using Declarative Services and such the need to use OSGi interfaces and mechanisms from your code is greatly reduced: You just add a few descriptor files to the jar's META-INF.

I would rather go with option 2,
Inherently your application is not a bundle, but an application.
If you want the OSGi value addition, spawn the OSGi container from within your application.
That way, at a future date if you decide to move away from OSGi, you can do in a simple way.

Have you looked at the Spring Application server? Doesn't this allow you to manage this stuff?

I would definitely recommend 1 - the app should become an OSGi bundle(s), and not only because of easy updating. If half of your code is in the OSGi framework and half is outside, you will have to construct a bridge for the communication between the two halves; you could also have issues with classes visibility.
There are also many benefits from 1, and it is not so difficult to achieve. What I would recommend is the following:
Separate the application in as many modules as it seems logical to you.
You are not forced to have many modules - OSGi can as easily handle two bundles 10 MB each as well as 100 smaller bundles. The separation should be a result of the functionality itself - a good starting point is the UML architecture diagram you probably did before you even started implementing the stuff. The places where the different functional parts communicate with each other are exactly the places where you should think about defining interfaces instead of classes - and these interfaces will then become your OSGi services and the implementations will become the bundles - and the next time you will have to update some part you will find out it is much easier to predict the effect on the other parts of the app because you separated it clearly and declared it in the manifest of the bundles.
Separate any external/open source libraries you use in separate bundles. They will most probably be the parts that will have to be updated more often and on a different timeline than your own code. It is also more important here to define clear package dependencies, package versions, and to avoid depending on the implementation parts instead of only on interfaces!
Think about which parts of the app you want to expose to plugins. Then make OSGi services out of these parts - i.e. publish the interfaces in the OSGi registry. You don't need to implement any specific thing - you can publish any Java object. The plugins will then use the regitry for the lookup.
The same goes for the plugins - think about what you want to get from plugins and define the respective interfaces that the plugins can implement and publish and your app can lookup in the registry.
And as a final tip - see what bundles are already available in the OSGi framework you have chosen. There are many standard OSGi interfaces defined by the OSGi spec - for configuration, logging, persistent storage, remote connections, user admin, eventing, and many more. Since they are standard, you can use them without becoming dependent on any specific OSGi implementation. And uninstall what you don't need.

What does OSGi solve?

I've read on Wikipedia and other sites about OSGi, but I don't really see the big picture. It says that it's a component-based platform, and that you can reload modules at runtime. Also the "practical example" given everywhere is the Eclipse Plugin Framework.
My questions are:
What is the clear and simple definition of OSGi?
What common problems does it solve?
By "common problems" I mean problems we face everyday, like "What can OSGi do for making our jobs more efficient/fun/simple?"

what benefits does OSGi's component system provide you? Well, Here is quite a list:
Reduced Complexity - Developing with OSGi technology means developing bundles: the OSGi components. Bundles are modules. They hide their internals from other bundles and communicate through well defined services. Hiding internals means more freedom to change later. This not only reduces the number of bugs, it also makes bundles simpler to develop because correctly sized bundles implement a piece of functionality through well defined interfaces. There is an interesting blog that describes what OSGi technology did for their development process.
Reuse - The OSGi component model makes it very easy to use many third party components in an application. An increasing number of open source projects provide their JARs ready made for OSGi. However, commercial libraries are also becoming available as ready made bundles.
Real World - The OSGi framework is dynamic. It can update bundles on the fly and services can come and go. Developers used to more traditional Java see this as a very problematic feature and fail to see the advantage. However, it turns out that the real world is highly dynamic and having dynamic services that can come and go makes the services a perfect match for many real world scenarios. For example, a service could model a device in the network. If the device is detected, the service is registered. If the device goes away, the service is unregistered. There are a surprising number of real world scenarios that match this dynamic service model. Applications can therefore reuse the powerful primitives of the service registry (register, get, list with an expressive filter language, and waiting for services to appear and disappear) in their own domain. This not only saves writing code, it also provides global visibility, debugging tools, and more functionality than would have implemented for a dedicated solution. Writing code in such a dynamic environment sounds like a nightmare, but fortunately, there are support classes and frameworks that take most, if not all, of the pain out of it.
Easy Deployment - The OSGi technology is not just a standard for components. It also specifies how components are installed and managed. This API has been used by many bundles to provide a management agent. This management agent can be as simple as a command shell, a TR-69 management protocol driver, OMA DM protocol driver, a cloud computing interface for Amazon's EC2, or an IBM Tivoli management system. The standardized management API makes it very easy to integrate OSGi technology in existing and future systems.
Dynamic Updates - The OSGi component model is a dynamic model. Bundles can be installed, started, stopped, updated, and uninstalled without bringing down the whole system. Many Java developers do not believe this can be done reliably and therefore initially do not use this in production. However, after using this in development for some time, most start to realize that it actually works and significantly reduces deployment times.
Adaptive - The OSGi component model is designed from the ground up to allow the mixing and matching of components. This requires that the dependencies of components need to be specified and it requires components to live in an environment where their optional dependencies are not always available. The OSGi service registry is a dynamic registry where bundles can register, get, and listen to services. This dynamic service model allows bundles to find out what capabilities are available on the system and adapt the functionality they can provide. This makes code more flexible and resilient to changes.
Transparency - Bundles and services are first class citizens in the OSGi environment. The management API provides access to the internal state of a bundle as well as how it is connected to other bundles. For example, most frameworks provide a command shell that shows this internal state. Parts of the applications can be stopped to debug a certain problem, or diagnostic bundles can be brought in. Instead of staring at millions of lines of logging output and long reboot times, OSGi applications can often be debugged with a live command shell.
Versioning - OSGi technology solves JAR hell. JAR hell is the problem that library A works with library B;version=2, but library C can only work with B;version=3. In standard Java, you're out of luck. In the OSGi environment, all bundles are carefully versioned and only bundles that can collaborate are wired together in the same class space. This allows both bundle A and C to function with their own library. Though it is not advised to design systems with this versioning issue, it can be a life saver in some cases.
Simple - The OSGi API is surprisingly simple. The core API is only one package and less than 30 classes/interfaces. This core API is sufficient to write bundles, install them, start, stop, update, and uninstall them and includes all listener and security classes. There are very few APIs that provide so much functionality for so little API.
Small - The OSGi Release 4 Framework can be implemented in about a 300KB JAR file. This is a small overhead for the amount of functionality that is added to an application by including OSGi. OSGi therefore runs on a large range of devices: from very small, to small, to mainframes. It only asks for a minimal Java VM to run and adds very little on top of it.
Fast - One of the primary responsibilities of the OSGi framework is loading the classes from bundles. In traditional Java, the JARs are completely visible and placed on a linear list. Searching a class requires searching through this (often very long, 150 is not uncommon) list. In contrast, OSGi pre-wires bundles and knows for each bundle exactly which bundle provides the class. This lack of searching is a significant speed up factor at startup.
Lazy - Lazy in software is good and the OSGi technology has many mechanisms in place to do things only when they are really needed. For example, bundles can be started eagerly, but they can also be configured to only start when other bundles are using them. Services can be registered, but only created when they are used. The specifications have been optimized several times to allow for these kind of lazy scenarios that can save tremendous runtime costs.
Secure - Java has a very powerful fine grained security model at the bottom but it has turned out very hard to configure in practice. The result is that most secure Java applications are running with a binary choice: no security or very limited capabilities. The OSGi security model leverages the fine grained security model but improves the usability (as well as hardening the original model) by having the bundle developer specify the requested security details in an easily audited form while the operator of the environment remains fully in charge. Overall, OSGi likely provides one of the most secure application environments that is still usable short of hardware protected computing platforms.
Non Intrusive - Applications (bundles) in an OSGi environment are left to their own. They can use virtually any facility of the VM without the OSGi restricting them. Best practice in OSGi is to write Plain Old Java Objects and for this reason, there is no special interface required for OSGi services, even a Java String object can act as an OSGi service. This strategy makes application code easier to port to another environment.
Runs Everywhere - Well, that depends. The original goal of Java was to run anywhere. Obviously, it is not possible to run all code everywhere because the capabilities of the Java VMs differ. A VM in a mobile phone will likely not support the same libraries as an IBM mainframe running a banking application. There are two issue to take care of. First, the OSGi APIs should not use classes that are not available on all environments. Second, a bundle should not start if it contains code that is not available in the execution environment. Both of these issues have been taken care of in the OSGi specifications.
Source : www.osgi.org/Technology/WhyOSGi

I've found the following benefits from OSGi:
Each plugin is a versioned artifact that has its own classloader.
Each plugin depends on both specific jars that it contains and also other specific versioned plug-ins.
Because of the versioning and isolated classloaders, different versions of the same artifact can be loaded at the same time. If one component of your application relies on one version of a plug-in and another depends on another version, they both can be loaded at the same time.
With this, you can structure your application as a set of versioned plugin artifacts that are loaded on demand. Each plugin is a standalone component. Just as Maven helps you structure your build so it is repeatable and defined by a set of specific versions of artifacts it is created by, OSGi helps you do this at runtime.

I don't care too much about the hotplugability of OSGi modules (at least currently). It's more the enforced modularity. Not having millions of "public" classes available on the classpath at any time protects well from circular dependencies: You have to really think about your public interfaces - not just in terms of the java language construct "public", but in terms of your library/module: What (exactly) are the components, that you want to make available for others? What (exactly) are the interfaces (of other modules) you really need to implement your functionality?
It's nice, that hotplug comes with it, but I'd rather restart my usual applications than testing all combinations of hotplugability...

You can, analogically speaking, change the motor of your car without turning it off.
You can customize complex systems for the customers. See the power of Eclipse.
You can reuse entire components. Better than just objects.
You use a stable platform to develop component based Applications. The benefits of this are huge.
You can build Components with the black box concept. Other components don't need to know about hidden interfaces, them see just the published interfaces.
You can use in the same system several equal components, but in different releases, without compromise the application. OSGi solves the Jar Hell problem.
With OSGi you develop thinking to architect systems with CBD
There are a lot of benefits (I reminded just these now), available for everyone who uses Java.

edited for clarity. OSGi page gave a better simple answer than mine
A simple answer: An OSGi Service Platform provides a standardized, component-oriented computing environment for cooperating networked services. This architecture significantly reduces the overall complexity of building, maintaining and deploying applications.
The OSGi Service Platform provides the functions to change the composition dynamically on the device of a variety of networks, without requiring a restarts.
In a single application structure, say the Eclipse IDE, it's not a big deal to restart when you install a new plugin. Using the OSGi implementation completely, you should be able to add plugins at runtime, get the new functionality, but not have to restart eclipse at all.
Again, not a big deal for every day, small application use.
But, when you start to look at multi-computer, distributed application frameworks, that's where it starts to get interesting. When you have to have 100% uptime for critical systems, the capability to hotswap components or add new functionality at runtime is useful. Granted, there are capabilities for doing this now for the most part, but OSGi is trying to bundle everything into a nice little framework with common interfaces.
Does OSGi solve common problems, I'm not sure about that. I mean, it can, but the overhead may not be worth it for simpler problems. But it's something to consider when you are starting to deal with larger, networked, applications.

A Few Things that drive me nuts on OSGi:
1) The implentations and their context loaders have a lot of quirks to them, and can be somewhat async (We use felix inside of confluence). Compared to a pure spring (no DM) where [main] is pretty much running through everything sync.
2)Classes are not equal after a hot load. Say, for instance you have a tangosol cache layer on hibernate. It is filled with Fork.class, outside of the OSGi scope. You hotload a new jar, and Fork has not changed. Class[Fork] != Class[Fork]. It also appears during serialization, for the same underlying causes.
3)Clustering.
You can work around these things, but it is a major major pain, and makes your architecture look flawed.
And to those of you advertising the hotplugging.. OSGi's #1 Client? Eclipse. What does Eclipse do after loading the bundle?
It restarts.

OSGi makes your code throw NoClassDefFoundError and ClassNotFoundException for no apparent reason (most probably because you forgot to export a package in OSGi configuration file); since it has ClassLoaders it can make your class com.example.Foo fail to be cast to com.example.Foo since it's actually two different classes loaded by two different classloaders. It can make your Eclipse boot into an OSGi console after installing an Eclipse plugin.
For me, OSGi only added complexity (because it added one more mental model for me to grok), added annoyances because of exceptions; I never really needed the dynamicity it "offers". It was intrusive since it required OSGi bundle configuration for all modules; it was definitely not simple (in a larger project).
Because of my bad experience, I tend to stay away from that monster, thank you very much. I'd rather suffer from jar dependency hell, since that's way way more easily understandable than the classloader hell OSGi introduces.

I am yet to be a "fan" of OSGi...
I have been working with an enterprise application at Fortune 100 companies. Recently, the product we use has "upgraded" to an OSGi implementation.
starting local cba deployment...
[2/18/14 8:47:23:727 EST] 00000347 CheckForOasis
finally deployed and "the following bundles will be quiesced and then restarted"
[2/18/14 9:38:33:108 EST] 00000143 AriesApplicat I CWSAI0054I: As part of an update operation for application
51 minutes... each time code changes... The previous version (non-OSGi) would deploy in less than 5 minutes on older development machines.
on a machine with 16 gig ram and 40 free gig disk and Intel i5-3437U 1.9 GHz CPU
The "benefit" of this upgrade was sold as improving (production) deployments - an activity that we do about 4 times a year with maybe 2-4 small fix deployments a year. Adding 45 minutes per day to 15 people (QA and developers) I can't imagine ever being justified. In big enterprise applications, if your application is a core application, then changing it is, rightly so (small changes have potential for far reaching impacts - must be communicated and planned with consumers all over the enterprise), a monumental activity - wrong architecture for OSGi. If your application is not an enterprise application - i.e. each consumer can have their own tailored module likely hitting their own silo of data in their own silo'd database and running on a server that hosts many applications, then maybe look at OSGi. At least, that is my experience thus far.

If a Java based application requires adding or removing modules (extending the base functionality of application), without shutting down the JVM, OSGI can be employed. Usually if the cost of shutting down JVM is more, just to update or to enhance functionality.
Examples:
Eclipse: Provides platform for plugins to install, uninstall, update and inter-depend.
AEM: WCM application, where functionality change will be business driven, which can not afford down times for maintenance.
Note: Spring framework stopped supporting OSGI spring bundles, considering it as unnecessary complexity for transaction based applications or for some point in these lines. I personally do not consider OSGI unless it is absolutely necessary, in something big like building a platform.

I've been doing work with OSGi almost 8 or so years and I have to say that you should consider OSGi only if you have a business need to update, remove, install or replace a component on runtime. This also means that you should have a modular mindset and understanding what modularity means. There's some arguments that OSGi is lightweight - yes, that is true but there are also some other frameworks that are lightweight and easier to maintain and develop. Same goes to secure java blah blah.
OSGi requires a solid architecture to be used correctly and it's quite easy to make OSGi-system that could just as easily be a standalone-runnable-jar without any OSGi being involved.

The OSGi provides following benefit:
■ A portable and secure execution environment based on Java
■ A service management system, which can be used to register and share services across bundles and decouple service providers from service consumers
■ A dynamic module system, which can be used to dynamically install and uninstall
Java modules, which OSGi calls bundles
■ A lightweight and scalable solution

It is also being used to bring additional portability of middleware and applications on the mobile side. Mobile side is available for WinMo, Symbian, Android for example. As soon as integration with device features occurs, can get fragmented.

At the very least, OSGi makes you THINK about modularity, code reuse, versioning and in general the plumbing of a project.

Others have already outlined the benefits in detail, I hereby explain the practical usecases I have either seen or used OSGi.
In one of our application, we have event based flow and flow is defined in plugins based on OSGi platform so tomorrow if some client wants different/additional flow then he just have to deploy one more plugin, configure it from our console and he is done.
It is used for deploying different Store connectors, for example, suppose we already have Oracle DB connector and tomorrow mongodb is required to be connected then write a new connector and deploy it and configure the details through console and again you are done. deployment of connnectors is handled by OSGi plugin framework.

There is already a quite convincing statement in its official site, I may quote as
The key reason OSGi technology is so successful is that it provides a very mature component system that actually works in a surprising number of environments. The OSGi component system is actually used to build highly complex applications like IDEs (Eclipse), application servers (GlassFish, IBM Websphere, Oracle/BEA Weblogic, Jonas, JBoss), application frameworks (Spring, Guice), industrial automation, residential gateways, phones, and so much more.
As for the benefits to developer?
DEVELOPERS: OSGi reduces complexity by providing a modular architecture for today’s large-scale distributed systems as well as small, embedded applications. Building systems from in-house and off-the-shelf modules significantly reduces complexity and thus development and maintenance expenses. The OSGi programming model realizes the promise of component-based systems.
Please check the details in Benefits of Using OSGi.