Хэл Фултон - Программирование на языке Ruby

 end

end

В более сложном сервлете, вероятно, использовался бы метод initialize. Тогда передаваемые ему параметры были бы последними при вызове метода server.mount.

К счастью, не нужно писать сервлеты для каждой крохотной задачки, которую должен выполнять WEBrick. У него есть несколько своих предопределенных сервлетов (все в пространстве имен WEBrick::HTTPServlet):

• FileHandler

• ProcHandler

• CGIHandler

• ERBHandler

Поскольку сервлет ProcHandler особенно интересен, скажем о нем несколько слов. Он позволяет «лениться», то есть не создавать подкласса AbstractServlet. Вместо этого мы передаем proc:

# Непосредственное монтирование блока...

server.mount_proc('/here') do |req, resp|

 resp.body = "Это то, что выводит мой блок."

end

# Создать объект Proc и смонтировать его...

some_proc = Proc.new do |req, resp|

 resp.body = ' Это то, что выводит мой Proc.'

end

server.mount_proc('/there', some_proc)

# Другой способ смонтировать Proc...

my_handler = HTTPServlet::ProcHandler.new(some_proc))

server.mount('/another', my_handler)

WEBrick располагает и многими другими возможностями, например точками подключения для выполнения дополнительных задач (скажем, запуска какой-нибудь программы при старте). Имеются также развитые средства протоколирования, аутентификации по протоколу HTTP и т.д. Дополнительную информацию ищите в онлайновой документации на сайте http://ruby-doc.org или где-либо еще.

19.7.4. Сервер Mongrel

Автором Mongrel является Зед Шоу (Zed Shaw) при участии других. Основная цель этого сервера — повысить производительность по сравнению с WEBrick. В данном отношении он добился значительных успехов и работает во много раз быстрее (хотя провести точные измерения сложно: результат зависит от многих факторов).

Mongrel часто используют в сочетании с Rails, а документация местами ориентирована на Rails. Но жесткой привязки к Rails нет — сервер может работать и в других контекстах.

Mongrel — скорее, приложение, тогда как WEBrick больше напоминает библиотеку. Во многом они схожи, но порядок запуска и API различаются.

Во многих случаях Mongrel можно запустить как приложение без написания какого-либо кода. Он понимает три основные команды: start, stop и restart. У команды start много параметров, модифицирующих поведение сервера, например: --port portnum, --log filename, --daemonize и т.д. Чтобы получить полный список, введите такую команду:

mongrel_rails start -h

Запуск в стандартном режиме — это хорошо, но рано или поздно возникнет нужда в чем-то необычном. На этот случай предусмотрены конфигурационные файлы.

Простой способ подготовить конфигурационный файл для Mongrel — воспользоваться флагом -G. Например, можно ввести такую командную строку:

mongrel_rails start -G myconfig.yml -p 3000 -r /home/hal/docs -l my.log

Заданные параметры будут сохранены (в формате YAML) в файле myconfig.yml (при наличии флага -G сервер завершается сразу после создания конфигурационного файла).

Для чтения параметров из конфигурационного файла задайте флаг -C:

mongrel_rails start -С myconfig.yml

Не употребляйте флаг -C вместе с другими. Он предполагает, что все параметры находятся в указанном файле.

Mongrel предлагает API для тонкой настройки поведения сервера. Флаг -S позволяет задать имя сценария, написанного с использованием этого API, который представляет собой небольшой язык предметной области (DSL — Domain-Specific Language). В документации приведен пример такого сценария (который добавляет обработчик для каталога, отличного от текущего):

# Файл: config/mongrel.conf

uri "/newstuff", :handler => DirHandler.new("/var/www/newstuff")

# Вызывается такой командой:

# mongrel_rails start -S config/mongrel.conf

Mongrel можно использовать и так же, как WEBrick. Следующая интуитивно понятная программа прекрасно работает:

require 'mongrel'

class TinyHandler < Mongrel::HttpHandler

 def process(request, response)

  response.start(200) do |head,out|

   head["Content-Type"] = "text/html"

   out.write <<-EOF

    Это всего лишь тест...

   EOF

  end

 end

