Warning: include(/home/users/j/j36685780/domains/38uzorochye.ru/wp-content/plugins/psn-pagespeed-ninja/public/advanced-cache.php): failed to open stream: No such file or directory in /home/host1846916/38uzorochye.ru/htdocs/www/wp-content/advanced-cache.php on line 10

Warning: include(): Failed opening '/home/users/j/j36685780/domains/38uzorochye.ru/wp-content/plugins/psn-pagespeed-ninja/public/advanced-cache.php' for inclusion (include_path='.:/usr/local/php/php-7.4/lib/php') in /home/host1846916/38uzorochye.ru/htdocs/www/wp-content/advanced-cache.php on line 10
Шина передачи данных. сравнительный пример интеграции

Сравнительный пример интеграции: шина передачи данных против интеграции «точка-точка»

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

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

В DATAREON ESB существуют следующие типы коннекторов:

  1. Коннектор SOAP-сервисов
  2. Коннектор REST-сервисов
  3. Коннектор MS SQL
  4. Коннектор IBM DB2
  5. Коннектор Oracle
  6. Коннектор PostgreSQL
  7. Коннектор SharePoint
  8. Коннектор OData 1C
  9. Коннектор TCP
  10. Коннектор Siemens Teamcenter
  11. Коннектор SAP
  12. Коннектор File
  13. Коннектор Pick to Light
  14. Коннектор SFTP
  15. Коннектор Biometry
  16. Коннектор Kardex
  17. Коннектор 1С 7.7
  18. Коннектор 1С 8.х
  19. Коннектор Active Directory
  20. Коннектор ADO.NET
  21. Коннектор RabbitMQ
  22. Коннектор Apache ActiveMQ
  23. Коннектор IBM MQ
  24. Коннектор SMTP
  25. Коннектор IMAP
  26. Коннектор ЛОЦМАН PLM

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

Список доступных коннекторов постоянно расширяется, полный перечень необходимо уточнять в компании DATAREON.

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

Централизованное управление

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

Центр управления DATAREON ESB может быть интегрирован со средой разработки «1С:Enterprise Development Tools», также построенной на платформе Eclipse, что делает работу в DATAREON ESB еще более удобной для разработчиков на платформе «1С:Предприятие 8».

В DATAREON ESB присутствует множество визуальных инструментов настройки. Например, мастер настройки и управления информационными потоками:

Масштабируемость интеграционной шины

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

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

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

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

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

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

Проактивная диагностика и мониторинг

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

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

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

Для более глубокого анализа в центре диагностики доступна работа со счетчиками производительности системы за определенный период времени. Данные могут быть экспортированы в MS Excel.

Предусмотрены механизмы рассылки уведомлений для оповещения системных администраторов об ошибках системы.

В DATAREON ESB также имеются мощные инструменты для отладки сценариев передачи данных, включающие:

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

Диагностическая информация представляется в виде следующей диаграммы:

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

Еще один компонент — сервер хранения сообщений. Он предназначен для хранения всей информации, прошедшей через DATAREON ESB, а также позволяет выполнять сквозной анализ передачи данных между системами: от события возникновения данных до конечных точек получения данных с анализом маршрута прохождения.

Пример построения сети объектов ESB:

Цены и лицензионная политика Техническая поддержка и сопровождение Сравнительный пример интеграции

Менеджеры DATAREON будут рады ответить на все вопросы по тел. +7(495)280-08-01. Также вы можете написать нам через форму

Пример сценария интеграции

Офис отправляет в магазины и на сайт изменения в прайс-листе.

Схема содержит три группы участников: «Офисы», «МагазиныСоСтарымПО» и «МагазиныНа1С». В группе «МагазиныНа1С» объединены участники, которые используют для автоматизации системы на платформе 1С:Предприятие. В группе «МагазиныСоСтарымПО» собраны участники, которые используют ПО других производителей.

В момент изменения прайс-листа в офисе формируется сообщение, содержащее актуальный прайс-лист в формате EnterpriseData. Это сообщение отправляется в канал «ИзОфисов».

