我正在考虑将哪种技术用于以下用例:
系统是事件驱动的 有一个流程(除了错误处理之外,大多数没有分支) 流本身应该是同步的,但是非阻塞的
到目前为止我的可能性是:from(URI) .transform(creatUserExpression) //prepare msg to send to db .inOut(DB.URI) //send to db .transform(UserCreatedExpression) //prepare msg to send to next step .inout(OtherService.URI) .end();
这看起来是一个很好的解决方案,但是骆驼适合处理我所有的业务逻辑 - 事件的所有流程? camel主要用于服务之间的集成,所以我们不确定将它用于业务逻辑是否正确
java RX - 看起来像一个可能的选项,仍然不够了解它,是否准备好生产? 当前版本为0.20.7 - 尚未成为1.X版本
akka - 试图将它用于流程 - 但是为了确保流程只采用一种方式我们需要使用FSM导致代码太复杂而我们决定反对它
任何其他建议将不胜感激
答案 0 :(得分:1)
我同意,大多数情况下,您通常会尝试在Integration路线中尽可能多地保持业务逻辑。 ESB上的业务逻辑通常是一个很大的问题,我所知道的一些更严格的架构师在他们看到集成层中的业务逻辑时会闯入暴力咒骂。当您使用ESB系统集成服务时,这种观点是有意义的。
在SOA / Services世界中,您不希望生产者和消费者紧密耦合,并且向集成层添加业务逻辑会打破这种抽象。消费者应该能够在不知道生产者如何工作的情况下使用来自SAP系统,C#Web服务,Java服务或任何其他服务的数据。它应该只是理解数据。
Apache Camel不是ESB,它是EIP工具包/框架。您也可以在客户端应用程序中使用Apache camel。这是我真的对Camel情有独钟的原因之一。它是我可以用来创建集成路由的库。它非常灵活,可以单独使用,无需使用全面的服务器。
所以在你的情况下,我没有看到使用apache camel出于此目的的问题。如果您要安装ServiceMix,FuseESB或其他完整的ESB系统,您只会使整个设置过于复杂。
我的建议(这只是一个建议)是,在这种情况下,在你的路线中有业务逻辑不会是坏事,因为这不是(从你的描述)关于集成,但利用Camel的力量来创建和维护一个事件系统。请记住,Camel没有运行时环境,因此您仍需要在某处托管此路由。一个简单的运行时容器是Apache Karaf。您可以使用此OSGi内核来安装和运行您的路由。上次我检查一下Karaf项目是不是低于40MB解压缩,所以与其他一些运行时间相比,它真的很小。
我已经以这种方式使用Camel为Android客户端创建和托管服务。我想我的主要信息是Camel可以被视为专门用于集成的路由引擎或路由引擎构建器。 Camel不是ESB,因此对业务逻辑的担忧并不总是适用。