Sorry for not replying earlier..some other stuff came up :(
anonymous wrote : The answer is that we want both streams of objects in a single working
memory so the rules operate against the combined set of facts.
Are we talking about sharing a working memory between three services here?
OrderEventHandlingService and CustomerEventHandlingService would need to insert their
events/facts into the same working memory that the DiscountService later uses.
I guess this could be done by passing the RuleBase along with the ESB Message instance in
the pipeline but this could get messy given the current architecture.
Would a possible solution for this use case be that the OrderEventHandlingService did its
required transformations and post the result to a JMS destination. The DiscountService
Drools Fusion application then uses that destination as the one of its sources for event.
It would do the same for the CustomerEventHandlingService.
What is the advantage of putting this business logic in an ESB service. This would mean
that replacing the ESB would also affect you business application as opposed to
"simply" configuring the new ESB with a transformation and a router to a JMS
destination in this case.
View the original post :
Reply to the post :