> REST or indeed other forms of designing the way the remote client and servers > communicate with each other is IMHO quite orthogonal to what OSGI is about. I think you take a too literal view in this case.
Both REST and OSGi services are about loosely connecting software blocks using
an explicit API and end-point. This architectural pattern is the successor of
object oriented technology and imho the biggest value. The advantage of OSGi
over REST is then that with OSGi there is no overhead so you can leverage this
powerful pattern for even the smallest of problems.
A good proof-point of this pattern is the ease in which an OSGi service can be
mapped to REST without having to know anything about REST using Distributed
OSGi or, for example, OSGi enRoute REST support.
Kind regards,
Peter Kriens
> On 30 mei 2016, at 11:07, Sergey Beryozkin <sberyoz...@gmail.com> wrote:
>
> Hi Peter
>
> I only have one comment,
> On 23/05/16 14:03, Peter Kriens wrote:
>> I think I agree with your analysis, despite the grains of salt. I find
>> the true innovation of OSGi the service model. To me, the service
>> oriented model truly allows you to decouple modules. It is hard work to
>> take an existing application with all its hairball characteristics and
>> turn it into a clean architecture that the OSGi service model requires
>> as well enforces. Trying to adapt the old patterns of class loading
>> hacks and overuse of statics (global variables!!) to a modular world
>> requires an effort. (As Jigsaw will demonstrate to non-believers.)
>>
>> The interesting things is that core aspect of this service model is
>> becoming highly popular in a different form: micro-services. OSGi allows
>> you to reap the benefits of this architectural design primitive with a
>> MUCH lower cost (both performance and developer cost) than the rather
>> expensive REST services that are common outside OSGi.
>
> REST or indeed other forms of designing the way the remote client and servers
> communicate with each other is IMHO quite orthogonal to what OSGI is about.
> DOSGI would be the closest one here and indeed one can use arguably expensive
> HTTP calls or more effective RMI/etc calls in between OSGI consumers and
> services, but IMHO it is a rather different conversation which communication
> style between remote parties works best :-)
>
> Cheers, Sergey
>> This allows you to
>> reuse this design primitive in even the lowest layer of your
>> architecture, creating many synergies. It never ceases to amaze me how
>> little code you need to write significant functionality in a properly
>> setup OSGi system. Configuration Admin, Declarative services, Remote
>> Service Admin, Event Admin, and many other services are vertical
>> building blocks that can be used in an amazing number of applications.
>>
>> That said, also the Capability model we’ve added over the years provides
>> a software management model that I think is highly under-appreciated.
>>
>> I’ve sold objects from the early 80’s until they became solidly
>> mainstream around 2000. I know I’ve tried to sell the service model
>> since that time because it addresses some scalability problems in
>> objects. (Transitive dependencies.) Its been a long time but I still
>> believe that OSGi services are a similar innovation as objects were in
>> the early 90’s. And I therefore still have hope that one day people will
>> understand how much cleaner you can make your software systems by
>> embracing that service model.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>>
>>> On 23 mei 2016, at 13:34, Craig Phillips <lcphill...@praxiseng.com
>>> <mailto:lcphill...@praxiseng.com <mailto:lcphill...@praxiseng.com>>> wrote:
>>>
>>>
>>> My response below does not necessarily apply to myself, but is what I
>>> regard the reality of the situation (which I deem unfortunate):
>>>
>>> With OSGi, you have to be "all in" ;
>>>
>>> I would be nice if OSGi were to have been built in to the Java
>>> language from the very beginning. If that were the case, I would not
>>> be making this post / reply.
>>>
>>> As for myself, I have worked with the "boot delegation" aspects to
>>> allow OSGi-based code and non-OSGi-based code to inter-operate
>>> seamlessly. Unfortunately, the task of having OSGi and non-OSGi
>>> code/componentry inter-operate is the very thing that causes OSGi to
>>> be dropped as a viable framework in a variety of projects. Again, I
>>> emphasize the word "unfortunate" as I regard OSGi as one of my
>>> favorite technologies.
>>>
>>> On the other hand, I have seen -- both with OSGi and just about
>>> anything else -- technologies misused/abused to the point of complete
>>> and utter ruin (I can name a few OSGi based efforts where they were
>>> "all in", but created a behemoth [in particular, misusing/abusing
>>> Karaf] that was such a spaghetti-tangle-rubber-band-ball of bundles
>>> that it not only fell apart, but created a bad not for the technology
>>> -- OSGi in these cases).
>>>
>>> So, even though I can make OSGi code and non-OSGi code work in
>>> "harmony", the reality of the situation, over at least a decade of
>>> attempted usage of the technology, is that you have to be "all in."
>>>
>>> How ever many grains of salt...
>>>
>>>
>>> ------------------------------------------------------------------------
>>> *From:*osgi-dev-boun...@mail.osgi.org
>>> <mailto:osgi-dev-boun...@mail.osgi.org>
>>> <mailto:osgi-dev-boun...@mail.osgi.org
>>> <mailto:osgi-dev-boun...@mail.osgi.org>>
>>> [osgi-dev-boun...@mail.osgi.org <mailto:osgi-dev-boun...@mail.osgi.org>
>>> <mailto:osgi-dev-boun...@mail.osgi.org
>>> <mailto:osgi-dev-boun...@mail.osgi.org>>] on behalf of Balázs Zsoldos
>>> [balazs.zsol...@everit.biz <mailto:balazs.zsol...@everit.biz>
>>> <mailto:balazs.zsol...@everit.biz <mailto:balazs.zsol...@everit.biz>>]
>>> *Sent:*Monday, May 23, 2016 3:59 AM
>>> *To:*OSGi Developer Mail List
>>> *Subject:*Re: [osgi-dev] How do you use OSGi?
>>>
>>> Hi,
>>>
>>> 33 answers arrived till now. I would like to thank you. I will write a
>>> short summary of responses here, soon.
>>>
>>> Kind regards,
>>> *Balázs **Zsoldos*
>>> *
>>> *
>>>
>>>
>>> On Thu, May 19, 2016 at 6:09 PM, Balázs
>>> Zsoldos<balazs.zsol...@everit.biz <mailto:balazs.zsol...@everit.biz>
>>> <x-msg://206/redir.aspx?REF=lSi0XUjj7PCbKz6K6Pa_IFpZGax_jRZ8klFUCdwQet2rUnlF_YLTCAFtYWlsdG86YmFsYXpzLnpzb2xkb3NAZXZlcml0LmJpeg
>>>
>>> <x-msg://206/redir.aspx?REF=lSi0XUjj7PCbKz6K6Pa_IFpZGax_jRZ8klFUCdwQet2rUnlF_YLTCAFtYWlsdG86YmFsYXpzLnpzb2xkb3NAZXZlcml0LmJpeg>..>>wrote:
>>>
>>> Hi,
>>>
>>> I would like to ask you to fill our short survey. We develop
>>> server-side applications based on OSGi and we try to release all
>>> reusable modules and tools that we implemented for ourselves as
>>> OpenSource modules. However, we would like to know what others use
>>> and need, so we can design our solutions in the way that it might
>>> help your work, too.
>>>
>>> The form I created is here: http://goo.gl/forms/lu6zsWu94GZYCvJN2
>>> <http://goo.gl/forms/lu6zsWu94GZYCvJN2>
>>>
>>> <x-msg://206/redir.aspx?REF=7Pa9-nhPCVNkWvlfz3_2_jeN9zl_yHP-HM54HkgD3bOrUnlF_YLTCAFodHRwOi8vZ29vLmdsL2Zvcm1zL2x1NnpzV3U5NEdaWUN2Sk4y
>>>
>>> <x-msg://206/redir.aspx?REF=7Pa9-nhPCVNkWvlfz3_2_jeN9zl_yHP-HM54HkgD3bOrUnlF_YLTCAFodHRwOi8vZ29vLmdsL2Zvcm1zL2x1NnpzV3U5NEdaWUN2Sk4y>>
>>>
>>> Thanks and regards,
>>> *Balázs **Zsoldos*
>>>
>>>
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>>> <mailto:osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>>
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>>
>>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>>
>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
