Введение
На протяжении последних нескольких лет SOA получает все более широкое распространение и развивается как основная архитектура организации для поддержки бизнес-преобразований, обеспечивая более тесную связь между бизнес-процессами и использованием IT. Об успешных реализациях SOA и препятствиях к внедрению и успешной реализации SOA было написано немало статей.
Пока организации определяли и претворяли в жизнь свои SOA-инициативы, недавний подъем массового компьютинга как среди профессиональных программистов, так и среди сотрудников, обладающих знаниями в области программирования, привел к возникновению другого подхода к разработке. В соответствии с этим подходом специалисты, лучше всего разбирающиеся в бизнес-проблеме, разрабатывают решения ускоренным методом без обычных непроизводительных издержек и формализма традиционных IT-методов. Новое поколение ситуативных приложений (SA), которые зачастую разрабатываются программистами-любителями итеративным и коллективным способом, сокращают традиционный жизненный цикл разработки на этапах редактирования-компиляции-тестирования-запуска. SA имеют потенциал для решения неотложных бизнес-проблем наиболее рентабельным способом благодаря тому, что они фиксируются на той части информационных систем, которая непосредственно влияет на конечных пользователей, и нацелены на области, которые в организации до сих пор считались слишком узкоспециализированными или низкоприоритетными.
В данной серии статей о ситуативных приложениях:
Часть 1:
- Изучаем шаблоны и технологии, которые внесли свою лепту в нынешний подъем разработки SA силами пользовательских сообществ в организациях, а также сравниваем и сопоставляем их с более традиционными корпоративными SOA-инициативами;
- Рассматриваем жизненные циклы, технологии и социальные аспекты каждой из архитектур;
- Откройте для себя, как можно использовать SA в организации для улучшения состояния корпоративного компьютинга.
Часть 2:
- Изучаем среду IBM SAE, которая была создана для того, чтобы предоставить отдельным пользователям и малым коллективам возможность создавать узконаправленные композитные приложения, способные удовлетворить неотложные бизнес-потребности;
- Знакомимся с тем, какие изменения необходимы организации для создания такой среды и какие проблемы необходимо разрешить при ее создании, включая доступ к корпоративным данным и вопросы конфиденциальности и безопасности;
- Изучаем некоторые упрощенные инструменты разработчика.
Часть 3:
- Анализируем несколько SA-приложений, отобранных таким образом, чтобы отобразить широкий диапазон бизнес- проблем, для решения которых используется этот вид приложений. Некоторые из них, как правило, используются сразу в нескольких направлениях бизнеса (lines of business, LOB) и представляют интерес для самых разных специалистов. Другие являются специфическими для конкретного направления бизнеса, однако имеют типичные проблемы, которые могут быть успешно решены средствами SA;
- Вы узнаете, какие затруднения преодолели авторы статьи с каждым из этих приложений, и получите архитектурное описание окончательных решений и использованных в них технологий, инструментов и методов;
- Кроме того, вы узнаете, какие материальные результаты мы получили, какие передовые методы разработали и какие уроки извлекли, работая с каждым из описанных SA.
Подъем в сфере ситуативных приложений, использующих сеть Интернет
|
Признанный в широких кругах термин ситуативные приложения относится к таким приложениям, которые создаются для разрешения конкретной ситуации, проблемы или задачи. Жизненный цикл разработки для этого типа приложений отличается от традиционной разработки SOA-решений специалистами по IT. SA-приложения обычно создаются нештатными программистами с использованием коротких, итеративных жизненных циклов разработки, которые часто измеряются днями или неделями, а не месяцами или годами. По мере изменений требований малого коллектива, использующего данное приложение, SA часто продолжает развиваться, вбирая в себя эти изменения. Существенные изменения в требованиях могут привести к полному отказу от используемого приложения, в некоторых случаях легче разработать новое приложение, чем изменять старое.
Идея компьютинга для конечного пользователя в организациях не нова. Разработка приложений непрофессиональными программистами при помощи IBM Lotus Notes, электронных таблиц Microsoft Excel в сочетании с Microsoft Access или других инструментов получила широкое распространение. Новое заключается в сочетании впечатляющего роста компьютинга силами пользовательских сообществ и общим повышением квалификации пользователей, появлением новых технологий и возрастающей потребности в динамичности бизнеса.
Появление таких технологий, как Asynchronous JavaScript + XML (Ajax), которые используют упрощенный доступ к данным в сети Интернет и полнофункциональные элементы управления пользовательского интерфейса (UI), в сочетании с архитектурным стилем Web-сервисов Representational State Transfer, REST (передача репрезентативных состояний) предоставляет удобную палитру для сборки высокоинтерактивных приложений на основе браузера.
Как и решения на базе SOA, SA-приложения редко разрабатываются с нуля, чаще они собираются из уже существующих компоновочных блоков (или запасных частей , как принято их называть). Наиболее известное подмножество SA - это гибридные приложения (Mashup). Обилие несложных интерфейсов прикладного программирования (API) и использование Web-компонентов в стиле Ajax (например, шаблоны проектирования Yahoo Developer Network и API, представленные на Web-сайте ProgrammableWeb.com) внесли свой вклад в рост популярности этого стиля разработки. В результате получили новую жизнь более старые Web-технологии, например JavaScript.
В таблице 1 перечислены факторы, которые внесли свою лепту в рост популярности ситуативных приложений (SA), использующих интернет, среди обладающих специальными знаниями в области программирования сотрудников и профессиональных разработчиков.
|
Фактор |
Вклад в рост популярности SA, использующих интернет |
|---|---|
|
Появление таких технологий и методов, как Ajax, REST, Atom и каналы новостей RSS |
Пользователи с небольшим багажом специальных знаний могут быстро создавать высокоинтерактивные приложения и осуществлять доступ к данным в простом, удобном формате. |
|
Всеобщая компьютерная грамотность |
Все большее количество пользователей может "программировать". |
|
Внедрение SOA |
Пользователям стало более удобно создавать и использовать решения из компоновочных блоков, созданных другими специалистами или пользователями. Разбиение функциональных возможностей унаследованного приложения на доступные для потребления сервисы делает их доступными для SA-приложений. |
|
Распространение компьютинга силами пользовательских сообществ коллективного творчества |
Разработчики и пользователи совместно используют компоновочные блоки и улучшают то, что создано их коллегами. |
|
Взаимопроникновение API и Web-компонентов |
Создатели SA-приложений имеют богатую палитру для выбора компоновочных блоков. |
|
Доступность большого количества гибридных приложений в публичных предметных областях |
Начинающие создатели SA-приложений учатся на примере приложений, написанных другими пользователями или разработчиками. |
|
Меньшие расходы на инфраструктуру |
SA не нуждаются в централизованном развертывании, можно использовать в качестве серверов компьютеры отдельных пользователей. |
|
Возрастающая потребность в динамичности бизнеса |
Направления бизнеса не могут ждать окончания длительных циклов разработки и бюджетных циклов, им необходимо немедленно решать свои бизнес-проблемы. |
Сравниваем SOA и SA
Одни специалисты говорят о натянутых отношениях между SOA и SA. Они отмечают, что SOA фокусируется на предоставлении надежных масштабируемых на уровне организации решений, тогда как SA представляют собой "доморощенные" приложения, масштабирование которых для удовлетворения бизнес- потребностей невозможно.
Другие отмечают синергизм в отношении этих двух технологий, как, например, в блоге, описывающем Web 2.0 (одним из аспектов которого и являются SA-приложения) как "реально самый масштабный образчик сервис-ориентированной архитектуры из всех возможных".
Наши наблюдения показали, что хотя SOA и SA имеют контрастирующие жизненные циклы и мотивацию разработки, различные шаблоны применения и используют совершенно разные технологии, у них есть немаловажные общие аспекты.
- Выделение функциональных возможностей унаследованных приложений и предоставление их в виде сервисов многократного использования;
- Программа как сервис;
- Компоновка или сборка нового решения из распределенных и комбинируемых компонентов многократного использования.
В то время как компоновочный центр SOA размещается на стороне сервера прозрачно для пользователя, многие SA используют сеть Интернет как платформу, часто фокусируясь на компоновке сервисов на архитектурном уровне потребителя, "на стекле ".
Жизненный цикл разработки и шаблоны применения
В отличие от разработки на базе SOA, которая часто занимает много месяцев и даже лет, при разработке SA-приложений предполагаются значительно более короткие жизненные циклы от идентификации потребностей до начала эффективной работы с приложением и получения экономического эффекта от повышения производительности и функциональности (показатель time-to-value). Такие решения могут разрешить некоторые неотложные бизнес-проблемы рентабельным способом-за счет привлечения той части информационных систем, которая напрямую касается сотрудников, обладающих специальными знаниями в области программирования,-и нацелены на те области, которые ранее считались слишком узкоспециализированными или низкоприоритетными, чтобы включать их в SOA-проект; с легкой руки Криса Андерсона (Chris Anderson) их иногда называют "хвостатыми решениями" (the Long Tail). При помощи этой парадигмы разработки информационные системы могут осуществить автоматизацию бизнес-областей, которые ранее считались неохваченными.
В отличие от корпоративной SOA разработки, SA можно рассматривать как движущиеся мишени и вечные бета-версии. Требования часто предлагаются и даже реализуются пользователями, которые не были первоначальными авторами или пользователями приложения; это свидетельствует о заинтересованности сообщества и психологии владельца, которые давно уже исчезли из традиционной контролируемой среды корпоративного приложения. В таблице 2 представлено подробное сравнение SOA и SA-приложений.
Таблица 2. Жизненные циклы разработки SOA и SA
|
SOA/Традиционная разработка информационных систем |
Ситуативные приложения (SA) | |
|---|---|---|
|
Time-to-value (продолжительность жизненного цикла) |
Многие месяцы или годы |
Дни или недели |
|
Фазы разработки |
Хорошо определены, впоследствии утверждены в виде плана-графика (хотя сроки часто нарушаются) |
Определенные фазы, вехи или графики отсутствуют Задача - достаточно хорошее решение неотложной проблемы |
|
Функциональные требования |
Определяются ограниченным количеством пользователей IT-специалистам необходимо "зафиксировать" требования, чтобы перейти к разработке При изменении бизнес-потребностей часто происходит деформация требований |
С изменением требований обычно изменяется и SA-приложение, учитывая изменения в бизнесе SA допускают непредусмотренные разработчиком варианты использования |
|
Нефункциональные требования |
Ресурсы, выделенные для решения вопросов производительности, доступности и безопасности Концентрация на этих и других нефункциональных требованиях (таких как масштабируемость и обслуживаемость) часто способствует разработке надежных решений |
Требования масштабируемости, удобства обслуживания, доступности и т. п. почти (или полностью) не принимаются в расчет. |
|
Тестирование |
IT-специалисты и несколько привлеченных пользователей |
Пользователи, в процессе реального использования приложения |
|
Финансирование |
Часто совпадает с ежегодным планированием расходов на IT Требует утвержденных бюджетных ассигнований |
Формальное выделение средств отсутствует Разрабатываются и выполняются под наблюдением IT-специалистов организации |
Социальный аспект
Укоренившееся различие между SOA и SA-приложениями заключается в социальном аспекте, принципе, который многими признается центральным для движения к Web 2.0 (который может быть выгодным и для централизованно управляемой SOA). Ситуативные приложения развиваются благодаря обратной связи от пользовательских сообществ, и само их существование зависит от этой архитектуры участия . В таблице 3 приводится сравнение социальных аспектов
Таблица 3. Социальный аспект -- различия между SOA и SA-приложениями
|
SOA |
Ситуативные приложения (SA) | |
|---|---|---|
|
Заинтересованные лица |
Руководители направлений бизнеса / IT-специалисты организации |
Отдельные разработчики / самопроизвольно сформировавшиеся небольшие коллективы, сообщества пользователей, которые собрались для разработки SA |
|
Целевые пользователи |
Крупные, неспециализированные группы |
Известный отдельный пользователь (часто создатель приложения) или небольшой коллектив, привлекающий пользователей, для которых данное приложение специально не разрабатывалось |
|
Механизм руководства |
Централизованный, формальный |
Обычные люди, члены пользовательского сообщества |
|
Развитие |
Управляется по вертикали сверху вниз, проводится централизованно, зависит от наличия финансирования |
Естественное, постепенное, на основе обратной связи и участия пользователей |
Создатели SA говорят, что испытывают глубокое удовлетворение от результатов своей работы и чувствуют, что все "под контролем". Маркетинговое исследование IBM показывает, что пользователи SA-приложений рассматривают их как особенно важные. Больше половины пользователей считают их "критически важными для бизнеса" и дают им оценку "очень важно" для успеха их личной повседневной деятельности, а также деятельности подразделений и компаний в целом (из отчета "Changing the corporate IT development model: Tapping the power of grassroots computing" (Изменение корпоративной модели разработки информационных систем: эффективное использование массового компьютинга) (октябрь 2007 г.).
Технологии
А теперь давайте рассмотрим технологические изменения (перечисленные в таблице 4), которые способствовали повышению роли SA-приложений.
Концентрация SA на использовании опыта пользователей и высокоинтерактивных клиентских приложений полностью соответствует тому, какие технологии и инструменты в ней применяются. Ajax, благодаря использованию эффективных элементов управления UI и доступа к данным, размещенным в сети Интернет, делает возможным значительное улучшение реактивности и производительности Web-приложений. Ajax достигает высокой интерактивности благодаря получению от сервера отдельных фрагментов страницы и обновления их в браузере.
Таблица 4. Особенности технологий SOA и SA
|
SOA |
Ситуативные приложения (SA) | |
|---|---|---|
|
Зрелость |
Высокоразвитые, проверенные технологии |
Часто используются менее зрелые и развивающиеся технологии |
|
Предпочитаемые технологии, архитектурные модели и стандарты |
Язык описания Web-сервисов (Web Services Description Language, WSDL), WS-*, SOAP, язык исполнения бизнес-процессов (Business Process Execution Language, BPEL), платформа Java™ 2 Platform, Enterprise Edition (J2EE), XML |
Ajax, REST, Atom, RSS, нотация объектов JavaScript (JavaScript Object Notation, JSON), XML, микроформаты, Flash, Ruby on Rails, PHP, JavaScript |
|
Интерфейс пользователя |
Не имеет значения |
Предпочтение отдается стандарту полнофункциональных интернет-приложений Rich Internet Applications (RIA) через использование таких технологий, как Ajax, Adobe Flex, Adobe Integrated Runtime (AIR), OpenLaszlo и XAML Browser Application (XBAP), а также интеграции шаблонов "at the glass" (на стекле) |
|
Инструменты |
Автономная интегрированная среда разработки (IDE) |
На базе браузера |
Архитектурный стиль REST, использующий унифицированные идентификаторы ресурса Uniform Resource Identifiers (URI) для идентификации Web-ресурсов, делает возможной одинаковую доступность таких ресурсов из браузеров, мобильных устройств, серверных приложений, ссылки из сообщений электронной почты и закладки, благодаря чему этот стиль программирования становится привлекательным для широкого диапазона клиентских приложений. Поскольку сервисы в стиле REST могут использовать инфраструктуру Web для кэширования, они могут достигать более короткого времени отклика. Учитывая, что в REST не нужно обслуживать режим коммуникации, вы можете повысить масштабируемость сервера, используя этот стиль-можно использовать для обработки первого и последующих запросов разные серверы
Применимость SA в организации
Сообщества Web 2.0, сформировавшиеся в организации, часто считают, что деятельность IT-специалистов, отвечающих за реализацию SOA, является неэффективной и не может удовлетворить бизнес-потребности. Хотя многие энтузиасты SA считают SOA тяжеловесной, между этими двумя технологиями существует ряд замечательных сходств (как было показано ранее в данной статье).
Разработка и SOA, и SA-приложений часто мотивируется желанием привнести динамичность в бизнес. IT-специалисты не должны игнорировать комплементарный характер SOA и SA-приложений; SA-приложения вносят важные новшества, из которых SOA может извлечь выгоду, а именно:
- Концентрация на пользователе и участие пользователей в разработке;
- Методы создания высокоинтерактивных приложений;
- Возможность создавать решения для тех областей, которые раньше считались слишком узкоспециализированными.
Преимущества SA-приложений
Используя преимущества огромного потенциала разработки силами пользовательских сообществ в организации, SA могут сделать преимущества внедрившей SOA организации более всеобъемлющими. Эти возможности впечатляют, как показано ниже.
SA помогают в ведении бизнеса посредством:
- Внедрения инноваций на уровне подразделений и отдельных пользователей - сотрудники, обладающие специальными знаниями в области программирования, могут оперативно реагировать на ситуацию в бизнесе;
- Предотвращения конфликтов из-за недопонимания и различного толкования требований - бизнес-пользователями и IT-специалистами;
- Повышения трудовой дисциплины благодаря более эффективным решениям и полномочиям.
SA улучшают бизнес-решения посредством:
- Создания приложений, лучше отвечающих задачам направлений бизнеса;
- Удовлетворения краткосрочных потребностей сотрудников, обладающих специальными знаниями в области IT;
- Учета требований сегмента рынка (разработки "хвостатых" решений, The Long Tail);
- Компоновки тактических решений на базе SA при помощи всего портфеля IT;
- Концентрации на нуждах конечного пользователя и формировании высокой квалификации у пользователей;
- Пополнение портфелей данных IT уникальными, трудно воссоздаваемыми данными, созданными отдельными пользователями и небольшими коллективами; эти данные становятся более эффективными и "чистыми" по мере использования их все большим количеством сотрудников.
SA способствуют повышению индекса ROI посредством:
- Сокращения жизненных циклов разработки;
- Устранения формальной деятельности по разработке в тех ситуациях, где в ней нет необходимости; это способствует повышению производительности;
- Снижение затрат на процесс разработки в целом;
- Создание приложений, которые до сих пор не были написаны, потому что считались слишком узкоспециализированными.
Проблемы SA-приложений
В то же время введение SA в корпоративную вычислительную среду ставит новые проблемы перед подразделениями по информационным технологиям; эти проблемы перечислены ниже.
Отдел по информационным технологиям может рассматривать SA-приложения как "контролируемый" хаос, поскольку:
- На них не выделяются средства, SA-приложения разрабатываются и выполняются под присмотром централизованного отдела по информационным технологиям;
- Архитектура участия включает пользователей в число соразработчиков;
- Приходится учитывать спонтанность разработки и развитие приложений, постоянно находящихся в состоянии бета-версий;
- Мало внимания уделяется нефункциональным требованиям, таким как масштабируемость, доступность и обслуживаемость;
- Не существует передовых методов внедрения этих приложений в организации.
Интеграция SA-приложений выходит на передний план, поскольку:
- Управление переносится с приложений на хорошо детализированные сервисы и каналы данных;
- Внутренние и внешние сервисы и каналы данных смешиваются в периметре корпоративных межсетевых экранов;
- Приложения совместно используются в глобальном масштабе;
- Направления бизнеса должны использовать Интернет как платформу для ведения дел.
Управление ситуативными и корпоративными приложениями вызывает сложности из-за:
- Наличия нескольких сред выполнения и разработки, а именно: J2EE; Linux, Apache, MySQL, PHP/Perl (LAMP) и Microsoft .NET;
- Все более сложного управления всей системой в смешанной среде (например, осуществление мониторинга, анализа событий, выявления основных причин и управления обновлениями).
SA вызывают проблемы с обеспечением безопасности, конфиденциальности и целостности данных, в том числе:
- Корпоративные данные можно рассматривать как стимул; предоставление в общее пользование источников корпоративных данных - это длительный и сложный процесс, в который вовлекается много заинтересованных лиц;
- Владение уникальными данными, сгенерированными направлениями бизнеса и отдельными пользователями, возникает вопрос о бережном отношении к информации;
- Случаи непредусмотренного использования SA-приложений (формальный контроль или обучение и рекомендации).
Заключение
Внедрение SA-технологии в организации требует дополнительной гибкости от существующей инфраструктуры организации. SOA может способствовать смягчению некоторых проблем, например путем многократного использования сервисов и инфраструктуры, созданной SOA-инициативами, для управления, функционирования и руководства.
Хотя многие IT-подразделения скептически относятся к полезности SA для корпоративного компьютинга или остерегаются использовать разработанные за пределами организации API в периметре своих межсетевых экранов, дирекция по информационным технологиям IBM приняла решение разрешить использовать SA в своих организациях. Чтобы лучше разобраться в проблемах и возможностях внедрения разработки в рамках сообщества, дирекция по информационным технологиям IBM разработала инициативу, которая получила название среды ситуативных приложений (Situational Applications Environment, SAE). На рисунке 1 изображена схема динамического лабораторного эксперимента по изучению SAE и выработке передовых методов.
Рисунок 1. Концепция SAE в IBM
Следите за выходом части 2 данной серии статей, в которой описываются архитектура и уроки, полученные при создании описанной среды SAE. Ниже перечислены ранние преимущества для бизнеса, которые мы наблюдали при изучении данной темы:
- Наблюдалась самоорганизация пользовательских сообществ вокруг интересующих их общих задач бизнеса, тем самым повышалась многократность использования ресурсов и решений;
- В некоторые приложения были включены дополнительные и улучшенные функциональные возможности, которые первоначально не предусматривались их создателями. Посредством комментариев и непосредственного участия в разработке пользователи делают приложения более полезными для себя и других;
- Бизнес-потребности пользователей вынуждают IT-подразделения предоставлять в общий доступ корпоративные источники данных как потребляемые сервисы, что позволяет обеспечить более избирательный доступ к данным;
- Ситуативные приложения позволяют руководству отдельных направлений бизнеса лучше контролировать принятие решений по поводу того, какие проекты выполнять и как именно : при помощи SA-приложений или в процессе традиционной разработки.
Использование SA-разработки вместе с SOA в корпоративном компьютинге может полностью изменить роль IT-специалистов и превратить их из разработчиков решений в специалистов по внедрению решений. Мы полагаем, что это необходимо для того, чтобы IT-специалисты сохранили свои позиции в организации.