Business logic: EJB vs OSGi declarative services

4
votes

I know that EJB is de facto standard in enterprise applications for business logic. However, osgi declarative services can do a lot of things which EJB do. Both are managed by container, both can be used as singleton, both can be used with CDI. The differences which I found are:

  1. EJB has already RMI mechanism but DS don't.
  2. EJB has thread pool but DS don't
  3. DS can require only OSGi but EJB requires JavaEE container (for example if we develop standalone application using JavaEE container will be difficult. Because it will either lead to performance overhead or to necessity to extract EJB container from JavaEE implementation (exm glassfish).

What are other important advantages of EJB explaining its using as standard?

EDIT:
The reason why I asked this question is the following - we want to develop some business logic which can be used both for SE and EE platform. That's why DS seem to be a better solution. However EJB and DS are two universes and we are afraid of missing something important.

3
jakarta-eeosgi
With a very simplified perception you can consider the OSGi service as EJB light. With EJB the J2EE container container will do a lot for you out of box (remote invocation, managing the security context, pooling, transactions, ...). You can achieve the same on the OSGi container, but you have to configure it upfront. - gusto2
Voting to close this as primarily opinion-based. StackOverflow is not for popularity contests. - Neil Bartlett
Also all those points are incorrect anyway. DS/OSGi has Remote Services, see the spec. DS has thread pools (just define an @Reference to an ExecutorService, and you're done). Finally DS doesn't actually need to run on OSGi (though why wouldn't you?). - Neil Bartlett
@Neil Bartlett Thank for your time. But could you instead of voting to close give a full answer to the question. As I am not such OSGi specialist as you but I don't agree that DS/OSGi remote services = RMI. - Pavel_K
@JimJim2000 You're right, OSGi Remote Services is far more than just RMI. I don't know though... this question as worded just seems to be inviting a slugfest between the J2EE and OSGi advocates. If there are technical aspects of either standard (remember they are both de jure standards, not merely de facto) that you would like to clarify, then you might want to ask a more pointed question about those aspects. - Neil Bartlett

3 Answers

4
votes

I did a talk at Apachecon 2015 about Enterprise applications on OSGi. It covers mainly DS vs blueprint as Java EE support is not yet fully ready on OSGi. Still you should find the main enterprise use cases and how to do them in DS.

See http://www.slideshare.net/ChristianSchneider3/osgi-productivity-compared-on-apache-karaf

0
votes

Neither.

Make business logic non dependent on either of those technologies, as they would limit your choices, and you already know you need to run on Java SE.

Good written business logic would have little dependencies and well tested with Unit Test.

And the resulted module jars can be used for both Java EE, and OSGi . If you need to support both, you would have to go with minimal set of common features.

What are other important advantages of EJB explaining its using as standard?

POJO is also standard, but absolute not complicated approach.

-1
votes

OSGi is more for defining the structure of your application where as EJB's are more concerned with handling the logic and letting the container define the structure.

Seeing as your question is in relation to using business logic in both a JEE and Java SE application EJB sounds like the better option especially given that OSGi JEE support isn't yet ready.

In reality I would actually suggest actually using an ESB like mule or WSO2 and just have the business logic that would be shared server-side, extracted out of your Java SE application.