旧式扩展 firefox_七个旧式整合模式

最新推荐文章于 2024-09-14 19:55:29 发布

danpu0978

最新推荐文章于 2024-09-14 19:55:29 发布

阅读量182

点赞数

文章标签：数据库 python java linux 大数据

原文链接：https://www.javacodegeeks.com/2020/06/seven-legacy-integration-patterns.html

版权

旧式扩展 firefox

如果现在我们必须集成两个（或更多）系统，我们知道–我们要么使用API，要么很少使用某些消息队列。

不幸的是，世界上许多系统不支持API集成。正如我们所说的，还有更多没有API的东西正在被创建。因此，当您不可避免地需要与它们集成时，您将留下不完善的选择。以下是与遗留系统（或以遗留方式构建的非遗留系统）集成的七个模式。

最初，我想使用“错误的集成模式”。但是，如果您没有其他选择，那么它们也不错–它们不可避免。糟糕的是，如此之多的系统继续构建而没有考虑集成的事实。

我已经不止一次看到了所有这些。而且我听到了更多关于它们的故事。不幸的是，它们也不是例外（幸运的是，它们也不是规则，至少现在不再如此）。

FTP上的文件-一个应用程序将文件（XML，CSV等）上载到FTP（或其他共享资源），而另一个应用程序通过计划的作业读取它们，解析它们并有选择地发送响应-在同一FTP或通过电子邮件。在集成方面，共享这样的文件肯定不是理想的选择–您无法获得请求的实时状态，而其他方面则很棘手–版本控制，高可用性，身份验证，安全性，可追溯性（审核线索）。
共享数据库 –共享同一个数据库的两个应用程序听起来像是灾难的秘诀，但是在野外看到它并不罕见。如果幸运的话，一个应用程序将是只读的。但是，打破数据库结构的更改和安全性问题是主要问题。您只能使用这种类型的集成，因为您将数据库直接暴露给了通常不希望执行的其他应用程序。
每日完整转储 –一些组织不是共享活动数据库，而是每天或每周对数据进行完整转储，并提供给另一方进行导入。随之而来的是明显的数据隐私问题，因为除了下面提到的所有内容（版本控制，身份验证等）之外，要对数据进行完整的转储（在某些情况下是在DVD或便携式HDD上）是不明智的。
搜寻 -当应用程序没有API时，仍然可以通过用户界面从应用程序中提取数据或将数据推送到其中。使用Web应用程序，因为它们“说” HTML和HTTP更容易。对于桌面应用程序，屏幕抓取已成为一种选择。所谓的RPA软件（机器人过程自动化）依赖于所有类型的抓取来集成遗留系统。它非常脆弱，需要复杂的（有时是昂贵的）工具才能正确使用。更不用说安全性方面了，这要求以非哈希形式将凭据存储在某个地方，以使抓取工具能够登录。
电子邮件 –当发送或接收系统不支持其他形式的集成时，电子邮件将是最后的选择。如果您可以通过连接邮箱来触发某些操作，或者在发送系统中发生某些事件之后生成电子邮件，则可能只需要集成它们即可。显然，电子邮件是一种非常糟糕的集成方式–它是非结构化的，由于多种原因它可能会失败，并且它并不是用于软件集成。如果您想获得更多创造力，则可以附加结构化数据，但是如果两端都可以支持相同格式，则可以扩展它们以支持适当的API。
适配器 –您可以开发一个自定义模块，该模块可以访问基础数据库，但可以公开适当的API。这几乎是可以接受的解决方案，因为您可以拥有独立于原始应用程序的正确编写的（某种）微服务，而其他系统则不知道它们是否与旧版软件集成在一起。但是，在某些情况下要正确设置它很棘手，因为您必须很好地了解数据库的状态空间。只读很容易，写起来更难甚至几乎不可能。
纸 -不，我没有化妆。在某些情况下，一个组织打印一些数据，然后另一个组织（或部门）接收纸质文档（通过邮件或其他方式）并将其输入到他们的系统中。那里存在昂贵的项目，这些项目旨在删除纸张组件并引入实际的集成，因为基于纸张的输入容易出错且运行缓慢。对于基于纸张的步骤，一些合法的情况是您需要额外的安全保护，而纸张痕迹以及有效地隔纸的事实可能会为您提供帮助。但是即使如此，它也不应该是唯一的传输层。