You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@river.apache.org by bill pickup <bi...@yahoo.com.INVALID> on 2014/09/27 09:12:11 UTC
OSGi, of that ilk...
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
Re: OSGi, of that ilk...
Posted by bill pickup <bi...@yahoo.com.INVALID>.
Greetings again,
Good to know that service-driven fusion is alive and kicking!
For my part, I propose a move backward to go forward, & work the ProSyst org.osgi.service.jini spec. However, Peter is correct in directing a formal solution at a later date, as the two frameworks should be friends.
The Felix solution should take a few days more, it cheats, of course - it's not what it is, but that it is, pro tem.
Bill
On Tuesday, September 30, 2014 1:44 PM, Dawid Loubser <da...@travellinck.com> 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
>
Re: OSGi, of that ilk...
Posted by Sam Chance <sg...@gmail.com>.
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 <ri...@paremus.com> 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 <da...@travellinck.com> 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)
Re: OSGi, of that ilk...
Posted by richard nicholson <ri...@paremus.com>.
On 30 Sep 2014, at 14:00, Dawid Loubser <da...@travellinck.com> wrote:
> Hi Richard,
>
> Thanks for that. Why would you say nobody paid attention? (obviously it wasn't very successful in the market, otherwise I image you wouldn't have "moved on"...).
Dave
If you are interest in what we've been up to - ping me off list.
Regarding why it didn't catch. Not really sure. Part of the problem is I think Jini and OSGi concepts were just too far ahead of the curve. Combine them and few people understood what was going on. Also politics between the big vendors.
Today is a little different. Distributed Data Centre platforms are becoming "fashionable" - watch the Mesosphere and Kubernetes propaganda :) Take "ZooKeeper" - weld a batch deployment solution around it deploy Docker images. Job Done! Along side this we also have the Micro Services "trend".
All somewhat perplexing if you've been using Jini or distributed OSGi for a number of years.
Of course one of the problems both OSGi and Jini have today is that Java is not "hip". Google, FaceBook and Twitter don't use it. But hang on - the vast majority of "real business" out there do continue to use Java!
I've ranted enough :)
Re: OSGi, of that ilk...
Posted by Dawid Loubser <da...@travellinck.com>.
Hi Richard,
Thanks for that. Why would you say nobody paid attention? (obviously it
wasn't very successful in the market, otherwise I image you wouldn't
have "moved on"...).
I've read about the Service Fabric (product?) some years ago, could
never really find any technical information.
kind regards,
Dawid
On 30/09/2014 16:57, richard nicholson 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 <dawid@travellinck.com
> <ma...@travellinck.com>> 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
>>>
>>
>>
>
Re: OSGi, of that ilk...
Posted by richard nicholson <ri...@paremus.com>.
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 <da...@travellinck.com> 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
>>
>
>
Re: OSGi, of that ilk...
Posted by Dawid Loubser <da...@travellinck.com>.
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
>