aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: Aries RSA - support for long running calls
Date Tue, 26 Jul 2016 11:37:41 GMT
We should keep the 1.x version on Java 7. For the next major version I 
can imagine to switch to Java 8 but we should
discuss that as a separate discussion thread so all of the Aries 
community is aware of it.


On 26.07.2016 13:04, Johannes Utzig wrote:
> Hi Tim,
> I understand your reasoning, thanks for the clearification.
> Also no problem about the name, no offense taken :-)
> @Christian
> Would the switch to target java 1.8 be OK for aries-rsa?
> Also, while we are at it, I am currently working on another feature that
> might be interesting for aries. I'd like to support Input/OutputStreams as
> parameters and return values. A prototype is done, but it still needs some
> more work.
> I'd like to contribute that as well if you want it.
> Best regards,
> Johannes
> 2016-07-25 19:08 GMT+02:00 Timothy Ward <>:
>> Apologies - this was meant to be directed at Johnnes. Juggling email on a
>> phone when you're on a canal boat in Wales can be challenging!
>> Tim
>> Sent from my iPhone
>>> On 25 Jul 2016, at 16:35, Timothy Ward <> wrote:
>>> Hi Erwin,
>>> I do appreciate your point of view, but the purpose of a good
>> specification should really be to specify the bare minimum necessary to
>> solve the client's problem(s)
>>> In the case of RSA the problem being solved is "how do I hook discovery
>> layer A into distribution provider B, and manage which services are
>> imported/exported?". As written the spec allows you to take pieces of ECF,
>> Amdatu and Aries RSA and use them all together, which is really valuable.
>>> Pluggable transport layers are a different issue, and really only affect
>> people writing RSA implementations, not people using remote services. As a
>> result there has to be a really compelling reason to specify that. In this
>> case Open Source is doing a good job of providing plugability, and the fact
>> that the specification does not require you to support transport plugins
>> means that you can write smaller distribution provider implementations for
>> embedded devices.
>>> This ethos is one reason why I think it *is* important to specify the
>> Async behaviour. As someone using remote services it is important that I
>> know what return types are supported, and how I can recognise RSA
>> implementations that support Async behaviours.
>>> I hope this helps,
>>> Tim
>>> Sent from my iPhone
>>>> On 25 Jul 2016, at 15:38, Johannes Utzig <> wrote:
>>>> Hi Tim,
>>>> please see answer below...
>>>>> This is already part of the specification. The plugin interface is
>> called
>>>>> RemoteServiceAdmin, and it has been widely adopted. Some projects like
>> ECF
>>>>> and Aries have created lower level Plug points, but that shouldn't be
>>>>> requirement for all RSA providers as it forces them to be bigger and
>> more
>>>>> complex.
>>>> I can accept that answer, but do not fully agree with it. Of course I
>> know
>>>> RemoteServiceAdmin, but most implementations I have seen split the
>>>> responsibilities into a RemoteServiceAdmin and a pluggable transport
>> layer.
>>>> The different transport layers can be agnostic of the RSA
>> implementation so
>>>> all the aries-rsa transports could easily work in ECF as well, the only
>>>> reason why that doesn't work is the lack of a standard interface to
>> make a
>>>> transport known to the RSA.
>>>> When I started working on the 'fastbin' transport of aries-rsa I've also
>>>> been in contact with Scott Lewis from ECF, and with his help made the
>> same
>>>> transport available in ECF. 99% of the code can be shared, but the entry
>>>> points need to be rewritten to work with either ECF, or aries-rsa.
>>>> Having an interface like this in the spec would allow the user to e.g.
>> use
>>>> the RSA of ECF, the topology manager from aries-rsa and the transport
>> layer
>>>> of CXF.

Christian Schneider

Open Source Architect

View raw message