авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 ||

«РОССИЙСКОЙ АКАДЕМИИ НАУК СИБИРСКОЕ ОТДЕЛЕНИЕ Федеральное государственное бюджетное учреждение науки Институт систем информатики им. А.П. ...»

-- [ Страница 2 ] --

Шина сообщений может быть спроектирована несколькими способами с учетом сложности системы, специфики трафика сообщений и анализа пи ковых нагрузок системы [37, 38].

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

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

Для успешной работы в таких условиях автор применил технологию управления конкурентным доступом в корпоративной базе данных с помо щью многоверсионности [11, 39].

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

При создании более сложной системы интеграции данное окружение первоначальной системы можно будет использовать без изменений, так как «контракт» команд и запросов имеет открытый формат и протокол.

Если возникнет необходимость изменения или добавления команд, не обходимо будет только переделать библиотеку команд системы.

Для того, чтобы подобная замена могла быть легко осуществима в бу дущем, автор использовал технологию “Dependency Injection” [40].

Защита от несанкционированного доступа 3. Защита данных в объединенной системе является одной из первейших задач полноценной интеграции.

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

В качестве защит от потенциальных угроз целесообразно рассматри вать следующие:

защита от несанкционированного копирования информации;

защита от несанкционированного изменения данных посредством ав торизации пользователей;

защита от злонамеренного разрушения базы данных.

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

Защита авторизации пользователя обобщенной системы представляет ся автору стандартной операцией с авторизацией при помощи пароля, до менной или аппаратной авторизации.

Все три метода одинаково успешно реализуются для любых типов ин тегрируемых систем.

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

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

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

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

В предложенной автором новой архитектуре для интеграционного ок ружения независимых систем может возникнуть новый тип угрозы несанк ционированного доступа путем подмены dll-библиотеки команд на другую библиотеку, содержащую код злоумышленника. Существует несколько спо собов защиты от подобного вмешательства, например, сравнения check суммы библиотеки с оригиналом, хранящемся в базе данных, и т.д. [60-64] Исследовав отказоустойчивость авторской и классической моделей ин теграции при штатном режиме работы, автор пришел к выводу, что простота конструкции и меньшее количество аппаратных узлов здесь играет решаю щую роль, и подсистема, спроектированная с использованием классической архитектуры, будет в целом более надежна.

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

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

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

Данные опытных измерений представлены в Приложении 2.

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

по 50-500 запросов в каждом случае чтения информации и по 5-100 в случае изменения информации.

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

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

Общая динамика наглядно представлена на Рис. 17 и Рис. 18.

Рис. 17 – График отклика подсистемы на запросы к получению данным системы в нагрузочных тестах.

Вертикальные оси графиков отображает время отклика (мс), горизон тальные – количество посланных запросов в секунду.

Рис. 18 – График отклика подсистемы на запросы на изменение данных системы в нагрузочных тестах.

Значения сравнительных характеристик отображены в Таблице 1.

Авторская Классический Сравнительные характеристки методика способ интеграции интеграции Масштабируемость системы + Отказоустойчивость системы + + Полное обновление записи в базе данных - + Сложность реализации и обслуживания + Сложность разработки системы + Требования к оборудованию - + Время получения информации + Защита данных от несанкционированного доступа + Таблица 1. - Итоговые значения сравнительных характеристик проектируемых подсистем Возможности интеграции независимых информационных 3. систем, созданных ранее третьими фирмами, с перспективой дальнейшей работы на устройствах с ограниченными вычисли тельными ресурсами В последнее время большую популярность завоевали мобильные уст ройства, такие, как всевозможные коммуникаторы и планшетные компьюте ры, использующие различные операционные системы. В то же время, в связи с почти повсеместной доступностью сети Интернет, большинство популяр ных программ могут быть использованы не только на стационарных компь ютерах, но и на мобильных устройствах.

Кроме того, пользовательский рынок постоянно пополняется приложе ниями, специально разработанными для мобильных устройств (например, в связи с распространением iPad появилось много новых приложений для MacOS).

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

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

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

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

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

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

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

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

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

В качестве опытной площадки была выбрана корпоративная система TRIS (Recruitment Systems Ldt Pty). Результаты исследования опубликованы [16]. По результатом автором была спроектирована и успешно внедрена обобщенная система «TRIS Mobile».

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

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

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

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

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

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

В этом случае база данных клиента (cache) работает в режиме синхрониза ции полученных объектов. В противном случае поиск объекта осуществляет ся в cache данных.

Внешний Клиентские сервисы интерфейс ввода и вывода взаимодействия с информации, сервис клиентской частью формирования приложения сообщений (Command Интерфейс message) взаимодействия Команды с пользователем Запрос к данным Запрос к Закрытое ядро данным системы Команды Cache Сервис Модуль описания внешнего обобщенной API системы Шина сообщений Хранилище База данных файлов Данные, Блок адаптированные денормализации Исходная система для чтения Клиентское Обобщенная серверная часть приложение Рис. 19 – Принципиальная схема взаимодействия клиентского приложения с обобщенной серверной частью, разработанной с использованием модифицированного шаблона CQRS Независимо от того, насколько стабильной является связь с сервером, все команды, поступающие от модуля клиентской сервисов на добавление новых объектов, изменение и удаление существующих объектов, сохраняют ся в очереди команд, также размещенной на стороне клиентской части.

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

