WebService proxy
Alexey Petriashev
Есть некоторое количество веб-сервисов и приложение, которое общается с ними.
Сейчас для генерации WebService proxy используется Spring.Net (Chapter 28. Web Services, пункт 28.3.2. Generating proxies dynamically)
То есть прокси генерируется по wsdl или по урлу в рантайме.
В последнее время Spring не особо радует (редко выходят релизы, фиксы, нет поддержки .Net 4.0),
поэтому появилась мысль мигрировать на другой контейнер, например Autofac.
Вопрос: Как подобное решается в других контейнерах? Или есть другой способ?
Alexey Petriashev
Посмотрю, работают ли Spring.Net прокси при компиляции с .Net 4.0
Однако, вопрос остается открытым.
Pavel Samokha
которого является DI-контейнер, но помимо этого включающий разные
возможности вроде указанной генерации прокси для web-service'ов, а
AutoFac - это только DI-контейнер, ничего более, т.е. описанных
возможностей в нем не будет - если вам надо - реализуйте сами.
Поддержка .Net 4.0 в trunk Spring.net уже есть.
On Feb 16, 10:15 am, Alexey Petriashev <petrias...@gmail.com> wrote:
> Вводная:
> Есть некоторое количество веб-сервисов и приложение, которое общается с
> ними.
> Сейчас для генерации WebService proxy используется Spring.Net (Chapter 28.
> Web Services<http://www.springframework.net/doc-latest/reference/html/webservices....>,
Алексей Петряшев
Я плотно работал только со Spring.net, поэтому хотелось бы знать как реализуется подобный функционал в других библиотеках.
Меня интересует кто как работает с веб-сервисами.
Варианты, которые не интересуют:
- Сгенеренный класс для веб-сервиса через Add Service Reference
- Ручное формирование SOAP-пакета
Sergey B
--
С Уважением,
Сергей
Pavel Samokha
расширения включают множество аспектов интеграции. Многие DI-
контейнеры
перерастают понятие "просто DI-контейнер".
Опять же - Castle - это тоже фреймворк, который включает контейнер
Windsor.
А Autofac - просто контейнер, к которому существуют библиотеки для
использования его в ASP.Net MVC и пр. - но ту функциональность которую
вы хотите он не включает. Если вам надо - вы можете реализовать
генерацию прокси для веб-сервисов самостоятельно, используя любой DI-
контейнер, который вам нравится.
On Feb 17, 11:39 am, Алексей Петряшев <petrias...@gmail.com> wrote:
> В том же Autofac есть множество Contribs, в Castle есть facilities. Эти
> расширения включают множество аспектов интеграции. Многие DI-контейнеры
> перерастают понятие "просто DI-контейнер".
> Я плотно работал только со Spring.net, поэтому хотелось бы знать как
> реализуется подобный функционал в других библиотеках.
> Меня интересует кто как работает с веб-сервисами.
> Варианты, которые не интересуют:
> - Сгенеренный класс для веб-сервиса через Add Service Reference
> - Ручное формирование SOAP-пакета
>
> 17 февраля 2011 г. 11:19 пользователь Pavel Samokha
> <vansic...@gmail.com>написал:
Alexey Petriashev
А ручками я не хочу, избалован Спрингом )).
Неужели все гененируют прокси с помощью Add Service Reference?
Alexey Petriashev
меня интересует вызов web-сервиса через интерфейс и его адрес.
Например есть web-сервис http://superserver.com/Services/CounterService.asmx
Есть интерфейс декларирующий методы этого сервиса:
public interface ICounterService
{
int GetNextValue( string counterName );
}
Я хочу использовать это так:
ICounterService counterService = serviceLocator.GetService<ICounterService>();
int nextValue = counterService.GetNextValue( "SomeCounter" );
В Spring'е я просто создавал прокси объект так:
<!--Сервис счетчиков-->
<object id="Services.CounterService" type="Spring.Web.Services.WebServiceProxyFactory, Spring.Services">
<property name="ServiceUri" value="http://superserver.com/Services/CounterService.asmx"/>
<property name="ServiceInterface" value="Gateway.ICounterService"/>
</object>
Вот так просто!
Dmitry Razumikhin
Обычно используем именно "Add Service Reference". Кодогенерация в
programming time'е - это не страшно, страшна слабая управляемость
процесса.
Пример из жизни: есть сторонний Web-сервис написанный на Delphi.
Реализация клиента, генерируемая через Add Service Reference,
оказалась несовместима с сервисом - возникает ошибка десериализации из-
за иного принципа формирования SOAP respons'a.
Сейчас ищу альтернативу.
Алексей Петряшев
Пример: Биллинговый Шлюз (реальный мой проект в production)
Конвеер обработки сообщений и общения со сторонноми биллингами.
Идеал - один биллинг - одна декларативная конфигурация, что сейчас и работает.
Зачем это нужно? Система в бою, под хорошей нагрузкой. Я могу внедрять новые биллинги без остановки сервиса, просто перечитывая конфигурацию. Если для нового биллинга будет требоваться свой прокси класс, то потребуется перекомпиляция проекта или подкладывание дополнительной библиотеки, чего не хотелось бы.
Андрей Чудновский
1. Наследуем ClientBase<T> так, чтобы он предоставлял доступ к Channel
public class UniversalClient<T> : ClientBase<T> where T : class
{
public T ChannelObj {
get { return Channel; }
}
}
2. Потреблять это дело можно так:
new UniversalClient<IService>().ChannelObj.DoSomething()
Настройки берутся из конфига стандартным для WCF образом, позволяя
соответственно задавать адрес сервиса и некоторые прочие вещи.
Соответственно далее есть следующие пути:
1. Генерировать прокси вида
ServiceClient : ClientBase<IService>, IService
Где соответственно все вызовы передаются соответствующим методам
Channel.
Конкретного примера под рукой нет, но Castle и Unity это точно
позволяют. Еще NHibernate умеет делать прокси из LinFu, то есть там
тоже можно.
2. Настроить ваш IoC контейнер, так чтобы вызов
serviceLocator.GetService<ICounterService>() возвращал new
UniversalClient<ICounterService>().ChannelObj
Тогда весь ваш существующий код должен работать.
Лично проверял только в режиме Hello World, поэтому для системы в бою
и с хорошей нагрузкой надо проверять нет ли эффектов разных.
On 18 фев, 09:34, Алексей Петряшев <petrias...@gmail.com> wrote:
> В нашем случае тоже можно заранее, но цель генерировать именно в рантайме.
> Пример: Биллинговый Шлюз (реальный мой проект в production)
> Конвеер обработки сообщений и общения со сторонноми биллингами.
> Идеал - один биллинг - одна декларативная конфигурация, что сейчас и
> работает.
> Зачем это нужно? Система в бою, под хорошей нагрузкой. Я могу внедрять новые
> биллинги без остановки сервиса, просто перечитывая конфигурацию. Если для
> нового биллинга будет требоваться свой прокси класс, то потребуется
> перекомпиляция проекта или подкладывание дополнительной библиотеки, чего не
> хотелось бы.
>
> 18 февраля 2011 г. 0:01 пользователь Dmitry Razumikhin <
> dmitry.razumik...@gmail.com> написал:
Alexey Petriashev
Прокси для веб-сервисов работают.