aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Ward <>
Subject Re: Aries RSA - support for long running calls
Date Mon, 25 Jul 2016 17:08:58 GMT
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!


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

View raw message