Преобразование веб-приложения в веб-сервис

Question

а. Какие вещи я должен рассмотреть? б. У меня есть несколько хранимых процедур, выполняемых текущим приложением. Если я создам эквивалентные методы для выполнения этих процедур, каков будет риск или проблема.

Answer 1

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

Еще одна вещь, о которой вам нужно подумать, это какой протокол сериализации вы будете использовать. Например, SOAP против протокола на основе REST.

Кроме того, подумайте о безопасности - соображения безопасности отличаются между веб-приложением и веб-службой.

Наконец, подумайте, как другие узнают о вашем веб-сервисе (или вообще узнают).

Answer 2

Мне кажется, что самая большая проблема будет в том, что вы, очевидно, испытываете желание сделать это. Я думаю, что вы делаете ошибку.

Ваше веб-приложение и предлагаемый веб-сервис предъявляют различные требования. «Превратив» приложение в сервис, вы обремените сервис требованиями приложения.

Вот «мысленный эксперимент»: что если вы написали сервис с нуля, игнорируя приложение. Насколько похожи сервис и приложение? Если бы они оказались одинаковыми, тогда трансформация имела бы смысл. В противном случае, не так много.

Answer 3

Управление вашей кодовой базой, как сказал Стивен, будет большой проблемой, если вы создадите эквивалентные методы. Вам гораздо лучше экстраполировать методы в новую библиотеку, которую будут использовать и веб-приложение, и веб-сервис. В ваших веб-приложениях не должно быть кода доступа к данным.

С веб-сервисом вам нужно учитывать ваших клиентов. Кто будет получать доступ к вашим данным и откуда. Если, например, это из клиента Windows .net в той же сети или на машине, привязка TCP может быть лучше. Или, если вам нужна поддержка старых клиентов .net Framework или даже Java-клиентов, вам нужно быть осторожным с тем, какую технологию вы используете.

Вы также можете выбрать между WCF или ASMX. На что предыдущий абзац поможет ответить.

Answer 4

Один риск - гарантировать, что ваш код останется прежним.

Под этим я подразумеваю то, что в этой ситуации существует явная возможность дублирования кода, и поэтому вы можете случайно забыть изменить одно из мест, где используется хранимая процедура (например, если вы добавляете новую переменная для хранимого вызова процедуры).

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