On 1 aug. 2013, at 22:47, Scott Lewis wrote:
> 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.
I don't intend to ... just try to rally the troops in one direction.
> 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.
I think it is clear, and which is my main point, that most developers do not
understand services, let alone dynamics. (And I think dynamic updates are not
that relevant in production, too much chance for things to go wrong; in
development it is great and does create more robust code that way).
> 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.
Wizards might help, and they're planned in bndtools, but the key thing is to
get a body of bundles that really leverage this model so people 'want' to use
services.
> 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.
Yup, OSGi µservices are where objects were in the early '90s. People in
mainstream had heard of it but thought it unnecessary overhead. And lets face
it, when I look at a look of open source code that struggles with
ServiceTracker and ServiceListener than I would probably hate it as well.
µServices did not grow up until we had the annotations.
> 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.
I think nobody disagrees with this ... However, I think you attack it from the
wrong direction. We need good OSGi bundles for many of the open source projects
that leverage OSGi, not abstract themselves away from it and thereby
duplicating enormous amounts of code. Too many bundles are warmed up JEE
projects. If we get more highly cohesive bundles using µservices providing
queuing, batching, security, etc. instead of the too often horrendously coupled
monsters life would be a lot easier ... And making a highly cohesive bundle is
usually surprising little work in OSGi. OSGi currently lacks those really good
highly cohesive, minimally coupled, building blocks. I do believe we are more
and more getting there though.
> 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.
We are working hard in bnd(tools) to make this a lot easier and we've come a
long way. However, there is a lot of work left. Big problem here is of course
funding for this work, I do not think I ever figure out this open source
'business' model :-(
> 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.
I think I agree with your observations of problems on the ground; it is my
primary goal to work on this and I will of course get the community to help out.
Thanks, kind regards,
Peter Kriens
>
> 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]> wrote:
>>> Send osgi-dev mailing list submissions to
>>> [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]
>>>
>>> You can reach the person managing the list at
>>> [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]>
>>> To: OSGi Developer Mail List <[email protected]>
>>> Subject: [osgi-dev] 'OSGi is hard'
>>> Message-ID: <[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]
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>
>>> End of osgi-dev Digest, Vol 81, Issue 6
>>> ***************************************
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> 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
