Что такое веб система
Разработка веб-системы, «тут» и «там»
Я намеренно пишу, скрывая лица. К сожалению, мой небольшой опыт написания отзывов про работу предприятий говорит про то, что на некоторых лучше не «светить». Они, с одной стороны, начинают суетиться, радуясь, что их заметили. А с другой — делать обиженный вид. Оно мне не надо, читать обидные комментарии, которые могут появиться. Поэтому, единственное, что я укажу про фигурантов — что в статье сравнивается крупная фирма в США и крупное предприятие, принадлежащее большой, можно даже сказать — государственной корпорации в Украине. Предприятия имеют крупные обороты, количество сотрудников схожее, количество работников, завязанных на мою систему — сравнительно похожее, около десяти. Работаю я с ними не первый день, сделал не один проект.
Для начала — очерчу немного задачи, которые я решал «тут» и «там».
Постановка задачи
«Задача Тут»: Система учета клиентов и отгрузки товаров. Система учета возврата документов фактически. Интеграция с центральной базой корпорации, лежащей в Интернете и не имеющей «концов» для подключения
«Задача Там»: Система учета клиентов и выставления им предложений. Фактически это — генератор ПДФ документов с возможностями подсчета разнообразных комплектаций и т. п. вещей.
В обоих случаях, программировал лично я, использован стиль программирования — «с нуля», инструмент — LAMP/FAR/Chrome. Разработка велась практически параллельно, разве что, система «там», в объеме всего задания, была немного больше.
Итак, начиналось все с задания. Немного расскажу как оно делалось «тут» и «там». Задание мне необходимо, так как я очень загружен, и просто так, «на коленке» делать рабочую систему не смогу. Выйдет непонятно что.
Хостинг-провайдеры
На ракспэйсе, крон задание ставил клиент, но у него, что-то не выходило, он дал мне концы и я его отредактировал самостоятельно, заняло пять минут. Тут, — администратор не мог установить крон-таск более месяца. В итоге — я лучше буду работать с медленным ракспейсом там, чем с быстрым мирохостом тут.
Я не хочу никого обидеть. Мол «там» лучше. «Тут» хуже. Да ничего подобного! Мне работать лучше — тут, с быстрым хостингом, с русскоязычным клиентом, с которым мы на коньяк ходили не раз, и знакомы не один день. Но жизнь распоряжается — иначе. И я понимаю, что приходиться выбирать, далекое, но более стабильное.
Где бы я хотел работать, в следующий раз? Конечно с иностранным заказчиком. Он, обычно, не постесняется сказать «спасибо» за сделанное. Причем иногда мне задавался вопрос, — неплохо было бы сказать «спасибо» за вот эту часть проекта, и неплохо — вот за ту. У «нас», хоть заказчик и хороший знакомый, но оплатил он систему. насколько я понимаю самолично, конечно энтузиазма это ему не прибавило. Вышестоящее начальство, просто забило на работающий инструмент, и заставило пользователей вести учет дальше в екселе. В котором 10+ тыщ строк и который на моем «восьмиядернике» открывается до 30-ти секунд времени.
ПС. Вот пара слов про систему, сделанную «тут». Немного скриншотов, чтобы вообще понять, про что идет речь. Про «ихнюю» систему не писал, мы ее правим и правим, да и нету времени немного. Надеюсь, что когда-нибудь я добавлю немного слов и про нее. Но, вообще, сильно оно не отличается.
Вообще интересно очень, как у сообщества хабра складывается работа тут/там. Для того, чтобы как-то это понять, осознать и скорректировать свои методы и пишу это все.
update1,2,3: Хочу сказать спасибо пользователям «хабра» под никамим Goder, side2k, mytribune, которые потратили усилия время на исправление моих грамматических ошибок.
Что такое веб система
В этой главе использованы электронные материалы [KAGA06 ] и книга[KAGA01 ], с. 183-189.
Идеи проекта, первоначально предложенного в конце 80-х годов для использования в CERN (Европейский центр ядерных исследований, Женева), в короткие сроки воплотились в беспрецедентно интенсивно развивающуюся открытую бесконечно масштабируемую распределенную гипермедийную информационную систему с прозрачными для пользователя распределением и неоднородностью ресурсов, обеспечивающую открытые возможности публикации информационных ресурсов и свободный доступ к большинству из них в любой момент времени. Количество пользователей и объем представленных в системе информационных ресурсов продолжают чрезвычайно быстро наращиваться.
Рассмотрим основные принципы технологий Веб, а также цели и существо осуществляемых в них радикальных перемен, направленных на создание Веб нового поколения.
7.1. Свойства Web как информационной системы
Проект рассматриваемого информационного сервиса Интернет первоначально разрабатывался для обеспечения работы Европейского центра ядерных исследований в Женеве (CERN) и назывался «Гипертекст для CERN». Работа над проектом началась в 1989 г. После завершения его реализации и первого опыта практической эксплуатации стало ясно, что использованные в проекте подходы и технологии могут с успехом применяться в среде Интернет более широким сообществом.
С начала 90-х годов новое информационное пространство стало чрезвычайно интенсивно развиваться. Менее пяти лет потребовалось для того, чтобы международное сообщество стало обладателем глобальной открытой информационной системы, названной ее создателями World Wide Web, и эта система продолжает развиваться беспрецедентно интенсивными темпами. Быстро растет не только количество пользователей Веб, но и объем информационных ресурсов, поддерживаемых в его среде. Причины заключаются не только в актуальности и востребованности технологий Веб. Немаловажную роль играют также те достоинства, которыми обладает Веб как информационная система и коммуникационная среда.
К числу достоинств Веб можно отнести:
обеспечение глобального доступа к информационным ресурсам;
возможность свободного доступа к большому объему информационных ресурсов разнообразной тематики из различных источников;
поддержка простого и естественного способа навигации в структуре поддерживаемых информационных ресурсов;
открытость системы для публикации информационных ресурсов и для подключения новых пользователей (в Веб отсутствуют какие-либо органы централизованного управления; он представляет собой совокупность подключенных добровольно и по собственной инициативе Веб-серверов и Веб-клиентов);
простота подготовки информационных ресурсов для публикации в Веб;
наличие свободно-доступного программного обеспечения, как клиентского, так и серверного;
прозрачность для пользователя фактора распределения информационных ресурсов и неоднородности аппаратно-программных платформ;
низкий уровень требований к квалификации пользователя и его техническим средствам доступа к ресурсам Веб.
Для формирования технической политики развития Веб в 1994 г. в рамках CERN при поддержке Агентства перспективных исследований Министерства обороны США (DARPA) и Европейской комиссии (EC) был учрежден Международный индустриальный консорциум World Wide Web Consortium (W3C), в состав которого входит более 300 членов. Среди них компании, занимающиеся разработками и использованием программных и информационных продуктов для среды Веб, поставщики технических средств, телекоммуникационные компании, правительственные и академические организации.
Главная задача W3C состоит в разработке рекомендаций по новым технологиям, а также реализующих их спецификаций, имеющих статус стандарта консорциума.
Веб-сервисы в теории и на практике для начинающих
Что такое веб-сервисы?
Прежде всего, веб-сервисы (или веб-службы) — это технология. И как и любая другая технология, они имеют довольно четко очерченную среду применения.
Если посмотреть на веб-сервисы в разрезе стека сетевых протококолов, мы увидим, что это, в классическом случае, не что иное, как еще одна надстройка поверх протокола HTTP.
С другой стороны, если гипотетически разделить Интернет на несколько слоев, мы сможем выделить, как минимум, два концептуальных типа приложений — вычислительные узлы, которые реализуют нетривиальные функции и прикладные веб-ресурсы. При этом вторые, зачастую заинтересованы в услугах первых.
Но и сам Интернет — разнороден, т. е. различные приложения на различных узлах сети функционируют на разных аппаратно-программных платформах, и используют различные технологии и языки.
Чтобы связать все это и предоставить возможность одним приложениям обмениваться данными с другими, и были придуманы веб-сервисы.
По сути, веб-сервисы — это реализация абсолютно четких интерфейсов обмена данными между различными приложениями, которые написаны не только на разных языках, но и распределены на разных узлах сети.
Именно с появлением веб-сервисов развилась идея SOA — сервис-ориентированной архитектуры веб-приложений (Service Oriented Architecture).
Протоколы веб-сервисов
На сегодняшний день наибольшее распространение получили следующие протоколы реализации веб-сервисов:
На самом деле, SOAP произошел от XML-RPC и является следующей ступенью его развития. В то время как REST — это концепция, в основе которой лежит скорее архитектурный стиль, нежели новая технология, основанный на теории манипуляции объектами CRUD (Create Read Update Delete) в контексте концепций WWW.
Безусловно, существуют и иные протоколы, но, поскольку они не получили широкого распространения, мы остановимся в этом кратком обзоре на двух основных — SOAP и REST. XML-RPC ввиду того, что является несколько «устаревшим», мы рассматривать подробно не будем.
Нас в первую очередь интересуют вопросы создания новых веб-служб, а не реализация клиентов к существующим (как правило поставщики веб-сервисов поставляют пакеты с функциями API и документацией, посему вопрос построения клиентов к существующим веб-службам менее интересен с точки зрения автора).
SOAP против REST
Проблемы данного противостояния хорошо описаны в статье Леонида Черняка, найденой на портале www.citforum.ru.
По мнению же автора, кратко можно выделить следующее:
SOAP более применим в сложных архитектурах, где взаимодействие с объектами выходит за рамки теории CRUD, а вот в тех приложениях, которые не покидают рамки данной теории, вполне применимым может оказаться именно REST ввиду своей простоты и прозрачности. Действительно, если любым объектам вашего сервиса не нужны более сложные взаимоотношения, кроме: «Создать», «Прочитать», «Изменить», «Удалить» (как правило — в 99% случаев этого достаточно), возможно, именно REST станет правильным выбором. Кроме того, REST по сравнению с SOAP, может оказаться и более производительным, так как не требует затрат на разбор сложных XML команд на сервере (выполняются обычные HTTP запросы — PUT, GET, POST, DELETE). Хотя SOAP, в свою очередь, более надежен и безопасен.
В любом случае вам решать, что больше подойдет вашему приложению. Вполне вероятно, вы даже захотите реализовать оба протокола, чтобы оставить выбор за пользователями службы и — это ваше право.
Практическое применение веб-сервисов
Поскольку речь идет о практическом применении, нам нужно выбрать платформу для построения веб-службы и поставить задачу. Так как автору ближе всего PHP 5, мы и выберем его в качестве технологии для построения службы, а в качестве задачи примем следующие требования.
Допустим, нам необходимо создать службу, предоставляющую доступ к информации о курсах валют, которая собирается нашим приложением, и накапливается в базе данных. Далее посредством веб-сервиса, данная информация передается сторонним приложениям для отображения в удобном для них виде.
Как видим задача довольно проста и, с точки зрения самой службы, ограничивается лишь чтением информации, но в практических целях нам этого будет достаточно.
Этап первый — реализация приложения сбора информации о курсах валют.
Информацию о курсах валют мы будем собирать со страниц сайта НБУ (Национального Банка Украины) ежедневно и складывать в базу данных под управлением СУБД MySQL.
Создадим структуру данных.
Таблица валют (currency):
Таблица номиналов обмена (exchange):
Для работы с базой данных воспользуемся ORM слоем на базе пакета PHP Doctrine. Реализуем граббер:
класс Grubber (models/Grabber.php):
и сам граббер (grabber.php):
Теперь заставим наш граббер отрабатывать раз в сутки в 10:00 утра, путем добавления команды запуска граббера в таблицы cron:
Все — у нас есть достаточно полезный сервис.
Теперь реализуем веб-сервис, который позволит другим приложениям извлекать данные из нашей базы.
Реализация SOAP сервиса
Для реализации веб-сервиса на базе SOAP протокола, мы воспользуемся встроенным пакетом в PHP для работы с SOAP.
Поскольку наш веб-сервис будет публичным, хорошим вариантом будет создание WSDL файла, который описывает структуру нашего веб-сервиса.
WSDL (Web Service Definition Language) — представляет из себя XML файл определенного формата. Подробное описание синтаксиса можно найти здесь.
На практике будет удобно воспользоваться функцией автоматической генерации файла, которую предоставляет IDE Zend Studio for Eclipse. Данная функция позволяет генерировать WSDL файл из классов PHP. Поэтому, прежде всего, мы должны написать класс, реализующий функциональность нашего сервиса.
класс CurrencyExchange (models/CurrencyExchange.php):
Отметим, что для автоматической генерации WSDL, нам необходимо написать комментарии в стиле javadoc, потому что именно в них мы прописываем информацию о типах принимаемых аргументов и возвращаемых значений. Неплохо также описывать в нескольких словах работу методов — ведь WSDL послужит описанием API для сторонних разработчиков, которые будут использовать ваш веб-сервис.
Не пишите в докблоках param void или return void — для WSDL это не критично, но вот при реализации REST доступа к тому-же классу у вас возникнут проблемы.
Теперь в Zend Studio входим в меню File->Export. выбираем PHP->WSDL, добавляем наш класс, прописываем URI-адрес нашего сервиса и создаем WSDL-файл. Результат должен быть примерно таким: http://mikhailstadnik.com/ctws/currency.wsdl
Если вы будете добавлять новую функциональность в ваш веб-сервис, вам нужно будет пересоздавать WSDL-файл. Но здесь не так все гладко. Следует учитывать, что SOAP-клиент, который уже запрашивал ваш WSDL файл, кеширует его на своей стороне. Поэтому, если вы замените старое содержимое новым в WSDL файле, некторые клиенты его не прочтут. А значит, при добавлении новой функциональности, дописывайте версию в имя вашего файла. И не забудбте обеспечить обратную совместимость для старых клиентов, особенно если вы не являетесь их поставщиком.
С другой стороны, WSDL довольно жестко задает структуру веб-сервиса, а это значит, что, если существует необходимость ограничить функциональность клиента по сравнению с сервером, вы можете не включать определенные методы ваших классов в WSDL. Таким образом они не смогут быть вызваны, несмотря на то, что существуют.
Реализация же самого сервера не предстваляет теперь никакой сложности:
Вы можете попробовать веб-сервис в работе по адресу: http://mikhailstadnik.com/ctws/
Там же доступен тестовый клиент: http://mikhailstadnik.com/ctws/client.php
Код простейшего клиента может быть таким:
Реализация REST сервиса
REST — это не стандарт и не спецификация, а архитектурный стиль, выстроенный на существующих, хорошо известных и контролируемых консорциумом W3C стандартах, таких, как HTTP, URI (Uniform Resource Identifier), XML и RDF (Resource Description Format). В REST-сервисах акцент сделан на доступ к ресурсам, а не на исполнение удаленных сервисов; в этом их кардинальное отличие от SOAP-сервисов.
И все же удаленный вызов процедур применим и в REST. Он использует методы PUT, GET, POST, DELETE HTTP протокола для манипуляции объектами. Кардинальное отличие его от SOAP в том, что REST остается HTTP-запросом.
Поскольку в PHP пока еще нет реалзации REST, мы воспользуемся Zend Framwork, в который включена реализация как REST клиента, так и REST севера.
Воспользуемся уже готовым классом CurrencyExchange. Напишем сам сервер:
Как видите все очень сходно и просто.
Однако, следует оговорить, что наш REST-сервис менее защищен, чем SOAP-сервис, так как любой добавленый метод в класс CurrencyExchange при его вызове отработает (сам класс определяет сруктуру сервиса).
Проверим работу нашего сервиса. Для этого достаточно передать параметры вызова метода в сроке GET-запроса:
При желании или необходимости вы можете самомтоятельно задавать структуру ваших XML ответов для сервиса REST. В этом случае, также будет необходимо позаботиться и о создании определения типа вашего XML документа (DTD — Document Type Definition). Это будет минимальным описанием API вашего сервиса.
Простейший тестовый клиент к REST сервису может быть в нашем случае таким:
В принципе, Zend_Rest на сегодняшний день нельзя назвать наиболее точной реализацией принципов REST. Утрируя, можно говорить о том, что эта реализация свелась к удаленному вызову процедур (RPC), хотя философия REST гораздо шире.
Вы можете скачать пример в исходных кодах c PHP Doctrine и Zend Framework (4,42 Мб).
Заключение
Мы выполнили задачу минимум и показали, что такое веб-сервисы, для чего они нужны и как их реализовывать. Естественно, приведенный пример, возможно, несколько оторван от жизни, но он был выбран лишь в качестве инструмента для объяснения предмета и сущности веб-сервисов.
Кроме того мы увидели, что реализация веб-сервиса — задача довольно простая при использовании современного инструментария, который позволяет сконцентрироваться, в первую очередь, на разработке функциональности самого сервиса, не заботясь о низкоуровневой реализации протоколов.
Автор надеется, что данный материал будет действительно полезен тем, кто становится на тропу разработки веб-служб.