Статьи

Удаленные службы OSGi и ECF — асинхронные службы


В
предыдущей публикации я обсуждал / представил некоторую поддержку асинхронного доступа к удаленным службам OSGi, которая в настоящее время существует в
реализации ECF .

В
блоге, опубликованном ранее на этой неделе ,
Питер Криенс рассказал о некоторых усилиях, предпринимаемых в EEG по добавлению асинхронной поддержки для удаленных (и даже локальных) сервисов. Один из его комментариев в этой публикации в блоге заключался в том, что асинхронную поддержку ECF можно считать неловкой из-за сложности / незнакомого использования API.

Я намеревался добавить более простые / более естественные механизмы для асинхронного удаленного доступа, чем то, что у нас уже есть, и то, что происходит в EEG и блоге Питера, было отличным стимулом для завершения еще некоторой этой работы. Существующие механизмы
имеют несколько неуклюжих, но они также делают очень сильный / гибкий фундамент … и поэтому можно строить новые механизмы на основе существующих механизмов.

Нормальные / синхронные прокси

В нашем
примере удаленных сервисов ‘hello’ у нас есть сервисный интерфейс:

public interface IHello {
    public void hello(String from); 
}

Потребители этой удаленной службы получают прокси-сервер, который реализует интерфейс IHello, а затем клиенты могут синхронно вызывать метод hello для выполнения удаленного вызова:

proxy.hello{"slewis");

Так как в вызовах метода java блокируются, поток, который вызывает метод hello, будет блокироваться, если (например) сеть медленная, хост службы медленный (или блокирует). Было бы хорошо, если бы у нас был способ (на потребителе / ​​клиенте) вызвать метод hello и гарантировать, что он не будет блокироваться … при этом все равно каким-то образом получаться результат (если есть) … когда удаленный вызов успешен … или получение информации о сбое, если что-то не работает / идет не так (например, из-за сбоя сети)

Асинхронные прокси

Мы только что добавили поддержку асинхронных прокси в реализации удаленных сервисов ECF. Это означает, что если интерфейс объявлен так (и в том же пакете, что и интерфейс IHello):

public interface IHelloAsync extends IAsyncRemoteServiceProxy {

    public void helloAsync(String from, IAsyncCallback callback);

    public IFuture helloAsync(String from);

}

распределение удаленной службы ECF система будет автоматически создавать прокси — сервер , который
реализует интерфейс IHelloAsync на потребителя / клиента.

Если метод helloAsync (String,
IAsyncCallback ) вызывается потребителем:

proxy.helloAsync("slewis",new IAsyncCallback() {
    void onSuccess(Object result) {
        System.out.println("we got result="+result);
    }
    void onFailure(Throwable exception) {
        System.out.println("oh no!");
        exception.printStackTrace();
    }
});

потребительский поток не будет
блокироваться , и успех / результат или сбой будут асинхронно сообщаться вызывающей стороне через прокси-сервер, вызывающий соответствующий метод на
IAsyncCallback .

В дополнение к использованию обратного вызова
также поддерживаются
фьючерсы (
IFuture ). Все, что нужно сделать, чтобы позволить потребителю использовать будущий результат, это объявить метод helloAsync, который возвращает IFuture:

    public IFuture helloAsync(String from);

Единственное, что требуется для того, чтобы это произошло на клиенте / клиенте, — это объявление интерфейса * Async ( IHelloAsync ). Затем, во время создания прокси на удаленном потребителе службы, если этот интерфейс * Async существует, он будет реализован прокси и может использоваться клиентом.

Обратите внимание, что объявление интерфейса * Async — единственное, что необходимо для того, чтобы это работало с любымСервисный интерфейс. Реализация хоста службы не должна фактически реализовывать интерфейс * Async, а дистрибутив удаленных служб ECF создаст прокси-сервер, который автоматически реализует интерфейс * Async. Кроме того, как и в случае с другими средствами ECF, все это выполняется независимым от транспорта способом, поэтому все существующие поставщики (JMS, XMPP, универсальный ECF, JavaGroups, Skype, REST, SOAP и т. Д. И т. Д.) Немедленно поддерживают это добавление с помощью нет дальнейшей работы.

Google Web Toolkit использует очень похожий подход для поддержки асинхронного удаленного вызова процедур. Однако в дополнение к обратным вызовам асинхронный прокси-сервер ECF также поддерживает фьючерсы. Это позволяет потребителю / клиенту выбрать желаемый стиль вызова: синхронный, асинхронный обратный вызов или асинхронное будущее.

С http://eclipseecf.blogspot.com/2010/04/osgi-remote-services-and-ecf.html