0

我正在尝试为我正在开发的分布式平台定义规范数据模型，该模型基于以下架构：

  • RESTful API 外观，向客户端公开功能
  • 基于 Apache Camel 的底层中间件，用于路由和转换客户端请求
  • 中间件调用的 RESTful 业务服务

这个想法是让外观层将传入的请求转换为通用信息模型，该模型具有带有标头和有效负载的自定义消息的形式：

  • 标头应包含中间件（Apache Camel）所需的信息，以便将消息路由到请求的工作流（因此基本上，外观知道应该调用哪个业务流程来处理来自客户端的每个传入请求）。它可以建模为枚举映射或表示自定义消息的类的一组属性。
  • 有效负载应该包含一个适当的 Java bean，代表传入请求的“业务模型”（例如 TicketOrder 或 Customer 对象）。它可以建模为表示自定义消息的类中的 Object 属性，并且参与管理该消息的工作流的 Camel 的所有处理器/转换器都应该期待该有效负载类型（选定的 Java bean）。

简而言之，我正在尝试为中间件定义一个业务数据模型，该模型仅包含 Camel 处理传入请求并将它们路由到业务服务所需的相关信息。该数据被建模为 Java bean 并作为有效负载附加到消息中，其标头包含对 Camel 有意义的路由详细信息。

您将如何改进上述解决方案？你会说这是一个很好的方法并且足够灵活吗？非常感谢。

4

1 回答 1

0

如果您使用 Camel 作为（轻量级）ESB，我认为没有太多需要担心的事情。在骆驼路线中，您可以只保留最适合这种情况的格式，您甚至可以为某些解决方案并行运行多个格式（例如，您可以使用 Java Bean 执行一些业务逻辑，但您也可以使用 XSTL将消息转换为 XML 和 XPath 以获得更好的解耦并进行一些处理 CBR）。

如果您需要大量使用 Java Bean 模型，我建议您创建一个可以从 JSON 中提取模型的项目，这样您就可以控制该工件的版本（例如，使用 Maven），并且可以成为 Java 应用程序的规范模型（如果 JSON 请求发生很大变化，则需要更新此项目）。创建 Java 数据模型项目并使用 OSGi 容器会给您带来更多解耦的好处，因为 OSGi 可以为不同的应用程序使用不同版本的模型。

问候， 栾

于 2013-08-06T11:40:49.783 回答