В узле «ДляВсех» все сообщения из канала «ИзОфисов» маршрутизируются по трем направлениям:

  1. Для передачи магазинам, использующим старое ПО, в формате JSON. Преобразование из исходного XML происходит в узле вида «Транслятор» с именем «JsonДляМагазинов». Полученный JSON отправляется в канал «ДляМагазиновСоСтарымПО».
  2. Для передачи магазинам, использующим ПО 1С, сообщение в исходном виде отправляется в канал «ДляМагазиновНа1С».
  3. Для публикации на сайте. Преобразование из исходного XML происходит в узле вида «Транслятор» с именем «JsonДляСайта». Полученный JSON отправляется на сайт HTTP запросом в узле «НаСайт».

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

Реализации протокола CAN

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

CAN-контроллер с промежуточным буфером

Контроллеры CAN с промежуточным буфером (ранее называемые чипами basicCAN) реализовали в качестве аппаратного обеспечения логику, необходимую для создания и проверки потока битов согласно протоколу. Однако администрирование наборов данных, которые должны быть отправлены и получены, в частности, фильтрация приёма осуществляется только CAN-контроллером.

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

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

CAN-контроллер с хранилищем объектов.

Объекты CAN состоят в основном из трех компонентов: идентификатора, кода длины данных и фактических полезных данных.

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

Контроллеры CAN с хранилищем объектов рассчитаны на максимальную нагрузку от локального микроконтроллера. Однако эти CAN-контроллеры требуют большей площади кристалла и, следовательно, более дороги. В дополнение к этому, они могут администрировать только ограниченное количество чипов(микроконтроллеров).

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

CAN подчиненные контроллеры для функций ввода / вывода.

Также как CAN-контроллеры, которые поддерживают все функции CAN-протокола, есть CAN-чипы, для которых не требуется следующий за ним микроконтроллер. Эти CAN-чипы называются SLIO (последовательное соединение ввода / вывода). CAN-чипы являются подчиненными и должны управляться CAN-мастером(центральный, основной микроконтроллер в сети).

Необходимость последовательного соединения в автомобилях

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

Предыдущую читайте здесь.

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

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

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

Если мы также рассмотрим будущие разработки, направленные на общую оптимизацию транспортных средств, то необходимо преодолеть ограничения, существующие в связи с обычными устройствами управления. Это можно сделать только путем объединения в сеть компонентов системы с использованием последовательной шины данных. Bosch разработал для этой цели систему «Controller Area Network» (CAN), которая с тех пор была стандартизирована на международном уровне (ISO 11898) и была «отлита в камне (в кремнии)» несколькими производителями полупроводников.

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

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

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

Сan шина на автомобиле ВАЗ

Can шина — это сетевой интерфейс ввода вывода, который используется практически во всех современных автомобилях, в том числе автомобилях марки ВАЗ. Данным интерфейсом оснащены модели Лада Приора (2170), Калина, Гранта и все последующие разработки АвтоВаз’а. Форм-фактор интерфейса для подключения OBD 2.

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

Технические характеристики шины Can, на автомобилях ВАЗ:

Реализация управления: Однопроводная схема (Шина LIN);

Скорость передачи данных: до 1 Мбит/с;

Скорость передачи данных между блоками системы комфорт: до 100 Кбит/с;

Интерфес Can: OBD 2;

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

Перечень устройст подключенных к данной шине, на автомобилях ВАЗ:

Силовой агрегат. Во главе цепи подключения, стоит блок ЭБУ. Далее по порядку подключаются остальные системы и блоки, в частности это: система управления коробкой передач, система безопасности (Airbug, ABS, VSA), усилитель руля, ТНВД, система отопления салона, сигнализация(иммобилайзер), монтажный блок и ряд датчиков отвечающих за работы ДВС.

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

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

