композитный сервис что это

Композитный сайт: технология Битрикс в каждую CMS

Здрасте!
Поговорим про самое спорное телодвижение компании Битрикс — технологию «Композитный сайт».
Спорное оно потому, что ребята запатентовали технологию, которая, по моему мнению, не тянет даже на курсовую 3 курса профильной специальности.

Ну да ладно, это ж маркетологи.

В статье рассмотрены:

Все вкусности внутри, го под кат.

INTRO

Честно, не понимаю какой был смысл патентовать технологию на 1-2 сотни строк кода, да к тому же и совсем не инновационную, это правда уже вопросы к «патентному бюро», так что пофиг.
Погнали!

Технология композитный сайт

Громко, конечно, называть это технологией, но все же пусть будет так.
Что же это такое?
Цитата с сайта Битрикс:

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

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

То, что выделено красным, выполняется параллельно.
Пояснять не буду, тут все понятно.

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

CompoJax

Собственно, «технология» делающая практически тоже самое, только без пафоса, патента, проще, прозрачнее + PJAX.

Разделить технологию можно на 2 части:

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

Алгоритм работы следующий:

Собственно, вот и все.

Алгоритмически «технологии» не одинаковы, так что нарушения патента, в принципе, нет. В патент не углублялся, но если придет повестка в суд сделаю в статье update. Ниже представлены все возможности CompoJax, параметры PJAX и способы его кастомизации. Данный код можно использовать везде, в компонентах, шаблонах, своих классах, неважно.

CompoJax включен в либу Juggernaut, однако, вы можете скачать его отдельно (всего 1 класс), ссылки ниже.

Не только для Битрикс

Как я заикнулся выше, данную технологию можно использовать не только в Битрикс, но и в любой CMS.
На самом деле, нужно просто наследоваться от CompoJax и перегрузить методы end и clearBuffer.

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

Рассмотрим перегрузку данных методов на примере WordPress:

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

Источник

Композитные Web-сервисы обретают реальность

Продолжение. Начало см. PC Week/RE, N 27/ 2004, с. 20, N 28/2004, с. 19.

Спецификации управления потоками исполнения

К настоящему моменту предложено несколько технологий для построения композитных сервисов: XLANG (фирмы Microsoft), BPFL (IBM), BPML (консорциума BPML.org), WSCI (Sun, SAP, BEA, консорциум W3C), BPSS (консорциум ebXML/OASIS), WSCL (Hewlett-Packard). В этой ожесточенной борьбе де-факто победа досталась новому игроку BPEL4WS, которую поддержала критическая масса фирм-разработчиков ПО и которая унаследовала многие из позитивных свойств предшественников. Даже вендоры, предлагавшие собственные спецификации, теперь поддерживают ее в своих продуктах. Между тем сохраняется актуальность спецификаций BPMI (она не ограничена авторскими правами) и BPSS (ebXML по-прежнему актуален).

BPEL4WS (Business Process Execution Language for Web Services)

Назначение: построение составных сервисов.

Авторы: IBM, Microsoft, BEA, Siebel Systems, SAP.

Статус: де-факто стандарт, подан для утверждения в OASIS.

Взаимодействие процесса BPEL4WS с внешним миром

BPEL4WS-процесс представляет все связи с партнерами как взаимодействие через абстрактный WSDL-интерфейс (portTypes и операции), на реальные сервисы ссылок не делается.

Пример внутреннего устройства процесса BPEL4WS

Примечание. BPEL4WS основан на нескольких XML-спецификациях: WSDL 1.1, XML Schema 1.0, XPath1.0. В описании процессов используются WSDL-сообщения и типы и модель данных XML Schema. Механизм манипуляции данными обеспечивает XPath. Все внешние ресурсы и партнеры представляются как WSDL-сервисы.

BPML (Business Process Modeling Language)

Автор: консорциум производителей средств BPM BPNI.org, 2002 г.

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

Вот основные сходства и различия, как их сформулировал сам консорциум в своих документах:

— BPML бесплатен в отличие от BPEL4WS;

— BPML включает BPEL4WS как подмножество;

— BPML и BPEL4WS имеют идентичный набор идиом и синтаксис;

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

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

— BPML базируется на WSCI для описания общедоступных интерфейсов и диаграмм процессов.

Web Services Choreography Description Language (WS-CDL)

Статус: W3C Working Draft 27 April 2004.

Авторы: Oracle, CommerceOne, Novell.

Диаграмма параллельных потоков в BPEL4WS-сценарии

Также WS-CDL не позиционируется как язык для описания исполнения бизнес-процесса. Эта роль отводится другим технологиям (BPEL4WS и Java), но WS-CDL определяет порядок выполнения операций (условное, последовательное, параллельное и исключительные ситуации) и правила для согласованного управления скрытыми от партнера бизнес-данными. Интерфейсами для взаимодействия систем в разных организациях являются WSDL-описанные сервисы.

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

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

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

