river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Lotj - languages other than java
Date Fri, 01 Jul 2016 06:35:16 GMT
Thanks Sim,

These are all good questions we need to consider.

I like the model of micro services where each service is responsible for implementing its
own back end persistence and state.  Do you consider a microservice to be web based? 

I have an implementation of discovery using multicast ipv6.  However for firewalls with limited
open ports such as https over ipv6, we have JERI https endpoints, but no discovery, DNS-SD
is a good discovery alternative waiting to be implemented.

For my own environment I will be adopting ipv6 , the global address space and autoconfiguration
solve many problems that users experience with ipv4 today.

I admit the locked down api caused me frustration, but I think it's clear now that we need
a process for managing api evolution.  

Complexity - The proxy preparation api tries to determine trust after downloading untrusted
code and deserialization of unverified data.  As gadget attacks demonstrate, too little too
late at great complexity.  This was an attempt to bolt security onto the existing lookup

JERI is good, method constraints are good, proxy trust is obsolete.  River's current ssl
and https JERI endpoints need to be brought up to date as they're no longer secure.  I've
already done this work externally, it can be donated when appropriate for the project.

If we address security issues, we can provide a secure alternative to RMI.  Oracle has chosen
'whack a mole' security for Serialization, rather than address some fundamental design flaws
with ObjectInputStream, for this reason, authentication of the source must occur prior to
accepting serial data.  Despite common belief, white listing isn't a completely secure solution
and adds conplexity as it's too fine grained.

For multi language support, this would limit the type system, but then, there's a lot that
can be done with strings, primitive types and byte arrays.  This doesn't have to limit java
service types, I think language support should be something determined during lookup, so we
don't limit the type systems of more powerful languages to primitives.

Looking at most Entry's used for lookup, most fields are strings and integers.  If you look
at the way lookup searches are implemented, an entry is represented by a string name and each
field is a tuple name value pair.

I think a ground up redesign of the lookup service, would address language compatibility as
well as complexity and security.

In other words, recognise the need for a lookup & registration protocol, as well as discovery,
after that, the service & client should be able to negotiate  whatever rpc protocol they
have in common and to do that, we'll also need a connection negotiation protocol.  We could
write specifications for these protocols.  This way we could allow any language/ platform
to register and provide services.  The code for lookup would not be downloaded as Reggie
is now, it would be protocol, rather than proxy based.  This would also fit well with IoT.

Meanwhile we can still support existing java based services.



Sent from my Samsung device.
  Include original message
---- Original message ----
From: Simon IJskes - QCG <simon@qcg.nl>
Sent: 30/06/2016 06:22:30 pm
To: dev@river.apache.org
Subject: Re: Lotj - languages other than java

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. 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message