В
предыдущей публикации я обсуждал / представил некоторую поддержку асинхронного доступа к удаленным службам 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