Although I appreciate Peter's observations and very happy to hear about
his ongoing work in this area, I would like to continue this discussion
a little bit. Although I have great respect for Peter's abilities, I
don't expect that he's going to fix all of these 'OSGi is hard' issues
by himself.
Although I agree that use of OSGi for building server-based webapps is a
real problem (particularly for new users), unfortunately I don't think
it's the only problem. Here are some others...in my recent experience:
1) OSGi services are not well understood...and so not used enough by
'newbies'. There are many reasons for this, I believe, but one that's
particularly a problem (IMHO) is dynamics. OSGi services (and DS)
handle dynamics very well...but I'm finding that many java developers
new to OSGi don't even appreciate the need for services (and DS)...in
order to help deal with dynamics. This was sort of a surprise to
me...given that I would expect server developers to appreciate such
needs (for reliability, upgrade, etc). But frequently they just
don't...and so when faced with the choice of: do I do this right and
abstract out a new service, separate contract from impl, etc...or do I
just create a new class and 'worry about it later'...many make the
latter choice...unfortunately.
My observation is that at least part of this is tooling...i.e. it's
still much more difficult to create a well-designed OSGi service (e.g.
separate interface class from service class at bundle level, etc). It
would be really nice if there were wizards and templates to do this...so
that newbies could create, run, test, refactor their service...as easily
as they can create a new class.
As the project lead for ECF's impl of OSGi Remote Services and Remote
Service Admin [1]...I'm also getting interest from people using remote
services...for OSGi-based SOA. Problems with understanding OSGi
services (1) are compounded when it comes to remote services (wrt
dynamics and reliability in particular). We would like to make it much
easier for people to declare, create, run/test remote services...and it
would be a simple matter to extend a wizard, for example to allow people
to specify remote service export properties (and/or import
properties)...as well as discovery providers, distribution providers,
etc...to allow for remote service export and import via RS/RSA. This is
something we/ECF are working on, but the more I work with new OSGi users
the more I think that a lot of the difficulties of RS overlaps with the
difficulty of just understanding OSGi services.
2) Classloading issues...particularly vis a vis integration with
existing codebases...and/or third party libs...are very difficult for
many app programmers to understand. Clearly, a lot of this is
basically the fault of non-modular codebases, poor planning for
extensibility, etc. But it is a reality...and it's a huge hurdle for
new OSGi devs to get over. I'm not sure what would work here...but
perhaps some runtime analysis tooling? Just a thought.
3) Dependency management. This is obviously a huge one...particularly
with versioning that OSGi supports. It's been a problem for people
I've worked with over and over. I know this isn't the fault of OSGi
really (OSGi helps keep things understanable)...but I think that lot of
developers assume incorrectly that it's a problem with OSGi...rather
than it's a problem with java that OSGi helps deal with. Again I'm not
sure whether/how tooling can help...perhaps some runtime and/or design
time dependency analysis (based upon resolver/wiring). But perhaps
there are other things...e.g. 'modular design' introductions, tutorials,
etc.
This isn't exhaustive, of course. These are just my observations from
recently working with OSGi consumers 'on the ground'. Hopefully others
will continue with observations of their own.
Scott
[1]
http://www.eclipse.org/community/eclipse_newsletter/2013/july/article3.php
On 7/19/2013 12:06 AM, Peter Kriens wrote:
I do agree with the judgement that OSGi is hard to get started with.
The problem with OSGi is that it not only blatantly shows how
unmodular your and much open source code is, it even refuses to run
your code. In many ways it is like your compiler refusing to compile
until you fixed the last of many warnings. Though this is all for good
reasons, in reality a lot of code is actually running ok even though
it is a mess on the inside.
So using standard classic Java patterns do not work very well, mostly
due to extensive dynamic loading to configure the app, which is
fundamentally not modular. This makes it really hard to get started
with OSGi because a lot of open source libraries do not work well with
OSGi for this reason. And even if they run, too few actually leverage OSGi
Last year I found out how hard it is to live outside an App server or
not use Spring. For a web app there is a lot of stuff that you have to
think about that is completely orthogonal to your domain: persistence,
security, caching, queuing, batching, etc. Unfortunately, those OSGi
components that provide that functionality are not there. Lots of open
source libraries, but none work really well in OSGi, they all have
their own configuration models, life cycle, etc., sticking out like
sore thumbs. I also frequently have to cry when I look how open source
libraries try to use OSGi :-(
This is the exact reason the OSGi Alliance has hired me again. My task
for the foreseeable future is to develop a framework for web apps that
leverages OSGi to the hilt, i.e. it does it all in the OSGi way. The
idea is to create a skeleton around the OSGi µservice model and
provide a concrete example how this skeleton can be used to create web
apps. All this extensively documented for end users and not
specification implementers. It also intent to have a full modular
development chain: IDE, build, ci, release, deployment. My goal is to
make web app development as easy and simple like PHP but as robust as
OSGi (I know, its ambitious).
I am currently writing an RFP to define the scope of this work, which
is hard since this is a very broad field. I'd love to get your ideas
as input. The RFP will become publicly available under our new process.
Looking forward to your input, kind regards,
Peter Kriens
On 18 jul. 2013, at 19:50, Krishnan Ganapathy wrote:
Hi Scott,
Am glad at this initiative. Very much needed I think. There is a lot
of grey areas still.. I dont see how web application developers can
become comformtable with OSGI concepts. At times it looks very fuzzy
even to me. I would be glad to contribute my two cents to this.
I dont know if this forum is appropriate for this discussion. Maybe
someone can throw light here...
Regards
Krishnan
On Thu, Jul 18, 2013 at 9:30 PM, <[email protected]
<mailto:[email protected]>> wrote:
Send osgi-dev mailing list submissions to
[email protected] <mailto:[email protected]>
To subscribe or unsubscribe via the World Wide Web, visit
https://mail.osgi.org/mailman/listinfo/osgi-dev
or, via email, send a message with subject or body 'help' to
[email protected]
<mailto:[email protected]>
You can reach the person managing the list at
[email protected] <mailto:[email protected]>
When replying, please edit your Subject line so it is more specific
than "Re: Contents of osgi-dev digest..."
Today's Topics:
1. 'OSGi is hard' (Scott Lewis)
----------------------------------------------------------------------
Message: 1
Date: Wed, 17 Jul 2013 12:47:26 -0700
From: Scott Lewis <[email protected]
<mailto:[email protected]>>
To: OSGi Developer Mail List <[email protected]
<mailto:[email protected]>>
Subject: [osgi-dev] 'OSGi is hard'
Message-ID: <[email protected]
<mailto:[email protected]>>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi Folks,
I would like to start a public discussion around the
comment/mis-perception that I've received several times from new OSGi
adopters: 'OSGi is hard'.
I know that there's a lot bound up in this comment (e.g.
complexity of
dependencies, modularity, tooling, unfamiliarity with key concepts,
etc). I would eventually like to counter this comment with
examples,
tutorials, tooling, reading, presentations, sequencing of all these
etc., etc...whatever is most effective...but before going
further...is
this the right forum for such a discussion? Or is there a
better/more
appropriate public OSGi forum?
Thanks,
Scott
------------------------------
_______________________________________________
OSGi Developer Mail List
[email protected] <mailto:[email protected]>
https://mail.osgi.org/mailman/listinfo/osgi-dev
End of osgi-dev Digest, Vol 81, Issue 6
***************************************
_______________________________________________
OSGi Developer Mail List
[email protected] <mailto:[email protected]>
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
