Я разрабатываю довольно сложное приложение как с win32, так и с веб-доступом. Реализация на стороне сервера является индивидуальной, и она будет размещаться в нашей компании. HTTP-сервер может быть реализован как автономный Indy (или другой) HTTP-сервер или более традиционно с Apache/IIS.
Я хотел бы знать, каковы преимущества / недостатки автономного HTTP-сервера по сравнению с Apache / IIS с точки зрения безопасности или чего-либо еще, что вы считаете важным.
Я бы сказал, что это зависит от ваших потребностей и ожиданий. Это большая разница, если вы пишете собственный простой http-сервер, возможно, даже с поддержкой ISAPI и т. Д., Или вы пишете узкоспециализированный http-сервер / прокси / и т. д., который выполняет только узкие специализированные задачи. Например, у меня есть такой специализированный прокси и специализированная структура обработки модулей ISAPI. Плюсов, я бы сказал, не так уж и мало. Итак, плюсы:
Минусы:
Мой вердикт будет таким. Если вам просто нужен простой http-сервер для обслуживания некоторого контента, и вы будете размещать его дома, на одном или нескольких серверах, выберите Apache. Если вы делаете специализированный фрагмент кода для обработки http, который будет часто устанавливаться и вам нужен контроль, тогда разработайте свой собственный. Поверьте мне, это стоит потраченного времени. Я так рад сейчас, что я придерживался этого тогда, когда мы решали одно и то же. Сейчас у меня на многих ноутбуках установлено довольно сложное программное обеспечение, и я не могу себе представить установку Apache на каждый ноутбук. А затем настроить его так, чтобы он работал так, как мне нужно.
И Indy (со всеми его заморочками и причудами) зарекомендовал себя как очень стабильный веб-сервер из коробки. ICS здесь, вероятно, такой же, но я еще не использовал его для этого, поэтому не могу сказать. Настройка HTTP-сервера Indy смехотворно проста.
Просто мои пять копеек ;)
Под «автономным веб-сервером» вы подразумеваете встроенный в ваше приложение? Я никогда не использовал Indy, но работал над несколькими приложениями Java, используя библиотеку Jetty. Основными преимуществами этого по сравнению с прокси-сервером Apache/IIS для сервера приложений являются более простое развертывание и настройка, поскольку веб-служба тесно интегрирована в приложение и не требует дополнительной установки.
Если у вас есть существующие приложения, и это новое приложение разрешено развертывать в той же среде, я уверен, что ваши системные администраторы захотят, чтобы вы использовали существующий сервер приложений. Никому не нравится дополнительная операционная сложность, даже если вам немного проще построить. Добавление другого приложения на сервер приложений тривиально.
Другие соображения:
Безопасность. Конфигурация сети, файлы журналов, элементы управления доступом и т. д. будут иметь разные реализации по сравнению с вашими системами Apache/IIS, и обычно это означает худшую безопасность. Простые вещи, такие как проверка подлинности SSL, которые системные администраторы понимают для Apache/IIS, будут работать по-другому со встроенным веб-сервером.
Производительность: встроенный сервер, вероятно, немного более эффективен, но менее масштабируем. Ваши кодовые решения сильно влияют на это, а со встроенными серверами легко все испортить.
Разработка: мне кажется, что со встроенными серверами намного проще работать, поскольку я могу запускать их как простые Java-приложения, а не веб-приложения, например. представление Eclipse Java вместо представления J2EE с интеграцией Tomcat.
Я знаю, что это ответ с точки зрения Java, но я надеюсь, что общие идеи применимы к Delphi.
IIS и Apache — хорошо известные http-серверы.
Единственным преимуществом наличия собственного http-сервера является упрощение развертывания, что, вероятно, не будет преимуществом, если предположить, что серверная часть вашего приложения будет размещаться исключительно в вашей компании.
Еще одним преимуществом может быть производительность, вы можете добиться более высокой пропускной способности и лучшего времени отклика с помощью собственного http-сервера. Но кроме простоты развертывания и производительности я не вижу никаких других преимуществ.
Хотя минусов хватает
Обычно я разрабатываю отдельно, чтобы получить лучший опыт отладки, а затем развертываю как ISAPI dll.
У меня было несколько случаев, когда я тоже задавался этим вопросом.
Я также работал над некоторыми реализациями IInternetProtocol, чтобы позволить Internet Explorer работать с альтернативными схемами URL.
Поэтому некоторое время назад я начал проект с открытым исходным кодом: http://xxm.sourceforge.net/.
Это позволяет вам свободно переключаться между расширением ISAPI, автономным сервером и, возможно, более позднее. (Модуль Apache и обработчик протокола Firefox находятся в разработке.)
Код Delphi и HTML объединены в одни и те же исходные файлы, как и другие языки веб-скриптов, но для создания библиотек, используемых для запуска веб-сайта, используется (быстрый) компилятор Delphi.
Я написал несколько приложений, реализующих Indy HTTP Stack и предоставляющих веб-сервисы. Это может быть как легко, так и сложно. Сложность возникает, когда вы начинаете работать с потоками, поскольку вам нужно знать, как Indy создает потоки для HTTP-запросов. Таким образом, интеграция его с кодом вашего сервера может потребовать некоторых размышлений, особенно если сервер подключается к источнику данных или общим элементам управления какого-либо типа.
Кроме того, вам нужно управлять всей безопасностью, доступом к файлам и почти всем остальным, что обычный веб-сервер будет делать самостоятельно. Здесь вы можете запутаться, потому что примеров для Indy немного.
Сказав это, я обнаружил, что HTTP-сервер Indy 10 является надежным и работает очень хорошо, если вы ориентируетесь на конкретные требования, например, просто обслуживаете XML на основе того, что делает ваше приложение. У вас есть полный контроль над тем, что делает сервер, и вы можете выбрать различные модели развертывания — служба Windows, автономное приложение и т. д.
Если у вас есть хорошо спроектированное потокобезопасное приложение, то реализация HTTP поверх него может быть такой же простой, как размещение компонента Indy HTTP Server на форме или модуле. Не нужно дублировать какой-либо код только для веб-материалов.
Я всегда сосредотачиваюсь на ISAPI и использую IDDebugger для отладки этого процесса. Это дает вам лучшее из обоих миров, вашу отладку против той же версии, которую вы в конечном итоге развертываете. К сожалению, я не разрабатываю для Apache, поэтому не могу говорить о простоте его разработки.
Поскольку я использую этот метод, мне никогда не приходится беспокоиться о том, что изменения между автономной версией и версией ISAPI не будут синхронизированы, и я могу легко поместить клиентскую версию в свою тестовую среду, чтобы воспроизвести какое-либо конкретное поведение, а затем протестировать это поведение с помощью исправления и быть абсолютно уверен, что он будет работать при развертывании в полевых условиях.
Слишком много вещей, о которых нужно беспокоиться, чтобы даже подумать об использовании автономного веб-сервера с выходом в Интернет. Гораздо лучше доверить это беспокойство (и многолетний опыт) IIS/Apache.