end

server = Mongrel::HttpServer.new("0.0.0.0", "3000")

server.register("/stuff", TinyHandler.new)

server.register("/other", Mongrel::DirHandler.new("./other"))

server.run.join # Ждать в потоке сервера

Если вы активно работаете с Mongrel, то вас может заинтересовать система GemPlugin. Это, по сути, автозагружаемые gem-пакеты, которые становятся «частью» Mongrel. Например, модуль «Mongrel cluster» позволяет легко управлять кластером серверов Mongrel.

О Mongrel можно рассказывать еще долго. Дополнительная информация о протоколировании, отладке, деталях системы подключения модулей и пр. содержится в онлайновой документации на сайте http://mongrel.rubyforge.org.

19.8. Заключение

В этой главе мы рассмотрели низкоуровневые детали программирования CGI-приложений для Web. Мы видели, как в этом помогают такие инструменты, как модуль mod-ruby. Существует еще немало инструментов, помимо упомянутых в этой книге, например ruby-web, Amrita, Tofu и Cerise. Как обычно, перед тем как сделать выбор, поищите альтернативы.

Мы также познакомились с высокоуровневыми библиотеками и каркасами: Rails, Nitro, IOWA и Wee. Было уделено внимание и автономному серверу WEBrick (и гораздо более быстрому Mongrel).

Теперь обратимся к иному, значительно более простому и абстрактному способу сетевого программирования. Следующая глава посвящена распределенной обработке с применением Ruby.

Глава 20. Распределенный Ruby

Меньше — это больше.

В настоящее время имеется немало технологий, поддерживающих распределенную обработку: различные варианты RPC, а также COM, CORBA, DCE и Java RMI.

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

Зачем это вообще может понадобиться? Причин много. Например, чтобы распределить некоторую вычислительную задачу между многими процессорами. Примером может послужить программа [email protected], которая использует ваш ПК для обработки небольших объемов данных в поисках внеземного разума (кстати, эта программа не является проектом института SETI). Другой пример — привлечение широких масс к взлому шифра RSA129 (эта попытка увенчалась успехом несколько лет назад). Существует очень много задач, которые можно разбить на небольшие части, пригодные для распределенного решения.

Можно также представить себе, что вы хотите предоставить интерфейс к некоему сервису, не раскрывая исходных текстов. Часто это делается с помощью Web-приложений, но из-за отсутствия состояния в протоколе HTTP это не всегда удобно (есть и другие недостатки). Механизм распределенного программирования позволяет решать подобные задачи более естественно.

В мире Ruby ответом на этот вызов стала программа drb, написанная Масатоси Секи (Masatoshi Seki); еще ее название записывают так: DRb. Существуют и другие способы распределенной обработки на Ruby, но drb, пожалуй, самый легкий. Здесь нет сложных служб разрешения имен, как в CORBA. Это всего лишь простая и удобная библиотека, предоставляющая всю необходимую функциональность. В данной главе мы рассмотрим основы работы как с ней самой, так и с надстроенной над ней системой Rinda.

20.1. Обзор: библиотека drb

Библиотека drb состоит из двух основных частей: серверной и клиентской. Грубую границу между ними можно провести следующим образом:

Сервер:

• запускает TCPServer и начинает прослушивать порт;

• привязывает объект к экземпляру сервера drb;

• принимает запросы на соединение от клиентов и отвечает на их сообщения;

• дополнительно может предоставлять контроль доступа (безопасность).

Клиент:

• устанавливает соединение с сервером;

• привязывает локальный объект к удаленному экземпляру сервера;

• посылает сообщения серверу и получает ответы.

Метод класса start_service отвечает за запуск TCP-сервера, прослушивающего указанный порт. Он принимает два параметра: URI (универсальный идентификатор ресурса), задающий порт (если он равен nil, то порт выбирается динамически), и объект, к которому мы хотим привязаться. Этот объект будет доступен удаленному клиенту, который сможет вызывать его методы, как если бы объект был локальным.

require "drb"

myobj = MyServer.new

DRb.start_service("druby://:1234", myobj) # Порт 1234.