Если у вас возникла эта проблема - пожалуйста, прочитайте!Надеюсь, вы спасете себя много проблем, зная это.Сначала попробуйте кофе!
Возможно, вы пришли из традиционного программирования, в области, не связанные с SOA, и теперь вы пишете сервисы SOA с мышлением «традиционного программиста».Вот 4 самых важных урока, которые я выучил с момента создания сервисов SOA.
Правило № 1
Старайтесь изо всех сил не писать услуги, выполнение которых занимает длительное время.Я знаю, что это может быть ОЧЕНЬ сложно, но гораздо надежнее иметь многократные вызовы меньших операций, чем один длинный сервис, выполняющий всю работу, а затем возвращающий ответ.Например, недавно я написал сервис, который обрабатывает ВСЕ задачи.Каждая задача была сохранена в виде XML-файла на сайте IIS, и каждая задача экспортировала данные в систему, например: SharePoint.В любой момент времени в больших объемах может быть до 30 000 задач, ожидающих обработки.За последние 2 месяца мне еще не удалось обеспечить его 100% -ную надежность, это после того, как мы углубились в настройки тайм-аута в привязках IIS, AppPools и WCF.Время от времени я получал: «Поток прерывался», и не было никаких причин или объяснений, почему это происходит.Я исчерпал все онлайн-базы знаний, никто не казался мудрее.В конце концов, после того, как я не смог исправить проблемы или даже воспроизвести их надежным способом, я решил полностью переписать.Я изменил свой код, чтобы вместо обработки ВСЕХ задач обрабатывать только 1 задачу за раз.
По сути, это означало, что один веб-сервис вызывался 30 000 раз, а не один раз, но с точки зрения производительности он примерно одинаков.Каждый звонок выдает ответ быстро и выполняет намного меньше работы.Это имеет еще одно преимущество, я могу предоставить клиенту мгновенную обратную связь по каждой операции.При длинном вызове вы получаете ответ обратно в самом конце и сразу ВСЕ.
Вы также можете намного легче перехватить и повторить вызов службы, если он не прошел, потому что вам не нужно повторятьснова весь вызов для каждой операции, а просто операция, которая не удалась.
Его также проще тестировать не только из-за обратной связи, но и потому, что вы можете протестировать 1 внутреннюю операцию, без необходимости в цикле, если хотите.
Наконец, это добавляет лучшее масштабирование, если вы планируете расширить свое приложение позже, потому что вы разбили вещи на более управляемые единицы работы.Например: раньше у вас был 1 сервис, который обрабатывал ВСЕ Задачи, теперь у вас есть веб-сервис, который может обрабатывать 1 ЗАДАНИЕ, благодаря чему вы можете более легко расширить функциональность, если вам нужно обработать 10 Задач или задач по выбору.
Правило № 2 Не обновляйте существующие веб-службы ASMX до WCF 3 только потому, что считаете их лучшей технологией.WCF 3 более сложен и не очень приятен для работы или развертывания.Если вам нужно перейти на WCF, постарайтесь продержаться для версии, которая поставляется с .net 4 платформы, похоже, она была обновлена.Еще одна вещь, которую вы упустите, это то, что в WCF нет тестовых форм, поэтому вы не можете просто быстро запустить веб-браузер, чтобы протестировать свои сервисы.Если вы похожи на меня - «Делайте это просто глупо», тогда WCF 3.5 вас разочарует.
Правило № 3 IIS6 может быть изворотливым, если это вообще возможно, избегать необходимости размещать свои службы в IIS6, если вы предпочитаете надежные услуги.Я не говорю, что невозможно достичь надежности в IIS6, но это требует МНОГО работы и большого тестирования.Если вы имеете дело с критически важными сервисами, старайтесь не использовать продукт, разработанный в 2001 году.
Правило № 4 Не стоит недооценивать разработку и тестирование, необходимые для создания надежных сервисов SOA.Честно говоря, все, что я могу сказать, это масштабное мероприятие.