Re: Exporters for other RPC frameworks

[Peter]

Cool.

Cheers,

Peter.

On 7/09/2016 9:18 PM, Dawid Loubser wrote:

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.
  >>>
  >>>
  >>
  >>
  >>