Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
REST & TCP
|
|||
|---|---|---|---|
|
#18+
Доборый день, коллеги. Начал работать с WCF и вот сразу столкнулся с некотороми вопросами. Надуюсь, что кто-то мне сможет помочь. Суть проблемы следующая: создал rest wcf сервис для получения изображения с одним OperationContract view sourceprint? Код: plaintext 1. 2. Теперь мне нужно также, чтобы этот сервис работал и с Tcp. Но вот в чем фишка. В http из URI поступают параметры прямо в метод (в par1, par2, par3...). Для Tcp как я понимаю надо делать запросы как-то через Request и Response объекты? Как я понимаю, скоздавать другой IService - не правильно. Если я не правильно понимаю, то подскажите, пожалуйста, как такие вещи ваще делаются. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2010, 09:22 |
|
||
|
REST & TCP
|
|||
|---|---|---|---|
|
#18+
cyssima, Ни разу не пробовал мешать в одном сервисе REST & TCP, но исходя из общих соображений: 1. модель WCF заранее предусматривает отделение "мух от котлет" - сервиса от транспорта; 2. REST базируется на HTTP-транспорте; 3. TCP базируется на WinSock-транспорте; 4. в общем случае вам нужно создавать (конфигурировать) 2 EndPoints: одну для REST и одну для TCP (там разные Bindings используются); 5. ну и, ес-с-нно, запускать 2 хостинг-процесса (REST может крутиться в IIS-е, TCP - в WinService или ConsoleApplication); 6. но при всем этом код самой службы будет один и тот же (и рабочая dll может деплоиться в одно место). (как-то так). З.Ы. да, чуть не забыл, для обращения к TCP-EndPoint придется делать своего клиента на основе прокси-класса, сгенеренного по описанию сервиса (wsdl) и передавать параметры в вызове метода Method1(string par1, string par2, string par3, string par4) этого прокси-класса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2010, 11:07 |
|
||
|
REST & TCP
|
|||
|---|---|---|---|
|
#18+
qu-qu, Да это то все супер... У меня собственно сейчас в одном WinService поднимаются два host для http и tcp И еще. Я все возвращаюсь к тому, что обычно сервис там webservice Или tcp - там определяются всетаки какие-то объекты более серьезные, нежели просто набор параметров метода. и передается компонованый объект Request а получаешь - Response. У меня же, как я понимаю, так как REST, то компонованных объектов не будет нигде? Даже в TCP? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2010, 11:31 |
|
||
|
REST & TCP
|
|||
|---|---|---|---|
|
#18+
qu-qu5. ну и, ес-с-нно, запускать 2 хостинг-процесса (REST может крутиться в IIS-е, TCP - в WinService или ConsoleApplication); Зачем? Все может крутиться в одном WinService или ConsoleApp - для чего тут IIS? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2010, 11:51 |
|
||
|
REST & TCP
|
|||
|---|---|---|---|
|
#18+
cyssimaqu-qu, ... У меня же, как я понимаю, так как REST, то компонованных объектов не будет нигде? Даже в TCP? Будет-будет... не сомневайтесь. Просто ваши "компонованные объекты" должны быть помечены атрибутами DataContract и они будут сериализоваться в текстовый XML в случае REST и еще куда-нить (очень сильно подозреваю, что в тот же XML только в виде binary-stream) в случае TCP. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2010, 14:13 |
|
||
|
REST & TCP
|
|||
|---|---|---|---|
|
#18+
Хопаqu-qu5. ну и, ес-с-нно, запускать 2 хостинг-процесса (REST может крутиться в IIS-е, TCP - в WinService или ConsoleApplication); Зачем? Все может крутиться в одном WinService или ConsoleApp - для чего тут IIS ? IIS для того, чтобы следить за жизненным циклом сервисного компонента (или многих), прибивать рабочие потоки, если что пойдет не так, recycle-ить процессы, вобщем - с "ручным" хостингом проблем намного больше, чем с "готовым"... (ИМХО). (подробности можно найти в MSDN). З.Ы. для тестирования можно обойтись "WinService или ConsoleApp", а в продакшн - я бы не стал ставить... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2010, 14:18 |
|
||
|
REST & TCP
|
|||
|---|---|---|---|
|
#18+
qu-qu, Вот у меня REST ставит в разных случаях разные WebOperationContext.Current.OutgoingResponse.StatusCode Как это отразится на вызове соответствующего метода через TCP? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2010, 14:20 |
|
||
|
REST & TCP
|
|||
|---|---|---|---|
|
#18+
Никак. Разные хосты - разные контексты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2010, 14:26 |
|
||
|
REST & TCP
|
|||
|---|---|---|---|
|
#18+
Даже больше. Разные инстансы - разные контексты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2010, 03:53 |
|
||
|
REST & TCP
|
|||
|---|---|---|---|
|
#18+
bured, +1. Не важно совершенно какая привязка. привязка для того и зделана, чтобы отделить через уровень абстракции транспортные и протокольные каналы от собственно интерфейса взаимодействия. Всё базируется на всё тех же отражениях типов CLS на WSDL и наоборот. А контракты данных отображают CLS типы на XSD ( в составе всё того же WSDL). И на этом точко. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2010, 18:58 |
|
||
|
|

start [/forum/topic.php?fid=19&fpage=27&tid=1397697]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
47ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
2ms |
| others: | 266ms |
| total: | 404ms |

| 0 / 0 |
