On 5/30/2016 4:05 AM, erwindl0 wrote:
Hi Sergey,My 2cts : service interfaces should be seen as strict contracts.
yes
If someone makes an incompatible interface change, by definition the intention is to "break" client expectations/implementations ;-)
I agree with you. I think your point about breaking the client also highlights the advantages of dynamically creating proxies via RSA: service interfaces/contracts can be versioned, use semantic versioning for managing contracts, and multiple versions of a contract can be made available. Via the initial contract+semantic versions, the client can have *clearly and accurately expressed* expectations as the contract changes.
When I say 'dynamically creating proxies' what I mean is the ability not just to create the proxy at runtime, but to also easily select/extend/replace/modify the distribution provider so that proxy creation can be easily customized. This also allows/enables/clear/complete separation of the service contract from the transport (e.g. Jax-RS vs home-grown REST, vs MQTT, vs websockets, etc) [1].
In my view this is a huge advantage for OSGi RSA over 'raw REST' clients (clients written directly to some REST API)...along with dynamics support for (e.g.) handling network failures [2]. One good thing is that raw REST and Remote Services can easily coexist by building a custom client-only distribution provider for one's existing REST service [3] or by using impls of standards like Jax-RS [4].
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.
yeah. Last I used it, a popular commercial service provider had 30+ distinct versions of their rest services, with separate docs/examples for each, all being maintained (at least that was what they said). Not that using remote services would make the difficulty of that go away, but it could provide some help.
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.
Avoidance of lockin to one protocol (one flavor/impl of REST or REST vs. AMQP, MQTT, etc) is, it seems to me, a big part of what RSA standardization is about [1].
Scott [1] https://dzone.com/articles/transport-independent-remote-services [2] https://dzone.com/articles/remote-services-over-unreliable-networks [3] https://github.com/ECF/Geonames[4] http://wiki.eclipse.org/Tutorial:_Exposing_a_Jax_REST_service_as_an_OSGi_Remote_Service
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 blocksusing 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 findthe true innovation of OSGi the service model. To me, the serviceoriented 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 requiresas 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 allows you to reap the benefits of this architectural design primitive with aMUCH 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 yourarchitecture, creating many synergies. It never ceases to amaze me howlittle 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 verticalbuilding 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 stillbelieve 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 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 Iregard 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 aboutanything else -- technologies misused/abused to the point of completeand 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 bundlesthat 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 asOpenSource modules. However, we would like to know what others useand 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
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