Схема применения WS-CDL-хореографий

WS-CDL обладает многими позитивными качествами: она оказывается транзакционной, созданные хореографии можно многократно использовать, процесс дирижирования сервисами опирается и управляется потоками данных, имеется модульность (можно импортировать компоненты из других хореографий), есть средства контроля за исключительными ситуациями и пр. Спецификация также совместима с WS-Reliability, WS-CAF, WS-Security, BPEL4WS и пр.

Примечание.В группу спецификаций W3C, посвященных дирижированию сервисами, входят еще два документа:

Источник

IBM WebSphere Developer Technical Journal: Часть 1.

Рисунок 1. Уровневая архитектура SOA

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

Tool Pack содержит:

Foundation Pack создан на базе WebSphere Process Server (который включен в пакет) и обеспечивает интегрированную среду времени выполнения и времени управления для бизнес-сервисов. Foundation Pack состоит из пяти модулей:

Industry Content Packs (необязателен)

WebSphere Business Services Fabric предоставляет необязательный Industry Content Packs, включающий в себя отраслевые расширения и предварительно созданные отраслевые сервисы для уменьшения усилий по созданию отраслевых SOA-решений. В настоящее время доступны два Industry Content Packs:

IBM Insurance Property and Casualty Pack

IBM Healthcare Payer Pack

Как заставить рассмотренные выше компоненты работать совместно для поддержки адаптивных композитных бизнес-сервисов? На рисунке 2 показаны этапы создания композитных бизнес-сервисов при помощи этих компонентов и имеющих к ним отношение продуктов IBM.

Рисунок 2. Цикл разработки композитных бизнес-сервисов

Давайте рассмотрим эти этапы:

Используйте WebSphere Business Modeler для перечисления ролей, действий, высокоуровневых входных/выходных данных, потока решений и бизнес-показателей, удовлетворяющих вашим требованиям.

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

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

Определите расширения ( онтологии (EN)) WebSphere Business Services Fabric на основе требований, модели бизнес-процессов и отраслевой модели (если есть). Расширения WebSphere Business Services Fabric затем развертываются в Business Services Repository.

Разработайте исполняемые бизнес-процессы, компоненты сервисов и модули, используя инструментальные средства бизнес-интеграции, Java EE и Web-сервисы в WebSphere Integration Developer. При необходимости некоторые из этих компонентов можно разработать, используя IBM Rational Application Developer.

Используйте Composition Studio для определения мета-данных бизнес-сервисов и передайте их в Business Services Governance Manager для утверждения.

Определения мета-данных бизнес-сервисов будут рассмотрены заинтересованными сторонами в Business Services Governance Manager и опубликованы в Business Services Repository.

Определите наименования подписчиков созданных бизнес-сервисов в Business Services Subscriber Manager. Эта информация сохраняется в Business Services Repository.

Разверните компоненты сервисов и исполняемые процессы в WebSphere Process Server.

WebSphere Process Server выполняет бизнес-процессы с оптимальными экземплярами сервисов, выбранными Business Services Dynamic Assembler на основе бизнес-контекста и мета-данных в Business Services Repository.

Ход выполнения записывается в Business Services Performance Manager для последующего анализа.

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

Источник

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

Что такое «композитный сервис» и зачем его создавать?

Александр Герасимов, эксперт по ИТ и телекоммуникациям

Определение «композитный сервис» применительно к сетевому сервису означает некий нестандартный сервис, составленный из определенным образом настроенных базовых сетевых сервисов. В основном это сетевые сервисы уровней 3-7 семиуровневой сетевой модели. Эти базовые сервисы могут определяться как программно-аппаратно, то есть аппаратно зависимо (оборудование BRAS, CGNAT, Firewall, DPI, AntiDDOS и пр.), как это есть сейчас, либо полностью программно, то есть аппаратно независимо (тоже самое, но с приставкой «virtual»). Виртуализованные сетевые сервисы (функции) vBRAS, vCGNAT, vFirewall и другие могут быть реализованы в сетях NFV с автоматическим программным управлением (SDN).

Таким образом, речь идет создании так называемых «цепочек сервисов», формирующих «композитный сервис» (Рис. 1). Вот какое определение техники создания «цепочек сервисов» дает Heavy Reading в своей White Paper, посвященной концепции Service Chaining [1]: «Создание цепочек сервисов – это нарождающийся набор технологий и процессов, позволяющих оператору динамически переконфигурировать базовые сетевые сервисы на программном уровне, без необходимости внесения изменений в сеть на аппаратном уровне. Путем маршрутизации потоков трафика в соответствии с «графами сервиса», техника service chaining позволяет реализовать как задачи оптимизации сети добиваясь лучшей утилизации сетевых ресурсов, так и задачи монетизации через предоставление композитных сервисов, автоматически оптимизированных под нужды конкретного клиента.

