Hi JB,
some comments inline.
Am 13.09.2015 um 17:21 schrieb Jean-Baptiste Onofré:
Hi Milen,
First, let's take spring-starter-embed out of the picture (it's the
part to embed Karaf and applications in a big jar file ready to execute).
Let's focus on the pure dev path.
Let me take two use cases:
1. Very Simple
In this example, you have one interface, one bean (business code), you
want to expose the bean as a service.
You can:
1.1. Use native OSGi:
- Effort: in addition of the business code, you have to write the
Activator, knowing the "OSGi API", dealing with the service
registration lifecycle. In addition, you have to prepare a Maven
pom.xml with bundle as packaging and dealing with maven-bundle-plugin.
- Workload: I evaluate that your business code is only 50% of the
workload, as you need to write the Activator and the pom.
I would never recommend to use native OSGi for business code as it is
too error prone. So lets simply leave out this one.
1.2. Use blueprint:
- Effort: in addition of the business code, you have to write
OSGI-INF/blueprint/your.xml blueprint descriptor. So, instead of the
"OSGi API", you have to know the blueprint syntax. The pom.xml is the
same as in 1.1.
- Workload: I evaluate that your business code is 55-60% of the
workload. You need to write the blueprint XML, but if you have
multiple beans it's probably easier than an activator (not sure ;)).
Alternative: Use CDI annotations and maven blueprint plugin. This should
result in similar percentages to SCR. The advantage is that the CDI
annotations are well known and standardized. OSGi services are covered
with pax cdi annotations.1.3. Use scr annotations:
- Effort: you use scr annotations directly in your bean
(@Component, @Activate, etc). The pom.xml is the same as the
maven-bundle-plugin generate the components XML for you. It requires
that your know the SCR annotations (low level), and add required
dependencies in the pom.xml
- Workload: your business code is 80% of the workload, 20% is
about the annotations and pom.xml
I agree with this. Though percentages will be even better in typical
multi module projects as you can define the maven bundle plugin once in
the parent.
1.4. Use karaf-boot:
- Effort: you have the choice between the karaf-boot annotations
(high level) or the scr annotations (low level). In the pom.xml, you
just have to add a dependency to karaf-boot-starter (for karaf-boot
annotations) or karaf-boot-starter-scr (for scr annotations). The
karaf-boot-starter* are BoM describing all that you need, including
scr dependencies.
- Workload: your business code is 85% of the workload, 15% about
the annotations and pom.xml. The gap of 5% compared to 1.3 is due to
the usage of karaf-boot-starter* that brings all the dependencies for
you (you don't have to figure out all dependencies set, etc in your
pom.xml).
As you describe yourself the percentage is not much better than scr or
blueprint approach with annotations. So I think it is clearly not worth
introducing a proprietary framework for this little advantage.
So, on this first use case, scr and karaf-good are probably the
easiest way to go.
2. JPA (the same can be applied to JTA, REST, SOAP, etc)
In this example, you want to expose a service dealing with JPA/JTA.
You have an @Entity POJO, and a DAO using JPA and the entity.
You can:
2.1. Use native OSGi:
- Effort: you have to create the Activator. The Activator can
create an EntityManager or retrieve one as a service. You have to
create the META-INF/persistence.xml. You have to call the
maven-budle-plugin in your pom.xml, without forget to define the
<META-INF/> element.
- Workload: your business code is about 40% of the workload, bunch
of code has to be written in the activator. You also have to create
the META-INF/persistence.xml.
Again lets jut leave it out.
2.2. Use blueprint:
- Effort: with latest Aries Blueprint versions, you have to create
a blueprint XML with <jpa:enable/> element and defining
beans/services. You still have to write the persistence.xml and update
the pom.xml
- Workload: your business code is about 60% of the workload
Like in CDI annotations with blueprint. Additional you can easily use
JPA and transactions with pure JTA and JPA annotations. So it is all
standardized, well known. The annotations are almost exactly like for
pax cdi. So as soon as it is matured you can siwtch to it easily.
2.2. Use SCR:
Unfortunately, we don't have direct support of JPA (or other
enterprise stuff) in SCR.
The new Aries JPA supports closure based jpa and jta support which is
almost as nice as annotation based.
I hope we can persuade the SCR people over time to allow interceptors so
we can close the gap.
2.3. Use karaf-boot:
- Effort: your just add @jpa(provider="openjpa",dataSource="my")
on the your DAO class. karaf-boot will create the persistence.xml for
you (and the blueprint descriptor for now).
- Workload: your business code is 95% of the workload, 5% is just
to define karaf-boot-starter-jpa dependency in your pom.xml.
I think the @jpa annotation is just syntactic sugar. It only saves the
persistence.xml which is a well known structure and allows further
customizations most people need anyway over time.
I agree that the annotation save a bit xml but as you tpyically can just
copy it from an example or archetype it is not really relevant.
When the project grows the fixed xml size will be less and less relevant.
For instance, for rest service, it could be the same: right now you
have to write a blueprint xml with <jaxrs:server/> element (using
CXF-RS). karaf-boot-starter-rest will do that for you, using the @rest
high level annotation that you can define on your rest class (where
you already have the @Path, @GET, etc jax-rs annotations).
For rest I can imagine using a special annotation. I propose to ot
include it in karaf though and instead implement it as a plugin to the
maven-blueprint-plugin.
As the Aries goal is to support enterprise development in OSGi I think
it is a better place to put these efforts.
Christian
