camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hasikada <>
Subject Multiple Camel contexts and request to multiple replies communication pattern (multicast)
Date Mon, 29 Jun 2015 13:01:54 GMT

I work on the ESB (entiprise service bus) project based on Apache Camel
running on Apache Karaf. The ESB provides several different services, Each
service provides REST API (e.g TestRest), service routes (e.g TestService)
and service beans (e.g TestBean). The service classs contains one CXFRS
route that delivers a REST request to an appropriate service route. Each
service is implemented as OSGI bundle. But currently the bundles are not
independent on each other. There is only one blueprint configuration for all
beans from all service bundles with only one Camel context. I plan to
refactor to situation where each service bundle has own blueprint and Camel
context. It raises question how to communicate between multiple independent
Camel Contexts. The JMS would be a possibility, but I need one request to
multiple replies pattern.

For example, I implemented the integrity check service (CheckService). The
service requests an integrity check on the other services (e.g MapService,
MediaService, NetworkService, etc).
	// CheckService


	    .multicast().aggregationStrategy(new ListAggregator<ServiceResponse>())

So, when an ESB client sends a REST request, CheckService needs to call each
integrity check service route over all known service bundles.

It would be nice if CheckService provides well known queue for the intergity
check requests. Any service bundle with integrity check implementation would
consumes request from the queue.

	// Check Service

	// MapService
	// MediaService

A ESB client sends the REST request for integrity check and expects the
aggregated check service result in the response.
It raises another question how to aggregate responses in
'direct:checkServices' route. Using request-reply messaging (InOut) in JMS
is not probably solution. Create another aggregation queue for responses
from services is not solution also due to asynchronous nature, as a client
expects result in REST request response.

Maybe the invert solution would work. Each service bundle registers its JMS
endpoint for integrity check to common database. The Check service reads
endpoints from the database and invoke them in request-reply manner.


Please, do you have any better idea?


View this message in context:
Sent from the Camel - Users mailing list archive at

View raw message