Любые жизнеспособные альтернативы WCF и WSDL для конечных точек интеграции? - PullRequest
Новая
       26

Любые жизнеспособные альтернативы WCF и WSDL для конечных точек интеграции?

3 голосов
/ 23 декабря 2009

Мой работодатель - поставщик программного обеспечения для конкретного рынка. Наши клиенты интегрируют нашу систему с другими, используя веб-сервисы. Мы используем технологию Microsoft, а наши веб-сервисы реализованы в ASP.NET и WCF.

Настало время пересмотреть наш текущий набор услуг и разработать стандарты компании для будущих интеграций. Я читаю «Шаблоны корпоративной интеграции», а также немного смотрю на nServiceBus и Mass Transit. Это может упростить такие проблемы, как управление версиями контрактов и модульное тестирование, но кажется, что они наиболее полезны для предоставления внутренней служебной шины, а не для предоставления услуг внешним клиентам.

Наши клиенты работают на разных платформах и требуют, чтобы наши услуги соответствовали стандартам. Это может означать разные вещи для разных людей, но я думаю, можно с уверенностью предположить, что они хотят получить доступ к веб-сервисам, описанным в WSDL.

В этом сценарии, WCF путь?

Ответы [ 2 ]

2 голосов
/ 23 декабря 2009

WCF на сегодняшний день является самым совместимым со стандартами стеком на платформе Microsoft. Приятно то, что он очень гибкий для разных клиентов "из коробки", и если есть вещи, которые вызывают у вас горе, большинство из них можно изменить с помощью нестандартного поведения без особых проблем.

1 голос
/ 03 мая 2012

Альтернативой, которую я обычно рекомендую, является интеграция через AMQP между вашими брокерами сообщений. Это значит, что вы можете использовать парадигму push вместо опроса (что очень мощно и масштабируемо по сравнению)!

Вы бы создали своего собственного брокера, такого как RabbitMQ, локально. Тогда вы позволите вашему интеграционному партнеру создать его. (Легко: просто скачайте ).

Если ваш партнер интегрируется из одного и того же центра обработки данных, вы можете предположить, что несколько сетевых разделений означают, что вы могли бы поделиться с брокером . С другой стороны, если вы находитесь в разных сетях, вы можете настроить посредника в режиме федерации . (Запустите rabbitmq-plugins enable rabbitmq_federation и , укажите для другого брокера)

Теперь вы можете использовать, например, MassTransit: 

ServiceBusFactory.New(sbc =>
{
    sbc.UseRabbitMqRouting();
    sbc.ReceiveFrom("rabbitmq://rabbitmq.mydomain.local/myvhost/myapplication");
    // sbc.Subscribe( s => s ... );
});

, как если бы вы не делали интеграцию.

Если вы посмотрите на http://rabbitmq.mydomain.local:55672/, теперь вы найдете интерфейс администрирования для RabbitMQ. MassTransit создает обмен для каждого типа сообщений (отправка такого сообщения на этот обмен будет распространяться среди всех подписчиков), для которого вы можете установить правила авторизации.

Правила авторизации могут быть в форме регулярного выражения для пользователя или могут быть интегрированы в LDAP. Обратитесь к документации для этого.

Вам также понадобится SSL в случае, если вы проходите через WAN, и у вас нет туннеля IPSec - эта документация здесь: http://www.rabbitmq.com/ssl.html, и вы включаете вот так .

Вот и все! Наслаждайтесь!

Post scriptum: если вы готовитесь к приключению, которое поможет вам управлять всей своей инфраструктурой как побочным эффектом, вы можете взглянуть на puppet . Puppet - поставщик и менеджер конфигурации серверов; в этом случае вам будет интересно установить SSL с Puppet. Во-первых, закажите сертификат поддомена с подстановочными знаками для вашего домена, затем используйте этот сертификат для подписи других сертификатов: вы можете делегировать это - см. Руководство rabbitmq, где говорится: «Теперь мы можем сгенерировать ключ и сертификаты, которые будет использовать наш тестовый центр сертификации «. - создать запрос на подпись сертификата для сертификата вместо создания нового органа - и позволить RMQ использовать его для SSL - он будет действителен для Интернета.

...