CA PLEX r6 – быстрая разработка web-приложений и сервисов на основе моделей


Оглавление (нажмите, чтобы открыть):

Разработка веб-приложений и веб-сервисов на C++. Как это правильно делать

September 6, 2020

​Современный мир не мыслим без работы в сети. Это может быть сеть предприятия, или Интернет, или какая-либо виртуальная частная сеть. Задачи, связанные с работой по сети, возникают в любой отрасли, практически без исключений. И если бы речь шла только о сайтах, раздающих статический материал, никому бы и в голову не пришло, писать это на С++.

Популярная сейчас концепция “микросервисов” предлагает нам, создавать распределенные в сети приложения, на базе связанных между собой небольших программ, каждая из которых выполняет строго определенную (в идеале только одну) функцию в общей системе. Очень часто такие системы пишутся сразу на нескольких языках — например, ядро на С++, а “периферия” на Питоне.

Компоненты системы взаимодействуют между собой по сети, используя различные протоколы. Также предоставляется способ внешнего взаимодействия с системой. Обычно, в качестве способа интеграции с “внешним миром” реализуется протокол на базе REST (Uber, Яндекс.Диск, DigitalOcean, AWS, список почти бесконечен). Реализовать такое взаимодействие можно чуть ли не в автоматическом режиме (Swagger). Код в этом случае будет сгенерирован для любого языка… но не для С++.

Как же быть, если нам нужно использовать C++, для реализации веб-сервиса, поддерживающего REST-API ? Почему нам может понадобиться именно С++ для этой задачи? Об этом и многом другом поговорим далее.

Веб-фреймворки и Веб-сервера

Итак, веб-сервисы и веб-приложения создаются, как правило, не на С++. Любой другой язык предоставляет массу качественных веб-фреймворков: у Python есть Django, Flask, Tornado; у PHP есть Symfony; у Javascript (Node.js) есть Express; у Java есть Spring Web MVC; у Erlang есть N2O и так далее. Это отличные решения, которые, в первую очередь, позволяют программисту не погружаться в протокол HTTP (RFC2616), а сразу сосредоточиться на бизнес-логике своего приложения. Многие веб-фреймворки имеют в своем составе реализацию ORM, что упрощает работу с базами данных. Кроме этого, веб-фреймворки предоставляют:

  • диспетчеризацию URL;
  • систему шаблонов, для удобного создания html-страниц;
  • средства для интернационализация и локализации;
  • авторизацию и аутентификацию;
  • и многое другое.

Но одного веб-фреймворка не достаточно для создания веб-сервиса, понадобится еще, как минимум, веб-сервер. В мире не так много веб-серверов, заслуживающих внимание. Это Apache HTTP server, Nginx, lighttpd, Tornado, Node.js, Yaws, Netty. Веб-серверов существует меньше, чем веб-фреймворков, и новые появляются значительно реже (Caddy). Зачем же нужен веб-сервер, если есть веб-фреймворк?

Веб-сервер — это надежная, быстрая, потребляющая небольшое количество ресурсов программа. Веб-сервер способен поддерживать одновременное подключение тысяч клиентов, и не терять при этом работоспособность. Веб-сервер отлично справляется с такими задачами как: шифрование данных (SSL termination), сжатие данных, обслуживание статических запросов, кеширование, балансировка нагрузки и так далее. Веб-фреймворки не касаются решения этих задач. Эти задачи не являются их зоной ответственности. Фактически, установив и настроив веб-сервер на прием запросов из внешнего мира, мы снимаем огромный “пласт” работы с веб-фреймворка (который “как бы спрятан” за веб-сервером). Например, ему больше не обязательно “быть готовым” встретить тысячи пользователей. Вместо этого, мы можем развернуть 20 веб-фреймворков за одним веб-сервером, и тонко настроить балансировку нагрузки.

То, что веб-сервер необходимо выбирать именно из числа выше названных, подтверждается крупнейшими компаниями — Яндекс, Google, Facebook, Bloomberg, Amazone — какой бы веб-фреймворк не использовался этими компаниями, неизменным остается то, что никто не пишет свой веб-сервер. Обычно, берут либо Nginx, либо Apache. И это первое, что нам нужно уяснить — при разработки веб-приложения на С++, нам также потребуется веб-сервер из числа названных.

Зачем писать веб-приложение на С++

Возможно, вы программист С++ и другие языки вам не знакомы. Возможно, в компании не разрешают писать на чем-либо кроме С++, а сделать свой веб-сервис необходимо по ТЗ. Ситуации бывают разные, и говорить, что С++ для этого совершенно не подходит не правильно.

