PIMAGOLD

Архитектура

Программное обеспечение PimaGold, основанное на LAMP и организованное в соответствии с MVC, представлено как услуга и имеет легкий вес с простой и понятной структурой и имеет низкую совокупную стоимость владения. Эти функции используются для достижения ряда целей.

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

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

Другая, и, возможно, главная цель - сделать ИТ-решения доступными для малого бизнеса.

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

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

Базовая конфигурация

Рисунок 1

Как изображено на рис.1, Архитектура не предполагает использование выделенного сервера приложений, что, пожалуй, является наиболее значимым фактором в совокупной стоимости владения на базовом уровне. Вместо этого область ответственности сервера приложений разделена между такими единицами, как Хранимые программы в RDBMS и Frontal FrameWork (FFW) и Client-Side JavaScript Framefork (CS JS-FW) или Mobile Framework в сочетании с JS-FW.

Зачем? Ответ заключается в том, что существует много типов бизнес-процессов, которые не столь ценны для их внедрения на полнофункциональном сервере приложений. Но в то же время эти процессы являются общими и существенными, подвержены изменениям и имеют относительно короткий срок службы. Большинство предприятий, особенно мелкие, никогда не выходят за пределы тех областей, где доминируют такие процессы. Отсутствие сервера приложений не только сокращает TCO, но и дает толчок к тонкому распределению функциональности. В случае архитектуры PimaGold, в результате этого распределения, типичная часть кода, с которой приходится иметь дело, редко превышает несколько десятков строк. Этот фрагмент кода обычно достаточен и обернут в отдельный файл. Таким образом, также устраняется необходимость в системе CPD, которая способствует TCO. Еще одним важным фактором ТСО является объем сетевого трафика. Передача SOAP-transport влечет за собой ненужные накладные расходы из-за тяжелых метаданных. Вместо этого архитектура PimaGold основана на многоцелевом FFW-протоколе (FFWP, рис.1), который позволяет строить структуры произвольной сложности любого количества компонентов. Основными преимуществами использования протокола являются эффективность и удобство в отношении облачных вычислений. FFW имеет собственное шифрование, поэтому не зависит от использования SSL или чего-то подобного, но не запрещено использовать FFWP через SSL.

Как показано на рис.2, запрос FFWP включает в себя идентификатор запроса и идентификатор сеанса, а также уникальные идентификаторы как веб-службы (FFW-ID), так и экземпляра JS-FW (MFW-ID) , что дает возможность опираться на уровень сеанса над FFWP-transport. Уровень сеанса FFWP широко используется в системе регистрации (RAS, рис.2), которая авторизует, собирает статистику и выступает в роли брокера для запросов к веб-сервисам. Для полноты необходимо упомянуть другие части, которые составляют основную архитектуру. Таким образом, существует эмулятор отладки, который использует файловую систему и обеспечивает непрерывное производство в направлении области контроллера и области просмотра, не дожидаясь версии модели. Использование эмулятора устраняет необходимость создания изоляции между средой разработки и ее производительной системой. Следующая часть - это XML-шаблоны, которые предназначены для облегчения кода веб-сервиса путем перемещения функций, ответственных за сборку AJAX-страниц.

Полученная страница собирается из фрагментов компонентов HTML и JavaScript в соответствии с правилами, написанными в XML-скрипте и в соответствии с внутренним состоянием веб-сервиса. Следующий способ манипулирования содержимым страницы - применить theme engine. Это касается как языковой поддержки, так и всего в целом.

Продвинутая конфигурация

Рисунок 2

Фактически, с точки зрения архитектуры cloudlet как функциональный блок представляет собой одну или несколько AJAX-страниц.

Долгосрочное состояние этого блока отображается на RDBMS, а его текущее состояние сохраняется в контексте активного сеанса. JS-FW предназначен для поддержки клиентской части этого контекста. Кроме того, этот модуль выполняет такие работы, как поддержка очередей запросов к общим ресурсам и определение дизайна в виде набора вызовов API и библиотеки, а также обертывание, если таковые имеются, вызовов Mobile Framework (например, MFW), включая обработку ошибок и т. Д. Кстати, все FFW-единицы демонстрируют единообразие в распространении сообщений об ошибках через все уровни и доводят их до пользователя и сохраняют их в системном журнале. Вообще говоря, это хорошая практика для облака, чтобы настроить свой собственный экземпляр JS-FW в целях эффективности.

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

Кроме того, MFW был разработан для расширения благодаря поддержке различных датчиков, таких как GPS и другие. Роль, которую играет MFW в архитектуре Advanced Application Architecture PimaGold, заключается не только в том, чтобы быть посредником между cloudlet и RAS, как показано на рис. 2, но это рассматривается как способ переноса приложений фронт-офиса с рабочих столов на мобильную платформу. В связи с этим любое приложение в PimaGold Architecture представляет собой набор веб-сервисов, которые используются в конкретном контексте RAS-сессии и связаны с уполномоченным агентом. Такие приложения, выполняющие вычисления большей частью на мобильном устройстве, могут использовать ресурсы, выделенные ему в хосте, и отражать их состояние в СУБД, а также в файловой системе, затрагивая только те данные, которые находятся в их распоряжении.

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

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

Контакт

По вопросам сотрудничества обращайтесь pimagold@gmail.com