3.4.1 Проблема недостаточности вычислительных ресурсов и свободно го файлового пространства на стороне «клиента»

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

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

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

Перед тем, как приступать к практическому решению проблемы недос таточности вычислительных ресурсов, необходимо сначала получить четкое представление с том круге задач, которые будет решать данное приложение [65].

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

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

Избавление от подобных фантомных связей [66, 67] может заметно снизить трафик между мобильным клиентом и сервером, уменьшить размер сохраняемых объектов, и, вследствие этого, уменьшить требуемое место для хранения объектов на жестком диске мобильного устройства, упростить функционал данного приложения (при условии, что сама задача, за выполне ние которой отвечает приложение, остается работоспособной), а также и пользовательский интерфейс.

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

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

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

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

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

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

20).

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

Будем называть такой режим работы штатным. Авторизованный пользова тель запрашивает данные определенного типа, по какому-либо выбранному им критерию.

Интерфейс мобильного Сервис авторизации сервера Транспортный сервис клиента Транспортный сервис сервера приложения Сервис авторизации клиента Случай когда сервер доступен Сервер доступен?

Сообщение состояния сервера Сообщение- Запрос на авторизацию Сервер доступен?

Сообщение-Документ Данные пользователя Сообщение- Документ данные пользователя Пользователь авторизован сохранение Сервер доступен? данных пользователя Сообщение состояния сервера Сотояния авторизованных Сервер не доступен пользоваталей не меняется Сервер доступен?

Сообщение состояния сервера Сообщение-Запрос на повторную авторизацию Сервер доступен вновь Сообщение-Документ Данные пользователя Сообщение- Документ данные пользователя сохранение Завершение работы пользователя данных пользователя Сервер доступен?

Сообщение состояния сервера Сервер не доступен Сообщение-Запрос на авторизацию Сообщение-Данные пользователя Авторизация считается успешной если проходит только килентский (упрощенный) уровень авторизации Рис. 20 – Диаграмма последовательностей авторизации пользователя Клиентское приложение публикует сообщение-событие (Event message). Серверу доставляется это сообщение, и в ответ сервер публикует сообщение (Document message) с набором удовлетворяющих запросу доку ментов (см. Рис. 21).

Интерфейс мобильного Транспортный сервис клиента Данные мобильного приложения Данные сервера приложения Случай когда сервер доступен Сервер доступен?

Поиск данных Сообщение-Документ с набором данных Сообщение-Документ с набором данных Сохранение данных на клиенте Случай когда сервер не доступен Сервер доступен?

Поиск данных Сообщение-Документ с набором ранее сохраненных данных Рис. 21 – Диаграмма последовательности получения данных клиентской частью приложения, установленной на мобильном устройстве, при штатных условиях работы системы Опубликованное сообщение отображается на устройстве вывода кли ентского приложения и, параллельно, заполняет стек объектов данного типа клиентского приложения. Таким образом, мобильный пользователь получает доступ к запрашиваемым данным.

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

После изменения, удаления или добавления объекта клиентское при ложение публикует сообщение-команду (Command message), которая разме щается в очереди команд на мобильной клиентской части приложения и, по мере сообщения с сервером, передается на шину команд сервера, и, далее, либо исполняется Domain model сервисом, либо отвергается, как не коррект ная, или не актуальная. Диаграмма событий обработки команд мобильного клиента представлена на Рис. 22.

Интерфейс мобильного Очередь команд мобильного Очередь команд сервера Деномализатор Domain model приложения приложения Сообщение на изенение объекта Постановка в очередь Передача команд серверу Сообщение об очистки очереди клиента Испольнение команды Сообщение - команда поступила в обработку Сообщение-событие: Изменение Объекта Рис. 22 – Диаграмма последовательности обработки команд при штатных условиях работы системы 3.4.4 Работа в условиях недоступности сервера Исходя из особенностей работы мобильных устройств, необходимо учитывать возможность работы с корпоративным приложением в условиях временного отсутствия доступа к интернету. В качестве решения подобной проблемы можно предложить авторизованный сеанс работы мобильного пользователя с набором объектов, полученных в результате сохранения пре дыдущих сеансов в режиме, когда стационарный сервер был доступен. При проектировании работы рассматриваемой распределенной системы, в дан ном режиме, перед нами возникает несколько проблем:

авторизация по способу, описанному выше;

организация работы с данными, сохраненными ранее;

отложенное сохранение.

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

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

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

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

Интерфейс мобильного Очередь команд мобильного Очередь команд сервера Транспортный сервис клиента приложения приложения Сообщение на изменение объекта Транспортный сервис сервера Постановка в очередь Проверка доступности сервера Ответ сервера если доступен Сообщение Сообщение Передача команд серверу Проверка доступности сервера Ответ сервера если доступен Рис. 23 – Диаграмма последовательностей обработки команд в условиях, когда сервер не доступен В случае восстановления доступа к серверу клиентском приложением должна быть асинхронно выполнена следующая последовательность опера ций:

Штатная авторизация пользователя.

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

