Date: Mon, 4 Jul 2016 18:37:25 +1000
From: j...@zeus.net.au
Subject: Re: Lotj - languages other than java
To: dev@river.apache.org
CC: si...@qcg.nl
Sim,
I'd like to see the project return to the days where we had a number of active
committers working together on the same goals.
I've got a project on github, where I've continued work that was controversial,
I'd like to bring this work back to the project if possible. It has some minor
breaking changes, but if backward compatibility was essential, it could be
accommodated.
Changes:
* New secure discovery providers, including https among others, including added
https protocol support for LookupLocator. However since firewalls may not
allow ipv6 multicast packets through, DNS-SD would be useful.
* IPv6 Discovery, global and local groups.
* Discovery V2 support added to LookupLocator's getRegistrar method.
* Updated encryption ciphers, removal of insecure ones.
* Deprecation of ProxyTrust et al.
* New default methods added to ServiceRegistrar to allow establising trust with
a service, prior to obtaining a service proxy, or Entry's (works with both
maven codebase provisioning and traditional codebase downloads).
* Input validation for untrusted serial data.
* META-INF/permissions.perm files list permissions required by codebase,
accessible from ClassLoader using mixin interface.
I recall you had a need for a SocketFactory in LookupLocator, at that time
LookupLocator only used discovery v1, which was deprecated, I'd like to include
a way to enable SocketFactory support in discovery V2. Note that LookupLocator
isn't serialized during discovery.
While the River codebase was a little difficult to understand at first, I find
it's quite easy to work with now.
While I'm a critic of Rivers flaws, addressing th em is straight forward, the
greatest challenge is convincing everyone that flaws exist, or that they need
addressing, there's still plenty of good stuff left worth saving.
Regards,
Peter.
Sent from my Samsung device.
Include original message
---- Original message ----
From: Peter<j...@zeus.net.au>
Sent: 01/07/2016 04:35:16 pm
To: dev@river.apache.org<dev@river.apache.org>
Subject: Re: Lotj - languages other than java
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 service.
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.
Thoughts?
Peter.
Sent from my Samsung device.
Include original message
---- Original message ----
From: Simon IJskes - QCG<si...@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.
