问题描述
在一个骆驼的路线,我应该考虑把我的业务逻辑在离散托管端点豆,喜欢的消息驱动bean或Web服务,VS只是骆驼处理器实现它?
In a Camel route, should I be thinking about putting my business logic in a discretely hosted bean endpoint, like a message-driven bean or a web service, vs just implementing it in Camel processors?
好像关注使用骆驼只是调解和放大器清洁分离;配器,使用处理器作为过滤器,而不是作为对业务逻辑的容器。但是我不预见在这个时候EJB容器的需求,而且好像我需要一个主机的MDB。
It seems like cleaner separation of concerns to use Camel just for mediation & orchestration, using Processors as filters, rather than as a container for business logic. However I don't forsee the need for an EJB container at this time, and it seems like I'd need one to host MDBs.
所以,清洁架构VS占用空间更小,更少的技术 - ?有没有人有想法,观点,或者这个强烈的感情
So cleaner architecture vs smaller footprint, fewer technologies - Does anyone have thoughts, perspectives, or strong feelings about this?
推荐答案
我一般用骆驼来执行以下...
I generally use Camel to perform the following...
- 整合(文件,JMS,HTTP等)
- 来实现逻辑(基于内容的路由,过滤器,节流等)
- 基于定时器进程(使用或的)
- 异常处理(重试逻辑,错误日志/通知/排队)
- any component integration (file, jms, http, etc)
- to implement EIP logic (content based routing, filters, throttling, etc.)
- timer based processes (using timer or quartz)
- exception handling (retry logic, error logging/notification/queueing)
否则,业务逻辑是自包含(尤其是遗留集成),它可以是preferable使用的POJO或Web服务。这促进了可测试性,使您的应用程序更加模块化,等等。然后,你可以用骆驼以下...
Otherwise, for business logic that is self contained (especially legacy integration), it may be preferable to use POJOs or WebServices. This promotes testability and makes your application more modular, etc. Then, you can use Camel for the following...
- 要使用这些服务,的和
- 要这些服务连线连成的路线
- 管理/监控的消息流,异常处理
在关于长时间运行的进程,骆驼可以通过各种模式/技术(JMS,CXF,轮询促进这一消费者,预定作业等),以及使您 ...
In regards to long running processes, Camel can facilitate this via various asycnhronous patterns/technologies (JMS, CXF, polling consumers, scheduled jobs, etc.) as well as gives you control over threading...
这一切说,有很多方法可以切片。骆驼是轻量级的,灵活的,旨在简化集成现有的技术,而不是取代它们......好运气
That all said, there are many ways to slice it. Camel is lightweight, flexible and designed to ease integration with existing technologies, not replace them...good luck
这篇关于在骆驼业务逻辑处理器VS服务端点的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!