Есть одна, но очень веская причина разрабатывать back-end веб-сервиса на С++ — любой интерпретируемый язык (будь то Python с его несчастным GIL-ом, Ruby, PHP и другие) проиграет С++ в быстродействии и потреблении ресурсов. Хорошо написанная, и оптимизированная компилятором, программа на С++ будет работать не хуже аналогичного варианта на С. Если, высокая эффективность для вас не главное требование, то возможно С++ не стоит брать для разработки веб-сервиса. Писать на С++ однозначно придется больше и дольше. Однако, есть вы хотите получить максимум КПД от своих вычислительных мощностей (которых всегда не хватает), то вам придется перейти на компилируемый язык. И С++ тут отличный и хорошо знакомый всем кандидат (языки Go и Rust еще не завоевали такой популярности, а Java и C# могут оказаться избыточными для микросервиса).

Итак, веб-приложение или веб-сервис будем разрабатывать именно на С++.

Почему не нужно писать свой Веб-сервер на Asio

Я очень много разрабатываю с использованием Asio и добиваюсь очень эффективных результатов. Миллионы сообщений переданных по сети в течении всего одной секунды, сериализованных и зашифрованных. Asio — это отличная библиотека! Но она не подходит для того, чтобы делать на ней веб-сервер… Почему? Ответ — это слишком низкоуровневый подход. Конечно, возможно у вас получится написать эффективный, быстрый и надежный код. Но сколько на это уйдет времени? И будет ли это решение в итоге быстрее, чем Nginx? И главное, как вы будете решать вопрос функциональных возможностей? Давайте просто сравним, что дает нам Asio, и что предлагает его “Java аналог” — Netty:

Asio C++ Library

Netty framework

Сразу скажу, что поддержка SSL и TLS в Asio хуже, чем у Netty. По сути, вам придется напрямую работать с OpenSSL, так как ASIO предоставляет весьма условные классы-обертки. Здесь можно было бы обойтись и вовсе без Asio, так как вся работы возлагается на OpenSSL. Но шифрование в данном случае не главное.

Обратите внимание на протоколы. Asio заканчивается на уровне TCP. Дальше вам всё нужно будет написать самим. Скорее всего потребуются дополнительные библиотеки, чтобы, например, обеспечить сжатие данных в протоколе HTTP, чтобы поддержать протокол Web-сокетов. В конце концов, чтобы просто получить веб-сервер, соответствующий протоколу HTTP/1.1. Ведь в С++ нет даже стандартной библиотеки для парсинга URL (кто считает это ерундой, тот не парсил арабские линки). Всё это вы либо возьмете из внешних библиотек, либо будете очень долго писать сами, либо (что хуже всего) откажетесь вовсе поддерживать (сказав — мне это не нужно).

Какой бы путь вы не выбрали с Asio, вы потеряете очень много времени, и не приблизитесь к решению именно вашей задачи. Вы просто будете писать свой веб-сервер, который в лучше случае сможет работать также надежно и быстро, как Nginx. И который в лучшем случае поддержит хотя бы 10% от того, что сразу идет в базовой конфигурации любого существующего веб-сервера. Вы удовлетворите только собственное желание “попробовать сделать самому”. Пишите на Asio то, что нельзя взять в готовом варианте. Веб-сервер же установите Nginx. На это у вас уйдет 1 минута, и 10 минут, чтобы сконфигурировать его работу.

Почему не нужно брать Веб-сервер на Qt, POCO, Wt C++ или cpp-netlib

К этому моменту мне, возможно, уже удалось отговорить вас писать веб-сервер самостоятельно. Но как насчет Qt? POCO? Wt? Или cpp-netlib? Последняя библиотека, кстати, использует Asio. Все перечисленные инструменты — это C++, а не Java/Python/C. Они имеют хорошие функциональные возможности, готовые реализации веб-серверов, и даже предлагают себя в качестве веб-фреймворков. Как, к примеру, Wt (у Wt на борту есть Bootstrap 2 и 3, что кажется уже перебором). Казалось бы на С++ есть всё готовое. Бери и используй. Но не спешите…

Вот один из многочисленных бенчмарков HTTP-серверов, опубликованный на Хабре. Смотрим результаты: POCO медленнее Nginx-а всего лишь в 5 раз, cpp-netlib медленнее в 20 раз! И вот вопрос: зачем тянуть в проект большие внешние библиотеки, которые изначально хуже, чем тот же Nginx? Nginx активно развивается на протяжении более десяти лет (как и Apache или lighttpd). Повторить эту работу не просто даже специализированным библиотекам. Отмечу, что все перечисленные C++ библиотеки, также уступают в функциональности тому же Apache. Для Apache сообщество на протяжении длительного времени написало такое количество подключаемых модулей, что их трудно все перечислить.

В итоге, если вы пишете свой веб-сервис или веб-приложение на С++, вам лучше использовать в качестве веб-сервера Nginx, Apache или lighttpd. При чем не нужно компилировать и линковать код этих веб-серверов вместе со своим кодом. Эти сервера должны быть установлены “штатно”, как и любые другие программы, и работать самостоятельно. Нам же остается только найти решение, как “подружить” программу на С++ с внешним веб-сервером. И решение здесь очень простое.

SCGI и FastCGI — способ подружить Веб-сервер и программу на C++

Если эти технологии вам не знакомы, то прочитайте о них на Википедии. В двух словах — это клиент-серверные протоколы взаимодействия веб-сервера и приложения (в нашем случае С++ приложения). Эти два протокола являются дальнейшим развитием протокола CGI. Однако, CGI работает медленно, и лучше этот подход не рассматривать.

FastCGI-приложения используют Unix Domain Sockets или TCP/IP для связи с веб-сервером. Первый вариант менее гибкий, но более быстрый. Второй вариант, это обычное сетевое клиент-серверное взаимодействие. И здесь (внимание) есть смысл применить свои навыки в Asio, и написать эффективный транспорт для общения с веб-сервером! Потому что, только это от вас и требуется.

Nginх “встретит” запрос пользователя, расшифрует его, определит куда следует направить дальше этот запрос, и передаст его вашему приложению на С++. Дождется ответа от вашего приложения, сожмет и зашифрует данные, а затем передаст их пользователю. Масштабировать такое решение очень легко — просто запустите столько копий FastCGI-приложения сколько потребуется (на разных машинах или на одной), настройте балансировку в Nginx и всё!

С вашего приложения снимается огромная работа, а в замен вам нужно поддержать на выбор FastCGI или SCGI. Тут есть два подхода — либо взять готовые решения, либо совместить, к примеру, свой транспорт на Asio и “чистый” парсер того же протокола SCGI. Кстати, SCGI реально реализовать одному программисту всего за несколько дней в полном объеме (с нуля).

В любом случае, вашей работы теперь существенно меньше, а результат просто отличный — это и настоящий веб-сервер, через который не страшно смотреть в мир, и простое масштабирование, и высокая скорость работы. Это надежный проверенный способ, о котором много написано статей, в том числе и на Хабре (здесь и здесь).

В итоге, что мы имеем. При разработке веб-сервиса или веб-приложения на С++ нам нужен внешний хороший веб-сервер, а наша программа на С++ должна поддержать протокол взаимодействия с выбранным веб-сервером — FastCGI или SCGI. Двигаемся дальше: как помочь себе в создании веб-фреймворка на С++.

Как помочь себе в создании веб-фреймворка на С++

Я против написания веб-сервера, но, я “за” написание собственного веб-фреймворка. Вот только рутинную работу, нужно на кого-то переложить. А самим написать самое “вкусное” — тот же диспетчер URL, на шаблонах, с созданием своего DSL (как же без этого). А что значит — рутинная работа?

В начале я описывал, что делает веб-фреймворк, и что делает веб-сервер. Задачи этих двух компонентов не пересекаются (обычно). Веб-сервер мы взяли готовый (например, Nginx), а в своей программе поддержали SCGI, но работа на этом не закончилась. Нам нужно добавить себе в программу те возможности, которые обычно предоставляются веб-фреймворками. И здесь целесообразно использовать по максимум готовые решения.

Например, нам потребуется очень много парсить… В начале нужно парсить URL — задача абсолютно стандартная. Решений очень много — от могучих парсеров по типу Google’s URL parsing library​, до минималистичных библиотек в один исходный файл. Затем, потребуется парсить передаваемые сообщения — это могут быть и данные форм, и Json-данные, и xml-данные. Но тут уже всё зависит от вашего сервиса. Вы, например, вольны отказаться от использования в REST-протоколе формата XML. И тогда парсер xml вам будет не нужен.

Вторая задача, это “общение” с базой данных. Как и в случае с парсерами, вам нужно будет выбрать решение на С++, исходя из потребностей. Если это “традиционная” база данных, возможно вам подойдет SQLAPI++ Library. Если вы используете какую-либо NoSQL базу, то существуют соответствующие клиенты на С++ и для них (например, для MongoDB).

Несколько слов про ORM. Задумайтесь, так ли он нужен в вашем микросервисе? ORM полезен в том случае, когда ваше приложение достаточно большое и совершает много простых запросов к базе. В этом случае, ORM скрывает всю эту “кухню”. Но если ваш микросервис делает всего 10-20 различных запросов к базе, то не стоит создавать весь этот overhead под названием ORM. Это всегда влечет дополнительные накладные расходы. Кроме того, вы лишаете себя возможности оптимизировать каждый из запросов. Лучше напишите эти запросы один раз, и забудьте про ORM. ORM, особенно “самописный”, скорее мешает в дальнейшем сопровождении кода, чем помогает. SQL знаком очень многим, а ORM — это обычная “вкусовщина”.

Сейчас популярны так называемые “микрофреймворки”. В них отсутствует такие возможности как:

  • система рендеринга html-шаблонов
  • ORM, и в принципе средства доступа к базам данных
  • различные плагины авторизации, аутентификации, роли, работа с email

Всё это легко подключается, если есть такая необходимость. Этому принципу и надо следовать. То что действительно нужно, у вас уже есть — это полноценный безопасный быстрый веб-сервер со всеми его возможностями, библиотеки для разбора URL и JSON, какой-либо драйвер к базе данных. Возможно на этом и следует остановиться. Объединить все компоненты и вашу бизнес-логику в красивое быстрое решение на С++.

Итак. При разработке веб-сервиса или веб-приложения на С++ нам нужен хороший веб-сервер, набор небольших микро-библиотек для парсинга URL, и тех форматов данных, которые будут передаваться, и возможно драйвер для базы данных. Также нам нужно поддержать протокол FastCGI или SCGI в своей программе на С++. Всё.

Заключение

Решение, которое вы получите в итоге будет в первую очередь эффективным, надежным и гибким. Все компоненты, от веб-сервера до парсеров, вы сможете в любой момент заменить на более подходящие. Ваши бенчмарки будут показывать отличные результаты, лучше и выше, чем у POCO или cpp-netlib. При этом ваши возможности по масштабированию и расширению функционала не будут ничем ограничены. Нужно интегрировать систему рендеринга html — без проблем, внедрить LDAP аутентификацию — без проблем. Если ничего из этого не нужно — то ваш веб-сервис будет по-настоящему “микросервисом”, и никакого лишнего кода.

Предложенный в этой статье подход не является чем-то новым, скорее наоборот. Спецификация на FastCGI появилась кажется еще в 90-х. В это время появились и веб-сервера, которые поддерживали протокол FastCGI. В подтверждение своих слов привожу ссылку на интересную лекцию от Яндекса: Архитектура высоконагруженного сервиса на примере бэкенда Яндекс.Store. Обратите особое внимание на 8-ой слайд. На нем вы увидите всё о чем было написано в этой статье.

Модель быстрой разработки приложений (RAD-модель)

В RAD-модели конечный пользователь играет решающую роль. В тесном взаимодействии с разработчиками он участвует в формировании требований и апробации их на работающих прототипах. Таким образом, в начале жизненного цикла на конечного пользователя выпадает большая часть работы, но в результате этого создаваемая система формируется более быстро.

В традиционном жизненном цикле разработки большую часть работы составляют программирование и тестирование. При автоматизации программирования и повторном использовании кода, применяемых в RAD-модели, большую часть работы составляют планирование и проектирование.

На рисунке, поясняющем принцип RAD-модели, указаны этапы процесса разработки и отображено участие заказчиков (штриховая линия) на каждом из них.

Модель включает в себя следующие фазы:

Составление требований и планирование – осуществляются с использованием, так называемого метода совместного планирования требований (планирование работ по созданию программного продукта и составление требований к программному продукту выполняются одновременно), который заключается в структурном анализе и обсуждении решаемых задач;

Описание пользователя – проектирование программного продукта, выполняемое при непосредственном участии заказчика;

Создание – детальное проектирование, кодирование и тестирование программного продукта, а также поставка его заказчику;

Сопровождение – приемочные испытания, установка программного продукта и обучение пользователей.

Модель обладает следующими достоинствами:

1. Использование современных инструментальных средств позволяет сократить время цикла разработки;

2. Привлечение к работе заказчика сводит к минимуму риск того, что он останется недоволен готовым программным продуктом;

3. Повторно используются компоненты уже существующих программ.

В то же время ей присущи и недостатки:

1. Если заказчики не могут постоянно участвовать в процессе разработки, то это может негативно сказаться на программном продукте;

2. Для работы нужны высококвалифицированные кадры, умеющие пользоваться современными инструментальными средствами;

3. Существует риск, что работа над программным продуктом никогда не будет завершена, так как может быть зациклена, поэтому всегда надо вовремя остановиться.

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

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Для студента самое главное не сдать экзамен, а вовремя вспомнить про него. 10023 — | 7495 — или читать все.

91.105.232.77 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.

Отключите adBlock!
и обновите страницу (F5)

очень нужно

Архитектура веба: основы для начинающих разработчиков

Рассказывает Jonathan Fulton, VP Engineering в StoryblocksCo

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

Пользователь ищет в Google «Strong Beautiful Fog And Sunbeams In The Forest». Первый результат отправляет его на Storyblocks. Пользователь нажимает на ссылку, которая перенаправляет его браузер на страницу с изображением. Тем временем браузер отправляет запрос на DNS-сервер, чтобы установить соединение со Storyblock, и, получив ответ, отправляет запрос на сайт.

Запрос попадает на балансировщик нагрузки, который случайным образом выбирает для обработки запроса один из десяти (или около того) веб-серверов, на которых запущен сайт. Веб-сервер достаёт некоторую часть информации об изображении из службы кэширования, а остальное — из основной базы данных. Если цветовой профиль для изображения ещё не был вычислен, задача «определить цветовой профиль» будет добавлена в очередь заданий. Эти задания серверы обрабатывают асинхронно и соответствующим образом обновляют базу данных с результатами.

Затем происходит поиск похожих фотографий: в службу полнотекстового поиска отправляется запрос с заголовком фотографии в качестве входных данных. Если пользователь авторизовался в Storyblocks, информация о его учётной записи загружается из базы данных учётных записей. Наконец, данные о просмотре страницы отправляются в firehose-хранилище для последующей записи в облачную систему хранения. В конечном счёте, эти данные будут загружены в хранилище данных, которое аналитики используют для обработки.

14 ноября в 18:30, Витебск, беcплатно

Теперь сервер рендерит страничку в HTML и отправляет её обратно браузеру пользователя, проходя сначала через балансировщик нагрузки. Страница содержит Javascript- и CSS-файлы, которые загружены в облачную систему хранения, подключённую к CDN, поэтому браузер связывается с CDN для получения содержимого. Наконец, браузер отображает страницу пользователю.

Далее будет рассказано про каждый элемент в деталях. Конечно, каждую тему можно рассмотреть гораздо подробнее, но в рамках этой статьи будут разобраны только основы. Этого должно хватить для понимания архитектуры современного веб-проекта.

1. DNS

DNS расшифровывается как «Domain Name System» (система доменных имён). Это базовая технология, которая делает возможной работу интернета. На самом базовом уровне DNS обеспечивает поиск пары из доменного имени и IP-адреса (например, google.com и 85.129.83.120), что позволяет компьютеру отправить запрос на соответствующий сервер. По аналогии с телефонными номерами разница между доменным именем и IP-адресом такая же, как и между вызовом Джону Доу и звонком по номеру 201-867-5309. Для поиска номера Джона нужна телефонная книга, а для поиска IP-адреса домена — DNS. Таким образом, можно считать DNS телефонной книгой интернета.

2. Балансировщик нагрузки

Прежде чем начать обсуждение балансировки нагрузки, нужно сделать шаг назад, чтобы обсудить горизонтальное и вертикальное масштабирование приложений. Что это и в чём разница? Эта тема хорошо объяснена в посте на StackOverflow: «горизонтальное» масштабирование характеризуется добавлением новых машин в пул ресурсов, тогда как «вертикальное» подразумевает, что наращивается мощность (например, увеличивается CPU или RAM) существующей машины.

В веб-разработке проект масштабируется горизонтально как минимум потому, что всё ломается. Серверы падают по непонятным причинам. Сети деградируют. В некоторых ЦОД-ах время от времени отключается свет. Несколько серверов позволит переживать незапланированные отключения без нарушения работы приложения. Другими словами, приложение становится «отказоустойчивым». Горизонтальное масштабирование позволяет минимально связывать разные части проекта (веб-сервер, базу данных и т. д.), потому что каждая из них запускается на разных серверах. Наконец, может наступить такой момент, когда вертикальное масштабирование более невозможно, так как в мире нет достаточно мощного компьютера для выполнения всех вычислений приложения. Поисковая платформа Google является типичным примером, хотя это относится и к компаниям с гораздо меньшими масштабами. Например, Storyblocks обычно использует от 150 до 400 AWS-машин EC2 в любой момент времени. Было бы сложно получить всю эту вычислительную мощность с помощью вертикального масштабирования.

Давайте вернёмся к балансировщикам нагрузки. Благодаря им возможно горизонтальное масштабирование. Они направляют входящие запросы на один из множества серверов приложения, которые обычно являются зеркальными копиями друг друга, и отправляют ответ обратно пользователю. Любой сервер обрабатывает запросы одинаково, так что балансировщик занимается распределением заданий, чтобы никакой из них не был перегружен.

Вот и всё. Концептуально балансировщики нагрузки довольно просты и понятны.

3. Серверы веб-приложений

Если смотреть издалека, серверы веб-приложений относительно просты. Они выполняют основную бизнес-логику, которая обрабатывает запрос пользователя и отправляет HTML обратно браузеру. Чтобы выполнять свою работу, они обычно общаются с различными бэкэнд-инфраструктурами, такими как базы данных, серверы кэширования, очереди заданий, службы поиска и т. д. Как упоминалось выше, обычно есть как минимум два, а то и больше, сервера, подключённых к балансировщику нагрузки для обработки пользовательских запросов.

Для реализации сервера приложений требуется выбрать конкретный язык (Node.js, Ruby, PHP, Scala, Java, C#, .NET и т. д.) и MVC-фреймворк для этого языка (Express для Node.js, Ruby on Rails, Play для Scala, Laravel для PHP и т. д.).

4. Сервер баз данных

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

Здесь стоит упомянуть SQL и NoSQL.

SQL расшифровывается как «Structured Query Language» (язык структурированных запросов). Он был изобретён в 1970-х годах, чтобы создать стандартный способ запросов к реляционным наборам данных, доступных широкой аудитории. SQL-базы данных хранят данные в таблицах, которые связаны между собой общими ключами. Такие ключи обычно представлены целыми числами.

Рассмотрим типичный пример хранения информации об истории адресов пользователей. Получатся две таблицы — user и user_addresses, — связанные друг с другом идентификатором пользователя (id в таблице user). Их можно увидеть на изображении ниже. Таблицы связаны, потому что столбец user_id в user_addresses является «внешним ключом» в столбце id в таблице users.

Если вы мало что знаете о SQL, настоятельно рекомендуем ознакомиться с нашим курсом по этой теме. Эта технология используется в веб-разработке почти везде, поэтому стоит хотя бы понимать основы для правильного построения приложений.

NoSQL расшифровывается как «не-SQL» и представляет собой более новый набор технологий баз данных. Он был разработан для обработки очень больших объёмов информации, которые могут генерироваться крупномасштабными веб-приложениями. Большинство вариантов SQL плохо масштабируются горизонтально, а масштабироваться вертикально могут только до определённого момента. Если вы ничего не знаете о NoSQL, рекомендуем начать знакомство со следующих статей:

Также хочется отметить, что индустрия повсеместно полагается на SQL даже как на интерфейс для баз данных NoSQL, поэтому нужно изучать SQL, даже если он не требуется в вашей работе. В современных реалиях почти невозможно этого избежать.

5. Кэширование

Служба кэширования предоставляет простое хранилище данных в формате ключ-значение, которое позволяет хранить и искать информацию за время, близкое к линейному (O(1)). Обычно приложения используют функции кэширования, чтобы сохранять результаты дорогостоящих вычислений и воспользоваться ими позже из кэша, а не пересчитывать их еще раз. Приложение может кэшировать результаты запроса в базы данных, результаты обращения к внешним службам, HTML для заданного URL-адреса и многое другое. Вот некоторые примеры из реального мира:

  • Google кэширует результаты поиска для популярных поисковых запросов, таких как «собака» или «Тейлор Свифт», а не ищет их каждый раз заново;
  • Facebook кэширует большую часть данных, которые вы видите при входе в систему, например, списки постов или друзей. Подробнее, о технологии кэширования используемого в Facebook, можно почитать в этой статье на Medium;
  • Storyblocks кэширует HTML-страницы от React, результаты поиска и другое.

Двумя наиболее распространёнными технологиями кэширования являются Redis и Memcache.

6. Очереди задач

Большинству веб-приложений требуется выполнять некоторую работу, напрямую не связанную с ответом на запросы пользователей, асинхронно, в фоновом режиме. Например, Google должен сканировать и индексировать весь интернет, чтобы возвращать релевантные результаты поиска. Он не делает это при каждом запросе, а сканирует сеть асинхронно, обновляя поисковые индексы «по пути».

Выполнять асинхронную работу позволяют разные архитектуры, но наиболее распространённой является архитектура «очередь задач». Она состоит из двух компонентов: очереди «заданий», которые необходимо выполнить, и одного или нескольких рабочих серверов (часто называемых «работниками»), которые обрабатывают задания из очереди.

В очередях задач хранятся списки заданий, которые нужно выполнить асинхронно. Всякий раз, когда приложению нужно выполнить какую-то задачу, которая должна выполняться по расписанию или в соответствии с действием пользователя, оно добавляет её в очередь. Проще всего организованы очереди FIFO — «первым пришёл — первым ушёл», но большинство приложений в конечном итоге нуждаются в какой-то системе балансировки очередей.

Например, в Storyblocks очередь заданий используется для выполнения многих скрытых работ, необходимых для поддержания проекта: кодирование видео и фотографий, обработка CSV-файлов для тегов метаданных, агрегирование статистики пользователей, отправка писем с паролями для сброса и т. д. Со временем проект отказался от простой очереди FIFO в пользу приоритетной очереди, чтобы операции с фиксированным временем выполнения, такие как отправка писем о сбросе пароля, были завершены как можно скорее.

Сервера заданий выполняют задания из очереди. Они запрашивают её, чтобы определить, есть ли работа, и если есть, — приступают к выполнению.

7. Полнотекстовый поиск

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

В этом примере три заголовка документов преобразуются в инвертированные индексы, что облегчает поиск по определённому ключевому слову среди документов с этим ключевым словом в заголовке. Обратите внимание, что обычные слова, также называемые стоп-словами («in», «the», «with» и т. д.), обычно не включаются в инвертированный индекс.

В действительности можно выполнять полнотекстовый поиск непосредственно из некоторых баз данных (например, его поддерживает MySQL), но обычно принято запускать отдельную службу, которая вычисляет и сохраняет инвертированные индексы и предоставляет интерфейс для запросов. Самая популярная полнотекстовая поисковая платформа сегодня — Elasticsearch, хотя есть и другие варианты, такие как Sphinx или Apache Solr.

8. Службы

Когда приложение достигает определённого масштаба, как правило, появляются определённые «службы», созданные специально для запуска в виде отдельных приложений. Они не выставлены на всеобщее обозрение, но приложение и другие службы взаимодействуют с ними. Например, в Storyblocks имеются несколько операционных и плановых служб:

  • служба учётных записей хранит пользовательские данные для всех сайтов компании, что позволяет работать перекрёстно и создаёт более унифицированный опыт использования;
  • служба контента хранит метаданные для видео, аудио и изображений, а также предоставляет интерфейсы для загрузки содержимого и просмотра истории загрузок;
  • служба оплаты предоставляет интерфейс для оплаты кредитными картами;
  • HTML → PDF сервис предоставляет простой интерфейс, который принимает HTML-код и возвращает соответствующий PDF-документ.

9. Хранилище данных

Будет компания жить или нет во многом определяется тем, как она работает с данными. Почти каждое современное приложение, достигая определённого масштаба, переходит к одной и той же организации сбора, хранения и анализа данных. Работа с данными проходит в три основных этапа:

  1. Приложение отправляет данные в «firehose»-хранилище, которое обеспечивает потоковый интерфейс для поглощения и обработки данных. Как правило, это информация о действиях пользователей. Часто необработанные данные преобразуются или дополняются и передаются в другие «firehose»-хранилища. Наиболее распространённые технологии для этого процесса — AWS Kinesis и Kafka.
  2. Исходные, а также окончательно преобразованные и дополненные данные сохраняются в облачном хранилище. AWS Kinesis предлагает сервис под названием Firehose, который позволяет сохранять необработанные данные в облачном хранилище (S3), которое чрезвычайно просто в настройке.
  3. Преобразованные и дополненные данные загружаются в хранилище данных для анализа. Типичным примером является AWS Redshift, им пользуется большинство стартапов, хотя крупные компании предпочитают решения от Oracle или другие проприетарные технологии хранения. Если наборы данных достаточно велики, то для анализа может потребоваться технология NoSQL MapReduce, например, Hadoop.

На диаграмме не изображён ещё один шаг: загрузка данных из приложения и баз данных различных служб в хранилище. Например, Storyblocks каждую ночь загружает VideoBlocks, AudioBlocks, Storyblocks, службу учётных записей и базы данных портала разработчиков в Redshift. Это даёт аналитикам целостное представление, так как основные бизнес-данные и данные действий пользователей хранятся в одном и том же месте.

10. Облачное хранилище

«Облачное хранилище — простой и масштабируемый способ для хранения и обмена данными через интернет». Такое определение дано AWS. Его можно использовать для хранения и доступа к чему угодно, что можно хранить в локальной файловой системе, пользуясь преимуществами RESTful API через HTTP. Решение от Amazon S3 на сегодняшний день является самым популярным облачным хранилищем, и его широко используют в Storyblocks для хранения видео-, фото- и аудиофайлов, CSS- и JavaScript-файлов, данных действий пользователей и многого другого.

11. CDN

CDN расшифровывается как «Content Delivery System» (система доставки контента). Эта технология позволяет намного быстрее, чем с исходного сервера, отправлять статические HTML-, CSS-, JavaScript-файлы и изображения. Она распространяет контент из многих «конечных» серверов по всему миру, чтобы пользователи загружали различные ресурсы из них вместо исходного сервера. Например, на изображении ниже пользователь из Испании запрашивает веб-страницу с сайта, серверы которого находятся в Нью-Йорке, но статические ресурсы для этой страницы загружаются с «конечного» сервера CDN в Англии, предотвращая медленные кросс-атлантические HTTP-запросы.

Для более полного понимания принципов работы современного веба вы можете также ознакомиться с другими нашими материалами:

Быстрая разработка приложений (RAD) на сейчас

Выбор методик разработки приложений становится задачей № 1 в условиях стремительного роста рынка. Согласно исследованию Gartner на программное обеспечение для предприятий в 2015 году по миру было затрачено 310 млрд. долларов США. Разработка концепции RAD (Rap >стало основой для создания гибкой, адаптивной системы разработки приложений, которая была бы противовесом жёсткой «водопадной» модели.

RAD — модель быстрой разработки приложений, ключевыми для которой является скорость и удобство программирования.

Появление RAD

За появление быстрой разработки приложения стоит благодарить неидеальность модели семейства Waterfall при создании ПО. Всё дело в том, что изначально водопадная система разработки была основана на традиционной инженерной модели, используемой для проектирования и возведения зданий и мостов.

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

Первую версию RAD создал Барри Боэм в 1986 году, который назвал её «спиральная модель». Каждый виток спирали разбит на 4 сектора и соответствует разработке фрагмента или версии ПО. С каждым новым витком идёт углубление и уточнение целей, спецификаций проекта. В результате появляется возможность выбрать обоснованный вариант.

Использовав идеи Барри, британец Джеймс Мартин разработал свою систему RAD на протяжении работы в 80-ых в IBM, и окончательно сформулировал их в книге «Быстрая разработка приложений» в 1991 г.

Правда не обошлось без путаницы в значении слова «RAD» даже среди IT-специалистов. Ведь речь шла о двух концепциях: RAD как эффективной альтернативе Waterfall и RAD как специфическому методу, разработанному Мартином. Последний был адаптирован к бизнес-системам с интенсивным использованием UI.

В дальнейшем идеи были развиты и улучшены пионерами RAD Джеймсом Керром и Ричардом Хантером в совместной книге «Внутри RAD», которая описывала путешествие проектного менеджера в процессе изучения и внедрения методологии быстрой разработки приложений в реальной жизни для реального проекта.

Эти и многие другие авторы смогли популяризировать новую методику как альтернативу традиционным системам подходов к жизненному циклу проекта.

Спиральная модель — процесс разработки ПО, комбинирующий проектирование и постадийное прототипирование.

Основы (принципы) быстрой разработки приложений

Принципы RAD сосредоточены на том, чтобы обеспечить основные преимущества методики быстрой разработки приложений:

  • повышенная скорость разработки
  • низкая стоимость
  • высокое качество.

С последним пунктом возникает больше всего проблем, потому что разработчик и заказчик видят предмет разработки по-разному.

Для устранения этой и других проблем Джеймсом Мартином и его последователями были выделены следующие принципы RAD:

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

Принципы RAD используются не только при реализации, а и распространяются на все этапы жизненного цикла, в частности, на стадию обследования организации, построения требований, анализ и дизайн.

Жизненный цикл программного обеспечения по RAD

В процессе RAD приложение проходит четыре фазы.

Фаза анализа и планирования требований

Определяются требования, функции приложения и их приоритетность, описываются информационные потребности. Фаза выполняется преимущественно пользователями при участии разработчиков. На этой стадии также обозначаются масштаб проекта, временные и финансовые рамки, платформы для запуска ПО.

Например, компании «Beverly Flowers» нужно приложение для онлайн-заказа цветов на дом. На создание отводится 50 дней, бюджет — 3 000 долларов.

Фаза проектирования

Часть пользователей участвует в техническом проектировании системы под руководством разработчиков. Группы или подгруппы RAD на этой фазе обычно используют комбинацию техник с овместной разработки приложений (JAD) и CASE-инструменты для воплощения потребностей пользователей в рабочих моделях.

JAD (Joint Application Development) — концепция совместной разработки приложений, в рамках которой происходит тесное взаимодействие между заказчиком и исполнителями для максимально эффективного решения вопросов, касающихся разрабатываемого ПО.
Case — комплект инструментов и методов для проектирования ПО для обеспечения высокого качества программ, отсутствия ошибок и простоты в обслуживании программных продуктов.

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

В результате фазы создаются:

  • общая информационная модель приложения
  • функциональные модели системы и подсистем
  • рабочие прототипы экранов, отчётов и диалогов.

Если в предыдущих моделях средства разработки прототипов не соответствовали реальным приложениям, и они в дальнейшем не использовались, то в RAD каждый прототип становится частью будущей системы.

В качестве платформы разработки выбрали freeware SpringToolSuite, для которой доступно большое количество сэмплов — прописанных кусочков кода.
В роли сервера — Apache Tomcat 6.0.

Фаза построения

На этой стадии происходит непосредственно быстрая разработка на основе полученных по предыдущим фазам результатов. При этом пользователи продолжают участвовать в развитии системы, предлагая изменения и улучшения приложения. Тестирование приложения тоже происходит во время разработки.

Фаза внедрения

Охватывает обучение пользователей, тестирование и замену старой системы на новую. Подготовка к этой фазе начинается с этапа проектирования.

Записав сообщение о возможности заказа через специальное приложение и разместив информационные стенды в точках продажи, за 2 недели удалось переключить часть покупателей на новый канал сбыта.

При этом доля заказов по телефону пропорционально снизилась, а значит удалось сократить штат менеджеров по работе с клиентами.

Стоит отметить, что в отличии от Waterfall, жизненный цикл проекта по методологии RAD не является жёстким. Зависимо от стартовых условий, количество фаз может уменьшаться, как и их наполнение.

Плюсы и минусы быстрой разработки приложений в вашей компании

Использовать Rapid Application Development или нет, во многом зависит от стартовых условий, требований заказчика и вида приложения.

К однозначным преимуществам RAD относятся:

  1. высокое качество. Взаимодействие пользователей с прототипами повышает функциональность проектов, выполненных в рамках быстрой разработки приложений. Такое программное обеспечение может больше отвечать потребностям заказчика (конечного пользователя), чем при использовании методик Agile/Waterfall.
  2. контроль рисков — несмотря на то, что львиная частьматериалов о RAD фокусируется на скорости и вовлечении пользователей как ключевым особенностям модели, нельзя исключать третье важное преимуществоснижение рисков. Интересно, но Боэм, создавший первую версию RAD, охарактеризовал спиральную модель как основанную на риске.
    Использование rapid application development позволяет уже на ранних стадиях сосредоточиться на главных факторах риска и приспособиться к ним.
  3. за единицу времени выполняется больше проектов в рамках бюджета — так как RAD подразумевает инкрементную модель разработки, шансы на критические ошибки, которые часто случаются в больших проектах по системе Waterfall, снижены.
    Если в проектах по водопадной системе реализация проекта была возможна после шести и более месяцев анализа и разработки, то в RAD вся необходима информация открывается раньше, во время самого процесса создания приложения.
Инкрементная модель разработки — формат разработки программного обеспечения, которая предусматривает деление продукта на относительно независимые компоненты. Последние разрабатываются и вводятся в эксплуатацию по отдельности.

Не обошлось и без недостатков.

К минусам rapid application development можно отнести:

  1. риск «новизны» — для большинства IT-компаний RAD было новинкой, требующей переосмысления привычных методик работы. Сопротивление новому, необходимость изучения с нуля инструментов и техник приводят к ошибкам во время первых внедрений rapid application development.
  2. если пользователи не могут постоянно брать участие в процессе разработки на протяжении всего жизненного цикла, это может негативно повлиять на конечный продукт — особенностью RAD является увеличенное взаимодействие пользователей и разработчиков в отличии от моделей Waterfall, в которых роль пользователей сводится к определению требований. Далее разработчики сами создают систему.
  3. уменьшенный контроль — гибкость, адаптивность процесса как одно из преимуществ RAD в идеале означает возможность быстро адаптироваться как к проблемам, так и возможностям.
    К сожалению, придётся отдать предпочтение чему-то одному — гибкости или контролю. В последнем случае методика быстрой разработки приложений не будет жизнеспособной.
  4. скудный дизайн — фокусирование на прототипах в некоторых случаях приводит к методике «взлом и тестирование», по которой разработчики постоянно вносят мелкие изменения в отдельные элементы и игнорируют проблемы системной архитектуры.
  5. отсутствие масштабируемости — преимущественно RAD используется маленькими и средними проектными командами. Недостатки методологии rapid application development особенно ярко проявляются при использовании быстрой разработки приложений в работе над крупными проектами.

Методология RAD подойдет вашему проекту, если:

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

Методология rapid application development не подойдёт вашему проекту, если:

  • для него важно качество и контроль
  • идет речь о создании крупномасштабного проекта — предполагаемое максимальное время разработки приложения составляет 60-90 дней, а при написании сотни тысяч строк программного кода соблюсти такое ограничение практически невозможно
  • критически важным для реализации является высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам
  • от приложения в определенной степени зависит безопасность людей.

Вердикт

Концепция быстрой разработки приложений (сокращённо RAD от Rapid Application Development) — разновидность инкреметных моделей разработки ПО.

Ключевые параметры, которыми оперирует RAD —
скорость и удобство программирования.

Методология станет отличным выбором для реализации небольших проектов с ограниченным бюджетом, разработать которые нужно в сжатые сроки. Для масштабных же систем, с высокими требованиями по контролю и планированию лучше выбрать другие модели разработки программного обеспечения.

Разработка веб-приложений на основе моделей высокого уровня абстракции Текст научной статьи по специальности « Автоматика. Вычислительная техника»

Аннотация научной статьи по автоматике и вычислительной технике, автор научной работы — Филичев Евгений Валентинович, Устинов Сергей Михайлович

Приведены проблемы наиболее актуальных подходов к разработке ПО с помощью механизмов моделирования . Предложена методика автоматизированной разработки веб-приложений , базирующаяся на использовании моделей высокого уровня абстракцииThis article briefly describes problems of most actual technologies of software development based on modeling mechanisms. The result of this analysis is new methodic of automated web application development using high-level abstraction models

Похожие темы научных работ по автоматике и вычислительной технике , автор научной работы — Филичев Евгений Валентинович, Устинов Сергей Михайлович,

Текст научной работы на тему «Разработка веб-приложений на основе моделей высокого уровня абстракции»

Матрица оптимальной программы обслуживания

Величина интервала ТО Номер средства комплекса жизнеобеспечения здания

Средство 1 Средство 2 Средство 3 Средство 4 Средство 5

ской эффективности КСЖ имеют значения: C = 1938,64 усл. ед.; C = -489356,17 усл. ед.

max ‘ J ^ ‘ min ‘ J ^

Сравнительные результаты расчетов для всех трех последовательно решенных в соответствии с описанным алгоритмом задач в относительной и натуральных шкалах измерений двухкритериальной процедуры синтеза оптимальной программы обслуживания КСЖ приведены в табл. 2.

Оптимальная матрица 53, определяющая программу обслуживания средств КСЖ, представлена в табл. 3.

Таким образом, в статье приведено решение задачи синтеза программы обслуживания по фактическому техническому состоянию средств КСЖ зданий, оптимальной по двум критериям. В качестве исходных данных для моделирования расчетов использованы показатели, которые нетрудно получить при эксплуатации объектов строительства. Это существенно повышает прикладной характер полученных выводов. Результаты решения задачи могут применяться в структурах, выполняющих функции по организации и осуществлению технической эксплуатации зданий и сооружений.

1. Надежность в технике. Термины и определения [Текст]/ГОСТ 27.002-89.

2. Экономика строительства [Текст]/Под ред. И.С. Степанова. -М.: Юрайт, 1997.-С. 416.

3. Зеленцов, В.А. Надежность, живучесть и техническое обслуживание сетей связи [Текст]/В.А. Зеленцов, А.А. Гагин. -Л.: МО, 1991.-С. 169.

4. Рогонский, В.А. Эксплуатационная надежность зданий и сооружений [Текст]/В.А. Рогонский, А.И.

Костриц, В.Ф. Шеряков [и др.]. -СПб.: ОАО Изд-во «Стройиздат СПб», 2004.- С. 272.

5. Герцбах, И.В. Модели профилактики (Теоретические основы планирования профилактических работ) [Текст]/ И.В. Герцбах. -М.: Сов. радио, 1969. -С. 216.

6. Менеджмент риска. Метод структурной схемы надежности [Текст]/ГОСТ Р 51901.14-2005.

7. Юдин, Д.Б. Вычислительные методы теории принятия решений [Текст] / Д.Б. Юдин. -М.: Наука, 1989. -320 с.

УДК: 004.4’244, 004.4’236

Е.В. Филичев, С.М. Устинов РАЗРАБОТКА ВЕБ-ПРИЛОжЕНИй НА ОСНОВЕ МОДЕЛЕй

высокого уровня абстракции

Веб-приложения занимают большую часть рынка программного обеспечения (ПО). С развитием веб-технологий функции, раньше реализуемые лишь с использованием ПО,

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

бочего места и не нуждаются в установке. Многие организации полностью отказываются от «толстых» клиентов, переходя на веб-интерфейсы, что позволяет значительно сократить расходы на сопровождение программного обеспечения и повысить эффективность работы. Задача администрирования целого парка компьютеров с установленным ПО сводится к администрированию одного веб-сервера со всеми приложениями. Естественным образом повышаются требования к самим веб-приложениям, возрастает их сложность и, как следствие, сложность их разработки. Вместе с тем, актуальность приобретает задача модификации веб-приложения, наращивания функциональных возможностей, изменения бизнес-логики для того, чтобы удовлетворять постоянно изменяющимся требованиям.

Один из наиболее эффективных способов снижения трудоемкости разработки приложений вообще и веб-приложений в частности — использование моделей высокого уровня абстракции и механизмов генерации программного кода приложения по этим моделям. Следует отметить, что данная задача является нетривиальной и до сих пор нет ее универсального решения. Существует несколько подходов для упрощения этой задачи, среди которых можно выделить использование метамоделирования как наиболее перспективный. В данной статье предлагается один из способов использования моделей высокого уровня абстракции для разработки веб-приложений.

Развитие техник моделирования

Первые попытки сократить дистанцию между моделью и кодом целевой системы были предприняты еще в 1970-х гг., после формулирования П. Ченом в 1976 г. [1] подхода сущностей-отношений. Несмотря на некоторые недостатки в выразительных возможностях, подход можно признать успешным, т. к. результатом его появления стало последующее создание инструментальных систем, способных генерировать программный код по моделям, среди которых можно отметить RISE, ErWin, DeZign и др. Подход сущностей отношений показал, что при использовании достаточно формализованной модели задача генерации программного кода по ней является выполнимой.

Затем последовала техника IDEFlx, обобщившая опыт, полученный при разработке таких техник моделирования, как IDEF1, сущностей-

отношений, реляционного подхода Э. Кодда, модели Объектов-Ролей Д. Найсена [2]. В IDEF1X была введена поддержка моделирования логических типов данных с использованием классификационной структуры или конструкции обобщения/специализации, отношения категоризации, представляющих собой взаимно исключающие подмножества общей сущности, а также понятие ключа. Благодаря всему этому, IDEF1X на момент появления являлась самой передовой техникой для определения логического дизайна баз данных и приложений и физического дизайна реализации базы данных, кроме того, она получила поддержку в различных программных продуктах (ER/Studio, ERwin и т. д.). Поддержка выражалась в возможности генерировать скрипты DDL для создания базы данных по диаграммам IDEF1X. Если бы уровень абстракции модели был выше, то, возможно, такого успеха техника IDEF1X не сумела бы достичь.

Следующим важным этапом развития моделирования можно считать создание группы объектного моделирования OMG и разработку универсального языка моделирования UML. UML объединил в себе идеи, использованные при разработке техник OOSE (Object-Oriented Software Engineering) Буча и Якобсона [3], техники Д. Рам-бо [4], Шлера и Меллора [5]. Результатом сотрудничества Г. Буча из корпорации Rational Software, И. Якобсона из Objectory и Д. Рамбо из General Electric в 1997 г. стал UML 1.0, хорошо определенный, выразительный, мощный, применимый в широком спектре проблем и областей язык моделирования. Он был предложен для стандартизации группе Объектного Моделирования (OMG) в ответ на ее запрос о едином стандартном языке моделирования. Вскоре был очерчен круг семантических задач для формализации новой спецификации UML с целью его интеграции с другими решениями для стандартизации.

В актуальный стандарт UML версии 2.3 помимо базовых диаграмм входят важнейшие механизмы расширения, такие, как стереотипы и ограничения. В рамках механизма ограничений создан целый язык, язык объектных ограничений (OCL) [6], а стереотипы расширяют базовый словарь UML, позволяя определять новые элементы, наследованные от существующих, и, таким образом, создавать метамодель для нового языка -подмножества UML, который помог бы разрабатывать более специфичные модели. Механизмы

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

Еще одним подходом, внесшим существенный вклад в решение задачи получения полного кода по модели, стал предложенный Ю-П. Толва-неном и С. Келли в 2000 г. подход разработки приложений, основанный на доменно-специфичном моделировании. К 2008 г. этот подход сформировался в законченном виде и подробно описан в работе [7]. В этом подходе предлагается понизить уровень абстракции до уровня конкретной прикладной области, что существенно снижает затраты на реализацию генератора кода целевого приложения за счет оперирования менее общими по сравнению с разработкой, управляемой моделью, понятиями.

Существующие подходы к разработке ПО на основе моделей

Таким образом, к настоящему времени существует несколько проработанных вариантов использования моделей как основных артефактов разработки, т. е. подразумевается, что, разработав модель или набор моделей, мы можем получить код готовой прикладной системы автоматически. Схематически это представлено на рис. 1.

Как видно из рисунка, никаких «ручных» действий над кодом системы проводить нет необходимости, более того, ручные действия сводят на нет все преимущества подобных подходов.

Для разработки ПО главным становится правильное определение модели. Остальное — задача программного обработчика или набора обработчиков. Различие в подходах заключается в том, как именно необходимо разрабатывать этот на-

Набор Автоматизированный^ Готовый код

моделей переход системы

Рис. 1. Модели как основной артефакт разработки

бор моделей, и какими характеристиками модели должны обладать.

Среди множества характеристик моделей можно выделить две основных: язык моделирования и уровень абстракции.

На сегодняшний день группой объектного моделирования OMG в качестве наиболее перспективного подхода выбран подход, основанный на архитектуре, управляемой моделью: MDA (Model Driven Architecture). В данном подходе предлагается строить несколько уровней моделей для того, чтобы повысить итоговый уровень абстракции. Вторым по распространенности является подход Келли и Толванена [7] DSM (Domain Specific Modeling), предлагающий для повышения уровня абстракции сужать область применения языка моделирования, делая его специфичным для конкретной прикладной области. Рассмотрим оба эти подхода более подробно.

Подход MDA. В подходе MDA предлагаемая схема разработки принимает вид, показанный на рис. 2.

На рисунке представлены отношения между моделями в MDA. Первичной моделью является модель PIM (Platform independent model), не зависящая от платформы. По модели PIM с помощью некоторых механизмов и характеристик платформы автоматически создаются специфичные модели PSM (Platform specific model), которые имеют жесткую привязку к конкретной платформе. В качестве языков для описания моделей предлагается использовать UML и его профили, также указывается возможность использования языка OCL для повышения детализации моделей и обеспечения возможности осуществить автоматизированный переход, по крайней мере, в теории.

Применительно к веб-технологиям модель PIM оперирует такими понятиями, как экранное представление, статические компоненты экранного представления, динамические компоненты экранного представления, пользовательский ввод и т. д. [8]. Основываясь на информации из PIM, необходимо описать правила построения веб-приложений под конкретную платформу. Если это платформа ASP.NET, то понятия, которыми будет оперировать PSM, это ASP.NET страница, ASP. NET элемент управления и т. д. Для поддержки функциональности на минимальном уровне потребуется описать большое количество вариантов преобразований, что сводит преимущества MDA на нет. Проанализировав подход MDA, можно

Рис. 2. Процесс разработки MDA

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

Подход DSM. Подход DSM опирается на похожие предпосылки, однако в нем для повышения уровня абстракции предлагается использовать специальные языки для каждой конкретной прикладной области. Сужение области применения позволяет плотнее увязать язык моделирования с реальными проблемами и снижает сложность на-

писания генератора кода, решающего задачу получения полного кода ПО по модели.

На рис. 3 представлена схема структуры DSM проекта и те ее части, которые видимы разработчикам. Данная схема показывает, что с точки зрения разработчика ПО процесс упрощается, по сравнению с MDA. Из двух уровней моделей и двух автоматизированных переходов, платформенно-независимого и платформенно-зависимого, остается лишь один, платформенно-зависимый. Подобное сокращение уровней значительно снижает затраты на разработку модулей генерации конечного кода. Структура генератора, в свою очередь, обычно скрыта от аналитиков, и ее можно сравнить с компилятором. Продолжая аналогию, преобразование моделей в исполняемый код однозначное и исключает модификацию

Рис. 3. Архитектура DSM проекта

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

Формулирование требований к методике разработки веб-приложений

Таким образом, и у подхода MDA, и у подхода DSM есть серьезные недостатки, снижающие эффективность их использования при разработке веб-приложений. В данной статье предлагается методика разработки веб-приложений, учитывающая опыт разработанных техник моделирования. В качестве требований к методике выбраны:

1) высокий уровень абстракции, позволяющий избежать написания кода приложения вручную;

2) гибкость и функциональность, не ограниченная конкретной прикладной областью;

3) эффективность разработки веб-приложений.

