Итак, каковы явные проблемы с этими веб-службами в их текущем состоянии?
- Нет встроенного механизма шифрования: Вы
придется зашифровать его самостоятельно или использовать
HTTPS.
- Нет способа аутентификации пользователей:
Вы можете передать имя пользователя / пароль
конечно, но что, если вы хотите сделать
Проверка подлинности Windows? Как насчет
Сертификаты X509?
- Невозможно выбрать
Транспортный механизм: HTTP является
относительно подробный протокол. Это
текстовый протокол поверх TCP / IP.
- Перенаправление: если у вас есть брандмауэр,
и вам нужно перенаправить сообщение
в зашифрованном виде вы не можете. Это
если брандмауэр не расшифрует его,
видит пункт назначения и вперед
сообщение.
- Сжатие: Сжатие
должно быть выполнено до того, как
сообщение отправлено по проводам.
Хорошо, Microsoft решила эти проблемы с помощью промежуточного выпуска, который назывался Web Service Extensions версий 2.0 и 3.0. Они решали эти проблемы за один раз. Тем не менее, это были дополнения. У меня был опыт
работа с ним и определенно требовала ручной обработки кода. Они были добавлены в соответствии со стандартами WS- *, установленными W3C Organizationsations.
Если вы хотели использовать дополнительные функции WSE, вам пришлось в конечном итоге пересобрать свой код. Ваш прокси на клиенте должен был унаследовать от нового базового класса. Вы должны были добавить дополнительную информацию о конфигурации. Вы можете выполнить базовый 4/5 шаговый процесс для обновления вашего клиента. Но это было не самое удобное.
При сравнении WSE 3.0 и WCF вы увидите, что все функции реализованы гораздо проще. Если я сравню это со списком выше:
- Шифрование может осуществляться на уровне сообщений (шифрование раздела «данные») или на транспортном уровне (шифрование по проводам), просто добавляя что-то вроде «messageAlgorithm = Basic128» в App.config.
- Вы можете без проблем использовать Аутентификацию Windows запущенного приложения, а также требовать установки определенного сертификата на клиентском компьютере перед его вызовом.
- Транспортные механизмы могут быть изменены в соответствии с вашими потребностями. У нас есть HTTP, HTTPS, TCP, Именованные каналы (для межпроцессных вызовов) и MSMQ. Обратите внимание, что к ним можно добавить, если вы того пожелаете, просто путем реализации нового базового класса и переопределения необходимых методов.
TCP намного быстрее в корпоративной внутренней сети, чем HTTP, плюс вы можете также реализовать шифрование, если вы действительно параноик.
- Перенаправление было реализовано в WSE 3.0, и я уверен, что расширяет его еще больше. Использование перенаправления важно, потому что во многих организациях Интернет подключен только к нескольким компьютерам, а внутренняя фильтрация выполняется по IP-адресу. Однако есть также нечто, называемое UDDI, которое позволяет нескольким машинам регистрироваться как имеющие службу. Так что вы не обязательно бьете по той же машине, на которую собираетесь.
- Сжатие реализовано в соответствии со стандартами WS- * и в соответствии с WSE 3.0. Существует определенный стандарт сжатия, который позволяет «прикреплять» документы к сообщениям XML.
Помимо этих функций, WCF более открыто реализует 4 "правила" SOA. SOA - это большая тема, которую можно найти в Интернете. Целые книги были написаны
в SOA, но просто признайте, что WCF является реализацией архитектуры SOA.
В одном из руководств по SOA предлагается указывать «контракты» (схемы), а не объекты / классы, поскольку объекты / классы могут означать привязку к языкам ОО. Схема указана в XML как независимая от языка.
WCF также определяет услугу через «контракт». Основной принцип заключается в том, что вы определяете договор, то есть операции, которые могут быть выполнены в первую очередь. В .NET это реализовано как интерфейс, украшенный определенными атрибутами.
Затем разработчик .NET реализует интерфейс в конкретном классе (украшенном некоторыми другими атрибутами) и кодирует методы для реализации их функциональности. Это означает, что «контракт» взят из интерфейса, а наши классы обеспечивают только его реализацию. Таким образом .NET предоставляет свой собственный путь
реализации стандарта.
Хотя вы можете кодировать все это, WCF дает вам возможность указать его в файле конфигурации - например, URI, механизм шифрования, транспортные механизмы для гибкости. Еще один стандарт SOA - это гибкость в реализации.
Вот краткий обзор. Я надеюсь, что это поможет окунуть ваши пальцы ног, не будучи слишком конкретным.