Totally agree with Richard. OSGi and Jini are quite symbiotic, IMHO. One is focused on services in the JVM, and the other is focused on distributed services. If one knew about Jini before OSGi, which describes me, and one saw an OSGi tutorial, one might say to himself "Wow! That's Jini, but in a box!"
The Paremus Service Fabric has married the two and realized the best of both worlds! On 9/30/14, richard nicholson <[email protected]> wrote: > Dave > > > You may not be aware but the Paremus Service Fabric was been successfully > using Jini / OSGi successful since 2005 timeframe. I present on why the > technologies were such a good fit at one of the last jini meeting in Europe > around that timeframe. Sam Chance who hangs around these forums will > testify. > > These days Paremus and the Service Fabric have moved on - we have and > continue to heavily contributed to the OSGi Alliance remote service > architecture - etc. > > Best Wishes > > Richard > > > Richard Nicholson > Chief Executive Officer > > > > > > url: http://www.paremus.com > blog: http://adaptevolve.paremus.com > > > Direct: +44 (0) 122 445 1260 > Mobile: +44 (0) 797 105 1645 > Indirect: +44 (0) 207 936 9098 > Fax: +44 (0) 845 127 5999 > > > _________________________________ > Paremus Limited. Registered in England. Registration No. 4181472 > Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA > Postal Address: 107-111 Fleet Street, London, EC4A 2AB > > The information transmitted is intended only for the person(s) or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete the material from any > computer. > > On 30 Sep 2014, at 13:44, Dawid Loubser <[email protected]> wrote: > >> I think such attempts, in the past, have been fraught with failure. >> The primary reason, I surmise, is that River requires code downloading >> (and thus, a very different classloading scheme). >> >> I myself can foresee a very elegant marriage between the two >> technologies, where downloaded code is automatically >> installed as bundles in the OSGi runtime (and perhaps automatically >> removed, if necessary), but there are probably many >> subtle complexities. >> >> As a strong, production-time user of both technologies, I would >> absolutely love to see progress in making the two play together. >> >> How do you propose we move forward? >> >> regards, >> Dawid Loubser >> >> On 27/09/2014 11:12, bill pickup wrote: >>> >>> Greetings. >>> >>> OSGi, >>> being service driven, and thus a nontoo-distant cousin to >>> Jini/River, needs an extender to talk to same, methinks. Has anyone >>> in the community had fun in this department? >>> >>> Bill >>> >> >> > > -- Sam Chance 443-694-5293 (m)
