Hi Ervin
Thanks for your comments
On 30/05/16 12:05, erwindl0 wrote:
Hi Sergey,
My 2cts : service interfaces should be seen as strict contracts.
If someone makes an incompatible interface change, by definition the
intention is to "break" client expectations/implementations ;-)
Then it's up to the provider to decide whether to maintain old and new
versions operational, or whether to force all clients to adapt/upgrade.
Indeed, any service system which has proxy-based clients needs to deal
with it, though if clients are loosely typed then the service interface
changes are easier to manage.
This is independent from the topic of allowing to implement a
"micro-services" approach locally (and remotely) as OSGi does, or
whether to lock-in to one particular remoting protocol as REST is.
You are right, OSGI (and other mechanisms) can be all embracing hiding
the communication details. I was only commenting to an original remark
that OSGI is more effective than REST - but I guess I indeed took it
literally :-)
Thanks all
Sergey
cheers
erwin
Op 30/05/2016 om 12:46 schreef Sergey Beryozkin:
Hi Peter
On 30/05/16 11:38, Peter Kriens wrote:
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.
And then once an interface changes the client code gets broken. And to
avoid it people will go the super interfaces way. I'm sorry, I'm not
really after hijacking this thread with possibly off-topic remarks
:-), I'm only thinking that comparing OSGI vs REST is not very effective.
Thanks, Sergey
Kind regards,
Peter Kriens
On 30 mei 2016, at 11:07, Sergey Beryozkin <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>
<mailto:[email protected]>> 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:*[email protected]
<mailto:[email protected]>
<mailto:[email protected]>
[[email protected]
<mailto:[email protected]>
<mailto:[email protected]>] on behalf of Balázs Zsoldos
[[email protected]
<mailto:[email protected]><mailto:[email protected]>]
*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<[email protected] <mailto:[email protected]>
<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
<x-msg://206/redir.aspx?REF=7Pa9-nhPCVNkWvlfz3_2_jeN9zl_yHP-HM54HkgD3bOrUnlF_YLTCAFodHRwOi8vZ29vLmdsL2Zvcm1zL2x1NnpzV3U5NEdaWUN2Sk4y>
Thanks and regards,
*Balázs **Zsoldos*
_______________________________________________
OSGi Developer Mail List
[email protected]
<mailto:[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
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