Для подключения к шине CAN используется специальный программируемый CAN-модуль (Can-Log) от , позволяющий считывать технические параметры автомобиля с целью их дальнейшей обработки, оптимизации, настройки. Данный модуль используется только совместно с дополнительным оборудованием, например с системой AT-65i M 1(Autotracker), диагностическим устройством или компьютером со специальным ПО.

Взаимодействие с продуктами на платформе «1С:Предприятие 8»

Особое внимание DATAREON ESB уделяет программным продуктам, реализованным на платформе «1С:Предприятие 8». В поставку включена специальная подсистема, написанная на языке V8, которая встраивается в любую систему на платформе «1С:Предприятие» и обеспечивает все необходимые механизмы для интеграции решения с DATAREON ESB

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

Правила обработки данных для конфигураций на платформе «1С:Предприятие 8» создаются и хранятся централизовано в DATAREON ESB. Распространение и обновление обработчиков в системах на платформе «1С:Предприятие 8» также выполняется централизованно в автоматическом режиме без необходимости модификации самой конечной системы. Отсутствие необходимости модификации конечной системы при изменении схемы обмена является особенно важным, если таких систем много или если предъявляются высокие требования к времени доступности системы, которые значительно ограничивают временной промежуток, в который изменения могут быть внесены.

Реализованы удобные мастера, которые позволяют создавать обработчики для 1С:

В DATAREON ESB реализованы механизмы отладки обработчиков 1С без использования конфигуратора 1С. Отладка кода 1С выполняется непосредственно из центра управления DATAREON ESB.

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

Все реализованные интеграционные сценарии учитывают особенности лицензионной политики фирмы «1С», в частности те, которые запрещают прямой доступ к данным системы на платформе 1С через СУБД.

Трансформация данных

Одной из проблем построения композитных приложений является различие интеграционных форматов и протоколов приложений, входящих в периметр интеграции. При этом довольно часты случаи, когда изменение форматов и протоколов невозможно из-за закрытости системы или отсутствия поддержки со стороны компании-разработчика. DATAREON ESB имеет в своем составе инструменты, позволяющие эффективно решать данную проблему. Эти инструменты предоставляют возможность настраивать правила трансформации в различные форматы с различными алгоритмами преобразования данных. Механизмы трансформации позволяют строить многошаговые алгоритмы преобразования данных с контролем различных условий, вплоть до написания кода на языках высокого уровня. Визуальные средства разработки снижают требования к специалистам, отвечающим за создание схем трансформации. Самые «ходовые» форматы – XML, JSON, DBF, CSV, Base64 – представлены в виде «мастеров» настройки. Возможно построение алгоритмов с обогащением данных (когда для определенных потребителей исходный пакет расширяется другими данными). 

Процессорная шина

3 Кстати, именно результирующей «учетверённой» частотой передачи данных (как и в случае с «удвоенной» передачей DDR-шины, где данные передаются дважды за такт) хвастаются производители и продавцы, умалчивая тот факт, что для многочисленных мелких запросов, где данные в большинстве своём умещаются в одну 64-байтную порцию (и, соответственно, не используются возможности DDR или QDR/QPB), на чтение/запись важнее именно частота тактирования.

В архитектуре же AMD64 (и её микроархитектуре K8), используемой компанией AMD в своих процессорах линеек Athlon 64/Sempron/Opteron, применён революционно новый подход к организации интерфейса центрального процессора – здесь имеет место наличие в самом процессоре нескольких отдельных шин. Одна (или две – в случае двухканального контроллера памяти) шина служит для непосредственной связи процессора с памятью, а вместо процессорной шины FSB и для сообщения с другими процессорами используются высокоскоростные шины HyperTransport. Преимуществом данной схемы является уменьшение задержек (латентности) при обращении процессора к оперативной памяти, ведь из пути следования данных по маршруту «процессор – ОЗУ» (и обратно) исключаются такие весьма загруженные элементы, как интерфейсная шина и контроллер северного моста.

Различия реализации классической архитектуры и АМD-K8

Различия реализации классической архитектуры и АМD-K8

