You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter <ji...@zeus.net.au> on 2016/06/30 03:37:55 UTC
Lotj - languages other than java
Currently with River, you need java to participate. Other languages can provide services, but you need a jvm to participate.
Most of discovery is language agnostic, so any language can participate in discovery.
The major limitation for other languages is the lookup service. Security issues and complexity also relate to the lookup service.
My thoughts are that a lookup service that performs search and registration, but provides a language independent and secure means of contacting service providers would be beneficial.
Anyone interested in discussing further?
Regards,
Peter.
Sent from my Samsung device.
Re: Lotj - languages other than java
Posted by Simon IJskes - QCG <si...@qcg.nl>.
If you solve the 'barrier' of the service discovery, do you also want to
provide universal access to the java services in the form of microservices?
It is doable to take any 'more used' service discovery solution and use
this as the river discovery. To introduce a level of abstraction with
the same primitives as the current river discovery mechanism offers.
River would then have adapted a more common discovery mechanism.
Next thing that we should decide, is how far do we go into universality.
I see univeral type systems, different serialisation plugins on the horizon.
The biggest showstopper for me was the API compatibility. In order to
make any progress we need a more agile process for modifing the API.
If we leave compatibility behind us, we could ask our selfs, what
benefit are we providing for the users? What can we introduce that does
not duplicate what is already in the market. For a java developer, i
think there is no need to convince, they can see benefits in just having
a java API to program against. We need to think about the environment
where java receives a lot of 'non-love', how we can create a 'whow, java
isn't all that bad, look at that easy solution' experience.
I think that river lost the spot it could have, as a java only solution
to JSON, XMLRPC, SOAP, etc libraries for java. From a helicopter view,
what does it do? Whe provide secure RPC, with discovery and scaling. And
we make it hard to use.
G. Simon
On 30-06-16 05:37, Peter wrote:
> Currently with River, you need java to participate. Other languages can provide services, but you need a jvm to participate.
>
> Most of discovery is language agnostic, so any language can participate in discovery.
>
> The major limitation for other languages is the lookup service. Security issues and complexity also relate to the lookup service.
>
> My thoughts are that a lookup service that performs search and registration, but provides a language independent and secure means of contacting service providers would be beneficial.
>
> Anyone interested in discussing further?
>
> Regards,
>
> Peter.
>
>
> Sent from my Samsung device.
>
>