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