BizTalk опубликовать сервис WCF net.tcp - PullRequest
2 голосов
/ 13 ноября 2008

Кто-нибудь знаком с настройкой адаптеров WCF-nettcp для BTS?

Когда я создаю адаптер WCF-netTcp для местоположения получения, я не уверен, как / когда BTS откроет порт 808 для прослушивания указанного URI адреса. Похоже, это произойдет, только если я перезапущу все приложение BizTalk. Если по какой-то причине он закрывается, я не вижу никакого способа перенастройки и повторного открытия порта.

Кроме того, поскольку это только привязка net.tcp, конечная точка mex не отображается. Я считаю, что клиентские приложения, которые хотят использовать эту открытую службу WCF, изначально нуждаются в метаданных mex. Доступ к этой конечной точке напрямую из проекта Visual Studio просто даст

Metadata contains a reference that cannot be resolved: 'net.tcp://biztalkserver/PostReceiveLocation_TCP/PostReceiveService.svc'.
Metadata contains a reference that cannot be resolved: 'net.tcp://biztalkserver/PostReceiveLocation_TCP/PostReceiveService.svc'.
If the service is defined in the current solution, try building the solution and adding the service reference again.

Невозможно сказать, как правильно выставить конечную точку mex для службы. Мастер публикации служб BizTalk WCF сбивает меня с толку; Я не могу получить ссылку на адаптер WCF / местоположение получения, которое я настроил. Я не нахожу документ, который учит, что нужно делать для служб NetTcp; это все о Http.

1 Ответ

1 голос
/ 15 ноября 2008

Забавно, прошло прохождение публикации службы WCF Net-Msmq , чтобы подтолкнуть меня к мысли о том, как на самом деле работает мастер публикации служб WCF.

Проблема заключается в следующем: когда я вручную создал местоположение получения WCF-netTcp, у него есть URI конечной точки, например net.tcp: //biztalkserver/PostReceiveLocation_TCP/PostReceiveService.svc. При выборе опции для публикации только конечной точки mex в мастере публикации служб WCF он в конечном итоге запрашивает местоположение службы WCF, которое, как я понял, является фактическим местоположением службы. Поскольку он не принимает ничего, кроме URL-адресов Http, он поддерживает только конечные точки WCF на основе Http.

Но для этого текстового поля предполагается разместить URL-адрес Http, который для является только конечной точкой mex , а не фактической конечной точкой WCF net.tcp. Это место в IIS, где мастер создает необходимые файлы метаданных. По окончании этого места, размещение конечной точки mex будет информировать клиентов о реальном сервисе, расположенном в конечной точке net.tcp.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...