На сервере выполнена вся очередь команд, сохраненных клиентским приложением.

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

Обновлены объекты, находящиеся в Cache клиентского приложения.

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

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

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

Критерием оценки актуальности информации можно выбрать время последнего обновления (с учетом миллисекунд) и часового пояса сервера.

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

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

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

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

Процесс добавления объектов в информационную систему при авто номной работе технически довольно прост. Единственная проблема, возни кающая при добавлении – проблема создания объектов–дубликатов.

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

Таким образом, предлагается следующий алгоритм решения проблемы:

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

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

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

Рассмотрим процесс сохранения данных отредактированного объекта.

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

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

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

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

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

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

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

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

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

Например, есть публичный online сервис фотокарточек соискателей на определенную работу (такие, как социальная сеть Linked In).

Есть корпоративное приложение, которое организует поиск и даль нейшее сопровождение соискателей (например, рекрутинговая система TRIS).

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

Аналогично, можно привести примеры развития функциональных воз можностей в сторону настольного клиента.

Выводы 3. Данная глава посвящена описанию разработанных автором способов интеграции независимых информационных систем.

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

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

Далее, для систем «закрытого» типа с внешним API такой модуль, по авторской идее, должен быть оформлен в виде dll библиотеки и запускаться как Windows-сервис [34] или Web-сервис [35].

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