Ещё одним довольно заметным отличием архитектуры К8 является отказ от асинхронности, то есть обеспечение синхронной работы процессорного ядра, ОЗУ и шины HyperTransport, частоты которых привязаны к «шине» тактового генератора (НТТ), которая в этом случае является опорной. Таким образом, для процессора архитектуры К8 частоты ядра и шины HyperTransport задаются множителями по отношению к НТТ, а частота шины памяти выставляется делителем от частоты ядра процессора 4

4 Пример: для системы на базе процессора Athlon 64-3000+ (1,8 ГГц) с установленной памятью DDR-333 стандартная частота ядра (1,8 ГГц) достигается умножением на 9 частоты НТТ, равной 200 МГц, стандартная частота шины HyperTransport (1 ГГц) – умножением НТТ на 5, а частота шины памяти (166 МГц) – делением частоты ядра на 11.

В классической же схеме с шиной FSB и контроллером памяти, вынесенным в северный мост, возможна (и используется) асинхронность шин FSB и ОЗУ, а опорной частотой для процессора выступает частота тактирования 5 (а не передачи данных) шины FSB, частота же тактирования шины памяти может задаваться отдельно. Из наиболее свежих чипсетов возможностью раздельного задания частот FSB и памяти обладает NVIDIA nForce 680i SLI, что делает его отличным выбором для тонкой настройки системы (разгона).

5 Пример: процессор Intel Celeron 1,7GHz Willamette с заявленной на коробке частотой шины FSB-QPB 400 МГц, тем не менее, имеет коэффициент умножения 17 (1700=100 * 17), а не 4,5.

Подключение 1С:Предприятия к «Интеграционной шине»

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

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

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

Взаимодействие с «Интеграционной шиной» выполняется с гарантированной доставкой сообщения, что означает:

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

Продукт «Интеграционная шина»

  • Обмен сообщениями. «Интеграционная шина» может подключаться к приложениям 1С начиная с версии платформы 1С:Предприятие 8.3.17. Также поддерживается обмен по протоколу AMQP и возможно подключение к внешним брокерам сообщений.
  • Удаленный вызов API. Есть возможность выполнять HTTP запросы к внешним системам для получения или отправки данных, вызовов REST API или WEB-сервисов.
  • Обмен файлами. Сообщения могут быть сохранены в файловой системе или на FTP-сервере. Также сообщения могут порождаться при изменении файлов в файловой системе или на FTP-ресурсах.

Для организации взаимодействия систем предлагается следующая последовательность:

  1. Разработчик описывает интеграцию систем в специализированном редакторе, используя простую графическую нотацию.
    1. Маршрут движения сообщений представляется направленным графом, который показывает, как сообщения передаются от источников к назначениям.
    2. При необходимости можно определить сложный алгоритм маршрутизации сообщений или трансформировать сообщение при помощи процедуры на встроенном языке.
    3. Источником сообщения может быть файл, результат HTTP запроса, внешний брокер сообщений или подключенная к «Интеграционной шине» внешняя система (такие системы называются участниками взаимодействия).
    4. Полученное описание сохраняется в специальном объекте Процесс интеграции.
    5. Определяются параметры Процесса интеграции, значения которых будут определены во время исполнения (пути, адреса сервисов и пр.).
  2. Созданные разработчиком Процессы интеграции разворачиваются на сервере «Интеграционной шины».
  3. Администратору сервера доступен графический интерфейс управления «Интеграционной шиной», в котором:
    1. Задаются значения дополнительным параметрам Процесса интеграции
    2. Определяются правила подключения Участников взаимодействия к серверу «Интеграционной шины» и способ их участия в процессах интеграции
    3. Запускаются Процессы интеграции и начинают доставлять сообщения
    4. Останавливаются Процессы интеграции
    5. Доступны данные мониторинга работы Процессов интеграции: количество обработанных сообщений, ошибок и пр.

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

Безопасность и ролевая модель

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

