Как сервер веб-службы обрабатывает URL?(И некоторые размышления о URL в WCF)

Question

Я новичок в WCF. Одна из неудобных вещей, с которыми я столкнулся, - это использование URL-адреса (конечной точки) для представления метода (веб-службы) и использования HTTP для его вызова.

Конечная точка состоит из ABC - Адрес, Связывание, Контракт (т.е. интерфейс). И это выглядит так:

http://www.myserver.com/myservice.svc

Обычно я помещаю URL-адрес в браузере и ожидаю, что какая-то страница вернется.

URL-адрес, указанный выше на сервере, является лишь одной из многих строк, которые я отправил методом HTTP GET. Как именно сервер веб-службы находит правильный метод с этой строкой URL? Я думаю, что сервер должен просто сделать следующие шаги:

1 - Выполните некоторый тривиальный анализ строки URL, после чего сервер узнает протокол и адрес привязки (это A и B часть вышеупомянутого ABC ).

2 - Затем процесс хоста службы проверяет файл конфигурации (будь то app.config или web.config) и находит целевой тип службы .

3 - Процесс хоста службы (будь то консольное приложение, приложение WinForm или рабочий процесс IIS) уже должен загрузить тип службы в свое адресное пространство. С информацией о типе службы, найденной на шаге 2, он может использовать отражение для вызова правильного метода. (Но я не уверен, как клиент отправляет на сервер информацию « which-method-of-the-service-type-i-want-to-invoke » ». В конце концов, мы могли только найти информация о типе услуги через конечную точку).

Таким образом, с точки зрения выше, URL - это просто идентификационный символ, точно так же, как URL используется как xmlns значение атрибута.

Правильно ли это понимание?

Спасибо за ваш ответ.

Answer 1

При условии, что ваша служба размещена в http://www.myserver.com/myservice и имя метода - "TestMethod".

при вызове метода теста это будет трассировка HTTP

a.Предполагается, что метод POST

POST /myservice/[Service1.svc]/TestMethod
host: myserver.com

и будет иметь тело запроса с входными параметрами для метода (sample: propertyid = 357352 & cultureCode = ENU & isEnlargeMode = true)

b.при условии, что метод GET

GET /myservice/[Service1.svc]/TestMethod
host: myserver.com

, здесь не будет никакого тела запроса.

Теперь, когда запрос достигает сервера, сервер идентифицирует имя метода из запроса и принимаетпараметры из тела запроса на случай, если это POST.

Answer 2

Я не совсем понимаю, что вас здесь беспокоит, но я хотел бы ответить несколькими соображениями / фактами:

1. При использовании привязок SOAP (basicHttpBinding, wsHttpBinding) все, что вы «выставляете», является конечной точкой службы; при размещении в IIS (что здесь имеет место) это будет *.svc файл, который должен существовать где-то в структуре папок IIS. Этот файл svc в основном содержит всю логику, которую вы запрашиваете, которая описывает, что ServiceHost создать для обработки запроса и т. Д., А сообщение SOAP содержит информацию о том, какой метод вызывать и какие параметры передавать.

2. При использовании REST (webHttpBinding) основная предпосылка и базовый «способ функционирования» REST требуют, чтобы вы представляли все как ресурс, к которому можно получить доступ с помощью URI - так что это базовое предположение о ОСТАВАЙТЕСЬ, что вы делаете выставляете свои сервисные «методы» - так как на самом деле это не методы, а ресурсы, с которыми вы можете работать

Сделайте какой-нибудь тривиальный анализ против Строка URL, тогда сервер будет знать Протокол привязки и адрес, (это часть А и В вышеупомянутый ABC).

Часть адреса азбуки WCF кажется довольно ясной: все, что вы вводите, или то, что ваш клиент использует в качестве целевого URL, является адресом службы, к которой вы обращаетесь.

Привязка также в значительной степени является данностью, так как вы должны добавить префикс URI к прозвищу протокола - http, net.tcp, net.msmq и т. Д.

Это оставляет контракт , который определяется файлом * .svc при размещении в IIS - файл svc определяет, что ServiceHostFactory использовать для создания ServiceHost для обработки запроса; Я действительно не понимаю, как еще вы хотите, чтобы это произошло, и для меня файл svc все равно немного похож на файл конфигурации.

Так что именно вы ожидаете от "тривиального разбора" в плане выяснения азбуки WCF ?? Можете ли вы объяснить немного больше? Может показать гипотетический образец?