river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dawid Loubser <da...@travellinck.com>
Subject Re: Exporters for other RPC frameworks
Date Wed, 07 Sep 2016 11:18:18 GMT
I'm partially leaning to re-implementation also.

I have not had a chance to look at the code again, but I think it was a
little bit tightly coupled to Rio's (service associations) features,
instead of pure Jini.
This was an accelerator for me at the time.

I'm very sure I could use the lessons learnt at the time to re-implement
it in a couple of days of spare time, with the additional benefit of 4
years extra life experience :-)

warm regards,
Dawid


On 07/09/2016 07:42, Peter wrote:
>  
>  
> A few quick thoughts:
>
> 1.  An existing implementation, even if hurriedly implemented is a good place to start
understanding the interop gap we're attempting to bridge.
> 2. As Dennis has suggested, we may decide to implement from scratch, if either the original
implementation cannot be donated (for whatever reason) or we learn from the implementation
and want to make a second attempt to produce something we're happy supporting long term.
> 3. Exporting spring services sounds good too.
>
> Good to see people positively engaged.
>
> Thanks & Cheers,
>
> Peter.
>
>
> Sent from my Samsung device.
>  
>   Include original message
> ---- Original message ----
> From: Dennis Reedy <dennis.reedy@gmail.com>
> Sent: 06/09/2016 11:25:32 pm
> To: dev@river.apache.org <dev@river.apache.org>
> Subject: Re: Exporters for other RPC frameworks
>
> Hi Dawid, 
>
> I remember chatting about this when you did the work, I think it would be 
> great if we could even do it from scratch as a side-project. As an aside, 
> we can also consider things like exporting Spring services as River 
> services: 
>
> http://docs.spring.io/autorepo/docs/spring/3.2.x/spring-framework-reference/html/remoting.html

>
> Somewhat different angle on this, but can illustrate that River is part of 
> s larger eco-system. 
>
> Regards 
>
> Dennis 
>
> On Tue, Sep 6, 2016 at 8:48 AM, Dawid Loubser <dawid@travellinck.com> wrote: 
>
>>  I'm going to have a chat to the client (I don't do that much work for 
>>  them anymore). 
>>  And I will have to dust off what I did, and probably generalise it - it 
>>  was for very specific circumstances, developed in a hurry, but it's been 
>>  running on a couple of services in production for 4 years, so the basics 
>>  hold up :-) 
>>
>>  To be honest, I haven't looked at the work you guys have been doing on 
>>  River 3 - but that would be a good starting point. 
>>
>>  What I did, was basically to write a service (which wraps a web 
>>  container), which you could configure to look for other services 
>>  (usually by type, but perhaps using other service properties as 
>>  selection criteria). It would generate "smart" proxies (which track, and 
>>  delegate calls to, a normal Jini service) and expose them as your choice 
>>  of web service style (SOAP, REST) and manage them in the embedded web 
>>  container. 
>>
>>  chat soon - 
>>  Dawid 
>>
>>
>>  On 06/09/2016 13:32, Bryan Thompson wrote: 
>>  > +1  I see exposing Jini / River more broadly as key. 
>>  > 
>>  > Bryan 
>>  > 
>>  > On Tue, Sep 6, 2016 at 4:18 AM, Peter <jini@zeus.net.au> wrote: 
>>  > 
>>  >> Thanks Dawid, talk about surpassing expectations. 
>>  >> 
>>  >> That's great news if you're able to donate your webservices works to 
>>  >> River, I agree, it will expose River to a potentially much wider 
>>  audience 
>>  >> with needs that River is presently unable to cater for, and may ignite

>>  >> greater interest as a result. 
>>  >> 
>>  >> Regards, 
>>  >> 
>>  >> Peter. 
>>  >> 
>>  >> Sent from my Samsung device. 
>>  >> 
>>  >>   Include original message 
>>  >> ---- Original message ---- 
>>  >> From: Dawid Loubser <dawid@travellinck.com> 
>>  >> Sent: 06/09/2016 07:37:26 pm 
>>  >> To: dev@river.apache.org 
>>  >> Subject: Re: Exporters for other RPC frameworks 
>>  >> 
>>  >> In 2012, I wrote infrastructure to export Jini services (running in 
>>  >> Dennis Reedy's Rio service provisioning infrastructure) as either 
>>  >> SOAP/XML web services, or RESTful JSON services, or - uniquely I believe

>>  >> - both at the same time without having to write adaptors or different 
>>  >> interfaces. 
>>  >> 
>>  >> I remember having to write some tricky smart-proxy generation code (I 
>>  >> used ASM at the time) in order to end up with proxies which JAX-WS and

>>  >> JAX-RS would be happy to expose (in an embedded Grizzly web container)
- 
>>  >> and dealing smoothly with services coming, going, and moving. 
>>  >> 
>>  >> If anybody would be interested in my work in this space - even though I

>>  >> did it commercially, I believe the client will be open to me 
>>  >> open-sourcing it. 
>>  >> 
>>  >> But basically, I think there is a strong need to expose Jini services 
>>  >> "at the edges" to common protocols like SOAP or RESTful JSON/HTTP. I 
>>  >> couldn't find anything, which is why I wrote my own. 
>>  >> 
>>  >> warm regards, 
>>  >> Dawid Loubser 
>>  >> 
>>  >> 
>>  >> On 06/09/2016 11:12, Peter Firmstone wrote: 
>>  >>> Anyone interested in Exporters for other RPC Frameworks? 
>>  >>> 
>>  >>> If so which and why? 
>>  >>> 
>>  >>> Pete. 
>>  >>> 
>>  >>> Sent from my Samsung device. 
>>  >>> 
>>  >>> 
>>  >> 
>>  >> 
>>  >> 
>>
>>
>>
>
>
>



Mime
View raw message