27 ответов
В большинстве случаев эти термины Web Server и сервер приложений используются взаимозаменяемо.
Ниже перечислены некоторые ключевые отличия в функциях веб-сервера и сервера приложений:
- Веб-сервер предназначен для обслуживания содержимого HTTP. Сервер приложений также может обслуживать HTTP-контент, но не ограничивается только HTTP. Он может быть предоставлен для поддержки других протоколов, таких как RMI/RPC
- Веб-сервер в основном предназначен для обслуживания статического контента, хотя большинство веб-серверов имеют плагины для поддержки языков сценариев, таких как Perl, PHP, ASP, JSP и т.д., через которые эти серверы могут генерировать динамический контент HTTP.
- Большинство серверов приложений имеют в своем составе Web-сервер, что означает, что сервер приложений может делать все, на что способен веб-сервер. Кроме того, сервер приложений имеет компоненты и функции для поддержки сервисов уровня приложения, таких как пул соединений, объединение объектов, поддержка транзакций, службы обмена сообщениями и т.д.
- Поскольку веб-серверы хорошо подходят для статического контента и серверов приложений для динамического контента, большинство производственных сред имеют веб-сервер, выступающий в качестве обратного прокси-сервера для сервера приложений. Это означает, что при обслуживании запроса страницы статическое содержимое (например, изображения/статический HTML) обслуживается веб-сервером, который интерпретирует запрос. Используя какой-то метод фильтрации (в основном расширение запрашиваемого ресурса), веб-сервер идентифицирует запрос динамического содержимого и прозрачно пересылает сервер приложений.
Пример такой конфигурации - сервер HTTP Apache Tomcat и сервер Oracle (ранее BEA) WebLogic. HTTP-сервер Apache Tomcat - это веб-сервер, а Oracle WebLogic - это сервер приложений.
В некоторых случаях серверы тесно интегрированы, такие как IIS и.NET Runtime. IIS - это веб-сервер. При использовании среды выполнения.NET среда IIS может предоставлять приложения.
Оба термина являются очень общими, один из них содержит другой, и наоборот в некоторых случаях.
Веб-сервер : служит для контента в Интернете с использованием протокола http.
Сервер приложений : хосты и раскрывают бизнес-логику и процессы.
Я думаю, что главное, что веб-сервер предоставляет все через HTTP-протокол, в то время как сервер приложений не ограничивается им.
Тем не менее, во многих сценариях вы обнаружите, что веб-сервер используется для создания интерфейсного сервера приложений, то есть он предоставляет набор веб-страниц, которые позволяют пользователю взаимодействовать с бизнес-правилами найденных на сервере приложений.
Это подробный ответ с некоторыми сценариями, чтобы четко понимать разницу, сходство и то, как оба могут работать совместно, и все
Сервер приложений - это термин, который иногда смешивается с веб-сервером . Хотя веб-сервер обрабатывает главным образом протоколы HTTP , сервер приложений имеет дело с несколькими различными протоколами, включая не ограниченный, HTTP .
Основной задачей веб-сервера является отображение содержимого сайта , а сервер приложений отвечает за логику , взаимодействие между пользователем и отображаемым контентом. Сервер приложений работает совместно с веб-сервером, где один отображается, а другой взаимодействует.
Информация, перемещаемая между сервером и его клиентом, не ограничивается простой разметкой экрана, а взаимодействием между ними.
В большинстве случаев сервер создает это взаимодействие через API-интерфейс компонента , например J2EE (платформа Java 2), EJB (Enterprise JavaBean) и другие различные модели прикладных программ.
Пример:
Лучший способ понять разницу между сценариями, в которых сервер приложений работает с веб-сервером, и сценарий, в котором нет сервера приложений, - через интернет-магазин.
Сценарий 1: веб-сервер без сервера приложений
у вас есть интернет-магазин с только веб-сервером и сервером приложений. На сайте будет представлен экран, на котором вы можете выбрать продукт. Когда вы отправляете запрос, сайт выполняет поиск и возвращает результат HTML обратно своему клиенту. Веб-сервер отправляет ваш запрос непосредственно на сервер базы данных (будьте терпеливы, я объясню это в нашем следующем самородок) и ждет ответа. После получения веб-сервер формирует ответ в файл HTML и отправляет его в ваш веб-браузер. Эта обратная и четвертая связь между сервером и сервером базы данных происходит каждый раз, когда выполняется запрос.
Сценарий 2. Веб-сервер с сервером приложений
если запрос, который вы хотите запустить, уже был выполнен ранее, и с тех пор данные не изменились, сервер будет генерировать результаты без необходимости отправки запроса на сервер базы данных. Это позволяет запросить в реальном времени, когда второй клиент может получить доступ к одной и той же информации и получать достоверную информацию в режиме реального времени, не отправляя другой дублирующий запрос на сервер базы данных. Сервер в основном действует как промежуточный сервер базы данных и веб-сервер. Это позволяет извлекать информацию, которую можно повторно использовать, в то время как в первом сценарии, поскольку эта информация встроена в конкретную и "настроенную" HTML-страницу, это не является многоразовым процессом. Второй клиент должен будет снова запросить информацию и получить другую встроенную страницу HTML с запрошенной информацией - очень неэффективно. Не говоря уже о том, что этот тип сервера очень гибкий из-за его способности управлять своими собственными ресурсами, включая безопасность, обработку транзакций, обмен сообщениями и объединение ресурсов.
Для поддержки такого множества сложных задач этот сервер должен иметь встроенную избыточность, большую вычислительную мощность и большое количество ОЗУ для обработки всех данных, которые он вытягивает в реальном времени.
Надеюсь, что это поможет.
Как указывал Rutesh и jmservera, различие является нечетким. Исторически сложилось, что они были разными, но через 90 эти две ранее отличающиеся категории смешивали черты и эффективно сливались. На данный момент лучше всего предположить, что категория продуктов "Сервер приложений" является строгим надмножеством категории "веб-сервер" .
Некоторая история. В ранние дни браузера Mosaic и гиперссылки на контент возникла эта вещь, называемая "веб-сервером", которая обслуживала содержимое веб-страницы и изображения через HTTP. Большая часть контента была статичной, а протокол HTTP 1.0 был всего лишь способом отправки файлов. Быстро категория "веб-сервер" эволюционировала, чтобы включить возможности CGI - эффективно запускать процесс на каждом веб-запросе для создания динамического контента. HTTP также созрел, и продукты стали более сложными, с кешированием, защитой и функциями управления. По мере того, как технология созрела, мы получили специфическую для Java технологию на стороне сервера от Kiva и NetDynamics, которые в конечном итоге слились в JSP. Microsoft добавила ASP, я думаю, в 1996 году к Windows NT 4.0. Статический веб-сервер узнал некоторые новые трюки, так что это был эффективный "сервер приложений" для многих сценариев.
В параллельной категории сервер приложений развился и существовал в течение длительного времени. компании поставляли продукты для Unix, такие как Tuxedo, TopEnd, Encina, которые были философски получены из приложений управления и мониторинга приложений для мэйнфреймов, таких как IMS и CICS. Microsoft предлагала Microsoft Transaction Server (MTS), который позже превратился в COM+. Большинство из этих продуктов указали "закрытые" протоколы коммуникаций, специфичные для продукта, для соединения "толстых" клиентов с серверами. (Для Encina протокол comms был DCE RPC, для MTS - DCOM и т.д.). В 1995/96 годах эти традиционные серверные продукты приложений начали внедрять базовые возможности HTTP-связи, сначала через шлюзы. И линии начали размываться.
Веб-серверы стали все более зрелыми в отношении обработки более высоких нагрузок, более concurrency и лучших функций. Серверы приложений поставляли все больше и больше возможностей связи на основе HTTP.
В этот момент линия между "сервером приложений" и "веб-сервером" является нечеткой. Но люди продолжают использовать термины по-разному, в качестве акцента. Когда кто-то говорит "веб-сервер" , вы часто думаете, что HTTP-ориентированный, веб-интерфейс, ориентированные приложения. Когда кто-то говорит "Сервер приложений", вы можете подумать "более тяжелые нагрузки, функции предприятия, транзакции и очередность, многоканальная связь (HTTP + больше). Но часто это тот же продукт, который обслуживает оба набора требований к рабочей нагрузке.
веб сервер
Запустите python -m "SimpleHTTPServer" и перейдите по адресу http://localhost: 8080 . То, что вы видите, это веб-сервер в его работе. Сервер просто обслуживает файлы по HTTP, хранящиеся на вашем компьютере. Ключевым моментом является то, что все это делается поверх протокола HTTP. Также существуют FTP-серверы, например, которые делают то же самое (обслуживая сохраненные файлы), но поверх другого протокола.
Сервер приложений
Скажем, у нас есть крошечное приложение, как показано ниже (фрагмент из Flask).
@app.route("/") def homepage(): return "My homepage" @app.route("/about") def about(): return "My name is John"
Небольшой пример программы отображает URL / на homepage() функции homepage() а /about - на функцию about() .
Для запуска этого кода нам нужен сервер приложений (например, Gunicorn) - программа или модуль, который может прослушивать запросы от клиента и, используя наш код, возвращать что-то динамически. В примере мы просто возвращаем очень плохой HTML.
О какой бизнес-логике говорят все остальные? Итак, поскольку URL-адрес отображается где-то конкретно в нашей кодовой базе, мы гипотетически показываем некоторую логику о том, как работает наша программа.
резюмируя
веб-сервер - обслуживает файлы, хранящиеся где-то (чаще всего.css,.html,.js). Обычными веб-серверами являются Apache, Nginx или даже Python SimpleHTTPServer.
Сервер приложений - обслуживает файлы, созданные на лету. По сути, большинство веб-серверов имеют какие-то плагины или даже поставляются со встроенными функциями для этого. Существуют также строгие серверы приложений, такие как Gunicorn (Python), Unicorn (Ruby), uWSGI (Python) и т.д.
Обратите внимание, что вы действительно можете создать веб-сервер с кодом сервера приложений. Это делается в некоторых случаях во время разработки, когда вы не хотите, чтобы на вашем компьютере работало несколько миллиардов различных серверов.
Как уже было сказано ранее, веб-серверы обрабатывают HTTP-петиции, а серверы приложений обрабатывают петиции для распределенных компонентов. Таким образом, возможно, самый простой способ понять разницу - сравнить два продукта в отношении среды программирования, которую они предлагают.
Веб-сервер → среда программирования
Причал: сервлет
Apache: Php, CGI
Серверы приложений → среда программирования
Сервер приложений WebLogic: EJB
Важнейшим отличием является то, что серверы приложений поддерживают технологию распределенного компонента , предоставляя такие функции, как удаленный вызов и распределенные транзакции, такие как EJB в мире Java или COM +/strong > на платформе Microsoft. Http-сервер часто поддерживает некоторые более простые среды программирования, часто скрипты, такие как ASP (.NET) в случае Microsoft или Servlet, включая JSP и многие другие в случае Java или PHP и CGI в случае Apache.
Другие возможности, такие как балансировка нагрузки, кластеризация, сеансовый переход, объединение пулов и т.д., которые раньше были в области серверов приложений, становятся доступными на веб-серверах, а также напрямую или через некоторые сторонние продукты.
Наконец, стоит отметить, что картина искажена "легкими контейнерами", такими как Spring Framework, которые чаще всего дополняют назначение серверов приложений более простым способом и без инфраструктуры сервера приложений. И поскольку аспект распространения в приложениях перемещается из распределенного компонента в сторону парадигмы обслуживания и архитектуры SOA, для традиционных серверов приложений все меньше и меньше места.
Веб-сервер исключительно обрабатывает запросы HTTP/HTTPS. Он служит для содержания в Интернете с использованием протокола HTTP/HTTPS.
Сервер приложений обслуживает бизнес-логику для прикладных программ через любое количество протоколов, возможно, включая HTTP. Прикладная программа может использовать эту логику так же, как вызовет метод для объекта. В большинстве случаев сервер предоставляет эту бизнес-логику через компонентный API, такой как компонентная модель EJB (Enterprise JavaBean), найденная на серверах приложений Java EE (Java Platform, Enterprise Edition). Главное, что веб-сервер предоставляет все через HTTP-протокол, в то время как сервер приложений не ограничен этим. Таким образом, сервер приложений предлагает гораздо больше услуг, чем веб-сервер, который обычно включает в себя:
- API (собственный или нет) API
- Управление жизненным циклом объекта
- Управление состоянием (сеанс)
- Управление ресурсами (например, пулы подключений к базе данных)
На большинстве серверов приложений Web-сервер является их неотъемлемой частью, что означает, что сервер приложений может делать все, на что способен веб-сервер. Кроме того, сервер приложений имеет компоненты и функции для поддержки сервисов уровня приложения, таких как объединение пулов, объединение объектов, поддержка транзакций, службы обмена сообщениями и т.д.
Сервер приложений может (но не всегда) запускаться на веб-сервере для выполнения программной логики, результаты которой затем могут быть доставлены веб-сервером. Этот пример сценария сервера веб-сервера/сервера приложений. Хорошим примером в мире Microsoft является отношение Internet Information Server/SharePoint Server. IIS - это веб-сервер; SharePoint - это сервер приложений. SharePoint сидит "сверху" IIS, выполняет определенную логику и обслуживает результаты через IIS. В мире Java существует, например, аналогичный сценарий с Apache и Tomcat.
Поскольку веб-серверы хорошо подходят для статического контента и серверов приложений для динамического контента, большинство производственных сред имеют веб-сервер, выступающий в качестве обратного прокси-сервера для сервера приложений. Это означает, что при обслуживании запроса страницы статическое содержимое, такое как images/Static html, обслуживается веб-сервером, который интерпретирует запрос. Используя какой-то метод фильтрации (в основном расширение запрашиваемого ресурса), веб-сервер идентифицирует запрос динамического содержимого и прозрачно пересылает сервер приложений.
Пример такой конфигурации - Apache HTTP Server и BEA WebLogic Server. HTTP-сервер Apache - это веб-сервер, а BEA WebLogic - сервер приложений. В некоторых случаях серверы тесно интегрированы, такие как IIS и.NET Runtime. IIS - это веб-сервер. при наличии среды выполнения.NET. IIS способен предоставлять сервисы приложений.
Web Server Programming Environment Apache PHP, CGI IIS (Internet Information Server) ASP (.NET) Tomcat Servlet Jetty Servlet Application Server Programming Environment WAS (IBM WebSphere Application Server) EJB WebLogic Application Server (Oracle"s) EJB JBoss AS EJB MTS COM+
Основное различие между веб-сервером и сервером приложений заключается в том, что веб-сервер предназначен для обслуживания статических страниц, например HTML и CSS, тогда как сервер приложений отвечает за генерацию динамического содержимого путем выполнения кода на стороне сервера, например, JSP, сервлета или EJB.
Какой из них я должен использовать?
Как только вы узнаете разницу между веб-сервером и сервером приложений и веб-контейнерами, легко определить, когда их использовать. Вам нужен web server такой как Apache HTTPD, если вы обслуживаете статические веб-страницы. Если у вас есть Java-приложение с JSP и сервлетом для генерации динамического контента, вам понадобятся web containers такие как Tomcat или Jetty. Хотя, если у вас есть приложение Java EE, использующее EJB, распределенные транзакции, обмен сообщениями и другие полезные функции,
вам нужен полноценный application server такой как JBoss, WebSphere или Oracle WebLogic.
Веб-контейнер является частью веб-сервера, а веб-сервер является частью сервера приложений.
Веб-сервер состоит из веб-контейнера, в то время как сервер приложений состоит из веб-контейнера и EJB-контейнера.
Веб-сервер выполняет HTTP-протокол для обслуживания веб-страниц. Сервер приложений может (но не всегда) запускаться на веб-сервере для выполнения программной логики, результаты которой затем могут быть доставлены веб-сервером. Этот пример сценария сервера веб-сервера/сервера приложений.
Хорошим примером в мире Microsoft является отношение Internet Information Server/SharePoint Server. IIS - это веб-сервер; SharePoint - это сервер приложений. SharePoint сидит "сверху" IIS, выполняет определенную логику и выполняет результаты через IIS.
В мире Java существует, например, аналогичный сценарий с Apache и Tomcat.
Сервер приложений обычно разрабатывается и развертывается для облегчения более длительных процессов, которые также будут более ресурсоемкими.
Веб-сервер используется для коротких всплесков, которые обычно не являются ресурсоемкими. Это в основном облегчает обслуживание веб-трафика.
С одной стороны, веб-сервер обслуживает веб-контент (HTML и статический контент) по протоколу HTTP. С другой стороны, сервер приложений представляет собой контейнер, на котором вы можете создавать и выставлять бизнес-логику и процессы клиентским приложениям с помощью различных протоколов, включая HTTP, в архитектуре n-уровня.
Таким образом, сервер приложений предлагает гораздо больше услуг, чем веб-сервер, который обычно включает в себя:
- API (собственный или нет) API
- Управление жизненным циклом объекта,
- Управление состоянием (сеанс),
- Управление ресурсами (например, пулы подключений к базе данных),
- Балансировка нагрузки, сбой...
В терминах Java есть еще один: веб-контейнер (или, точнее, контейнер сервлетов). Это, скажем, между веб-сервером и сервером приложений. Веб-контейнер в терминах Java - это сервер приложений, который в основном реализует только часть JSP/Servlet Java EE и не имеет нескольких основных частей Java EE, таких как поддержка EJB. Примером является Apache Tomcat.
Граница между этими двумя становится все более тонкой.
Серверы приложений предоставляют бизнес-логику клиенту. Таким образом, подобный сервер приложений включает в себя набор методов (не обязательно, хотя и может быть сетевым компьютером, позволяющим многим запускать на нем программное обеспечение) для выполнения бизнес-логики. Таким образом, он просто выводит желаемые результаты, а не HTML-контент. (аналогично вызову метода). Так что это не строго HTTP-протокол.
Но веб-серверы передают HTML-контент в веб-браузеры (строго на основе HTTP). Веб-серверы могли обрабатывать только статические веб-ресурсы, но появление сценариев на стороне сервера помогло веб-серверам также обрабатывать динамическое содержимое. Где веб-сервер принимает запрос и направляет его на script (PHP, JSP, CGI-скрипты и т.д.), Чтобы СОЗДАТЬ HTML-контент, который будет отправлен клиенту. Затем веб-сервер знает, как отправить их обратно клиенту. ПОТОМУ ЧТО, что действительно знает веб-сервер.
Сказав это, в наши дни разработчики используют оба эти метода вместе. Если веб-сервер принимает запрос и затем вызывает script для создания HTML, НО script снова вызовет ЛОГИКУ сервера приложений (например, Получить данные транзакции), чтобы заполнить содержимое HTML.
Таким образом, в этом случае оба сервера были эффективно использованы.
Поэтому.... Мы можем с уверенностью сказать, что в настоящее время в большинстве случаев веб-серверы используются в качестве подмножества серверов приложений. НО это не так.
Я прочитал много статей по этой теме и нашел довольно удобной.
Сервер приложений - это машина (исполняемый процесс, запущенный на какой-либо машине, фактически), который "прослушивает" (на любом канале, используя любой протокол), для запросов клиентов для любой предоставляемой им услуги, а затем делает что-то на основе эти просьбы. (может или не может потребовать ответа клиенту)
Веб-сервер работает на компьютере, который "прослушивает" специально по каналу TCP/IP с использованием одного из "интернет-протоколов" (http, https, ftp и т.д.) и делает все, что он делает на основе этих входящие запросы... Как правило, (как определено на языке оригинала), он извлекал/сгенерировал и вернул html-страницу клиенту, либо извлечен из статического файла html на сервере, либо построен динамически на основе параметров входящего запроса клиента.
Все вышеперечисленное просто слишком усложняет что-то очень простое. Сервер приложений содержит веб-сервер, на сервере приложений есть еще несколько дополнений/расширений к нему, чем стандартные веб-серверы. Если вы посмотрите на TomEE в качестве примера:
CDI - Apache OpenWebBeans EJB - Apache OpenEJB JPA - Apache OpenJPA JSF - Apache MyFaces JSP - Apache Tomcat JSTL - Apache Tomcat JTA - Apache Geronimo Transaction Servlet - Apache Tomcat Javamail - Apache Geronimo JavaMail Bean Validation - Apache BVal
Вы увидите, что Tomcat (веб-контейнер/сервер) - это еще один инструмент в арсенале серверов приложений. Вы можете получить JPA и другую технику на веб-сервере, если хотите, но серверы приложений просто упакуют все эти вещи для вашего удобства. Чтобы быть полностью классифицированным как сервер приложений, вам, по существу, необходимо выполнить список инструментов, определенных некоторым стандартом.
Фактически Apache - это веб-сервер, а Tomcat - сервер приложений. Когда HTTP-запрос поступает на веб-сервер. Затем статическое содержимое отправляется обратно в браузер через веб-сервер. Есть ли логика и сделать это, а затем этот запрос отправляется на сервер приложений. после обработки логики, тогда ответ отправляется на веб-сервер и отправляется клиенту.
A Веб-сервер может быть либо компьютерной программой, либо компьютером, на котором запущена программа, которая отвечает за прием HTTP-запросов от клиентов, отсылает ответы HTTP вместе с дополнительным содержимым данных, которые обычно являются веб-страницами таких как документы HTML и связанные объекты на нем.
Сервер приложений - это вид программного обеспечения, который будет поставлять различные приложения на другое устройство. Это компьютер, найденный в офисной или университетской сети, который позволяет всем в сети запускать программное обеспечение с одной и той же машины.
Сервер приложений является расширенной
версией сервера в операционной системе Windows Server ® 2008. Новая версия
сервера приложений предоставляет интегрированную среду для развертывания и выполнения
пользовательских дел на сервере приложений. Эти приложения отвечают на запросы,
поступающие по сети от удаленных клиентских компьютеров или из других приложений.
Как правило, для развертывания и запуска на сервере приложений пользователь
производит одно или более из следующих действий:
- Internet Information Services (IIS) (протокол
передачи гипертекста (HTTP) сервер, встроенный в Windows Server) - Microsoft ®.NET Framework
версии 3.0 и 2.0. (Если у вас есть приложения, построенные с.NET
Framework 3.5, вы можете загрузить и установить.NET Framework 3.5 на
операционной системы.) - ASP.NET
- COM +
- Очереди сообщений
- Веб-службы, которые построены с Windows Communication Foundation (WCF)
Мы рекомендуем использовать роль сервера
приложений Windows Server 2008 выполняемую приложениями, которые зависят от
служб роли или компонентов, которые являются частью комплексной роли сервера
приложений и выбрать во время процесса установки. Примером может быть
определенна конфигурация Microsoft BizTalk ® Server, которая использует набор
служб роли или компонентов, которые являются частью среды сервера приложений.
Обычно роль сервера приложений необходима
при развертывании бизнес-приложения в рамках вашей организации (или
разработанного независимый поставщик программного обеспечения (ISV) для вашей
организации), и когда разработчик указал, что конкретная роль службы требуются.
К примеру ваша организация может иметь приложение обработки заказа, доступ к
записи клиентов, которые хранятся в базе данных. Приложение получает доступ к
сведения о клиенте через набор веб-служб WCF. В этом случае можно настроить
один компьютер Windows Server 2008 в качестве сервера приложений и базы данных
можно установить на том же компьютере или на другом компьютере.
Не все серверные приложения выгодны для
установки роли сервера приложений. Например роль сервера приложений не является
необходимой для поддержки сервера Microsoft Exchange Server или Microsoft SQL
Server на Windows Server 2008.
Чтобы определить, если роль сервера
приложений является полезным для вашей организации бизнес-приложений, есть
администраторы тесно связанные с разработчиками приложений для выявления
требований приложения, например, она использует ли.NET Framework 3.0 или COM +
компоненты.
Что такое сервер приложений?
Сервер приложений предоставляет следующее:
- Среда выполнения поддерживает эффективное
развертывание и управление высокопроизводительных серверных
бизнес-приложений. Эти приложения способны обслуживать запросы от
удаленных клиентских систем, включая веб-браузеры, соединения из Интернета
или из корпоративной сети или интрасети и систем удаленного компьютера,
которые может отправлять запросы в виде сообщений. - .NET Framework 3.0, который предоставляет
разработчикам упрощенную модель программирования для подключенных
серверных приложений. Разработчики могут использовать встроенный.NET
Framework библиотеки для многих функций приложения, включая ввода/вывода
(I/O), числовые и обработка текста, доступ к базе данных, XML обработку,
управление транзакциями, рабочий процесс и веб-служб. Для системных
администраторов.NET Framework обеспечивает безопасную и высокую
производительность выполнения средой выполнения для серверных приложений,
а также упрощенные приложения настройки и развертывания среды. - Установка Windows Server 2008 в новый, удобный для
пользователя мастера добавления ролей, помогает вам выбрать службы ролей и
функции, которые необходимы для запуска приложений. Мастер добавления
ролей автоматически устанавливает все компоненты, необходимые для данной
роли службы и делает его более легким для вас, для создания и
предоставления компьютер в качестве сервера приложений для
бизнес-приложений.
Кто будет заинтересован в этой роли?
Эта информация о роли сервера приложений
является главным образом для информационных технологий (ИТ) специалистов, ответственных
за развертывание и обслуживание Организации линии бизнес-приложений (LOB).
Бизнес-приложения обычно разрабатываются в вашей организации или для вашей
организации.
Среда сервера приложений состоит из одного
или нескольких серверов под управлением Windows Server 2008, настроенных с роли сервера приложений. Это включает серверы,
выполните следующие действия:
- Приложения, построенные с.NET Framework 3.0
- Приложения, построенные для использования COM +,
очереди сообщений, веб-службы и распределенные транзакции - Подключение к интрасети или Интернету для обмена
информацией - Приложения, которые предоставляют или
использовать веб-службы - Приложения, которые предоставляют веб-страниц
- Взаимодействовать с другими удаленными системами,
работающие на разных платформах и операционных системах
Расширенный среды сервера приложений может
также включать следующее:
- Домен клиентские компьютеры и их пользователей
- Компьютеры, которые используются главным образом
для управления серверами приложений - Серверы инфраструктуры, которые работают ресурсы,
такие как доменных служб Active Directory (AD DS) или другие репозитории
протокола LDAP (Lightweight Directory Access Protocol), службы
сертификации, шлюзы безопасности, процесс серверы, интеграции серверов,
приложений или шлюзы данных или базы данных
Какие новые возможности предоставляет эта роль?
Новый, расширена версию сервера
приложений, роль устанавливается с помощью мастера добавления ролей в
диспетчере сервера. Администраторы, которые имеют бизнес-приложений,
построенных с.NET Framework 3.0 может обнаружить, что настройка среды
размещения для этих приложений проще, с этой ролью сервера. Мастер добавления
ролей руководство администратора через процесс выбора служб роли или
функциональных возможностей, доступных в этой роли и могут быть необходимы для
выполнения конкретных бизнес-приложений.
Ядро сервера приложений
Ядро сервера приложений – это группа
технологий, устанавливаемых по умолчанию при установке роли сервера приложений.
По существу, это ядро сервера приложений.NET Framework 3.0. (Если у вас есть
приложения, построенные с.NET Framework 3.5, вы можете загрузить и
установить.NET Framework 3.5 на операционной системы.)
Windows Server 2008 включает.NET Framework
2.0, независимо от любой роли сервера, которая устанавливается. .NET Framework
2.0 содержит Common Language Runtime (CLR), которая обеспечивает среды
выполнения кода, которая обеспечивает безопасное выполнение кода, его
упрощенное развертывание, и поддержку совместного использования нескольких
языков, а также обширные библиотеки для создания приложений.
Добавляетядро сервера приложений.NET Framework 3.0
возможности базовой линии.NET Framework 2.0 возможности. Для получения
дополнительных сведений.NET Framework 3.0, см.Центр разработчиков NET Framework
(http://go.microsoft.com/fwlink/?LinkId = 81263).
Почему важна эта функциональная
возможность?
Ключевые компоненты ядра сервера
приложений установлены как набор библиотек кода и.ЧИСТЫЕ сборки. Ниже приведены
ключевые компоненты ядра сервера приложений:
- Windows Communication Foundation (WCF)
- Windows Workflow Foundation (WF)
- Windows Presentation Foundation (WPF)
Из этих трех, WCF и WF часто используются
в серверных приложений, а также-приложениях клиента. WPF используется
преимущественно в клиентских приложениях, и это не обсуждается далее здесь.
Дополнительные сведения о WPF, см. в Windows Presentation Foundation (http://go.microsoft.com/fwlink/?LinkId = 78407).
WCF является Microsoft унифицированную
модель программирования для создания связанных приложений, использующих
веб-службы для взаимодействия друг с другом. Эти приложения являются также
известен как сервис ориентированных приложений (SOA), и они становятся все
более важным для бизнеса. Разработчики могут использовать WCF для создания
SOA-приложений, которые используют безопасные, надежные, транзакционные
веб-служб, общаться на платформах и взаимодействовать с существующими системами
и приложениями в вашей организации.
WCF позволяет разработчикам создавать или
комбинировать различные технологии, которые сегодня доступны для создания
распределенных приложений (COM + и.Услуги NET Enterprise, очереди сообщений.NET
Remoting, ASP.Чистый веб-служб и расширения веб-служб (WSE)) таким образом,
чтобы иметь смысл для бизнеса и вычислительной среды вашей организации. Для
получения дополнительных сведений о WCF видеть Windows Communication
Foundation? (http://go.microsoft.com/fwlink/?LinkId = 81260).
WF – это модель и ядро программирования
для создания приложений, поддерживающих бизнес-процессы, быстро на Windows
Server 2008. Рабочий процесс - это набор мероприятий, которые описывают процесс
реального мира, такие, как процесс заказа покупки. Рабочий процесс обычно
описывается и рассматривать графически - то, как блок-схемы. Описание рабочего
процесса часто называют «модели». Рабочие элементы проходят через модель
рабочего процесса от начала до конца.
Рабочие элементы или видов деятельности в
рамках модели может выполняться людьми или системами или компьютеров. Хотя это
можно описать рабочий процесс в традиционных языков программирования как ряд
шагов и условий, для более сложных рабочих процессов или рабочие процессы,
которые поддерживают более простые изменения, проектирование процесса
графически и хранения что дизайн как модель обычно является гораздо более
надлежащие и гибкие.
WF поддерживает рабочий процесс системы и
документооборота в различных сценариях, включая следующие:
- Рабочий процесс в бизнес-приложений
- Последовательный поток экранов, страниц и
диалоговые окна, представленные в ответ на взаимодействие пользователя с
пользовательским интерфейсом (UI) для данного пользователя - Документ центре рабочий процесс, например,
обработка заказа на покупку или медицинские записи - Взаимодействие документооборота, таких, как
отправка электронной почты для бизнес-клиентов и получение электронной
почты от клиента - Составной рабочий процесс для SOA
- Бизнес правил-управляемые делом рабочий процесс,
например: «В понедельник в 17: 00, отправить запрос на обновление каталога
для деловых партнеров». - Рабочий процесс для управления системами
Что работает по-другому?
Хотя есть роль сервера приложений в
Windows Server 2003, Новая, расширенная роль сервера приложений, доступных в ОС
Windows Server 2008 не просто обновление от средства настройки сервера
приложений, который включен в Windows Server 2003 или более ранних версий
операционной системы. Так как роль функциональность является совершенно новой,
администраторы должны осознавать, что не существует миграции пути для средства
настройки сервера приложений с Windows Server 2003 или более ранних
операционных систем.
Как решить эти проблемы?
Если обновления сервера до Windows Server
2008 с Windows Server 2003 или более ранних версий операционной системы, и вы
хотите использовать возможности роли сервера приложений, необходимо
переустановить роль сервера приложений с помощью мастера добавления ролей в
диспетчере сервера. Как настроить Windows Server 2008 с правильным применением
служб с помощью мастера добавления ролей в диспетчере сервера, можно легко
переместить ваши приложения с Windows Server 2003 до Windows Server 2008.
Когда следует использовать роль сервера
приложений?
Если на сервере бизнес-приложений, которые
необходимо развертывать и управлять требуется одно или несколько из следующих
технологий: Microsoft.NET Framework 3.0, очередь сообщений, COM + или распределенные
транзакции, следует настроить ваш сервер в роли сервера приложений.
Как подготовиться к установке?
Как часть вашей подготовки для установки
роли сервера приложений создаете перечень приложений, которые будут выполняться
на этом сервере. Если вы являетесь администратором, работа с разработчиками или
ISV, который разработал приложения для определения поддержки технологий и
конфигурации, которые должны присутствовать на сервере для запуска приложений.
Затем сопоставьте эти технологии служб ролей, которые описаны в следующих
разделах, так что вы можете выбрать и должным образом настроить службы во время
установки роли сервера. Обычно разработчик или ISV список из технологий,
которые должны быть установлены для этого приложения, например,.NET Framework
3.0.
Веб-сервер
Этот параметр устанавливает службы IIS
версии 7.0, веб-сервер, встроенный в Windows Server 2008. IIS была доступна в
Windows Server в течение многих лет, но значительно был пересмотрен для Windows
Server 2008 для обеспечения улучшения в производительности, безопасности,
управления, поддержки, надежности и модульности.
Службы IIS предоставляют следующие
основные преимущества:
- IIS делает возможным для сервера приложений
провести внутренние или внешние веб-сайты или услуги со статическим или
динамическим содержимым.
ASP.NET приложения, которые доступны в веб-обозревателе.- Службы IIS обеспечивают поддержку для запуска
веб-служб, которые построены с Microsoft WCF или ASP.NET.
Доступ К сети COM +
Этот параметр добавляет COM + доступ К
сети для удаленного вызова приложений, которые построены и размещенных в COM +
и корпоративных служб компонентов. Такие приложения называют также компонентами
корпоративных служб.
Доступ К сети COM + является одной из
возможностей удаленного вызова, поддерживается в Windows Server начиная с
Windows 2000 Server, и он по-прежнему поддерживаться в Windows Server 2008.
Более новые приложения обычно использовать WCF для поддержки удаленного вызова,
потому что WCF обеспечивает взаимодействие на нескольких платформах.
Служба активации процессов Windows
Этот параметр добавляет службы активации
процессов Windows (WAS). Можно запустить и останавливать приложения,
динамически, основываясь на сообщениях, получаемых по сети через HTTP, очереди
сообщений, TCP и именованные каналы протоколов. Динамические запуск и остановка
приложений означает, что более эффективное использование ресурсов сервера. БЫЛО
это новая услуга в Windows Server 2008.
Общий доступ К портам Net.TCP
Этот параметр добавляет портам Net.TCP.
Эта служба роли позволяет нескольким приложениям использовать один TCP-порт для
входящих сообщений. Например SOA, который построен с WCF могут совместно
использовать тот же порт. Совместное использование портов требуется часто когда
настройки брандмауэра или сетевые ограничения позволяют лишь ограниченное число
открытых портов или когда несколько отдельных экземпляров приложения WCF должна
быть запущена и в то же время.
Таким образом, чтобы несколько WCF
приложения могут совместно использовать порты (мультиплексирование), портам
Net.TCP выполняет мультиплексирование. Портам Net.TCP принимает входящие
запросы на подключение, используя протокол TCP. Затем автоматически перенаправляет
входящие запросы различным службам WCF, основанный на целевых адресов запросов.
Общий доступ к портам работает только тогда, когда приложения WCF используют
протокол net.tcp для входящих соединений. Общий доступ к портам Net.TCP – это
новая услуга в Windows Server 2008.
Распределенные транзакции
Приложения подключиться и выполнять
обновления нескольких баз данных или других транзакций ресурсов могут
потребовать, чтобы эти обновления выполняются с «логики» семантики транзакций -
это технология, которая обеспечивает, что каждая часть транзакции является
полным или откат всей транзакции ее в первоначальное состояние.
Поддержка распределенных транзакций в
Windows Server 2008 предоставляет способ для приложений для этого требования
выполнены. Поддержка распределенных транзакций в Windows Server с Microsoft
Windows NT ® Server 4.0, и эта поддержка продолжается в Windows Server 2008.
Доступна ли эта роль во всех выпусках Windows Server 2008?
Сервер приложений доступен в следующих
выпусках Windows Server 2008:
- Windows Server 2008 стандарт
- Windows Server 2008 Enterprise
- Windows Server 2008 Datacenter
- Windows Server 2008 для систем на базе Itanium
Роль сервера приложений не доступны в
следующем выпуске Windows Server 2008:
- Windows Web Server 2008
Он ведет себя по-разному в некоторых
изданиях?
Сервера приложений, поведение не меняется
основаны на выпуске Windows Server 2008.
Доступен в 32-разрядных и 64-разрядных
версиях?
Сервер приложений доступен в 32-разрядных
и 64-разрядных версиях Windows Server 2008.
Что? Какое
еще серверное программирование? Что это за беда? И зачем она нам нужна?
Мы, вроде
бы, научились создавать Web-страницы в среде Dreamweaver. Мы даже научились
создавать с его помощью целые Web-сайты и публиковать их на Web-сервере. Мы
изучили две разновидности дизайна страниц: фреймовый, когда сайты строятся на
основе наборов фреймов, и табличный, когда содержимое страницы помещается в
большую сложную таблицу. Мы познакомились с таблицами стилей, метатегами и серверными
директивами. И, наконец, узнали о Web-программировании и Web-сценариях, позволяющих
добавить "жизни" нашим статичным страничкам. Что же еще надо для счастья?
Да, изученного
ранее нам вполне хватит, чтобы создавать вполне приличные сайты. Многие Web-дизайнеры
на этом и останавливаются. Но ведь мы хотим большего, не так ли?
Так давайте
же сделаем следующий шаг - перейдем от страниц, хранящихся в файлах на сервере,
к страницам, генерируемым специальными программами. Как раз написанием таких
программ и занимается серверное программирование.
Но давайте
по порядку. И начнем мы с того, что выясним, зачем нужны эти серверные программы.
Что
такое серверное программирование
Действительно,
что это такое и с чем его едят?
Зачем
нужны серверные программы
Вы когда-нибудь
посещали интернет-магазин? Например, популярнейший "Озон" (http://www.ozon.ru) .
Помните, как там выполняется заказ товара?
Если не помните
или вообще не знаете, что такое интернет-магазин, давайте вспомним (или узнаем).
Вы заходите
на Web-страничку, описывающую нужный вам товар. После долгих мук совести вы
все-таки решаетесь на покупку и щелкаете на кнопке Купить.
После этого
вы получаете несколько Web-страниц, где можете задать свой адрес, способы оплаты
и доставки товара и, наконец, подтвердить покупку. Все это вы делаете, щелкая
соответствующие кнопки и вводя данные в соответствующие поля ввода, расположенные
прямо на страницах.
Что происходит
при этом? Как обрабатываются введенные вами данные? Неужели самим Web-обозревателем?
Отнюдь. Эти
данные обрабатываются на Web-сервере.
Интернет-магазин
- просто один из примеров, пришедших в голову автору, являющемуся поклонником
и постоянным клиентом вышеупомянутого "Озона". Точно так же работают
серверы электронной почты, основанной на Web, поисковые машины, электронные
доски объявлений, форумы, вообще, любые Web-сайты, принимающие от посетителя
какие-то данные и обрабатывающие их. Во всех этих случаях Web-обозреватель принимает
от посетителя данные и отправляет их Web-серверу, который обрабатывает их и
выдает результат обработки в виде автоматически сформированной Web-страницы.
Как это происходит
на деле? Сейчас мы это выясним. И первым делом ответим на вопрос...
Как
Web-сервер
обрабатывает данные пользователя
Итак, каким
же образом программа Web-сервера обрабатывает данные, отправленные ей пользователем?
Да никак.
Web-сервер не приспособлен их обрабатывать. Его задача: прием от Web-обозревателя
запроса на файлы (Web-страницы, таблицы стилей, графические изображения, фильмы,
звуки, архивы, исполняемые файлы и т. п.), поиск этих самых файлов на жестких
дисках серверного компьютера и отправка найденных файлов назад Web-обозревателю.
Это его основная задача. Конечно, некоторые особо мощные серверы могут выполнять
дополнительные действия над отправляемыми файлами перед собственно их отправкой
(в частности, выполнять серверные директивы). Есть и программы-"многостаночники",
выполняющие функции не только Web-сервера, но и сервера FTP, почты, новостей
UseNet и бог знает чего еще. Но основная функция: простая выдача файлов по требованиям
клиентов -и не более того.
Секрет в том,
что данные посетителя обрабатываются не самим Web-сервером. Для этого применяются
специальные программы, работающие вместе с Web-сервером на том же серверном
компьютере. Они называются серверными программами,
не имеют интерфейса
пользователя и "общаются" только с Web-сервером, принимают от него
введенные пользователем данные и возвращают ему результат. Этим они коренным
образом отличаются от клиентских программ, работающих непосредственно с пользователем.
(К клиентским программам относится, в частности, ваш любимый Web-обозреватель.)
Из этого следует,
что Web-сервер умеет-таки принять данные от пользователя. Да, это входит в его
основную задачу: принять данные и перенаправить их серверной программе. В свою
очередь серверная программа их обработает и вернет Web-серверу результат.
Вот тут-то
и начинается самое интересное. Дело в том, что результат, возвращаемый серверной
программой Web-серверу, - это не что иное, как обычный HTML-код! Фактически
серверная программа возвращает готовую Web-страницу, сформированную на основе
данных, введенных посетителем. Такая страница называется динамической,
в
отличие от статических
страниц, написанных Web-дизайнером и сохраненных
в файлах на дисках серверного компьютера. А уж эту динамическую страницу Web-сервер
и направляет клиенту в качестве ответа на введенные данные.
Серверные
программы делятся на следующие четыре вида.
- Исполняемые программы,
работающие через интерфейс CGI
(Common Gateway Interface - общий интерфейс
обмена), так называемые CGI-npoграммы.
Эта разновидность серверных
программ - самая старая, однако отнюдь не устаревшая.
- Расширения Web-сервера
(приложения формата ISAPI, NSAPI, модули расширения Apache и т. п.). Новый
способ, позволяющий встраивать серверные программы в сам Web-сервер, делая
их его составными частями. Впервые предложен фирмой Microsoft для их сервера
Microsoft Internet Information Server (интерфейс ISAPI) и разработчиками популярного
бесплатного Web-сервера Apache.
- Активные серверные
страницы
(ASP, JSP и др.). Фактически это обычные статические Web-страницы,
сохраненные в файлах, Которые, кроме обычного HTML-кода, включают в себя команды,
обрабатываемые либо самим Web-сервером, либо его расширением. Также новый
способ, впервые предложенный Microsoft для того же Internet Information Server.
- Серверные сценарии,
написанные на интерпретируемом языке (Perl, Python, VBScript, JavaScript
и др.). Обычные сценарии, работающие через интерфейс CGI или ISAPI на стороне
сервера.
Теперь рассмотрим
все это разнообразие подробнее.
CGI-программы
представляют собой обычные исполняемые файлы, написанные на любом языке программирования
и откомпилированные в ма
шинный
код процессора. Они не имеют интерфейса пользователя (как и все серверные программы),
а работают с Web-сервером, получают от него входные данные и ему же пересылают
результаты своей работы. Запускаются они самим Web-сервером, когда в них возникает
нужда (когда необходимо обработать полученные от пользователя данные), и работают
под управлением операционной системы серверного компьютера. При этом, если Web-серверу
поступает одновременно несколько запросов на обработку данных от пользователей,
он запускает соответствующее количество копий CGI-программы.
К достоинствам
CGI-программ можно отнести легкость создания (многие среды разработки программ
поддерживают создание таких приложений, в частности популярнейший Borland Delphi,
начиная с версии 3) и простоту отладки. Также, поскольку CGI-приложения представляют
собой независимые программы, они выполняются отдельно от Web-сервера (как говорят
программисты и системные администраторы, выполняются в другом адресном пространстве).
Это значит, что при сбое в CGI-программе завершается только она - сам Web-сервер
остается "на плаву". А недостаток у CGI-программ всего один: большой
расход системных ресурсов, поскольку для обработки каждого набора данных запускается
отдельная копия серверной программы. И если Web-серверу поступит слишком много
запросов на обработку данных, серверный компьютер может и зависнуть.
Расширения
Web-сервера - более новая разновидность серверных программ. Они представляют
собой обычные библиотеки DLL, в которых реализована вся логика серверной программы.
Такие библиотеки как бы встраиваются в программу Web-сервера и работают как
ее неотъемлемая часть. Поскольку библиотеки DLL работают только в среде Windows,
для того чтобы создавать расширения в иных операционных системах, были придуманы
и другие форматы. В частности, модули расширения сервера Apache не являются
библиотеками DLL,
Именно в виде
библиотек DLL создаются расширения Web-серверов Internet Information Server
фирмы Microsoft и Netscape Web Server фирмы Netscape. В первом случае расширения
имеют формат ISAPI
(Internet Server Application Programming Interface
- интерфейс программирования приложений интернет-сервера), а во втором - NSAPI
(Netscape Server Application Programming Interface - интерфейс программирования
приложений сервер^ Netscape). Формат модулей расширения Apache так и называется
- модули Apache.
Достоинство у расширений Web-сервера одно: бережный расход системных ресурсов. Дело в том, что для обработки всех наборов данных пользователя запускается всего один экземпляр расширения, который отнимает существенно меньше ресурсов, чем уйма запущенных CGI-программ. Однако расширения труднее создавать и отлаживать, к тому же они не так безопасны.
Как CGI-программы.
Поскольку они работают как часть Web-сервера, любая ошибка в расширении приведет
к зависанию сервера.
Оба описанных
выше вида серверных программ обладают одним огромным недостатком. Прежде чем
они смогут работать, они должны быть написаны на языке программирования и откомпилированы
в машинные коды процессора, что отнимает много времени, особенно при отладке.
Конечно, откомпилированные программы работают быстрее интерпретируемых, т. е.
тех, где каждая инструкция читается, расшифровывается и обрабатывается специальной
программой-интерпретатором. Но у интерпретируемых программ есть и свои преимущества,
главными из которых являются простота и быстрота написания. Две следующие разновидности
серверных программ, которые будут описаны, как раз будут интерпретируемыми.
Как уже говорилось,
активные серверные страницы - это обычные Web-страницы, включающие в себя особые
серверные сценарии,
выполняемые самим Web-сервером или специальной серверной
программой (CGI-приложением или расширением Web-сервера). В частности, ASP
(Active Server Pages - активные серверные страницы), поддерживаемые Microsoft
Internet Information Server, и JSP
(Java Server Pages - серверные страницы,
написанные на JavaScript), поддерживаемые рядом других Web-серверов, работают
именно таким образом. Серверные страницы ASP пишутся на языках JavaScript и
VBScript, a JSP - только на JavaScript.
Достоинства
активных серверных страниц вы уже знаете: легкость и быстрота написания и простота
отладки. Кроме того, поскольку активные серверные страницы -- это обычные Web-страницы
с "вкраплениями" программного кода, их написание легко освоят все,
кто знаком с HTML. Недостаток: относительная медлительность и повышенные требования
к системным ресурсам.
Серверные
сценарии подобны активным серверным страницам тем, что являются интерпретируемыми,
однако представляют собой "чистый" программный код, без HTML-""примесей".
Интерпретатор практически всегда представляет собой CGI-программу, однако ничто
не мешает разработать его в виде расширения Web-сервера. Сценарии обычно пишутся
на языке программирования Perl, специально предназначенном для обработки текста;
также используются языки Python, JavaScript, VBScript и даже (как говорят) язык
командных файлов MS-DOS. Фактически писать сценарии можно на любом языке программирования,
для которого есть интерпретатор.
Достоинства
и недостатки серверных сценариев те же, что у активных серверных страниц. Однако
сценарии потребляют исключительно много системных ресурсов, даже больше, чем
CGI-приложения. Ведь для обработки каждого набора данных пользователя запускается
своя копия интерпретатора, а интерпретатор, в свою очередь, расходует много
ресурсов на обработку сценария. И все же, несмотря на это, сценарии - самый
популярный способ создания серверных программ.
В табл. 15.1
приведены расширения файлов серверных программ.
Таблица
15.1.
Расширения файлов серверных программ
|
Вид серверных
программ
|
Подвид
|
Расширение
|
||
|
CGI-программы |
- |
exe |
||
|
Расширения Web-сервера |
ISAPI и NSAPI
Модули Apache |
dll Нет расширения |
||
|
Активные серверные страницы Серверные сценарии |
ASP JSP |
asp jsp |
||
|
Язык Perl JavaScript
VBScript Другие языки |
pl, cgi js, cgi
vbs, cgi cgi |
|||
Вот мы и рассмотрели,
как Web-сервер обрабатывает (точнее, не обрабатывает) данные пользователя. Теперь
переместимся в начало цепочки и рассмотрим, как Web-обозреватель отправляет
данные пользователя серверной программе.
Как
Web-обозреватель отправляет введенные данные
В начале этой
главы мы говорили о том, что для сбора данных посетителя используются элементы
управления, помещаемые на самих Web-страницах. Это обычные элементы управления,
знакомые вам по приложениям Windows: поля ввода, кнопки, списки, флажки и пр.
Посетитель сайта вводит в них данные и нажимает особую кнопку, запускающую отправку
данных Web-серверу, а значит, и серверной программе.
Элементы управления,
предназначенные для ввода данных посетителя, помещаются в форму. Форма -
это особый элемент страницы, выполняющий собственно кодирование данных и
пересылку их Web-серверу. (Можно сказать, что форма является родителем для элементов
управления.) Сами же элементы управления только принимают данные от посетителя,
но не кодируют и не передают их.
Каждый элемент
управления, находящийся в форме, должен иметь уникальное имя. Эти имена используются
Web-обозревателем для того, чтобы представить введенные в форму данные в удобочитаемом
для серверной
Например:
Здесь мы рассмотрели
идеальный случай, когда значения каждого элемента управления содержат только
допустимые с
точки зрения протокола HTTP символы: буквы латинского алфавита,
цифры, тире, подчеркивания и некоторые другие знаки. (Как вы помните, HTTP -
протокол передачи файлов, используемый Web-сервером.) Если же вы передаете данные,
содержащие недопустимые символы, скажем, пробелы или буквы русского алфавита,
каждый такой символ будет представлен в виде шестнадцатеричного кода, которому
предшествует знак процента, например, так (закодированные символы пробела выделены
полужирным шрифтом):
Благодаря
такому формату данных написание обрабатывающих их серверных программ становится
очень простым. В частности, язык Perl имеет встроенные средства расшифровки
для этого формата.
Представленные
в вышеуказанном виде данные впоследствии кодируются с использованием одного
из предопределенных методов кодирования
и отправляются по Сети серверной
программе. Всем этим фактически занимается форма (но не элементы управления).
Сам процесс
отправки данных начинается после того, как пользователь нажмет особую кнопку.
Эта кнопка носит название Отправить
(Submit -в англоязычных программах)
и обязательно должна присутствовать в форме. Также в форме может присутствовать
кнопка Сброс
(Reset), обнуляющая введенные пользователем данные. Как
правило, эти кнопки располагаются в самом низу формы.
Вы можете
считать, что форма - это некое подобие обычного диалогового окна Windows-приложения,
принимающего данные от пользователя, кодирующего их определенным образом и отсылающего
основному окну. (Диалоговые окна Windows-приложений также обязательно имеют
две кнопки: ОК
и Отмена
(Cancel).) Но если в случае обычного Windows-приложения
программист должен явно задать, как будут шифроваться и пересылаться данные,
в случае с Web-формой этого делать не нужно. Вам необходимо будет только задать
три обязательных параметра:
- интернет-адрес серверной
программы, которая будет обрабатывать данные формы;
- метод кодирования отправляемых данных;
- один из двух методов
отправки данных.
О методах
отправки данных мы поговорим чуть позже. А сейчас выясним все о двух других
обязательных параметрах формы.
Интернет-адрес
серверной программы очень похож на интернет-адрес любого другого файла, например
Web-страницы. Взгляните сами - так будет выглядеть адрес CGI-программы:
http: //www.
somesite. ru/bin/program.exe Так - адрес расширения Web-сервера: http: //www.somesite.ru/bin/extension.dll
Это - адрес активной серверной страницы:
http: //www.
somesite . ru/asps/active_page . asp
А это - адрес
программы-сценария, написанной на языке Perl:
http: //www.
somesite. ru/scripts/perl_script.pl
Как видите,
ничего сложного в этом нет. Серверная программа - обычный файл, помещенный на
жестких дисках серверного компьютера, и ссылка на него также не представляет
ничего особенного.
Для кодирования
передаваемых по Сети данных обычно используются три наиболее популярных метода:
application/x-www-form-urlencoded,
multipart/form-data
и (значительно реже) text/plain. Возможно применение и других способов кодирования,
но в абсолютном большинстве случаев используются три перечисленных. Вдобавок
эти три метода кодирования поддерживаются большинством программ Web-обозревателей.
Примечание
Если вы
еще помните, что такое тип данных MIME, то, взглянув на приведенные выше названия
методов кодирования данных, сразу увидите, что это как раз типы MIME. Именно
с их помощью задаются методы кодирования.
В подавляющем
большинстве случаев используется метод кодирования application/x-www-form-uriencoded.
Кстати, именно он применяется по умолчанию, если метод кодирования не задан.
Метод кодирования multipart/form-data используется, если вы собираетесь отправить
на Web-сервер файлы; он обеспечивает соответствующее такому случаю преобразование
двоичных данных. Последний метод - text/plain -- представляет данные в виде
обычного текста, что может быть полезно, если данные формы будут отправляться
по электронной почте (иногда применяется и такой способ передачи данных).
Итак, с кодированием
данных разобрались. Остается выяснить, как же эти данные передаются по каналам
Сети.
Как
данные передаются по Сети
Как вы уже
знаете, для пересылки данных по Интернету, да и по любой локальной или глобальной
компьютерной сети, используется особый набор.правил, называемый протоколом.
Протокол определяет, каким образом данные будут шифроваться и упаковываться
для последующей передачи по сети. Естественно, что и передающая, и принимающая
программы должны поддерживать один и тот же протокол, чтобы "понять"
друг друга. (Иначе возникнет так называемая несовместимость по протоколу передачи
данных, штука весьма неприятная.) Собственно, уже говорилось об интернет-протоколах
и повторяться сейчас нет смысла.
Также вы знаете,
что для пересылки по Сети Web-страниц и связанных с ними файлов (графических
изображений, звуков, архивов и т. п.) используется протокол HTTP. Он же применяется
и для передачи данных, причем для этого предусмотрены два метода передачи
данных. Оба способа широко используются в интернет-программировании и имеют
свои преимущества и недостатки. Давайте их рассмотрим.
Первый способ
носит название GET
по значению соответствующего параметра формы. При
его использовании данные передаются как часть интернет-адреса в HTTP-запросе.
Как вы помните,
Web-обозреватель для того, чтобы получить от Web-сервера нужный ему файл, отправляет
этому серверу так называемый HTTP-запрос, включающий в себя интернет-адрес необходимого
файла. Так вот, данные могут быть переданы как часть этого адреса.
Возьмем, например,
такой набор данных, приведенный чуть выше:
name1 = Ivan
surname = Ivanovich name2 = Ivanov age = 30
Теперь подготовим
его для пересылки по методу GET (сами данные выделены полужирным шрифтом):
http://www.somesite.ru/bin/program.exe?name1=Ivan&surname2=Ivanovich&name2=Ivanov&age=30
Как видите,
пересылаемые по методу GET данные помещаются в самый конец интернет-адреса и
отделяются от него вопросительным знаком. При этом пары "имя" = "значение"
отделяются друг от друга знаком "коммерческое и" ("&").
Все очень просто и наглядно.
Такая простота
и наглядность представления данных - основное преимущество метода GET. Как говорится,
все на виду. Также значительно упрощается отладка Web-страниц: поскольку передаваемый
Web-серверу адрес отображается в строке адреса Web-обозревателя, вы всегда сможете
увидеть, что именно было передано. (Однако, как вы понимаете, конфиденциальные
данные таким методом не передашь - их увидят все, кто стоит за вашей спиной.)
http://www.mysite.ru/bin/choose.exe?chapter=3
Как видите,
фактически это ссылки на серверную программу, содержащие один параметр chapter
и его значение. Это значит, что все остальные страницы такого сайта формируются
серверной программой динамически, на основании полученных параметров. По такому
принципу очень часто строятся сайты-справочники, сайты-каталоги программ, электронные
магазины и другие сайты, содержащие большое количество классифицированной информации.
К несчастью,
метод GET обладает огромным недостатком: с его помощью невозможно передавать
большие объемы данных. Это происходит из-за ограничения, накладываемого стандартами
на длину интернет-адреса: не более 256 символов. Вычтите отсюда длину собственно
адреса серверной программы - и вы получите максимально допустимый размер ваших
данных. Второй недостаток метода GET - обратная сторона его достоинства. Данные,
пересылаемые им, открыты для всеобщего обозрения и могут быть легко прочитаны
в строке адреса Web-обозревателя.
Метод GET
стоит использовать, если пересылаемые серверной программе данные заведомо невелики
и не являются секретными. В частности, он используется для пересылки ключевых
слов поисковым машинам, в сайтах, построенных на основе серверной программы
(см. выше)
и т. п. Если же вам нужно пересылать объемистые либо конфиденциальные
данные, используйте второй метод передачи, называемый POST.
Метод POST
передает данные серверной программе все в том же HTTP-запросе, но уже не
частью интернет-адреса, а в виде так называемых дополнительных данных. Поскольку
размер дополнительных данных не ограничен (по крайней мере, он может быть очень
велик), вы можете передавать все, что угодно, в каких угодно количествах. В
частности, именно этим способом Web-серверу могут передаваться даже файлы.
Достоинства
метода POST: отсутствие ограничения на объем передаваемых данных и "невидимость"
их. Недостатки: сложность расшифровки данных и трудность отладки. Методом POST
передаются, например, анкетные данные, адреса покупателей в электронных магазинах,
литературные произве
дения
на сайты http://www.stihi.ru и http://www.proza.ru и т. п. В общем, то, что имеет большие объемы.
Как говорят,
комитет WWWC намерен вообще со временем отказаться от метода GET и все данные
передавать с помощью метода POST. Пока что метод GET просто объявлен не рекомендованным
для использования во вновь создаваемых сайтах, реально же он еще поддерживается
Web-обозревателями.
Вот мы и выяснили
все о серверных программах. Ну, может, не все, но пока нам этого достаточно.
Теперь поговорим о том, насколько полно все это поддерживается Dreamweaver MX.
Серверное
программирование - подход Dreamweaver
Трудно ли
писать серверные программы? Да, трудно. Вероятно, даже труднее, чем Web-страницы.
Однако вспомните,
часто ли нам приходилось писать HTML-код вручную? Совсем редко, не правда ли?
А все потому, что Dreamweaver заботливо оберегал нас от этого, предоставляя
удобный интерфейс для визуального создания страниц. Мы просто писали текст,
форматировали его, помещали на страницу изображения, таблицы, применяли к элементам
страницы поведения и т. п. Одним словом, чувствовали себя комфортно.
И неужели
нам теперь придется писать серверные программы вручную?! Нет, совсем не обязательно.
Уже упоминалось,
что Dreamweaver предоставляет неопытным пользователям и вообще тем, кто не хочет
иметь дела с JavaScript-кодом, так называемые поведения. Поведение
-
это уже готовый сценарий, написанный профессиональными программистами и помещаемый
в код Web-страницы самим Dreamweaver после того, как пользователь выберет это
поведение в меню поведений панели Behaviors.
Пользователю не надо заботиться
о том, что в определенное место кода страницы необходимо поместить сценарий,
выполняющий то или иное действие, ему не нужно будет проверять этот сценарий
на наличие ошибок и согласовывать его с другими сценариями. Все это за него
делает Dreamweaver.
В самом деле,
набор операций, применяемых в серверном программировании, очень невелик. Открыть
базу данных, получить из нее какие-то данные, вывести их на странице, записать
новые данные - что еще нужно!
Конечно, если
вы хотите реализовать какие-то хитроумные действия, вам придется писать серверные
страницы "врукопашную". Но, согласитесь, такое бывает нечасто.
Итак, мы выяснили
две вещи. Во-первых, Dreamweaver MX поддерживает создание серверных Web-страниц.
Во-вторых, для помещения в них сценариев используются хорошо знакомые вам поведения.
Dreamweaver предлагает большой набор поведений для серверных сценариев, которых
вам хватит на первых порах.
Осталось выяснить,
какие именно серверные страницы позволяет создавать Dreamweaver. Точнее, какие
технологии создания серверных страниц он позволяет использовать. Таких технологий
четыре, и сейчас они будут перечислены.
- ASP. Эта технология
вам уже знакома.
- ASP.NET. Дальнейшее
развитие ASP.
- PHP. Бесплатная технология,
распространяемая с открытыми исходными текстами. Довольно популярна и часто
используется с бесплатными же Web-серверами, например Apache.
- Macromedia ColdFusion.
Собственная разработка фирмы Macromedia.
Какую же из
них выбрать? Ведь нам надо будет создавать примеры Web-страниц.
Давайте выберем
ASP. И вот почему.
Для того чтобы
работать с серверными страницами, нам понадобится Web-сервер. Без него серверные
страницы просто не будут работать. А, возможно, вы знаете, что со всеми более-менее
новыми версиями Windows поставляется небольшой Web-сервер. В системах Windows
95/98/ME это Personal Web Server, а в Windows NT/2000/XP - Internet Information
Server. Его возможностей нам вполне хватит для экспериментов с серверным программированием.
Так вот, этот
Web-сервер полноценно поддерживает технологию ASP. Вы можете писать активные
серверные страницы и выполнять их под ним. И вам не придется загружать никаких
дополнительных компонентов - все, что вам нужно, уже включено в состав дистрибутивного
комплекта Windows. Вот поэтому и был выбран ASP.
Технологию
ASP.NET пока что не поддерживает практически ни один Web-сервер; фирма Microsoft
пока что не выпустила ни один продукт с поддержкой этой технологии. Для работы
с PHP-страницами вам придется искать и загружать по Сети довольно большой дистрибутивный
комплект, содержащий обработчик РНР, а потом долго его настраивать. Что касается
технологии ColdFusion, то вряд ли вы в состоянии выложить за нее несколько тысяч
долларов. Так что вариантов у нас практически нет.
Введение
в базы данных
Последнее,
что мы рассмотрим в данной главе, - это базы данных и работу с ними. Поскольку
львиная доля серверных программ работает именно с базами данных, нам эти знания
очень пригодятся. Конечно, мы не будем рассматривать все технологии баз данных
во всех подробностях, а, как и раньше, ограничимся кратким ликбезом. Вы сами
можете поискать нужные книги и тексты в Сети, если заинтересуетесь этим.
Что такое
база данных?
Ничего особенного, обычный файл или группа файлов, содержащих
данные, организованные особым образом. Если база данных состоит из множества
файлов, она все равно остается единым целым. Данные, содержащиеся в базе, обрабатываются
при помощи особой программы, называемой процессором баз данных.
Процессор
баз данных может быть как совершенно отдельной программой, работающей на том
же компьютере, что и использующая данные программа, так и входить в ее состав.
Базы данных
могут быть организованы по-разному. Но подавляющее большинство баз данных, эксплуатируемых
в настоящее время, являются реляционными.
Данные в таких базах организуются
в виде таблиц. Каждая такая база данных может включать в себя одну или большее
количество таблиц; сложные базы данных, как правило, имеют много таблиц, связанных
между собой.
Каждая таблица
в свою очередь состоит из набора строк, разделенных на ячейки, причем в каждой
ячейке содержатся данные определенного типа: текст, числа, логические величины,
даты и т. д. Строки таблиц баз данных называются записями,
а ячейки,
на которые делится каждая запись, - полями.
Как уже говорилось, каждое
поле имеет определенный тип и обязательно снабжено именем,
по которому
программа, работающая с данными, и осуществляет доступ к этому полю.
На рис. 15.1
приведен пример такой таблицы. Как видите, эта таблица имеет три поля:
- NAME - название технологии создания серверных страниц, текстовое;
- PRICE - цена программы-обработчика,
числовое;
- USING - поддерживается
ли эта технология в настоящее время, логическое ("да-нет").
Кроме того,
эта таблица имеет четыре записи, соответствующие технологиям, поддерживаемым
Dreamweaver MX: ASP, ASP.NET, PHP и ColdFusion.
Очень часто
одно из полей таблицы делается ключевым.
Значение ключевого поля используется
для однозначной идентификации какой-либо записи. Разумеется, ключевые поля всех
записей таблицы должны в этом случае содержать уникальные значения. Иногда ключевое
поле называется полем счетчика.
| Пример таблицы, входящей в базу данных |
Сначала были Файл-сервер и Принт-сервер, довольно быстро к ним добавился Почтовый сервер. Не успели мы как следует привыкнуть к Web-серверам, как судьба подкидывает нам новые испытания - изволь осваивать Сервер Приложений. Особая проблема возникает при переложении понятия на русский язык. Тут уже путаница становится просто невообразимой. Искушенный читатель может с досадой воскликнуть - «Э! Да что же тут нового? Это же обычная многозвенка: сервер приложений, сервер базы данных и клиент!» - и прекратить чтение. Однако, Сервер Приложений - это Федот, да не совсем тот.
Итак, начнем по порядку, чтобы и не столь искушенный читатель понял, что имеется в виду. Предмет наших размышлений - это Application Server или Сервер Приложений. Ныне модно в качестве предисловия давать рекламу наоборот - перечислять то, чего в написанном нет; то ли из ложной скромности, то ли следуя завету Микеланджело: убирать все лишнее. Поэтому вы не найдете в этой статье серьезного доказательного сравнения технических реализаций Серверов Приложений, описания методов и приемов работы с этими реализациями, примеров файлов, листингов и кусков кода - приведен лишь список источников, в которых можно все это отыскать. Здесь же займемся более общими, но не менее увлекательными вопросами - что такое Сервер Приложений, зачем это нужно, как это покупать и выбирать и как с этим работать. Предвижу недовольство читателей, которые убеждены в том, что их не пускают на «кухню» и, следовательно, в приготовленном кушанье будет намешано неизвестно что. Приведу краткие соображения, почему следует читать и писать не только сугубо технические статьи. Прежде чем готовить еду, надо определить что - суп или гарнир, легкий ужин или обед для званых гостей, надо составить меню, заготовить продукты, выработать план изготовления, а уже потом приступать к поварскому ритуалу. Какой этап важнее - на этот предмет существует известная сказка, в которой плотник, портной и кукольник спорят, кому должна принадлежать сделанная ими кукла. Насколько я помню, в сказке побеждал кукольник, поскольку именно он вдохнул в куклу жизнь. В этом смысле таким волшебником несомненно является программист-разработчик. Нимало не преуменьшая его роль, я все-таки замечу, что современные программные приложения всегда плод коллективной работы. Поэтому провал или даже неудовлетворительное выполнение любого промежуточного этапа могут безнадежно загубить все дело.
Но, довольно реверансов. Нас ждет Сервер Приложений, которому просто не терпится убедить вас в том, что без него не обойтись.
Как ни грустно опять обращаться к знакомой всем заинтересованным лицам истории компьютерных технологий, без этого Сервер Приложений предстанет перед нами бродягой без роду и племени. Но я постараюсь быть краткой, тем более что истории то всего лет 50, правда, очень стремительных. Основные этапы этой истории приведены на рис. 1.
Первая эра - эра эксклюзивного «монолита», когда компьютерные программы, или потом, пакеты программ, выполнялись на одном компьютере. Особого выбора у потенциальных потребителей программных продуктов тогда не было - или сам разрабатывай, или заказывай у опытных людей. Тогдашние операционные системы не баловали богатством возможностей - работает приложение на компьютере - и хорошо. Оно могло работать годами, выполняя раз навсегда закрепленные функции, и все были довольны. Это время часто называют и «эрой мэйнфреймов», хотя именно мэйнфреймы подошли вплотную к «тихой революции». От них появилась возможность приставить к одному серверу несколько «глаз» - терминалов, которые позволили плавно перейти в «клиент-серверную эру». Вот тут то и появляется служака «сервер». Сервер работает, служит, выполняя задания его величества клиента. Клиент от простенького «застенчивого» терминала вырастает до важного и значительного повелителя. Нынешний революционный момент характеризуется тем, что серверы не могут, а клиенты не хотят существовать по-старому. Первые не могут справиться с обилием поставленных перед ними требований, а вторые недовольны качеством обслуживания их запросов. Выход - в дальнейшей специализации. То, что пыхтя и отдуваясь выполняет несчастный сервер, теперь будет распределено на множество серверков - компонентов, каждый из которых успешно выполняет свою функцию. В такой компании клиенты превращаются в равноправные компоненты, чья задача - представительство функциональных сотоварищей (других компонентов) для пользователя, сидящего перед дисплеем.
Раз уж мы ввели строительный термин - монолит, то приведем строительно-архитектурную параллель. Первая - монолитная эра, эра дольменов и кромлехов, отдельных решений, автоматизирующих конкретные производственные задачи заказчика. Опыта еще мало - каждое сооружение в некотором смысле произведение искусства. Вторая эра - однотипные поселения, каждое их которых характеризуется зaмком (сервером) и постройками попроще вокруг (клиентами). И если простые постройки не представляют большой архитектурной ценности, то замки - решения штучные и дорогостоящие. А переходим мы в эру массовой застройки, когда «строительство» программных приложений поставлено на поток. И сколько бы мы ни ругали такую застройку, именно этот способ позволяет обеспечить жильем - программными приложениями, всех желающих за разумную цену и в реальные сроки.
Типовые современные дома обычно строятся из блоков или панелей. Так и современные программные приложения строятся или, скорее, будут строиться из компонентов. (Компонент - самостоятельный программный продукт, поддерживающий объектную парадигму, реализующий отдельную область бизнес-логики и умеющий взаимодействовать с другими компонентами с помощью открытых интерфейсов.) Такая технология позволит ответить на самые острые проблемы компьютерного мира - сокращение времени разработки программного приложения, облегчение процесса внедрения и поддержка гибкости внедренного решения. На рис. 2 изображены этапы жизненного цикла программного приложения.
Нынешняя практика, когда серьезное приложение разрабатывается минимум за два года, невыгодна ни разработчикам, ни потребителям. Первые производят устаревшие до реализации, невостребованные программные продукты, а вторые не успевают насладиться плодами автоматизации, получить отдачу от вложений и затрат. Не успели дом поставить - как выясняется, что он не отвечает современным нормам, жильцы в нем жить не хотят, и он только занимает место, которое можно употребить на постройку нового современного дома.
Под лозунгом «Быстрее, легче и гибче» и создаются современные бизнес-компоненты. Преимущества подобного подхода можно выразить в длинном списке: масштабируемость, стабильность, управляемость, настраиваемость, гибкость, переносимость, возможность многократного использования. Но, к сожалению, чудес в жизни не бывает и, если сложностей и неурядиц убыло в одном месте, то в другом они как раз прибавились. Для того чтобы компоненты умели взаимодействовать, необходимо развитие «клея» - промежуточного программного слоя.
Итак, если со стороны бизнеса все красиво, как на затейливом персидском ковре, то зато на изнанке - уйма всяких узелков и зацепок. Последние годы мировое программное сообщество усиленно пытается внести порядок в эту изнанку, в чем, надо сказать весьма преуспело. Основная возможность здесь - стандартизация компонентов, приведение их к единой природе. Блоки здания должны быть сопрягаемы. Нити ковра должны быть из близких материалов. Идея здесь достаточно проста - внешние интерфейсы компонентов должны быть описаны в едином стиле - на одном и том же языке. Поэтому два известных на сегодняшний день стандарта, CORBA и COM+ создали свои варианты IDL - Языка Описания Интерфейсов. CORBA, COM+ и технология Java, которая, естественно, использует для описания интерфейсов язык Java, предлагают близкие подходы к методу взаимодействия компонентов. На основе описания внешних интерфейсов создаются прокси (заместители) для клиента и сервера, которые позволяют им связываться друг с другом в реальном времени. Прокси для клиента принято называть стабом, а прокси для сервера - скелетоном. (Мы договорились - я не претендую на изложение технологий, а только даю краткий взгляд на них. Поэтому, в частности, не касаюсь возможностей динамического взаимодействия компонентов в технологии CORBA, когда внешние интерфейсы не определены на момент компиляции системы и появляются дополнительные динамические элементы.)
После стандартизации интерфейсов, мировое компьютерное сообщество перешло на следующий уровень стандартизации - самих компонентов. Из рис. 3 понятно, что я имею в виду под следующим уровнем стандартизации - все дальше от «железа», все ближе - к пользователю. В технологии CORBA это:
- ССМ (CORBA Component Model)- компонентная объектная модель, компонентное развитие модели бизнеса ВОМ - Business Object Model;
- BOCA (Business Object Component Architecture) - принципы архитектуры компонентных систем, развитие OMA (Object Management Architecture) на вышележащий уровень стандартизации;
- CDL (Component Definition Language)- язык определения компонентов, развитие IDL.
Разработка этих стандартов продвигается, правда, не так быстро, как хотелось бы всем заинтересованным сторонам. Но признанным героем на поле стандартизации компонентов стала технология компании Sun - Enterprise Java Beans (EJB). Возможно причина ее успеха в том, что в «семейном кругу» одного языка программирования намного проще решить вопросы взаимодействия. Тем более языка молодого и резвого, который многие проблемы, такие как вызов удаленных методов (RMI - Remote Method Invocation), умеет решать сам. Не иcключено, что универсальные цели консорциума OMG, развивающего технологию CORBA, - объединить компоненты, написанные на разных языках программирования, функционирующие на разных системах и разных компьютерах в разных точках земного шара, являются в данном случае некоторым тормозом. В дальнейшем мы увидим как две технологии, сомкнувшись, отбросив амбиции, дают замечательный результат на радость всем заинтересованным сторонам.
Что же такое этот «бин» (beаn - боб) и почему, стремительно выскочив как джин из бутылки в компьютерный мир, он уже завоевал такую популярность? Если перевести определение Sun как можно ближе к оригиналу - то «это модель для создания и развертывания серверных компонентов многократного использования, написанных на языке Java.» Продолжим вместе с Sun расплетать косу этого определения, - «компоненты - это заранее разработанные куски программного кода, которые могут быть установлены в работающие прикладные системы». Если классы Java образуют компонентную модель для проектирования приложений в технологии Java, то Java Beans логически развивает эту модель на следующем уровне интеграции создания автоматизированных систем и абстрагирования от процесса программирования - стадии внедрения. По сути, это переход от разработки приложения под заказ из готовых программных компонентов к сборке из готовых ЕJB действующих компонентов. Если раньше дома складывали из кирпичей, то теперь - из комнат-секций. Cлово Enterprise в названии Enterprise Java Beans означает новую ступень технических задач, стоящих перед программными приложениями. Такие задачи привычны для приложений уровня Предприятия: поддержка распределенности, службы именования, транзакций, безопасности, уведомлений-сообщений, долговременного хранения, и т.д. Неудивительно, что этот список напоминает список Служб технологии CORBA.
С точки зрения разработки, EJB представляют собой Java-классы специального типа вместе с описателем-паспортом бина и параметрами среды функционирования, которые бин умеет обрабатывать. Описатель бина (Deployment Descriptor) в свою очередь представляет собой XML-файл, в котором содержатся правила, связанные с управлением бином, например, права доступа пользователей к бину. Несколько бинов могут объединяться, образуя приложения, Java-апплеты и новые бины.
 |
| Рис. 4. Контейнер Enterprise Java Beans |
По технологии EJB бобы-бины размещаются в стручке - контейнере (рис. 4) На контейнер возложены обязанности по защите бинов и поддержке их взаимоотношений с внешним миром: регистрация-прописка объектов, обеспечение для них внешних интерфейсов, создание и разрушение реализаций этих объектов, охрана безопасности, управление их состояниями и координация транзакций. В технологии не определено, как конкретно должен быть реализован контейнер. Это могут быть как многопоточные процессы на отдельном сервере, в которых выполняются бины, так и законченные программные приложения, которые можно переносить или распределять между серверами и/или процессами. Клиентские бины обрабатываются внутри виртуальных контейнеров, таких как Web-страницы, формы, составные документы, и т.д.
В технологии определены два основных типа бинов. Session Beans - сеансы клиент-серверного взаимодействия отрабатывают действия клиента, например, запись в базу данных, выполнение вычислений, и т.д. Это окна клиента в мир программных приложений. Они, в свою очередь, также бывают двух типов:
- Stateless session - не умеют сохранять свое состояние и существуют только на протяжении текущего сеанса. В случае сбоя сеанс не может быть восстановлен;
- Stateful session - сохраняют свое состояние; сеанс может быть восстановлен.
Entity Bean - компоненты объектного представления данных, размещаемых в хранилище. Entity Bean транзакционны и восстанавливаемы. Каждая их реализация имеет уникальную метку, называемую «первичным ключом» (Primary Key) по аналогии с таблицами баз данных. В свою очередь эти бины делятся на две группы по способу определения где, в каком хранилище и как хранятся данные:
- Bean-Managed Persistence - самостоятельные бины, управление хранением осуществляется на уровне бинов;
- Container-Managed Persistence - «опекаемые» бины, чьим хранением заправляет контейнер.
Кроме класса, реализующего функциональность бина, в него входят два обязательных класса, реализующие два типа интерфейсов:
- Home Interface - доступ к «домашним» службам бина, таким как начало или отбой для Session Bean или поиск Entity Bean. Этот интерфейс реализует все службы жизненного цикла компонента и позволяет контейнеру управлять и руководить его поведением;
- Remote Interface - доступ к бизнес-службам бина.
Клиентские приложения общаются с бинами через контейнер, который открывает наружу оба интерфейса бина: Home и Remote. С помощью первого открывается сеанс или находится нужный бин, а с помощью второго - осуществляется отработка действий клиента в Session или транзакционная механика обработки Entity.
Итак, повторим идею технологии с прикладной точки зрения. Прикладная бизнес-логика приложения делится на изолированные бизнес-объекты, каждый из которых реализуется в виде EJB. Они устанавливаются на Сервере Приложений или EJB Сервере и реализуют запрашиваемую логику для клиента (локального или удаленного). Давайте прямо сейчас, при первом появлении понятия Сервер Приложений в технологии Java, развеем непонимание, о котором уже говорилось в начале статьи. Написав оба слова, составляющие понятие, с заглавных букв, мы магическим образом преобразовали сервер приложений, реальную машину из корпуса, начинки и кабелей, в программное приложение.
Обратимся вновь к интерпретации Sun. Под Сервером Приложений в технологии Java понимается программное приложение, обеспечивающее оптимальную среду для выполнения EJB. Сервер Приложений занимается «коммунальным хозяйством» дома - программной системы. На его руках надзор за системными ресурсами, такими как процессы, потоки, память, связь с базами данных, сетевые отношения, выравнивание загрузки распределенных узлов. Кроме этого важнейшая обязанность Сервера Приложений заключается в предоставлении cle;, компонентам.
Еще раз хочу подчеркнуть, что технология EJB, впрочем, как и технология CORBA не предоставляет готовые программные решения - контейнеры, Сервера Приложений, а только стандарты на такой тип программного обеспечения.
Стандарты - единственная возможность обеспечить некоторый порядок в бурно развивающемся компьютерном мире. Стандарты необходимы всем трем заинтересованным сторонам в области информационных технологий: разработчикам, потребителям-заказчикам и промежуточному звену - консультантам, интеграторам, продавцам. Первым - для поcтавки на рынок конкурентоспособных, жизнестойких решений, вторым - как средство борьбы с «зоопарком» программных систем, третьим - как возможность строить гибкие, интегрированные программные среды для своих заказчиков.
Стандарты продолжают захватывать все новые области информационных технологий. Но, если в сетевых технологиях стандарты полностью прижились, то в области программных приложений они еще только набирают силу. Понятны опасения специалистов использовать в собственных решениях «неправильный» стандарт, который зачастую, невзирая на грамотные технические решения, заложенные в его основу, не идет дальше прекрасных инициатив и не получает развития. Выбирая дорогу, всегда есть опасность оказаться в тупике. Именно поэтому стоит внимательно читать указатели (в смысле дорожные знаки) и прислушиваться к мнению мирового сообщества. Серверы Приложений уже сейчас имеют реализации от большинства крупных производителей программных систем (компании Inprise, Oracle, Sybase, Sun, BEA, Iona, IBM). Кроме того, в данной области архитектуры программных приложений пока не появилось ни одного достойного конкурента. Так что стиль пока единственный - Сервер Приложений.
Если посмотреть на Серверы Приложений глазами конечного пользователя, то они представляют собой основные несущие конструкции сооружения под названием многозвенная распределенная компонентная программная система. Именно Серверы Приложений поставляют бизнес-компоненты и обеспечивают необходимый уровень системных служб для этих компонентов, т.е. всю коммунальную систему жизнеобеспечения. Приложения, которые наш Сервер предоставляет клиентам, могут располагаться где угодно, причем эти приложения могут даже не знать, где хранятся данные, с которыми они работают - на каком сервере и в какой базе данных. Для клиентов Сервер Приложений открывает и закрывает сеансы. Для приложений - позволяет настраивать системные службы, из которых важнейшими являются служба долговременного хранения, политика хранения компонентоа Entity Beans, служба транзакций и служба безопасности.
«А надо ли городить огород?, - спросит недоверчивый читатель. - Зачем мне такое дополнительное ПО для моего сугубо конкретного программного приложения?»
Огород, может быть, городить и не надо, а обеспечить газом, электричеством и горячей водой наш блочный дом, программное приложение - необходимо. Да и надежный кодовый замок на входной двери не помешает. Конечно, можно предоставить решать эти проблемы самим жильцам. Пусть каждый в одиночку кипятит воду и укрепляет входную дверь. Тогда уж лучше просто влезть на дерево (я никоим образом не имею в виду службу каталогов NDS) и кушать бананы (не путайте с Baan).
Чтобы постройка программного приложения не напоминала возведение Вавилонской башни, в технологии EJB расписано, кто именно должен принимать участие в проекте. Комплексная бригада строителей здания состоит, по представлению компании Sun, из следующих профессионалов.
Архитектор
Поставщик серверной платформы (EJB Server Provider) - специалист в области распределенной платформы и служб. Он предоставляет инфраструктуру разработки и среду выполнения для программных приложений.
Конструктор
Поставщик контейнеров (EJB Container Provider) - эксперт в области распределенных систем, системной безопасности и поддержки транзакций. Он обеспечивает системный уровень контейнеров, то есть системную оболочку для одного или более компонентов - Enterprise Bean.
Снабженец
Поставщик бизнес-компонентов (Enterprise Bean Provider) - аналитик в функциональной области, который реализует бизнес-компоненты как разработчик или подбирает готовые.
Монтажник
Компоновщик Приложений (Application Assembler) - также эксперт-функционал, собирающий программное приложение из строительных блоков - бизнес-компонентов. Его взгляд на соответствующий бизнес должен быть более общим и универсальным, чем у Снабженца - Поставщика бизнес-компонентов.
Прораб
Внедренец (Deployer) - специализируется в установке приложений. Он настраивает приложение на реальную среду.
Управдом
Администратор системы (System Administrator) - обеспечивает работоспособность системы на этапе эксплуатации.
Конечно, то, что компания Sun описала именно такие роли, не означает, что любой проект, связанный с Enterprise Java Beans обязательно требует одного и только одного указанного специалиста и именно такой состав комплексной бригады. Да и найти, скажем, готового поставщика контейнеров не так-то просто. Что совершенно необходимо - так это не упустить специфические для компонентного проекта моменты: выбор архитектуры и способы реализации системных служб, определение структуры и поведения контейнеров и проработка вопросов внедрения (развертывания).
Завершив экскурс в EJB, можно привести определение Сервера Приложений «с большой буквы». Сервером Приложений называется программный продукт, поставляющий среду выполнения для прикладных компонентов, расположенный между клиентом - с одной стороны и данными и прикладными программами - с другой, который может обеспечить интеграцию различных источников данных и прикладных ресурсов и предоставить компонентам необходимые для них сервисы.
Разочарованный читатель возмутится: «Зачем же нам объясняли про EJB, если в определении про них нет ни слова!» Попробую пояснить. Я намеренно привела универсальное определение Сервера Приложений, которое относится ко всем типам компонентов (CORBA, EJB, COM+). Серверы Приложений, зародившись внутри технологии EJB, оказались столь удобны, что достаточно уверенно продвигаются как единое решение для всех компонентных технологий. Реализации Серверов Приложений уже умеют работать с разными компонентами. В качестве примера приведу Application Server компании Inprise, который можно успешно использовать в среде компонентов EJB и CORBA. Другой наблюдаемый процесс - смыкание технологий Java и CORBA. С небольшой долей натяжки можно считать, что EJB могут иметь двойное гражданство, а именно представлять собой еще и CORBA-объекты. С моей точки зрения, поддержка CORBA является необходимым условием для конкурентности реализации Сервера Приложений. Ведь из всех перечисленных технологий только эта поддерживает Унаследованные Системы - функционально пригодные, но технически устаревшие. Если считать парк автоматизации современного предприятия или компании некоторым поселением - деревушкой или городком, создаваемая интеллектуальная компьютерная среда должна включать уже существующие постройки. Одинаково неправильно требовать сноса существующих зданий или не обращать на них внимания.
Другой аспект выбора реализации Серверов Приложений заключается в функциональности, которая наиболее приоритетна. Попробуем разделить Серверы приложений на группы.
1. Интеграционный Сервер Приложений. (Application -integration-centric application server)
Основная задача такого Сервера - интеграция Бизнес-приложений в единую интеллектуальную среду. Такие Серверы особенно актуальны для организации приложений, связанных с задачами типа Supply Chain (Цепочки Поставщиков) и электронной коммерции. К таким серверам относятся реализации крупнейших поставщиков брокеров объектных запросов - компаний Inprise и Iona.
2. Информационный Сервер Приложений (Data-centric application server)
Деятельность такого сервера сконцентрирована на манипулировании данными. В качестве хранилищ могут выступать произвольные приложения, которые, в частности, не обязательно представляют собой реляционные базы данных и, уж тем, более объектные. Такие серверы берут на себя организацию представления распределенных данных, хранящихся в различных источниках, в объектной парадигме. Естественно, Oracle поставляет серверы именно такого типа.
3. Обрабатывающий Сервер Приложений (Processing-centric application server)
Центральной заботой таких серверов является обеспечение специфической бизнес-логики. Например, сервер, реализующий распределенные вычисления, или сервер ERP-системы. К таким реализациям относится IBM Websphere.
4. Управляющий Сервер Приложений (Rules-based application server)
Такие серверы являются подмножеством Обрабатывающих Серверов Приложений, но в отличие от них сконцентрированы на выполнении определенных бизнес-правил. Они ориентированы прежде всего на область электронной коммерции. Примером таких серверов является реализация от компании Vision Software.
5. Сервер XML (XML Server)
Этот сервер представляет собой подмножество Информационного сервера, с той лишь разницей, что в качестве хранилищ данных выступают XML - документы. С другой стороны, такой сервер может представлять собой подмножество Интеграционного сервера, в котором в качестве механизма интеграции выбран XML. Известна реализация такого сервера от компании Bluestone Software.
Не следует думать, что разделение Серверов Приложений по группам такое четкое. Наиболее интересные экземпляры Серверов Приложений гармонично сочетают в себе достоинства различных групп. Кроме того компании-разработчики активно развивают свои продукты. А каждая новая версия, естественно, богаче предыдущей.
Предвижу следующий вопрос читателей: - « А это уже где-нибудь работает?» Ответ - «Да!». Особенно востребованы Сервера Приложений во всем, что касается использования Internet. И за счет поддержки распределенности, возможностей выравнивания загрузки, отслеживания распределенных неоднородных транзакций, управления безопасностью и многих других своих возможностей. Именно эти интеллектуальные приложения находят в Серверах Приложений могучую опору.
 |
| Рис. 5. Java 2 Enterprise Edition |
Вскользь упомяну о следующих усилиях по созданию технологии компонентного программного обеспечения, снова связанных с Java. Это J2EE (Java 2 Enterprise Edition) - стандарт для многозвенных систем уровня предприятия, прикладная платформа, обеспечивающая взаимодействие Enterprise Java Beans, Java Server Pages, апплетов и сервлетов. рис. 5 в точности иллюстрирует то, как это выглядит у компании Sun.
Средства взаимодействия компонентов располагаются в нижней части рисунка. J2EE впервые стандартизовала выполнение родного для Java протокола удаленных вызовов методов через Internet - IIOP (Internet InterOrb Protocol). Таким образом, к сотрудничеству между CORBA и Java добавился еще один пункт. Серверные компоненты заключены в контейнеры, взаимодействующие с помощью специальных коннекторов. На уровне контейнеров задаются системные сервисы: Транзакций, Сообщений и Почты. На верхнем уровне находится API-интерфейс и Средства управления. Сказать об этой технологии в контексте Серверов Приложений меня вынудило не только то, что этот стандарт является логическим развитием технологии EJB, в которой впервые определился наш герой, но и то, что уже появляются Серверы Приложений, удовлетворяющие новому стандарту. Я имею в виду уже упоминавшийся Application Server (Inprise).
Но, стоп, боюсь, что Вы уже устали от обилия технологий и нагромождения стандартов? Если да - то тогда обратитесь к рис. 6, где я попыталась свести все воедино.
В защиту всего этого хозяйства хочу отметить, что, говорят, наши предки -обезьяны прекрасно жили на деревьях и, если и сплетали себе нечто вроде гнезд, но ни один из нас не согласился бы там жить постоянно, разве что для того, чтобы испытать захватывающее приключение. Так и программные приложения постепенно слезли с деревьев и начали строить себе дома. А если говорить о стандартах в строительстве, то их все равно намного больше, чем на сегодняшний день существует в информационных технологиях. В утешение хочу добавить, что наши стандарты неплохо уживаются друг с другом. По крайней мере, учатся это делать. Как пример, хочу обратить ваше внимание на неоднократное упоминание лакомого современного стандарта XML в этой статье, которая вроде бы написана совсем о других стандартах.
Легче ли создавать программные системы с помощью Сервера Приложений? Я бы покривила душой, если бы однозначно ответила - «да», хотя мне и очень хочется это сделать. Как всяким инструментом, к тому же непростым, им надо научиться пользоваться. Его нужно применять только в определенных условиях, как по инфраструктуре, так и по программному обеспечению. Отдельный вопрос - какую именно реализацию Сервера Приложений следует использовать. Сервер Приложений - верный друг, но только для заботливого и грамотного хозяина.
Об авторе
Марина Аншина - сотрудник отдела системной интеграции компании «ТопС, Системный Интегратор». С ней можно связаться по электронной почте по адресу: [email protected]
Моральный кодекс молодого строителя программного обеспечения - Сервера Приложений
Сервер Приложений обязан
- Создавать сеансы взаимодействия клиента и сервера и управлять ими.
- Защищать корпоративные данные от несанкционированного доступа.
- Обеспечивать транзакционную целостность информации.
- Распределять нагрузку между серверными приложениями.
- Поддерживать требуемый уровень качества предоставляемых клиенту сервисов.
- Отыскивать для клиента сервер требуемой функциональности.End Sub
Источники
http://www.inprise.ru - документация на русском языке по Inprise Application Server и возможность загрузки пробной версии
Http://www.infoworld.com/sponsor/supplements/appdev3/appdev3.html
Http://www.borland.com/appserver/
Http://www.geocities.com/SiliconValley/Way/ 9006/mw.html
Http://www.appserver-zone.com/
Http://www.app-serv.com/
Http://javaboutique.internet.com/articles/AppServers/
Http://www.flashline.com/components/appservermatrix.jsp
Http://www.iona.com/products/iPortal/appserver.htm
Http://webreview.com/wr/pub/1999/02/26/appservers/index.html
Http://www.beasys.com/products/weblogic/server/papers.html
Серверы приложений
1. Серверы приложений: типы, назначение, функции.
Cерверы приложений - это программное обеспечение, предназначенное для создания систем с выделенными сервисами бизнес-логики. Чаще всего серверы приложений выполняются под управлением серверных операционных систем (различных версий UNIX, Windows NT Server, Windows 2000 Server). Компоненты, реализующие бизнес-логику распределенного приложения и выполняющиеся под управлением сервера приложений, могут представлять собой COM- или CORBA-объекты, Java-серверы либо Enterprise Java Beans (EJB) - Java-компоненты. Многие серверы приложений позволяют реализовать приложения, устойчивые к сбоям. В настоящее время серверы приложений являются основой многих корпоративных решений, например распределенных приложений, реализующих следующие схемы:
- «предприятие - потребитель» (B2C, business-to-consumer), такие как онлайновая продажа товаров, бронирование билетов и мест в гостиницах, услуги страхования;
- «предприятие - предприятие» (B2B, business-to-business), такие как виртуальные торговые площадки, позволяющие заключать торговые сделки между предприятиями;
- «предприятие - сотрудник» (B2E, business-to-employer), такие как корпоративные порталы.
Нередко в корпоративных решениях применяются конфигурации, содержащие несколько серверов приложений. Как правило, подобные решения обладают многозвенной архитектурой, при этом серверы приложений обычно располагаются между сервером баз данных и Web-сервером либо между сервером баз данных и клиентскими приложениями. Нередко функциональность Web-сервера реализуется и в самом сервере приложений.
Современные серверы приложений в большинстве случаев характеризуются возможностью построения кластеров и распределения нагрузки, а также средствами восстановления после сбоев, поскольку требования к надежности и производительности приложений, использующих продукты подобного класса, обычно весьма высоки.
Из технологий, поддерживаемых современными серверами приложений, следует в первую очередь отметить средства интеграции приложений, созданных на различных платформах, в том числе поддержку Web-сервисов, средства разработки приложений, наличие продуктов специализированного назначения, основанных на данном сервере приложений (например, средств управления информационным наполнением), поддержку беспроводных Лидерами рынка серверов приложений на данный момент является компания IBM. Из других наиболее известных продуктов, относящихся к категории серверов приложений, следует отметить серверы компаний Oracle, Sun Microsystems, Borland, Sybase,.
Borland Enterprise Server 5.0 (Borland Software Corporation)
Borland Enterprise Server довольно широко применяется в телекоммуникационном и банковском секторах. Этот продукт обладает некоторыми уникальными технологическими особенностями, такими как Borland Application Partitioning. Данная технология позволяет определить детальные характеристики сервисов и Web-серверных приложений, описать собственный набор сервисов для каждой конфигурации (partition), выделить для каждой конфигурации самостоятельный системный процесс. Все это упрощает конфигурирование распределенных систем и управление ими и в целом повышает надежность и доступность приложений, созданных на основе этого сервера.
Семейство серверов Microsoft .NET (Microsoft Corporation)
Наиболее часто применяемыми серверами приложений являются продукты семейства корпоративных серверов Microsoft .NET, предназначенные, как и другие серверы приложений, для создания и развертывания интегрированных корпоративных приложений. Все эти серверы характеризуются поддержкой стандартов Интернета, поддержкой кластерной архитектуры, высокой степенью взаимной интеграции, а также интеграции с операционной системой Windows и средствами разработки Microsoft.
К семейству корпоративных серверов Microsoft .NET сама компания Microsoft относит:
- Microsoft SQL Server - сервер баз данных, являющийся одним из лидирующих продуктов данного класса для платформы Windows и обычно применяющийся совместно со многими другими серверами Microsoft .NET;
- Microsoft Application Center - средство управления кластерами серверов для осуществления горизонтального масштабирования;
- Microsoft BizTalk Server 2002 - сервер интеграции приложений и создания инфраструктуры их взаимодействия, основанный на обмене документами между приложениями, принадлежащими разным организациям;
Microsoft не производит серверы приложений общего назначения, однако вместо этого выпускает широкий спектр специализированных серверных продуктов, предназначенных для решения конкретных бизнес-задач (создания портала, разработки сайта электронной коммерции и т.д.) и создания решений на их основе, в целом практически исчерпывающий все современные направления применения серверов приложений.
Oracle9i Application Server (Oracle Corporation)
Oracle9i Application Server (Oracle9iAS) - это сервер приложений, предназначенный для создания широкого спектра корпоративных приложений, начиная от динамических Web-сайтов и заканчивая корпоративными порталами и системами, интегрирующими разнородные корпоративные приложения.
Особенностью данного сервера приложений является наличие в его составе широкого набора специальных сервисов и готовых специализированных решений, использующих СУБД Oracle9i и Oracle9iAS, таких как:
- Oracle9iAS Portal - готовое структурное решение для быстрого развертывания и поддержки работы информационного портала организации, поддерживающее применение портлетов - компонентов портала, содержащих механизмы работы с определенными информационными источниками;
- Oracle9iAS Wireless - программное обеспечение, предназначенное для создания и развертывания приложений беспроводного доступа, в том числе и беспроводных порталов;
- Email Server - решение для организации сервера электронной почты, доступ к которому возможен из любых клиентских программ, поддерживающих Интернет-стандарты POP3 и IMAP. Архитектура, лежащая в основе продукта, ориентирована на множество одновременно работающих пользователей и большой объем хранимых почтовых сообщений;
Enterprise Application Server 4.1 (Sybase)
Sybase Enterprise Application Server (EAServer) - это сервер приложений для создания порталов и корпоративных решений. Этот продукт, как и другие подобные продукты, предоставляет широкий набор инструментов для развертывания Web-приложений и распределенных систем.
Особенностью данного сервера приложений является универсальная по отношению к клиентским компонентам программного обеспечения поддержка широкого спектра технологий построения распределенных систем, включая CORBA, XML, HTML, DHTML, ActiveX, PowerBuilder, COM, а также средства интеграции различных приложений. Многие пользователи этого продукта отмечают высокое качество управления транзакциями и надежные средства обеспечения безопасности. Sybase EAServer позволяет использовать бизнес-логику унаследованных приложений, интегрируя их программный код в среду EAServer при помощи технологии Application Integrators.
2. Серверы Интернет. Web-сервер, его функции и предъявляемые к нему требования. Microsoft Internet Information Services ( MIIS). Web-сервер Apaс he.
Web-сервер - это программа, обрабатывающая сообщения, и работающая с протоколом HTTP (Hypertext Transfer Protocol). Именно этот протокол является основным для WWW. Он представляет собой набор правил для обмена данными и основан на принципе «запрос-ответ». Запрос идет от клиента к серверу и содержит служебную информацию о типе запроса (данные, заголовок, форма), заголовок запроса (допустимые типы файлов, авторизация, версия клиента, адрес, где была активирована ссылка на данный ресурс, и сам адрес) и запрос данных. Ответ идет от сервера к клиенту. В нем находится служебный код (число), показывающий состояние обработки запроса, ответный заголовок (версию сервера, дату, длину и тип данных) и сами данные.
В последнее время увеличилось количество Web-серверов, выпускаемых различными производителями. Естественно, любой Web-сервер поддерживает некоторый минимальный набор функций – поддержка протокола HTTP, настройка на разные порты, создание log-файлов, пользовательские директории, функции защиты. Планирование своей системы вы вряд ли начнете с Web-сервера: скорее вы будете выбирать операционную систему. Тут нужно иметь в виду, что не всякий сервер реализован для конкретной операционной системы. Далее, прежде чем установить сервер, необходимо понять, что он поддерживает, а что нет. Любой сервер поддерживает протокол HTTP, но не всякий сервер изначально поддерживает, например, работу с базами данных. Плюс к этому сейчас любой разработчик Web-серверов создает свой API (Application Program Interface) для работы с сервером. Удобство средств разработки программ для сервера тоже играет немалую роль. Наиболее распространен сервер Apache, который, по оценкам, установлен примерно на 60% всех WWW-серверов, причем является бесплатным, свободно распространяемым и считается одним из самых надежных и стабильных. Сейчас в мире существуют довольно много Web-серверов (несколько десятков), но популярностью пользуются лишь несколько. Самых популярных три: Apache от ASF (Apache Software Foundation), Internet Information Server от Microsoft и iPlanet server (бывший Netscape Enterprise server) от Netscape и Sun.
Apache от ASF
Без преувеличения можно сказать, что это самый распространенный Web- сервер в мире. Сейчас имеются версии фактически для всех известных платформ и операционных систем, в том числе и для Windows NT. Поддержка Windows NT появилась лишь в последней версии, и это еще больше повысило популярность Apache в мире. Его несомненными достоинствами являются надежность, исключительная производительность и огромный набор функций и дополнительных модулей. Версия 1.3.x считается одной из самых стабильных и быстрых среди всего семейства Apache. Основными свойствами Apache являются поддержка кросс-платформ, протокол HTTP/1.1, модульная структура, защита, запись log-файлов.
Краткие характеристики Web сервера Apache:
- последняя версия: 2.0 alpha 4;
- последняя официальная версия: 1.3.12;
- бесплатный, открытый код;
- операционные системы: NetBSD, Digital UNIX, BSDI, AIX, OS/2, SCO, HPUX, Novell NetWare, Macintosh, Be OS, Windows NT, Linux, Windows 95, FreeBSD, Windows 98, IRIX, Solaris;
- HTTP/1.1; есть функция автоматического ответа при изменении документа; возможен запрет доступа с конкретных адресов, к конкретным документам, доступ конкретных пользователей; допускаются изменения без перезапуска сервера;
- поставляется вместе с полным исходным кодом; поддерживает другие протоколы (ftp, telnet); имеет настройку на пользовательские директории; содержит модуль proxy.
iPlanet server (бывший Netscape Enterprise server) от Netscape и Sиn
Не так давно произошло объединение Netscape и Sun в области создания Web- сервера, а именно: бывший Netscape Enterprise server теперь перешел в новое качество – iPlanet server. Это не просто смена имени. Теперь ко многим качествам предыдущего сервера добавилась тесная интеграция с Java- технологиями. Последней версией является 4.1. iPlanet Server, который поставляется на компакт-диске или может быть загружен по Сети. При этом он не является бесплатным. Есть версии как под Windows NT, так и под некоторые UNIX-системы. Привлекает простота установки, конфигурирования и управления. Базовая установка занимает не более 15 минут. Вся дальнейшая настройка производится с использованием Java-программы, запускаемой в браузере откуда угодно. Что касается Java, то, как и следовало ожидать, сервер поддерживает новейшие Java-технологии, такие как Java Servlets 2.1, Java Server Pages .92, JVM, JavaScript 1.4. На сегодняшний день это единственный сервер такого плана. В дополнение к этому iPlanet server включает в себя возможности по управлению доступом к базам данных. В его поставке содержатся драйверы для работы с Oracle, Informix, DB2, и Sybase. С точки зрения программирования для iPlanet server, сейчас наметилась тенденции к объединению с iPlanet Application Server. Это позволит существенно расширить возможности по созданию программ для Web-сервера iPlanet. Все перечисленные свойства делают Web-сервер iPlanet привлекательным для использования в разных областях. Также ведется работа над сервером FastTrack, который будет ограниченным по возможностям аналогом полного сервера, но при этом бесплатным (при полной аналогии с Netscape FastTrack). Что касается технической поддержки, то все описания, справочники и другие материалы относительно iPlanet server сделаны на высоком уровне (впрочем, как и любая документация, находящаяся на сервере Netscape).
Сформулируем кратко основные характеристики сервера:
- последняя версия: 4.1;
- цена: 60 дней бесплатно, далее 1495 долл.;
- операционные системы: HPUX 11.0, Solaris 2.6/7.0, IBM AIX 4.2.1, Compaq Tru64 Unix 4.0d, SGI IRIX 6.5, NT 4 SP4;
- ·поддержка Java Servlets 2.1, Java Server Pages .92, JVM, JavaScript 1.4; Oracle, Informix, DB2, и Sybase; преобразование PDF в HTML; поддержка LDAP;
- может создавать несколько log-файлов, протоколировать производительность, создавать log-файлы для каждого CGI-скрипта; под Windows NT запускается как сервис и/или программа, под UNIX может запускаться из inetd; допускает настройку на несколько портов;
- в поставку включен SNMP агент; поддерживает Windows CGI, HTTP/1.1, в том числе и HTTP/1.1 PUT; есть функция автоматического ответа при изменении документа; поддерживает Netscape Server API;
- возможен запрет доступа с конкретных адресов, доступ конкретных пользователей; есть поддержка S-HTTP; допускаются изменения без перезапуска сервера; есть поддержка SSL второй и третьей версий и авторизации.
- графическая программа установки; графическая программа управления; присутствует программа для оценки производительности во время работы; поддержка директорий пользователей; встроенный алгоритм поиска; возможность удаленного управления.
Internet Information Server (IIS) от Microsoft
Сервер IIS является лучшим для Windows NT. Это и понятно, потому что вряд ли кто-нибудь, кроме разработчиков операционной системы, может сделать программу, полностью использующую возможности этой системы. Версия 4.0 поставлялась бесплатно вместе с Service Pack, а версия 5.0 поставляется исключительно как часть Windows 2000. Версия 5.0, по мнению специалистов, отличается более высокой надежностью, более тесной интеграцией с Windows и целым набором новых свойств. Установка и конфигурирование занимают не более 10 минут. Особенно приятно, что теперь ненужно устанавливать какие-либо Service Pack и не нужно перегружать систему после установки. При всем этом сам сервер занимает около 30 Мбайт на диске и вполне работает на машине Pentium 200 МГц с объемом памяти 128 Мбайт. Однако установить и запустить сервер можно только на Windows 2000 Server. Помимо удобной установки, удобно реализована и система управления сервером. Существует несколько полезных программ шаблонов (Wizards) для выполнения частых и рутинных операций. Вообще, справедливости ради нужно отметить следующее: в том, что касается удобства, мало кто сможет соревноваться с программами Microsoft. К тому же IIS поддерживает известные и включает в себя новые стандарты защиты. Так, есть поддержка известных методов SSL 3.0, Kerberos 5.0, и нового метода Fortezza (новый стандарт безопасности). Наиболее интересной и отличительной чертой IIS является поддержка WebDAV (Web-based Distributed Authoring and Versioning). Это недавно появившийся стандарт, который позволяет превращать внутренние сети в единое пространство, используя ресурсы соседних компьютеров как свои. Для пользователей IIS это означает, что они могут c большим удобством разделять свои рабочие файлы и иметь при этом возможность блокировать файлы. Вместе с тем существуют и некоторые проблемы, и несовместимость. Не совсем корректно происходит работа одновременно с Front Page Server, иногда при изменении конфигурации приходится перезапускать систему, встречаются ошибки при использовании системы удаленного администрирования. Но в целом версия 5.0 является значительным шагом вперед по сравнению с 4.0 в плане надежности и удобства.
Приведем кратко основные характеристики:
- последняя версия: 5.0;
- цена: поставляется вместе с Windows 2000 Server;
- операционные системы: Windows 2000 Server, Advanced Server;
- может создавать несколько log-файлов; протоколирование производительности;
- поддерживает HTTP/1.1;
- возможен запрет доступа с конкретных адресов, к конкретным документам, доступ конкретных пользователей; допускаются изменения без перезапуска сервера;
· графическая программа установки; графическая программа управления; поддерживает другие TCP-протоколы (ftp, telnet); присутствует программа для оценки производительности во время работы; поддержка директорий пользователей; встроенный алгоритм поиска; возможность удаленного управления.