协议转换/规范化:Biztalk,替代方案?

发布于 2024-07-07 09:04:08 字数 423 浏览 5 评论 0 原文

我们需要从安全系统、火灾报警器、摄像系统等系统中获取数十种不同的协议,并将它们集成到一个通用协议中。

我希望这是一个消息服务器,许多系统可以订阅和/或通过它进行通信。

  • 轮询和非轮询“驱动程序”(协议转换器)
  • 处理 RS232 / RS485 / tcp
  • 以 Java 或 C# 等托管语言
  • 可编程“驱动程序”规则引擎功能

biztalk 适合吗?

有开源替代品吗?

有没有 Java/Java EE 方法可以做到这一点?

该系统一方面是 SCADA 系统,另一方面是中间件/消息传递服务器。

任何关于最佳方式的想法将不胜感激。 我知道驱动程序端将涉及大量编程,但是尽管我很想从头开始构建整个系统,但这是不合适的。

We have a need to take dozens of different protocols from systems such as security systems, fire alarms, camera systems etc.. and integrate them into a single common protocol.

I would like this to be a messaging server that many systems could subscribe to and or communicate through.

  • polling and non-polling "drivers" (protocol converters)
  • handle RS232 / RS485 / tcp
  • programmable "drivers" in a managed language like Java or C#
  • rules engine capability

Does biztalk fit this?

Are there open source alternatives?

Is there a Java / Java EE way to do this?

At one end the system would be a SCADA system at the other is is kind of a middleware / messaging server.

Any thoughts on the best way to proceed would be appreciated. I know that there will be a considerable amount of programming involved on the driver side, however as tempted as I am, building the whole system from scratch would not be appropriate.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

仙女山的月亮 2024-07-14 09:04:08

我会避免使用 BizTalk for SCADA 和 RS232/RS485,因为这些通常需要实时(或至少低延迟)解决方案。 BizTalk 针对高吞吐量进行了优化,但存在默认情况下延迟较高的缺点。

您可以调整 BizTalk 以实现低延迟,但此时您会发现您绕过了 BizTalk 内置的几乎所有内容,并且它可能会妨碍您而不是帮助您。

I would avoid BizTalk for SCADA and RS232/RS485 because these typically require realtime (or at least low latency) solutions. BizTalk is optimized for high throughtput, but has the drawback of having high latency by default.

You can tweak BizTalk for low latency, but at this point you'll find you bypass almost everything BizTalk has built-in and it would probably get in the way instead of helping you.

入画浅相思 2024-07-14 09:04:08

如果您不介意在 Java 平台上工作,这里有一个轻量级协议切换器和 Apache Camel 的开源项目中的“企业集成模式”。

Camel 已经可以使用大多数常见协议和技术,例如 文件, 电子邮件JMSXMPP 等等,因此这些事情不需要实际编码。

要添加新的自定义协议,最简单的方法是在 MINA 组件 之上构建,该组件负责所有网络、套接字处理、线程等(例如,NIO 与 BIO 等)。

然后,您只需扩展它以添加您自己的协议编解码器(如何在套接字上编组/解组消息,可能使用帧等)。

HL7 组件 就是执行此操作的一个示例。 更多在此处编写 MINA 编解码器的详细信息

然后,一旦您获得了 Camel 组件(我们称之为 foo),您就可以使用简单的 URI 从任何协议桥接到任何其他协议,以实现任何 企业集成模式,例如 基于内容的路由器收件人列表路由单等,

例如 在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}");

If you don't mind working on the Java platform there's a lightweight protocol switcher and implementation of the Enterprise Integration Patterns in an open source project called Apache Camel.

Camel can already speak most of the common protocols and technologies like files, email, JMS, XMPP and so forth so there'd be no actual coding required for those things.

To add new custom protocols the simplest route is to build on top of the MINA component which takes care of all the networking, socket handling, threading and so forth (e.g. NIO versus BIO et al).

Then you just extend it to add your own protocol codec (how to marshal/unmarshal messages on the socket with possibly using framing etc).

The HL7 component is an example of doing this. More detail on writing MINA codecs here.

Then once you've got your camel component (lets call it foo) you could then bridge from any protocol to any other protocol using simple URIs to implement any of the Enterprise Integration Patterns such as Content Based Router, Recipient List, Routing Slip etc

e.g. in Java code

// 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}");
再见回来 2024-07-14 09:04:08

www.livedata.com

它有点贵,但它是一个基于 python 的引擎,可以采用一种协议并吐出另一种协议,它已经为多种 SCADA 协议(例如 ICCP、modbus、OPC 和 DNP)进行了设置,开箱即用。 然后你就可以在下游谈论任何你想谈论的事情。

  • 约翰

www.livedata.com

It's a bit pricey but it's a python based engine that can take one protocol and spit out another, it's already setup for multiple scada protocols such as ICCP, modbus, OPC, and DNP out of the box. Then you can talk whatever you want downstream.

  • John
ぺ禁宫浮华殁 2024-07-14 09:04:08

我建议OpenSCADA。 该网站目前有点混乱,但该软件正在积极使用和积极开发中。 一个明确的目标是为 SCADA 用例创建一个通用的、技术独立的接口(尽管目前方向或多或少面向 java [但我们也尝试使用 ikvm 创建 .NET 版本])。

因此,您可以使用 OpenSCADA 与所有“硬件”设备进行通信,然后创建一个连接其余中间件的桥,或者创建一个 OpenSCADA 桥作为中间件中的插件。 例如,我们已经有连接到读卡器的驱动程序,这些读卡器通过串行服务器连接到 LAN。

I suggest OpenSCADA. The website is at the moment a bit of a mess, but the software is actively in use and in active development. A explicit goal is to create a common, technology independent, interface for SCADA use cases (although at the moment the direction is more or less oriented towards java [but we experiment also with ikvm to create a .NET version]).

So you could use OpenSCADA to communicate with all the "hardware" devices and then create a bridge to the rest of your middleware, or create a OpenSCADA bridge as a plugin within your middleware. We already have for instance drivers which connect to card readers linked via a serial server to the LAN.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文