You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Johannes Utzig <ju...@gmail.com> on 2016/07/22 13:00:58 UTC
Aries RSA - support for long running calls
Hi,
as a quick introduction, my name is Johannes Utzig and I work for the
SEEBURGER AG.
We have been involved with aries-rsa since the beginning and maintain a
fork of it on github. We are primarily interested in the fastbin transport
and I usually try to create pull requests for enhancements/fixes we're
doing that might be useful to have upstream.
I am currently working on adding support for long running remote calls
(several minutes/hours) to fastbin.
If possible, I would like to contribute that feature upstream if there is
an interest for it.
The idea is to allow Future and CompletableFuture as return values of
remote methods.
If such a return value is detected, the invocation strategy switches to
async and the client receives an implementation of (Completable)Future that
will be filled as soon as the call result becomes available.
Example Provider:
public CompletableFuture<String> helloAsync() {
return CompletableFuture.supplyAsync(() -> "Hello");
}
Example Consumer:
exampleService.helloAsync().get(5, TimeUnit.MINUTES));
A few questions about that:
-Does someone maybe have a better idea on how to support long running/async
calls?
-would you be interested in that contribution?
-My implementation requires java 8 features like CompletableFuture but rsa
is currently building with 1.7. Would it be OK to move to java 8 as a
target version?
Best regards,
Johannes
Re: Aries RSA - support for long running calls
Posted by Johannes Utzig <ju...@gmail.com>.
I completely agree, which is why I left the support for Future and
CompletableFuture in the code and added Promise as a third option.
The first version can be found here:
https://github.com/seeburger-ag/aries-rsa/commit/6c28ee11b09c3b2109a4ac8f0e479c0d9a7d50b5
The commit is for our modified version of aries-rsa, but I will rebase it
properly to master if you want the contribution and once it is clear how it
should be designed.
To add support for e.g. rxjava one would write a strategy like this one:
https://github.com/seeburger-ag/aries-rsa/blob/topic/async-calls/provider/fastbin/src/main/java/org/apache/aries/rsa/provider/fastbin/tcp/AsyncPromiseInvocationStrategy.java
And then add it to this enum:
https://github.com/seeburger-ag/aries-rsa/blob/topic/async-calls/provider/fastbin/src/main/java/org/apache/aries/rsa/provider/fastbin/tcp/InvocationType.java
Best regards,
Johannes
Re: Aries RSA - support for long running calls
Posted by Christian Schneider <ch...@die-schneider.net>.
OSGi promises are a good idea. I did not think of them.
It probably makes sense though to also implement another way for async
execution as I am not sure if developers will adopt them in large scale
as they are an OSGi standard.
I think in the long run most people will opt either for the java
standard way or an open source impl like rxjava that is available
broadly and simply popular. As we can not predict what happens it makes
sense that we implement more than one way.
Christian
On 24.07.2016 15:18, Timothy Ward wrote:
> Hi Christian, Johannes,
>
> I have to ask, why would you not use OSGi Promises for this? Representing Long running and/or asynchronous tasks is exactly what OSGi Promises were designed for. They're also much simpler than CompletableFuture (which is a horrible API to try to use), and tie in to the rest of the OSGi ecosystem (for example the current Asynchronous Services spec, the proposed Push Stream spec and the next Log Service updates)
>
> There is already an RSA 1.2 update needed in the next OSGi specification release - I would be happy to work with you to define a remote services config type for asynchronous remote service support. That way this behaviour would also be portable between implementations.
>
> I think that having a standard here is important, because there are actually a lot of different RSA implementations in the wild, and if they all do things completely differently then it will be confusing to users and result in the feature not being used. It will also help to ensure that the different providers hosted by single projects (Aries RSA and ECF both have multiple options here) are self-consistent.
>
> Best Regards,
>
> Tim Ward
>
> OSGi IoT EG Chair
>
> Sent from my iPhone
>
>> On 22 Jul 2016, at 16:11, Christian Schneider <ch...@die-schneider.net> wrote:
>>
>> Yes.. I just looked into CompleteableFuture. This looks quite good already.
>> So hopefully we get some more feedback on how to proceed.
>>
>> Christian
>>
>> 2016-07-22 16:25 GMT+02:00 Johannes Utzig <ju...@gmail.com>:
>>
>>> Hi Christian,
>>>
>>> I have not stumbled upon this yet, but on first glance it looks very
>>> similar to what you can do with a CompletableFuture:
>>>
>>> testService.helloAsync().thenAccept(result -> System.out.println(result));
>>>
>>> Looks like the main difference is that Observable allows multiple items
>>> that become available over time.
>>>
>>> But part of my change was a bit of a cleanup in the handling of the
>>> InvocationStrategy which should make it easier to add support for
>>> additional invocation strategies (like an Observable based).
>>> As for the initial implementation I would prefer to keep it free of
>>> additional mandatory dependencies.
>>>
>>> Johannes
>>>
>>> 2016-07-22 15:38 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
>>>
>>>> Hi Johannes,
>>>>
>>>> welcome to the Aries community and thanks for the pull requests and
>>> issues
>>>> you already provided.
>>>>
>>>> Long running calls could make a lot of sense but I am not sure if Future
>>>> is still the way to go.
>>>> It seems people are using Observable now (
>>>> http://reactivex.io/documentation/observable.html) to be able to use
>>>> rxjava (https://github.com/ReactiveX/RxJava).
>>>>
>>>> So I think it might make sense to directly provide this. I am not
>>>> experienced in rxjava but maybe we got some people here who know that
>>>> better.
>>>>
>>>> Christian
>>>>
>>>>
>>>>> On 22.07.2016 15:00, Johannes Utzig wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> as a quick introduction, my name is Johannes Utzig and I work for the
>>>>> SEEBURGER AG.
>>>>> We have been involved with aries-rsa since the beginning and maintain a
>>>>> fork of it on github. We are primarily interested in the fastbin
>>> transport
>>>>> and I usually try to create pull requests for enhancements/fixes we're
>>>>> doing that might be useful to have upstream.
>>>>>
>>>>> I am currently working on adding support for long running remote calls
>>>>> (several minutes/hours) to fastbin.
>>>>> If possible, I would like to contribute that feature upstream if there
>>> is
>>>>> an interest for it.
>>>>> The idea is to allow Future and CompletableFuture as return values of
>>>>> remote methods.
>>>>> If such a return value is detected, the invocation strategy switches to
>>>>> async and the client receives an implementation of (Completable)Future
>>>>> that
>>>>> will be filled as soon as the call result becomes available.
>>>>>
>>>>> Example Provider:
>>>>>
>>>>> public CompletableFuture<String> helloAsync() {
>>>>> return CompletableFuture.supplyAsync(() -> "Hello");
>>>>> }
>>>>>
>>>>> Example Consumer:
>>>>>
>>>>> exampleService.helloAsync().get(5, TimeUnit.MINUTES));
>>>>>
>>>>> A few questions about that:
>>>>>
>>>>> -Does someone maybe have a better idea on how to support long
>>>>> running/async
>>>>> calls?
>>>>>
>>>>> -would you be interested in that contribution?
>>>>>
>>>>> -My implementation requires java 8 features like CompletableFuture but
>>> rsa
>>>>> is currently building with 1.7. Would it be OK to move to java 8 as a
>>>>> target version?
>>>>>
>>>>> Best regards,
>>>>> Johannes
>>>> --
>>>> Christian Schneider
>>>> http://www.liquid-reality.de
>>>>
>>>> Open Source Architect
>>>> http://www.talend.com
>>
>>
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
>>
>> Open Source Architect
>> http://www.talend.com
>> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Aries RSA - support for long running calls
Posted by Christian Schneider <ch...@die-schneider.net>.
On 01.08.2016 12:05, Johannes Utzig wrote:
> 2016-08-01 10:50 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
>
>
>> Do you think we can even define and implement this in a transport agnostic
>> way or do we need to support async per transport?
>>
>> Christian
>>
>>
> I don't see how this could be done with the current architecture as the
> whole invocation and communication part is the sole responsibility of the
> distribution provider.
> To support async calls the distribution provider needs to detect the
> arguments/return values and replace Future/Promise and so on with custom
> instances. All the RSA currently sees on the client side is a proxy object
> and then it's already too late.
> On the server side, the RSA doesn't even see that a remote invocation took
> place so it cannot participate in the request.
> We might be able to make it easier for new transports with abstract base
> classes or so, but with the current interface I don't think it can be done
> transparantly for the transport.
>
> Johannes
>
I think you are right. I am also not sure if handling async on the rsa
side is really what we need. Whenver possible I think it is better to
handle the asynchronicy on the transport level so
we ideally do not block any threads.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Aries RSA - support for long running calls
Posted by Johannes Utzig <ju...@gmail.com>.
2016-08-01 10:50 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
> Do you think we can even define and implement this in a transport agnostic
> way or do we need to support async per transport?
>
> Christian
>
>
I don't see how this could be done with the current architecture as the
whole invocation and communication part is the sole responsibility of the
distribution provider.
To support async calls the distribution provider needs to detect the
arguments/return values and replace Future/Promise and so on with custom
instances. All the RSA currently sees on the client side is a proxy object
and then it's already too late.
On the server side, the RSA doesn't even see that a remote invocation took
place so it cannot participate in the request.
We might be able to make it easier for new transports with abstract base
classes or so, but with the current interface I don't think it can be done
transparantly for the transport.
Johannes
Re: Aries RSA - support for long running calls
Posted by Christian Schneider <ch...@die-schneider.net>.
I think it would be great to have a RFP for Remote Service Admin with
async support.
Do you think we can even define and implement this in a transport
agnostic way or do we need to support async per transport?
Christian
On 01.08.2016 10:07, Timothy Ward wrote:
> Are we also happy to work this into an OSGi RFP/RFC?
>
> Regards,
>
> Tim
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Aries RSA - support for long running calls
Posted by Timothy Ward <ti...@apache.org>.
Are we also happy to work this into an OSGi RFP/RFC?
Regards,
Tim
> On 26 Jul 2016, at 16:52, Christian Schneider <ch...@die-schneider.net> wrote:
>
> In that case I am fine with requiring Java 8 for the build and for fastbin at runtime.
>
> Christian
>
> On 26.07.2016 17:42, Johannes Utzig wrote:
>> That would work just fine as long as the build job is compiled with a JDK 8
>> (target can remain with 1.7 for the other modules of course).
>>
>> 2016-07-26 17:16 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
>>
>>> I was not aware that CompleteableFuture is a java 8 only feature.
>>> Would it maybe work to just require java 8 in the fastbin transport. As
>>> the transport is new I would not be much concerned
>>> about the compatibility.
>>>
>>> Christian
>>>
>>> On 26.07.2016 14:27, Johannes Utzig wrote:
>>>
>>>> Makes sense. However, that means that I probably won't be able to create a
>>>> pull request since it wouldn't be able to support CompletableFuture and
>>>> the
>>>> internal implementation heavily relies on CompletableFuture
>>>> unfortunately...
>>>> Any idea what timeframe the next major version has?
>>>>
>>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
Re: Aries RSA - support for long running calls
Posted by Christian Schneider <ch...@die-schneider.net>.
In that case I am fine with requiring Java 8 for the build and for
fastbin at runtime.
Christian
On 26.07.2016 17:42, Johannes Utzig wrote:
> That would work just fine as long as the build job is compiled with a JDK 8
> (target can remain with 1.7 for the other modules of course).
>
> 2016-07-26 17:16 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
>
>> I was not aware that CompleteableFuture is a java 8 only feature.
>> Would it maybe work to just require java 8 in the fastbin transport. As
>> the transport is new I would not be much concerned
>> about the compatibility.
>>
>> Christian
>>
>> On 26.07.2016 14:27, Johannes Utzig wrote:
>>
>>> Makes sense. However, that means that I probably won't be able to create a
>>> pull request since it wouldn't be able to support CompletableFuture and
>>> the
>>> internal implementation heavily relies on CompletableFuture
>>> unfortunately...
>>> Any idea what timeframe the next major version has?
>>>
>>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Aries RSA - support for long running calls
Posted by Johannes Utzig <ju...@gmail.com>.
That would work just fine as long as the build job is compiled with a JDK 8
(target can remain with 1.7 for the other modules of course).
2016-07-26 17:16 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
> I was not aware that CompleteableFuture is a java 8 only feature.
> Would it maybe work to just require java 8 in the fastbin transport. As
> the transport is new I would not be much concerned
> about the compatibility.
>
> Christian
>
> On 26.07.2016 14:27, Johannes Utzig wrote:
>
>> Makes sense. However, that means that I probably won't be able to create a
>> pull request since it wouldn't be able to support CompletableFuture and
>> the
>> internal implementation heavily relies on CompletableFuture
>> unfortunately...
>> Any idea what timeframe the next major version has?
>>
>>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
Re: Aries RSA - support for long running calls
Posted by Christian Schneider <ch...@die-schneider.net>.
I was not aware that CompleteableFuture is a java 8 only feature.
Would it maybe work to just require java 8 in the fastbin transport. As
the transport is new I would not be much concerned
about the compatibility.
Christian
On 26.07.2016 14:27, Johannes Utzig wrote:
> Makes sense. However, that means that I probably won't be able to create a
> pull request since it wouldn't be able to support CompletableFuture and the
> internal implementation heavily relies on CompletableFuture unfortunately...
> Any idea what timeframe the next major version has?
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Aries RSA - support for long running calls
Posted by Johannes Utzig <ju...@gmail.com>.
Makes sense. However, that means that I probably won't be able to create a
pull request since it wouldn't be able to support CompletableFuture and the
internal implementation heavily relies on CompletableFuture unfortunately...
Any idea what timeframe the next major version has?
2016-07-26 13:37 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
> 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.
>
> Christian
>
>
> 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 <ti...@hotmail.com>:
>>
>> 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 <ti...@hotmail.com> 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 <ju...@gmail.com> 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.
>>>>>
>>>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
Re: Aries RSA - support for long running calls
Posted by Christian Schneider <ch...@die-schneider.net>.
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.
Christian
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 <ti...@hotmail.com>:
>
>> 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 <ti...@hotmail.com> 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 <ju...@gmail.com> 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.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Aries RSA - support for long running calls
Posted by Johannes Utzig <ju...@gmail.com>.
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 <ti...@hotmail.com>:
> 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 <ti...@hotmail.com> 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 <ju...@gmail.com> 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.
>
Re: Aries RSA - support for long running calls
Posted by Timothy Ward <ti...@hotmail.com>.
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 <ti...@hotmail.com> 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 <ju...@gmail.com> 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.
Re: Aries RSA - support for long running calls
Posted by Timothy Ward <ti...@hotmail.com>.
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 <ju...@gmail.com> 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.
Re: Aries RSA - support for long running calls
Posted by Johannes Utzig <ju...@gmail.com>.
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.
Re: Aries RSA - support for long running calls
Posted by Timothy Ward <ti...@hotmail.com>.
Hi Johannes,
More comments inline.
Sent from my iPhone
> On 25 Jul 2016, at 08:49, Johannes Utzig <ju...@gmail.com> wrote:
>
> Hi Tim,
>
> please see comments inline.
>
>
>> I have to ask, why would you not use OSGi Promises for this? Representing
>> Long running and/or asynchronous tasks is exactly what OSGi Promises were
>> designed for. They're also much simpler than CompletableFuture (which is a
>> horrible API to try to use), and tie in to the rest of the OSGi ecosystem
>> (for example the current Asynchronous Services spec, the proposed Push
>> Stream spec and the next Log Service updates)
>
> Because I did not think of that. I just updated the implementation to also
> work with Promise, thanks for the hint!
>
>
>>
>> There is already an RSA 1.2 update needed in the next OSGi specification
>> release - I would be happy to work with you to define a remote services
>> config type for asynchronous remote service support. That way this
>> behaviour would also be portable between implementations.
>>
>> I think that having a standard here is important, because there are
>> actually a lot of different RSA implementations in the wild, and if they
>> all do things completely differently then it will be confusing to users and
>> result in the feature not being used. It will also help to ensure that the
>> different providers hosted by single projects (Aries RSA and ECF both have
>> multiple options here) are self-consistent.
> I think having something like this in the standard would be great. Is this
> approach something that you could see making it into the standard?
That's exactly what I'm suggesting.
> Another thing that would IMO make a lot of sense to add to the RSA spec is
> an interface for plugging in new distribution providers. I don't know if
> you are aware of the service interface Christian created for aries-rsa, but
> having something like that in the actual spec would enable users to mix and
> match the transport layers of different RSA implementations.
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.
>
> https://github.com/apache/aries-rsa/blob/master/spi/src/main/java/org/apache/aries/rsa/spi/DistributionProvider.java
>
> Best regards,
> Johannes
Re: Aries RSA - support for long running calls
Posted by Johannes Utzig <ju...@gmail.com>.
Hi Tim,
please see comments inline.
> I have to ask, why would you not use OSGi Promises for this? Representing
> Long running and/or asynchronous tasks is exactly what OSGi Promises were
> designed for. They're also much simpler than CompletableFuture (which is a
> horrible API to try to use), and tie in to the rest of the OSGi ecosystem
> (for example the current Asynchronous Services spec, the proposed Push
> Stream spec and the next Log Service updates)
>
Because I did not think of that. I just updated the implementation to also
work with Promise, thanks for the hint!
>
> There is already an RSA 1.2 update needed in the next OSGi specification
> release - I would be happy to work with you to define a remote services
> config type for asynchronous remote service support. That way this
> behaviour would also be portable between implementations.
>
> I think that having a standard here is important, because there are
> actually a lot of different RSA implementations in the wild, and if they
> all do things completely differently then it will be confusing to users and
> result in the feature not being used. It will also help to ensure that the
> different providers hosted by single projects (Aries RSA and ECF both have
> multiple options here) are self-consistent.
>
>
I think having something like this in the standard would be great. Is this
approach something that you could see making it into the standard?
Another thing that would IMO make a lot of sense to add to the RSA spec is
an interface for plugging in new distribution providers. I don't know if
you are aware of the service interface Christian created for aries-rsa, but
having something like that in the actual spec would enable users to mix and
match the transport layers of different RSA implementations.
https://github.com/apache/aries-rsa/blob/master/spi/src/main/java/org/apache/aries/rsa/spi/DistributionProvider.java
Best regards,
Johannes
Re: Aries RSA - support for long running calls
Posted by Timothy Ward <ti...@hotmail.com>.
Hi Christian, Johannes,
I have to ask, why would you not use OSGi Promises for this? Representing Long running and/or asynchronous tasks is exactly what OSGi Promises were designed for. They're also much simpler than CompletableFuture (which is a horrible API to try to use), and tie in to the rest of the OSGi ecosystem (for example the current Asynchronous Services spec, the proposed Push Stream spec and the next Log Service updates)
There is already an RSA 1.2 update needed in the next OSGi specification release - I would be happy to work with you to define a remote services config type for asynchronous remote service support. That way this behaviour would also be portable between implementations.
I think that having a standard here is important, because there are actually a lot of different RSA implementations in the wild, and if they all do things completely differently then it will be confusing to users and result in the feature not being used. It will also help to ensure that the different providers hosted by single projects (Aries RSA and ECF both have multiple options here) are self-consistent.
Best Regards,
Tim Ward
OSGi IoT EG Chair
Sent from my iPhone
> On 22 Jul 2016, at 16:11, Christian Schneider <ch...@die-schneider.net> wrote:
>
> Yes.. I just looked into CompleteableFuture. This looks quite good already.
> So hopefully we get some more feedback on how to proceed.
>
> Christian
>
> 2016-07-22 16:25 GMT+02:00 Johannes Utzig <ju...@gmail.com>:
>
>> Hi Christian,
>>
>> I have not stumbled upon this yet, but on first glance it looks very
>> similar to what you can do with a CompletableFuture:
>>
>> testService.helloAsync().thenAccept(result -> System.out.println(result));
>>
>> Looks like the main difference is that Observable allows multiple items
>> that become available over time.
>>
>> But part of my change was a bit of a cleanup in the handling of the
>> InvocationStrategy which should make it easier to add support for
>> additional invocation strategies (like an Observable based).
>> As for the initial implementation I would prefer to keep it free of
>> additional mandatory dependencies.
>>
>> Johannes
>>
>> 2016-07-22 15:38 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
>>
>>> Hi Johannes,
>>>
>>> welcome to the Aries community and thanks for the pull requests and
>> issues
>>> you already provided.
>>>
>>> Long running calls could make a lot of sense but I am not sure if Future
>>> is still the way to go.
>>> It seems people are using Observable now (
>>> http://reactivex.io/documentation/observable.html) to be able to use
>>> rxjava (https://github.com/ReactiveX/RxJava).
>>>
>>> So I think it might make sense to directly provide this. I am not
>>> experienced in rxjava but maybe we got some people here who know that
>>> better.
>>>
>>> Christian
>>>
>>>
>>>> On 22.07.2016 15:00, Johannes Utzig wrote:
>>>>
>>>> Hi,
>>>>
>>>> as a quick introduction, my name is Johannes Utzig and I work for the
>>>> SEEBURGER AG.
>>>> We have been involved with aries-rsa since the beginning and maintain a
>>>> fork of it on github. We are primarily interested in the fastbin
>> transport
>>>> and I usually try to create pull requests for enhancements/fixes we're
>>>> doing that might be useful to have upstream.
>>>>
>>>> I am currently working on adding support for long running remote calls
>>>> (several minutes/hours) to fastbin.
>>>> If possible, I would like to contribute that feature upstream if there
>> is
>>>> an interest for it.
>>>> The idea is to allow Future and CompletableFuture as return values of
>>>> remote methods.
>>>> If such a return value is detected, the invocation strategy switches to
>>>> async and the client receives an implementation of (Completable)Future
>>>> that
>>>> will be filled as soon as the call result becomes available.
>>>>
>>>> Example Provider:
>>>>
>>>> public CompletableFuture<String> helloAsync() {
>>>> return CompletableFuture.supplyAsync(() -> "Hello");
>>>> }
>>>>
>>>> Example Consumer:
>>>>
>>>> exampleService.helloAsync().get(5, TimeUnit.MINUTES));
>>>>
>>>> A few questions about that:
>>>>
>>>> -Does someone maybe have a better idea on how to support long
>>>> running/async
>>>> calls?
>>>>
>>>> -would you be interested in that contribution?
>>>>
>>>> -My implementation requires java 8 features like CompletableFuture but
>> rsa
>>>> is currently building with 1.7. Would it be OK to move to java 8 as a
>>>> target version?
>>>>
>>>> Best regards,
>>>> Johannes
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
>
> Open Source Architect
> http://www.talend.com
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
Re: Aries RSA - support for long running calls
Posted by Christian Schneider <ch...@die-schneider.net>.
Yes.. I just looked into CompleteableFuture. This looks quite good already.
So hopefully we get some more feedback on how to proceed.
Christian
2016-07-22 16:25 GMT+02:00 Johannes Utzig <ju...@gmail.com>:
> Hi Christian,
>
> I have not stumbled upon this yet, but on first glance it looks very
> similar to what you can do with a CompletableFuture:
>
> testService.helloAsync().thenAccept(result -> System.out.println(result));
>
> Looks like the main difference is that Observable allows multiple items
> that become available over time.
>
> But part of my change was a bit of a cleanup in the handling of the
> InvocationStrategy which should make it easier to add support for
> additional invocation strategies (like an Observable based).
> As for the initial implementation I would prefer to keep it free of
> additional mandatory dependencies.
>
> Johannes
>
> 2016-07-22 15:38 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
>
> > Hi Johannes,
> >
> > welcome to the Aries community and thanks for the pull requests and
> issues
> > you already provided.
> >
> > Long running calls could make a lot of sense but I am not sure if Future
> > is still the way to go.
> > It seems people are using Observable now (
> > http://reactivex.io/documentation/observable.html) to be able to use
> > rxjava (https://github.com/ReactiveX/RxJava).
> >
> > So I think it might make sense to directly provide this. I am not
> > experienced in rxjava but maybe we got some people here who know that
> > better.
> >
> > Christian
> >
> >
> > On 22.07.2016 15:00, Johannes Utzig wrote:
> >
> >> Hi,
> >>
> >> as a quick introduction, my name is Johannes Utzig and I work for the
> >> SEEBURGER AG.
> >> We have been involved with aries-rsa since the beginning and maintain a
> >> fork of it on github. We are primarily interested in the fastbin
> transport
> >> and I usually try to create pull requests for enhancements/fixes we're
> >> doing that might be useful to have upstream.
> >>
> >> I am currently working on adding support for long running remote calls
> >> (several minutes/hours) to fastbin.
> >> If possible, I would like to contribute that feature upstream if there
> is
> >> an interest for it.
> >> The idea is to allow Future and CompletableFuture as return values of
> >> remote methods.
> >> If such a return value is detected, the invocation strategy switches to
> >> async and the client receives an implementation of (Completable)Future
> >> that
> >> will be filled as soon as the call result becomes available.
> >>
> >> Example Provider:
> >>
> >> public CompletableFuture<String> helloAsync() {
> >> return CompletableFuture.supplyAsync(() -> "Hello");
> >> }
> >>
> >> Example Consumer:
> >>
> >> exampleService.helloAsync().get(5, TimeUnit.MINUTES));
> >>
> >> A few questions about that:
> >>
> >> -Does someone maybe have a better idea on how to support long
> >> running/async
> >> calls?
> >>
> >> -would you be interested in that contribution?
> >>
> >> -My implementation requires java 8 features like CompletableFuture but
> rsa
> >> is currently building with 1.7. Would it be OK to move to java 8 as a
> >> target version?
> >>
> >> Best regards,
> >> Johannes
> >>
> >>
> >
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > http://www.talend.com
> >
> >
>
--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
Re: Aries RSA - support for long running calls
Posted by Johannes Utzig <ju...@gmail.com>.
Hi Christian,
I have not stumbled upon this yet, but on first glance it looks very
similar to what you can do with a CompletableFuture:
testService.helloAsync().thenAccept(result -> System.out.println(result));
Looks like the main difference is that Observable allows multiple items
that become available over time.
But part of my change was a bit of a cleanup in the handling of the
InvocationStrategy which should make it easier to add support for
additional invocation strategies (like an Observable based).
As for the initial implementation I would prefer to keep it free of
additional mandatory dependencies.
Johannes
2016-07-22 15:38 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
> Hi Johannes,
>
> welcome to the Aries community and thanks for the pull requests and issues
> you already provided.
>
> Long running calls could make a lot of sense but I am not sure if Future
> is still the way to go.
> It seems people are using Observable now (
> http://reactivex.io/documentation/observable.html) to be able to use
> rxjava (https://github.com/ReactiveX/RxJava).
>
> So I think it might make sense to directly provide this. I am not
> experienced in rxjava but maybe we got some people here who know that
> better.
>
> Christian
>
>
> On 22.07.2016 15:00, Johannes Utzig wrote:
>
>> Hi,
>>
>> as a quick introduction, my name is Johannes Utzig and I work for the
>> SEEBURGER AG.
>> We have been involved with aries-rsa since the beginning and maintain a
>> fork of it on github. We are primarily interested in the fastbin transport
>> and I usually try to create pull requests for enhancements/fixes we're
>> doing that might be useful to have upstream.
>>
>> I am currently working on adding support for long running remote calls
>> (several minutes/hours) to fastbin.
>> If possible, I would like to contribute that feature upstream if there is
>> an interest for it.
>> The idea is to allow Future and CompletableFuture as return values of
>> remote methods.
>> If such a return value is detected, the invocation strategy switches to
>> async and the client receives an implementation of (Completable)Future
>> that
>> will be filled as soon as the call result becomes available.
>>
>> Example Provider:
>>
>> public CompletableFuture<String> helloAsync() {
>> return CompletableFuture.supplyAsync(() -> "Hello");
>> }
>>
>> Example Consumer:
>>
>> exampleService.helloAsync().get(5, TimeUnit.MINUTES));
>>
>> A few questions about that:
>>
>> -Does someone maybe have a better idea on how to support long
>> running/async
>> calls?
>>
>> -would you be interested in that contribution?
>>
>> -My implementation requires java 8 features like CompletableFuture but rsa
>> is currently building with 1.7. Would it be OK to move to java 8 as a
>> target version?
>>
>> Best regards,
>> Johannes
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
Re: Aries RSA - support for long running calls
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Johannes,
welcome to the Aries community and thanks for the pull requests and
issues you already provided.
Long running calls could make a lot of sense but I am not sure if Future
is still the way to go.
It seems people are using Observable now
(http://reactivex.io/documentation/observable.html) to be able to use
rxjava (https://github.com/ReactiveX/RxJava).
So I think it might make sense to directly provide this. I am not
experienced in rxjava but maybe we got some people here who know that
better.
Christian
On 22.07.2016 15:00, Johannes Utzig wrote:
> Hi,
>
> as a quick introduction, my name is Johannes Utzig and I work for the
> SEEBURGER AG.
> We have been involved with aries-rsa since the beginning and maintain a
> fork of it on github. We are primarily interested in the fastbin transport
> and I usually try to create pull requests for enhancements/fixes we're
> doing that might be useful to have upstream.
>
> I am currently working on adding support for long running remote calls
> (several minutes/hours) to fastbin.
> If possible, I would like to contribute that feature upstream if there is
> an interest for it.
> The idea is to allow Future and CompletableFuture as return values of
> remote methods.
> If such a return value is detected, the invocation strategy switches to
> async and the client receives an implementation of (Completable)Future that
> will be filled as soon as the call result becomes available.
>
> Example Provider:
>
> public CompletableFuture<String> helloAsync() {
> return CompletableFuture.supplyAsync(() -> "Hello");
> }
>
> Example Consumer:
>
> exampleService.helloAsync().get(5, TimeUnit.MINUTES));
>
> A few questions about that:
>
> -Does someone maybe have a better idea on how to support long running/async
> calls?
>
> -would you be interested in that contribution?
>
> -My implementation requires java 8 features like CompletableFuture but rsa
> is currently building with 1.7. Would it be OK to move to java 8 as a
> target version?
>
> Best regards,
> Johannes
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com