Рис. 1. Концепция формирования «композитных сервисов» путем создания различных цепочек из базовых сетевых сервисов

Считается, что такая кастомизация нужна в основном для предоставления виртуальных сетевых функций облачным приложениям, которые требуют динамического изменения конфигурации сети. Но это не совсем так. Техника service chaining нужна и для кастомизации базовых сервисов, таких как, например, ШПД, потребляемых просто для доступа в сеть Интернет и никак не привязанных к конкретному прикладному сервису. Цель — оптимизация потребительских характеристик продукта под требования узкого сегмента рынка или даже конкретного клиента, причем в автоматическом режиме и с минимальными издержками, то есть не только для крупных корпоративных клиентов, но и для массовых.

Как создавать «композитный» сервис?

Как было отмечено выше, «композитный сервис» может быть создан и в традиционных сетях путем настройки соответствующего оборудования. Но это довольно долгий и затратный путь, не имеющий перспектив на массовом рынке. А вот в сетях SDN и NFV «композитный сервис» может создаваться автоматически через механизм service chaining, представленный функционалом SDN-контроллера (Control Plane), когда из ограниченного количества базовых виртуализованных сетевых функций можно «собирать» их цепочки, формируя таким образом сколь угодно разнообразные по своим характеристикам «композитные» продукты.

Архитектура решения представлена на Рис. 2.

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

Не буду пересказывать подробно описанную в white paper Heavy Reading и других источниках технику service chaining, а остановлюсь на одном чрезвычайно важном аспекте, обычно выпускаемом из виду в многочисленных публикациях по рассматриваемой теме.

В представленной на Рис. 2 сетевой конструкции обращает на себя внимание отсутствие важной компоненты. Дело в том, что продукт – это не только функции сети, но и функции, формируемые процессами технического обслуживания и клиентского взаимодействия. Это означает, что в «композитный» продукт необходимо встраивать не только виртуализованные сетевые функции, но и функции систем биллинга, CRM и контакт-центра, ERP и так далее, для чего их также необходимо виртуализовать, то есть избавиться от ручного труда при осуществлении таких процессов.

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

Пожалуй, единственным в мире телекомов примером такого подхода является реализуемая AT&T программа трансформации Domain 2.0, цель которой сформулирована как создание «определяемой пользователем сети» (User Defined Network).

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

Таблица 1. Комплексность подхода AT&T по созданию сети, определяемой пользователем (User Defined Network)

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

Таблица 2. Use case использования интеллектуальной OSS/BSS применительно к обеспечению автоматического вывода на рынок нового сервиса (модель DevOps)

В рамках программы Domain 2.0 задача трансформации операционных и бизнес-процессов в автоматически исполняемые облачные выделена в отдельный проект создания так называемой «платформы реализации сервисов» (Service Realization Excellence platform, SRE). В рамках данного проекта уже разработано более 6о «инструментов» (модулей) для полностью программного исполнения жизненного цикла продукта – от разработки до его внедрения и измерения коммерческих результатов. В настоящее время платформа SRE используется AT&T как основная для исполнения всех сетевых операций.

Это, в свою очередь, знаменует кардинальное изменение не только подходов к модернизации сетей, но и к организационной и бизнес-трансформации. AT&T формулирует это так: перейти от модели, ориентированной преимущественно на вопросы эксплуатации физической сети связи, к модели постоянного совершенствования (Development&Operations) виртуальной среды. В результате длительный процесс модернизации физической сети связи, закупки аппаратных и программных средств, кастомизации и внедрения приложений OSS/BSS и так далее сводится к процессу разработки виртуальной среды, а этап внедрения как таковой фактически не требуется, что кардинально повышает скорость изменений. В настоящее время это ключевой фактор выживания оператора в столь быстро и радикально меняющейся бизнес-среде.

В отличие от модели SOA, положенной в основу Frameworkx, OSS/BSS нового поколения будут, вероятно, представлять собой экосистемы взаимодействующих между собой через механизм открытых API облачных сервисов. Такой подход позволит реализовать любую модель формирования облачных сервисов (компонент OSS/BSS): частную (полностью на стороне оператора), публичную (полностью на стороне провайдера OSS/BSS aaS) или гибридную.

Важно отметить, что в значительной степени усилиями AT&T в модель Frameworkx начинают вноситься существенные изменения на основе первых результатов проекта Domain 2.0. В частности, это программа ZOOM (Zero-touch Orchestration, Operations and Management).

Это означает, что и для других операторов, в том числе для российских, появляется возможность использовать полученные в ходе реализации программы Domain 2.0 наработки, без необходимости инвестировать в НИОКР десятки миллиардов долларов, как вынужден делать выступающий локомотивом процесса цифровизации в телеком отрасли AT&T, чтобы сохранить за собой статус самого дорогого (по капитализации) оператора связи в мире.

Источник