Преобразование/нормализация протокола: Biztalk, альтернативы?

Question

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

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

• опроса и не опрос "водителей" (преобразователи протоколов)
• ручка RS232/RS485/TCP
• программируемые "драйверы" в управляемом языке, как Java или C#
• правил возможности двигателя

Имеет ли biztalk это?

Есть ли альтернативы с открытым исходным кодом?

Есть ли способ Java/Java EE для этого?

На одном конце система будет системой SCADA на другом, является своего рода сервером промежуточного программного обеспечения/обмена сообщениями.

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

Answer 1

Если вы не против работать на платформе Java, есть легкий коммутатор протоколов и реализация Enterprise Integration Patterns в проекте с открытым исходным кодом под названием Apache Camel.

Camel уже можно говорить большинство common protocols and technologies как files, email, JMS, XMPP и так далее, так что не было бы никакого фактического кодирования требуется для этих вещей.

Чтобы добавить новые пользовательские протоколы, самый простой маршрут состоит в том, чтобы построить поверх MINA component, который заботится обо всех сетевых подключениях, обработке сокетов, потоке и т. Д. (Например, NIO по сравнению с BIO и др.).

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

HL7 component - пример этого. Подробнее detail on writing MINA codecs here.

Тогда, как только у вас есть свой компонент верблюжий (позволяет называть его Foo) можно затем соединить с любым протоколом к ​​любому другому протоколу, используя простые идентификаторы URI для реализации любого из Enterprise Integration Patterns, таких как Content Based Router, Recipient List, Routing Slip и т.д.

например в Java коде

// route all messages from foo 
// to a single queue on JMS 
from("foo://somehost:1234"). 
    to("jms:MyQueue"); 

// route all messages from foo component 
// to a queue using a header 
from("foo://somehost:1234"). 
    recipientList(). 
    simple("activemq:MyPrefix.${headers.cheese}"); 

Answer 2

Я хотел бы избежать BizTalk для SCADA и RS232/RS485, потому что они обычно требуют решения в реальном времени (или по крайней мере с малой задержкой). BizTalk оптимизирован для высокой пропускной способности, но имеет недостаток, связанный с высокой задержкой по умолчанию.

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

Answer 3

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

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

Answer 4

www.livedata.com

Это немного дорогой, но это на основе двигателя питон, который может принимать один протокол и выплюнуть другой, это уже установка для нескольких протоколов, таких как Scada МККП, MODBUS, OPC и ДНП из коробки. Тогда вы можете говорить, что хотите, вниз по течению.

• Джон