Все экспериментальные исследования проводились на площадке, пре доставленной компанией Recruitment Systems Ltd Pty (Австралия, http://www.Recruitment systems.com/) при апробации и внедрении автором своих методик, разработанных в рамках проектов Tris Enterprise © и Tris Mobile © (2011, 2012 гг.). В качестве первоначальной информационной сис темы была выбрана корпоративная система TRIS©, которую следует отно сить к классу закрытых систем с внешним API.

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

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

Шаблон позволяет существенно снизить сетевой трафик;

достаточно просто, с точки зрения реализации, применить такие технологии, как Domain model [1] и Data Transfer Object [43], поэтому, по мнению автора, позволяет вполне успешно решать проблему несоответствия между высокими требова ниями, предъявляемыми к корпоративным системам и ограниченными воз можностями пользовательских устройств, на которые будет устанавливаться клиентская часть такого приложения.

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

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

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

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

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

Данный метод был апробирован при разработке приложения «TRIS Mobile», разработанного по заказу компании Recruitment Systems Pty Ltd (Австралия) и в настоящее время находящегося в промышленной эксплуата ции.

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

Глава 4. Интеграция нескольких информационных систем методом «Business Community»

Рассмотрим простую ситуацию, часто возникающую при взаимодейст вии двух реальных контрагентов.

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

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

Примем во внимание факторы, благоприятствующие построению инте грации.

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

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

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

Таким образом, построение интеграции представляется экономически оправданным.

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

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

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

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

Как и в предыдущем разделе, проведем анализ взаимодействия реаль ных систем и предложим информационную модель в рамках концепции «SOA-CQRS» [1, 11].

Рассмотрим Рис. 24.

«uses» «uses»

Контракт взаимодействия «uses»

«uses»

Инициатор взаимодействия Участник «uses»

«uses»

«uses» «uses»

Список Предметов Отчет о реализации «uses»

«uses»

«uses»

«uses»

Эксперт инициатора Эксперт участника Рис. 24 - UML сценарий взаимодействия реальных информационных систем Из диаграммы сценария видно, что между двумя агентами «Инициатор взаимодействия» и «Участник» возникает ряд взаимных обязательств, регла ментируемых «Контрактом взаимодействия». «Контрактом взаимодействия»

также определяется «Перечень типов объектов» взаимодействия и формат отчета-сообщения об изменениях данных.

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

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

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

Однако, если применить авторский подход, изложенный в 2.2, можно представить информационную систему «Инициатор взаимодействия» или систему «Участник» в виде системы, схема которой приведена на Рис. 25, т.е. представить каждую из них в виде клиентского приложения, организо ванного в виде сервиса.

Информационная система Универсальный адаптер «Участник взаимодействия»

Преобразователь WebService сообщений Клиент Business Logic управления Документы Данные, Данные адаптированные для чтения Рис. 25 - Преобразование информационной системы «Участник взаимодействия» в клиентский сервис.

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

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

Универсальный адаптер представляет собой программный модуль, способный взаимодействовать с оригинальной информационной системой в зависимости от ее типа (см. 2.2). Адаптер имеет пользовательский интерфейс для осуществления ручной корректировки и визуального контроля процесса синхронизации справочников системы с общими справочниками «бизнес сообщества». Для удобства проектирования таких адаптеров автор предлага ет представлять его в терминах сервисно-ориентированной архитектуры.

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

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

Это может быть легко реализовано, как шаблон «Абстрактная фабрика» [20].

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

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

После того, как данные из блока предоставлены запрашивающей сис теме и обработаны ею, сообщение (отчет) об изменении данных и/или их статусов, формируется в соответствии с «Контрактом взаимодействия» и предоставляется системе, предоставившей данные, что обеспечивает син хронизацию данных.

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

На Рис. 26 и Рис. 27 представлены схемы взаимодействия систем участников с центральным сервисом.

"Инициатор взаимодействия" Центр обработки Запрос на регистрацию Уведомление о начале обработки Уведомление о результатах регистрации Подтверджение получения уведомления Получение общих справочников в xsd файле Подтверждение получения списка Готовность к работе Дополнение общих справочников Изменение общих справочников в xsd файле Подтверждение получения списка Переход в ожидание и начало реогранизации данных Готовность к работе Рис. 26 - Диаграмма последовательности регистрации и обмена общими справочниками между центром обработки и системой «Инициатором взаимодействия»

Проанализируем диаграмму, приведенную на Рис. 26.

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

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

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

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

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

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

Для корректного анализа диаграммы предположим, что изначально обе системы («Инициаторы») находятся в состоянии «Готов в работе».

Система 1 "Инициатор" Система 2 "Инициатор" Центр обработки Система "Участник" Готовность к работе Запрос на получения списка предметов Переадресация сообщений Передача списка Систем Передача списка данных Передача списка данных Передача отчета о реализации Подтверждение Передача отчета о реализации Подтверждение Рис. 27 - Диаграмма последовательности передачи пакета данных и его обработки Тогда после включения в обобщенную систему нового участника, он может послать запрос на получение списка предметов взаимодействия.

Центр обработки обрабатывает сообщение от системы-участника, и, учиты вая тип данных и готовность систем, предлагающих набор данных нужного типа, отправляет сообщения: для систем-инициаторов с адресом системы участника и набором критериев для фильтрации;

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

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


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

Информационная система, Универсальный адаптер предоставляющая данные Преобразователь WebService сообщений Клиент Business Logic управления Документы Центральный сервис обработки Данные, Данные Сервис адаптированные Репозиторий обработки для чтения сервисов сообщений Сервисная Обобщенный клиент 1 шина Сервис проверки протокола Информационная система Данные Универсальный адаптер (контракта) «Получатель»

Преобразователь WebService сообщений Клиент Business Logic управления Документы Данные, Данные адаптированные для чтения Обобщенный клиент Рис. 28 - Принципиальная схема системы, спроектированной с использованием метода «Business Community»

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

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

Модификация метода «Business Community» для «Облачных 4. вычислений» (Cloud computing) Альтернативной реализацией описанного раннее метода «Business Community» является его применение в сочетании с технологией «Облачных вычислений» (Cloud Computing) [18].

На Рис. 29 представлена адаптированная к использованию в Cloud Computing схема работы метода Business Community.

Информационная система, предоставляющая данные Cloud Computing Универсальный Центральный сервис управления клиент управления WebService и обработки запросов Сервис Репозиторий обработки сервисов Документы сообщений Сервисная шина Сервис проверки Данные протокола Преобразователь (контракта) Данные сообщений Информационная система «Получатель» Обобщенное хранилище данных Универсальный клиент управления и обработки запросов Модуль обработки Обобщенные данные, логики предметной адаптированные для области чтения Документы Данные Рис. 29 - Принципиальная схема системы, спроектированной с использованием метода «Business Community», в сочетании с технологией “Cloud Computing” Сравнивая Рис. 29 с общей схемой, приведенной на Рис. 28, отметим, что часть блоков претерпела некоторые изменения. Рассмотрим их подроб нее.

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

Они могут, как и ранее, иметь любое (с некоторыми ограничениями, описан ными в [3, 16, 17]) программное обеспечение и быть размещенными как на сервере владельца, так и, по его желанию, целиком либо частично перенесе ны в «облачные» вычисления, что никоим образом не отразится на примени мости метода.

В соответствии с концепцией Business Community, каждая информаци онная система вместе с ее универсальным адаптером формируют т.н. «обоб щенный клиент» [2, 15], и взаимодействие системы с ее адаптером осущест вляется посредством специального API, предоставляемого универсальным адаптером.

При переносе технологии в облачные вычисления, «обобщенный кли ент» заменяется неким «тонким клиентом», названным на Рис. 29 «Универ сальным клиентом управления и обработки запросов» и связанным с инфор мационной системой посредством API (аналогично основному методу Business Community).

При переносе технологии в «облачные» вычисления «тонкий клиент»

выполняет следующие функции:

Синхронизация данных между системой и обобщенным информаци онным хранилищем данных;

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

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

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

Следует отметить, что при использовании обычного метода Business Community предоставляемые данные не сконцентрированы в едином храни лище. Каждая система, открывая для других систем адаптированные для чтения данные, хранит их внутри своего обобщенного клиента. В этом слу чае взаимодействие между системами осуществляется с помощью Web сервиса, включенного в состав Универсального адаптера.

При переносе метода в Cloud [19], объединенное информационное пространство имеет обобщенное хранилище всех данных, представленных их системами-владельцами и адаптированных для чтения. Размещение этого обобщенного хранилища непосредственно в «облачных» вычислениях по зволяет упростить схему и отказаться от использования клиентских Web сервисов. Вместо них автор предлагает использовать только типовые серви сы, размещенные внутри облачных вычислений.

Как и в обычном методе Business Community, «Центральный сервис»

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

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

Предложенный метод может быть внедрен для любой платформы об лачных сервисов. Экспериментальные разработки проводились с использо ванием платформы Windows Azure.

Внедрение технологии Business Community позволяет организовать информационное сообщество на качественно новом уровне.

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

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

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

Перенос технологии Business Community в Cloud Computing позволяет усовершенствовать схему работы и предложить более оптимальные решения ряда технических вопросов за счет использования возможностей «облачных вычислений».

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

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

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

При размещении в «облачных» вычислениях в обобщенной системе повышается уровень безопасности данных за счет использования надежных центров обработки данных (data center) компании-провайдера (например, Microsoft) [21].

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

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

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

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


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

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

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

В главах 2, 3 и 4 приведено описание авторских технологий, позво ляющих решать задачу интеграции систем для сложных случаев, когда перед разработчиком встает необходимость подбора нестандартного решения:

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

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

Метод динамической (настраиваемой) интеграции нескольких инфор мационных систем «Business Community»;

Интеграция нескольких информационных систем методом «Business Community» с использованием «Облачных вычислений» (Cloud computing).

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

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

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

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

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

Литература 1. Greg Young Официальный сайт [Электронный ресурс]. – Режим досту па: http://codebetter.com/gregyoung (дата обращения: 10.01.2013).

2. Бертран Мейер Методы программирования : в 2 т./ пер. с фр.Ю. А.

Первина;

под ред. А. П. Ершова. -Москва : Мир 3. Eckerson, Wayne W. "Three Tier Client/Server Architecture: Achieving Scalability, Performance, and Efficiency in Client Server Applications."

Open Information Systems 10, 1 (January 1995): 3- 4. Нильссон Д. Применение DDD и шаблонов проектирования. Проблем но-ориентированное проектирование приложений с примерами на C# и.NET = Applying Domain-Driven Design and Patterns with Examples in C# and.NET. — М.: «Вильямс», 2008. — С. 549.

5. Генри Бекет Java SOAP для профессионалов. – Москва : Бином 6. Martin Keen, Susan Bishop, Alan Hopkins. Patterns: Implementing an SOA using Enterprise Service Bus, IBM Redbooks, NY, 7. Дхарма Шукла, Боб Шмидт. Основы Windows Workflow Foundation = Essential Windows Workflow Foundation. — М.: «ДМК Пресс», 8. V. Andronikou, K. Mamouras, K. Tserpes, D. Kyriazis, T. Varvarigou, Dynamic QoS-aware Data Replication in Grid Environments, Elsevier Future Generation Computer Systems - The International Journal of Grid Computing and eScience, 9. Hamilton, James. “Inter-Datacenter Replication & Geo-Redundancy” ресурс]. – Режим доступа:

[Электронный http://perspectives.mvdirona.com/2010/05/10/InterDatacenterReplicationGeo Redundancy.aspx (дата обращения: 10.01.2013) 10.Бертран Мейер Объектно-ориентированное конструирование про граммных систем: пер. с фр. В. Билиг, Е. Павлова. -Москва : Русская ре дакция 11.Мартин Фаулер, Архитектура корпоративных программных приложе ний, Patterns of Enterprise Application Architecture, Вильямс – 12.Bieberstein N., Bose S., Fiammante M., Jones K. Service-Oriented Archi tecture (SOA) Compass: Business Value, Planning, and Enterprise Roadmap.

NY.: IBM Press, 2006. 1058 p 13.Платонов Ю.Г. Метод слабосвязанных бизнес-коммуникаций в гомо генных информационных системах // Современные проблемы науки и образования. – 2013. – № 1;

URL: http://www.science-education.ru/107 8263 (дата обращения: 17.04.2013).

14.World Wide Web Consortium. Официальный сайт [Электронный ре сурс]. – Режим доступа: http://www.w3.org/standards/xml/schema (дата обращения: 10.01.2013).

15.Дейт К. Введение в системы баз данных. – 6-е изд. – М.: Диалектика, 1998. – 563 c.

16.Платонов Ю. Г. Разработка мобильных приложений для работы с кор поративными информационными системами // Проблемы информатики.

– 2011. – № 3. – С. 15-33.

17.Платонов Ю. Г. Анализ перспектив перехода информационных систем на сервисно-ориентированную архитектуру // Проблемы информатики.

– 2011. – № 4. – С. 56-65.

18.Платонов Ю.Г., Артамонова Е.В. МЕТОД BUSINESS COMMUNITY И «ОБЛАЧНЫЕ» ВЫЧИСЛЕНИЯ (CLOUD COMPUTING) // Фундамен тальные исследования. – 2013. – № 4 (часть 5). – стр. 1089 1093;

URL: http://www.rae.ru/fs/?section=content&op=show_article&article _id=10000577 (дата обращения: 17.04.2013).

19.Grossman R., The Case of Cloud Computing // IEEE IT Professional. – 2009. – Vol 11, № 2. – Р. 23–27.

20.Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. Приемы объектно ориентированного проектирования. Паттерны проектирования = Design Patterns: Elements of Reusable Object-Oriented Software. — СПб: «Питер», 2007. — С. 366.

21.Microsoft Inc. Официальный портал для разработчиков Windows Azure [Электронный ресурс]. – Режим доступа - http://www.windowsazure.com/ en-us/manage/services/recovery-services/ (дата обращения: 20.04.2013).

22.Платонов Ю. Г. Анализ необходимости перевода информационных систем на сервисно-ориентированную архитектуру для предприятий с повышенной ответственностью за качество кода // Тез. докл. Междуна родной Ершовской конференции по информатики PSI'11 //Секция «Нау коемкое программное обеспечение». – Новосибирск, 2011. – С.208–215.

23.Microsoft Inc. MSDN: “Globally Unique Identifiers - Internal Structure” [Электронный ресурс]. – Режим доступа: http://msdn.microsoft.com/en us/library/cc246027.aspx (Дата обращения 01.05.2013) 24.Erik Hatcher, Otis Gospodnetic. Lucene in Action — Manning, NY, 2004.

— Р. 456.

25.Apache Inc. Lucene official website [Электронный ресурс].- Режим дос тупа: http://lucene.apache.org/core/4_2_1/index.html (Дата обращения 01.05.2013) 26.Rahul Roy, Shard – A Database Design [Электронный ресурс].- Режим доступа: http://technoroy.blogspot.ru/2008/07/shard-database-design.html (Дата обращения 10.12.2010) 27.Microsoft Inc. Federations: Building Scalable, Elastic, and Multi-tenant Da tabase Solutions with Windows Azure SQL Database [Электронный ре сурс]. – Режим доступа: http://social.technet.microsoft.com/wiki/ con tents/articles/2281.federations-building-scalable-elastic-and-multi-tenant database-solutions-with-windows-azure-sql-database-en-us.aspx (Дата обра щения 05.04.2011) 28.Рэнд Моримото, Кентон Гардиньер, Майкл Ноэл, Джо Кока. Microsoft Exchange Server 2003. Полное руководство = Microsoft Exchange Server 2003 Unleashed. — М.:«Вильямс», 2006. — С. 29.Edge Charles S., Jr ch. 3 // Enterprise Mac Administrator's Guide. — New York City: Apress, 2009.

30.Платонов Ю. Г. Использование CQRS-технологии при разработке кор поративных приложений// Молодая информатика. – 2011. – № 3. – С. 53 62.

31.Марк Лутц. Программирование на Python / Пер. с англ. — 4-е изд. — СПб.: Символ-Плюс, 2011. — Т. I. — 992 с.

32.Microsoft Inc. Типы триггеров DML. [Электронный ресурс]. – Режим доступа: http://msdn.microsoft.com/ru-ru/library/ms178134(v=sql.105).aspx (Дата обращения 05.04.2011) 33.Пол Нильсен. SQL Server 2005. Библия пользователя = Microsoft SQL Server 2005: Bible – М.: “Вильямс”, 2008.-C. 34.Белоусов А. А. Службы Windows XP. [Электронный ресурс]. – Режим доступа: http://bookfi.org/book/632955 (Дата обращения 05.04.2013) 35.Эрик Ньюкомер. Веб-сервисы: XML, WSDL, SOAP и UDDI – СПб.:

Питер, 2003. – 256 с.

36.Тао Чжоу. Системы балансировки нагрузки Web-сервисов // Windows 2000 Magazine. – 2000. - № 3 с 27-40;

URL: http://citforum.ru/internet/ webservers/websbal.shtml (дата обращения 14.04.2013) 37.David Chappell. Enterprise Service Bus – NY.: O’Reilly, 2004.- 467 pp.

38.Michael Bell. Service-Oriented Modeling: Service Analysis, Design, and Ar chitecture – NY.: Wiley & Sons, 2008. – 872 pp.

39.Gerhard Weikum, Gottfried Vossen. Transactional information systems:

theory, algorithms, and the practice of concurrency control and recovery – NY.: Morgan Kaufmann, 2002. – 852 pp.

40.Mark Seemann. Dependency Injection in.NET – NY.: Manning Publication Co, 2011. – 584 pp.

41.ГОСТ Р 34.10-2001 Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи 42.Дал У., Дейкстра Э., Хоор К. Структурное программирование = Structured Programming. — 1-е изд. — М.: Мир, 1975. — С. 247.

43.W3 Inc. Официальный сайт спецификации SOAP. [Электронный ре сурс]. – Режим доступа: http://www.w3.org/TR/2007/REC-soap12-part0 20070427/ (Дата обращения 25.01.2011) 44. Maurizio Lenzerini. Data Integration: A Theoretical Perspective// Молодая информатика. – – PODS 2002. pp. 233–246;

URL:

http://www.dis.uniroma1.it/~lenzerin/homepagine/talks/TutorialPODS02. pdf (дата обращения: 17.04.2013).

45. Добровольский А.Н. Интеграция приложений: методы, взаимодейст вия,топология, инструменты// Открытые системы. – 2006. – № 9;

URL:

http://www.osp.ru/os/2006/09/3776464/ (дата обращения: 17.04.2013) 46. Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных.

Полный курс = Database Systems: The Complete Book. — Вильямс, 2003. — 1088 с.

47.Ahmed K. Elmagarmid, Panagiotis G. Ipeirotis, Vassilios S.

Verykios. Duplicate Record Detection: A Survey. // IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, VOL. 19, № 1, JANU ARY 2007;

URL:

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.123.708&rank= (Дата обращения: 15.04.2013) 48.V. Andronikou, K. Mamouras, K. Tserpes, D. Kyriazis, T. Var varigou. Dynamic QoS-aware Data Replication in Grid Environments, El sevier Future Generation Computer Systems// The International Journal of – №4;

URL:

Grid Computing and eScience. 2012. обращения:

http://jcst.ict.ac.cn:8080/jcst/EN/Y2012/V/I2/256 (Дата 29.02.2013) 49.Microsoft Inc. MSDN: “Репликация SQL Server” [Электронный ресурс].

– Режим доступа: http://msdn.microsoft.com/ru-ru/library/ms151198.aspx (Дата обращения 01.05.2013) 50.Oracle Inc. Oracle. Оптимизация производительности.- M. Символ Плюc, 2006. – C. 51.B. Curtin, The Internet Society (1999). RFC 2640 - Internationalization of the File Transfer Protocol.[Электронный ресурс]. – Режим доступа:

http://tools.ietf.org/html/rfc2640 (Дата обращения 25.01.2011) 52.R. Fielding, The Internet Society (1999). RFC 2616 - Hypertext Transfer HTTP/1.1.[Электронный ресурс]. – Режим доступа:

Protocol - http://tools.ietf.org/html/rfc2616 (Дата обращения 25.01.2011) 53.R. Droms, The Internet Society (3.1997). RFC 2131 - Dynamic Host Con ресурс]. – Режим доступа:

figuration Protocol.[Электронный http://tools.ietf.org/html/rfc2131 (Дата обращения 25.01.2011) 54.Evans E. Domain-Driven Design - Tackling Complexity in the Heart of Software. — Addison-Wesley, 2004. — p. 529.

55.Domain Driven Design Community Официальный сайт [Электронный ресурс]. – Режим доступа: http://domaindrivendesign.org/ (дата обраще ния: 10.01.2013).

56.David Laribee. Введение в проблемно-ориентированное проектирова ние// MSDN Magazine. – 2009. - № 2;

URL: http://msdn.microsoft.com/ru ru/magazine/dd419654.aspx (Дата обращения: 15.12.2011) 57.Bloch, Joshua. Effective Java (2nd edition). Addison-Wesley. 2008. pp. 58.Lior Malka. How to Design API for Cryptographic Protocols. [Электрон ный ресурс]. – Режим доступа:

(Дата обращения:

http://www.lior.ca/publications/api_design.pdf 10.01.2013).

59.Shelly, Gary. Systems analysis and design. Boston, MA: Course Technol ogy, Cengage Learning. 2011. p. 60.R. Rivest, The MD5 Message-Digest Algorithm. RFC 1321 - Internationali zation of the File Transfer Protocol.[Электронный ресурс]. – Режим досту па: http://tools.ietf.org/html/rfc1321 (Дата обращения 25.01.2011) 61.Bruce Schneier, “Applied cryptography: Protocols, Algorithms and Source Code in C”, John Wiley&Sons, 62.W. David Schwaderer “C Programmer’s Guide to Netbios”, Howard W.

Sams&Company, 63.Гостехкомиссия России, “Руководящий документ: Защита от несанк ционированного доступа к информации. Термины и определения.” – М.:

Военное издательство, 1992.

64.Clark D., Wilson D. A comparison of Commercial and Military Computer Security Policies / Proce. Of the 1987 IEEE Symposium on Security and Pri vacy. – Oakland. Cal., 1987.

65.Шишкин К.Н. Бизнес-план мобильного приложения [Электронный ре сурс]. – Режим доступа: https://smartmarket.net/static/media/projects /requests/docs/77/Business-plan-TIN.pdf (Дата обращения: 01.09.2011) 66.Samuelson P., Scotchmer S. The Law and Economics of Reverse Engineer ing // The Yale Law Journal, Vol. 111, No. 7 (May, 2002), pp. 1575- 67.Мартин Фаулер. Рефакторинг. Улучшение существующего кода = Refactoring: Imptoving the Design of Existing Code. – М.: Символ-Плюс, 2008.

68.Мартин Фаулер. UML. Краткое руководство по стандартному языку объектного моделирования. – М.: Символ-Плюс, 2006 г. - С. 69.Хассан Гома. UML. Проектирование систем реального времени, рас пределенных и параллельный приложений, 2-е издание. – М.: ДМК Пресс, 2011г. – С. 70.С.А. Трофимов. CASE-технологии. Практическая работа в Rational Rose. – М.: БИНОМ, 2002 г. – С. Приложение 1. Примеры конечных автоматов, описывающие жизненный цикл исполнительных документов Опубликовать Создавший ЗАО отв. за ИД получает роль "Владелец" Прочие условия:

для этого ЗАО 1. Обязательные поля:

* Исполнитель;

* Ведущий по теме;

Добавить ЗАО Принять * Нач. с. программирования;

{роль: Отв. за Предварительно должны быть * Нач. с. проектирования;

ИД} получены подписи:

* Нач. отдела;

1. Исполнитель.

Черновик * Изделие;

2. Ведущий по теме.

* Дата начала;

3. Нач. с. программирования.

2. Должны быть указаны этапы.

Опубликовать 4. Нач. с. проектирования.

{Роль: Владелец} 5. Нач. с. изготовления.

Аннулировать 6. Согласующий (если указан).

{роль: Владелец || Отв.за ИД} Подготовлен [подписание] {роль: Начальник отдела} и [подписание] {роль: Начальник дата начала работ даты отдела} подписи Начальника отдела Аннулировать {роль: Владелец || [отмена подписи] Отв.за ИД} {роль: Начальник Принят отдела} Начать работу {роль: Отв. за ИД || Начальник отдела} [отмена подписи] Аннулировать {роль: Начальник отдела} {роль: Владелец || и работы с документом не Отв.за ИД} проводились В работе Автоматическая процедура при утверждении последнего связанного ЗАЗ Промежуточное состояние, указывающее на то, что Работы завершены работы по всем связанным ЗАЗ завершены (все связанные ЗАЗ Утвердить в состоянии "Утвержден" {Роль: Начальник или "В архиве" Утвердить отдела} и все ЗАЗ {Роль: Начальник утверждены отдела} Отменить утверждение ЗАО нельзя В архиве Аннулирован Рис. I - Исполнение Заявки на доработку БПО Создавший ОПР Отв. за ИД или Отв. за ПО получает роль "Владелец" для этого ОПР Добавить ОПР {роль: Отв. за ПО Опубликовать || Отв. за ИД} Обязательные поля:

* Автор отчета;

* Исполнитель;

Черновик * Утверждающий;

Принять Опубликовать Предварительно должны {роль: Владелец} быть получены подписи:

1. Исполнитель.

2. Согласующий (если указан).

Подготовлен Аннулировать {роль: Владелец || Отв. за ПО|| Отв. за ИД} [отмена подписи] [подписание] {роль: Утверждающий} {роль: Утверждающий} В работе Аннулировать {роль: Владелец || Отв. за ПО|| Отв. за ИД} Закрыть Автоматическая {роль: Утверждающий} процедура утверждения ЗАЗ, ЗАО на основании данного ОПР {Все ЗАЗ и ЗАО утверждены} Аннулирован Закрыт Рис. II - Исполнение документа «Отчет тестирования БПО»

Приложение 2. Экспериментальные данные для сравнительно го анализа шардинга баз данных в информационных системах с повышенным требованием к качеству кода Таблица 1. Сводная таблица результатов стресс-тестирования разных мо делей шардинга Количество 50 100 500 1,000 3,000 5, документов (тыс) 1 2 3 4 5 6 Один сервер (классическое размещение) Среднее время записи документа 8 8 9 9 9 Среднее время модификации документа 9 9 12 17 27 Среднее время удаление документа 4 5 5 9 14 Среднее время поиска документа 5 7 12 20 39 Вертикальный шардинг Две копии MS SQL Среднее время записи документа 8 8 9 9 9 Среднее время модификации документа 9 9 12 13 17 Среднее время удаление документа 4 5 5 8 14 Среднее время поиска документа 5 7 12 19 40 Три копии MS SQL Среднее время записи документа 8 8 9 9 9 Среднее время модификации документа 9 9 12 14 18 Среднее время удаление документа 4 5 5 8 12 Среднее время поиска документа 5 7 12 19 33 Четыре копии MS SQL Среднее время записи документа 8 8 9 9 9 Среднее время модификации документа 9 9 12 14 17 Среднее время удаление документа 4 5 5 9 12 Среднее время поиска документа 5 7 12 18 27 Пять копии MS SQL Среднее время записи документа 8 8 9 9 9 Среднее время модификации документа 9 9 12 13 15 Среднее время удаление документа 4 5 5 8 12 Среднее время поиска документа 5 7 12 17 26 Шесть копии MS SQL Среднее время записи документа 8 8 9 9 9 Среднее время модификации документа 9 9 12 13 16 Среднее время удаление документа 4 5 5 8 11 Среднее время поиска документа 5 7 12 17 27 Окончание Таблицы 1 2 3 4 5 6 Горизонтальный шардинг Две копии MS SQL Среднее время записи документа 8 8 9 9 9 Среднее время модификации документа 9 9 12 13 17 Среднее время удаление документа 4 5 5 8 14 Среднее время поиска документа 5 7 12 19 40 Три копии MS SQL Среднее время записи документа 8 8 9 9 9 Среднее время модификации документа 9 9 12 13 16 Среднее время удаление документа 4 5 5 7 9 Среднее время поиска документа 5 7 12 19 25 Четыре копии MS SQL Среднее время записи документа 8 8 9 9 10 Среднее время модификации документа 9 9 12 14 18 Среднее время удаление документа 4 5 5 8 9 Среднее время поиска документа 5 7 12 17 20 Пять копии MS SQL Среднее время записи документа 8 8 9 9 9 Среднее время модификации документа 9 9 12 13 15 Среднее время удаление документа 4 5 5 7 9 Среднее время поиска документа 5 7 12 16 20 Шесть копии MS SQL Среднее время записи документа 8 8 9 9 9 Среднее время модификации документа 9 9 12 14 17 Среднее время удаление документа 4 5 5 7 9 Среднее время поиска документа 5 7 12 16 19 Все замеры приведены в миллисекундах.



Pages:     | 1 ||
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.