Для удовлетворения этим требованиям методика основана на следующих положениях.

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

В качестве платформы необходимо использовать технологию разработки определенного типа приложений в целом, т. к. это позволит избежать узкой направленности готового решения.

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

Переходы между уровнями должны выполняться в автоматическом режиме. Введение ручного анализа кода и его модификации негативно сказывается на эффективности конечного решения. Подобный подход допустимо использовать

для разработки не только веб-приложений, но и приложений вообще. Далее эти положения будут рассмотрены более подробно.

Определение оптимального количества уровней моделирования

Как уже было отмечено, эффективнее всего организовывать многоуровневый процесс разработки. Обобщая опыт подходов MDA и DSM, на нижнем уровне необходимо располагать исполняемый код готового приложения, в то время как на верхнем уровне должны находиться модели высокого уровня абстракции. Для того чтобы снять ограничения узкой направленности подхода, в качестве промежуточной платформы необходимо выбирать непосредственно технологию разработки приложений, т. е. инструментальную систему, включающую в себя языковую поддержку и поддержку некоторой платформы. В данной статье рассматриваются веб-приложения, поэтому платформой разработки выступает технология ASP.NET. Промежуточный уровень является необходимым условием применения данного подхода на практике, т. к. в его отсутствие задача реализации перехода от моделей к готовому коду, минуя поддержку платформы, крайне трудоемка, и на сегодняшний день не существует инструментальных систем — примеров ее успешного решения. При необходимости, промежуточный уровень можно разделять на подуровни, с целью дальнейшего упрощения переходов от моделей к готовому приложению. Однако для веб-приложений и технологии ASP.NET это разделение не является целесообразным, т. к. трудоемкость реализации переходов в случае нескольких промежуточных уровней превышает трудоемкость реализации переходов для одного промежуточного уровня. Таким образом, эффективнее всего использовать трехуровневую схему разработки, которая схематично представлена на рис. 4.

В качестве моделей высокого уровня абстракции выступают модели веб-приложения, созданные с помощью языка моделирования высокого уровня, специфичного для платформы, но независимого от прикладной области. С помощью автоматического преобразования по такой модели создаются модели, специфичные для платформенного генератора и оперирующие понятиями, реализованными в коде на языке высокого уровня. Следующее автоматическое преобразование позволяет получить готовый исполняемый код веб-приложения ASP.NET.

высокого преобразование 1 опирающиеся преобразование 2 Готовый

уровня на платформу —

Рис. 4. Схема комбинированного подхода разработки веб-приложений

Описание платформы разработки

Платформа разработки, наряду с автоматизированными переходами, является ключевой частью предлагаемой методики. Она должна сочетать в себе интеграцию с технологией разработки, в нашем случае, ASP.NET, позволять описывать приложения с помощью программных моделей на языке программирования высокого уровня, такого, как С#, а также допускать возможность создания этих программных моделей с помощью некоторых внешних инструментов. Всем этим требованиям удовлетворяет инструментальная система генерации сайтов ASP.NET, разработанная в рамках сотрудничества ООО «Деловые Консультации» и ООО «Брэйн Системс». Разработанная платформа является многоуровневой, и содержит в себе несколько модулей и наборов объектов, реализующих соответствующие функциональные возможности. Еще одним преимуществом данной платформы является поддержка корпоративного ядра «СКАУТ», разработанного ООО «Деловые Консультации» и позволяющего описывать бизнес-логику приложений в привязке к базе данных. Наборы объектов платформы можно разделить на следующие группы.

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

Набор объектов уровня бизнес-логики; эти объекты непосредственно привязаны к ядру «СКАУТ» и реализуют его функции по созданию объектов и операциям с ними.

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

Все эти объекты располагаются на соответствующих уровнях программной модели. Про-

граммная модель основана на языке высокого уровня и состоит из классов C#.

Помимо перечисленных выше объектов в платформу входят:

