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 <[email protected]> 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 <[email protected]>:

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 <[email protected]>:

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

Reply via email to