Содержание к диссертации
Введение
Глава 1. Обзор по мобильной коммерции 14
1.1. Критический анализ состояния мобильной коммерции в мире 14
1.1.1. Эволюция рынка мобильных платежей: общие тенденции 14
1.1.2. Региональные аспекты развития рынка мобильных платежей 19
1.2. Анализ условий развития платежных систем для сетей сотовой связи в России. Анализ нормативно-правовой базы, анализ схем осуществления платежных операций с помощью мобильного терминала 27
1.3. Формирование требований к платежной системе 32
1.4. Выводы по первой главе 36
Глава 2. Архитектура Электронной Платежной Платформы для Сетей сотовой Связи (ЭППСС) 37
2.1. Бизнес-архитектура 37
2.1.1. Основные бизнес-модели 37
2.1.2. Основные модели бизнес-процессов в ЭППСС 42
2.2. Программная архитектура 46
2.3. Основные компоненты программной архитектуры 51
2.3.1. Процессинговый центр 51
2.3.2. Центр управления счетами 53
2.3.3. ПО Пользователя 54
2.3.4. ПО Продавца 56
2.3.5. ПО Оператора связи 57
2.3.6. Аппаратная структура ЭППСС 59
2.4. Выводы по второй главе 60
Глава 3. Инструменты разработки сервисов 62
3.1. Требования к мобильному сервису нового поколения 62
3.2. Инструментальная среда 66
3.2.1. Формальная постановка задачи проектирования мобильных сервисов 66
3.2.2. Интеллектуальный подход к решению задачи проектирования мобильных сервисов 68
3.2.3. Представление архитектуры мобильного сервиса в форме функциональной цепочки 71
3.2.4. Принцип действия и состав инструментальной среды 74
3.2.5. Система вопросов, управляющих процессом формирования мобильного сервиса в инструментальной среде 80
3.2.6. Оценка архитектуры инструментальной среды 83
3.3. Использование способов локального взаимодействия 86
3.3.1. Характеристики технологии NFC 86
3.3.2. Классификация NFC-приложений для мобильного телефона 88
3.3.3. Программные средства, обеспечивающие работу с NFC в мобильном телефоне 89
3.3.4. Сервис электронной продажи билетов с использованием технологии NFC 91
3.4. Типовой сервис продажи электронных билетов 94
3.4.1. Принцип работы и характеристики демонстрационного сервиса электронной продажи билетов 94
3.4.2. Реализация основных программных модулей сервиса 99
3.4.3. Автоматизация процесса создания сервиса посредством инструментальной среды 104
3.5. Выводы по третьей главе 112
Глава 4. Исследование производительности систем по предоставлению мобильных услуг 114
4.1. Исследование производительности ЭППСС 114
4.1.1. Задачи исследования производительности; 114
4.1.2. Экспериментальное изучение производительности (тестирование) 118
4.1.3. Моделирование производительности 123
4.1.4. Моделирование на основе анализа структуры кода 131
4.1.5. Сравнительный анализ методов исследования производительности 134
4.2. Тестирование программного комплекса ЭППСС 135
4.2.1. Постановка задачи 135
4.2.2. Организация экспериментального стенда 136
4.2.3. Анализ условий проведения эксперимента 139
4.2.4. Воспроизводимость результатов 143
4.2.5. Исследование влияния на производительность конфигурации RAID-массива 145
4.3. Анализ характеристик производительности мобильного сервиса на основе технологии NFC как обслуживающей системы 151
4.3.1. Описание модели мобильного NFC сервиса как обслуживающей системы 151
4.3.2. Измерение нагрузки и параметризация входных данных системы 157
4.3.3. Измерение производительности системы 159
4.3.4. Модификационный анализ используемой модели 164
4.4. Выводы по четвертой главе 175
Заключение 176
Список литературы 177
Приложение №1 185
Приложение №2 186
- Региональные аспекты развития рынка мобильных платежей
- Принцип действия и состав инструментальной среды
- Экспериментальное изучение производительности (тестирование)
- Модификационный анализ используемой модели
Введение к работе
Актуальность темы. Высокая степень проникновения (138%1 в крупных городах, по данным на июнь 2009 г.) и доступность услуг сотовой связи в России на настоящий момент диссонирует с составом и качеством предлагаемых мобильных сервисов и контента. Начиная с 2005 г. это сказывается перенасыщением рынка мобильного контента и стагнацией доходов операторов связи и провайдеров мобильных услуг. Причиной существующего дисбаланса между высоким уровнем развития технологий сотовой связи и низким уровнем существующих мобильных сервисов является тот факт, что возможности провайдеров по предоставлению мобильных услуг нового поколения (мобильное телевидение, электронные билеты и пр.) не обеспечены соответствующими технологиями их тарификации и оплаты. Как следствие, большинство провайдеров контента предоставляют свои услуги по стандартным схемам тарификации с использованием биллинга оператора связи или посредством так называемых агре-гаторов. В общем случае это приводит к существенному повышению себестоимости услуги, її кроме того, не обеспечивает легитимной финансово-юридической схемы взаимодействия с потребителем. Использование указанных выше схем определяет экстенсивный характер развития мобильных услуг в России, характеризуемый ориентированностью предоставляемых сервисов на конкретные технологические платформы операторов связи и агрегаторов.
Отчасти переход к платформенно-независимым сервисам возможен в сетях 4G (например, основанных на стандарте WiMAX2) путем обеспечения потребителю возможности полнофункционального использования сервисов в Интернет и их оплаты посредством уже существующих систем электронных платежей. Однако такой подход существенно ограничивает возможности персона-лизации абонента сотовой связи, основанные на механизмах идентификации по учетной записи оператора (что является принципиальным достоинством мобильных сервисов в сетях стандарта GSM и CDMA).
Выходом из сложившейся ситуации является внедрение электронной платежной платформы в сетях сотовой связи (ЭППСС), независимой от операторов связи и реализующей адекватные способы оплаты мобильных услуг на основе технологии электронных платежей в соответствии с действующим законодательством Российской Федерации. Такая платформа должна обеспечить поддержку мобильных сервисов, предполагающих непосредственное взаимодействие потребителя и провайдера услуги, в которой оператор сотовой связи предоставляет только механизмы идентификации и транспортную среду. Это позволит устранить ограничения, налагаемые технологическими платформами операторов связи и агрегаторами, и расширить рынок мобильных услуг за счет привлечения независимых провайдеров, что является актуальным для развития мобильной коммерции в России в целом.
С учетом неактивных SIM-карт. 2 Торговая марка Yota.
Предметом исследования являются: программная архитектура ЭППСС, архитектура типового мобильного сервиса с организацией оплаты на основе ЭППСС и технологический программный инструментарий для разработки типовых мобильных сервисов.
Целью работы является решение задачи, имеющей существенное значение для организации предоставления массовых мобильных он-лайн услуг нового поколения, а именно: обоснование, проектирование и разработка математического и программного обеспечения ЭППСС, позволяющего использовать технологии злекгронных платежей в сетях сотовой связи, и создание технологической инструментальной среды для автоматизации проектирования и разработки мобильных сервисов на основе ЭППСС.
Задачи исследования. Достижение поставленной цели подразумевает решение следующих задач:
Формирование системы требований к ЭППСС для использования в сетях сотовой связи на основе критического анализа существующей нормативно-правовой базы в области электронных платежей в Российской Федерации.
Обоснование бизнес-архитектуры ЭППСС и проектирование на ее основе высокоуровневой и низкоуровневой программной архитектуры ЭППСС.
Обоснование и разработка инструментальной технологической среды для создания мобильных он-лайн сервисов на основе ЭППСС.
Исследование характеристик производительности мобильных он-лайн сервисов на основе ЭППСС посредством аналитических расчетов, имитационного моделирования и экспериментов на тестовом полигоне.
Методы исследования включают в себя методы системного анализа и теории систем, методы инженерии программного обеспечения, методы анализа систем массового обслуживания (теории очередей), методы теории вероятностей и математической статистики.
Научную новизну результатов работы определяют:
Предметно-ориентированный подход к проектированию архитектуры программного обеспечения ЭППСС, отражающий специфику действующего в Российской Федерации нормативно-правового регулирования в финансово-экономической сфере.
Двухзвенная схема организации типового мобильного он-лайн сервиса, обеспечивающая непосредственное взаимодействие пользователя с провайдером услуги посредством ЭППСС, не вовлекая оператора связи в процесс осуществления платежных операций.
Практическую ценность работы составляют:
Каталог требований и условий функционирования ЭППСС, обеспечивающих легитимность платежных операций согласно нормативно-правовой базе Российской Федерации.
Программная архитектура ЭППСС и описание основных ее компонентов в форме комплекта программной документации, пригодного для тиражирования и производства.
Программное средство - инструментальная технологическая Среда для авто
матизации процесса разработки мобильных он-лайн сервисов в рамках пред
ложенной архитектуры ЭППСС.
На защиту выносятся:
Предметно-ориентированная программная архитектура ЭППСС, отражающая технологический процесс осуществления электронных платежей согласно действующему законодательству Российской Федерации в финансово-экономической сфере.
Иерархическая технология автоматизации процесса разработки типовых мобильных сервисов в рамках ЭППСС посредством интеллектуальной инструментальной среды.
Достоверность научных результатов и выводов подтверждается строгостью наложенных ограничений предметной области, проведенным анализом характеристик ЭППСС как критической системы, апостериорным исследованием производительности мобильных сервисов на основе ЭППСС, а также практическим использованием разработанных методов и средств при создании систем электронных платежей на основе технологии ПэйКэш.
Внедрение результатов работы. Результаты работы нашли свое применение при выполнении проекта «Инструментальная технологическая среда для создания массовых мобильных он-лайн сервисов нового поколения» (НИР 2008-4-1.4-18-01-022) направления 1.4 «Генерация знаний» ФЦП «Исследования и разработки по приоритетным направлениям развития научно-технологического комплекса России на 2007-2012 годы» В процессе работы получено два свидетельства о государственной регистрации программ для ЭВМ: «Инструментальная технологическая среда для создания мобильных он-лайн сервисов нового поколения» (свидетельство № 2009610628), «Сервис продажи электронных билетов» (свидетельство № 2009611398). Результаты работ внедрены в производственную деятельность ОАО «ВымпелКом» (услуга «Мобильный платеж»), ОАО «Санкт-Петербургский акционерный коммерческий банк «Таврический» и ОАО «МОБИ.Деньги».
Апробация работы. Изложенные в диссертации результаты обсуждались на международных и российских научно-технических конференциях: VI Международная конференция «Подвижная связь в России. Правила оказания услуг подвижной связи» (2005 г., Москва), 5-ая Международная конференция «Мобильная связь в России. Тенденции и перспективы развития» (2006 г., Москва), 2-ая Международная конференция «Мобильная коммерция и платежи» (2006 г., Москва), 9-й Международный экономический форум (2005 г., Санкт-Петербург), «Мобильная коммерция - 2008» (2008 г., Москва).
Публикации. По теме диссертации опубликовано 9 печатных работ (из них 6 - в изданиях из перечня ведущих рецензируемых научных журналов и изданий, рекомендованных ВАК РФ).
Личный вклад автора в работах, выполненных в соавторстве, заключается в проведении анализа состояния отрасли мобильной коммерции в мире, проведении анализа условий для создания ЭППСС в России и формировании требований к ЭППСС, определяющих ее высокоуровневую программную архитек-
туру, разработке концепции инструментальной технологической среды для создания мобильных он-лайн сервисов, формировании подходов к проектированию мобильных сервисов, участию в процессе проектирования и постановке поверочных расчетов; в диссертацию включены результаты, которые соответствуют личному участию автора.
Структура и объем работы. Диссертация состоит из введения, четырех глав, заключения и списка литературы (85 наименований). Содержит 187 с. текста, включая 53 рис. и 39 табл.
Региональные аспекты развития рынка мобильных платежей
В настоящее время в мире существуют два крупнейших региональных рынка мобильных услуг. Это Западная Европа (955 млн. долларов в год) и Азиатский Восток (702 млн. долларов в год) [16].
В Западной Европе пионерами в области мобильных услуг являются страны Скандинавии [18]. Крупнейшие скандинавские операторы Radiolinja, Telenor и TeliaSonera продвигают системы оплаты товаров и услуг с помощью SMS, в частности оплату парковки автомобилей. В настоящее время одной из самых развитых (с точки зрения предоставления мобильных услуг) европейских стран является Австрия. Лидером и главным инициатором продвижения этих сервисов в Австрии является оператор Mobilkom Austria [19, 20].
В восточной Азии основную часть рынка мобильных сервисов формируют Япония и Южная Корея. Самым крупным и известным японским проектом по предоставлению мобильных услуг является Felica Mobile — продукт совместной разработки Sony, NTT DoCoMo и East Japan Railway. Felica Mobile, фактически, стала в Японии стандартом бесконтактного интерфейса, используемого в мобильных телефонах. NTT DoCoMo [21] разработал концепцию мобильного кошелька Osaifu-Keitay (в переводе с японского «мобильный кошелек») на основе интегрированного в телефон чипа Felica и начал распространение таких телефонных аппаратов в 2004 году. Телефоны с поддежкой функции Osaifu-Keitay в течении двух лет приобрели 24% абонентов NTT DoCoMo. Основной услугой Felica Mobile является оплата транспорта в системе Tokyo Transit. Другим крупным сервисом, разработанным в рамках данного проекта, является оплата железнодорожных билетов в системе Mobile Suica. К концу 2007 года в Японии имелось более 40 миллионов мобильных телефонов, приспособленных для осуществления бесконтактных платежей. По прогнозам (Sony) в 2008 году количество таких телефонов составит 50 миллионов и, соответственно, 55% от общего их количества [22].
Сопоставляя успешные коммерческие проекты по предоставлению мобильных услуг в Западной Европе и восточной Азии, видно, что успех внедрения и продвижения мобильных сервисов определяется, в первую очередь, выбором рыночной модели, который, в свою очередь, диктуется стилем финансового регулирования, принятого в данном государстве. Это связано с тем, что мобильный сервис (интерпретируемый как платная услуга посредством мобильной связи) предусматривает «дистанционную» идентификацию абонента и использование так называемых «электронных денег». Таким образом, мобильных сервисов вывод на рынок непосредственно увязан с легальной системой оплаты мобильных услуг. Успешность продвижения мобильных услуг в Австрии, Финляндии и Японии в первую очередь связана с возможностью реализации адекватных систем мобильных коммерции, определяемых спецификой финансового регулирования в этих странах.
Следует отметить, что развитие систем мобильных платежных систем в различных странах идет неравномерно. В 2005 г. компания Arthur D. Little опубликовала рейтинг стран мира по степени внедрения и использования мобильных платёжных систем [23]. В каждой стране оценка сектора расчётно-платёжных и финансовых услуг в сети подвижной связи проводилась по нескольким критериям: широта спектра услуг в области мобильной коммерции, охват участников всей цепочки по созданию услуг с добавленной стоимостью, чёткость и ясность стратегии участников рынка мобильной коммерции. Согласно исследованиям Arthur D. Little, лидирующие позиции в сфере мобильной коммерции среди европейских стран занимает Австрия, в Азии -Корея, Сингапур и Япония (рис.2). В Австрии отмечен наиболее широкий спектр расчётно-платёжных и финансовых услуг в сети подвижной связи.
Следует отметить, что если два-три года назад проекты мобильной коммерции были сосредоточены в развитых странах, то сейчас практически все страны, включая развивающиеся (страны Азии, Африки, Латинской Америки), активно работают в этом направлении. В частности, Всемирная Ассоциация GSM на примере ряда стран продемонстрировала, что после введения в действия систем мобильных платежей, ARPU операторов связи становится в среднем в полтора-два раза выше [24]. Специалисты Edgar, Dunn & Company отмечают также, что в ближайшей перспективе Африка станет регионом с одним из наиболее быстро развивающимся рынком м-платежей.
Рынок м-платежей в США и Латинской Америке до сих пор находится в зачаточном состоянии. Отметим, что в США, в стране с самой высокой в мире степенью распространения систем платежей посредством кредитных карт, велика вероятность перевода части этой отрасли на м-платежи при условии появления приемлемых технических решений [25].
Среди лидирующих в области м-платежей стран можно перечислить Сингапур, Южную Корею, Японию, Финляндию, Норвегию, Австрию, Испанию и Бельгию. Успех внедрения и продвижения мобильных услуг в этих странах определяется, в первую очередь, выбором рыночной модели, который, в свою очередь, диктуется стилем финансового регулирования, принятого в данном государстве. Это связано с тем, что мобильный сервис (интерпретируемый как платная услуга посредством мобильной связи) предусматривает «дистанционную» идентификацию абонента и использование так называемых «электронных денег». Таким образом, вывод мобильных сервисов на рынок непосредственно увязан с легальной системой оплаты мобильных услуг. Успешность продвижения мобильных услуг в Австрии, Финляндии и Японии в первую очередь связана с возможностью реализации адекватных систем мобильных коммерции, определяемых спецификой финансового регулирования в этих странах.
В появившемся в 2004 г. обзоре «Исследование проблем провайдеров мобильного контента», подготовленном американским поставщиком решений для мобильной коммерции Qpass, отмечается, что, по мнению 85% поставщиков мобильного контента, Операторы страдают от «плохих или неадекватных систем мобильной коммерции». Более того: 70% опрошенных контент-провайдеров назвали сложившуюся ситуацию «неприемлемой».
В обзоре была представлена несколько иная точка зрения на развитие «мобильных платежей в США и Европе». Поставщики наиболее популярного сегодня (как в Старом, так и в Новом Свете) мобильного контента — игр, мелодий звонков и информации - упрекают Операторов мобильной связи Европы за их неспособность организовать адекватную систему оплаты потребления мобильного контента. Американские же мобильные Операторы, наоборот, медленно начав мобильную «революцию», быстро обгоняют своих европейских коллег в плане внедрения гибких систем мобильных платежей за контент. В США проще продвигать новые технологии, потому что там меньше языков, меньше Операторов связи, меньше терминалов и меньше биллинговых систем, чем в Европе.
Технологическая цепочка м-платежей обычно очень сложна и включает большое количество участников, которые должны взаимодействовать, чтобы иметь возможность предоставить соответствующие услуги потребителям. Среди таких участников - мобильные Операторы, государственные регуляторы, банки, платежные системы кредитных карт, поставщики контента, товаров и услуг, провайдеры платежей, разработчики, производители программного обеспечения и терминального оборудования. Все они имеют разные интересы, занимают различные позиции на своих рынках и по-разному относятся к перспективам развития м-платежей, к новым моделям сотрудничества. Однако общей тенденцией сейчас становится стремление к партнерству, желание объединить усилия в построении систем мобильных расчетов, в создании стандартных технологий, в наращивании широкой сети торговцев, которые готовы пойти навстречу потребителям и предоставить им возможность платить за услуги и товары посредством мобильных телефонов.
В большинстве стран Операторы мобильных сетей имеют преимущества в том, чтобы занять лидирующие позиции в создании объединений заинтересованных компаний и тем самым достичь успеха при внедрении услуг м-платежей. Тем не менее, специалисты Arthur D. Little выявили несколько различных рыночных моделей внедрения мобильных платежей, возникших в исследованных странах:
1) На рынках стран с либеральным режимом регулированием финансовых услуг, как правило, Операторы мобильной связи лидируют в развитии м-платежей. В качестве примера здесь можно привести Финляндию, Австрию и Японию. 2) На рынках с более строгим финансовым регулированием руководство на себя берут финансовые организации, активно сотрудничая при этом с Операторами мобильной связи. Подобную ситуацию можно наблюдать на примере Испании и Бельгии.
3) На рынках с самым жестким финансовым регулированием, как, например, в Соединенных Штатах, Операторам мобильной связи не разрешается принимать платежи в пользу третьих лиц, а финансовые институты в силу ряда причин связаны государством множеством обязательств и ограничений. На этих рынках зарождается модель, где инициативу берут на себя предприятия смежных отраслей. Это могут быть сети розничных продавцов, провайдеры платежных услуг или разработчики программных продуктов.
4) В Сингапуре реализована модель построения м-платежей под управлением государства. Здесь правительство вкладывало время и деньги в объединение участников системы мобильных платежей [26].
5) Последняя рассматриваемая модель - «анархическая модель». В ней участники следуют каждый своим путем, предлагая собственные решения для отдельных небольших секторов рынка, почти не кооперируясь между собой. Такую картину можно наблюдать на некоторых рынках, где м-платежи все еще находятся в зачаточном состоянии, например, в Германии и Англии.
Принцип действия и состав инструментальной среды
Подход к проектированию мобильных сервисов позволяет обосновать высокоуровневую архитектуру инструментальной оболочки. Инструментальная оболочка включает в себя набор программных средств, необходимых для обеспечения процессов спецификации требований, проектирования и программной реализации мобильных сервисов. При этом инструментальная оболочка включает в себя как средства, реализующие интеллектуальный подход к проектированию, так и технологический инструментарий, необходимый для упрощения самого процесса разработки.
Инструментарий для разработки мобильных сервисов нового поколения, в свете концепции раздела 3.1.2, представляет собой визуальную оболочку с подгружаемыми (или встраиваемыми) «виджетами» для типовых классов сервисов. Поскольку в общем случае сервис предназначен для предоставления информации определенного формата по запросу пользователя, то можно выделить простейшие типовые сценарии взаимодействия пользователя с системой, которые поддерживаются инструментальной средой:
Однофазный запрос. Пользователь формирует запрос, отсылает его на сервер и получает в ответ необходимую ему информацию. На этом сессия завершается. Вариантом этого сценария является предоставление потока данных (например, аудио или видео) по запросу: при этом обмен сообщений прекращается, но- поток данных не пpepывaeтcя до завершения по инициативе одной из сторон.
Многофазовый запрос. Взаимодействие осуществляется в несколько этапов: пользователь предоставляет необходимую информацию в ответ на запросы сервера. Сервер передает данные после получения всей информации, необходимой для удовлетворения запроса пользователя.
Непрерывное взаимодействие с пользователем. Обмен сообщениями не прекращается до прерывания сессии по инициативе одной из сторон. В рамках каждого из описанных выше сценариев инструментальной средой поддерживается система классов сервисов (мобильный контент, электронные билеты и пр.), для которых фиксируется протокол взаимодействия и интерфейс представления. Формализация интерфейсов осуществляется на трех уровнях:
Взаимодействие с терминальным ПО, обеспечивающим выполнение алгоритма сервиса. Фиксируется при помощи описания интерфейса, необходимого для реализации программным модулем или его оберткой (в случае невозможности изменения кода модуля).
Протокол взаимодействия с клиентским приложением. Определяет набор команд, передаваемых посредством коммуникационной среды между клиентским приложением и программным модулем, реализующим интерфейс, описанный выше.
Интерфейс пользователя, индивидуальный для каждого класса и представляющий собой структурированный набор элементов управления, предназначенных для осуществления интерактивного взаимодействия. Возможна более детальная конфигурация элементов управления для каждого конкретного сервиса.
Выделение классов сервисов осуществляется на основании различий в типе представляемой информации и способе ее представления (удаленное и локальное взаимодействие). Доступ к сервисам на основании построенной классификации осуществляется посредством серверного программного обеспечения, каркас которого автоматически генерируется в процессе визуального проектирования. Провайдер сервисов в процессе добавления нового сервиса указывает:
Реализацию интерфейса, необходимого для данного класса сервисов. Интерфейс может быть реализован как локальным программным модулем, так и удаленным модулем, доступным, например, посредством соответствующего Web-сервиса.
Адрес и протокол для взаимодействия пользователя с сервисом.
Условия предоставления (схема тарификации, стоимость, режим работы и пр.).
После определения этих параметров пользователь получает возможность получения нового сервиса при помощи работающего на его мобильном устройстве клиентского приложения.
Использование сервисов осуществляется через клиентскую часть программного обеспечения (которая автоматически генерируется по ходу визуального проектирования). Клиентская часть программного обеспечения представляет собой среду для взаимодействия с сервисами провайдера. Приложение состоит из скелета-оболочки (общего для всех классов сервисов) с подключаемыми в нее модулями: для каждого из используемых классов сервисов устанавливается свой модуль взаимодействия с пользователем, представляющий собой фиксированный набор элементов управления. Модули могут встраиваться в клиентское приложение, как при начальной сборке установочного пакета приложения, так и после установки на мобильное устройство (подкачкой с сервера провайдера сервисов). По выбору разработчика, клиентское приложение в инструментальной среде реализуется для трех различных сред: Windows Mobile, Symbian, J2ME.
Дополнительным объектом разработки может являться т.н. ПО точки контроля (например, программно управляемого турникета). Оно также генерируется в процессе визуального проектирования в соответствии с правилами организации серверного и клиентского ПО.
Платежная система является независимым элементом инфраструктуры, не входящим в состав инструментальной оболочки. Однако инструментальная оболочка обеспечивает подключение к системе путем указания характеристик соответствующего платежного сервиса (рассматривается как независимое приложение). Инструментальная среда рассчитана на три группы потенциальных пользователей, различающихся по квалификации:
A) Пользователи, не имеющие опыта разработки распределенных приложений, однако обладающие четким представлением основных бизнес процессов своей предметной области.
Б) Пользователи, имеющие устойчивые представления как о бизнес-процессах, так и о технологиях их реализации в мобильных сервисах, однако не имеющие опыта разработки таких приложений на уровне кода.
B) Продвинутые пользователи, имеющие соответствующий опыт разработки.
В соответствии с классами пользователей, инструментальная среда включает в себя следующие уровни разработки (см. рис.15):
Уровень спецификатора требований (СТ). Спецификатор требований - это программа, обладающая базовыми функциями ИС, которая позволяет пользователю задавать описание мобильного сервиса в терминах бизнес-процессов предметной области в форме функциональной цепочки (раздел 3.1.3) посредством визуального редактора. СТ предлагает пользователю выбрать общую архитектуру распределенного приложения и определить и настроить основные компоненты вручную, или использовать типовые сценарии (эталонные сервисы), представленные в базе данных. Результатом работ СТ является XML-документ, содержащий полное описание структуры распределенного приложения в терминах используемых модулей, которые хранятся в соответствующем репозитории. СТ ориентирован в основном на пользователей группы «А»; однако он может быть использован группами «Б» и «В» для экспериментального прототипирования.
Уровень мастеров генерации кода (МГК). МПС являются более низкоуровневым средством, чем СТ. МГК на основании опроса пользователя формируют архитектуру распределенного приложения и настраивают его основные модули, а также генерируют сами программные коды, используя готовые компоненты из репозитория. В отличие от СТ, взаимодействующего с пользователем в терминах бизнес-процессов, в МГК пользователь отражает, в первую очередь, технологические аспекты реализации сервиса. МГК могут использовать XML-документ проекта, создаваемый посредством СТ. В этом случае дублирующие вопросы в системе диалога МГК не используются; в лучшем случае МГК сводится к уровню транслятора документа проекта в исходный код приложения.
В отличие от СТ, формирующего описание сразу всех компонентов распределенного приложения, в инструментальной среде может использоваться несколько МГК, соответствующих разным классам модулей. Например, на рис. 15 отображены: мастер генерации серверного приложения, мастер генерации клиентского приложения, мастер генерации терминального приложения. Дополнительно можно рассмотреть мастера специальных терминалов (например, мобильной кассы) и мастера создания новых компонентов для встраивания их в репозиторий. Таким образом, МГК являются обязательным дополнением к СТ, хотя пользователями классов «Б» и «В» могут использоваться независимо. Выделение нескольких классов мастеров позволяет производить тонкую настройку и модификацию каждой из частей распределенного приложения в отдельности, не меняя уже существующих (отработанных) частей сервиса. Кроме того, МГК позволяют реализовать не только функциональные цепочки, но и схемы с ветвлениями. Результатом работы МГК являются готовые программные коды, описывающие части распределенного приложения, которые могут переноситься и запускаться на соответствующем оборудовании.
Экспериментальное изучение производительности (тестирование)
В зависимости от используемого при тестировании ПО интегральные тесты можно дальше разделить на универсальные, специализированные и пилотные [69]. Более подробно эта классификация рассмотрена в таблице 3. Существует огромное число универсальных тестов [71] (SPECint2000 для операций, ориентированных на целочисленные вычисления, SPECfp2000 для операций с плавающей точкой и т. п. [72]), но наиболее известными из них являются тесты ТРС (Transaction Processing Performance Council - Совета по обработке транзакций [73]). ТРС является независимой некоммерческой организацией, созданной для исследования обработки транзакций и производительности систем управления базами данных (СУБД) и распространения объективной и воспроизводимой информации о производительности в тестах ТРС для компьютерной индустрии. Наиболее используемые в индустрии тесты этой организации: ТРС-С (тесты по обработке транзакций) и ТРС-Н (запросы к хранилищам данных). Сама процедура проведения тестов включает четкую стандартизацию и обязательное проведение аудита независимой сертифицированной компанией. С другой стороны, сами тесты являются исключительно упрощенными и значительно отличаются от реальных систем. С нашей точки зрения, эти тесты дают исключительно важную информацию для сравнения различных аппаратных и программных решений, позволяют сравнивать их между собой, но не применимы для выбора конкретной системы для решения задачи заказчика.
Специализированные тесты гораздо более соответствуют действительности. В этих тестах используется программное обеспечение, которое может применяться в проекте. Наиболее известны тесты SAP benchmark [74]. При тестировании по методике SAP происходит тестирование работы всех систем и подсистем: процессоров, ввода-вывода, сетевого трафика, обработки ошибок и других. Каждый SAP Standard Application Benchmark состоит из набора исполняемых сценариев, симулирующих типичные транзакции и бизнес-процессы, соответствующие обычным сценариям работы с системой. SAP предлагает набор тестовых данных для проведения испытаний. Для того чтобы тесты производительности SAP соответствовали реальным условиям эксплуатации и могли использоваться для сайзинга, в них симулируется поведение клиента, заполняющего стандартные формы. Каждому такому симулированному клиенту задается время задержки в 10 секунд перед выполнением очередного шага в диалогах, что соответствует среднему реальному времени размышления живых опытных операторов. Во время выполнения тестов число одновременно работающих симулированных клиентов непрерывно возрастает до тех пор, пока время отклика системы в диалоговом режиме не превысит установленные спецификацией на тесты 2 секунды. Такая нагрузка намного больше соответствует реальным системам, чем нагрузка в тестах ТРС, т. к. учитывает тот факт, что приемлемое время отклика системы более важно для работы, чем общее число проведенных транзакций. Это сравнительно небольшое изменение оказывает решающее влияние на настройки системы и на нагрузку всех ее компонентов, делая ее максимально близкой к реальной работе пользователей. В результате чего специализированные тесты, и особенно SAP benchmark, лучше подходят для оценки производительности серверных платформ.
В связи с направленностью тестов на понимание их результатов людьми, принимающими решения и не обязанными разбираться в технических деталях и терминах, результатом теста является число полностью обработанных бизнес-операций. Такими операциями могут быть: число введенных заказов, число произведенных товаров, число заказов на сборку и т. п.
В целом такие тесты гораздо более приближены к реальной жизни, но также обладают рядом недостатков. В первую очередь это небольшое количество приложений, для которых разработаны такие тесты. Кроме SAP benchmark, можно отметить Oracle Applications Standard Benchmark [75],. тесты PeopleSoft [76], Siebel [77] и ряд других приложений. Если планируется использовать другие приложения или нестандартные аппаратные и программные приложения, то эти тесты также мало информативны. Кроме того, конфигурация аппаратных средств, как и в случае тестов ТРС, ориентирована на достижение максимальной производительности и отличается от тех конфигураций, которые будут использованы в реальном проекте.
Еще более точные результаты могут быть получены в пилотных тестах. В рамках таких проектов представители производителя или системного интегратора проводят тестирование и настройку приложения на оборудовании, максимально приближенном к системе заказчика. В этом случае используются наиболее точные данные о профилях нагрузки на приложение и получаются наиболее точные рекомендации по выбору. Кроме того, пилотные тесты позволяют оптимизировать производительность приложения за счет тонких настроек параметров операционной среды и специальной конфигурации серверной платформы.
Ключевая особенность пилотных тестов и нагрузочного тестирования не измерение быстродействия системы в неких универсальных условных единицах, а настройка совершенно конкретного приложения под конкретные требования и условия работы потребителя. Такое изменение акцентов в оценке производительности в первую очередь связано с тем, что потребителю необходимо выполнение его бизнес-задач с минимальными затратами и достаточным быстродействием. Специфика бизнеса и выполнения бизнес-операций в каждом конкретном случае может значительно отличаться от общей модели, выбранной производителем. При этом сайзинг на основе нагрузочного тестирования позволяет с максимально возможной точностью подобрать необходимую конфигурацию, что, в свою очередь, увеличивает возврат инвестиций и радикально снижает стоимость владения.
Правильное проведение нагрузочного тестирования начинается с чрезвычайно важной операции — согласования с заказчиком методики тестирования. Ошибки на этапе согласования могут приводить к провалу проекта, когда уже были вложены значительные средства и потеряно много времени. В процессе согласования необходимо описать тестируемые операции, модель системы, критерии оценки производительности, модель и профили нагрузки, характеристики аппаратной и тестовой платформы, план-график тестирования и еще ряд критически важных условий. Нагрузочные тесты не ограничиваются лишь исполнением тестов и снятием метрик — это комплексная задача, включающая оптимизацию и настройку всей информационной инфраструктуры. Только такой подход позволяет добиться необходимого экономического эффекта и снизить риски.
Проведение нагрузочного тестирования и выбор программно-аппаратных средств для построения надежной информационной инфраструктуры для выполнения критически важных бизнес-приложений очень сильно зависит от выбора компании-поставщика таких услуг. Такая компания должна обладать значительным опытом выполнения подобных работ, высококвалифицированным персоналом, опытом работы с разработчиками бизнес-приложений и доступом к технической и методической информации компаний-производителей аппаратных платформ и программных средств, таких как Intel, HP, Oracle, Microsoft и др., и грамотно владеть соответствующим инструментарием.
Модификационный анализ используемой модели
Мы получили модель и проверили ее применимость для определенного случая (надо заметить, что верификация общей модели чисто теоретически невозможна, поскольку ей не сопоставлена существующая система). Для модификационного анализа данной модели необходимо построить детализованную иерархическую модель определенных узлов взаимодействия с сервером.
Первоначально пользователь всегда обращается к серверу. В выбранной для исследования реализации данная компонента представляется приложением в контейнере Java Enterprise Edition. Допустим, мы хотим улучшить время ответа в реальной системе. Естественным подходом для этого может служить кластеризация серверной части. В виду того, что дополнительное серверное оборудование является в достаточной степени дорогим, необходимо иметь возможность оценить возможный выигрыш от такой операции. Для этого параметризуем узлы данной компоненты.
Тогда общий вид узлов можно будет записать следующим образом.
Рассчитывая для новой системы время ответа (отклика) при М = 1,2,3,5,100, можем получить следующий график, представленный на рис.46.
Соответственно можно построить график относительного ускорения при разных частотах входных заявок и разном уровне кластеризации (рис. 47).
Рассчитывая на сколько процентов уменьшилось время отклика для частоты заявок 0,714, можем получить табл. 35 результатов
Интересно, что на представленном выше графике на рис.47, поведение системы качественно не менялось в зависимости от количества вычислительных узлов. Это происходило потому, что частота насыщения системы никак не менялась, ввиду того, что напрямую определялась узлом платежной системы и его требованием обслуживания — D6= 0,750
Рассмотрим более интересный случай, параметризуя частоту насыщения.
Зададим входные данные представленные в табл. 36.
Хорошо видно, что на бесконечность время ответа для М = 1; 2 уходит раньше, это происходит потому, что Asat = f(.D7) = /"(М), для значений же М = 3,5,100, Xsat = f{D6) = const и точка насыщения у них одна.
Относительное ускорение времени отклика при разных значениях уровня кластеризации изображено на графике, представленном на рис. 49.
Красная и синяя кривая показывают полученное относительное ускорение по сравнению с некластеризованнои системой, которое уходит на бесконечность ввиду разных точек насыщения и возвращается к 1 при значении частоты входящих заявок, при которой происходит насыщение всех трех систем.
Розовая и зеленая кривые показывают относительное ускорение системы при М = 5,100 по сравнению с решением М = 3. У всех трех кривых точка насыщения одна, а потому они аккуратно сходятся к 1, в точках частоты заявок при которых поведение всех трех систем будет одинаково плохим.
Для того чтобы закончить обоснование, приведем сводную таблицу частоты насыщения для всех значений параметра М. Как более интересный, рассмотрим второй случай, когда поведение системы меняется качественно (график результатов эксперимента для единой точки насыщения можно найти в Приложении 1). То есть Kat = — такое что Dj Dt, t — 1. .8, но при этом требование обслуживания Щ узла / параметризованно количеством вычислительных узлов.
Зададим входные данные системы, представленные в табл. 38.
Можно заметить, что в значениях близких к jisat и больших, значение системного времени на экспериментальном (RM=IM C2,M=2) стенде не уходит в бесконечность. Это происходит из-за того, что в реальности мы не можем обеспечить непрерывный поток заявок. И на любом промежутке времени поток входящих заявок будет терминальным (конечным).
Так в данном эксперименте для каждой частоты входящих заявок выполнялось 7 = 52 запросов. Соответственно: при Я Asat, в пределе заявки выстраивались одна за другой на первом узле, а далее выполнялись последовательно, именно это и демонстрируют данные, полученные со стенда.
Значение, к которому стремится системное время ответа в данных случаях, легко посчитать
Необходимо отметить, что данные, рассчитанные по модели, хорошо согласуются с данными, полученными на экспериментальном стенде. При Я = 2j2 системные времена ответа будут соответственно 63,88; 38,05; 33,63.
