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.re...@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 <da...@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 <j...@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 <da...@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. 
>>  >>> 
>>  >>> 
>>  >> 
>>  >> 
>>  >> 
>>
>>
>>
>
>
>


Reply via email to