Каковы характеристики масштабируемых, безопасных и простых в использовании веб-сервисов? - PullRequest
1 голос
/ 15 февраля 2010

Наше приложение в настоящее время предоставляет веб-сервисы, созданные на основе WSDL 1.1 и SOAP 1.1, в соответствии со следующими стандартами w3c:

http://schemas.xmlsoap.org/soap/http такое привязка WSDL 1.1 для SOAP 1.1 HTTP-привязка.

Мы хотим обновить наши веб-службы, чтобы они стали Масштабируемыми, безопасными и простыми в использовании

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

Это усилие подводит меня к вопросу:

Чего мне ожидать от реконструкции? наших веб-сервисов, которые масштабируемый, безопасный и простой в использовании?


Текущие проблемы с нашими веб-сервисами

  • Вы должны войти (1-я транзакция), чтобы получить токен (сохранить сеанс в памяти), чтобы использовать их.
  • Не масштабируется, потому что любой разработчик может открыть сеансы 20K и привести к сбою сервера веб-службы.
  • Не является безопасным, поскольку те же пользователи, что и администратор сайта, могут пользоваться веб-сервисами.
  • Нелегко использовать, потому что веб-сервис не содержит никакой бизнес-логики.

Причины, по которым нашим клиентам нравится наш интерфейс веб-службы, заключаются в том, что любой элемент данных, который они добавляют в веб-приложение, будет немедленно представлен в определении веб-службы (wsdl).


Еще один бит информации:

Я надеялся подтвердить мою теорию, что все пункты, упомянутые выше как проблемы, могут быть решены, если мы внедрим наши веб-сервисы в режиме RESTful. Поскольку каждая транзакция не будет вызывать наращивание памяти, и каждая транзакция будет включать параметры безопасности с открытым ключом или подобным.

В любом случае, JRO, возможно, если я нарежу вопрос в серии, я получу лучший результат. Я буду держать этот вопрос здесь до конца дня, если я не получу ничего лучшего, я приму совет JRO.

Ответы [ 3 ]

2 голосов
/ 15 февраля 2010

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

Давайте подойдем к этому из выявленных вами проблем веб-службы (концепции вокруг вашего вопроса слишком велики для этого пространства):

  • Вы должны войти (1-я транзакция), чтобы получить токен : не уверен, почему это рассматривается как "проблема" без некоторого контекста. Является ли генерация / проверка токена проблемой? Является ли реализация для пользователя проблемой? Вам необходимо уточнить, почему это проблема.

  • Нельзя масштабировать, поскольку любой разработчик может открыть сеансы 20K и вызвать сбой сервера веб-службы. Вопросы HTTP-соединения лучше всего решать с помощью веб-серверов и балансировщиков нагрузки, а не с помощью программного управления. Если вам нужно ограничить соединение с одной конечной точкой, начните с аппаратного уровня.

  • Не является безопасным, поскольку те же пользователи, что и администратор сайта, могут использовать веб-службы. Это подразумевает реализацию безопасности для службы и то, как логика обработки учетных данных обрабатывается внутренне. , Не уверен, что сказать, кроме как исправить это - это ваша логика, вы контролируете, что делать, когда у вас есть учетные данные в руках. Если проблема в модели управления безопасностью, это другая тема. Определите суть проблемы и не путайте вашу реализацию с проверенными на практике моделями.

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

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

1 голос
/ 15 февраля 2010

Каковы характеристики масштабируемых, безопасных и простых в использовании веб-служб?

Масштабируемость, безопасность и простота использования. Помимо этого, многое будет зависеть от того, что вы пытаетесь сделать. Вы предоставили очень мало информации о том, что делает ваш веб-сервис, каковы проблемы и что вы хотели бы от него сделать.

0 голосов
/ 16 февраля 2010

Что касается безопасности, я могу предложить вам скачать бесплатную копию Руководства по безопасности веб-служб Microsoft .

Это руководство поможет вам быстро принять наиболее подходящие решения в области безопасности в контексте требований вашего веб-сервиса, предоставляя обоснование и обучение для каждого варианта. Подход, основанный на сценариях, предназначен для демонстрации ситуаций, в которых успешны различные шаблоны безопасности. Руководство также объединяет ряд матриц решений, чтобы помочь вам в применении ваших собственных критериев использования шаблонов безопасности веб-служб для удовлетворения требований вашей среды

Это очень полезно в любой среде разработки.
Приятного чтения!

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