Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3
Include Page
apache-felix-ipojo-header
apache-felix-ipojo-header

HTML

<div class="content">

Why choose iPOJO?

The OSGi Service Platform provides an excellent foundation for building dynamically extensible Java-based applications. However, such power and flexibility does not come without cost. In addition to new APIs and packaging formats, OSGi developers must shift their thinking to be able to design highly dynamic applications. Early efforts, such as the Service Binder and Service Tracker, attempted to alleviate some of these issues, as well as more recent efforts, such as Declarative Services and Spring Dynamic Modules. iPOJO is another such effort in this area. It is a service-oriented component model created specifically for the OSGi Service Platform.

The purpose behind iPOJO is twofold. The first goal is to simplify OSGi development to the bare necessities. This means that providing services, using services, and dealing with dynamism should require as little effort as possible from the developer. The second goal is to push beyond support for basic OSGi mechanisms and try to more seamlessly incorporate advanced features, including component configuration, synchronization, and composition. This page summaries the key point of iPOJO.

Simplicity

Trying to create

Why choosing iPOJO?

A simple development model

Trying to do an OSGi-based application with services can be really is challenging. The OSGi API is complex to use and a lot of knowledge about internal mechanisms has to be known to avoid synchronization issues. iPOJO provides a very simple development model. Let; let's look:

Code Block
java
java
1Providing a service
@Component
@Provides
public class MyServiceImplementation implements MyService {
 	//....
}


Code Block
java
java
1Requiring a service
@Component
public class MyServiceConsumer {
 	@Requires
	private MyService myservice;

	// Just use your required fieldservice as any regular field !
}

Is Isn't that not easy? Providing and requiring OSGi services and requiring them have never been so simple.

...

Power

Supporting OSGi services is not the only feature of iPOJO. iPOJO provides a lot of others many other features that allow to simplify developing sophisticated applications very easily. In addition of OSGi services, lifecycle control, and configuration, iPOJO supports the . For example, iPOJO supports configuring components with Configuration Admin, allows sending/receiving and sending events with the Event Admin, allows remote configuration with JMX... And that's just examples, and more.

...

Flexibility

A Is iPOJO missing feature, would like to adapt iPOJO for your application. a feature you need? No problem. iPOJO provides an extensibility mechanism allowing that allows you to mange other (specificcustom) requirements. You can easily adapt iPOJO for your own needs. Creating an extension does not require modifications to modify the core, just implement your own specific you only need to implement a custom handler that will be plugged on your instance. Moreover, Your handlers can also use any of the other iPOJO features.

...

Portability

iPOJO works on any R4.1 OSGi implementation, . It also works on a lot of many Java virtual machines such as Oracle JRockit, JamVM, Dalvik (Android), and Mika... iPOJO only requires only a J2ME Foundation 1.1 virtual machine. So, iPOJO can be embedded inside mobile phone applications or inside your washing machine.

Small footprint, minimal overhead

Performance

Being Been powerful is great, but what about footprint and performances?
iPOJO is small , and was designed to stays stay small. iPOJO The core size of iPOJO is 205Kb (against 816Kb approximately 205k (compared to 816k for Guice-Peaberry and 2112Kb 2112k for the minimal Spring-DM configuration). In addition of to the core, you only deploy required the features you require. For example, if you need proxy injection, just deploy the temporal dependency bundle (less than 70Kb).

The run-time overhead of iPOJO is also very small. On the Peaberry benchmark, iPOJO has very good performance. :

Div
classshell
Code Block

Guice-Peaberry:

276.00

ns/call


iPOJO

Service

Dependency:

118.00

ns/call


Spring-DM:

2384.00

ns/call


iPOJO

Temporal

Dependency:

159.00

ns/call


iPOJO

Temporal

Dependency

with proxy injection:

w/ proxy: 173.00

ns/call

Other benchmarks were also applied. For French readers, you can find them additional benchmarks in the chapter 10 of iPOJO - A flexible service-oriented component model for dynamic systems

...

Development support

Developing OSGi applications can quickly become a nightmare, when it doesn't work things are working as expected. iPOJO helps you to debug your application (and it often happen). FirstFor starters, you can debug iPOJO components as normal OSGi applications (stack traces and line number are not modified). Then, But thanks to the iPOJO's introspection mechanisms, you can also know the structure of your application (which instance uses which service...). So, so you easily understand why a service dependency is not fulfilled, property values...

...

the value of properties, etc.

Design support

iPOJO also provides an architecture description language to design applications in a flexible and hierarchic manner. Designed applications are expressed in term of service to be terms of services and are natively dynamic, and to meaning they support implementation evolution and substitution. Moreover, iPOJO supports service isolation to get your own private service.

Conclusion

So, let's have Give it a try!.

For any question questions or feedback, send an email on the users@felix.apache.org mailing list (send a mail to users-subscribe@felix.apache.org to subscribe).

Include Page
apache-felix-ipojo-footer
apache-felix-ipojo-footer