I have already created two examples for enterprise projects on OSGi.
Both provide a UI, a service layer that implements a JPA based
repository and a JPA based model.
This one is using CDI annotations and the maven-blueprint-plugin to
create blueprint on the fly:
http://liquid-reality.de/display/liquid/2015/06/30/Apache+Karaf+Tutorial+part+10+-+Declarative+services
https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-blueprint-cdi
This one uses DS and the closure based JPA support:
http://liquid-reality.de/display/liquid/2015/03/05/Apache+Karaf+Tutorial+Part+9+-+Annotation+based+blueprint+and+JPA
https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-ds
I think in themselves the projects are already pretty simple. I do not
see different annotations having a big impact on that.
Still these examples are nothing you could whip up from zero during a
talk. What I would like to achieve is to have an environment where you
can create such an application from an empty eclipse workspace during a
typical talk duration live on stage.
This should include having a test and a near production ready deployment.
I am not sure how to get there but that is what we could discuss here. I
know that Adam Bien is creating such applications based on JEE during
his talks and I think this is pretty impressive.
Additionally I would like to add the requirement that the created
application should show typical best practices that allow to scale up
such a project to a real world project.
The motiviation for this is that many real life projects start like
this. People see a cool technology on a conference and play with it at
home. If it works smoothly they propose it at work. If it then scales up
nicely to a real world prototype the decision is easy to go with it. I
think that is the way to really make people switch to OSGi and karaf.
Christian
Am 13.09.2015 um 21:57 schrieb Milen Dyankov:
Thanks for your examples Jean-Baptiste! I was tinning more about
practical business use cases, but let me comment on those.
First though a little disclaimer. Even though I'm familiar with how
Blueprint works in general, I have not used it for anything serious.
For me it has always been too Spring'ish and the amount of "magic" it
uses is a little bit too much. I moved from iPojo to DS and this is
what I have been using for the last couple of years. So I would leave
aside the native OSGi (I fully agree with Christian on that one) and
Blueprint (I don't feel I'm in a position to comment in a
prejudice free way).
Now about the examples. I don't think I need to comment on the first
one at all. Assuming you are right in your estimations I don't think
5% is worth learning yet another approach. Especially one that tries
to hide from you how things actually work. And as the project grows I
think those 5% will quickly go down to 0 (if not in the negative
range) because one can hardly do anything serious in OSGi without good
understanding of how service registry (including filters, ratings,
patterns, configadmin, ...) works .
As for the second example - I think there is a huge difference between
remote services (REST, SOAP, ...) and persistence / transactions and
we should not consider those equal to automate / simplify. Remote
services are straightforward. You request a resource, something builds
it for you (how, is totally out of scope for the use case) and sends
it back to you in the form requested. This is very very easy to
automate. In fact in one of my demos (which btw I will present at
ApacheCon) I do exactly that. It's bundle with a single class using
standard JAX-RS annotations. I don't see how can you make it any
easier than that.
JPA and JTA is a whole different story. It is complex. Not because of
the standard, framework or the implementation but because of the
domain it operates on. Developer need to know the model,
relationships, constraints, isolation levels, limitation of the
underlying storage, ... thousands of things. Honestly speaking I don't
see @jpa(provider="openjpa",dataSource="my") useful for anything but a
very simple use case (tempted to write a "hello world" equivalent). I
still remember the CMP EJB that was supposed to make this so simple
and how it died naturally because simple equals limited. Then
Hibernate made ORM useful. But let's be honest here, it was far from
simple. And still people were moving from EJB to Hibernete to get the
job done. We (the Java community) have walked a long way to bring ORM
to what it is today and it's still far from simple. That is because
the problem it targets is complex and flexibility is far more
important for any real use case.
With all the respect, I don't believe a few high level annotations
will make anyone switch to Karaf for some serious projects. For
personal projects and initial attraction - may be. But if you want to
introduce this as a technology to be used in a real project - "it's
easy" is not enough argument to convince your senior architects. In
fact I would argue that if the SpringBoot didn't have the word
"Spring" in it (and all the trust and marketing that goes with that)
it could have existed for a number of years and none of us would have
heard about it.
On the other hand in the OSGi landscape we already have a bunch of
projects which goal is to make it easier for Java EE folks to move to
OSGi world. But even they have realized you can't completely ignore
and hide OSGi. You are probably familiar with Amdatu's projects. I
must admit I find their web services and DOSGi approach a lot easier
than CXF. Also more flexible. But it's not only that. Out of
curiosity, I just had a look at Pax CDI and surprise surprise there is
a @OsgiService annotation there. There is also an explanation of
requirements and capabilities which one need to understand. Sure those
can be generated for you by the build tool and you can completely
ignore @OsgiService annotation and only wire your beans. But in such
case my question would be: why are you using OSGi ? There is also bnd
and bndtools that in many cases simplify development a lot (and you
can use them with ant, maven, gradle, whatever the build system of
tomorrow will be).
My point is, I wish we (OSGi community) were more united and more
collaborating. I think there is too much internal competition in the
space and efforts are focused in promoting particular projects (often
by attempting to compete with a well established JEE product) and not
so much the technology itself. I think OSGi (as of release 6) is
simple enough. I think there are plenty (IMHO too many) of choices for
developing OSGi applications to choose from to be as close as possible
to what you already know. I think it will never be the case that
someone would develop something serious with OSGi without investing in
knowing how it works! I think what is hard is hard because it has to
be hard. When it is "hard" it make you think about why you are doing
what you are doing. Ultimately this results in better design and solid
architecture.
That is not to say there is nothing to improve. But I'm more on
Christian's side here. I would look around to see how to improve what
is already there. Whether that is CDI (really? people want that?) or
(better) integrating with bnd/bndtools or something else. To quote
Einstein "make as simple as possible but not simpler" ;)
Regards,
Milen
On Sun, Sep 13, 2015 at 7:51 PM, Christian Schneider
<[email protected] <mailto:[email protected]>> wrote:
The CDI and JEE annotations are exactly taylored to the enterprise
use cases. I doubt that we can create better ones.
Abstracting away from the technology can only mean you introduce
another layer of indirection. This can only make sense if the
underlying technology is crappy which I think is not the case.
I am looking forward to see what you propose but I think
reinventing the whole set of annotations will probably not be the
way to go. We saw this path in the karaf 4 commands and I think
the result is not good.
Instead I propose we look at the annotations and examples you
provide and think how they could be implemented with existing
standards + a minimal set of additional
annotations that fit well into an existing technology.
Christian
Am 13.09.2015 um 19:13 schrieb Jean-Baptiste Onofré:
Hi Christian,
Workload is one thing, multi-dependencies/pom/etc is something.
In the annotations, even if the workload is the same, it's the
kind of annotations. The purpose is to provide more high
level, use case centric annotations, more than low level
technical one.
I agree that we could extend the maven-blueprint-plugin, but I
would prefer to keep it more high level and decoupled from the
underlying technology involved.
karaf-boot purpose is to be straight forward and avoid the
"big mess & soup about what should I use, what the version, etc".
I'm still convince that at least a BoM provided by karaf-boot
is interesting.
I'm also still think that an abstract Karaf oriented is valid.
Regards
JB
--
http://about.me/milen