Для обеспечения безопасности данных в DATAREON ESB поддерживается шифрование передаваемых данных с помощью алгоритмов шифрования AES, RC2 или TripleDES. Также поддерживается установка безопасного сетевого соединения по протоколу SSL или TLS.

Несмотря на то, что управление и настройка передачи данных для всей сети выполняется из единого инструмента управления, ответственность за работоспособность различных компонент может разделяться между пользователями. Разграничение прав доступа выполняется посредством ролевой модели. Уровень доступа пользователей может быть настроен в разрезе каждого объекта DATAREON ESB. Это позволяет разделять группы пользователей по зонам ответственности и ограничивать доступ к объектам DATAREON ESB согласно полномочиям.

Преимущества нашей «Интеграционной шины»

После знакомства с «Интеграционной шиной» может возникнуть естественный вопрос: рынок ПО класса ESB достаточно обширен, на нем представлено немало достойных продуктов, в том числе и бесплатных; зачем же фирме «1С» делать ещё один продукт, не изобретаем ли мы велосипед?

Конечно, перед тем, как принять решение разрабатывать «Интеграционную шину», мы задались тем же вопросом. И ответили себе на него так — да, делать продукт сто́ит, потому что:

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

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

Мы планируем этап бета-тестирования «Интеграционной шины» и будем рады помощи партнеров и клиентов. Чтобы участвовать в бета-тестировании продукта нажмите зелёную кнопку «Пробовать» в начале статьи.

Промышленные применения сети CAN

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

Стандартное использование CAN в «S-классе» Mercedes-Benz и принятие CAN коммерческими автопроизводителями США для быстрой передачи (до 1 Мбит / с) заставляли промышленных пользователей навострить уши. Не только производители мобильных и стационарных сельскохозяйственных и морских машин и оборудования выбрали CAN, но и выбор производителей медицинской аппаратуры, текстильных машин, а также специальной техники и элементов управления лифтами. Система последовательной шины особенно хорошо подходит для сетевых «интеллектуальных» устройств ввода-вывода, а также датчиков и исполнительных механизмов внутри машины или завода.

Промышленность текстильного машиностроения является одним из пионеров CAN. Один производитель оснастил свои ткацкие станки модульными системами управления, сообщающимися в режиме реального времени через сети CAN еще в 1990 году. Тем временем несколько производителей текстильных машин объединились в группу «CAN Textile Users Group», которая, в свою очередь, является членом международной группы пользователей и производителей «CAN in Automation». Аналогичные требования к текстильному оборудованию имеются в упаковочных машинах и машинах для производства и обработки бумаги.

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

Помимо высокой надежности передачи, низкие затраты на соединение на станцию являются еще одним решающим аргументом для CAN

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

Итоги

Как мы видим, последовательные интерфейсы пришли в компьютерную индустрию всерьёз и надолго. Не за горами времена, когда такие почётные долгожители, как PCI, IDE(PATA), SCSI, совсем уйдут со сцены, ибо преемники – PCI Express, Serial ATA, Serial Attached SCSI – уже агрессивно отвоёвывают позиции у «старичков». В стане процессорных шин пока паритет – архитектура K8 компании AMD c организацией процессорной шины на основе HyperTransport уже зарекомендовала себя как удачное решение, но и компания Intel с «последней редакцией» параллельной шины FSB (QPB) чувствует себя довольно уверенно и не собирается от неё отказываться.

Что касается возможной войны технологий PCI Express и HyperTransport, то здесь не тот случай – уж слишком разные сферы применения уготованы разработчиками этим решениям. Для вторжения в сферу сверхбыстрых передач у PCI Express недостаточно пропускной способности (максимум 8 ГБ/с для х16 против 41 ГБ/с у HyperTransport). Что касается работы HyperTransport с периферийными контроллерами, то данная шина не обладает для этого достаточными возможностями протоколов в силу своего изначального предназначения – замены процессорной шины, первое упоминание о «горячем» подключении появилось лишь в спецификации HyperTransport 3.0, да и стандартом пока что не предусмотрено внешних разъёмов.