CC BY
65
УДК 519.711.2:72
УМИТ ИСИКДАГ (UMITISIKDAG),
Бейкент университет,
кафедра технологии программирования,
Аязага, Стамбул, Турция
ШАБЛОНЫ ПРОЕКТИРОВАНИЯ
ДЛЯ СЕРВИСНО-ОРИЕНТИРОВАННЫХ АРХИТЕКТУР НА ОСНОВЕ BIM-ТЕХНОЛОГИЙ"
В настоящее время реализация комплексных строительных проектов информационного моделирования объекта является процессом управления проектом общей информационной магистрали. В ближайшем будущем информационные модели зданий (BIM) будут использоваться в качестве уникальных ресурсов для обеспечения бесперебойной интероперабельности на уровне данных, что существенно ускорит процессы жизненного цикла объекта. В связи с этим возможность совместного использования моделей BIM в данной отрасли становится важной и помогает решить проблемы низкой эффективности и продуктивности информационных систем (ИС). С другой стороны, в новых архитектурах ИС широко применяется сервисная и ресурсная ориентация в плане обеспечения взаимодействия в распределенных средах. В статье приведены три шаблона проектирования, которые облегчат обмен информацией на основе технологий BIM через Интернет и совместное использование моделей BIM на основе веб-технологий. Разработаны паттерны для формализации подходов при взаимодействии с общедоступными моделями BIM через Интернет. Первый паттерн - BIM AJAX - объясняет, как методы AJAX могут применяться для извлечения данных из моделей BIM. Второй паттерн -BIM SOAP Facade - обеспечивает стандартный крупномодульный интерфейс для доступа к многоаспектным моделям BIM через Интернет. Третий паттерн - RESTful BIM -конкретизирует, как системы, основанные на BIM-технологиях, используют (ресурсноориентированную) архитектуру REST. Статья начинается с общего представления информационных моделей зданий с описанием их характеристик и функций. Далее показаны традиционные подходы к обмену моделями BIM и их общему использованию. В конце статьи рассмотрены три разработанных шаблона проектирования.
Ключевые слова: информационное моделирование зданий (BIM); протокол REST; протокол SOAP; паттерн AJAX; интеграция; веб-сервисы.
* Статья переведена и опубликована в «Вестнике ТГАСУ» согласно Лицензионному соглашению с издательством Elsevier от 11 марта 2013 г. № 3106250230954.
В статье рассматривается возможность совместного использования информационных моделей зданий (BIM) в качестве уникальных ресурсов для обеспечения бесперебойного обмена данными через Интернет, что позволит ускорить процессы проектирования и контроля за состоянием зданий и сооружений.
Применение рассматриваемых технологий в архитектурно-строительном проектировании представляет значительный интерес, но требует адаптации к российским условиям.
© 2012 Elsevier B.V. Авторские права защищены © Умит Исикдаг (Umit Isikdag), 2013 © Перевод на русский язык, оформление. ТГАСУ, 2013 © Издание, распространение на территории РФ. ТГАСУ, 2013
Введение
Информационное моделирование объекта стало основной областью научных исследований в архитектурно-строительной отрасли для решения проблем, связанных с информационной интеграцией и интероперабельностью. Основной причиной реализации информационных моделей зданий (моделей В1М) явилась, главным образом, возможность эффективного обмена информацией и совместимость различных приложений, применяемых в архитектурно-строительной отрасли на протяжении всего жизненного цикла здания. В настоящее время информационное моделирование здания является процессом управления проектом на основе общей информационной магистрали, где модели В1М выступают в роли ключевых ресурсов при предоставлении интероперабельности на уровне данных.
Сегодня сервисная и ресурсная ориентация широко применяется для обеспечения взаимодействия в распределенных средах. В этой связи вебсервисы могут быть определены как «программный компонент или интерфейс для обеспечения межкомпьютерного взаимодействия через Интернет». Вебсервис должен иметь веб-интерфейс, описанный в машинно-обрабатываемом формате. Сервисно-ориентированная архитектура может состоять из взаимодействующих компонентов (сервисов), которые можно вызвать и чьи описания интерфейса можно опубликовать и обнародовать [1]. В настоящее время разработки Интернет-технологий и программного обеспечения привели к возникновению сервисно-ориентированных архитектур, что сделало возможным взаимодействие удаленных приложений (использование функций других программных компонентов в качестве их собственных функций) с помощью применения их стандартных веб-интерфейсов. Сервис-ориентация (и вебсервисы) позволяют ослабить увязку приложений через Интернет, что означает взаимодействие нескольких приложений без необходимости иметь данные об их рабочих средах. Каждое из этих приложений (или программные компоненты), участвующее в таком веб-взаимодействии, как сервис данных, компонентов или приложений, известно как веб-сервис.
В последнее время сервисно-ориентированные архитектуры де-факто становятся критериями интеграции приложений, основанных на вебтехнологиях. Применение веб-сервисов W3C происходит все чаще, поскольку растет потребность в связи между приложениями и работоспособностью. Организации могут извлечь пользу из сервисно-ориентированных архитектур, объединив службы, разработанные внутри компании и вне ее, наряду с обеспечением стандартных способов взаимодействия между различными программными приложениями, работающими на разнообразных гетерогенных платформах через Интернет [2].
Требования к модельно-ориентированным веб-сервисам. Несмотря на то, что в наше время основным направлением в индустрии программного обеспечения является интероперабельность посредством веб-сервисов, архитектурно-строительная отрасль все еще не полностью использует сервисноориентированные архитектуры, т. к. до сих пор сосредоточена на уровне данных (т. е. на интеграции с использованием обмена файлами и информацион-
ным массивом). Напротив, последние исследования в данной области [2-4] направлены на применение веб-сервисов для интеграции архитектурностроительных моделей (моделей В1М) и предлагают интеграцию модельноуправляемых и моделирующих сервисно-ориентированных архитектур с целью эффективного использования архитектурно-строительных моделей/моделей В1М в средах групповой деятельности. Кроме того, новейшие исследования предлагают, чтобы (семантические) веб-сервисы также играли ключевую роль в интеграции и интероперабельности, одновременно способствуя сервисно-ориентированным моделирующим архитектурам [5-7]. Например, СЬп8йап880п и др. [6] утверждают, что одним из самых серьезных препятствий эффективного внедрения информационно-телекоммуникационных технологий (ИКТ) в архитектурно-строительную отрасль являются недостающие онтологии, как на деловом уровне, так и на уровне Интернета. Согласно Акте и др. [5], семантические веб-сервисы могут служить мульти-доменной (САБ/ОК) совместимости данных на семантическом уровне. Rezgui и др. [7] упоминают, что архитектурно-строительная отрасль должна переходить от интеграции приложений по обработке данных к интеграции, основанной на онтологиях, и предлагают архитектурные схемы совместной работы предприятий на основе семантических веб-сервисов с целью обеспечения интеграции, основанной на онтологиях. Кроме того, архитектурно-строительная отрасль видит такие ИКТ, как моделирующие веб-сервисы ROADCON [8] и Start-CON [9], в качестве необходимого условия для перспектив интеграции архитектурно-строительных систем.
Итак, оба подхода к интеграции, предусмотренные для архитектурностроительной отрасли как: 1) предоставляющие сервисно- и модельноориентированные архитектуры и 2) интеграция на основе семантических вебсервисов, основываются на веб-сервисах и сервисно-ориентированных архитектурах. Таким образом, принимая во внимание последние исследования и перспективы ИКТ в архитектурно-строительной отрасли, можно утверждать, что в ближайшем будущем для проведения (модельно-ориентированной и семантической) системной интеграции в архитектурно-строительной отрасли будет необходимо внедрение моделирующих или семантических вебсервисов.
Метод. Исследования, представленные в данной статье, сосредоточены на обеспечении и содействии интероперабельности архитектурностроительных систем посредством модельно-ориентированных веб-сервисов и направлены на определение набора паттернов для ускорения сервисно-и модельно-ориентированных архитектур и сервисно- и модельноориентированной интероперабельности в архитектурно-строительной отрасли. Разработке таких моделей способствовала растущая эффективность взаимодействия между моделями В1М посредством сервисно-ориентированных архитектур, чем обеспечивалась эффективная визуализация моделей В1М (со стороны пользователя), способствующая безупречному человеко-машинному взаимодействию, независимо от пользовательской среды.
Реализованный метод исследования включает в себя триангуляцию обзоров литературы (технологий) и задачи по разработке паттерна. Первый этап
исследований сосредоточен на пересмотре основных понятий моделей BIM и подходов к совместному использованию и обмену моделями. Затем рассматриваются методы системной интеграции. Обзор технологий, включенный в исследования, охватывает оценку технологий по установлению и внедрению сервисно-ориентированных архитектур. Два основных архитектурных стиля сервис-ориентации - протоколы и стандарты SOAP и REST - изучались на втором этапе наряду с AJAX-технологией. Заключительный этап исследований включает определение веб-сервисных паттернов на основе: 1) AJAX и 2) двух исследуемых архитектурных стилей.
Первый паттерн - BIM AJAX - объясняет, как технология AJAX может применяться для извлечения данных из моделей BIM. Второй паттерн - BIM SOAP Facade - сосредоточен на подключении интероперабельности через стандартный веб-интерфейс в объектно-ориентированной среде. Третий паттерн - RESTful BIM - сосредоточен на подключении интероперабельности через веб-интерфейс без запоминания состояния в ресурсно-ориентированной среде. Эти три паттерна обращены к трем разным модельно-ориентированным механизмам, которые могут применяться для взаимодействия с моделями BIM через Интернет. Первый паттерн использует стандартный запрос JavaScript/XML для связи с моделями BIM через НТТР протокол, в то время как два последних - метод веб-сервисов. В следующем разделе представлено краткое описание общих положений, а в последних конкретизируются вышеперечисленные паттерны.
1. Информационные модели здания
1.1. Определение, характеристики и функции
Метод реализации комплексных строительных проектов (РКСП), недавно появившийся в США, отражает всемирное мнение в отношении управления объектом в течение всего срока эксплуатации и внедрения проекта в архитектурно-строительную отрасль [10]. РКСП способствует своевременному применению знаний и опыта в проекте и требует активного привлечения ключевых участников. Рабочее определение РКСП [11] заключается в том, что информационное моделирование здания важно при коллективной работе, необходимой для РКСП. Вклад комплексной бригады, связанной с инструментами технологии BIM (для моделирования и имитации проекта), позволяет завершить дизайн на более высоком уровне еще до начала этапа документирования. Таким образом, при РКСП проект определяется и до начала строительства совершенствуется до более высокого уровня, обеспечивая его более высокую эффективность и короткие сроки. Как упоминалось в Underwood и Isikdag [10], при реализации комплексных строительных проектов информационное моделирование здания может быть определено как «процесс управления информацией на протяжении всего жизненного цикла здания (от замысла до разрушения), который сосредоточен, главным образом, на запуске и содействии полному циклу реализации проекта при совместном использовании цифровой 3D модели здания с развитой семантикой на всех стадиях жизненного цикла проекта и здания».
Несмотря на то, что информационное моделирование здания рассматривается как ключевое средство процесса РКСП, оно выходит за пределы управления информацией в процессе РКСП, поскольку этот процесс заканчивается стадией ликвидации, за которой следует строительство, в то время как процесс информационного моделирования здания продолжается даже после стадии разрушения (размещения) как процесс управления знаниями для будущих проектов. Процесс информационного моделирования здания уникален, поскольку базируется на цифровых моделях BIM общего доступа, интегрированных и интероперабельных. Таким образом, в то время как информационное моделирование здания должно определяться как процесс и устройство, делающее возможным управление информацией, информационная модель здания может быть определена как «(набор) цифровой(-ых) 3D модели(-й) здания с развитой семантикой, которая(-ые) образует(-ют) основу процесса информационного моделирования здания».
Модели BIM известны как изобилующие данными; интеллектуальные параметрические цифровые представления объекта, изображения и данные из которых, необходимые для различных пользовательских целей, извлекаются и анализируются для генерирования информации, нужной для принятия решений и совершенствования процесса разработки объекта [12]. Дальнейшие определения информационного моделирования зданий и информационных моделей зданий (модели BIM) можно найти в работах [13, 14]. В этих источниках информационное моделирование рассматривается как новый способ создания, совместного использования, обмена и управления информацией на протяжении всего жизненного цикла объекта.
Isikdag и др. [15] дали окончательные характеристики информационным моделям как существующим в трехмерном, объектно-ориентированном, совокупном, пространственном источнике с развитой семантикой, открытом для обзора. В зависимости от среды, информационные модели здания могут иметь разные функции, например, выступать как средство связи (Space Linker), которое связывает макро- и микропространства города; средство интероперабельности (Interoperability Enabler), содействующее использованию общедоступной информации и программного обеспечения различными пользователями; архив данных (Data Store), в котором хранятся данные в течение всего жизненного цикла объекта; средство снабжения (Procurement Facilitator), которое ускоряет решение некоторых проблем в отношении закупок в течение жизненного цикла объекта; средство обеспечения коллективного сотрудничества (Collaboration Supporter), поддерживающее совместное использование и управление данными, полученными в режиме реального времени; процессная модель (Process Simulator), ускоряющая процессы моделирования строительства (в «-размерном имитационном пространстве); системный интегратор (System Integrator), который объединяет несколько информационных систем во всей строительной отрасли; информационные сервисы (Building Information Service), которые могут предоставлять информацию по требованию в режиме реального времени через Интернет; инструмент реализации экологического проектирования (Green Design Enabler), проводящий углубленный анализ для разработки и строительства экологически благоприятных
(энергоэффективных) зданий; спасательное средство (Life Saver), облегчающее решение ключевых задач при ликвидации чрезвычайных ситуаций. В настоящее время попытки стандартизации ключа безопасности в области BIM-технологий сводятся к Industry Foundation Classes (IFC; ISO PAS 16739) [16] - формату данных с открытой спецификацией, которая не контролируется ни одной компанией или группой компаний, и CIMSteel Integration Standards 2 (CIS/2) [17] - стандартом интеграции, принятым Американским институтом по разработке стальных конструкций в качестве формата обмена данными между программами проектирования стальных конструкций.
1.2. Общедоступность и обмен данными: традиционные методы
Технологии BIM определяются объектной моделью (схемой BIM). Объектная модель на основе технологии BIM - это логическая структура данных (или модель данных), которая определяет логические объекты, свойства и взаимосвязи технологии BIM. Модель данных генерируется приложением (как правило, САПР или ПО технологии BIM) и хранится либо в физических файлах, либо в базах данных. Традиционные подходы к обмену и совместному использованию данных моделей BIM [15, 18] включают следующее:
Обмен файлами. Физический обмен файлами моделей BIM производится путем обмена физического файла BIM либо через физические средства (например, флэш-память), либо через компьютерные сети (например, Интранет или Интернет). Физический файл обычно генерируется САПР-приложением и может обмениваться между различными приложениями. Физический файл BIM может быть файлом XML или файлом ISO 10303 Part 21. Например, в настоящее время физические файловые форматы IFC Part 21, CIS2 Part 21и IFC XML позволяют обмениваться информацией через различные системы САПР и программные обеспечения Строительный анализ (Structural Analysis) и ТГВ (HVAC).
Интерфейсы приложений. Физический файл BIM может быть доступен с использованием Интерфейса программирования приложений (ИПП). Этот подход сосредоточен скорее на общем использовании данных, а не на их обмене и обычно происходит в двухуровневой архитектуре, где один уровень образуется ИПП. ИПП может предназначаться специально для технологии BIM или являться Стандартным интерфейсом доступа к данным (СИДД) ИПП (если технология BIM определяется использованием методов описания ISO 10303). Если физический файл является файлом XML, то модель может иметь общий доступ с использованием XML-интерфейсов (например, ИПП, поддерживающими объектную модель документов - модель DOM). Осуществляется коммерческая (открытая) реализация этих ИПП для формата IFC, предназначенного для моделей BIM IFC, известных как IFC-плагины, IFC-надстройки, IFC-инструменты DLL, IFC-инструменты, IFC-инструментарий (IFC plug-ins, IFC add-ons, IFC Engine DLLs, IFC Tools, IFC Toolboxes) [19] и т. д.
Общедоступные базы данных. Общедоступные базы данных могут хранить информацию, охватывающую многие аспекты жизненного цикла в архитектурно-строительной отрасли. Преимущество хранения модели BIM в общей базе данных состоит в том, что многочисленные приложения могут
иметь доступ к модели данных и использовать такие параметры баз данных, как обработка запроса и создание бизнес-объекта. Модели BIM хранятся в реляционной или, в основном, в объектной базе данных. Схемы BIM могут быть схемами XML (XTD) или ISO 10303 EXPRESS. Базы данных могут импортировать физические файлы модели (файлы XML или Part 21) или создавать примеры объекта с помощью стандартного (ODBC) или запатентованного интерфейса доступа к данным, СИДД (SDAI). Затем модель данных может быть запрошена при помощи интерфейсов баз данных.
Несмотря на то, что традиционные методы использовались в течение многих лет и большинством поставщиков программного обеспечения, недавние исследования, включающие внедрение в проект SABLE [3] будущих сценариев интеграции технологии BIM, испытанных в Открытом геопростран-ственном консорциуме [4], в предложенной архитектуре SOA4BIM [2] и в открытом BIM-сервере, поддерживающем сервисно-ориентированные архитектуры [20], показали, что в ближайшем будущем модели BIM будут применяться в рамках сервис-ориентированной архитектуры (BIM СОА), а вебсервисы BIM станут неизбежным требованием к функционированию информационных систем в архитектурно-строительной отрасли.
2. Интеграция, веб-сервисы и AJAX
Системная интеграция может быть определена как стратегический подход к связыванию воедино многих информационных систем с целью поддержания их способности к обмену информацией и новыми процессами в реальном времени [21]. Обзор литературы в области интеграции систем программного обеспечения выделил два основных подхода к интеграции [21-25]. Первый подход - информационная интеграция - позволяет данным перемещаться между исходными и целевыми системами без привлечения прикладной логики систем. Методы информационной интеграции можно объединить в 3 различные категории, такие как обмен информацией, совместное использование информации и преобразование данных. В информационной интеграции основополагающий вопрос об обмене или совместном использовании информации звучит так: «Сколько необходимо действий, чтобы переместить данные из исходной системы в целевую?» [26]. Если несколько приложений требуют информацию из исходных данных, то рекомендуется обмен данными. В противном случае (когда многочисленные приложения требуют использования одной и той же информации) применяется совместное использование данных в качестве метода интеграции. Преобразование данных может потребоваться как при сценарии обмена, так и сценарии совместного использования данных.
Если система данных о цели не сможет заменить функциональность исходной системы (хотя и содержит существенный объем информации исходной системы) в результате информационной интеграции, то системы должны быть объединены с помощью методов интеграции сервисов и приложений.
Даже при том, что в настоящее время архитектурно-строительная отрасль сосредоточена на информационной интеграции, необходимость в инте-
грации сервисов и приложений постоянно растет, поскольку функциональные назначения CAD/BIM приложений расходятся с каждым днем и, как правило, совместного использования данных не достаточно для замены функционала, предусмотренного одним приложением для другого.
Интеграция сервисов и приложений обеспечивает интеграцию путем взаимодействия компонентов системы. Методы интеграции сервисов и приложений можно сгруппировать в 4 различные категории, такие как вызовы удаленных процедур (Remote Procedure Calls), пересылка сообщений (Messaging), распределенные объекты (Distributed Objects) и веб-сервисы и порталы (Web services and Portals). В следующих разделах будет подробно рассмотрена интеграция с веб-сервисами.
В дополнение к определениям, данным в предыдущем разделе, вебсервис можно назвать «ресурсом, который может быть вызван через Интернет или стандартные веб-интерфейсы с использованием стандартизированных сообщений». Веб-сервисы предусматривают стандартные веб-интерфейсы для унаследованного и текущего приложения, чтобы задействовать стандартные протоколы обмена данными и вывести их функционал на стандартные вебинтерфейсы.
Исследователь He [27] указал, что существует два требования для внедрения веб-сервисов: 1) интерфейсы должны основываться на таких Интернет-протоколах, как HTTP, FTP и SMTP и 2) кроме приложений, считывающих двоичные данные, сообщения должны быть в формате XML. Веб-сервисы обладают двумя характерными свойствами: слабая связь и прозрачность сети [28].
Слабая связь. В традиционной распределенной среде компьютеры имеют сильную связь, т. е. каждый компьютер связан друг с другом в распределенной среде посредством комбинации патентованных интерфейсов и сетевых протоколов. Веб-сервисы, напротив, имеют слабую связь, т. е. когда часть программного обеспечения выводится в качестве веб-сервиса, то довольно просто перебросить ее на другой компьютер.
Прозрачность сети. Поскольку потребители и провайдеры вебсервисов отсылают сообщения друг другу с помощью открытых Интернет-протоколов, веб-сервисы предлагают полную прозрачность сети всем, кто ими пользуется. Прозрачность сети относится к способности веб-сервисов быть активными в любом месте сети или группы сетей, не оказывая влияния на их функционирование. Поскольку каждый веб-сервис имеет свой собственный универсальный индикатор ресурсов, то они обладают одинаковой приспособляемостью к веб-сайтам в Интернете.
В наше время существует два стиля веб-сервисов: SOAP и REST. SOAP - это стиль веб-сервиса, основанный на использовании протокола SOAP (простого протокола доступа к данным) для обмена сообщениями в формате XML между сетями с применением протокола HTTP (протокола передачи гипертекста). REST - это архитектурный стиль, при котором вебсервис функционирует путем вызова различных веб-ресурсов.
Протокол SOAP. В настоящее время SOAP является языком лингва франка веб-сервисов. Принцип SOAP заключается в удаленном вызове посредством пересылки сообщений через Интернет. Протокол SOAP имеет два
ограничения: 1) кроме приложений, считывающих двоичные данные, сообщения должны выполняться посредством SOAP и быть сформатированы по его правилам; 2) описание (объявленный интерфейс) сервиса должно быть определено на WDSL (язык описания веб-сервисов), т. е. на языке XML, необходимом для описания и размещения веб-сервиса SOAP.
Передача состояния представления (REST). Термины веб-сервисы REST и RESTful были приняты в докторской диссертации Роя Филдинга [29]. Как объясняют Pautasso и др. [30], изначально термин REST был введен как архитектурный стиль для построения крупных распределенных гипермедийных систем. Согласно стилю REST, веб-сервис может быть построен на ресурсах (т. е. на всем, что доступно цифровым способом через Интернет), их именах (определяемых универсальными индикаторами или URL), представлениях (метаданые/данные о текущем состоянии ресурса) и связях между представлениями. Принцип REST заключается в пересылке удаленных запросов представлениям веб-ресурсов.
Большинство веб-сервисов, реализованных в настоящее время, трансформировано из интерфейсов унаследованных систем. Как упоминается в работе Pulier и Taylor [28], описание веб-сервиса чаще всего запускает старое программное обеспечение (или уровень данных унаследованной системы) с целью получения Интернет-запроса и отклика на него для его функционального назначения. Несмотря на то, что технология AJAX не может быть классифицирована как метод интеграции, она может применяться для облегчения сетевых взаимодействий, а применение AJAX при извлечении модели BIM через Интернет может ускорить времяёмкость систем, основанных на информационном моделировании объекта. AJAX (Asynchronous JavaScript and XML) - это общее название, присвоенное группе методов вебпрограммирования, используемых, главным образом, на стороне клиента. Согласно Garrett [31], AJAX включает: 1) дисплей с динамическим отображением и взаимодействием с использованием модели DOM; 2) обмен и преобразование данных с применением XML и XSLT; 3) асинхронное извлечение данных с применением XMLHttpRequest; 4) язык JavaScript, объединяющий все вместе. Приложение AJAX исключает природу взаимодействия пуск-остановка-пуск-установка в Интернете путем ввода посредника Ajax engine между пользователем и сервером. Вместо загрузки веб-страницы в начале сеанса браузер загружает Ajax engine, написанный на языке JavaScript. Этот инструмент отвечает как за предоставление интерфейса таким, как видит его пользователь, так и за связь с сервером от имени пользователя и разрешает взаимодействие пользователя с приложением для асинхронного и независимого сообщения с сервером.
3. Паттерны
Шаблон проектирования программного обеспечения определяется двумя аспектами. Во-первых, паттерн обозначает проблему, которая обычно возникает при проектировании и внедрении программного обеспечения (требования к паттерну), а затем описывает решение общей проблемы таким обра-
зом, чтобы его можно было многократно использовать в различных ситуациях (т. е. в других разработках ПО). Шаблон проектирования программного обеспечения обычно представляет собой повторяющуюся структуру сообщающихся компонентов, которая решает главную проблему проектирования в рамках определенного контекста [32, 33]. Паттерн может являться шаблоном для решения задач в области проектирования ПО, а также заданным и признанным формализованным описанием взаимодействия между программными компонентами с целью улучшения разработки ПО. Применение моделей в разработке ПО помогает разработчикам в принятии проектных решений: і) когда они сталкиваются с обычными проблемами в области разработки нового ПО или 2) когда они хотели бы ввести в разработку новые способы взаимодействия между различными уровнями или компонентами.
Несмотря на то, что в литературе [34] существует формализованное описание такого вида архитектуры, как «модель-представление-контроллер» (Model-View-Controller (MVC)), формальные архитектуры, поддерживающие применение модельно-ориентированных веб-сервисов, не являются общими для архитектурно-строительного ПО. Tаким образом, как только модели, описанные здесь, получают признание, они могут содействовать внедрению формальных архитектур в модельно-ориентированные веб-сервисы с целью облегчения взаимодействия сервис-сервис / приложение-сервис в рамках архитектурно-строительного ПО.
Tрадиционные подходы к общедоступным моделям и моделям обмена информацией в архитектурно-строительной отрасли, например с использованием моделей BIM (как пояснялось в предыдущем разделе), сосредоточены, в основном, на обмене физическими файлами между приложениями и на применении общедоступных центральных баз данных для выполнения CRUD-операций (создание/чтение /обновление/удаление) на этих моделях (моделях BIM). Более того, в настоящее время применение Model Views, архитектуры «модель-представление» (подгруппы технологии BIM, определенной согласно потребностям сценария обмена специальной информацией), способствует управлению информацией на основе технологии BIM в течение всего жизненного цикла объекта.
Последние НИОКР, такие как проект SABLE [3] и BIMServer [20], показали, что есть возможность использовать стили SOAP/REST веб-сервисов для получения информации из модели BIM. Применение сервисноориентированных подходов для получения информации из модели BIM поможет архитектурно-строительным приложениям при замене одного функционала на другой, когда одних общедоступных данных будет недостаточно для правильного межоперационного функционирования (т. е. выполнения функции другой системы, в качестве ее собственной).
Несмотря на то, что в литературе, касающейся данной области, приведены примеры совместного использования (центральных) баз данных и веб-сервисного стиля SOAP для получения информации из модели BIM, никто не занимался формализацией і) совместного использования распределенных моделей BIM и 2) сбора данных из общедоступных моделей BIM посредством Интернета. Хотя применение распределенных моделей BIM может показаться
технически сложным (поскольку это может вызвать проблемы с поддержкой версий и правами собственности), но при грамотном управлении можно получить значительные преимущества, увеличить уровень интероперабельности архитектурно-строительных приложений, предотвратить информационную перегрузку в общедоступных базах данных и обеспечить эффективное использование аппаратного обеспечения и сетевых ресурсов.
Следующие разделы приводят описание трех паттернов интеграции, предложенных в данных исследованиях для формализации, а именно архитектуры веб-сервисов на основе технологии BIM. Эти паттерны основаны на методах AJAX, архитектурных стилях SOAP и REST, которые в настоящее время используются в качестве основных. Первый паттерн предлагает, чтобы применение метода AJAX - взаимодействие с моделями BIM и их визуализация - содействовало коммуникации сред коллективных вычислений на основе веб-технологий. Второй паттерн (стиль SOAP) предоставляет возможности эффективного управления технологией BIM и архитектурой «модель-представление» с использованием стандартного набора веб-интерфейсов и сообщений. Третий паттерн (стиль REST) обеспечит описание всех объектов в модели BIM в качестве совокупности веб-ресурсов и представлений. Такое описание позволит пользователям получать информацию напрямую от каждого объекта, находящегося в модели BIM, не задумываясь о том, как и в каком виде хранится модель BIM.
3.1. Паттерн AJAX BIM
3.1.1. Необходимость и назначение
В настоящее время визуализация технологии BIM в Интернете осуществляется с помощью вычислительной клиент-серверной модели для взаимодействия моделей BIM. На практике в клиент-серверной модели используется общедоступная база данных или BIM (модель) сервер для хранения модели. Взаимодействие с моделью выполняется посредством стандарта CLI (ИПП) сервера. Последние исследования в области открытого проекта BIM-Server [20] также предусматривают интерфейсы SOAP и REST для взаимодействия с информационными моделями здания.
В отличие от разработок на стороне сервера, в настоящее время визуализация моделей BIM на основе веб-технологий (сторона клиента) наблюдается редко, т. к. визуализация стороны клиента затруднена из-за большого размера файлов моделей, передаваемых клиенту. Во-первых, отправка модели целиком (физический файл модели BIM) клиенту (для целей визуализации) -это очень трудоемкая задача для многих моделей BIM (размер файла для большинства этих моделей составляет 10-50 МБ). Для решения этой проблемы визуализация модели (с меньшим файловым размером) обычно передается клиенту в качестве графического файла, например в виде документов COLLADA или X3D. Фактически в этой ситуации невозможно тотчас получить информацию о свойствах объекта (во время просмотра графической модели), т. к. данное представление является лишь геометрическим и не содержит семантической информации.
Чтобы получить семантическую информацию относительно объектов, представленных в графической модели (например, материал стены), во время просмотра модели (например, когда кто-то желает изучить материал стены, наводя курсор на графическое представление стены) на сервер BIM посылается запрос относительно рассматриваемого объекта, а затем результаты запроса могут быть переданы обратно клиенту для получения информации. Хотя такой вариант в настоящее время принят в качестве оптимального, он потребует внедрения и конфигурации особого продукта (BIM сервера) на стороне сервера. Вдобавок в среде из 20 совместных пользователей, синхронно отсылающих запросы на сервер для получения информации о различных элементах здания, BIM сервер может реагировать чрезвычайно медленно или вообще прекратить отклик.
Для разрешения такой ситуации AJAX engine, внедренный в клиентскую среду, может взаимодействовать с XML-представлением модели BIM, расположенной на стандартном сервере HTTP для предоставления информации об объекте, рассматриваемом в графической модели. Tакой подход устранит необходимость внедрения продукта BIM сервера (для быстрой визуализации, которая требует лишь семантико-графического представления модели)
и, более того, обеспечит быстрое взаимодействие клиент-сервер в средах с многочисленными пользователями, т. к. структурированные запросы на стороне сервера в такой ситуации не потребуются.
3.1.2. Паттерн
Согласно предложенной архитектуре системы (рис. і), в паттерне AJAX визуализация XML модели BIM (например, файл формата IFCXML) будет располагаться на веб-сервере.
Веб-сервер в этом паттерне относится к стандартному серверу HTTP, который может отвечать на запросы AJAX (а не к продукту, специально разработанному для управления моделями BIM). AJAX engine на клиентской стороне не допустит асинхронного взаимодействия между пользователем и сервером, независимо от сообщения с сервером. Данный шаблон предлагает, чтобы AJAX engine, внедренный на стороне клиента, устранял потребность в выполнении структурированных запросов на стороне сервера каждый раз, когда возникает потребность в части информации относительно элемента объекта. Вместо этого запрошенная информация может быть легко передана клиенту при помощи технологии AJAX и предоставит описание объекта на стороне клиента.
Система, разработанная в соответствии с этим шаблоном, могла бы работать следующим образом. На первом этапе в результате запроса HTTP GET визуализация всей модели BIM будет передана с сервера клиенту в виде графического файла (COLLADA, X3D и т. д.). Передача графического файла будет быстрой, т. к. такое (COLLADA, X3D) представление модели BIM является только геометрическим. Затем многочисленные участники проекта на стороне клиента могут асинхронно изучать графическое представление модели. Как только пользователь запросит семантическую информацию относительно элемента объекта (стены), он сможет взаимодействовать с моделью, наводя
курсор или кликая мышью. Во время такого взаимодействия будет послан асинхронный запрос XML Http (AJAX) на сервер HTTP, после чего информация об особом элементе объекта (материале стены) будет отправлена клиенту в виде отклика в формате XML. Описание выбранного объекта будет предоставляться пользователю без перезагрузки веб-страницы (и, таким образом, без повторной передачи графического файла от сервера к клиенту).
BIM-клиент (вэб-браузер)
Графическая
модель
AJAX Engine
Описание
объекта
HTTP
запрос
Асинхронный запрос XMLHttp
XML
отклик
COLLADA
XML
файл
BIM файл XML
Веб-сервер
Рис. 1. Реализация паттерна AJAX BIM
Такая формализация коммуникации между клиентом и сервером гарантирует пересылку оптимального объема информации от сервера клиенту при каждом взаимодействии. Асинхронный способ сообщения с сервером существенно снизит время, необходимое для получения описания объекта в муль-тиклиентской среде, т. к. пропускная способность сервера и сети не будет использоваться синхронно всеми пользователями. Более того, поскольку потребность в структурированных запросах на стороне сервера будет устранена, производительность сервера также возрастет. Шаблон AJAX BIM будет наиболее полезен при быстрых визуализациях. Фактически, если возникнет потребность выполнения операций CRUD на моделях (через Интернет), то будет необходим набор формализованных SOAP веб-сервисов для их представления. Следующий паттерн демонстрирует, как можно выполнить передачу данных, а также выполнить и упростить операции CRUD в архитектурах, основанных на SOAP.
3.2. Шаблон Facade BIM SOAP
3.2.1. Необходимость и назначение
В настоящее время средства совместной работы на основе технологии BIM используют общую базу данных. В обозримом будущем применение общей базы данных не станет технически осуществимым, т. к. это вызовет информационную перегрузку общей базы данных (в которой находится модель и различные представления), а также перегрузку сетевого трафика на стороне сервера. Сегодня приложения BIM используют общие базы данных. Фактически увеличение объема данных в моделях BIM наряду с необходимостью приложений заменять функции друг друга и потребностью в коллективном виде работы вынуждает приложения сосредоточиться на преобразовании данных и интеграции уровня обслуживания. Архитектурный шаблон, имеющий дело с такими изменениями, должен обратиться к преобразованию данных и обеспечить простые и стандартные веб-интерфейсы для приложений BIM с целью выполнения действий на моделях CRUD с применением веб-технологий. Шаблон (BIM SOAP Facade), рассматриваемый в следующих разделах, сосредоточен на предоставлении интерфейса с применением стандарта SOAP и предлагает преобразование данных на стороне сервера.
3.2.2. Шаблон
Концепция обеспечения SOAP интерфейсов для информационных моделей здания не является новой. Целью проекта SABLE (простой доступ к обмену данными о жизненных циклах зданий), завершенного в 2006 г., было обеспечение веб-сервисов путем создания и применения SOAP интерфейсов, зависящих от домена, к модели IFC [3]. Фактически паттерн Facade для BIM SOAP, описанный ниже, представляет собой новый подход к взаимодействию с моделью BIM с помощью физических файлов BIM и баз данных, основанных на принципах шаблона Facade. Шаблон Facade BIM SOAP обеспечит управление распределенными базами данных общей модели BIM с помощью веб-сервисов SOAP. Перед тем как углубиться в рассмотрение данного шаблона, следует подытожить принципы самого шаблона Facade. Согласно Gang of Four [32], шаблон Facade предоставляет единый интерфейс ко всей подсистеме. Как объясняется в Shalloway и Trott [35], когда кому-то требуется новый (упрощенный) способ взаимодействия с системой (ресурсом) или необходимо использовать систему (ресурс) особым способом (например, применить трехмерное программное обеспечение для просмотра двухмерного), шаблон Fa?ade может быть использован для построения нового способа взаимодействия с этой системой. Шаблоны Facade можно использовать не только для создания упрощенного интерфейса в рамках функций (операций), но и для уменьшения количества программных компонентов, с которыми объект-клиент должен иметь дело (рис. 2).
Шаблон Facade BIM SOAP на один шаг опережает принципы шаблона Facade, доводя до уровня веб-сервисов, и предусматривает его для BIM приложений (рис. 3). Поскольку классы шаблона Facade генерируются в объектно-ориентированных системах, SOAP Facades тоже могут быть созданы в за-
висимости от аналогичных архитектурных принципов. Единственным различием между ними является то, что интерфейс SOAP Facades определяться в WSDL, что означает, что SOAP Facades может будут веб-сервисами высокого уровня, использующими веб-сервисы низкого уровня (здесь SOAP интерфейсы). Веб-интерфейсы низкого уровня могут взаимодействовать с любым видом системного компонента, включая файлы и базы данных. Ниже приведена реализация шаблона Facade SOAP в архитектуру системы, основанной на технологии BIM.
Рис. 2. Паттерн Facade
Как видно из рис. 3, в системе, разработанной в соответствии с BIM SOAP Facade, главными компонентами являются служба преобразования формата и серверная модель. Служба преобразования формата - это локальная служба или служба на уровне веб, доступ к которой можно получить через локальный И1II 1/веб ИПП (Local API/Web API) из BIM приложений или же внешний интерфейс может обеспечить человеко-машинное взаимодействие (HCI) со службой преобразования формата. Служба преобразования формата будет применяться для преобразования одного формата файла BIM (CAD DWG; форматы Sketch Design; CIS/2) в другой (IFC). Несмотря на то, что многие архитектурно-строительные приложения поддерживают стандартные модельные форматы (такие, как IFC), все еще необходимо преобразование между различными моделями (поскольку интероперабельность без потребности в преобразовании любых данных находится на ранней стадии развития в архитектурно-строительном ПО). Служба преобразования формата может быть реализована в веб-сервере (как ИПП) или как веб-сервис. Результатом службы преобразования формата станет физический файл BIM, который затем будет помещен в серверную модель.
Из-за проблем, относящихся к праву собственности и управлению обновлениями модели BIM, хранение самой модели BIM в качестве физического файла не является хорошей практикой при выполнении операций CRUD в моделях.
Рис. 3. Релизация шаблона BIM SOAP Facade
Таким образом, в этом паттерне предполагается, что BIM будет храниться (управляться) в пределах среды серверной модели. Технологии BIM будут применяться в серверных моделях (в средах хранилищ данных и управления ими, где операции CRUD будут выполняться посредством моделей BIM). Модель-представление (Model Views) технологии BIM может быть сгенерирована оперативно (по требованию) и храниться в серверной модели вместе с самой BIM или отдельно как физические файлы. Данные в моделях BIM и архитектура «модель-представление» станут доступны через интерфейсы SOAP для выполнения операций CRUD. В этом паттерне интерфейсы SOAP обозначены как веб-сервисы низкого уровня. Наконец, SOAP Facade будет действовать в качестве внешних интерфейсов интерфейса SOAP, поскольку он обеспечит упрощенные и формализованные способы взаимодействия с моделями BIM и серверными моделями. SOAP Facade поможет сократить количество SOAP интерфейсов, с которыми имеет дело клиент (ПО BIM) при взаимодействии с моделями. SOAP Facades также подключат интегрированное изображение различных информационных моделей и моделей BIM (модель-представление) (т. к. они могут сочетать интерфейсы нескольких информационных моделей и моделью-представлением). Функции, заявленные (выведенные) в SOAP Facades, будут просто взаимодействовать с моделями BIM и моделью-представлением для выполнения операций CRUD, что устранит потребность в информации о том, где находится BIM или в какой серверной модели она хранится. Более того, пользо-
вателям и клиентскому программному обеспечению не понадобится информация о структуре или схеме модели BIM.
Например, архитектура программного обеспечения, разработанная с учетом паттерна BIM SOAP Facade, легко выполнит запрос SOAP для преобразования модели CIS/2 в модель IFC с помощью службы преобразования формата без запрашивания какой-либо другой информации (такой, как запрос и передача классов, местоположение моделей, способ их хранения и управления и т. д.).
С другой стороны, частичное картографирование модели (например, рассматривается информация лишь о колоннах стального здания) может быть выполнено с помощью SOAP интерфейсов и компонентов доступа к данным (Data Access Components) (стандартных ИПП серверной модели или ИПП, разработанных для взаимодействия с моделями BIM/моделью-представлением, такими как инструментарий IFC или XMLDOM API), а конечный результат может храниться в виде модели BIM или модели-представлении. Паттерн BIM SOAP Facade предусматривает легкие в использовании, упрощенные механизмы выполнения операций CRUD и управление многочисленными моделями BIM через Интернет. Поскольку интерфейсы SOAP будут разработаны параллельно с требованиями прикладного домена, они будут редко (или никогда не будут) позволять получать данные от каждого объекта в модели BIM, что является единственным недостатком этого паттерна. Таким образом, приложение, которое требует сбора информации от каждого объекта модели BIM, не сможет получить эту информацию в архитектуре SOAP Facade, т. к. действия в отношении этих объектов ограничены правилами, определенными интерфейсом Facade. Например, приложение не сможет запросить объект IFC, основанный на его идентификаторе (ID), если данное действие не определено интерфейсом Facade. Однако модель BIM RESTful, описанная ниже, устраняет этот недостаток BIM SOAP Facade при помощи метода сбора данных от каждого объекта BIM.
Проверка правильности паттерна была проведена путем внедрения, то есть путем применения интерфейса SOAP, предусмотренного BIM Server [20]. При проверке правильности был разработан простой сервис WCF SOAP для Microsoft Visual Studio 2010 (который образует SOAP Facade) на основе интерфейса SOAP BIM Server. Стадии разработки были следующие. Во-первых, сервис SOAP, предусмотренный BIM Server, был зарегистрирован как справочная служба (рис. 4) для генерации SOAP Facade.
Как правило, SOAP Facade предусматривает меньше способов, чем оригинальный веб-сервис BIM в BIM сервере. В данном исполнении используется SOAP Facade с одним способом. Facade с одним способом - это SetProject-Name (задать имя проекту) и, как только Facade запрашивается из Интернета, проекту BIM сервера присваивается имя «Пробный проект». Затем служба Facade SOAP реализуется на стороне сервера.
Язык WSDL разработанного паттерна Facade SOAP показан на рис. 5.
На последней стадии проверки правильности паттерна сервис Facade SOAP используется в рамках простой формы для присвоения имени проекту (рис. б). Как только пользователь начинает взаимодействовать с формой, имя
проекта «Пробный проект» задается путем вызова метода через Интернет (т. е. SOAP Facade).
Рис. 4. Службы интерфейса SOAP для BIM Server
З.З. Паттерн RESTful BIM
3.3.1. Необходимость и назначение
Как отмечалось ранее, несмотря на то, что паттерн BIM SOAP Facade облегчает: 1) передачу одного формата модели BIM другому и 2) предоставляет простой единый когерентный интерфейс многочисленным моделям и представлениям, сбор данных от каждого объекта в модели BIM невозможен в паттерне Facade SOAP.
- <widl:definitions name="ServiceГ targ«tNam*ipac*= http tempun org ">
- <xsd: schema targetNamespace^ 'http tempun otg Imports"x xsd:schema>
- <wsdl: message name®"I$ervicel_$etProjectName_lnputMessage''X4vsdl:message>
- <tndl:mftta{f nam**"IServicel_SetProjectName_OutputMes»age’*x wsdl:m**sage>
- <tvsdl:portTYp« nam**''IServicel"x.mdl:portTYp*>
- *-\\sdl:binding name- BasicHttpBindim? ISetMcel ' Ispe—"tns ISet\icel">
<soap:bindiujj transport- http schcmas xralsoap.oig soap http' >
c soap operation soap.\ction="hnp tempun.org IServicel SetProjectName sfyle='document" >
- <wsdl:port name» BasicHttpBindinff lSen'icel" binding* tns BasicHttpBmding^Semcel^
<ioip:addmi location** http localhost 7293 Service l*vc">
Рис. 5. WSDL для SOAP Facade с одним способом
Рис. 6. Извлечение из приложения сервиса SOAP Facade
Следовательно, чтобы запустить сбор данных на уровне объекта, клиентскому программному обеспечению необходим мелкомодульный интерфейс с моделью BIM (схожий с базой данных интерфейса на уровне вызовов, CLI) на уровне Интернета.
Фактически разработка такого интерфейса для каждой модели BIM и модели-представления (особенно, когда модель-представление находится на уровне экземпляра (динамическом) будет нелегкой и потребует особых функций программы для оперативной выработки SOAP интерфейсов, т. е. языков WSDL (охватывающих каждый класс модели). Одним из решений этой проблемы является полное изменение архитектурного стиля, при этом подход SOAP остается в стороне, а на первый план выходит RESTful (ресурсноориентированный подход для создания мелкомодульных веб-интерфейсов для моделей BIM и модели-представлению). Третий паттерн RESTful BIM сосредоточен на описании всех объектов BIM в качестве веб-ресурсов с помощью архитектурного стиля REST. Поскольку этот паттерн основан на принципах архитектур RESTful, он был назван RESTful BIM.
3.3.2. Паттерн
Как показано на рис. 7, описание моделей BIM как веб-сервисов стиля REST может быть выполнено несколькими способами.
Рис. 7. Внедрение паттерна RESTful BIM
Первый способ - хранение BIM в серверной модели и автоматическое описание каждого объекта модели в качестве представления в веб-сервисе RESTful. Осуществление возможно с помощью ИПП, который обеспечивает представление объектов в серверной модели. Второй способ - применение ИПП REST Enabler для представлений экземпляров в модель-представление. В обоих случаях ИПП REST Enabler опишет REST-представления объектов в качестве веб-ресурсов. Поскольку в настоящее время почти нет программного обеспечения BIM, которое использовало бы сервисы REST без каких-либо дополнительных работ по программированию, программное обеспечение на основе технологии BIM было выбрано в качестве потребителя сервиса RESTful BIM. В данной версии паттерна сбор всей информации из сервиса RESTful BIM выполняется через веб-браузеры, но эта ситуация в ближайшем будущем изменится.
Хотя RESTful BIM предварительно используется на данный момент в экспериментальном и исследовательском ПО, в будущем ожидается, что готовое ПО для BIM обеспечит полную интеграцию с RESTful архитектурами. Описывая каждый объект модели BIM как REST, ресурс обеспечит мелкомодульный интерфейс модели BIM, который запустит клиентское приложение для сбора информации относительно единственного объекта в BIM.
Несмотря на то, что применение реляционных баз данных для хранения BIM не является традиционным, модель-представление может храниться в реляционных базах данных. Последние технологические разработки привели к созданию интерфейсов, позволяющих автоматически отображать объекты в реляционной базе данных для REST ресурсов. Таким образом, сегодня стало возможным автоматически генерировать REST ресурсы из модели-
представления, хранящейся в реляционной базе данных. Этот процесс довольно прям и прост и использует средства REST, такие как sqlREST [36]. Как только REST enabler реализуется для реляционных баз данных (sqlREST), он создает ресурс для каждого объекта и уровня.
RESTful/RESTish реализация в серверах BIM свидетельствует о конкретном внедрении этого паттерна. Примерами правильности данного паттерна служат этапы реализации REST в открытом источнике BIMServer [20] и веб-сервер IFC, разработанный Техническим университетом Дрездена [37]. Пользовательский интерфейс веб-сервера IFC изображен на рис. 8.
Hi С[В http://bd52.cib.bau.tu-dresden.de/ifcwebserver/cache/userl/BIMhou se_ARKjnfo2.ifc_tree.html
Home|Header|Tree of IFC objects [ List of IFC objects
open all | dose all
IFC B!Mhouse_ARK_mfo2.tfc В П IfcRepresentationltem j—Q (xml) IfcApplication(l)
Й _j IfcProfileDef
j--Q (xml) IfcArbitraryClosedProfileDef(142)
Й IfcParameterizedProfileDef
Q (xml) IfcRectangleProfileDef(9)
EJ^3 IfcRoot
Й 0 IfcObject S ^3 IfeProduct
® j_j IfcSpaltalStructureElement I В IfcElement
B-f-l IfcBuildingElement
(xml) ilfcCo1umn(4)i | (xmt) IfcDoor(43)
(xml) IfcSlab(54)
(xml) IrcStair(6)
(xml) IfcWalf(4)
Ef~l IfcWall
(JJ (xmt) IfcWindow(29)
B fl IfcFeatureElement №> (xml) IfcProject(L)
B Q IfcPropertyDefinition В? Г 1 IfcRelationship IfcProperty
Q (xml) IfcComplexPnoperty(9)
В Г] IfcSimplePropertY ф -0] IfcCormectionGeometry
П (xml) IfcConnectionSurfaceGeometrv(3S4)
0 tfjj IfeRepresentalionCootext
Q (xml) lfcGeometricRepresentationcontex((l)
Ё)<53 IfcObjeetPlaeement
! Q (xml) IfcLocalPlacement(387)
•Q (xml) IfcMatenal(l)
Q (xml) IfcMatenafLayerfS)
Q (xml) lfcMatenalLayerSet(5)
Q (xml) lfcMatenalLayerSetUsage(6) fvmll IWlrn«ni73finnf 11
Рис. 8. Пользовательский интерфейс IFC
Иерархическая структура, представляющая объекты IFC (IFC Object Tree), может перемещаться на разные уровни, и, чтобы получить информацию, пользователь может взаимодействовать с этой структурой. Как только пользовательский запрос подается в дерево навигации, генерируется запрос стиля REST (отклик). Отклик может направить пользователя к загружаемому набору запрошенных объектов (в формате ISO10303-P21) или в виде XML файла. С другой стороны, RESTish функциональные возможности BIM сервера включают в себя сбор информации от каждого объекта в модели BIM, импорт-экспорт моделей BIM, поддержку версий BIM (просмотр предыдущих
версий одной и той же модели) и определение того, кто сделал изменения, какие и когда. BIM Server имеет веб-интерфейс, где можно запрашивать модели с сервера, используя стили REST и SOAP. Новейшая версия программного обеспечения имеет интегрированное веб-ориентированное средство просмотра, которое использует плагин O3D для веб-браузера для просмотра трехмерных изображений модели. Главный пользовательский интерфейс BIM сервера представлен на рис. 9.
•> *2 Ы Ф ьпрулос«»юкв0в2/р^е<г|*р?ро4<10 - С Go;*
ITBiMserver
Ytov тч toggrt * N Мтиотшю» Looowt
Рис. 9. Пользовательский интерфейс BIM Server
В данных исследованиях был разработан внешний интерфейс (рис. 10) для обоснования использования сервисов, упомянутых в этом паттерне. Разработанный внешний интерфейс используется для сервиса RESTful, предусмотренного BIM Server [20]. Внешний интерфейс может соединять любой уровень BIM Server (на основе его URL) через Интернет. Затем через идентификатор проекта и идентификатор новой версии (Project Id и Revision Id) специального проекта, находящегося на сервере, пользователи могут получать информацию с учетом любого класса (уровня) модели BIM методом RESTful. Как показано на рис. 10, результирующий набор, возвратившийся как результат запросов REST, является текстовым файлом формата ISO 10303 Part 21/ASCII, который предоставляет список объектов запрошенной модели.
3.4. Сравнение паттернов
Паттерны, описанные в данной статье, имеют и сходства, и различия, возникающие в результате технологий их реализации, фокуса и архитектурных стилей. В таблице показано краткое сравнение этих паттернов.
Паттерн AJAX BIM облегчает взаимодействие с помощью визуального представления моделей BIM и асинхронной передачи информации от модели к клиенту. В этом паттерне переданная информация будет, главным образом, семантической. Facade BIM SOAP обеспечивает интерфейсы высокого уровня с формальным (предопределенным) языком запросов для BIM при отвязывании модели от интерфейсов и клиентов. Наоборот, паттерн RESTful BIM
предоставляет модели интерфейсы низкого (объектного) уровня и способствует мелким запросам.
Сравнение паттернов
BIM AJAX BIM SOAP Fagade RESTful BIM
Фокус паттерна Облегчает взаимодействие при быстрых представлениях Облегчает сбор веб- ориентированных данных посредством формальных запросов высокого уровня Облегчает взаимодействие на уровне объекта через Интернет
Внедрение паттерна Сосредоточено на клиенте Сосредоточено на сервере Сосредоточено на сервере
Степень детализации Объектный уровень Уровень интерфейса Объективный уровень
Зависимость от правил Нет Есть Нет
Поддержка модели представления Нет Есть Есть
Связь клиент-модель Сильная связь Слабая связь Слабая связь
Рис. 10. Внешний интерфейс RESTful BIM
Внедрение паттерна AJAX BIM сосредоточено на клиенте (т. е. основной целью является асинхронная передача информации от модели BIM клиенту), в то время как два других паттерна внедряются на стороне сервера (несмотря на тип клиента и его возможности продолжать работать). В паттернах
AJAX BIM и RESTful BIM степень детализации запроса (взаимодействия) находится на уровне объекта (взаимодействие происходит с объектами BIM). Наоборот, паттерн Facade BIM SOAP предоставляет взаимодействие на уровне интерфейса (т. е. запросы клиентской стороны сфокусированы на получении информации из интерфейсов SOAP Facade, а не из интерфейсов объектов SOAP серверной модели). Паттерн SOAP Facade предоставляет интерфейсы высокого уровня, разработанные на основе правил (таких как ‘Provide columns of 1s floor’), в то время как два других паттерна не зависят от правил, поскольку сфокусированы на прямом взаимодействии с объектами BIM. Так как паттерн AJAX BIM сосредоточен, в основном, на прямом взаимодействии с BIM, он не поддерживает одиночные или множественные представления модели. К тому же он не предлагает никакого механизма синхронизации BIM и модели-представления, в то время как два других паттерна предлагают механизмы взаимодействия между BIM и моделью-представлением, которые смогут запустить эту синхронизацию. В паттерне AJAX BIM клиентские запросы AJAX зависят от объектной структуры BIM, в то время как в последних двух паттернах клиентские запросы осуществляются вопреки интерфейсам, предоставленным реализацией SOAP Facade и RESTful. Таким образом, в последних двух паттернах связь клиент-модель не сильная.
Заключение
Сервисно- и ресурсно-ориентированные архитектуры сформируют следующее поколение WWW. Общее представление об индустрии программного обеспечения заключается в том, что сильная сторона версии Web 2.0/3.0 находится за пределами сервисно- и ресурсно-ориентированных архитектур, что обеспечит эффективный доступ к данным и службам приложений без учета местоположения среды, в которой они работают. Фактически архитектурностроительная отрасль все еще сосредоточена на установлении уровня интероперабельности и интеграции данных и процессов. Например, специалисты и ученые этой отрасли все еще занимаются разработкой стандартов для обмена и совместного пользования (геометрического и семантического) информацией в области строительства (например, IFC, CIS2). В этой отрасли ведутся параллельные исследования в области обеспечения эффективного управления жизненным циклом объекта с помощью общедоступных цифровых моделей зданий, разработанных на основе стандартов. Вместе два этих направления называются информационным моделированием здания (Building Information Modeling). Сейчас информационное моделирование здания интерпретируется как процесс управления информацией на протяжении жизненного цикла здания, поддерживаемый совместным использованием цифровой 3D модели здания с развитой семантикой на всех стадиях жизненного цикла проекта и здания. Ключ к успеху информационного моделирования объекта лежит в ответе на вопрос «Насколько удачно мы управляем информацией об объекте», а не «Какую модель данных мы используем» или «Какое ПО мы используем». Таким образом, обеспечение эффективных методов «управления и интеграции информации об объекте» - это обеспечение «моделей данных для общего использова-
ния и обмена информацией об объекте». В настоящее время подходы к интероперабельности в архитектурно-строительной отрасли являются модельнозависимыми. Как и многие другие, архитектурно-строительная отрасль в ближайшем будущем тоже неизбежно перейдет к сервисно-ориентированной интеграции. В отличие от других, в архитектурно-строительной отрасли переход к «сервисно-ориентированной интеграции» будет развиваться из «модельнозависимых» подходов, которые в наши дни являются главными. Таким образом, успех будущих попыток в области архитектурно-строительной интеграции будет зависеть, в основном, от того, насколько хорошо усвоены (внедрены) модельно-зависимые подходы и насколько хорошо развита модельно-зависимая интероперабельность. В этой связи формализация роли информационной модели здания в сервисно-ориентированных средах является ключевым моментом для успешного преобразования интеграционного восприятия архитектурностроительной отрасли. Паттерны, описанные в данной статье, послужат, в первую очередь, этой цели.
В статье представлены три шаблона проектирования для формализации модельно- и сервисно-ориентированной интероперабельности в архитектурно-строительной отрасли. Эти шаблоны показывают, как модельно- и сервисно-ориентированные разработки могут быть внедрены в конкретную область знаний (такую, как архитектурно-строительная), требующую переработки большого объема данных. Данные исследования заключаются в представлении паттернов для формализации модельно- и сервисно-ориентированных архитектур и обеспечения формализма при использовании современных методов разработки веб-приложений и архитектур, таких как AJAX, SOAP и REST при взаимодействии с моделями BIM.
Паттерн AJAX BIM объясняет, как методы AJAX могут быть использованы при взаимодействии с графическими моделями BIM в веб-ориентированных системах. Этот паттерн будет наиболее полезен для увеличения эффективности веб-ориентированных и BIM-зависимых систем для быстрой визуализации в пределах многопользовательских сред. Этот паттерн гарантирует оптимальный объем информации, посылаемый от сервера к клиенту при каждом взаимодействии с моделью BIM. Асинхронный способ коммуникации с сервером окажет положительное влияние на время работы веб-ориентированной системы. Более того, поскольку потребность в структурированных запросах со стороны сервера будет устранена, общая эффективность сервера тоже возрастет.
Паттерн BIM SOAP Facade, представленный в статье, использует принципы хорошо известного паттерна GoF Facade, отправляет его на уровень вебсервисов и обусловливает его применение в технологии BIM. Три компонента BIM SOAP Facade, а именно: служба преобразования формата, интерфейсы SOAP и SOAP Facade - обеспечивают легкий в применении, стандартизованный набор методов для веб-ориентированного управления многочисленными моделями BIM (модель-представление). Однако единственным недостатком этого паттерна является то, что он не разрешает сбор информации от каждого объекта модели BIM (модель-представление).
Для решения этой проблемы подходит третий паттерн, предложенный в статье, - RESTful BIM, который являет собой архитектуру для обеспечения мелкомодульного интерфейса для всех объектов модели BIM (модель-представление). С помощью паттерна RESTful BIM пользователи смогут легко получать информацию через Интернет от каждого объекта модели BIM.
Выбор паттерна (в веб-ориентированных интерфейсах с применением технологии BIM) будет зависеть, главным образом, от требований пользователя, но другие факторы, которые могут повлиять на выбор паттерна, включают применяемое архитектурно-строительное ПО, текущую архитектуру системы и знание (опыт) команды разработчиков в области методов AJAX и архитектурных стилей SOAP и REST. Формализации, представленные в этих паттернах, сделают свой вклад в переход от модельно-зависимой интероперабельности к модельно- и сервисно-ориентированной интеграции архитектурно-строительного ПО.
Паттерны, разработанные в данных исследованиях, предоставляют возможность формализовать высоконастраиваемые сервисно-ориентированные архитектуры на базе BIM-технологий с использованием методов AJAX и архитектурных стилей SOAP и REST. И хотя стиль SOAP является более зрелым в плане современных реализаций, стиль REST (ресурсно-ориентированный) тоже предоставляет много возможностей, поскольку может обеспечить мелкомодульный сбор данных на веб-уровне.
Библиографический список
1. W3C Glossary [Глоссарий W3C], http://www.w3.org/TR/ws-gloss 2010 (last visited on No-vember2010).
2. R. Jardim-Goncalves, A. Grilo, SOA4BIM: putting the building and construction industry in the Single European Information Space [SOA4BIM: архитектурно-строительная отрасль в едином Европейском информационном пространстве], Automation in Construction 19 (4) (2010) 388-397.
3. SAbLE-BLIS Project Web Site [Веб сайт проекта SABLE-BLIS], http://www.blis-project.org 2007 (last visited on February, 2007),
4. OGC Document 07-037r4: Summary of the OGC Web services [Краткое описание вебсервисов OGC], Phase 4 (OWS-4), http://www.opengeospatial.org/projects/initiatives/ows-4
2009 (last visited on February, 2009).
5. B. Akinci, H. Karimi, A. Pradhan, C.-C. Wu, G. Fichtl, CAD and GIS interoperability through semantic web services [САПР и ГИС интероперабельность посредством семантических веб-сервисов], ITcon 13 (2008) 39-55.
6. P. Christiansson, K. Svidt, В. Sorensen, Future integrated design environments [Будущие интегрированные среды проектирования], ITcon 14 (2009) 445-460.
7. Y. Rezgui, S. Boddy, M. Wetherill, G. Cooper, Past, present and future of information and
knowledge sharing in the construction industry: towards semantic service-based
e-construction? [Прошлое, настоящее и будущее общедоступной информации и знаний в строительной индустрии: на пути к семантическому сервисно-ориентированному дистанционному строительству?] Computer Aided Design 43 (5) (2011) 502-515, http://dx.doi.org/10.1016/jxad.2009.06.005.
8. ROADCON Final Report, http://cic.vtt.fi/projects/roadcon/docs/roadcon_finalreport.pdf 2003(last visited on November 2010).
9. Strat-CON Final Report, http://cic.vtt.fi/projects/stratcon/stratcon_final_report.pdf 2007(last visited on November 2010).
10. J. Underwood, U. Isikdag, Handbook of Research on Building Information Modeling and Construction Informatics: Concepts and Technologies [Руководство по научным исследованиям в области информационного моделирования здания и строительной информатики: концепции и технологии], IGI-Global, December, 2009.
11. A Working Definition: Integrated Project Delivery [Рабочее определение: интегрированная реализация строительных проектов], http://www.ipd-ca.net/images/ IntegratedProjectDeliv-eryDefinition.pdf 2007.
12. AGC The Contractors' Guide to BIM [Руководство для разработчиков моделей BIM] - Edition 1, http://www.agcnebuilders.com/documents/BIMGuide.pdf 2006 (last visited on November 2010).
13. NBIMS, National Building Information Modeling Standard Part-1: Overview, Principles and Methodologies [Национальные стандарты информационного моделирования здания Часть 1], US National Institute of Building Sciences Facilities Information Council, BIM Committee, 2007 Online at: http://www.wbdg.org/pdfs/ NBIMSv1_p1.pdf (last visited on November 2010).
14. CRC-Fact Sheet, Sydney Opera House FM Exemplar project: Fact Sheet 2-BIM, http://www.construction-innovation.info /images/pdfs/ SOH-FH_Fact_Sheet_2. pdf 2005 (last visited on November 2010).
15. U. Isikdag, G. Aouad, J. Underwood, S. Wu, Building Information Models: a review on storage and exchange mechanisms [Информационные модели здания: механизмы хранения и обмена], in: D. Rebolj (Ed.), Proceedings of 24th W78 Conference: Bringing ITC knowledge to work, Maribor, 2007, pp. 135-144.
16. buildingSMART Technical Resources [Технические ресурсы buildingSMART], http://www.iai-tech.org/ 2010 (last visited on November 2010).
17. CIMsteel Integration Standards [Стандарты интеграции CIMsteel] Release 2: Second Edition, http://www.cis2.org 2003(last visited on November 2010).
18. R. Vanlandea, C. Nicolle, C. Cruzb, IFC and building lifecycle management [IFC и управление жизненным циклом], Automation in Construction 18 (1) (2008) 70-78.
19. IFC Wiki, An Open Portal on IFC [Вики IFC, открытый портал IFC], http://www.ifcwiki.org
2010 (last visited on November 2010).
20. BIMServer, Open Source Building Information Modelserver Project [Открытый проект информационной серверной модели здания], http://www.bimserver.org 2010(last visited on November 2010).
21. D.S. Linthicum, Next Generation Application Integration: From Simple Information to Web Services [Новое поколение интеграции приложений: от простой информации к вебсервисам], Addison-Wesley, 2003.
22. T. Erl, Service-oriented Architecture: A Field Guide to Integrating XML and Web Services [Сервисно-ориентированная архитектура: руководство по интеграции XML и вебслужб], Prentice Hall PTR, 2004.
23. R. Ruggiero, Integration Theory [Теория интеграции], Part 1. DM Review Magazine, http://www.information-management.com/ infodirect/20050812/1034584-1.html 2005 (last visited on November 2010).
24. C. Imhoff, Understanding the Three E's of Integration EAI, EII and ETL [Об интеграции трех «Е» EAI, EII и ETL], DM Review Magazine,
http://www.dmreview.com/issues/20050401/10238 93-1.html 2005 (last visited on November 2010).
25. G. Hohpe, В. Woolf, Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions [Паттерны производственной интеграции: проектирование, строительство и пересылка сообщений], Addison-Wesley, 2003.
26. L. Seligman, P. Mork, A. Halevy, K. Smith, M.J. Carey, K. Chen, C. Wolf, J. Madhavan, A. Kannan, D. Burdick, Open II: an open source information integration toolkit [Open II: инструмент интеграции], in: A. Elmagarmid, D. Agrawal (Eds.), E-Proceedings of SIGMOD 2010, 2010, http://portal.acm.org/ citation.cfm?id=1807167 (last visited on November 2010).
27. H. He, What Is Service-Oriented Architecture O'REILLY XML.COM [Что такое сервисноориентированная архитектура O'REILLY XML.COM],
http://www.xml.com/pub/a/ws/003/09/30/soa.html 2003(last visited on November 2010).
28. Е. Pulier, H. Taylor, Understanding Enterprise SOA [О предприятии SOA], Manning Publications, Greenwich, USA, 2006.
29. R.T. Fielding Architectural styles and the design of network-based software architectures [Архитектурные стили и проектирование программных архитектур]. PhD Thesis. Dept. of Information and Computer Science, University of California, Irvine, 2000.
30. C. Pautasso, O. Zimmermann, F. Leymann, Restful web services vs. “big” web services: making the right architectural decision [Веб-сервисы Restful и «большие» веб-сервисы: принимая правильное архитектурное решение], in: J. Huai, R. Chen (Eds.), WWW'08: Proceeding of the 17th international conference on WorldWideWeb, 2008, pp. 805-814.
31. J.J. Garrett, Ajax: A New Approach to Web ApplicationsAdaptivePath.com. [Новый подход к Web ApplicationsAdaptivePath.com.],
http://www.adaptivepath.com/ideas/essays/archives/000385.php 2005 (last visited on November 2010).
32. Е. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns: Elements of Reusable Object-oriented Software [Шаблоны проектирования: средства многоразового объектноориентированного программного обеспечения], Addison-Wesley, 1995.
33. S.M. Yacoub, H.H. Ammar, Pattern Oriented Analysis and Design [Шаблонноориентированный анализ и проектирование], Addison-Wesley, 2003.
34. U. Isikdag, J. Underwood, Two design patterns for facilitating Building Information Model-based synchronous collaboration [Два шаблона проектирования для содействия синхронной работе на базе информационной модели здания], Automation in Construction 19 (5) (2010) 544-553.
35. A. Shalloway, J.R. Trott, Design Patterns Explained: A New Perspective on Object-oriented Design [Шаблоны проектирования: новая перспектива объектно-ориентированного проектирования], Addison-Wesley, 2002.
36. sqlREST: REST Enabler for Relational Databases [REST enabler для реляционных баз данных], http://sqlrest.sourceforge.net/ (last visited on December 2008).
37. IFC Web Server, IFC Web Server Project [Веб-сервер IFC, проект Веб-сервера IFC], http://bci52.cib.bau.tu-dresden.de/ifcwebserver/ 2011(last visited on October 2011).
