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.
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.
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, SergeyKind regards, Peter KriensOn 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 serviceoriented model truly allows you to decouple modules. It is hard work totake 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 isbecoming highly popular in a different form: micro-services. OSGi allowsyou 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, SergeyThis 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 providesa 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 inthe early 90’s. And I therefore still have hope that one day people willunderstand how much cleaner you can make your software systems by embracing that service model. Kind regards, Peter KriensOn 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 ashort 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