модуль генерации кода; набор шаблонов для генерации кода; модули, отвечающие за хранение информации и получение ее из выбранного хранилища (поддерживается несколько вариантов хранения созданных объектов).

Данную платформу предлагается использовать как прикладную область — домен в терминах подхода DSM. Это позволяет одновременно повысить уровень абстракции с веб-приложения под конкретную прикладную область до веб-приложения ASP.NET, сохранив невысокие расходы на разработку модулей генерации кода.

Интеграция с технологией разработки ASP.NET заключается в том, что по программной модели веб-приложения в терминах платформы строится готовое веб-приложение ASP.NET, со страницами aspx, библиотеками, содержащими реализацию бизнес-функций и связи с базой данных, а также с функциями ядра «СКАУТ», которые позволяют более гибко реализовывать бизнес-логику веб-приложения.

Платформа опирается на технологии Micro-soft.NET, поэтому ее программная модель допускает создание объектов с помощью скриптов Windows PowerShell, что и было использовано при реализации перехода от моделей высокого уровня абстракции к программной модели в терминах платформы.

Модели верхнего уровня и реализация автоматических преобразований

Данный подход предлагается применять в среде разработки MS Visual Studio 2010 Ultimate, поэтому естественным выглядит решение использовать функциональные возможности моделирования, предоставляемые пакетом дополнения Visualization and Modeling Feature Pack. Это позволяет получить поддержку языка моделирования высокого уровня, такого, как UML, вместе с мощным механизмом его расширения в

виде профилей, а также доступ на программном уровне к разработанным моделям, что помогает анализировать эти модели и создает основу для реализации переходов в платформенные модели. Для разработки моделей верхнего уровня используются возможности метамоделирования, предоставляемые Microsoft Visualization & Modeling SDK, в частности, включающие в себя механизмы стереотипов UML.

Для автоматического преобразования 1 предлагается использовать шаблоны t4 для генерации текста. Таким образом, сначала в терминах разработанного профиля UML создаются модели высокого уровня абстракции, не привязанные к конкретной прикладной области, но содержащие связь с платформой разработки. Создание моделей осуществляется в рамках проекта моделирования в Microsoft Visual Studio 2010. Созданные в этом проекте диаграммы затем анализируются в рамках другого проекта Visual Studio, включающего в себя поддержку шаблонов генерации текста t4 templates и ссылку на библиотеку Microsoft. VisualStudio.ArchitectureTools.Extensibility.dll. Реализация преобразования 1 осуществляется с помощью названных выше шаблонов путем анализа разработанных в проекте моделирования диаграмм и написания на их основе скриптов PowerShell, содержащих необходимые команды для воспроизведения модели веб-приложения в программной модели платформы генерации сайтов. Функциональность получения по моделям платформы готового кода проекта реализована в механизмах платформы. Таким образом, предлагаемая методика позволяет разрабатывать веб-проекты для любой прикладной области, используя в качестве первичного артефакта разработки модели высокого уровня абстракции. С помощью реализованных автоматических преобразований возможно получение полного кода веб-приложения по таким моделям.

Предложенную в данной статье методику можно формализовать как последовательность


1. Определение функциональных требований к веб-приложению.

2. Определение необходимых уровней расположения бизнес-логики приложения. Некоторые бизнес-функции удобнее реализовывать серверными компонентами ASP.NET, для других эффективнее использовать механизмы, предоставляемые базой данных.

3. В случае, если существующих компонентов платформы не хватает для реализации требуемых бизнес-функций, разработка новых компонентов, реализующих требуемые функции.

4. Доработка профиля UML, включение в него появившихся на третьем этапе компонентов.

5. Построение наглядных моделей веб-приложения в профиле UML, согласование с заказчиком.

6. Автоматизированные переходы от построенных моделей в готовый к публикации на сервере код веб-приложения.

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

Следует отметить, что предложенный подход был опробован и показал хорошие практические результаты в следующих программных продуктах: «Скаут-Заявки для Сбербанка»; «Скаут-Навигатор»; «Телемикс».

Для выполнения поставленных в ТЗ задач по каждому из этих проектов разработаны спецификации необходимых пользовательских элементов управления, произведена разработка и добавление этих элементов в библиотеки платформы, описаны необходимые классы для языка моделирования и механизмы переходов от моделей, содержащих новые элементы, в готовый серверный код.

1. Chen, P. The Entity-Relationship Approach to Logical Data Base Design [Текст] / P. Chen. -Wellesley, MA: Q.E.D. Information Sciences, Inc. -1977.

2. Nijssen, G.M. Current Issues in Conceptual Schema Concepts [Текст] / G.M. Nijssen (ed.) // Proc. 1977 IFIP Working Conf. on Modelling in Data Base Manage-

ment Systems, Nice, France. -Amsterdam: North-Holland Publishing, 1977. -P. 31-66.

3. Jacobson, I. Object Oriented Software Engineering: A Use Case Driven Approach [Текст]/ I. Jacobson; Revised ed. -Addison-Wesley Professional, 1992.

4. Rumbaugh, J. Object-Oriented Modeling and De-

sign. [Текст]/ J. Rumbaugh. -NJ.:-Prentice Hall, Engle-wood Cliffs, 1991.

5. Shlaer, S. Object-Oriented Systems Analysis: Modeling The Real World in Data [Текст] / S. Shlaer, S.J. Mel-lor. -N.J.:Prentice Hall, Englewood Cliffs, 1988.

6. Warmer, J. Object Constraint Language, The Getting Your Models Ready for MDA [Текст] / J. Warmer,

A. Kleppe; 2 ed. -Addison Wesley, 2003. -240 c.

7. Kelly, S. Domain Specific Modeling. Enabling Full Code Generation [Текст] / S. Kelly, J-P. Tolvanen. -Wiley, 2008. -427 c.

8. Conallen, J. Building Web Applications with UML [Текст] / J. Connalen; 2 ed. -Addison Wesley, 2002. — 496 c.

А.М. Бородин, С.В. Поршнев

АНАЛИТИЧЕСКИЕ СПОСОБы ОцЕНКИ ЭФФЕКТИВНОСТИ ПРИМЕНЕНИЯ пространственных ИНДЕКСОВ В OLAP-СИСТЕМАХ

В работах [1, 2] показано, что выполнение агрегирующих запросов по наборам аналитических данных в OLAP-системах при использовании пространственных индексов оказывается весьма эффективным, в первую очередь, с точки зрения скорости выполнения запросов. Помимо этого оказалось, что выбранный подход позволяет при изменении набора данных ограничиться только частичным перестроением индекса. В то же время оценки эффективности выполнения агрегирующих запросов по аналитическим данным, приведенные в [1, 2], были получены экспериментально, поэтому зависят от конкретных наборов аналитических данных. В этой ситуации для обоснования возможности экстраполяции данных оценок на аналитические данные OLAP-систем произвольной структуры разработка аналитических методов оценки эффективности пространственных индексов является актуальной.

В статье изложено решение задачи создания аналитических способов оценки эффективности метода индексирования данных, разработанного в [1, 2], в т. ч. R*-дерева, Ra*-дерева и KDB-дерева.

Способ оценки ожидаемой эффективности R-дерева

R-дерево предназначено для индексирования набора пространственных объектов. При этом основной характеристикой объекта является многомерный параллелепипед (параллелотоп) минимально возможного объема, описанный вокруг объекта, ребра которого параллельны осям

координат (minimum bounding rectangle — MBR)*. MBR-параллелотоп описывается заданием координат его вершин.

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

где i — номер измерения куба; к — номер отсче-

та в /-м измерении; х1иш

координат /-го вектора (измерения); х^х — максимальное значение координат /-го вектора (измерения). Использование единичного OLAP-куба, как очевидно, снимает проблему отличий в единицах измерения величин, расположенных в соответствующих измерениях исходного OLAP-куба.

Для получения аналитической оценки эффективности R-дерева докажем несколько промежуточных утверждений.

Назовем отрезок 5 = [50,равномерно распределенным, если 50,е [0,1], 50 i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

Лемма 1. Вероятность р пересечения отрез- за-

ков 5 = [50,51]ид = [д0,таких, что 5 данные числа, 5 и д — равномерно распределенные отрезки, и |д| + 5

Семь принципов создания современных веб-приложений

Эта статья основана на моей презентации с конференции BrazilJS в августе 2014 года. Она базируется на идеях, о которых я писал в блоге недавно, в основном, в связи с UX и производительностью.

Я хочу представить 7 действенных принципов для веб-сайтов, которые хотят применить JavaScript для управления UI. Эти принципы являются результатом моей работы как веб-дизайнера, но также как давнего пользователя WWW.

JavaScript бесспорно стал незаменимым инструментом для разработчиков фронтенда. Сейчас сфера его применения расширяется на другие области, такие как серверы и микроконтроллеры. Этот язык программирования выбрали престижные университеты, чтобы обучать студентов основам информатики.

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

  • Должен ли JavaScript использоваться как замена функциям браузера: история, навигация, рендеринг?
  • Умирает ли бэкенд? Нужно ли вообще рендерить HTML?
  • Правда ли, что будущее за приложениями на одной странице (Single Page Applications, SPA)?
  • Должен ли JS генерировать страницы на веб-сайте и рендерить страницы в веб-приложениях?
  • Нужно ли использовать техники вроде PJAX или TurboLinks?
  • Каково точное отличие между веб-сайтом и веб-приложением? Должно ли остаться что-то одно?

Далее последуют мои попытки ответить на эти вопросы. Я попытался исследовать, как использовать JavaScript с точки зрения пользователя (UX). В частности, уделил особое внимание идее минимизации времени, которое требуется пользователю для получения интересующих его данных. Начиная с основ сетевых технологий и заканчивая предсказанием будущего поведения юзера.

1. Рендеринг страниц на сервере

tl;DR: Рендеринг на сервере осуществляется не ради SEO, а для производительности. Принимайте в расчёт дополнительные запросы для получения скриптов, стилей и последующие запросы к API. В будущем, принимайте в расчёт использование метода HTTP 2.0 Push.

Прежде всего, я вынужден обратить внимание на общепринятую ошибку разделять «приложения с рендерингом на сервере» и «одностраничные приложения». Если мы хотим добиться наилучшего восприятия с точки зрения пользователя, то не должны ограничивать себя такими рамками и отказываться от одной альтернативы в пользу другой.

Причины вполне очевидны. Страницы передаются по интернету, у которого есть физические ограничения, что незабвенно проиллюстрировал Стюарт Чешир в знаменитом эссе «Это latency, дурачок»:

Расстояние между Стэнфордом и Бостоном 4320 км.
Скорость света в вакууме 300 x 10^6 м/с.
Скорость света в оптоволокне составляет примерно 66% скорости света в вакууме.
Скорость света в оптоволокне 300 x 10^6 м/c * 0,66 = 200 x 10^6 м/c.
Односторонняя задержка при передаче в Бостон 4320 км / 200 x 10^6 м/c = 21,6 мc.
Задержка при передаче туда и обратно 43,2 мc.
Пинг из Стэнфорда в Бостон в интернете современного образца около 85 мс (…)
Итак, современное оборудование интернета передаёт сигнал со скоростью 0,5 от скорости света.

Указанный результат 85 мс можно улучшить (и уже сейчас он чуть лучше), но важно понять, что существует физическое ограничение на задержку при передаче информации через интернет, как бы не увеличивалась полоса пропускания на компьютерах пользователей.

Это особенно важно в связи с ростом популярности JavaScript-приложений, которые обычно содержат только разметку

Как на базе веб-сайта разработать мобильное приложение

Работающий стартап, это тот, который построенный на принципах стратегии MVP (Minimum Viable Product). Такой подход позволяет вам проверить ваш продукт перед запуском его в широкие массы.

После запуска MVP изучаете реакцию вашей аудитории и рынка на него, меряете покупательских спрос. Как результат, вы получаете первые плоды от продаж, первый пользовательский опыт, первый отзыв о продукте / сервисе. У вас вырисовывается полное представление о проекте, и о том, что с ним дальше делать: в каком направлении развиваться и развиваться ли вообще.

Ниже мы детально рассмотрим как механизм MVP может помочь в сборе информации и превращении ее в ценностное предложение. И помните, что как стратегический предприниматель, лучше выбирать такой способ разработки продукта, который покажет результаты в первые дни работы. Пссс… правильный ответ — веб-приложение;)

Взывая к принципам “Бережливого стартапа” (Lean startup)

Запуская технический продукт, который не имеет никакой взаимосвязи с камерой или микрофоном смартфона, подумайте о том, чтобы начать все-таки с веб-приложения. Функционально браузеры быстрее развиваются чем мобильные приложения, и соответственно количество пользователей у них больше. При создании приложения лучше задействовать принципы MVP. Также не забывайте, что оно должно запускаться в Chrome или Safari.

Приложения подобные Uber или Instagram напрямую зависят от функциональности девайса (геолокация), но есть много других продуктов, которые не нуждаются в взаимодействии с API устройства. А благодаря адаптивному веб-дизайну такие приложения получают межплатформенную доступность и корректно отображаются на экранах разного разрешения.

Существует десятки технических методов разработки мобильных приложений. Различия между ними сводятся к скорости написания приложения, стоимости, и к качеству конечного продукта. Понимание различий между ними, пожалуй, сложная задача.

Итак, давайте рассмотрим четыре популярные технологии создания мобильных приложений, а также их основные различия. Это поможет определить практичный способ верификации бизнес-идеи и облегчит конструирование будущего продукта. Возможно, веб-приложение (а не нативное мобильное приложение) поможет сократить расстояние между MVP и запуском полноценного проекта.

Прогрессивное веб-приложение (Progressive Web Apps)

Эта относительно новая технология, разработанная Google. Она позволяет мобильным устройствам добавлять веб-сайт или веб-приложение на домашний экран смартфона и дальше использовать его в оффлайн-режиме.

Для превращения веб-приложения в прогрессивное веб-приложение, вам нужно добавить в него значок для главного экрана, манифест веб-приложения и рабочие службы — все это позволит сайту загружаться быстрее, работать в оффлайн-режиме и отправлять push-уведомления. Обратите внимание, что при загрузке прогрессивного веб-приложения в браузере телефона устройству предлагается добавить сайт на главный экран.Прогрессивные веб-приложения не полностью поддерживаются на устройствах iOS, но, надеюсь, это изменится в ближайшем будущем.

  • Позволяет получать push-уведомления;
  • Приложения могут работать в оффлайн-режиме;
  • Базовые сайты получают лучшее ранжирование в поисковых системах.
  • Эта технология — это просто оболочка браузера, а не полнофункциональное приложение, поэтому технически это все еще веб-сайт;
  • Пользователи не получат опыт работы с нативным приложением (анимация, производительность), поскольку пользовательский интерфейс — это просто полноэкранное окно браузера без строки URL, которая может работать в автономном режиме;
  • Плохая совместимость (по-прежнему недоступна на iPhone и iPad).

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

Прогрессивные веб-приложения — отличный способ дополнить веб-сайт или веб-приложение, расширяя его охват. Они могут улучшить глобальный пользовательский опыт с устройствами, которые их поддерживают; однако, поскольку эта технология не распространена, ее следует рассматривать как дополнительное средство увеличение охвата веб-сайта, а не как способ трансформации веб-сайта в мобильное приложение.

Гибридное мобильное приложение (Hybrid Mobile Apps)

Apache Cordova

Apache Cordova — это платформа для создания мобильных приложений с использованием HTML, CSS и Javascript.

Приложения, созданные с использованием Apache Cordova, работают во встроенной среде браузера (WebView) на мобильных платформах Android, iOS и загружаются из App Store или Google Play Store. Приложение запускается с помощью ярлыка, который расположен на главном экране, и взаимодействует с API-интерфейсами смартфонов, функциями девайса (геолокация, камера и т. д.).

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

Помимо Cordova, есть и другие популярные платформы — Ionic и PhoneGap. Для примера того, как такое приложение выглядит и работает, можно скачать приложение для Национального музея афроамериканской истории и культуры.

Это приложение было создано с использованием Ionic framework и предлагает следующие возможности:

  • Поиск / исследование конкретных объектов в музее;
  • Видео дополненной реальности;
  • Обмен через социальные сети;

Недавним примером гибридного приложения, которое мы создали в Ezetech для Tickfinity — TicketNetwork POS для мобильных устройств (видео).

  • Высокая скорость разработки;
  • Написаны с помощью HTML, CSS, Javascript, что обеспечивают кросс-совместимое iOS, Android и веб-программное обеспечение (требуется только один веб-разработчик);
  • Доступны фреймворки, которые эмулируют пользовательские элементы UI (например, кнопки, меню и так далее);
  • UX близок к нативному опыту с использованием элементов UI, которые имитируют поведение обычного приложения;
  • Доступ к API-интерфейсу смартфона ( камера, push-уведомления, геолокация и другие).
  • UX не так хорош, как в родных приложениях (задержки на клики 300 мс, фантомные клики при прокрутке);
  • Чем сложнее приложение, тем медленнее оно работает из-за использования различных оболочек и библиотек;
  • Не работает в офлайн режиме;
  • Анимации трудно реализовать в UI.

Этот вариант подходит для MVP простых веб или мобильных приложений. Если у вас уже есть веб-приложение, построенное с помощью Javascript, вы можете использовать существующий код. Проще говоря Apache Cordova хорош для быстрого создания недорогих мобильных приложений со стандартными функциями.

React Native

React — отличный выбор, если ваше веб-приложение построено с помощью React.js. Это относительно новая технология в мире гибридных приложений, и миграция из существующего веб-приложения в мобильное может пройти довольно быстро. В результате вы получаете мобильное приложение, которое использует собственные компоненты ОС вашего смартфона (кнопки, входы и другие функции устройства). Производительность хорошая, потому что исходный код конвертируется в собственное мобильное приложение, а не работает во встроенном окне браузера.

Некоторые примеры приложений, использующих React Native:

  • Высокая скорость разработки для веб-приложений на основе React;
  • Веб-приложение, созданное с помощью React.js, может быть легко преобразовано в мобильное приложение React Native, а некоторые исходные коды можно повторно использовать;
  • Собственный пользовательский опыт;
  • Приложение выглядит и воспринимается как родное мобильное приложение для конкретной платформы;
  • Низкие затраты на разработку;
  • Эксперты в React Native обычно могут создавать приложения для Android и iOS.
  • Относительно новая технология (ограниченные решения с открытым исходным кодом);
  • Ограничено в отношении визуального дизайна;
  • Не подходит для сложных проектов, таких как мобильные игры или приложения, требующие высокой нагрузки (значительные вычисления).

React Native — самая популярная технология для разработки гибридных мобильных приложений. Она используется крупнейшими цифровыми корпорациями и имеет много преимуществ. Это хороший вариант, если вашему приложению не требуется поддерживать несколько соединений с сервером в реальном времени или выполнять сложные вычисления. Технология по прежнему новая, и не так много библиотек и модулей с открытым исходным кодом, как для собственных технологий разработки мобильных приложений, но она быстро развивается.

Разработка нативного приложения (Native app development)

Создание родных (native) приложений для каждой платформы — лучший выбор с точки зрения производительности и качества продукции, но это также и самый дорогой подход. Если у вас уже есть веб-приложение, вам нужно будет только создать мобильные клиенты для мобильного приложения Android и iOS, которые будут подключены к тому же бэкенду, что и ваш веб-клиент. Незначительные изменения могут быть все еще необходимы на бэкенде, но это не займет много времени.

Обычно вам нужно как минимум 2 разработчика — разработчик iOS, который работает над iPhone-приложением с использованием Objective-C или Swift, и разработчика Android, который будет использовать Java или Kotlin. Поэтому стоимость разработки будет выше, чем в любом из вышеперечисленных подходов.

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

Несколько примеров нативных мобильных приложений:

Coinbase: одно из самых популярных приложений для торговли криптовалютами.

Uber: самое популярное приложение для транспортировки.

  • Многие модули и библиотеки доступны для решения общих задач разработки;
  • Хорошая производительность и отличный пользовательский интерфейс на всех мобильных платформах;
  • Позволяет приложению получать доступ ко всем устройствам разрешенным производителем;
  • Может работать в офлайн режиме и хранить данные на устройстве.
  • Более высокие затраты по сравнению с разработкой гибридных приложений;
  • Различные стеки технологий для разных платформ (требуется больше разработчиков).
  • Обратите внимание, что лучше всего создавать нативное приложение c нуля, только если у вас есть на это ресурсы. Технологии для создания таких приложений уже давно существуют, что дает множество модульных решений, а также сообществ с открытым исходным кодом, доступных разработчикам для эффективного решения проблем.

Заключение

Есть два основных варианта, которые хорошо подойдут для перехода из веб-приложения в мобильное — разработка гибридного приложения и запуск с нуля (разработка нативного приложения).Если функциональность вашего продукта не слишком сложна, и вы просто хотите предложить мобильным пользователям лучший опыт, вы должны использовать React Native (если сайт на реакте) или Apache Cordova для разработки вашего гибридного приложения. Это оптимальный вариант, если у вас ограничен бюджет и вам нужна поддержка на Android и iOS.

Для сложных приложений, которые должны выполнять сложные вычисления, поддерживать соединение в реальном времени с сервером и предлагать пользователям уникальные функции, которые требуют постоянного взаимодействия с другими приложениями, лучше использовать нативную разработку. В этом случае вы сможете создать приложение с наиболее важным функционалом и улучшать его по мере роста вашего бизнеса.

Что касается разработки прогрессивного веб-приложения, то это достаточно новая технологическая парадигма. Такое приложение хорошо подойдет для расширения охвата вашего ресурса, но до полноценного мобильного приложения ему еще далеко.

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Платформы и средства создания Web-сервисов

В обзоре «Технологии для Web-сервисов», публикуемом в этом номере, мы ознакомились с технологиями, лежащими в основе Web-сервисов. В данной статье мы рассмотрим, каким образом ведущие компании поддерживают эти технологии и что они предлагают в качестве платформ и продуктов для создания, выполнения и использования Web-сервисов.

BEA Systems

омпания BEA предлагает создание Web-сервисов на платформе J2EE с использованием протокола SOAP. J2EE-приложения реализуют EJB и JMS как Web-сервисы. Сервисы используют WSDL как язык описания сервисов и обеспечивают доступ к компонентам посредством протокола SOAP 1.1 и транспортного уровня на основе HTTP. Для интеграции с партнерами применяются реестры на основе UDDI. В отличие от других компаний, BEA (и Borland) для управления бизнес-транзакциями между предприятиями использует Business Transaction Protocol (BTP). Этот протокол не зависит от стека и может быть реализован с использованием таких стандартов, как ebXML или SOAP.

Компания BEA четко выделяет два типа Web-сервисов — сервисы удаленного вызова процедур (RPC-based Web Services) для поддержки простых Web-сервисов и сервисы сообщений (Message-based Web Services) для поддержки асинхронных моделей коммуникаций, которые требуются для создания корпоративных Web-сервисов. Поддержка обоих типов Web-сервисов реализуется на платформе BEA WebLogic Enterprise Platform — это показано на рис. 1.

Сервисы удаленного вызова процедур

К этому типу Web-сервисов относятся сервисы, основанные на удаленном вызове процедур и реализуемые с использованием EJB без сохранения состояния (Stateless EJB). В этом случае клиентское приложение получает доступ к удаленному объекту. Взаимодействие между клиентом и Web-сервисом осуществляется на основе специфичных для сервиса интерфейсов. Вызывая Web-сервис, клиент посылает ему параметры, которые вызывают соответствующие методы сервиса, а сервис возвращает клиенту определенные данные. Поскольку такое взаимодействие предполагает осуществление синхронных операций между клиентом и сервером (клиент посылает запрос и ожидает ответа, прежде чем перейти к выполнению каких-либо других действий), сервисы удаленного вызова процедур напоминают традиционные распределенные объектные модели типа RMI или DCOM.

Сервисы сообщений

Как мы отмечали выше, сервисы сообщений используются для создания корпоративных Web-сервисов. Такие сервисы базируются на документах, а не на специфичных для сервиса интерфейсах. Вызывая сервис сообщений, клиент отсылает документ (например, заказ на приобретение продуктов), а не дискретный набор параметров. Web-сервис принимает документ, обрабатывает его и может даже не отсылать результирующее сообщение. Отсутствие в данном сценарии тесной связи между запросом и ответом дает определенные преимущества по сравнению с сервисами удаленного вызова процедур.

Платформа для создания и выполнения Web-сервисов, предлагаемая фирмой BEA, называется BEA WebLogic E-Business Platform и содержит следующие ключевые компоненты:

  • BEA WebLogic Server — сервер приложений, входящий в лидирующую тройку продуктов на рынке. Представляет собой основу платформы BEA WebLogic E-Business Platform и обеспечивает доступ и внедрение простых Web-сервисов. В настоящее время предусмотрена поддержка таких стандартов, как XML, SOAP, UDDI и WSDL;
  • BEA WebLogic Integration — открытый и расширяемый продукт, позволяющий интегрировать партнеров через Web и создавать комплексные Web-сервисы с поддержкой транзакций и защиты информации, работающие на основе стандартов ebXML и BTP;
  • BEA WebLogic Personalization Server — обеспечивает настройку Web-сервисов под конкретных клиентов в зависимости от пользовательских настроек, бизнес-правил или других критериев;
  • BEA WebLogic Workshop — средство разработки Web-сервисов на платформе BEA WebLogic E-Business Platform.

Создание Web-сервисов с помощью интегрированной среды WebLogic Workshop облегчается тем, что данная среда предоставляет обширный набор визуальных средств для разработки дизайна сервисов. Использование специальных компонентов обеспечивает доступ к таким ресурсам, как базы данных, компоненты EJB, а также к другим Web-сервисам и существующим приложениям. В состав продукта входят следующие компоненты: ServiceControl, TimerControl, EJBControl и JMSControl. Логика работы сервиса сохраняется в JWS-файле, содержимое которого графически отображается в режиме дизайна (рис. 2).

Приложения, создаваемые с помощью WebLogic Workshop, полностью соответствуют спецификации J2EE и не требуют внедрения на сервер приложений BEA WebLogic Server — достаточно любого сервера приложений, поддерживающего стандарт JWS. В состав WebLogic Workshop входит версия BEA WebLogic Server, поэтому Web-сервисы безо всяких проблем внедряются как файлы Enterprise Archive (EAR).

Завершая рассмотрение продуктов фирмы BEA Systems, отметим, что компания хорошо позиционирована на рынке, предлагает один из ведущих серверов приложений, имеет четкую стратегию по поддержке Web-сервисов и связанных с ними технологий и следует ей, разумно подходя к приобретению продуктов сторонних компаний и развивая собственные продукты.


Дополнительную информацию по продуктам фирмы BEA можно получить по адресу: http://www.beasys.com/products/index.shtml.

Borland

ирму Borland можно смело назвать пионером в области разработки средств создания Web-сервисов для различных платформ. Так, Delphi 6 позволяет создавать и использовать SOAP и WSDL на платформе Windows, Borland Kylix — на платформе Linux, а JBuilder — на платформе Java.

Продукты компании Borland можно разделить на три категории: разработка, развертывание и управление. К первой категории относятся:

  • Borland Enterprise Studio — это полная платформа для моделирования, разработки и внедрения решений для бизнеса и электронной коммерции. Продукт выпускается в двух вариантах: Borland Enterprise Studio for Java (включает JBuilder) и Borland Enterprise Studio for Windows (включает Delphi);
  • C++Builder — популярное средство для разработки Windows-приложений на языке C++; в версии 6 позволяет разрабатывать Web-сервисы и приложения на их основе. C++Builder 6 обеспечивает поддержку клиентов Web-сервисов, использующих как SOAP encoding, так и Document Literal style. Последний входит в состав Microsoft .NET Web Services. Предоставляя набор высокоуровневых компонентов и визардов, в том числе автоматическую публикацию WSDL-документов для Web-сервисов в режиме исполнения и генерацию кода на основе WSDL (WSDL Importer), C++Builder 6 позволяет разработчикам легко адаптировать существующие приложения для работы в режиме Web-сервисов и доступа к ним как во внутрикорпоративной сети, так и через Web;
  • Delphi 6 — обеспечивает быструю разработку приложений с использованием технологий CORBA и Web Services для платформы Windows. Необычайная легкость создания Web-сервисов позволяет быстро трансформировать существующие приложения в Web-систему. Интегрированная поддержка Apache дает возможность быстро создавать динамические Web-приложения с доступом к базам данных. Совместимость с Borland Kylix 2 обеспечивает кросс-платформенную разработку (в том числе многозвенных систем на основе CORBA IIOP и SOAP) без ущерба функциональности. Возможность доступа к компонентам Enterprise JavaBeans, развернутым на Borland AppServer, и наличие высокоуровневых средств работы с XML позволяют создавать решения корпоративного уровня;
  • JBuilder — включает наиболее полный набор средств визуальной разработки для создания приложений на платформе Java 2/J2EE 1.3. JBuilder 6 удовлетворяет практически всем возможным требованиям разработчиков конечных решений, позволяя интегрировать Web- и корпоративные приложения и обеспечивая группы разработчиков удобной и масштабируемой средой разработки. Визуальные инструменты и мастера упрощают и ускоряют разработку приложений. JBuilder 6 позволяет вести разработку на нескольких платформах, включая Windows, Linux, Solaris и Mac OS X. В настоящее время JBuilder занимает более 60% рынка коммерческих средств разработки на платформе Java;
  • Kylix — обеспечивает быструю разработку приложений с применением технологий CORBA и Web Services для платформы Linux. Уникальная легкость создания Web-сервисов дает возможность оперативно трансформировать существующие приложения в Web-систему. Интегрированная поддержка Apache позволяет быстро создавать динамические Web-приложения с доступом к базам данных. Совместимость с Borland Delphi 6 обеспечивает кросс-платформенную разработку без ущерба функциональности, включая разработку многозвенных систем на основе CORBA IIOP и SOAP. Возможность доступа к компонентам Enterprise JavaBeans, развернутым на Borland AppServer, и наличие высокоуровневых средств работы с XML позволяют создавать решения корпоративного уровня.

Для развертывания приложений Borland предлагает Borland e-business platform — основу для создания полноценной информационной инфраструктуры современного предприятия. Ориентированность на стандарты, уникальная гибкость и масштабируемость — залог успеха проектов, построенных на базе данных технологий. К этой категории относятся следующие продукты:

  • Borland Enterprise Server — первый интегрированный комплекс средств на основе новейших промышленных стандартов CORBA 2.4 и J2EE 1.3. Borland Enterprise Server, развивающий функциональность AppServer и VisiBroker, занимает ведущие позиции в области инфраструктурного программного обеспечения для телекоммуникационного и банковско-финансового секторов, в которых масштабируемость, высокая скорость обработки транзакций и доступность в режиме 24Ѕ7 являются критически важными требованиями;
  • Borland Enterprise Server AppServer Edition позволяет разработчикам сконцентрировать свои усилия на создании прикладной логики в виде компонентов EJB (Enterprise JavaBeans). Лежащее в основе AppServer инфраструктурное ядро VisiBroker добавляет к богатству функциональности J2EE мощь коммуникативных средств CORBA IIOP (Internet Inter-ORB Protocol), удовлетворяющих требованиям таких новых и актуальных стандартов, как CORBA Portable Object Adapter (POA), Object-by-value (OBV — передача объектов по значению) и RMI-over-IIOP;
  • Borland Enterprise Server Web Edition включает Web-сервер Apache и Web-контейнер Tomcat, которые были усовершенствованы Borland (в Apache встроен IIOP plug-in, конвертирующий HTTP-запросы в IIOP). Также в поставку BES Web Edition включена база данных JDataStore, которая не только удовлетворяет стандартные потребности разработчиков в области СУБД, но и позволяет осуществлять кэширование сессий. Borland Web Engine, интегрирующий Borland Web Server и Borland Web Container, построен на базе ядра VisiBroker, при помощи которого происходит управление балансом загрузки, а также обеспечивается отказоустойчивость среды развертывания сервлетов/JSP, Web-приложений и Web-сервисов, созданных с использованием Delphi;
  • Borland InterBase 6 — SQL-сервер баз данных, объединяет простоту использования, низкие затраты на сопровождение и мощность систем корпоративного уровня. Компания Borland гарантирует, что InterBase 6 совмещает силу мощной, апробированной архитектуры с развитыми технологиями, необходимыми для успеха прикладных систем.

И наконец, для управления и мониторинга прикладной инфраструктуры предприятия Borland предлагает AppCenter — уникальное средство управления и мониторинга объектных распределенных систем. Borland AppCenter 4.1 включает развитые инструменты управления объектами CORBA и компонентами Enterprise Java Beans (EJB), что делает его незаменимым средством для обеспечения жизненного цикла современных информационных систем. Интеграция AppCenter 4 с VisiBroker 4.x и Borland AppServer 4.x (включая версию 4.5.1) обеспечивает создание единой высоконадежной информационной среды предприятия.

Разработка Web-сервисов средствами Delphi 6, C++ Builder и Kylix базируется на трех основных компонентах:

  • BizSnap — для создания Web-сервисов на основе XML и SOAP. BizSnap упрощает обмен, трансформацию и манипуляцию XML-документами, обеспечивая гибкость и расширяемость бизнес-приложений, приводя их в готовность к использованию в электронном бизнесе новой волны;
  • WebSnap — для создания и отладки Web-приложений. Инструменты, входящие в состав WebSnap, например отладочный Web-сервер, упрощают отладку и тестирование приложений. Возможность плотной интеграции приложений WebSnap в корпоративные Web-сайты и порталы, разработанные с использованием таких известных средств, как DreamWeaver и FrontPage, а также поддержка серверных сценариев на JavaScript, VBScript и других языках позволяют вам задействовать существующие наработки в области Web-приложений;
  • DataSnap — для создания соединений с базами данных для приложений и сервисов через XML, DCOM или CORBA. DataSnap оптимизирует число соединений и потоки данных между клиентами и серверами баз данных за счет централизации доступа к данным и их обновления во всех процессах и приложениях электронного бизнеса, а также позволяет масштабировать приложения в зависимости от изменения объемов обрабатываемых данных.

Дополнительную информацию о продуктах фирмы Borland можно получить по адресу: http://www.borland.com/.

Hewlett-Packard

ewlett-Packard была первой компанией, которая стала заниматься исследованиями в области Web-сервисов еще в 1995 году. В 1999 году компания объявила о платформе E-speak, ставшей прообразом современной линейки продуктов фирмы, но до марта 2001 года никакой видимой активности в этом направлении не проявляла. В настоящее время объявлено о большом наборе программных продуктов под общим названием NetAction. Этот набор можно разделить на следующие основные компоненты:

  • HP Netaction Internet Operating Environment (IOE) — интегрированная платформа для построения и внедрения решений, позволяющая сконцентрироваться на бизнес-проблемах, а не на разработке программ;
  • HP Opencall — платформа для разработки сервисов, связанных с доставкой данных, голосовой информации и т.п.;
  • HP Chai — полная платформа для доставки Web-сервисов на различные устройства. Представляет собой настраиваемую Java-среду для доступа к Web, а также модульные блоки Embedded Linux.

Взаимодействие этих компонентов, а также ряда других продуктов фирмы показано на диаграмме (рис. 3).

Рассмотрим основные компоненты HP Netaction IOE более подробно:

  • HP Application Server — сервер приложений «нового поколения» с сервис-ориентированной архитектурой и поддержкой подключаемых сервисов;
  • HP Application Server Resilient Edition — версия сервера приложения для поддержки непрерывной работы, сообщений, транзакций и других технологий для обеспечения работоспособности Web-сервисов;
  • HP Process Manager — средство управления процессами, позволяющее графически определять бизнес-процессы и автоматизировать их выполнение;
  • HP Process Manager, Interactive Edition — средство быстрой (посредством графических средств моделирования) разработки композитных приложений для основанных на базе Web или мобильных сервисов;
  • HP Total-e-Transactions — средство управления транзакциями для J2EE-приложений;
  • HP Message Service — средство поддержки J2EE Java Message Service;
  • HP Web Services Registry — позволяет потребителям создавать и управлять корпоративными реестрами и доступом к Web-сервисам. Включает HP Registry Composer — графическое средство для регистрации и поиска сервисов как в Web-, так и в корпоративных реестрах;
  • HP Total-e-Syndication — средство автоматизации доставки наполнения Web-сервисов, интегрирующееся с другими продуктами фирмы;
  • HP Mobile Portal Solution — средство для доставки сервисов и наполнения на мобильные устройства;
  • HP Web Services Transactions — средство для управления транзакциями, состоящее из трех компонентов: координатора транзакций, сервера транзакций и клиентских библиотек, используемых для инициализации транзакций;
  • HP Web Services Platform — основанная на стандартах открытая архитектура для разработки, внедрения, регистрации, поиска и потребления Web-сервисов, в том числе программных средств и утилит для реализации Java-объектов в виде Web-сервисов. Архитектура HP Web Services Platform показана на рис. 4.

Для разработки сервисов предлагается использование средства HP Service Composer, которое предоставляет графический интерфейс для создания WSDL-интерфейсов для Java-объектов и поддерживает автоматическое внедрение Web-сервисов на сервер приложений HP Application Server.

Hewlett-Packard занимает собственную нишу на рынке средств создания Web-сервисов, сравнимую, может быть, с нишами, занимаемыми IBM и Sun, — компания обладает и аппаратными платформами для выполнения Web-сервисов, и программными платформами для внедрения и управления сервисами, а при успешном слиянии с Compaq у Hewlett-Packard появятся и консалтинговые сервисы.

отя IBM и не была в числе первых компаний, сформулировавших свое видение Web-сервисов, она фактически является лидером (как и с Microsoft) по продвижению стандартов и технологий, связанных с Web-сервисами. В настоящее время компания IBM не только предлагает широкий спектр продуктов для создания и внедрения Web-сервисов (от WebSphere Suite до средств хостинга Web-сервисов, поддержки Web-сервисов на уровне СУБД DB2 — в семействе продуктов Tivoli и Lotus), но и имеет определенную политику в отношении развития самой концепции Web-сервисов и активно участвует в ее продвижении, сотрудничая с другим лидером — Microsoft.

Говоря о предлагаемых IBM продуктах для создания и внедрения Web-сервисов, следует в первую очередь отметить такие средства, как WebSphere Studio для создания сервисов на языке Java, сервер приложений WebSphere Application Server, MQ Series для управления сообщениями для объединения систем, включая поддержку SOAP и Web-сервисов на уровне СУБД DB2.

Основные продукты

Из обширного семейства продуктов фирмы IBM можно выделить две линейки, представляющие прежде всего интерес для тех, кто собирается создавать Web-сервисы: семейство продуктов WebSphere Studio и семейство продуктов WebSphere Application Server:

  • WebSphere Studio — это набор средств для создания Web-сервисов. Существенно то, что данный продукт рассчитан не только на разработчиков, но и на Web-дизайнеров, художников и Web-мастеров, которые могут принимать участие в создании сервисов. WebSphere Studio включает такие средства, как Applet Designer — визуальное средство для создания Java-аплетов, WebArt Designer — для создания графических элементов и Animated Gif Designer — для создания анимированных GIF-изображений. Помимо этого отметим наиболее важные компоненты, входящие в состав WebSphere Studio: WebSphere Studio Site Developer — средство для создания и публикации Web-сервисов с поддержкой основных Web-стандартов, WebSphere Studio Application Developer — полный набор средств, включенных в WebSphere Studio Site Developer, а также средства мониторинга и тестирования сервисов;
  • WebSphere Application Server — этот серверный продукт обеспечивает поддержку всех основных стандартов Web-сервисов, интегрируется с WebSphere Studio, облегчая таким образом создание и внедрение Web-сервисов. Кроме того, в состав WebSphere Application Server включены средства интеграции с другими продуктами фирмы IBM — например Lotus Domino и WebSphere Commerce Suite. WebSphere Application Server — один из первых серверов приложений, совместимый со спецификацией J2EE 1.3.

По данным Giga Information Group, платформа WebSphere является наиболее важной для создания Web-сервисов — ее указали 33% опрошенных. Второй по значимости оказалась Microsoft .NET, а третьей — J2EE с дополнительными технологиями поддержки Web-сервисов (рис. 5).

Другие продукты

Среди огромного числа продуктов, предлагаемых IBM, есть такие, которые так или иначе связаны с Web-сервисами. Наиболее важными из них являются следующие:

  • VisualAge for Java — визуальное средство разработки на языке Java, интегрируемое с семейством продуктов WebSphere Studio;
  • DB2 — реляционная база данных, поддерживающая основные стандарты Web-сервисов, в том числе XML, UDDI и SOAP. DB2 при использовании совместно с DB2 XML Extender позволяет извлекать и хранить данные через Web-сервисы;
  • Web Services Hosting Technology — семейство продуктов для управления Web-сервисами, позволяющее анализировать использование сервисов и использовать различные модели оплаты;
  • Web Services Gateway — набор различных функций защиты доступа, включая поддержку аутентификации пользователей;
  • Web Services Toolkit — набор средств для разработки Web-сервисов.

Web Services Toolkit, бесплатно распространяемый IBM набор средств для разработки Web-сервисов, представляет собой реализацию архитектуры Web-сервисов, описанную в документе «Web Services Architecture Overview», доступном на Web-сайте фирмы IBM. Этот набор содержит следующие компоненты:

  • клиентская часть:
    • UDDI4J API для управления UDDI-реестрами (как корпоративными, так и расположенными в Internet) через функции Save, Delete, Find и Get;
    • Services Registry API для управления UDDI-реестрами через функции Publish, Unpublish и Find;
  • спецификации WSDL 1.1, Web Services Flow Language (WSFL), WS-Inspection и HTTPR (Reliable HTTP);
  • набор средств для разработки Web-сервисов:
    • утилиты на базе AXIS, включая утилиту Java2WSDL для генерации WSDL-документов на основе Java-кода и утилиту WSDL2Java для генерации Java-прокси-кода на основе WSDL-документа;
    • Web Services Toolkit Configuration Tool для настройки и конфигурации Web Services Toolkit;
    • Utility Web Services Portal Tool для управления пользователями Web-сервисов, включенными в состав Utility Web Services;
  • набор Web-сервисов (Utility Web Services), предоставляющих набор функций, которые можно использовать при создании бизнес-приложений:
    • Notification;
    • Common Data;
    • User Identity;
    • Metering;
    • Accounting;
    • Contract.
  • примеры использования Utility Web Services;
  • набор программных средств для развертывания Web-сервисов, включая WebSphere Application Server Micro Edition и UDDI-реестр;
  • утилита WSDLdoc для автоматической генерации документации на основе WSDL-файлов;
  • набор Java-классов для программного управления WSDL-документами (WSDL4J);
  • SOAPConnect for LotusScript — средство, позволяющее приложениям Lotus Domino и Lotus Notes использовать Web-сервисы;
  • UDDI4J для управления UDDI-реестрами из Java-приложений.

Архитектура Web Services Toolkit представлена на рис. 6. Здесь показаны основные компоненты Web Services Toolkit. Средства создания Web-сервисов, расположенные в нижней части справа, включают утилиты для обнаружения и публикации сервисов, а также для создания сервисов на основе существующих Java-приложений. Компоненты времени исполнения разделяются на серверные и клиентские компоненты. К серверным компонентам относятся UDDI-реестр для создаваемых Web-сервисов, набор Utility Web Services и примеры использования сервисов. Клиентские компоненты расположены в приложениях, которые обращаются к серверным компонентам, и поддерживают Java-интерфейсы, позволяющие приложениям осуществлять следующие операции:

  • публиковать и находить Web-сервисы, непосредственно обращаясь к UDDI (UDDI4J);
  • публиковать и находить Web-сервисы через WSDL-документы (WSDL-прокси);
  • обращаться к Web-сервисам через SOAP.

Отметим, что Web Services Toolkit не является коммерческим и его задача заключается в предоставлении набора технологий для широкого использования разработчиками. Ряд этих технологий впоследствии может войти в новые версии коммерческих продуктов типа WebSphere Studio Application Developer, WebSphere Application Server или в другие продукты IBM, Tivoli или Lotus (см. http://www.lotus.com/developer/).

В будущих версиях Web Services Toolkit планируется реализовать следующие компоненты: дополнительная поддержка защиты, расширения для управления сервисами, поддержка WorkFlow, поддержка новых версий Apache AXIS, предоставление среды для создания, публикации и поиска сервисов, улучшение интеграции с UDDI-реестрами.

Дополнительная информация о Web Services Toolkit доступна на Web-сайте по адресу: http://www.alphaworks.ibm.com/tech/webservicestoolkit/.

Microsoft

icrosoft играет активную роль на рынке средств создания и потребления Web-сервисов и совместно с IBM участвует практически во всех связанных с этой технологиях новациях. Практически нет ни одного стандарта (начиная со стандарта языка XML), в принятии которого не была бы заметна роль Microsoft. Примером заинтересованности Microsoft в лидерстве на рынке Web-сервисов может служить факт создания совместно с IBM в феврале 2002 года ассоциации Web Services Interoperability Organization (WS-I, http://www.ws-i.org/), которая к настоящему времени насчитывает более 100 членов.

В качестве платформы для Web-сервисов Microsoft предлагает .NET Framework и набор корпоративных серверных приложений (семейство .NET Enterprise Servers). На сегодняшний день .NET представляет собой наиболее полную реализацию технологий Web-сервисов. Для разработки и потребления Web-сервисов Microsoft предлагает Visual Studio .NET — визуальную среду, поддерживающую все языки программирования и интегрирующуюся с существующими серверами компании.

Полнота реализации фирмой Microsoft технологий Web-сервисов подтверждается данными исследований, проведенных компанией Gartner, Inc. (см. «Web Services Major Vendors», D. Smith, August 2001 — рис. 7).

Продукты Microsoft для создания Web-сервисов подразделяются на пять основных категорий — .NET Experiences, клиенты, XML Web-сервисы, утилиты и серверы:

  • XML Web-сервисы — представляют собой строительные блоки компонентов, основанные на стандартах Web-сервисов: SOAP, WSDL, UDDI и XML. Первой, но неудачной попыткой создания подобных блоков стал набор сервисов, известных как .NET My Services, для хранения различной персональной информации. К этой категории также относятся такие сервисы, как .NET Passport и .NET Alerts;
  • .NET Experiences — Microsoft описывает .NET Experiences как набор Web-сервисов, которые позволяют «обращаться к информации через Internet или из обычных приложений». Пока различия между XML Web-сервисами и .NET Experiences определены недостаточно четко, но первыми продуктами в категории .NET Experiences стали: MSN — пользовательский Web-узел, поддерживаемый Microsoft, bCentral — Web-узел для малого бизнеса и Microsoft Visual Studio .NET — средство разработки приложений для .NET;
  • клиенты — к этой категории относятся как аппаратные, так и программные компоненты. Аппаратным компонентом может быть любое устройство, способное обращаться к Web-сервисам и поддерживающее TCP/IP-коммуникации, в том числе персональные компьютеры, телефоны, «ручные» компьютеры, игровые консоли и т.п. С точки зрения Microsoft, тип аппаратного компонента не имеет значения — главное, чтобы он базировался на каком-либо варианте платформы Windows; будь то Windows XP или Windows CE;
  • серверы — к данной категории относятся продукты семейства .NET Enterprise Servers, в том числе Microsoft Windows 2000 и др.;
  • утилиты — Microsoft предлагает большой набор программных средств для создания .NET Web-cервисов, в том числе Microsoft Visual Studio .NET и .NET Framework.

Архитектура платформы Microsoft .NET показана на рис. 8.

Семейство продуктов Microsoft

Семейство продуктов Microsoft .NET пополняется практически каждый месяц, но для нашего обзора достаточно уже существующих серверных продуктов, средств разработки, операционных систем и Web-сервисов:

  • серверные продукты базируются на серверной операционной системе Windows 2000, на смену которой в скором времени придет ОС Windows .NET Server. Среди различных серверных продуктов следует выделить: Windows 2000 Server — серверную операционную систему, включающую поддержку каталогов, Web, приложений, коммуникаций, файловые сервисы и сервисы печати, Application Center для управления группами серверов; Mobile Information Server — сервер, позволяющий доставлять информацию и .NET-сервисы на мобильные устройства; BizTalk Server — сервер для поддержки обмена XML-информацией и документами между приложениями и бизнесами; Commerce Server — сервер для создания приложений электронной коммерции; Content Management Server — сервер для управления наполнением Web-сайтов и доставки этого наполнения различным клиентам;
  • средства разработки. Основным продуктом здесь является Microsoft Visual Studio .NET — средство для создания .NET-сервисов, поддерживающее такие языки программирования, как Visual Basic, C# и J#. Последний, однако, формально поддерживая синтаксис языка Java, не позволяет создавать стандартные Java-приложения — написанный код будет работать только под управлением Microsoft .NET;
  • операционные системы и прикладное ПО. Операционные системы являются ядром стратегии Microsoft .NET. Сюда входят все версии Windows, включая Windows CE для PDA, Windows Embedded и версии Windows, работающие на консоли Microsoft Xbox. Из прикладного программного обеспечения фирмы Microsoft отметим пакет Microsoft Office, для последней версии которого существует поддержка .NET;
  • Web-сервисы. Сервисы — это XML-компоненты и строительные блоки, которые могут использоваться Microsoft и другими компаниями для построения Web-сервисов.

Некоторые вопросы использования Microsoft Visual Studio .NET для создания Web-сервисов рассматривались в статье «Web нового поколения — Web-сервисы», опубликованной в КомпьютерПресс № 6’2001.

Дополнительную информацию о поддержке Web-сервисов можно найти на Web-сайте фирмы по адресу: http://www.microsoft.com/webservices/.

Oracle

есмотря на то что фирма Oracle давно обсуждала проблемы, связанные с Web-сервисами, вполне четкая концепция поддержки этой технологии сформировалась относительно недавно. Теперь поддержка Web-сервисов сопровождается широкомасштабной кампанией, лозунг которой можно сформулировать следующим образом: «С использованием продуктов Oracle разработка Web-сервисов будет в десять раз быстрее, в десять раз менее ресурсоемкой, а сами сервисы будут в десять раз надежнее».

Oracle имеет два подхода к созданию и использованию Web-сервисов: во-первых, фирма предлагает программную инфраструктуру, которую разработчики могут использовать для создания Web-сервисов, а во-вторых, разрабатывает и продает программные продукты как Web-сервисы.

Более того, Oracle использует Web-сервисы для того, чтобы расширить сферу влияния за пределы рынка баз данных. Началом этому послужило появление E-Business Suite — набора корпоративных продуктов, которые могут работать через Internet.

Для разработки Web-сервисов Oracle предлагает J2EE-совместимую среду Oracle 9i JDeveloper (этот продукт доступен в виде бесплатной версии). Для выполнения Web-сервисов применяется сервер приложений Oracle 9i Application Server, а для создания приложений, использующих данные, СУБД Oracle 9i Database.

Кроме того, Oracle предлагает E-Business Suite — серверное программное обеспечение, работающее через Internet и включающее такие компоненты, как CRM, B2B, управление финансами, проектами, ресурсами, а также компоненты Business Intelligence. Набор Oracle Small Business Suite также работает через Internet и содержит модули для ведения счетов, создания отчетов, управления заказчиками и ряд других.

На рис. 9 показана инфраструктура Web-сервисов, предлагаемая Oracle.

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

Средства разработки Oracle 9i

Семейство средств разработки Oracle 9i представляет собой набор интегрированных программных продуктов, используемых для создания и внедрения Web-сервисов. Еще раз отметим, что это семейство состоит из трех основных компонентов: Oracle 9i JDeveloper для разработки Web-сервисов, Oracle 9i Application Server для выполнения Web-сервисов и Oracle 9i Database для создания приложений, работающих с данными, которые могут использоваться совместно с Web-сервисами:

    Oracle 9i JDeveloper — это J2EE-совместимая платформа для разработки Web-сервисов на языке Java. Oracle 9i JDeveloper может работать под управлением Windows, Linux и Solaris. Существенным здесь является то, что созданные с использованием Oracle 9i JDeveloper решения легко внедряются на сервер приложений Oracle 9i Application Server (Oracle утверждает, что для этого достаточно одного щелчка кнопки мыши — sigle click delpoyment). В состав Oracle 9i JDeveloper входят и средства для работы с базами данных, что не удивительно для компании, в арсенале которой имеется Oracle 9i Database. Продукт поддерживает создание Web-сервисов и их внедрение как Java-сервисов, а также внедрение на платформе Microsoft .NET. Таким образом, разработчики получают единую среду для создания и внедрения Web-сервисов на обеих платформах. Для работы с XML предлагается XML Developer’s Toolkit (XDK), в состав которого входят: XML Parsers (Java, C, C++, PL/SQL), XSLT Processors, XML >

Oracle Web Services Business Suites

Семейство Oracle Web Services Business Suites — это набор программных продуктов, функционирующих как Web-сервисы. E-Business Suite содержит полный комплект корпоративных средств, работающих через Internet, куда входят средства для управления клиентами, средства интеграции бизнесов, финансовые средства, средства управления проектами, ресурсами и набор модулей для аналитической обработки информации. В состав Small Business Suite (ближайший аналог — bCentral фирмы Microsoft) включены средства для управления счетами, платежами, средства создания Web-магазинов, онлайновой оплаты счетов, управления отчетами и т.п. Использование Small Business Suite обходится в 99 долл. в месяц. Помимо этого Oracle предлагает дополнительные программные продукты, выполненные в виде Web-сервисов. Сюда относятся средства для управления продажами, средства поддержки клиентов, средства для создания порталов и т.п.

Демонстрируя свою приверженность Web-сервисам, Oracle использует эту технологию для управления своими внутренними операциями. Oracle показала потенциальную модель и доказала, что программное обеспечение может распространяться как набор сервисов.

Завершая рассмотрение средств для создания Web-сервисов, а также предлагаемых Oracle Web-сервисов, отметим, что несомненным преимуществом продуктов данной фирмы является широкий набор программных продуктов, легко интегрирующихся между собой, не последнюю роль в котором играет Oracle 9i Database, широко используемая при создании различных корпоративных решений. Еще одним преимуществом является то, что продукты компании не связаны с какой-либо конкретной аппаратной платформой.

Более подробную информацию об Oracle Web Services Business Suites можно получить по адресу: http://www.oracle.com/applications/index.html.

Sun Microsystems

ирма Sun давно приводила аргументы в пользу того, что сервисы, доступные через Web, в один прекрасный момент заменят традиционные приложения. Тем не менее у Sun ушло достаточно много времени на то, чтобы ее видение проблемы сформировалось в четкую концепцию, поэтому планы фирмы по отношению к Web-сервисам оформились сравнительно недавно.

Sun объявила инициативу Sun ONE (Open Net Environment) в октябре 2001 года (рис. 10). Необходимость появления этой платформы была обусловлена следующим обстоятельством: несмотря на то что J2EE обеспечивает надежную, масштабируемую, переносимую платформу для создания корпоративных решений, она до недавнего времени не имела стандартизованной поддержки Web-сервисов.

Sun ONE — это и архитектура, и платформа, и набор средств для создания и внедрения основанных на открытых стандартах (XML, UDDI, WSDL, SOAP) Web-сервисов, называемых в терминах Sun сервисами по запросу — Services on Demand (рис. 11).

Платформа Sun ONE базируется на следующих основных компонентах: на операционной системе Solaris, платформе Java 2 Platform, наборе серверов семейства iPlanet и средствах разработки Forte Development Tools. Ниже мы рассмотрим эти компоненты более подробно и перечислим их основные характеристики и назначение.

Solaris

Solaris — это операционная система на базе UNIX, функционирующая на системах на основе SPARC и на основе Intel. Она разработана с учетом мультипроцессорной поддержки и 64-битной архитектуры. Вместе с операционной системой поставляются Forte for Java, Forte Developer 6 Tools, iPlanet Web Server, iPlanet Directory Server, набор офисных продуктов StarOffice и СУБД Oracle8i Enterprise Edition.

В семейство Solaris входят следующие продукты:

  • Solaris Operating Environment — основа систем фирмы Sun. Это вычислительная среда для серверов любого уровня — от серверов отделов до массивных, объединенных в кластеры серверов, насчитывающих более 100 процессоров, — разработанная для мультипроцессорных 64-битных систем;
  • Trusted Solaris Operating Environment — расширяет возможности Solaris Operating Environment, защищая вычислительную среду от внутренних и внешних проникновений;
  • Solaris WBEM Services — используется для создания и модификации информации, хранимой в стандартном CIM-формате, облегчает администрирование Solaris Operating Environment и обеспечивает взаимодействие управляющих сервисов;
  • Solaris Bandwidth Manager — управляет сетевым трафиком;
  • Solaris Resource Manager — управляет системными ресурсами, обеспечивая их доступность и лучшее использование;
  • Solaris Easy Access Server — используется для включения систем на базе Solaris в сети на базе Windows NT;
  • Solaris PC NetLink — переносит сетевые сервисы типа Windows NT, файловые сервисы, сервисы печати, управление каталогами и аутентификацией с PC-серверов в среду Solaris Operating Environment;
  • Solaris Data Encryption — обеспечивает поддержку технологий шифрования для Solaris Operating Environment;
  • Solaris PDASync — синхронизует настольные приложения Solaris с устройствами на базе Palm OS и приложениями, выполняющимися на персональных компьютерах;
  • Sun Cluster — позволяет использовать базовые сервисы Solaris в рамках кластеров, обеспечивая полную совместимость с существующими приложениями для Solaris Operating Environment;
  • Sun Management Center — обеспечивает функции управления для Solaris Operating Environment, включая сервисы для управления аппаратными и программными конфигурациями. В дополнение к Sun Management Center предлагается Service Availability Manager, который увеличивает доступность сетевых серверов, выполняющихся локально или удаленно на системах Sun, осуществляет мониторинг и подтверждает доступность сетевых сервисов — Web-серверов, FTP-, Mail-, Calendar-сервисов и т.п. Дополнительным продуктом для Sun Management Center также является System Reliability Manager, который увеличивает надежность платформы и содержит ряд модулей для внедрения обновлений, слежения за файловой системой, запуска скриптовых программ и анализа протоколов сбоев операционной системы.

Более подробную информацию об операционной системе Solaris можно получить по адресу: http://wwws.sun.com/software/solaris/.

Java 2 Platform

Java является ключевой технологией фирмы Sun, на которой базируется большинство предлагаемых ею продуктов и сервисов. С момента появления технологии Java базовая философия фирмы не изменилась: вы один раз пишете приложение на языке Java и оно способно работать на любой платформе, независимо от операционной системы. Для этого необходимо использование соответствующей виртуальной машины Java — Java VM. Самая новая версия платформы для разработки на языке Java — Java 2 Platform, Enterprise Edition (J2EE). С точки зрения фирмы Sun, приложения, которые будут выполнять функции Web-сервисов, должны быть написаны на языке Java. Java-приложения могут работать на любом устройстве, содержащем Java VM, включая персональные компьютеры, мобильные компьютеры, сотовые телефоны и беспроводные устройства.

Более подробную информацию о Java можно получить по адресу: http://wwws.sun.com/software/java/index.html.

В задачи данного обзора не входит рассмотрение всех интерфейсов и технологий, основанных на платформе J2EE. Здесь мы остановимся лишь на интерфейсах, обеспечивающих работу с XML-документами и создание и потребление Web-сервисов, — Java XML Pack и Java Web Services Developer Pack.

Java XML Pack

Пакет Java XML Pack — это набор интерфейсов и средств для разработки, публикации, обнаружения и потребления XML Web-сервисов для платформы Java 2 Platform. Входящие в состав Java XML Pack технологии можно разделить на две большие категории — средства для работы с XML-документами и средства для использования XML-технологий. К первой категории относятся:

  • Java API for XML Processing (JAXP) — набор интерфейсов для обработки XML-документов с использованием JAXP-совместимого парсера. Обеспечивается поддержка как событийной модели (SAX), так и древовидной модели (DOM) обработки XML-документов;
  • Java Architecture for XML Binding (JAXB) — средства для отображения между XML-документами и Java-классами, позволяющие использовать XML-документы как обычные Java-объекты.
  • К средствам использования XML-технологий, входящим в состав Java XML Pack, относятся:
  • Java API for XML Messaging (JAXM) — поддержка передачи XML-сообщений с использованием языка Java. JAXM базируется на спецификациях SOAP 1.1 и SOAP with Attachments, но при необходимости возможно расширение функциональности для поддержки высокоуровневых протоколов типа ebXML или bizTalk;
  • Java API for XML Registries (JAXR) — унифицированный механизм доступа к реестрам из языка Java. JAXR не связан с конкретной реализацией реестров и может использоваться как с XML-реестрами на базе стандарта ebXML Registry and Repository, так и с реестрами на основе спецификации Universal Description, Discovery and Integration (UDDI)
  • Java API for XML-based RPC (JAX-RPC) — средства поддержки вызова удаленных методов на базе языка XML через Internet.

Java Web Services Developer Pack

Недавно фирма Sun выпустила пакет Java Web Services Developer Pack (Java WSDP), в состав которого входит и Java XML Pack. Java Web Services Developer Pack — это набор средств, облегчающих создание Web-сервисов на платформе Java 2. Этот набор включает, помимо Java XML Pack, следующие компоненты:

  • JavaServer Pages Standard Tag Library (JSTL) 1.0 Beta 1;
  • Ant Build Tool 1.4.1;
  • Java WSDP Registry Server 1.0 EA2;
  • Web Application Deployment Tool;
  • Apache Tomcat 4.1-dev Container.

Java WSDP поддерживается на следующих платформах: Solaris 2.8, Windows 2000, Professional Edition, Windows XP, Professional Edition, RedHat Linux 7.2.

В состав Java Web Services Developer Pack входит более чем 600-страничное методическое пособие «The Java Web Services Tutorial», в котором рассматриваются все аспекты создания Web-сервисов с использованием перечисленных выше интерфейсов, библиотек и технологий.

iPlanet

iPlanet — это семейство серверных продуктов фирмы Sun. В его состав входят Web-сервер, сервер каталогов, а также другие серверы, которые мы кратко рассмотрим ниже. Следует отметить, что появление в составе iPlanet средств обмена сообщениями является прямым ответом на Microsoft .NET Alerts. Однако в отличие от Microsoft .NET Alerts средства обмена сообщениями и нотификациями фирмы Sun базируются не на Microsoft Passport, а на альтернативном решении, известном как Liberty Alliance.

В семейство iPlanet входят следующие продукты:

  • iPlanet Directory Server — предназначен для хранения и управления профилями, привилегиями доступа, приложениями и сетевыми ресурсами. Кроме того, существуют версии iPlanet Directory Server Access Management Edition и iPlanet Directory Server Integration Edition;
  • iPlanet LDAP Proxy Server — обеспечивает сервисы безопасности для iPlanet Directory Server;
  • iPlanet Certificate Management System — обеспечивает корпоративные сервисы аутентификации сотрудников, клиентов и партнеров, управляет сертификатами на базе X.509;
  • iPlanet Web Proxy Server — служит в роли управляющего трафиком, собирая данные из сети, определяя механизмы перенаправления и выполняя соответствующие сервисы;
  • iPlanet Portal Server — используется для внедрения коммерческих порталов и включает сервисы управления членством, персонализации, интеграции и поиска информации;
  • iPlanet Web Server Enterprise Edition — Web-сервер с поддержкой Java Servlets и Java Server Pages;
  • iPlanet Biller Xpert — облегчает подготовку и публикацию счетов, оплату через Internet;
  • iPlanet Market Maker — управляет каталогами, ценовыми моделями, онлайновыми переговорами, аукционами и т.п.;
  • iPlanet BuyerXpert — используется для контроля закупок с Web-интерфейсом;
  • iPlanet SellerXpert — используется для автоматизации работы каналов продажи;
  • iPlanet Trustbase Transaction Manager — обеспечивает защищенные коммуникации между организациями и клиентами;
  • iPlanet Messaging Server — обеспечивает сервисы для обмена информацией, отсылки и приема сообщений с поддержкой Web-интерфейса;
  • iPlanet Calendar Server — управляет календарями, разделением ресурсов, расписанием событий и групповой работой;
  • iPlanet Application Server — используется для разработки, внедрения и управления основанными на Java 2 Platform Enterprise Edition (J2EE) приложениями на различных серверах, клиентах и устройствах. Также существуют версии iPlanet Application Server EAI Edition и iPlanet Application Server B2B Edition;
  • iPlanet Message Queue for Java — используется для интеграции унаследованных систем и данных с новыми приложениями и ERP-решениями;
  • iPlanet Unified Development Server — служит для быстрого создания, внедрения и управления сетевыми приложениями.

Более подробную информацию о семействе продуктов iPlanet можно получить по адресу: http://wwws.sun.com/software/iplanet/products/.

Forte Development Tools

Для разработки Web-сервисов используется Forte for Java — интегрированная среда разработчика на языке Java (рис. 12). Forte for Java базируется на платформе NetBeans Tools Platform и позволяет разработчикам создавать J2EE-приложения, разрабатывать и публиковать Web-сервисы, включать Web-сервисы в состав Web-сайтов и т.п.

Forte for Java поставляется для различных платформ, в том числе для Windows, Linux и Solaris. Среда разработчика имеет открытый интерфейс и расширяема — в настоящее время существуют дополнительные продукты от более чем 75 сторонних компаний. Для коллективной разработки приложений используется Forte Code Management Software.

Более подробную информацию о Forte for Java можно получить по адресу: http://wwws.sun.com/software/Developer-products/ffj/index.html.

Помимо всего прочего фирма Sun занимается разработкой набора Web-сервисов, включающего Sun ONE WebTop — набор офисных продуктов (текстовый процессор, электронная таблица, графический пакет и т.п), доступных как Web-сервисы, а также набора Web-сервисов для поддержки посылки/получения сообщений и управления расписаниями событий. Кроме того, в документе, озаглавленном «Sun ONE Architecture Guide», можно найти раздел, посвященный базовым Web-сервисам, в котором упоминаются такие сервисы, как Location Web Service, Presence Web Service, Notification Web Service, Usage Web Service, Search Web Service, File Web Service, а также набор Web-сервисов, делающих доступной функциональность продуктов семейства iPlanet.

Одним из примеров Web-сервисов является myServices.ONE, который реализует корзину покупателя, используемую в нескольких магазинах. Созданный с помощью iNsight for Forte for Java, этот Web-сервис позволяет покупателям просматривать и обновлять свои покупки в одной корзине. В сервис myServices.ONE входят: myIdentity (поддержка идентификации между Web-узлами), myBasket (поддержка централизованной корзинки покупателя для нескольких магазинов), myJeeves (централизованная автоматизация оплаты).

Как мы уже отмечали, фирма Sun не сразу четко сформулировала свою позицию по отношению к Web-сервисам. Из-за этого было потеряно время, позволившее другим компаниям — в первую очередь IBM и Microsoft — выйти в лидеры. Тем не менее Sun обладает всем необходимым — от языка Java до средств разработки, от операционной системы до серверных продуктов, — чтобы выйти в первую пятерку лидеров, предлагающих средства для создания Web-сервисов. К положительным моментам также следует отнести большое число Java-разработчиков, лояльных к продуктам и технологиям фирмы, а также наличие широкого спектра аппаратных решений.

Sybase

феврале нынешнего года компания Sybase объявила о стратегической инициативе, направленной на то, чтобы помочь клиентам перенести существующие инфраструктуры на Web-сервисы. Sybase планирует активно участвовать в поддержке стандартов, участвует в работе таких организаций, как Web Services Interoperability Organization (WS-I) и Organization for Structured Information Standards (OASIS).

Поддержка Web-сервисов будет осуществляться по четырем ключевым направлениям: разработка, внедрение, доступ и управление. Ниже мы рассмотрим продукты, которые будут выполнять каждую из перечисленных функций.

Разработка

EAServer Web Service Toolkit — набор средств для создания, тестирования, автоматизации и внедрения приложений с использованием Web-сервисов и соединения таких приложений с существующими бизнес-процессами. Эти средства также позволяют публиковать Web-сервисы через UDDI-реестры.

PowerDesigner 9.0 объединяет различные подходы к моделированию и позволяет пользователям полностью разобраться в элементах, составляющих Web-сервис. С помощью PowerDesigner 9.0 дизайнеры могут легко генерировать код и объекты баз данных, необходимые для разработки и выполнения Web-сервисов. Используя генерацию кода на основе шаблонов, PowerDesigner 9.0 автоматизирует создание кода для выбранного языка программирования, а также WSDL-документов, необходимых для внедрения Web-сервисов.

PowerBuilder будет поддерживать все стандарты, связанные с Web-сервисами, включая SOAP, XML, WSDL, UDDI и XSL, а также стандарты, которые появятся в будущем. Разработчики смогут публиковать и редактировать данные, а также обмениваться XML-информацией через протоколы, связанные с Web-сервисами на платформах J2EE и Microsoft .NET. Web-сервисы будут доступны клиентам PowerBuilder и другим клиентам, поддерживающим стандарты Web-сервисов. В настоящее время партнерская стратегия Sybase в области PowerBuilder дает разработчикам доступ к Web-сервисам через невизуальные объекты (Non-Visual Objects, NVO). PowerBuilder и Web Services Toolkit, поставляемый в составе Sybase EAServer, облегчают разработчикам на PowerBuilder создание и внедрение NVO как Web-сервисов прямо на сервер приложений EAServer.

Внедрение

EAServer 4.1 — сервер приложений с поддержкой открытых стандартов и технологий, необходимых для разработки, потребления и внедрения приложений на основе Web-сервисов, включая поддержку UDDI, SOAP, J2EE, WSDL и возможности управления UDDI-реестрами.

Business Process Integrator позволяет бизнесам интегрировать и управлять «потоком» Web-сервисов и приложений; таким образом компании могут управлять внешними и внутренними бизнес-процессами. Этот продукт позволяет доставлять SOAP-сообщения от одного приложения на основе Web-сервисов к другому, а кроме того, поддерживает приложения в стандартах ebXML и RosettaNet.

СУБД Sybase, в том числе Adaptive Server Enterprise, Sybase Adaptive Server IQ и SQL Anywhere, дают возможность приложениям на основе Web-сервисов обращаться к данным, хранимым в СУБД Sybase, а также в СУБД от IBM, Microsoft и Oracle, посредством хранимых процедур.

Доступ

В Sybase Enterprise Portal расширены возможности Portlet Framework для поддержки компонентов порталов (Portlets) с использованием Web-сервисов. Расширение существующей структуры позволяет разработчикам реализовать бизнес-логику в виде Web-сервисов и разделять такие сервисы между компонентами порталов (Portlets) и приложениями. Подобный подход позволяет существенно снизить время, необходимое для разработки и тестирования. Помимо этого такие Web-сервисы становятся доступными другим порталам и приложениям.

iAnywhere Solutions m-Business Platform поддерживает Web-сервисы для расширения доступа к корпоративной информации через мобильные и беспроводные устройства. Встроенная поддержка мобильных коммуникаций, включая возможность посылки сообщений на различные устройства с помощью различных сетевых протоколов, может быть использована как Web-сервис другими корпоративными приложениями. Компания также планирует создание набора средств для разработчиков, который позволит создавать дополнительные Web-сервисы.

Управление

BizTracker следит за производительностью среды, в которой выполняются Web-сервисы.

Open Bizs Interchange координирует и управляет Web-сервисами, а также различными гетерогенными технологиями на одном логическом уровне, который располагается над другими сервисами и может рассматриваться как единый элемент управления. Выступая в виде сервиса хостинга, Open Bizs позволяет пользователям быстро соединяться с партнерами с помощью выбираемой технологии и не требует установки и настройки различных связующих компонентов.

12 методологий разработки ПО

  • Waterfall — традиционный подход.
  • RUP (Rational Unified Process) — рациональный.
  • Agile — общая методология гибкой разработки.
  • Crystal Clear — подход с уравниванием разработчиков в коллективе.
  • Spiral — спиральный метод.
  • DSDM (Dynamic Systems Development Model) — динамическая модель.
  • FDD (Feature Driven Development) — методология, рассматривающая будущие изменения.
  • JAD (Joint Application Development) — ориентированный на пользователя подход.
  • RAD (Rapid Application Development) — модель быстрой разработки.
  • Scrum — концепция работы в условиях сорванных сроков и идеологического кризиса.
  • XP (Extreme Programming) — экстремальная разработка в динамической среде.
  • LD (Lean Development) — метод, предполагающий бережное отношение ко всем участникам процесса.

Давайте попробуем разобраться, что скрывается за этими английскими названиями.

Waterfall

Модель Waterfall относится к классическому пониманию разработки ПО. Весь процесс является жестким и линейным, имеет четкие цели для каждого этапа, новая фаза начинается по завершению предыдущей, нет возврата назад. Преимущества водопадной методологии — децентрализация и строгий контроль над сроками и качеством исполнения.

На практике Waterfall часто не оправдывает ожиданий, поскольку игнорирует динамические изменения. Так, после тестирования очень сложно откатить процесс и заложить функции, не учтенные на стадии разработки. Waterfall неэффективен ещё и потому, что предполагает временные простои сотрудников в рамках одного проекта. Тестирование проводится только в конце разработки, хотя проблемы, найденные на этом этапе — это дорогостоящие исправления.

RUP — итеративный подход, который решает проблемы, которые есть у Waterfall. Чем хорош RUP:

  • Учитывает изменяющиеся требования. Как бы ни был хорош руководитель проекта, учесть всё в начале невозможно.
  • Интеграция функций происходит постепенно, то есть каждая «деталь» проходит цикл разработки, проверки и внедрения в проект. Как следствие, снижаются риски и стоимость производства.
  • Ранний выпуск продукта. ПО выходит с уменьшенной функциональностью, чтобы занять нишу на рынке и противостоять конкурентам, после чего обрастает «мясом».
  • Повторное использование. При наращивании функциональности проще выделить типовые решения, которые сократят разработку.
  • Постоянное обучение. Из-за частых итераций разработчики не имеют больших пауз между доработкой кода, поэтому профессиональный рост происходит плавно и безболезненно.
  • Постоянное улучшение продукта. Итерации позволяют оценить проект не только с точки зрения соответствия плану и ТЗ, но и найти пути увеличения эффективности и качества продукта.

Agile

Agile — метод гибкой разработки программного обеспечения, предполагающий большое количество итераций. Документ Agile Manifesto описывает 4 идей и 12 принципов гибкого подхода, коротко его можно описать всего двумя пунктами:

  • Неформальные отношения важнее задокументированных. То есть устные договоренности между сотрудниками, между заказчиком и исполнителем важнее всего, что отражено в планах, договорах и техническом задании. Иначе говоря, клиент всегда прав.
  • Работающий продукт — главная оценка прогресса. Важны не инструменты, решения, производительность и изящество, а тот факт, что все запланированные возможности реализованы.

Несмотря на недостатки, Agile стала фундаментальной концепцией для разработки ПО и нашла отражение в других методологиях, речь о которых пойдет далее.

Crystal Clear

Методология, созданная для небольших коллективов из 6−10 сотрудников. Также поддерживает принципы гибкой разработки, но имеет чуть больше конкретики. Основная идея, которая и заключена в названии — каждая команда является набором людей с разным уровнем знаний, разными умениями и опытом.

Именно поэтому нет универсального подхода для разработки софта, он должен определяться в процессе общения внутри группы. Там же назначаются роли, инструменты, стандарты. Затем группа принимается за единицу и те же самые вопросы решаются на уровень выше, пока иерархия не дойдет до заказчика.

Spiral

Модель спирального жизненного цикла — это сложная организация жизненного цикла ПО, которая фокусируется на раннем выявлении и уменьшении проектных рисков. Разработка начинается в небольшом масштабе, решаются локальные задачи, оцениваются риски и пути их уменьшения. Следующий шаг охватывает более комплексные задачи — следующий виток спирали.

Преимущество подхода не в увеличении скорости разработки, а в снижении уровня возникновения рисков. Успешность спирального метода зависит от добросовестного, внимательного и компетентного управления, а размер проекта не имеет принципиального значения.

Модель развития динамических систем была разработана в Великобритании в середине 1990-х годов и является эволюционным развитием быстрой разработки приложений (RAD). Основная идея стандартная: при планировании в самом начале невозможно понимать всех тонкостей разработки, поэтому весь процесс — исследовательская работа.

В DSDM тоже присутствует деление на команды, в каждой из которых есть уполномоченный для принятия стратегических решений. В процессе могут участвовать все заинтересованные стороны: пользователи, разработчики, заказчики, руководители. Тестирование проводится на протяжении всего жизненного цикла.

FDD — процесс для обеспечения масштабируемости и повторяемости, при этом поощряющий творчество и инновации. Вот основные принципы:

  • Разработка каждого крупного проекта должна иметь системность.
  • Процессы должны быть простыми и проработанными.
  • Ценность и логичность процесса должна быть ясна каждому члену команды.
  • Предпочтение отдаётся коротким итеративным циклам разработки. Это уменьшает количество ошибок и позволяет быстрее наращивать функциональность.

FDD регламентирует время, которое должно затрачиваться на каждый из процессов. Организационной деятельности в цикле должна занимать не более 23−25%, в то время как на непосредственную разработку, сборку и тестирование функций необходимо тратить 75−77% времени.

JAD — это методология, нацеленная на максимальную занятость в разработке конечного пользователя. Происходит это посредством встреч и проведения совместных семинаров. JAD была придумана в 1970-х годах сотрудниками IBM и нацелена на бизнес в целом. Однако со временем данная концепция стала успешно применяться и для разработки программного обеспечения.

В отличие от подхода Waterfall, JAD приводит к сокращению времени разработки, большей удовлетворенности клиентов и экономии средств на изучении рынка. С другой стороны, это требует большой клиентской выборки и необходимости разработчиков работать не со строгими требованиями ТЗ, а с постоянно меняющимся мнением.

RAD — методология, которая во главу угла ставит скорость и удобство разработки. Одно из главных условий — использование языка быстрой разработки. Это название абстрактного языка программирования, с помощью которого программист способен решать задачи быстрее, чем с представителями третьего поколения (C / C ++, Pascal или Fortran). Вот ещё несколько пунктов концепции:

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

RAD предполагает использование целого комплекса инструментов помимо языка быстрой разработки: системы сбора требований, среды разработки, фреймворки, программы для группового общения, ПО для тестирования.

Scrum

Scrum — гибкий метод управления проектами, целью которого является повышение производительности труда в командах, ранее парализованных более тяжелыми методологическими процессами. В основе концепции лежат «спринты». Спринт — короткая итерация, строго ограниченная по времени (обычно 2−4 недели). В это время минимизируется длительность совещаний, но увеличивается их частота (они называются «схватками»).

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

Экстремальное программирование — возможность вести разработку в условиях постоянно меняющихся требований. Вот несколько признаков:

  • Игра в планирование. В начале проекта есть только приблизительный план, после каждой итерации его чёткость возрастает.
  • Высокая частота релизов. Новая версия продукта имеет незначительные изменения по сравнению с предыдущей, но время на выпуск при этом минимально.
  • Контакт с клиентом. Для удовлетворения требований конечной аудитории необходимо оперативное реагирование на замечания и пожелания.
  • Рефакторинг. Улучшение качества кода без уменьшения функциональности.
  • Стандарт выполнения кода. Или применяются общие правила, или разногласия в оформлении не подлежат обсуждению и критике.
  • Коллективная ответственность. Несмотря на то, что каждый член команды выполняет свой участок работ, за код в целом отвечает весь коллектив.

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

  • Поощрении сотрудников за успешную работу.
  • Изменении текущих задач только по мере необходимости или по запросу заказчика.
  • Строгом выполнении плана: всё, что сверх — считается потерями времени и ресурсов.
  • Внедрении общей концепции «Мыслить широко, делать мало, ошибаться быстро, учиться стремительно».

В условиях короткого дайджеста трудно раскрыть все преимущества и недостатки методологий, показать эффективные области применения. О наиболее актуальных на сегодняшний день концепциях мы поговорим отдельно. О каких именно? Оставляйте свои пожелания в комментариях.

Методология разработки софта — организация труда, включающая идеологические принципы, план, контроль над процессами, подход к сотрудникам. Выделим 12 видов:

  • Waterfall — традиционный подход.
  • RUP (Rational Unified Process) — рациональный.
  • Agile — общая методология гибкой разработки.
  • Crystal Clear — подход с уравниванием разработчиков в коллективе.
  • Spiral — спиральный метод.
  • DSDM (Dynamic Systems Development Model) — динамическая модель.
  • FDD (Feature Driven Development) — методология, рассматривающая будущие изменения.
  • JAD (Joint Application Development) — ориентированный на пользователя подход.
  • RAD (Rapid Application Development) — модель быстрой разработки.
  • Scrum — концепция работы в условиях сорванных сроков и идеологического кризиса.
  • XP (Extreme Programming) — экстремальная разработка в динамической среде.
  • LD (Lean Development) — метод, предполагающий бережное отношение ко всем участникам процесса.

Давайте попробуем разобраться, что скрывается за этими английскими названиями.

Waterfall

Модель Waterfall относится к классическому пониманию разработки ПО. Весь процесс является жестким и линейным, имеет четкие цели для каждого этапа, новая фаза начинается по завершению предыдущей, нет возврата назад. Преимущества водопадной методологии — децентрализация и строгий контроль над сроками и качеством исполнения.

На практике Waterfall часто не оправдывает ожиданий, поскольку игнорирует динамические изменения. Так, после тестирования очень сложно откатить процесс и заложить функции, не учтенные на стадии разработки. Waterfall неэффективен ещё и потому, что предполагает временные простои сотрудников в рамках одного проекта. Тестирование проводится только в конце разработки, хотя проблемы, найденные на этом этапе — это дорогостоящие исправления.

RUP — итеративный подход, который решает проблемы, которые есть у Waterfall. Чем хорош RUP:

  • Учитывает изменяющиеся требования. Как бы ни был хорош руководитель проекта, учесть всё в начале невозможно.
  • Интеграция функций происходит постепенно, то есть каждая «деталь» проходит цикл разработки, проверки и внедрения в проект. Как следствие, снижаются риски и стоимость производства.
  • Ранний выпуск продукта. ПО выходит с уменьшенной функциональностью, чтобы занять нишу на рынке и противостоять конкурентам, после чего обрастает «мясом».
  • Повторное использование. При наращивании функциональности проще выделить типовые решения, которые сократят разработку.
  • Постоянное обучение. Из-за частых итераций разработчики не имеют больших пауз между доработкой кода, поэтому профессиональный рост происходит плавно и безболезненно.
  • Постоянное улучшение продукта. Итерации позволяют оценить проект не только с точки зрения соответствия плану и ТЗ, но и найти пути увеличения эффективности и качества продукта.

Agile

Agile — метод гибкой разработки программного обеспечения, предполагающий большое количество итераций. Документ Agile Manifesto описывает 4 идей и 12 принципов гибкого подхода, коротко его можно описать всего двумя пунктами:

  • Неформальные отношения важнее задокументированных. То есть устные договоренности между сотрудниками, между заказчиком и исполнителем важнее всего, что отражено в планах, договорах и техническом задании. Иначе говоря, клиент всегда прав.
  • Работающий продукт — главная оценка прогресса. Важны не инструменты, решения, производительность и изящество, а тот факт, что все запланированные возможности реализованы.

Несмотря на недостатки, Agile стала фундаментальной концепцией для разработки ПО и нашла отражение в других методологиях, речь о которых пойдет далее.

Crystal Clear

Методология, созданная для небольших коллективов из 6−10 сотрудников. Также поддерживает принципы гибкой разработки, но имеет чуть больше конкретики. Основная идея, которая и заключена в названии — каждая команда является набором людей с разным уровнем знаний, разными умениями и опытом.

Именно поэтому нет универсального подхода для разработки софта, он должен определяться в процессе общения внутри группы. Там же назначаются роли, инструменты, стандарты. Затем группа принимается за единицу и те же самые вопросы решаются на уровень выше, пока иерархия не дойдет до заказчика.

Spiral

Модель спирального жизненного цикла — это сложная организация жизненного цикла ПО, которая фокусируется на раннем выявлении и уменьшении проектных рисков. Разработка начинается в небольшом масштабе, решаются локальные задачи, оцениваются риски и пути их уменьшения. Следующий шаг охватывает более комплексные задачи — следующий виток спирали.

Преимущество подхода не в увеличении скорости разработки, а в снижении уровня возникновения рисков. Успешность спирального метода зависит от добросовестного, внимательного и компетентного управления, а размер проекта не имеет принципиального значения.

Модель развития динамических систем была разработана в Великобритании в середине 1990-х годов и является эволюционным развитием быстрой разработки приложений (RAD). Основная идея стандартная: при планировании в самом начале невозможно понимать всех тонкостей разработки, поэтому весь процесс — исследовательская работа.

В DSDM тоже присутствует деление на команды, в каждой из которых есть уполномоченный для принятия стратегических решений. В процессе могут участвовать все заинтересованные стороны: пользователи, разработчики, заказчики, руководители. Тестирование проводится на протяжении всего жизненного цикла.

FDD — процесс для обеспечения масштабируемости и повторяемости, при этом поощряющий творчество и инновации. Вот основные принципы:

  • Разработка каждого крупного проекта должна иметь системность.
  • Процессы должны быть простыми и проработанными.
  • Ценность и логичность процесса должна быть ясна каждому члену команды.
  • Предпочтение отдаётся коротким итеративным циклам разработки. Это уменьшает количество ошибок и позволяет быстрее наращивать функциональность.

FDD регламентирует время, которое должно затрачиваться на каждый из процессов. Организационной деятельности в цикле должна занимать не более 23−25%, в то время как на непосредственную разработку, сборку и тестирование функций необходимо тратить 75−77% времени.

JAD — это методология, нацеленная на максимальную занятость в разработке конечного пользователя. Происходит это посредством встреч и проведения совместных семинаров. JAD была придумана в 1970-х годах сотрудниками IBM и нацелена на бизнес в целом. Однако со временем данная концепция стала успешно применяться и для разработки программного обеспечения.

В отличие от подхода Waterfall, JAD приводит к сокращению времени разработки, большей удовлетворенности клиентов и экономии средств на изучении рынка. С другой стороны, это требует большой клиентской выборки и необходимости разработчиков работать не со строгими требованиями ТЗ, а с постоянно меняющимся мнением.

RAD — методология, которая во главу угла ставит скорость и удобство разработки. Одно из главных условий — использование языка быстрой разработки. Это название абстрактного языка программирования, с помощью которого программист способен решать задачи быстрее, чем с представителями третьего поколения (C / C ++, Pascal или Fortran). Вот ещё несколько пунктов концепции:

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

RAD предполагает использование целого комплекса инструментов помимо языка быстрой разработки: системы сбора требований, среды разработки, фреймворки, программы для группового общения, ПО для тестирования.

Scrum

Scrum — гибкий метод управления проектами, целью которого является повышение производительности труда в командах, ранее парализованных более тяжелыми методологическими процессами. В основе концепции лежат «спринты». Спринт — короткая итерация, строго ограниченная по времени (обычно 2−4 недели). В это время минимизируется длительность совещаний, но увеличивается их частота (они называются «схватками»).

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

Экстремальное программирование — возможность вести разработку в условиях постоянно меняющихся требований. Вот несколько признаков:

  • Игра в планирование. В начале проекта есть только приблизительный план, после каждой итерации его чёткость возрастает.
  • Высокая частота релизов. Новая версия продукта имеет незначительные изменения по сравнению с предыдущей, но время на выпуск при этом минимально.
  • Контакт с клиентом. Для удовлетворения требований конечной аудитории необходимо оперативное реагирование на замечания и пожелания.
  • Рефакторинг. Улучшение качества кода без уменьшения функциональности.
  • Стандарт выполнения кода. Или применяются общие правила, или разногласия в оформлении не подлежат обсуждению и критике.
  • Коллективная ответственность. Несмотря на то, что каждый член команды выполняет свой участок работ, за код в целом отвечает весь коллектив.

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

  • Поощрении сотрудников за успешную работу.
  • Изменении текущих задач только по мере необходимости или по запросу заказчика.
  • Строгом выполнении плана: всё, что сверх — считается потерями времени и ресурсов.
  • Внедрении общей концепции «Мыслить широко, делать мало, ошибаться быстро, учиться стремительно».

В условиях короткого дайджеста трудно раскрыть все преимущества и недостатки методологий, показать эффективные области применения. О наиболее актуальных на сегодняшний день концепциях мы поговорим отдельно. О каких именно? Оставляйте свои пожелания в комментариях.

Основы разработки веб-приложений / Сэмми Пьюривал (2015) [PDF]

Лайфхаки для Windows. Все самое интересное

Благодаря этой книге вы усвоите основы создания веб-приложений, построив простое приложение с нуля с помощью HTML, javascript и других свободно предоставляемых инструментов. Это практическое руководство на реальных примерах обучает неопытных веб-разработчиков тому, как создавать пользовательский интерфейс, строить серверную часть, организовывать связь клиента и сервера, а также применять облачные сервисы для развертывания приложения. Каждая глава содержит практические задачи, полноценные примеры, а также ментальные модели процесса разработки. Эта книга поможет вам сделать первые шаги в создании веб-приложений, обеспечив глубокие знания по теме.

В начале 2008 года, через шесть лет после окончания школы и работы учителем на полставки, мне очень хотелось стать преподавателем компьютерных дисциплин на полный день. Очень быстро выяснилось, что место преподавателя найти нелегко, а получение хорошей работы зависит от удачи в большей степени, чем от чего-либо еще. Ну что ж, я поступил так, как поступает любой уважающий себя академик, столкнувшись с удручающим положением на академическом рынке труда, а именно: решил повысить свою конкурентоспособность с помощью изучения разработки веб-приложений. Это, конечно, звучит странно. Кроме всего прочего, к тому моменту я уже около девяти лет изучал компьютерные дисциплины и, более того, свыше шести лет учил студентов разрабатывать программное обеспечение (ПО). Разве я не должен был хорошо знать, как создавать веб-приложения? Похоже, что нет, так как существует определенный разрыв между практической ежедневной работой по разработке ПО и программированием как учебной дисциплиной, изучаемой в колледжах и университетах. Фактически мои знания по веб-разработке были ограничены HTML и в некоторой степени CSS, который я в то время изучал самостоятельно. К счастью, у меня было несколько друзей, которые активно работали в компьютерном мире, и большинство из них в то время обсуждало (относительно) новый фреймворк 1 , который назывался Ruby on Rails. Мне показалось, что это весьма под-
ходящая область для развития, так что я купил несколько книг по этой теме и принялся читать обучающие материалы в Интернете, чтобы побыстрее освоиться. А через несколько месяцев, пытаясь хоть чего-нибудь добиться на практике, я чуть было не сдался. Почему? Да потому, что большинство книг и учебных статей начиналось с предположения, что я уже умею создавать веб-приложения и делаю это на протяжении нескольких лет! А между тем, несмотря на мой солидный теоретический багаж по компьютерному программированию, оказалось, что все эти материалы слишком лаконичны и очень сложны для понимания. Например, выяснилось, что можно пройти несколько классов по компьютерным дисциплинам, ни разу не столкнувшись с шаблоном проектирования Model — View — Controller, а в некоторых книгах уже в первой главе предполагается, что вы прекрасно с ним знакомы. Тем не менее мне удалось изучить веб-разработку на уровне, достаточном для того, чтобы несколько раз провести консультации, которые оказались весьма кстати, пока я не получил должность преподавателя. Благодаря этому я заметил, что меня настолько увлекают практические стороны данной области, что я продолжил заниматься консультированием, одновременно работая учителем. Через несколько лет занятий тем и другим мне предложили вести мой первый класс по разработке веб-приложений в Университете Северной Каролины в Эшвилле. Изначально я планировал начать с Ruby on Rails, но, взявшись за новейшие книги и обучающие материалы по ней, выяснил, что они никак не улучшились за все эти годы. Нет, они были хорошим подспорьем для людей, которые отлично знают основы, но для студентов, которые у меня учились, они определенно не годились. Грустно, но неудивительно — академические книги по веб-разработке оказались еще хуже. Большинство из них содержали устаревшие концепции и не раскрывали важнейших тем, нужных для понимания платформ наподобие Ruby on Rails. Мне
даже случилось выступить рецензентом одной книги, переизданной в 2011 году и до сих пор описывающей верстку с помощью таблиц и тег ! Что ж, у меня не было другого выхода, кроме как создавать свой курс с нуля и писать все материалы самостоятельно. В то время я проводил небольшую консультационную работу по Node.js (адаптация JavaScript для стороны сервера) и подумал, что было бы интересно попробовать создать курс, обучающий одному и тому же языку и для клиента, и для сервера. Более того, я поставил себе цель дать моим студентам достаточно знаний для самостоятельного изучения Ruby on Rails, если они решат продолжить. Эта книга содержит большую часть материалов, созданных мной во время преподавания этого курса в Университете Северной Каролины в Эшвилле. В ней описано, как создать простое веб-приложение на основе базы данных с нуля, используя JavaScript. Сюда включены описание простейшего рабочего процесса (с использованием текстового редактора и системы контроля версий), основы технологий клиентской стороны (HTML, CSS, jQuery, Javascript), основы серверных технологий (Node.js, HTTP, базы данных), основы облачного развертывания (Cloud Foundry) и несколько примеров правильной практики написания кода (функции, MVC, DRY). Во время нашего пути мы исследуем фундаментальные основы языка JavaScript, научимся программировать, используя объекты и массивы, а также рассмотрим
ментальные модели, которые соответствуют этому типу разработки ПО.

Понравилась статья или книга? Поделись с друзями:

Все книги представленные на сайте WEB-Программист только в ознакомительных целях. Любое их использование Вами допускается только в ознакомительных целях. Если Вы планируете их использовать в дальнейшем, то Вы обязаны приобрести их у правообладателей. Администрация сайта не несет ответственность за их использование Вами

Мастер Йода рекомендует:  Знакомство с WP_Meta_Query и WP_Date_Query
Добавить комментарий
Автор книги
Год выхода: 2015
Жанр: Главная » Книги » JavaScript » Основы разработки веб-приложений / Сэмми Пьюривал (2015) [PDF]
Издательство: Питер
Язык: Русский
Статус: Для продвинутых программистов
Формат: pdf
Количество страниц: 272
Ссылка на скачивание Скачать
На сайт предоставил Июл 3, 2020 23:07 Andriy
Поделись книгой в социальных сетях